CCSv5.5 RTA printf log is missing messages

Egor,

Can you post the picture again?   I don’t see it.

In general, if you are trying to send too much data too fast for the transport, or if there is not enough CPU idle time available for transporting the data off the DSP, LOG buffers can wrap around, and data can be lost.  I don’t know if this is what is happening for you, but it might be.

What device and RTA data transport are you using?

And if you reduce the amount of data you are sending, do you stop missing messages?

Thanks,
Scott

Thanks for replying, Scott. It so strange, because yesterday the screenshot displayed well...anyway, I'm posting it again:

The pair of messages, as I said in previous post, has to display every 100 ms without any missings of any of them.

As you recommended I reduced "Frequency is tuned..." message and left only "To the calling channel...". The result is on the next screenshot:

As it can be seen, after index 8 (Ind:8) index 20 is going, instead of index 9. So, 11 messages has been lost.

The information about hardware and soft:

Device - TMS320C6713 - single core DSP.

Emulator - Sauris SAU510-USB IsoPlus2. Data transport realizes through JTAG interface.

LOG buffer placed in external memory(I tried internal with no success(same result)). Size of log 256 words, bufType - circular.

From code side messages output realizes through LOG_printf and LOG_printf4, then messages displays in RTA->PrintfLogs tab.

What means "RTA data transport"? I'm afraid I didn't get what you'd like me to show.

Also I screenshoted some useful info, perhaps it'll help:

Statistics data:

CPU Load in idle mode:

Thanks for feedback,

Egor.

Egor,

Thanks for the additional details.

By “RTA data transport” I meant the data transport mechanism for sending RTA instrumentation data between the DSP and the debugger host.  You indicated JTAG, which implies to me that you are using RTDX as the transport. 

The load graph indicates that the CPU load is roughly 20%.  But the time scale on the graph indicates nanoseconds.  How are you capturing this load graph?

The IDL loop needs to run to initiate RTDX transfers.  If it is indeed running very regularly, it is still possible that the data rate available with RTDX is too low for the amount of data you are sending.  Have you tried abbreviating the messages (for example, removing “To the calling channel. Ind:" from each message) to see if less messages are dropped? 

Also, if there are extended periods when the IDL loop cannot run because a higher priority thread is running, then this can cause gaps like this too.  It might be that the circular LOG buffer is wrapping around while the DSP is waiting to send data to the debugger from the IDL loop.  Have you tried increasing the number of LOG records to be greater than 256?  This should help accommodate gaps of time when IDL can’t run.

Hope this helps…

Regards,
Scott

Scott,

I tried abbreviating the messages, as you recommended. Seems, it has become a little bit better, but the problem of missing messages still exists. The same story with increasing LOG_trace buffer size.

The load graph behaves very strangely (or I don't know how to use it) and seems not  to be very reliable. As I found out "time" scale can be overwritten with any another title with no changes in graph representation. Sometimes it curves nothing at all. Maybe load graph window captures data from Raw Logs:

Anyway, analyzing the project I found out two tasks, threads of which are not contlolled by semaphores. The tasks are forced to sleep using TSK_sleep(2) and TSK_sleep(1). My colleagues persuade me that the parameter passes in TSK_sleep in milliseconds, but as I found out from BIOS api doc spru403s.pdf time value is passed in ticks.

But even if the tasks worked during all processor idle time, CPU load value would be much higher then it is presented in the Statistics Log screenshot .

Can these two task cause missing packets in Printf Logs window or not? Does TSK_sleep() operates with milliseconds or ticks?

May CPU load data from Raw Log and load graph window be unreliable?

Where can I watch percent of CPU load of certain task if it is possible? I thought I could do it through Statistics Data window, but I'm not sure I understand purpose of each column in the window except STS:

I can't get, why all the colomns of the tasks are zero?

Thank you for the answers,

Egor.

Egor,

I don’t know why the information is not updating as you expect in the different RTA views.  If the CPU is heavily loaded there can be gaps in RTA data because it is always transported to the debugger as lower priority to other application execution.  And gaps can make the displayed data confusing. 

I think probably the most important things to determine at this point are that 1) there is not too much data to transport, and 2) that the CPU can spend plenty of time in the idle loop to be sure RTA data is not dropped.  Also, that there aren’t significantly long periods of having all interrupts disabled (since this will impair the RTA data transport too).

Your specific questions:

"Does TSK_sleep() operates with milliseconds or ticks?"
You are right it is system clock ticks.

"Can these two task cause missing packets in Printf Logs window or not?"
Yes, they could.  With TSK_sleep(1), If you have a clock tick period of 1 millisecond, that task will run, sleep for a millisecond, run again, …

"Where can I watch percent of CPU load of certain task if it is possible?"
Here is an app note that describes a THRLOAD module that can be used to determine task-specific load: http://processors.wiki.ti.com/index.php/Getting_CPU_Load_on_a_per_task_basis

Hope this helps.

Regards,
Scott

Scott,

I'd like to use THRLOAD module, but I can't download it, using the link, provided in the TI wiki article:
www-a.ti.com/downloads/sds_support/applications_packages/rf_modules/index.htm
Seems, the link is broken.

I searched of the problem and found out that it has already been discussed:
e2e.ti.com/.../1080806

I've tried both links to download RF modules package, but neither the first nor the second works:

1) software-dl.ti.com/.../index.htm
2) software-dl.ti.com/.../rf_modules-v1_00_01_05-Setup.exe

The first one directs to the second link, but after trying the second one only empty page loads, nothing more happens.
Maybe it's a problem with my browser? I use Google Chrome. I tried IE with no success too.
Could you download it for me and post a downloading link here, if it's possible?

Best regards,

Egor.

Egor,

I just tried and see that the first link I sent doesn’t work, as described in that other forum thread.  Sorry.

Can you please try downloading again from the #1 or #2 links?  I wonder if maybe there was a network issue at the time you tried.  I just tried myself and could download from those two links. Then I tried from outside the TI firewall from my android phone and could download both via Chrome and Firefox without issue.

If this still doesn’t work for you maybe send me a forum “friend” request and then I can post it to you directly…

Thanks,
Scott

Scott,

Absolutely the same story. I could download rf_modules only from my android tablet. But I couldn't download it from my work and home PCs.
Anyway, I'll try to get any useful information with THRLOAD...

Thanks,
Egor.