Tool for flashing nrf52840 SoC while doing Firmware upgrade

[Tamizh]

Hi,

I'm using nrf52840SoC(flashed with open-thread rcp firmware) on a custom IMX-ULL-6 board. Is Jlink the only way to flash the firmware into the nrf52840 SoC? 

I'm asking this because after product deployment, if I want to provide a firmware upgrade to the devices, it won't be possible to use JLink, right? 

So,

1)Is there any other way to flash the firmware into the SoC?

2) Which upgrade method do you suggest for my use case with a firmware upgrade?

[Marte Myrvold]

Hi,

You can use a bootloader to perform a device firmware update. With the OpenThread RCP application, the best option is to use serial recovery. With serial recovery, you can perform DFU at boot.
One of my colleagues has made some samples showcasing how to do this, both over UART and USB, which you can find here: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery. This code is not thoroughly tested or qualified and should be considered provided “as-is”. Please test it with your application and let me know if you find any issues.

Best regards,

Marte

[Tamizh]

Hi Marte Myrvold ,

Sorry for the late response as I've faced a delay in receiving the custom board for checking.

While the UART serial recovery method you mentioned works flawlessly on the nrf52840dk board, I have not had the same success with my custom board using the wait method to enter recovery on each boot. Fortunately, this discussion has provided me with some useful insights.

 MCUBoot usb with openthread sample 

Could you guide me on where to make the changes referred to in that thread that supposedly worked? I couldn't locate the file.

Thanks

[Tamizh]

Yes, I can run Applications like echo bot, Open thread, and even SMP_SVR without MCUboot. 
I'm able to send mcumgr commands and get responses while running SMP_SVR application(in the samples of nrf_sdk)

But this serial recovery Image only has issues. After flashing the above-mentioned serial recovery into the SoC, I'm able to see that the bootloader is waiting for the specified time for entering into Recovery( from the minicom logs).

But the problem is that mcumgr commands are getting NMP Timeout instead of a response like the above.

Am I missing anything here?

[Marte Myrvold]

Hi,

This error means that the mcumgr cannot connect to the device. It can be due to mcumgr not being present on the board, or that the connstring is incorrect. Can you verify that the device's serial port is the same as what you used in the connstring for acm0?

Best regards,

Marte

[Tamizh]

Hi,

The connection string is correct and I'm using the same port for SMP_SVR and this serial recovery. 

For the latter, it doesn't work.

[Marte Myrvold]

Hi,

I see that you have CONFIG_MCUBOOT_INDICATION_LED=y set in mcuboot.conf. Do you see LED 1 turn on, indicating that the bootloader is in serial recovery mode?

Is the COM port open somewhere else? This might also cause NMP timeout.

Best regards,
Marte

[Tamizh]

Hi,

We didn't have the LED to verify in the custom board. But I can see that the application is loaded after 5 secs wait, even if I send the mcumgr command(which gets timeout as a response).  The port is also not communicating with any other service (during this process). Can you suggest any method for verifying whether the SMP server is running on the bootloader while resetting the SoC?

[Marte Myrvold]

Hi,

You have RTS/CTS flow control enabled in the uart.overlay (hw-flow-control), which might be causing issues with mcumgr. Please try removing this and see if that fixes the problem. Since you are making changes to devicetree, you should delete the build directory completely before rebuilding.

Best regards,
Marte

[Tamizh]

Hi,

No luck. Even after removing hw-flow-ctrl and pristine build still, the results are same

[Sigurd Hellesvik]

Hi,

Marte is out of the office, so I will continue helping in this case in the meantime.

Try to compare the following files between the project that works (for DK) and for your custom board:

• build/zephyr/zephyr.dts
• build/zephyr/.config

Do you see any differences that could cause the error here?
If not, upload these four files, and I can try to compare them as well.

Regards,
Sigurd Hellesvik

[Tamizh]

Hi Sigurd Hellesvik ,

Thanks for the follow-up.

Here is the attachment which includes the above-mentioned files for both nrf52840DK and the custom IMX board.

https://drive.google.com/file/d/1A_IEFxiJSrfn90I4QftsVaZP3MQxCOBx/view?usp=sharing

Thanks.

[Sigurd Hellesvik]

Looking at these files, nothing looks out of the ordinary.

Can you confirm that I understand the following correctly?

• Serial Recovery works on the nRF52840DK on your end
• SMP Server in the application works on your custom IMX board.
• Serial Recovery with button/pin trigger does not work on your custom IMX board
• Serial Recovery with wait trigger does not work on your custom IMX board

I realize that we should also check the configuration files for the bootloader.
Can you also upload

• build/mcuboot/zephyr/zephyr.dts
• build/mcuboot/zephyr/.config

Regards,
Sigurd Hellesvik