• State Verified Answer
  • Replies 2 replies
  • Subscribers 90 subscribers
  • Views 1256 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 243506
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Debugging via RTT in Segger Embedded Studio stops working after DFU

EAn

Hi all,

Debugging via RTT in Segger Embedded Studio stops working after DFU, however if I connect via JLinkExe + JLinkRTTClient I can still interact and debug via RTT... Any clue why that is?

I'm using SDK for Mesh 3.2.0 and nRF5 SDK 15.3.0.

Thank you!

Best Regards,

//EA

Parents
  • +1

    Hi,

    RTT uses a "SEGGER RTT Control Block" in RAM, for communication to/from the device. (It uses the standard J-Link connection to read/write RAM, and that is the way data is sent across the RTT channels.) For details, see the "How RTT Works" section on the SEGGER J-Link RTT technology web page.

    When you do a DFU update, the application before and after the DFU may use a different area of RAM for the RTT Control Block. If so, the RTT session will no longer work (because from the PC side the software reads and/or alters device RAM in the wrong location.) Reconnecting works, because when starting a new RTT session RAM is scanned over the J-Link connection for finding the location of the Control Block.

    There are a couple of ways to get around this:

    A) Open the RTT session with a predefined location for the RTT Control Block

    Start JLinkRTTViewer from the command line, with the --rttaddr option followed by the RAM address for the RTT Control Block. You can e.g. start two sessions, one for the old application and one for the new one. The location for the RTT control block can be read from the .map files. For the details, see the thread RTT viewer sometimes works, sometimes does not. No determinism?

    B) Use compiler specific directives to place the RTT Control Block at the same location for both apps.

    Syntax depends on toolchain. For examples, see the thread RTT logging from application started by bootloader.

    Note that there is a difference between DFU in nRF5 SDK and nRF5 SDK for Mesh. In nRF5 SDK the bootloader is like a separate application, so the RTT Control Block "synchronizing" must be done between bootloader and application. In the nRF5 SDK for Mesh case you need "synchronizing" between old application and new application. For both cases, make sure to use RAM addresses available to the application (e.g. not within SoftDevice RAM.)

    C) Use UART instead of RTT for logging.

    Regards,
    Terje

Reply
  • +1

    Hi,

    RTT uses a "SEGGER RTT Control Block" in RAM, for communication to/from the device. (It uses the standard J-Link connection to read/write RAM, and that is the way data is sent across the RTT channels.) For details, see the "How RTT Works" section on the SEGGER J-Link RTT technology web page.

    When you do a DFU update, the application before and after the DFU may use a different area of RAM for the RTT Control Block. If so, the RTT session will no longer work (because from the PC side the software reads and/or alters device RAM in the wrong location.) Reconnecting works, because when starting a new RTT session RAM is scanned over the J-Link connection for finding the location of the Control Block.

    There are a couple of ways to get around this:

    A) Open the RTT session with a predefined location for the RTT Control Block

    Start JLinkRTTViewer from the command line, with the --rttaddr option followed by the RAM address for the RTT Control Block. You can e.g. start two sessions, one for the old application and one for the new one. The location for the RTT control block can be read from the .map files. For the details, see the thread RTT viewer sometimes works, sometimes does not. No determinism?

    B) Use compiler specific directives to place the RTT Control Block at the same location for both apps.

    Syntax depends on toolchain. For examples, see the thread RTT logging from application started by bootloader.

    Note that there is a difference between DFU in nRF5 SDK and nRF5 SDK for Mesh. In nRF5 SDK the bootloader is like a separate application, so the RTT Control Block "synchronizing" must be done between bootloader and application. In the nRF5 SDK for Mesh case you need "synchronizing" between old application and new application. For both cases, make sure to use RAM addresses available to the application (e.g. not within SoftDevice RAM.)

    C) Use UART instead of RTT for logging.

    Regards,
    Terje

Children
Related
Terms of service