Bootloader start application at 0x1000 fails

[MassimoF]

I'm using an example project of the secure serial bootloader (pca10056_uart_debug) and changed some configuration for my custom board. I added RTT debugging and changed uart pins as well as hwfc. As application I'm using a already existing project, that is set up with the SDK16 and SD140. I compiled bootloader (with new key) and application seperate and generated the bootloader settings of the application. After merging everything together (SD140+APP+BL+Settings), I cross checked the address of SD,APP and BL with the NRFConnect app. Everything seems ok.  Then I cleaned and flashed the chip with nrfjprog. The bootloader wants to start the app at 0x1000 but the application does not start at this point.

Do I have to configure or change something in the Application Project settings or configuration setup of the Applicatoin? What could be the problem of hanging after initiating the app start?

For settings generation I use this command:

nrfutil settings generate --family NRF52840 --application testapp.hex --application-version 1 --bootloader-version 0 --bl-settings-version 2 --app-boot-validation NO_VALIDATION --key-file ../my_private_key.key settings.hex

For merging:

mergehex -m $(SD) $(TESTAPP) $(OUTPUT)/secure_bootloader_uart_mbr_custom_board.hex -o .temp_output1.hex
mergehex -m .temp_output1.hex settings.hex -o $(OUTPUT)/merge_out_SD_APP_BL_SETTINGS.hex

For flashing:

nrfjprog -f nrf52 --program $(OUTPUT)/merge_out_SD_APP_BL_SETTINGS.hex --sectorerase

The memory layout after merging all:

Here the output of the RTT debugging after resetting the chip.

[Vidar Berg]

Hello,

It looks like you are doing everything correctly. Could you try to run "nrfjprog --readregs" after flashing the device to see where it gets stuck?

Thanks,

Vidar

[MassimoF]

Hello Vidar,

this is the output of --readregs after the call of app start

[Vidar Berg]

Hello,

Thanks. So the PC is inside the application's address range, and last byte of xPSR (0x3) shows that the program is in the hardfault interrupt context. Have you tried to see if the program runs ok if you program just the MBR+app without the bootloader?

The only problem I can think of is if the app is not configured to start at address 0x1000 in flash or if it uses the the first 8 bytes of RAM which is reserved to the MBR (0x20000000 - 0x20000008)

[MassimoF]

Hello,

Thanks for the quick reply.

I'm using the mbr_blinky example and tried it with and without the bootloader. 

Without bootloader the example runs fine (blinky_mbr.hex + mbr.hex). Adding the bl + settings (settings of blinky_pca10056_mbr.hex) I'm having the same problem.

I checked the project settings of the blinky_mbr example:

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x1000;FLASH_SIZE=0xff000;RAM_START=0x20000008;RAM_SIZE=0x3fff8"
      
linker_section_placements_segments="FLASH RX 0x0 0x100000;RAM RWX 0x20000000 0x40000"

I don't know the difference of RAM_PH_START and RAM_START but I suppose that the example with mbr shuld be configured correctly?    

[Vidar Berg]

MassimoF said:

I suppose that the example with mbr shuld be configured correctly

 Yes, this should have worked. RAM_PH_* specifies the total RAM available on the chip, while RAM_* specifies the RAM address range to be used by the app. I'm suprised the same works if you don't program the bootloader.

Have you tried to debug the app to maybe see what triggers the fault?

Hardfault in blinky example:

[MassimoF]

When I start a debug sesstion with the blinky_mbr example I don't get any hardfault.

This is what the flash looks like after debugging.

The Project setup

blinky_pca10056_mbr.emProject.zip

[Vidar Berg]

This appears to be without the bootloader present. Are you able to debug the app with the bootloader present?

[MassimoF]

I added the bl.hex and settings.hex as load files and got the hardfault:

This is the entry point when debugging. From there it jumps directly in the hardfault:

[Vidar Berg]

I think we are getting close to a solution here. Are you compiling the bootloader without code optimization by any chance? In that case it's probably related to the bug I mentioned here: https://devzone.nordicsemi.com/f/nordic-q-a/62777/need-help-with-custom-dfu-bootloader-transferring-back-to-main-app