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) 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?
That would be more or less the CDC ACM feat Wait feature. This uses USB instead of UART, but you can add Wait you your UART sample in the same way.
That would be more or less the CDC ACM feat Wait feature. This uses USB instead of UART, but you can add Wait you your UART sample in the same way
CDC ACM feat Wait feature, this did not work for (also using USB).
Please can you suggest what changes needs to be made in oder to use UART.
And as mentioned to enter serial recovery mode by 'sending a command over UART' with out power cycle?
Thank you!
lorao said:CDC ACM feat Wait feature, this did not work for (also using USB).
Did not work how?
lorao said:And as mentioned to enter serial recovery mode by 'sending a command over UART' with out power cycle?
You can make your device do this.
In your application, you can create an UART handler which calls sys_reboot() on your device.
Then send an mcumgr command during the wait period.
You can make your device do this.
In your application, you can create an UART handler which calls sys_reboot() on your device.
Then send an mcumgr command during the wait period.
Is this to be implemented on bootloader or in the main application? (for example if the main application is to Blink LED)
Sigurd Hellesvik said:In your application, you can create an UART handler which calls sys_reboot() on your device.
Main application
Sigurd Hellesvik said:Then send an mcumgr command during the wait period.
External device.
The bootlaoder runs before the application, and stops when the application is running
Therefore, you can not receive input to the bootloader when the main application is running.
The device must be reset for the bootloader to run again.
Sigurd Hellesvik said:In your application, you can create an UART handler which calls sys_reboot() on your device.
Main application
Sigurd Hellesvik said:Then send an mcumgr command during the wait period.
External device.
The bootlaoder runs before the application, and stops when the application is running
Therefore, you can not receive input to the bootloader when the main application is running.
The device must be reset for the bootloader to run again.
Sigurd Hellesvik I have implemented UART handler to call sys_reboot(SYS_REBOOT_COLD).
And using bootloader from your example mcuboot_serial_recovery_uart by adding
Does the bootloader run if you reboot the device manually? (via button or reset pin)
Also, try to set CONFIG_MCUBOOT_INDICATION_LED for MCUboot, and see if the LED lights up
Sigurd Hellesvik Yes by pressing button 1 while power cycle the bootloader runs fine.
Also LED lights up (LED 1) for mcuboot_serial_recovery_uart
But not with reset button
This works fine on my end.
Turns out that CONFIG_MCUBOOT_INDICATION_LED only works for Button mode, and is not supported for Wait mode.
If you want to enable this for Wait mode, you can apply these changes temporarily to MCUboot:
diff --git a/boot/zephyr/main.c b/boot/zephyr/main.c
index 2c5f9afd..3081f845 100644
--- a/boot/zephyr/main.c
+++ b/boot/zephyr/main.c
@@ -620,9 +620,14 @@ void main(void)
* some time, so it's better to reuse thistime to already receive the
* initial mcumgr command(s) into our buffers
*/
+
+#ifdef CONFIG_MCUBOOT_INDICATION_LED
+ gpio_pin_set_dt(&led0, 1);
+#endif
rc = boot_console_init();
int timeout_in_ms = CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT;
uint32_t start = k_uptime_get_32();
+
#endif
FIH_CALL(boot_go, fih_rc, &rsp);
@@ -646,6 +651,10 @@ void main(void)
timeout_in_ms = 1;
}
boot_serial_check_start(&boot_funcs,timeout_in_ms);
+
+#ifdef CONFIG_MCUBOOT_INDICATION_LED
+ gpio_pin_set_dt(&led0, 0);
+#endif
#endif
if (FIH_NOT_EQ(fih_rc, FIH_SUCCESS)) {
Are you able to see that sys_reboot(SYS_REBOOT_COLD) works with these changes?
Sigurd Hellesvik Now the bootloader lit's up the LED for 5 sec and waits for mcumgr command and if there are no commands send in 5 sec then LED turn off (works as expected)
But after updating the application firmware, and resetting the device, then later the LED turns ON back after 5 secs and never runs the application.
And it works fine if the below configs are not included: