Saturday, February 24th 2018, 10:55pm UTC+1

You are not logged in.

  • Login
  • Register

Dannym

Beginner

Date of registration: Feb 23rd 2016

Posts: 9

1

Friday, March 25th 2016, 8:35pm

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?

This post has been edited 1 times, last edit by "Dannym" (Mar 25th 2016, 8:36pm)


SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

2

Tuesday, March 29th 2016, 6:52pm

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

Dannym

Beginner

Date of registration: Feb 23rd 2016

Posts: 9

3

Tuesday, April 5th 2016, 5:53pm

OK, so SEGGER_RTT_IN_RAM isn't a thing anymore, but what about the "SEGGER_RTT_Init()" task, is that still necessary?

I tried the RTT Viewer setup and gave a base+range for RTT and it seems to work!

What's it take to become a "known device"?

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

4

Thursday, April 7th 2016, 9:58am

SEGGER_RTT_Init() needs only be called when the RTT Control Block is not zeroed in the startup code.

Good to read it is working now.

"Known devices" are the devices where flash download is supported by J-Link.

Regards
Johannes

Dannym

Beginner

Date of registration: Feb 23rd 2016

Posts: 9

5

Thursday, April 7th 2016, 5:40pm

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.

Dannym

Beginner

Date of registration: Feb 23rd 2016

Posts: 9

6

Friday, April 8th 2016, 10:28pm

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?

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

7

Tuesday, April 12th 2016, 10:20am

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

duncan_xue

Beginner

Date of registration: Apr 25th 2016

Posts: 3

8

Monday, April 25th 2016, 3:27pm

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!

This post has been edited 1 times, last edit by "duncan_xue" (Apr 28th 2016, 6:07pm)


SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

9

Thursday, April 28th 2016, 7:07pm

Hi,



Could you give the latest beta (V2.35) SystemViewer a try?

It fixes one issue which could cause invalid packets in high load situations, too.



Regards

Johannes

duncan_xue

Beginner

Date of registration: Apr 25th 2016

Posts: 3

10

Thursday, April 28th 2016, 9:03pm

Hi Johannes
Thank you very much for your reply.
I tried V2.35 (beta), including both target sources and host GUI packages, I still got "invalid packets, recording stopped".
Any ideas/suggestions?
BTW, what is the definition of "high load situations" ?
Thanks!

duncan_xue

Beginner

Date of registration: Apr 25th 2016

Posts: 3

11

Monday, May 2nd 2016, 7:46pm

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

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 377

12

Thursday, May 12th 2016, 11:34am

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