Hello,

I'm having an issue with the JLink not being able to automatically detect the RTT control block.

If I set an exact control block address in J-Link RTT Viewer, the control block is located and RTT log output is as expected. If I set a search range which includes the known RTT control block address, the RTT control block is not found. Similarly, automatic detection does not locate the control block.

My setup is as follows:
Device: STM32F746IG. Linker specifies internal RAM @ 0x20000000, length 320K
JLink tool version v6.94, JLink Plus probe
Windows 10 Host

SEGGER_RTT_Conf.h is configured to place the control block and RTT buffers in a linker section named .segger_rtt. Using a linker script, this section has been placed at a fixed known location in RAM with the RTT control block located at 0x2004ef78.
Entering 0x2004ef78 as the RTT control block address in RTT viewer results in immediate RTT location and RTT log output.
If using a manual search range of '0x2004EF00 0x100' instead of manually specifying an exact location, the RTT control block is not found. Same result for automatic detection. When viewing the RTT search status at localhost:19080/rtt.hml, the Status shows 'Looking for RTT CB @ 0x2004EF00 (Range 1/1)' indicating that the search range has been received, but RTT control block is not found.

My preference is to support auto detection to make it easier for our testers. Do you why this is not working and other things to try?

Answers to the following questions may also assist debugging:

• Are there any alignment requirements for the RTT control block? e.g. Does the 'SEGGER RTT' signature need to be located on a 16 byte boundary, 4 byte etc? (I have tried various alignment with no success).
  
• Do you publish standard RTT search ranges for each processor or have a method to find out this information?
  
• If specifying an exact RTT control block address, does the JLink still attempt to validate the RTT control block signature and report an error if the control block isn't found?
  
• Does the JLink perform a linear search through all addresses in the configured search ranges, or is only a partial search executed?
  
• When checking the control block, does the JLink perform further validation of control block contents in addition to the signature? e.g. Does the Jlink validate that the buffer addresses are also located in RAM?
  

Thank you
Austin

Hi Fabian,

Thank you for your response. Your sample hex file works correctly on my hardware with the RTT viewer automatically detecting the control block and outputting 'Hello World xx!' with incrementing xx.

With my original application programmed, I turned on the J-Link log file and captured an unsuccessful RTT attempt with auto-detection enabled, log is attached. The log includes a connection using auto detection (fail) and then connection using specified address (pass). A side issue I found was that with the Override setting enabled, I was no longer able to successfully load the localhost:19080/ page in a browser while I had the RTT viewer connected (this is likely a different issue).

I've created a sample test application which has been cut down from my main application and exhibits the same behavior (attached). To test this application:

1. Erase chip
   
2. Program app-boot-trampoline.hex (This is a simple trampoline bootloader which jumps to the main app programmed in the next step at a higher address in flash)
   
3. Program main.hex
   
4. Use RTT Viewer to connect and view logs which should output incrementing '0' - '9' characters. RTT viewer only outputs logged text if entering 0x2004ef78 as RTT control block address.
   

The SEGGER_RTT_Conf.h has been modified from stock (I didn't check, but SEGGER_RTT.c may also have been modified from stock sources in my project).

Hopefully the example will assist in debugging this issue. I'm also interested in the answers to the other questions I posed if possible as it may be useful information to assist debugging in the future.

Thank you
Austin

Hi Fabian,

Just following up to see if you have made any progress on this issue?

Given that the issue is reproducible, would you prefer I track this as a separate support ticket via segger.com/support/technical-support/?

Thank you
Austin

Hi Fabian,

Thank you for looking into this. Yes, the suggested change to ensure the full 24 byte ID string is valid in the RTT control block fixes my issue. It does seem a bit strange to me that manual specification of the control block doesn't appear to check for the full ID string as does the automatic and search range options.

I have some notes/suggestions for you to consider related to RTT improvements:

• The information at wiki.segger.com/RTT#Memory_footprint could be updated to note the exact expected control block ID layout, including use of expected 0x0 values in the ID array.
  
• As of v6.94, SEGGER_RTT.c does not initialize the full ID string in the control block, only array members 0 through 10. Given that the JLink probe searches the full ID string, consider updating _DoInit to perform initialization of the entire ID array, including expected 0x0 bytes.
  
• I had placed the RTT control block outside of BSS section using SEGGER_RTT_SECTION , and this RTT control block area was not zero-initialized on boot as appears to be expected by _DoInit. I think this is a valid use case, especially when an application may want to preserve the RTT log buffers across a reset or share log buffers between multiple applications. e.g. Continue to use RTT logging when jumping between application and bootloader. It would be a nice addition if the INIT() macro supported this use case, potentially with a compile option such as #define SEGGER_RTT_PRESERVE_INITIALIZED_RTT. The INIT()/_DoInit() code could do a full scan of the ID in the control block and only reinitialize the control block if not already present. Making the _DoInit() code work without requiring zero initialized storage would be a nice addition.
  
• The _DoInit() code unconditionally initializes both p->aUp[0] and p->aDown[0], even if SEGGER_RTT_MAX_NUM_UP_BUFFERS==0 or SEGGER_RTT_MAX_NUM_DOWN_BUFFERS==0. In my application, I had originally set SEGGER_RTT_MAX_NUM_DOWN_BUFFERS=0 but it would appear this is not a valid configuration because p->aDown[0] will access an invalid address. I suggest that the init code be updated to support 0 length num buffers, or a compile time check to ensure that user has not set either of these two configuration variables to <= 0. e.g.
  #if SEGGER_RTT_MAX_NUM_UP_BUFFERS == 0
  #error "SEGGER_RTT.c implementation assumes SEGGER_RTT_MAX_NUM_UP_BUFFERS > 0"
  #endif
  #if SEGGER_RTT_MAX_NUM_DOWN_BUFFERS == 0
  #error "SEGGER_RTT.c implementation assumes SEGGER_RTT_MAX_NUM_DOWN_BUFFERS > 0"
  #endif
  

Regards
Austin