Problem getting RTT running

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

  • Problem getting RTT running

    We have an M0 here (custom mfg, but OTS IP), and need to use RTT fluidly. I've got the V5.10p software and Keil UV5 and a USB J-Link through JTAG. We are running code in RAM.

    When I did the RTT Viewer and "Existing Session", I got:

    0> SEGGER J-Link V5.02f - Real time terminal output
    0> J-Link V10 compiled Mar 15 2016 18:03:41 V10.0, SN=50000599
    0> Process: UV4.exe

    But no other viewer output. This looks like text which sources from the debugger, not our cortex. That last line looks irregular- I'm using UV5, not UV4. I went with USB, "Cortex-M0", JTAG, 1MHz, RTT Control Block 0=auto, got nothing.

    Inside Keil, I tried the Command window and typed _SEGGER_RTT and got 0x10000434, so I put that into "RTT Control Block" and it WORKS, my printf data comes across and anything I type ends up in the downlink buffer. But I can't ask our users to manually check the address after every compile and copy that into the config.

    The manual says SEGGER_RTT_IN_RAM should be defined as (1) in certain cases. I found this in older versions of RTT code (which also didn't work automatically, with or without this defined to 1, and I called the Init task)- but it does NOT exist at all in v5.10p, even though it's still in the User Guide. There's nothing to set.

    I read some ambiguous stuff that the SEGGER_RTT_IN_RAM wasn't necessary if you had the Jlink, even with the code in RAM, it could get the _SEGGER_RTT from code automatically. I did see the Keil Command window say "ws SEGGER_RTT_IN_RAM" at some point, which I thought was RTT Viewer grabbing the address without exhaustively searching RAM. But it wasn't working with or without that SEGGER_RTT_IN_RAM =1. I don't see any way to query RTT Viewer to see what address it's trying to use for the Buffer Control Block, although Channel Infos does give the buffer sizes.

    The actual question: how can I get this to automatically find the RTT Control block, instead of asking Keil for _SEGGER_RTT and copying it into the Viewer config manually?

    The post was edited 1 time, last by Dannym ().

  • Hello,

    If RTT works when you specify the RTT Control Block Address, everything in general is fine.

    The Auto Detection only works for known RAM of known devices.
    In other cases either the address has to be explicitly set or a search range can be given.
    The search range can possibly the whole RAM. (Syntax <Address[Hex]> <Size[Hex]>, e.g. 0x10000000 4096)

    SEGGER_RTT_IN_RAM is not required anymore, since the RTT initialization makes sure the control block in the data section can be identified.

    The RTT Viewer output is correct, since the executable of uVision 5 is still called UV4.exe.

    Best regards
    Johannes
  • It looks like I was mistaken. In my test I already had a session connected and it used that, it did NOT find the RTT Control block.

    My _SEGGER_RTT is 0x10000434. I opened the RTT Viewer, did "USB", "Cortex-M0", JTAG 4000KHz, RTT Control Block "0x10000000 0x2000"

    Nothing is displayed. I checked Channel Info and I get "RTT Control Block not found on target, yet".

    Shouldn't this work? An automatic RTT detection is kinda critical here.
  • I looked through and tried the following commands in J-Link Commander:

    exec SetRTTSearchRanges 0x10000000 0x2000

    Then opened RTT Viewer and left RTT Control Block at "0" for searching. It didn't work, did I not do this right?

    I also tried:
    exec SetRTTAddr 0x10000500

    This is my known RTT address. Again, starting RTT Viewer from there doesn't make it work. What's the relationship between these JLink Commander commands and the RTT Viewer environment?

    Just as a context, we need to provide demo boards to a handful of customers, and explaining "every time you compile, go to Debug Command window, type _SEGGER_RTT, then open up RTT Viewer and enter that number"... it seems sub-optimal.

    I ended up going into SEGGER_RTT.c and changing (in Keil) to:

    SEGGER_RTT_CB __attribute__((at(0x10000500))) _SEGGER_RTT;

    This did, in fact, result in the _SEGGER_RTT assuming a fixed location. Is there a more elegant way of doing this?
  • Hi,

    RTT Viewer does not let you specify a search range, yet.
    We will add this to the configuration dialog.

    Just to make sure it is working with your device,
    could you start J-Link Commander and execute exec SetRTTSearchRanges 0x10000000 0x2000 as you did before,
    then start RTT Client (JLinkRTTClient.exe) and see if this shows your RTT output?

    In the current RTT implementation you can define SEGGER_RTT_SECTION to link the RTT Control Block into a specific section,
    we might add the possibility to define an address via SEGGER_RTT_Conf.h,too, for toolchains which allow this.

    Best regards
    Johannes
  • Invalid packets received, recording stopped

    Hi
    I am evaluating SysView v2.34 (downloaded last week), on my Cortex-M3 system with FreeRTOS V8.1.2, and with USB connected J-link.
    I encountered one problem that made the tool practically not ready for our analysis.
    SystemView got message "Invalid packets received, recording stopped" a few seconds after continuous recording started (about ~3000 events had been recorded),
    even if I disabled all interrupts in SEGGER_RTT_LOCK.

    Does any one have any ideas/suggestions?
    Thanks in advance!

    The post was edited 1 time, last by duncan_xue ().

  • Hi Johannes
    When I got error "invalid packets, recording stopped", I didn't know the error was on host GUI side or on the target side.
    Can you please provide more information, such as in what condition the error occurs?
    Is that possible for you to open the GUI source code, so we can debug?
    Thanks
  • Hi,

    "Invalid packets, recording stopped" indicates, that either a packet with invalid parameters has been received or an incomplete packet has been received.
    The first issue occurs due to target side issues, i.e. incorrect locking,
    the second issue did occur with low-end J-Links (J-Link OB) when many events were generated in short time (high-load situation).

    The SystemViewer source code cannot be made available.

    Could you save and send a recording where you get the invalid packet?

    Best regards
    Johannes