I tried to update firmware over UART (using MCUboot).
The flag shows test pending, and was able to test the application and provide expected output.
But was not able to "confirm image", it shows Error:NMP timeout, when the confirm image command is executed.
Thanks in advance
Hi,
Did you ever restart your application during the DFU procedure?
Do you use Serial Recovery or an SMP Server in the application? (See my unofficial tutorial on MCUboot to learn the difference)
Regards,
Sigurd Hellesvik
Hi Sigurd Hellesvik
Yes I'm using a example samples/subsys/mgmt/mcumgr/smp_svr from NCS v2.2
I executed commands as shown below:
Case:1 (I did reset)
mcumgr <connection string> image test <hash of slot-1 image>
sudo mcumgr <connection string> reset
After the test, it reverts back.
Case:2
And by using the command : sudo mcumgr <connection string> image confirm , it works without reverting the images.
So,
1. What should be done in case 1, so that the image files are not reverted after reset.
2. In case 2, how can I update with a new image again (for the 2nd time), because I assume the images are swapped in this case after 1st update and it no longer receives mcumgr command.
It shows Error:NMP timeout, when trying to execute mcumgr command.
lorao said:1. What should be done in case 1, so that the image files are not reverted after reset.
When you are running an image in "test" mode, you must tag it as "confirmed" to not revert back on the next reset.
This can be done in multiple ways:
If the new application supports an SMP Server, you can use said SMP Server to confirm the image, using "mcumgr ... confirm" as you are trying to do.
Alternatively, you can call boot_write_img_confirmed() from your test-mode application. Remember to only confirm the image from the application after you are sure that the running application works fine.
lorao said:2. In case 2, how can I update with a new image again (for the 2nd time), because I assume the images are swapped in this case after 1st update and it no longer receives mcumgr command.
To update again, the new image must also support mcumgr commands.
If you ever update to an image without mcumgr support (an SMP Server), you can no longer update the device.
The alternative is Serial Recovery, where you can send mcumgr commands to MCUboot, so that you can always update over serial.
lorao said:It shows Error:NMP timeout, when trying to execute mcumgr command.
NMP timeout means that mcumgr-cli can not get any responses from the nRF chip. Often because the SMP Server is not running on the device, or not connected to the correct uart.
Regards,
Sigurd Hellesvik
lorao said:1. What should be done in case 1, so that the image files are not reverted after reset.
When you are running an image in "test" mode, you must tag it as "confirmed" to not revert back on the next reset.
This can be done in multiple ways:
If the new application supports an SMP Server, you can use said SMP Server to confirm the image, using "mcumgr ... confirm" as you are trying to do.
Alternatively, you can call boot_write_img_confirmed() from your test-mode application. Remember to only confirm the image from the application after you are sure that the running application works fine.
lorao said:2. In case 2, how can I update with a new image again (for the 2nd time), because I assume the images are swapped in this case after 1st update and it no longer receives mcumgr command.
To update again, the new image must also support mcumgr commands.
If you ever update to an image without mcumgr support (an SMP Server), you can no longer update the device.
The alternative is Serial Recovery, where you can send mcumgr commands to MCUboot, so that you can always update over serial.
lorao said:It shows Error:NMP timeout, when trying to execute mcumgr command.
NMP timeout means that mcumgr-cli can not get any responses from the nRF chip. Often because the SMP Server is not running on the device, or not connected to the correct uart.
Regards,
Sigurd Hellesvik
Sigurd Hellesvik Thank you for the suggestion.
I think the option of using Serial recovery would be good one.
Please can you explain a bit on how to use serial recovery and what needs to be changed in the current smp_svr application.
Thank you!
I have explained this in my my unofficial tutorial on MCUboot, where you also can find examples for Serial Recovery
Sigurd Hellesvik So, if I understood it correctly, I can use "mcuboot_serial_recovery_uart" from the example you provided instead of smp_svr ?
That will enable to update firmware multiple times right?
Yes and yes.
Since it is an unofficial sample, I will add this following discalimer:
Beware that this code/configuration is not fully 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.
Sigurd Hellesvik Thank you. Serial recovery worked as expected.!!!
I would like to make few changes:
1) Is it possible to change the process of entering to serial recovery mode by 'sending a command over UART' instead of 'pressing Button 1', with out power cycle?
If not, any suggestions on how to implement the process in which the device enters the bootloader mode by sending a command over UART, without physically pressing any buttons on the device
Thank you!