RTT with Black Magic Probe doesn't work when using mcuboot

[KBrK]

I'm using an nrf52840 on a custom board and send debug messages with printk to RTT. When mcuboot is added to the firmware it is no longer possible to read the messages from RTT with a black magic probe. Before this was possible. RTT itself is not broken as the messages still can be read with a JLINK device. Has anybody have had any experience with using RTT and a black magic probe and has anyone managed to get it to work while using mcuboot.

[KBrK]

Update: RTT with the blackmagic probe works, as long as you're not connecting via Bluetooth LE. If I connect then I get a "Program received signal SIGSEGV, Segmentation fault." Using BLE while reading RTT with a JLink device works.

[Vidar Berg]

Hello, 

I'm not familiar with this debug probe (have heard about it but not used it), but logging over RTT should be non-intrusive and not affect how the program runs. Are you attaching the debugger and starting the RTT session before you establish the BLE connection?

Best regards,

Vidar

[KBrK]

Yes, I'm attaching the debugger and starting the program through the debugger (arm-none-eabi-gdb -ex "target extended-remote /dev/ttyACM0" -ex "monitor swd_scan" -ex "attach 1") and (run) and open the minicom in a 2nd terminal window. The printk messages get sent as long as no ble device is connected, once you try to connect the program crashes with SIGSEGV as described above. Without RTT printk messages the program continues to run even when you connect via Bluetooth. Connecting via Bluetooth also causes no issues when the program is not started via the debugger but by simply resetting the device.

[Vidar Berg]

Is it the GDB client that crashes with SIGSEV? Either way, maybe you could post a screenshot to show what you see when it crashes? 

[KBrK]

yes, exactly

[Vidar Berg]

It shows that a fault has been raised on the nrf target, not in the GDB client. But you have not loaded the debug symbols. Use 'file' command in gdb to load the symbols table from the *.elf file. Then, run backtrace and info registers to see if we can get more information about the crash.

[KBrK]

[Vidar Berg]

The stack trace shows that an assert was raised by the bluetooth controller. This can happen if the debugger halts the CPU and then allows execution to continue afterward as the controller will detect when it has failed to meet its real-time requirements. Do you see this assert if you attach a J-link probe instead?