Attachments (0)
Nordic Case Info
  • Case ID: 341358
Options

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.

Parents
  • 0

    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.

  • 0 in reply to KBrK

    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

  • 0 in reply to KBrK

    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? 

  • 0 in reply to Vidar Berg

    yes, exactly

  • 0 in reply to KBrK

    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.

  • 0 in reply to KBrK

    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?

Reply
  • 0 in reply to KBrK

    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?

Children
  • 0 in reply to Vidar Berg

    No, the program has been working flawlessly when attaching to a J-Link probe. However I've not started the program through the J-Link probe but just opened the RTT within Visual Studio while the code was running independently. This however is not possible for the blackmagic probe as here you need to run the code manually from within the gdb interface if you want to access RTT.

  • 0 in reply to KBrK

    I see. I assume the issue is that the blackmagic client is halting the CPU while BLE is enabled. I'm afraid my best suggestion is to reach out to the vendor and ask about this.

  • 0 in reply to Vidar Berg

    Thank you for your assistance. I have contacted the makers of the BMP. Additionally I found out that the SIGSEGV only happens when "monitor rtt" is enabled for the BMP

  • +1 in reply to KBrK

    This is an issue with the blackmagic probe halting the CPU for reading the RTT messages. Depending on when somebody reads this, it might already be resolved in the stable firmware version of the BMP. Until then you can checkout pull request #2037 and take a look at this issue on github: https://github.com/blackmagic-debug/blackmagic/issues/2089 . Updating the firmware of the BMP resolved the issue for me completely.

Terms of service