Can't get bootloader to log

[Lee Daniel Crocker]

Using SDK 12.2, I have compiled the secure bootloader successfully, tweaking the sdk_config and Makefile to use RTT for logging and turning on logging, and using the "_debug" linker script to place it at 0x75000. I used nrfutil to make a bootconfig.hex. I installed the bootloader, config, softdevice, and my app. Using JLinkExe, I can see all of them: SD at 0x0, my app at 0x1f000, bootloader at 0x75000 and config at 0x7f000.

When I boot the pca10040, LED3 comes on and stays on, but nothing is seen on the RTT console, I can't see the device advertising, and it appears hung. If I hold down button 4 while booting, LEDs 1 and 3 stay on, but still appears hung. Nothing ever shows on the RTT console.

It's hard to debug this if I can't see what's happening. Is there some reason the bootloader can't use RTT logging? Am I missing a step (for example, how does it know to look at 0x75000 instead of 0x78000)?

[Hung Bui]

Hi,

You need to test and check if you can actually move the bootloader to 0x75000 before testing with RTT.

To enable RTT logging, you need to update the sdk_config.h to set NRF_LOG_ENABLED = 1 and set NRF_LOG_BACKEND_SERIAL_USES_RTT = 1. You can try to disable optimization to O0 and can debug as normal application.

[Lee Daniel Crocker]

Not sure what you mean by "move" the bootloader. It's compiled for 0x75000 and loaded there, and UICR has that address at 0x10001014, and "0x7E000" at 0x10001018. As I aid in the question, I've verified that the code is indeed there.

I had those sdk_config settings as well as the ones for things like buffer size, all copied from other example projects using RTT.

I didn't have -O0 because the Makefile supplied with the SDK uses -Os, which compiles fine. When I change it to -O0, the first thing that happens is that it complains about nrf_bootloader_app_start.c having an assembly function that uses R7. Tweaking the Makefile to add -fomit-frame-pointer to the compile line for that file fixes that, but causes the program to grow too large even to fit at 0x75000, as well as causing a link error with "nrf_drv_rng_block_rand".

[Lee Daniel Crocker]

Update: though I never got -O0 to work, fixing the Makefile to add -fomit-frame_pointer to the compilation of nrf_bootloader_app_start.c seems to have done something. I now get stuff on the RTT console when I enter an "r" command to JLink, but not when I power the board on by itself.

It prints:

:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:In real nrf_dfu_init
:INFO:running nrf_dfu_settings_init
:INFO:Enter nrf_dfu_continue
:INFO:Valid App
:INFO:Enter nrf_dfu_app_is_valid
:INFO:Return true. App was valid
:INFO:Enter nrf_dfu_app_is_valid
:INFO:Return true. App was valid
:INFO:Jumping to: 0x0001f000
:INFO:Running nrf_bootloader_app_start with address: 0x0001f000
:INFO:Disabling interrupts
:INFO:Setting SD vector table base: 0x0001f000

Not sure what's supposed to happen after that. Holding down button 4 while doing an r/g does nothing (two LEDs on, no RTT).

So now the question is, how did it ever compile with the SDK's included Makefile? And why is not running on power cycle?

[Hung Bui]

Hi Lee, When I mean "move" meanting instead of 0x78000, it is flashed at 0x75000 and the PC start from there (The MBR check 0x10001014 in UICR and forward the PC there).

My suggestion is:

• Test the stock bootloader example, make sure it works at address 0x78000 (don't enable RTT or anything). Try to DFU update an application.

• Change the address to 0x75000 and check if it still work.

• Don't change to O0, keep it as Os first, and enable RTT and check if it works. Don't copy the whole sdk_config.h from other project, only modify it to enable what you want.

• If you want to remove optimization, use O0 and "move" the bootloader to something lower to get more space, for example 0x73000.

• About your last question, the log showed that the application started, the bootloader is finished, that's why you see nothing after that.

[Lee Daniel Crocker]

Getting closer. It occurred to me that RTT only exists when I'm plugged into JLink, so I reverted back to UART logging, which works from powerup. Now when the bootloader is in two-leds-lit mode, it shows up as "DfuTarg" to the toolkit app. Unfortunately, when I try to upload one of the sample ZIPs like dfu_test_app_hrm_s132.zip, the app stops with "DFU SERVICE NOT FOUND". The bootloader's log ends with:

:INFO:Waiting for events