buttonless DFU issue loading with jlink

[Belenie]

Hello,

we are using the nRF52840-DK.

 

File: secure_bootloader_ble_s140_pca10056.emProject

File: ble_app_buttonless_dfu_pca10056_s140.emProject

 

In short, we are noticing when uploading through SES with Jlink, the uicr_bootloader_start_address 0xff8 memory location is being modified to be all "F". The Bootloader example works in the case when the bootloader_example.zip is uploaded using the DFU.

Overview:

File: secure_bootloader_ble_s140_pca10056.emProject

File: ble_app_buttonless_dfu_pca10056_s140.emProject

Board: nRF52840-DK

Intent: Add buttonless dfu feature to our existing ble project.

Issue 1: Buttonless example is successful when uploading the package.zip using the DFU. When uploading Buttonless example with J-Link through SES, we get an err_code = 4, resulting in NRF_BREAKPOINT_COND.

When uploading with SES/J-Link the 0x1000 (4096) page is being written to and this is causing the uicr_bootloader_start_address @ 0xff8 location to be erased, and is reading 0xffff-ffff. We are expecting the uicr_bootloader_start_address @ 0xff8 to be 0xF8000.

I believe the reason the DFU transfer of the buttonless example works, is because the bootloader is protecting the flash from being overwritten (Line 32 of secure bootloader main.c). While the SES upload is not protecting that space.

Question: Why is the project writing to 0x0 – 0xfff?

Modifications made to our application: We have an existing BLE application we are developing, and are adding the buttonless dfu feature to our application. I will list the settings I have modified in my attempt to get the buttonless dfu feature working on our application.

After making these changes our application does not work with both upload methods, SES/J-Link or, DFU. The 0xff8 memory issue described above is also seen with our application.

• Modified main.c to include buttonless features
• Include several SDK files into the project
  • nRF_DFU folder
    • c
    • c
    • c
  • nRF_SVC folder
    • c
  • Add user include directories
    • ../nRF5-SDK/components/libraries/bootloader/ble_dfu
    • ../nRF5-SDK/components/libraries/bootloader/dfu
    • ../nRF5-SDK/components/libraries/bootloader
    • ../nRF5-SDK/components/libraries/svc
  • Add Preprocessor Defines Code>>Preprocessor>>Preprocessor Definitions (Common)
    • BL_SETTINGS_ACCESS_ONLY
    • NRF_DFU_SVCI_ENABLED
    • NRF_DFU_TRANSPORT_BLE=1
  • Modified sdk_config.h
    • Note: These were the only defines different in our app vs the buttonles example. These are the values I kept in our app.
    • BLE_DFU_ENABLED 1
    • NRF_PWR_MGMT_CONFIG_AUTO_SHUTDOWN_RETRY 1
    • NRF_LOG_BACKEND_RTT_ENABLED 1
  • xml
    • added "uicr_bootloader_start_address" section
  • Added bootloader address to Build>>Memory Segments (Common)
    • "uicr_bootloader_start_address RX 0x00000FF8 0x4"
      

Buttonless_DFU_helpful memory map.docx

[Turbo J]

Belenie said:

Question: Why is the project writing to 0x0 – 0xfff?

Because these are documented locations for bootloader address. I think you are supposed to write to the MBR page without a page erase, but have no idea how to tell SES to do that.

Fixed this problem by changing these addresses in the linker script to the alterative UICR addresses (NRFFW[0] and NRFFW[1] in UICR).

For LD this looks like:

 uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
 uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4

[Belenie]

I will say It is not clear to me what is being written to the MBR page when the app is being loaded. I am under the impression that I do not want to be writing anything to the MBR page while flashing the app.

 

Is the application, or softdevice writting to the MBR?

 

Why would I want to change the addresses to the alternative UICR addressed, instead of removing the writing happening to the MBR page? it seems that the writing should not be happening?

[BEplane]

Thank you Belenie for posting this for me, I was having difficulty posting and have since figured out a solution to posting.

I have created a post, which makes this post a duplicate. My post with updated information can be found,

https://devzone.nordicsemi.com/f/nordic-q-a/53531/nrf52840-ble-buttonless-dfu-sdk-15-3-0-example-memory-issue

Thank you,

[Vidar Berg]

The MBR data is included in the bootloader image and can easily get overwritten if you, for instance, flash the Softdevice after programming the bootloader. This is an unfortunate limitation in  SDK 15.3.0. But it is fixed in the SDK 16.0.0. From the release notes:

-Bootloader start address is now placed in UICR at compile time, and the MBR page is
populated at runtime. This is to mitigate problems with flashing
where the MBR was erased.

The SES projects will load the Softdevice hex along with the project by default. So this is probably why the data gets overwritten in this case. I suggest removing the Softdevice load option for the application project. That should fix the problem.