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.

[Marte Myrvold]

Hi,

In the nRF Connect SDK, we use SMP to transfer DFU images, so the device transmitting the image must act as an SMP client. I have not tried using TeraTerm for this, so I am not sure if it is possible to get it to work as an SMP client. We recommend using AuTerm when doing DFU from a computer.

A colleague has made an example showing how to do DFU from one nRF52840 DK to another using SMP client and server. These examples were last tested in nRF Connect SDK v2.2.0, so they are outdated, but they can be useful as a starting point. The 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. You can find it here: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/v2.2.0/bootloader_samples/client_smp/smp_client_uart.

As for the timeout error, did you follow the DevAcademy exercise when implementing DFU over UART? If not, I recommend doing so, as this has been tested and should work. If everything is correct in your application, it could be that you have not disabled virtual mass storage, which might interfere with DFU. The baud rate and other settings in AuTerm look correct in your image. The nRF54L15 has two COM ports. Have you tried both?

Best regards,
Marte

[varsha@]

Hello,

Im sorry for the late reply. 

I have tried on different Baudrates (115200 and 9600) and on both the COM Ports available. And yes, I also disabled the virtual mass storage.

I am getting the same Timeout error. I am attaching the code which I tried on the DK.

 1452.blinky.zip

[varsha@]

Hello, 

I tried to use mcumgr as well for DFU over UART. I am getting an error of NMP Timeout. I disabled the virtual Mass storage also.  

 

Where must I be going Wrong?

Thankyou.

[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)