• State Verified Answer
  • Replies 10 replies
  • Subscribers 74 subscribers
  • Views 1936 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272908
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

  • 0 in reply to ovrebekk

    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

  • 0 in reply to PriyeshN

    Hi Priyesh

    Very interesting, thanks for sharing your results. 

    Did you try to compare the resulting hex files you got from mergehex and srec_cat.exe respectively, to see if there are any big differences?

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hi Torbjørn,

    I do see some differences between two hex files, 10 hex records to be exact. Rest file matches entirely. The records are distributed throughout and not contiguous and neither bunched at the file boundary.

    Regards,

    Priyesh

Reply Children
Related
Terms of service