Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unknown hangs with secure bootloader without debug

Hello,

This is a strange problem and I do hope I am missing something. There are two bootloaders in the examples/dfu section for a particular transport - with debug and without debug. Making my own custom build of the bootloader for the project (private key, buttonless, no uart, etc), I stumbled upon an unexplainable for me problem: The same bootloader, with the same code works properly when the debug information is included and hangs silently when not.

Things that are different between the two:

sdk_config.h:

-----------------

A few nuts and bolts concerning RTT logging configuration (same as in the example code provided) and LOG_LEVEL settings.

.emProject:

---------------

The one without debug omits a pair of the debug related macros - DEBUG_NRF and NRF_DFU_DEBUG_VERSION

Flash placement differs: The one with debug takes flash from x71000, the one without debug from x78000 (as in examples), RAM placement is the same for both.

Flash sections order is a tiny bit different, but that doesn't look like critical problem, there is no 4x4 overlaps in the final image and Programmer verifies it as correct.

Everything else, as far I managed to check, is the same. What am I missing?

Does anybody else meet with this situation?

Parents
  • Hi Alexander, 

    Could you give some more information about when the bootloader hang ? Was it hang right when booting ? or when you were doing DFU ? 

    Please try to turn on some log. 

    You can also move the non-debug version of the bootloader to address 0x71000 and then change the optimization level to 0 . This way you can step into the code and check where it stuck. 
    Have you tried to test the stock bootloader with no modification ? 

  • I verified, replacing debug bootloader with no debug one doesn't work. Probably, I've seen somewhere something like the size of the bootloader doesn't change during the lifecycle of the application, so I guess its position in flash too.

  • Hi Alexander,

    Could you check which version of mergehex you have ? 
    We had an issue with v10.12.1 , you can have a look here: https://devzone.nordicsemi.com/f/nordic-q-a/75729/possible-mergehex-issue-v10-12-1

    Note that when you switch between the bootloader hex files, especially those with different start addresses in flash, you should do an nrfjprog --eraseall. The reason is that the start address of the bootloader is written in the UICR (and the MBR area) so it's required if you want to change the start address of the bootloader. 

    Could you confirm that by using the nRF Connect programmer (or nrfjprog ) and flash the hex files separately instead of mergehex it works for you ? both the debug version and non debug version ? 

  • Hello Hung,

    The bug with mergehex was the one, as I wrote above :) and I tested it as soon as 10.12.2 came out, on saturday morning - It works ok, the gap mishandling and alignment issue was fixed in 10.12.2. I was just waiting for your notification to confirm. One of the misfortunes of that bug was damaging the boundary areas between text and rodata, and between rodata and application sections (and THAT is where all the observers addresses are collected!).

    As for the changing of bootloaders with different start address - yes, thank you, I just forgot about the MBR/UICR bootloader start address thing :) Of course, you can't (safely) change these things on the fly, you must stick to one address and I do remember that it was written somewhere in the docs, but that warning was a bit vague, as it was talking about sizes, not addresses.

Reply
  • Hello Hung,

    The bug with mergehex was the one, as I wrote above :) and I tested it as soon as 10.12.2 came out, on saturday morning - It works ok, the gap mishandling and alignment issue was fixed in 10.12.2. I was just waiting for your notification to confirm. One of the misfortunes of that bug was damaging the boundary areas between text and rodata, and between rodata and application sections (and THAT is where all the observers addresses are collected!).

    As for the changing of bootloaders with different start address - yes, thank you, I just forgot about the MBR/UICR bootloader start address thing :) Of course, you can't (safely) change these things on the fly, you must stick to one address and I do remember that it was written somewhere in the docs, but that warning was a bit vague, as it was talking about sizes, not addresses.

Children
No Data
Related