Too Few RTDX Host Buffers...?

Unfortunately, we no longer provide support for RTDX, and it definitely has some lingering quirkiness. Most likely you're not doing anything wrong here, and the best you may be able to do here is find some kind of workaround.

Have a look at this article about using BIOS 5 RTA in CCSv4. It doesn't address your specific issue, but hopefully it will help inform you about what should and shouldn't work, and offer some suggestions to try.

http://processors.wiki.ti.com/index.php/BIOS_5_Real-Time_Analysis_%28RTA%29_in_CCSv4

Thanks,

Chris

Chris,

Thanks for the input. Hopefully when you say "we no longer provide support for RTDX", you don't include RTA in this lack of support. RTA is the ONLY reason to use DSP/BIOS and if there is no on-going RTA support how are folks supposed to debug real-time applications?

MikeH

RTA is an important tool and is still supported.

RTDX is the 'run mode' transport which has been the main way that RTA has received data in real time. Support is no longer provided for the RTDX transport, and so the emphasis is moving towards RTA over transports that aren't based on the emulator and JTAG connection, such as ethernet and UART.

In the meantime, we're stuck with RTDX, which is generally functional, but clearly has some issues. This is supplemented by 'stop mode' support where, when you halt the target, any data sitting in the buffers is collected and displayed in RTA.

If you're willing to share, I'd be interested to hear about how you use the RTA tools. Do you find the data streaming in real time valuable, or do you really just need a snapshot or window of data that you go back and analyze? Do you look at the BIOS events to see the activity of your TSKs, or are you more concerned with your own LOG_print statements?

Thanks,

Chris

Chris,

Run mode is not currently as important to me, whoever may be more so in the future. My main (current) hurdle is optmizing a compression algorithm for lowest CPU consumtion, which I can to with RTA and DSP/BIOS STS (mostly CLK_gethtime()). But I am very new to this whole real-time development scene and am just learning what tools are available and how to use them. I assume that run-mode transport may become more valuable as the system becomes more fully integrated. I currently do not use the LOG_printf statment but can see how it may be helpful for tracing program flow, which is not currentl an issue. I am mainly watching a single TSK for processor consumption.

Thanks for the feedback.

MikeH

Hi

Run time streaming is very important to me. When we run long tests, its handy to have the log output without having to stop the CPU since there are other parts of the system that can't be stopped.

Its also handy to review all historical events. This requires too large a buffer if we have to store every event over the life of the test.

Also, we are more concerned about our own log prints.

Chris35513 said:

RTDX is the 'run mode' transport which has been the main way that RTA has received data in real time. Support is no longer provided for the RTDX transport, and so the emphasis is moving towards RTA over transports that aren't based on the emulator and JTAG connection, such as ethernet and UART.

How can you have RTA (Real Time Analysis) without a real time transport mechanism?

Could you tell us more about the sending of RTA data via ethernet? Is it available? It would be a pain to have to add a PHY, and then add the NDK driver, but if thats the way things are going..... UART would be too slow.

Mike: I got to your thread from another issue I was trying to understand

http://e2e.ti.com/support/embedded/f/355/p/75501/278333.aspx#278333

Cheers

 "no longer provide support for RTDX"

Is that mean I can't use Message Log anymore?

Because each time I click "connect" to my DM6437 with Message Log view opened.

It pops out the same "Too Few RTDX" dialog.

If I click "connect" to my DM6437 with Message Log view closed.

There is no "Too Few RTDX" dialog pops out.