NRF54L15 - DFU over UART. Not able to update the Firmware.

[varsha@]

Hello,

I am trying to send the zephyr.signed.bin file to the NRF54L15 through TTL, using "send file" option in TeraTerm (Trying on DK for now, the Custom Device will be taking the Data from another Micro controller  through UART in actual case).

But I can see that the Data is getting written into the IMAGE_1 slot of the flash, but the  firmware update is not taking place, and the old firmware runs again. I am not able to debug on how to start with solving this issue. 

According to me , the doubts are: 

1.  How to Validate if I am able to write the data into the FLASH properly or not. 

2.  How to validate if what I have written into the Flash (IMAGE_1 / Secondary Slot) is not corrupted.

3.  I am getting an error as well : Image in the secondary slot is not valid! - How to Debug this?

The logs : 

SEGGER J-Link V8.18 - Real time terminal output
SEGGER J-Link (unknown) V1.0, SN=1057786512
Process: JLink.exe
*** Booting MCUboot v2.1.0-dev-ae1ee57f3906 ***
*** Using nRF Connect SDK v3.0.2-89ba1294ac9b ***
*** Using Zephyr OS v4.0.99-f791c49f492c ***
[00:42:57.631,091] <inf> mcuboot: Starting bootloader
[00:42:57.631,360] <dbg> mcuboot: boot_slots_compatible: Non-optimal sector distribution, slot0 has 76 usable sectors (84 assigned) but slot1 has 84 assigned
[00:42:57.631,632] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:42:57.631,819] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:42:57.631,988] <inf> mcuboot: Boot source: none
[00:42:57.632,123] <inf> mcuboot: Image index: 0, Swap type: none
[00:42:57.668,235] <inf> mcuboot: Bootloader chainload address offset: 0xf000
[00:42:57.668,384] <inf> mcuboot: Image version: v0.0.0
[00:42:57.668,499] <inf> mcuboot: Jumping to the first image slot
*** Booting nRF Connect SDK v3.0.2-89ba1294ac9b ***
==========data cameee===========
evt->data.rx.len = 50732
wrote data length= 256   from address = 0
wrote data length= 256   from address = 256
wrote data length= 256   from address = 512
wrote data length= 256   from address = 768
wrote data length= 256   from address = 1024
wrote data length= 256   from address = 1280
wrote data length= 256   from address = 1536
.
.
.
.
.
wrote data length= 256   from address = 50432
wrote data length= 44   from address = 50688
Total bytes in image_1: 50732
*** Booting MCUboot v2.1.0-dev-ae1ee57f3906 ***
*** Using nRF Connect SDK v3.0.2-89ba1294ac9b ***
*** Using Zephyr OS v4.0.99-f791c49f492c ***
[00:44:13.027,971] <inf> mcuboot: Starting bootloader
[00:44:13.028,239] <dbg> mcuboot: boot_slots_compatible: Non-optimal sector distribution, slot0 has 76 usable sectors (84 assigned) but slot1 has 84 assigned
[00:44:13.028,509] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:44:13.028,696] <inf> mcuboot: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
[00:44:13.028,861] <inf> mcuboot: Boot source: none
[00:44:13.028,996] <inf> mcuboot: Image index: 0, Swap type: test
[00:44:13.406,143] <err> mcuboot: Image in the secondary slot is not valid!
[00:44:13.442,267] <inf> mcuboot: Bootloader chainload address offset: 0xf000
[00:44:13.442,415] <inf> mcuboot: Image version: v0.0.0
[00:44:13.442,529] <inf> mcuboot: Jumping to the first image slot
*** Booting nRF Connect SDK v3.0.2-89ba1294ac9b ***
*** Using Zephyr OS v4.0.99-f791c49f492c ***
Opened image_1 flash area successfully.
Erased image_1 flash successfully.
Ready to receive firmware via UART...
no err : device_is_ready
err = -134 : uart_configure
err = 0 : uart_callback_set

Line 228 gives an error.

[Marte Myrvold]

Hi,

Have you tried using AuTerm instead of TeraTerm? I recommend looking at Exercise 1 – DFU over UART in our nRF Connect SDK Intermediate course on DevAcademy. This shows how to add DFU over UART to your application and how to perform DFU using AuTerm.

Best regards,
Marte

[varsha@]

Yes , I did try this, but I was unable to use the AuTerm application as, as I was getting the Timeout error. Also , I wanted to try manually, by writing the data into the flash,  as I will be using a micro controller to send the Firmware for Update through UART.

[Vidar Berg]

Hello,

Does LED 0 start blinking after you flash the firmware, indicating that your Blinky app is running (or in mcuboot serial recovery mode)?  Also note that when enabling SMP over UART in your app you need to make sure you don't have the console or logger module assigned to the same UART instance. I suggest you try with the following configurations added to your prj.conf file

CONFIG_UART_CONSOLE=n

CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_USE_SEGGER_RTT=y

[varsha@]

Yes, I just tried the configs you provided. Still there is no change.

Vidar Berg said:

Does LED 0 start blinking after you flash the firmware, indicating that your Blinky app is running

Yes, the LED 0 blinks every 1 second, and if I press button 1 + Reset button, The LED1 stays on and LED0 stops blinking. I tried to get the image list using mcumgr in both the "normal mode" as welll as in the "serial recovery mode" as I was not sure in which mode I should be using the mcumgr commands.  I am getting the same Timeout error.

Same with the Auterm. I tried to get the Image -> Get -> Go after making configurations. 

And the error was - Timeout (Mode: List image state)

[Vidar Berg]

It's strange that you are getting the timeout both when running in serial recovery mode in mcuboot and also in the app. I'm not able to reproduce this here either using the project you uploaded. Attached is the merged.hex file from my build. Please try it on your end and see whether it works or not.

Blinky  built with SDK v3.0.2 

2477.merged.hex

[varsha@]

Hello, 

I realized I had made a careless mistake—while testing sleep current earlier, I had disabled the COM ports in nRF Connect for Desktop. It only just occurred to me, and after enabling them again, everything is working properly now.

I'm sorry for taking up your time, and I truly appreciate your patience and support in helping me troubleshoot this.

Thank you.

[Vidar Berg]

Hi,

I'm glad to hear you found the problem, thank you for the update. I have made the same mistake of forgetting that I have disabled the COM port in the board configurator.