• State Not Answered
  • Replies 2 replies
  • Subscribers 87 subscribers
  • Views 849 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 277876
Options

nRF52832 unexpected memory layout after dfu OTA update

GDM

Hi,

Using the Nordic secure bootloader for dfu OTA update, I am facing an issue causing the system to go under a condition where the bootloader is not any longer able to launch the application after performing the update over ble. 

When this scenario occurs reading back the flash memory with nRFConnect, I find that the flash memory layout has an unexpected region  between the two main application blocks as depicted in the figure below 

  

Moreover I noticed that, after connecting with jlink and reading back the flash memory, the system resets and the then application is properly started. 

Is there any condition in the bootloader operation that could generate this layout of the application region affecting the application launch?

Any support shall be appreciated.

Parents
  • 0

    Hi,

    Looking at the image and description I assume we are looking at a flash dump where you use dual slot and the upper half of the application region is where the new image is temporarily stored. The nRF Connect Programmer can be a bit misleading when it shows the flash content graphically, so it may be better to analyze this by reading out the entire  flash content and looking at it. It is not really possible to say from the image what is what.

    When you write that the system resets and the application is properly started, does it then start the new application (so that it is activated/copied in place before starting), or is it the old application that is started? It would be interesting if you can reproduce the issue(s) you are seeing with the debug bootloader (example project´s suffixed with "_debug"). That has extensive RTT logging and often gives a good indication about the cause when debugging bootloader issues.

Reply
  • 0

    Hi,

    Looking at the image and description I assume we are looking at a flash dump where you use dual slot and the upper half of the application region is where the new image is temporarily stored. The nRF Connect Programmer can be a bit misleading when it shows the flash content graphically, so it may be better to analyze this by reading out the entire  flash content and looking at it. It is not really possible to say from the image what is what.

    When you write that the system resets and the application is properly started, does it then start the new application (so that it is activated/copied in place before starting), or is it the old application that is started? It would be interesting if you can reproduce the issue(s) you are seeing with the debug bootloader (example project´s suffixed with "_debug"). That has extensive RTT logging and often gives a good indication about the cause when debugging bootloader issues.

Children
  • 0 in reply to Einar Thorsrud

    Hi Einar,

    Sorry for the delay of my response. The image refers to a dual slot scheme.

    After further analysis, I found out that the memory layout subsequent to the firmware update seems not related to the actual issue affecting the application launch.

    According to your suggestione, I switched to the bootloader with RTT debug enabled. A soon as possible I will be back with more details from the bootloader log.

    Thanx for your support.

    Giuseppe

Related
Terms of service