[ABANDONED] J-Link only locates RTT control block if address explicitly specified, but not found if using a search range

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] J-Link only locates RTT control block if address explicitly specified, but not found if using a search range

    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,
    Thank you for your inquiry.

    I just gave this a quick try and on my and everything is working as expected (auto search and search range).

    Setup:
    - STM32F746G-DISCO
    - J-Link Plus V10
    - J-Link Software V6.94a
    - The sample (hex file):
    download.segger.com/Fabian/STM32F7_RTT_Sample.hex
    It is a small printf() loop sample, linking the the SEGGER RTT CB to 0x2004ef78.

    Could you please tell us if the RTT sample above works on your side, too?
    Could you please provide us with a small example project or .hex file this issue is reproducible with?

    Could you please send us a J-Link log file? How to enable:
    wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
    Files
  • Hi Austin,
    Thank you for the provided project.
    We are able to reproduce this issue and will be looking into it as soon as possible.

    I will keep you posted.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Austin,
    We are currently very busy with other projects and therefore did not manage to take a look at this yet.

    A separate support ticket should not be necessary.

    I managed to allocate a slot for this tomorrow.
    I will send you an update as soon as we looked at it tomorrow.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Austin,
    We found the source of the issue.

    The RTT memory footprint is defined as described here:
    wiki.segger.com/RTT#Memory_footprint

    You application does not configure the RTT Control Block (CB) ID correctly.
    At the beginning of the CB the autosearch expects 24 bytes of ID String.
    Of these 24 bytes, 16 bytes are the identification string:
    "SEGGER RTT\0\0\0\0\0\0" which means in your case 0x2004EF78 should read:
    2004EF78 = 53 45 47 47 45 52 20 52 54 54 00 00 00 00 00 00 SEGGER RTT......

    Your application writes this into the ID section:
    2004EF78 = 53 45 47 47 45 52 20 52 54 54 00 79 3D DF 48 F1 SEGGER RTT.y=.H.
    which is against specification.

    If the ram region is corrected manually, the CB is found via auto-detection:


    Since we only check for the whole ID string when we do auto-detection, this works when specifying the control block address.

    I would suggest to upgrade your RTT sources to the latest revision.
    In case of doubt, you can compare your project to the one I provided, as it seems to work as expected on your side, too.

    Does this answer your question?

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • Thanks for solution. I encountered the same problem. I use gcc and set noinit "rtt" section on 0x20000000 address, before "data" section.
    I was looking for a solution all day. in my case when debugging from eclipse RTT viewer worked correctly. but after restarting the power could not find any more.
    Note: if SEGGERT_RTT has buffers that are not used, they must be forced to zero, otherwise the RTT viewer will not output anything either.
    memset( &_SEGGER_RTT, 0, sizeof( _SEGGER_RTT) );
  • Hi,
    Sorry for the delay in response. Busy times...

    We are currently looking into this.
    I will keep you posted.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.