NRF52840 - Problems merging and flashing secure_bootloader_uart_mbr_pca10056 and ble_app_uart_pca10056_s140

[tyrelkostyk]

Hello,

I am trying to program my NRF52840 chip with the Secure Bootloader UART project, in addition to the BLE App UART project as mentioned in the title. So far, having these two projects together works great - normal operation and DFU Upgrades (delivered over UART) work great. See below for details on what's failing.

I am using SDK 16.0.0 and SoftDevice S140 7.0.1.

I followed the Nordic guide that explained step by step how to add the Buttonless DFU procedure to the ble_app_uart project. Guide can be found here: https://www.u-blox.com/sites/default/files/Add-NordicSemiconductorDFU-to-SDKexample_AppNote_%28UBX-19050198%29.pdf

This worked, however for our specific project we didn't want DFU over BLE, but rather we wanted DFU over UART (delivered by another processor on our custom board). To achieve this, we are using the secure_bootloader_uart_mbr_pca10056 project in combination with the ble_app_uart_pca10056_s140. And so far, this works great for upgrading (as well as normal operation).

However, there is one small but important flaw that continues to ail our team: when using any nRF tool (like nrfjprog) or even any J-Link Flash tool, when we attempt to flash the final merged hex file (containing the bootloader, settings, soft device, and ble_app_uart) onto the NRF Peripheral chip, the chip only boots into the UART Bootloader. From here it can receive a DFU upgrade just fine, and then the app works fine afterwards as well. So we know that the bootloader works on its own, and that the ble_app_uart project works after an upgrade (since that's what we're upgrading to). BUT the only thing that doesn't appear to be working, is the merging and/or the flashing.And it's only an issue the first time it's programmed; once the peripheral receives an upgrade, it works fine. But this is concerning for us, as we don't want to require a DFU upgrade every time we prepare a device for production.

What is extra confusing is that this process of merging and flashing worked as expected when we did the buttonless DFU over BLE first (as described in the guide I linked above). We did not change any of the Flash or RAM addresses. We made a few small changes to the bootloader (SDK settings to enable certain DFU options, etc.), and these changes have been tested and they're working fine.

Any and all help would be appreciated! And I would be happy to offer more information as necessary.

Cheers,

Tyrel K

[tyrelkostyk]

I thought it might also be beneficial to demonstrate how I'm generating the merged hex files, and how I flash the nRF52840.

1. I generate the Bootloader Settings page (after compiling and gathering the necessary project hex files) using the nRF Util command line tool:

nrfutil settings generate
        --family NRF52840
        --application ble_app_uart_pca10056_s140.hex --application-version 0
        --bootloader-version 0 --bl-settings-version 2
        bl_setting_page.hex

2. I merge them all using the mergehex command line tool:

mergehex --merge
        secure_bootloader_uart_mbr_pca10056.hex
        bl_setting_page.hex
        s140_nrf52_7.0.1_softdevice.hex
        ble_app_uart_pca10056_s140.hex
        --output Full_App.hex

NOTE: the most recent version of the mergehex tool supports 4 simultaneous merge inputs (it used to only accept 3). I've tried this with the limit of 3 merge inputs, and I see the same behaviour.

3. I erase the existing flash on the nRF52840 chip using the nRFJPROG command line tool:

nrfjprog -f nrf52 --recover

NOTE: I've connected to the nRF52840 chip by using the BMD-340 EK as an inline JTAG Debugger, and I've also used a dedicated J-Link flash programmer. Same behaviour is seen with both tools.

4. And lastly, I write the fully merged app hex file to the nRF52840 chip:

nrfjprog --program Full_App.hex

At this point, I power-cycle the board (as required after Flashing the chip). It boots on, but only into the Bootloader. From there my secondary MCU can deliver a DFU over UART just fine, and then the main app works fine from then on. I'll mention again that the DFU Upgrade Package (firmware and init packet) is generated from the same build that is used in the above steps.

[Vidar Berg]

Hello,

Could you try to program the hex files separately instead merging them, or alternatively, make sure you are using mergehex.exe v10.11.1 or older? Reason I'm asking it that it seems like we may have introduced a rather unfortunate bug in the latest v1.12.x release that may cause the merged image to become slightly altered. The picture below is from I test I did where I compared the flash content after programming a merged hex to when the same FW image was programmed with separate hex files.

The checksum validation of the application  (Boot validation) will of course fail if this happens, and the bootloader will fall back to DFU mode as a result.

Thanks

Vidar

[tyrelkostyk]

Thank you Vidar! Simply downgrading to v10.11.1 resolved my issue.

[Vidar Berg]

Glad to hear that, thanks for confirming! I have already reported the bug internally, so it will hopefully be fixed soon.

[Farhang]

2 months later and 10.12.1 is still the latest on the nordic website.

I wish Nordic had at least put a warning on the webpage that this nrf Command line has a buggy mergehex and advise people to use 10.11.x instead.

It took me a while to figure out our new Firmware is failing because of this bug...

[Vidar Berg]

I'm sorry you had to waste time to track down this bug. I thought we would be able to release the fix for this bug much sooner, but it has already gone 2 months like you said, so we should obviously have taken some actions to inform customers of this problem in the meantime. I have forwarded your feedback internally. Thanks for the reminder.

[PXL]

Hi Vadir, any hope to get a corrected Mergehex in 2021 ?