This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RTT viewer sometimes works, sometimes does not. No determinism?

I am using RTT to debug my application and it's fine when it's working. The problem is that it seems to be flaky as hell. Sometimes it just stops working without any apparent reason, I can't see a single print in the SEGGER J-Link RTT Viewer.

By testing random combinations of reseting the target, power cycling it, reprogramming the firmware etc the RTT sometimes starts working again. Whenever I do small change in my app and need to reprogram the fw, there is about 50/50 chance that the RTT will go mute. 

This makes development and debugging really, really painful. Does anybody have any tips how to make sure that RTT is not screwed? Is there some known order how things need to be started to make it more stable?

My J-Link RTT Viewer is version V5.12f. Sometimes hitting F2 / F3 to connect / disconnect repeatedly seems to help, but currently I can't get anything out of the RTT no matter what I try.

I have also tried debugging in Segger Embedded Studio (V4.18). Debugging and flashing seems to work quite OK, so I don't think there's anything wrong in my debugger connection. The cabling and J-Link drivers etc should be ok (I'm working with a custom board based on nRF52832).

There does not seem to be any usable RTT viewer integrated into SES. If you open J-Link Control Panel inside SES then there is the RTT tab that seems completely useless. See screenshot below:

 

The RTT viewer in SES has a tiny textbox that can barely fit one line of text. And it cannot be resized?! Seems like completely useless tool for any real work.

I hope I am just missing some trick in my build/program/debug cycle that is preventing the RTT to work properly. The error should not be in the firmware itself, because sometimes the RTT prints are working and sometimes not. 

Any help appreciated!

Parents
  • More oddities noticed during testing:  I have RTT debug prints used in both the bootloader and the main application. 

    If I don't install any bootloader but just launch the app from SES and run it in debug mode, then RTT prints work just fine.

    When I program the nRF52 with bootloader, softdevice and application image and let it run, then RTT is working only partially: I can see the debug prints from the bootloader, up until to the point where the execution jumps from bootloader to main application. However, after the jump to main app I can't see a single RTT debug print anymore. Otherwise the app is running OK, because I can see it advertising and I can connect to the device with my phone etc.

    Is there some known issues related to RTT prints and jumping from bootloader to main app?

  • The issue of RTT debug prints not being visible after jumping from bootloader to main seems to match quite well this old thread:
    https://devzone.nordicsemi.com/f/nordic-q-a/20708/rtt-logging-from-application-started-by-bootloader

    It is quite likely that the RAM area used for RTT prints is different between my bootloader and application. Need to try fix that and see if it helps. 

  • After doing some detective work on my own, I've confirmed that the RTT configurations are indeed different between my bootloader and application. This explains at least part of the flaky behavior that I was complaining about. 

    By checking the *.map output files of bootloader and app, and looking for _SEGGER_RTT I now know that the RTT control blocks are located at addresses 0x200034e4  and 0x20008c60 (bootloader / app, respectively).

    When I open a RTT terminal in Segger RTT Viewer, the default option is to automatically detect the RTT control block. I guess there's some search of know magic pattern in RAM or something like that.

    Now if I choose to enter the RTT control block address manually, I can select whether I want to be listening for RTT prints from bootloader or application. (When opening RTT terminal, I enter one of the RAM locations listed above, depending on which I am interested in).

    This is much better than what I started with, because now there's clearly some explanation why the RTT prints sometimes work and sometimes don't.

    The RTT viewer seems to support multiple terminals. Ideally, I would like to configure it so that I open two terminals and enter the RTT control block location manually. First terminal would be for bootloader messages and second terminal for application output. I tried to set this up, but for some reason only one RTT "channel" is working at the time. I can either get bootloader or application messages, but not both.

    Has anybody had luck in configuring the RTT Viewer like described above? 

    If the RTT viewer can't do what I described, then the next options would be to align the RTT control block RAM addresses so that it is placed in same location for bootloader and app. I assume that the up/down buffers need to be at same location and same size, too?

    I think I've solved at least part of the mystery on my own, but any tips from experienced RTT users are more than welcome.

  • Sharing a tip that other users may find useful: 

    when starting Segger RTT Viewer, you can use command line options to e.g. specify the RTT control block location explicitly. The command line options are covered in the Segger manual, see:
    https://www.segger.com/downloads/jlink/UM08001

    (3.7.7 Command line options)

    In my case, I can now launch the RTT viewer to look for the bootloader or application prints using following commands:

    // for app prints:
    JLinkRTTViewer.exe -d NRF52832_XXAA -if swd -ra 0x20008c60 -a
    
    // for bootloader prints:
    JLinkRTTViewer.exe -d NRF52832_XXAA -if swd -ra 0x200034e4 -a
    

    This is handy because the pop-up dialog that you normally see when launching RTT Viewer can be bypassed. The last option -a means "auto connect", i.e. connect directly to target using the given settings and do not show the dialog.

    By explicitly defining the RTT contol block address, the RTT prints seem to be now working reliably in my setup, therefore setting this comment as answer to the problem.

Reply
  • Sharing a tip that other users may find useful: 

    when starting Segger RTT Viewer, you can use command line options to e.g. specify the RTT control block location explicitly. The command line options are covered in the Segger manual, see:
    https://www.segger.com/downloads/jlink/UM08001

    (3.7.7 Command line options)

    In my case, I can now launch the RTT viewer to look for the bootloader or application prints using following commands:

    // for app prints:
    JLinkRTTViewer.exe -d NRF52832_XXAA -if swd -ra 0x20008c60 -a
    
    // for bootloader prints:
    JLinkRTTViewer.exe -d NRF52832_XXAA -if swd -ra 0x200034e4 -a
    

    This is handy because the pop-up dialog that you normally see when launching RTT Viewer can be bypassed. The last option -a means "auto connect", i.e. connect directly to target using the given settings and do not show the dialog.

    By explicitly defining the RTT contol block address, the RTT prints seem to be now working reliably in my setup, therefore setting this comment as answer to the problem.

Children
No Data
Related