Just wanted to follow up to mention that using sys_reboot approach we were able to get our device to consistently re-connect to LTE after dropouts. Thanks again for your help.
Reconnecting LTE after Disconnect
occurrentarts excellent!! When you have time I would upgrade to the latest MFW and NCS so you can avoid rebooting the device.
Also, you only need to run the connect() call once in your application. Turning the modem on into “normal” mode should make it connect. (That’s what I’m doing in the aforementioned sample)
- Edited
Hi Jared,
Brian (a.k.a. occurrentarts) has just rewritten the code to work with the 1.7.1 SDK and the latest MFW, which appears to be working well. Meanwhile, I’m having a problem applying the MFW firmware update and could use your assistance to figure it out.
Here’s what shows up in the terminal when I attempt to apply the update:
PS D:\David\Wildlife\DeterGents\ZephyrToolsRepo\nfed\samples\mfw_update> python3 update_modem.py mfw_nrf9160_1.3.1.zip com3 1000000
# modem firmware upgrade over serial port example started.
[HighLevel] Creating new probe
[HighLevel] Initialize new probe.
[Probes.com3] [ModemUARTDFUProbe] Dll directory is C:\Users\barli\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\pynrfjprog\lib_x64.
[Probes.com3] [ModemUARTDFUProbe] Find and connect to dfu dll
[Probes.com3] [ModemUARTDFUProbe] Using DFU dll at C:\Users\barli\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\pynrfjprog\lib_x64\NRFDFU.dll.
[Probes.com3] [ModemUARTDFUProbe] Load library at C:\Users\barli\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\pynrfjprog\lib_x64\NRFDFU.dll.
[Probes.com3] [ModemUARTDFUProbe] Library loaded, loading member functions.
[Probes.com3] [ModemUARTDFUProbe] Member functions succesfully loaded.
[Probes.com3] [ModemUARTDFU-com3] Initialize new probe.
[Probes.com3] [ModemUARTDFU-com3] Successfully opened port: com3@1000000,flow_control:none,parity:none.
[Probes.com3] [ModemUARTDFU-com3] {
"duration": 903,
"error_code": "Ok",
"operation": "open_uart",
"outcome": "success",
"progress_percentage": 100
}
[HighLevel] Probe initialization complete!
[Probes.com3] [ModemUARTDFU-com3] Check if provided file exists
[Probes.com3] [ModemUARTDFU-com3] Check if provided file can be read
[Probes.com3] [ModemUARTDFU-com3] Programming bootloader
[Probes.com3] [ModemUARTDFU-com3] Programming modem bootloader 72B3D7C.ipc_dfu.signed_1.1.0.ihex.
[Probes.com3] [ModemUARTDFU-com3] Extracting 13416 bytes from 72B3D7C.ipc_dfu.signed_1.1.0.ihex.
[Probes.com3] [ModemUARTDFU-com3] {
"duration": 0,
"message": "Calculating image size",
"operation": "upload_image",
"progress_percentage": 5
}
[Probes.com3] [ModemUARTDFU-com3] {
"duration": 0,
"message": "Uploading image to device",
"operation": "upload_image",
"progress_percentage": 10
}
[Probes.com3] [ModemUARTDFU-com3] {
"duration": 30004,
"error_code": "Timeout",
"message": "Image upload failed. Bad response from device",
"operation": "upload_image",
"outcome": "fail",
"progress_percentage": 100
}
[Probes.com3] [ModemUARTDFU-com3] Error during image file upload. Upload returned an error.
[Probes.com3] [ModemUARTDFU-com3] Failed to program bootloader file
[Probes.com3] [ModemUARTDFUProbe] Failed to program DFU package
[HighLevel] Failed programming the device.
[Probes.com3] b'An error was reported by NRFJPROG DLL: -220 TIME_OUT. \n[Probes.com3] [ModemUARTDFU-com3] Error during image file upload. Upload returned an error.\n\textra: [Probes.com3] [ModemUARTDFU-com3] Failed to
program bootloader file\n\textra: [Probes.com3] [ModemUARTDFUProbe] Failed to program DFU package\n\textra: [HighLevel] Failed programming the device.'
[Probes.com3] [ModemUARTDFUProbe] Uninitializing ModemUARTDFU probe at serial port com3.
[Probes.com3] [ModemUARTDFU-com3] Sending device reset request
[Probes.com3] [ModemUARTDFU-com3] Sending reset request to device.
[Probes.com3] [ModemUARTDFU-com3] Closing connection to mcuboot device
[Probes.com3] [ModemUARTDFU-com3] serial port com3 closed.
[Probes.com3] [ModemUARTDFU-com3] {
"duration": 1,
"error_code": "Ok",
"operation": "close_uart",
"outcome": "success",
"progress_percentage": 100
}
[HighLevel] Done.
[HighLevel] Closing and freeing sub dlls.
Traceback (most recent call last):
File "D:\David\Wildlife\DeterGents\ZephyrToolsRepo\nfed\samples\mfw_update\update_modem.py", line 43, in <module>
run(args.uart, args.firmware, args.baudrate)
File "D:\David\Wildlife\DeterGents\ZephyrToolsRepo\nfed\samples\mfw_update\update_modem.py", line 26, in run
modem_dfu_probe.program(modem_firmware_zip)
File "C:\Users\barli\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\pynrfjprog\HighLevel.py", line 388, in program
raise APIError(result, error_data=self.get_errors(), log=self._logger.error)
pynrfjprog.APIError.APIError: An error was reported by NRFJPROG DLL: -220 TIME_OUT.
[Probes.com3] [ModemUARTDFU-com3] Error during image file upload. Upload returned an error.
extra: [Probes.com3] [ModemUARTDFU-com3] Failed to program bootloader file
extra: [Probes.com3] [ModemUARTDFUProbe] Failed to program DFU package
extra: [HighLevel] Failed programming the device.
Thanks,
David
Barliesque you can actually use nrfjprog
to apply modem firmware updates now.
nrfjprog --program mfw.zip
You do need a programmer that supports mfw updates though. I know the nRF9160DK works.
You can get the latest nrfjprog
from Nordic here: https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools/download
- Edited
I don’t understand why I would need to get a programmer, given Brian was able to apply the firmware update without it – I’m just trying to follow the same process he’s already had success with.
I have your SDK tools installed in VS Code, with the following:
nrfjprog version: 10.15.0 external
JLinkARM.dll version: 6.88a
Ahh I saw nrfjprog DLL in the output so I assumed you were trying to use a programmer. My bad.
As for the error, it’s stating a timeout. So, I would make sure that
- The mfw_update sample is programmed to the device
- That you’re choosing the correct serial port
- Also to be doubly sure make sure you install the python requirements:
pip3 install -r requirements.txt
Run that within the mfw_update
sample folder.
Hope that helps
Also what type of system are you running this on? Windows?
PS D:\David\Wildlife\DeterGents\ZephyrToolsRepo\nfed\samples\mfw_update> pip3 install -r requirements.txt
Requirement already satisfied: pynrfjprog in c:\users\barli.zephyrtools\env\lib\site-packages (from -r requirements.txt (line 1)) (10.15.2)
Requirement already satisfied: future in c:\users\barli.zephyrtools\env\lib\site-packages (from pynrfjprog->-r requirements.txt (line 1)) (0.18.2)
I am running on WIndows, yes.
I’ve also verified the device is on COM3
Any ideas?
The mfw_update sample is programmed to the device
Can you confirm Barliesque?
Make sure your device is not in bootloader when running the script. Also make sure you don’t have any open serial connections to COM3.
Yes, mfw_update is programmed to the device. Using LTE Link Monitor, all AT commands fail – not sure if that’s expected for mfw_update. Pressing the RST button doesn’t cause any messages to appear there either. Before attempting the upload, I’ve made sure to close down anything that could have an open connection to COM3. The blue light is unlit, so not in bootloader mode.
- Edited
Are you able to run at_client
on that board? (And try again with AT commands?) The mfw_update firmware will not respond to AT commands.
Sorry, where do I find that?
I’ve run plenty of things on this board to know it works properly–most recently Blinky, which I installed just before the mfw_update.
The biggest thing is to confirm bidirectional comms over that USB to UART chip. You can find at_client
in nfed/samples/at_client
Built and installed the at_client, then opened up LTE Monitor, pressed RST button and the terminal showed this:
2022-03-03T02:48:48.515Z DEBUG modem << õýÕ÷¯ÿõ÷õÕUý÷·Uÿõ÷÷ýßõõõõõõ÷õõ÷ÿõ½×õõý÷µÿÿõ÷·ÿßÿõýwõ÷õÿuõõÿõUuW÷uõõUu_UuõõWu]UõýUuWUuõõUuýõÝõWw}õuýWuÿõýõUw]UõõUwÿõßõUõýUõýWw}õõõýõ÷õ]ÝõUõõUõýWuõUõýUwõUõýUuõUõýWuÿ]]ÕõW÷õõÝõWw_uõõõýuWuõõõUuWuõõõýõõõõÝõWõ÷õõýõWWÿÕwuõwß__õU»uuu}õU÷WýUõõU÷õõ_}Uý}ÝõýõõõõýõÿuõõU*** Booting Zephyr OS build v2.6.99-ncs1-1 ***
2022-03-03T02:48:48.520Z DEBUG modem << The AT host sample started
Kind of gives me mixed messages there – looks like the at_client is working, but what’s the garbage before that? Is it maybe some random data that’s been sent as a test?
It’s the SPM image running at 1M baud. Change your BAUD to 1M to see what it says.
If you hit AT
and press enter, does it respond?
- Edited
jaredwolff If you hit AT and press enter, does it respond?
It responds to AT with OK.
jaredwolff Change your BAUD to 1M…
I thought it already was at 1M
For monitoring its 115200
For transferring its 1000000