Can't get bootloader to log

RE: Can't get bootloader to log

Thomas — Sun, 12 Mar 2017 05:57:03 GMT

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.

RE: Can't get bootloader to log

Lee Daniel Crocker — Mon, 13 Feb 2017 18:40:55 GMT

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

RE: Can't get bootloader to log

Hung Bui — Mon, 13 Feb 2017 08:45:20 GMT

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.

RE: Can't get bootloader to log

Lee Daniel Crocker — Sat, 11 Feb 2017 00:05:22 GMT

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.

RE: Can't get bootloader to log

Lee Daniel Crocker — Fri, 10 Feb 2017 23:04:38 GMT

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

RE: Can't get bootloader to log

Hung Bui — Fri, 10 Feb 2017 09:59:07 GMT

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.

RE: Can't get bootloader to log

Lee Daniel Crocker — Thu, 09 Feb 2017 18:05:32 GMT

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?

RE: Can't get bootloader to log

Lee Daniel Crocker — Thu, 09 Feb 2017 18:03:23 GMT

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".

RE: Can't get bootloader to log

Hung Bui — Thu, 09 Feb 2017 12:05:11 GMT

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.