nRF52840 with SDK v17 - Application CRC check in secure bootloader always fails

[PriyeshN]

Hi,

My dev environment is as follows:

nrf52840 + s140 +SD7.0.1 + SDK17.0.0.9 + SES + nrfutil v6.1.0

I started my development for DFU and utilized secure buttonless DFU bootloader provided along with SDK. Things worked well. I also wrote a post build script which generated the bootloader settings hex file and then it merged all the 4 hex files viz application+soft device+bootloader+bootloader settings into one hex file for production usage. This all worked well in both debug as well as release configuration until I tried to further optimize the "Release" configuration.

For optimization, I configured the release configuration to:

- strip the debug information with gcc debug level set to none

- used app_config.h file to stop the nrf, and RTT logs

After this, the bootloader CRC check for application always fails and thus bootloader always enters into dfu. I have confirmed this with whatever possible bootloader debugging. Even after reverting the project configuration settings, I'm not able to get the bootloader calculate the CRC which is written into bootloader_settings. I have also checked that the start address and size passed to compute the CRC in bootloader is correct but still it does not match the CRC calculated by nrfutil.

Although I have very minor changes in my bootloader (compared to the one in SDK), but, I do have seen the same behavior with raw bootloader provided along with SDK. 

Can someone please help me on this?

Thanks

[ovrebekk]

Hi Priyesh

I assume you did the same exercise of merging the hex files after you optimized the release configuration?

Have you tried to compare the two hex files and see if there are any big differences?

Based on your comments I believe the only result should be that the application part is smaller, since there is no debug information and log functionality, or are there other changes?

Best regards
Torbjørn

[PriyeshN]

Hi Torbjørn,

Thanks for looking into this.

Yes, your expectation is correct. I did compare the two hex files and the application hex is smaller as the debug information is stripped.

I have an update for you on this. I was working on this yesterday and I tried by flashing all the 4 hex files separately (I prefer Jflash-lite) and surprisingly, it worked. :) 

As my curiosity increased, I then doubted the mergehex utility. So, I went ahead and tried the ARM suggested srec_cat.exe utility to merge the hex files, and yes, this is also working.

I have updated my post-script files to use srec_cat utility for now, but, still don't know why there is such behavior.

Regards,

Priyesh

[ovrebekk]

Hi Priyesh

My bad, talking to one of the DFU experts I realized mergehex is not supposed to be used for DFU purposes. 

Instead you should use the nrfutil tool. 

mergehex is only intended for use with nrfjprog, to allow you to program both application and SoftDevice in a single operation. 

Best regards
Torbjørn

[PriyeshN]

Hi Torbjørn,

I was in impression that mergehex got installed along with nrfutil as I never explicitly installed/used mergehex. Also, I followed the instructions on Nordic page for the usage of mergehex for merging the hex files:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h61sjziauupw1j397q9s9ldr01q4j6d5

Appendix - Bullet 1 - "Combine application, bootloader and softdevice image - Bootloader setting"

On the link you shared for nrfutil, I don't see any help for merging the hex using nrfutil. Can you please help me in merging hex using nrfutill.

Thanks,

Regards,

Priyesh

[Hung Bui]

Hi Priyesh, 

I assume you only use mergehex for programming the device via SWD (programmer) interface not for generating the .zip file to do DFU ? 
There is a chance that it's an issue with the mergehex file. Please have a look at this case: https://devzone.nordicsemi.com/f/nordic-q-a/69987/latest-mergehex-output-fails-to-be-programmed-mergehex-9-8-1-produces-different-hex-than-10-12-1
You may need to use older version of mergehex. 

[PriyeshN]

Hi Hung,

I use the mergehex to merge different hex files only and not to generate DFU package. DFU package is generated using nrfutil.

Regards,

Priyesh

[Hung Bui]

Please try to test with older version of mergehex as suggested by Vidar. 
The flash dump after you flash 4 files separatedly and the flash dump after you flashed the merged hex file should be the same. 

[PriyeshN]

Thanks Hung,

I tried with 10.11.1 version of mergehex and now it works. Although, the read file (from nrfConnect programmer) and the merged hex still do not match (too many differences), but the functionality is working i.e. CRC check in bootloader is passing and code flow is now starting the application.

I agree with the comments from other members Farhang & droberson on below post: 

https://devzone.nordicsemi.com/f/nordic-q-a/69940/nrf52840---problems-merging-and-flashing-secure_bootloader_uart_mbr_pca10056-and-ble_app_uart_pca10056_s140/286885

to have a warning flag against the new mergehex versions. Or a better suggestion would be to either  resolve the bug and update mergehex or simply remove the buggy files from release section. This is simply wasting time of developers analyzing, debugging the issue before they post here as last retort.

Convey my thanks to Vidar Berg