AM5728: TI-RTOS - Clock Swi "catches up" after debugger pause

Jon Lake

Part Number: AM5728

Hi,

I'm working with TI-RTOS on the AM572x and I'm trying to debug my application, which includes a clock instance posting messages to a mailbox which are read by a task. I've put breakpoints in my code, but when I unpause execution after hitting a breakpoint, the clock Swi executes many times in a row, filling up the mailbox before the task is able to read from the mailbox. This doesn't happen during normal execution. To debug the situation, I increased the mailbox message limit from 15 to 100 and increased the clock period from 50 ms to 500 ms. What I'm seeing in the ROV is that the clock Swi fills up more message slots in the mailbox the longer I leave the debugger paused for. This suggests that the clock has some way of recognizing the real elapsed time during the pause and "catches up" on a backlog of clock ticks. Is this the case? Is there a way to avoid this behavior?

I'm using SYS/BIOS libraries from bios_6_76_03_01 in the TI-RTOS processor SDK. I'm debugging with CCS 9.3.0.00012 and using the TI XDS2xx USB Debug probe.

Here's a reduced timing diagram of the relevant portion of my application:

Idle Task Swi_Clock
| | |
| O Mailbox_pend() |
O<---O |
O | |
O-----|----------------------------->O Mailbox_post() -
| O process msg <---------O |
| O Mailbox_pend() | | 50 ms
O<---O | |
O | | |
O----O---------------------------->O Mailbox_post() -
| O process msg <----------O
| O Mailbox_pend() |
O<--O |

... ... ...

Thanks

over 4 years ago

0 Jon Lake over 4 years ago

Prodigy 170 points

Any insight into this issue? I ran my code with UIA and got an Execution Graph indicating that the Timer Hwi is repeating rapidly after resuming execution, posting a lot of Clock Swis that take over once the Hwis stop (shown in attached images).

I'm running the code on the main A15 core, so I'm surprised that the timers wouldn't be halted by the debugger. This is running on a custom board modeled after the AM572x EVM, so I'm wondering if there's some timer configuration that would fix this issue, but I'm not sure where to look.

0 Jon Lake over 4 years ago in reply to Jon Lake

Prodigy 170 points

I was able to solve my issue with the help of this post:

RTOS/TMDXIDK5718: DMTimer not available - Processors forum - Processors - TI E2E support forums

Apparently, the default timer for Timer_ANY on the AM572x/A15 is the A15's Private Peripheral Timer according to the A15 TRM (ID = 30, falls in the private peripheral range specified in the AM572x TRM). This timer can't be stopped by the debugger, so dmtimer needs to be used to access the AM572x's Generic Timers, which can be stopped by the debugger. I wound up using TIMER2 by default. I found some of this background into in this post:

Clock issues with Sysbios on A15 - TI-RTOS Forum (Read-Only Archived) - TI-RTOS (Read-Only) - TI E2E support forums

I only had to slightly modify the code from the first post for my application. Here's what I put in my .cfg file:

var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
var params = new Timer.Params;
params.period = 1000;
params.runMode = Timer.RunMode_CONTINUOUS;
params.periodType = Timer.PeriodType_MICROSECS;
params.arg = 1;
Timer.create(-1, '&hwiFxn', params);

Clock.tickSource = Clock.TickSource_USER;

And here's what I put in my main .c file:

void hwiFxn(UArg arg1)
{
    Clock_tick();
}

After doing this, I was seeing in the ROV that there was no longer a Hwi with intNum 30 (A15 PPI2 unstoppable timer), and there was one with intNum 70 (AM572x stoppable TIMER2). Pausing my application in a task function also verified that the Clock Swi was no longer piling up messages in the task's mailbox after unpausing.