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)?

[Lee Daniel Crocker]

Odd results now. To go back to basics I burned the pre-compiled secure_dfu_secure_dfu_ble_s132_pca10040_debug.hex from the SDK. I was able to upload the sample ZIP from a Nexus tablet and a Samsung tablet. But it failed trying from a Motorola phone and an iPad. So maybe it's the mobile app side that's my problem.

[Hung Bui]

Segger RTT use SWD interface to send logging data out, so you need to connect to Jlink to be able to get RTT debugging.

"DFU SERVICE NOT FOUND" usually happens when the phone caches the attribute table and fails to do service discovery to update the new table (when we switch to DFU bootloader), you can try to turn off and on Bluetooth on the phone, and try to use nRFConnect to connect and do DFU, instead of nRFToolbox (in nRFConnect we erase the cached att table)

Make sure you set IS_SRVC_CHANGED_CHARACT_PRESENT = 1 in your normal application, so the phone would know that you may change the ATT table.

[Lee Daniel Crocker]

Yep, nRFConnect worked beautifully. Guess I know which code to use/steal/be inspired by now. Thanks for the help.

[Thomas]

Hey Lee Daniel, After demining our way through (we use the pca10040_debug version so that we don't have to bother with most other issues) we ended up a similar situation. We checked that the app is really at the address it should be at (0x0001f000) and we get the same cryptic messages. Is it hang? is it locked in? is something else that's supposed to be there or not there? We successfully uploaded our app but as the bootloader then tries to switch to that app (instead of starting a BLE service waiting for a firmware update) we find ourselves in this deadend. Lee Daniel, if you were able to figure this out, could you share your workaround/solution? that would be tremendously helpful.