SYSBIOS: Incoherent clock when using clock module

Dear all,

I have a real-time application on an AM3358. I'm using Code Composer Studio to write my firmware.

I'm using the ti.sysbios.knl.Clock module to periodically call a certain function. This function prepares some data for the PRUs and then triggers the PRUs with one system event each. In this case, PRU0 is running the critical program (i.e. the one that takes longest) and is therefore triggered as early as possible.

I protect the the first section of the called function (until PRU0 is triggered) with a hardware interrupt gate, because I want to guarantee that this section runs uninterrupted. The swi generated by the clock has the highest priority level of 15.

In the example that I will discuss below, I set some clock module settings statically in a cfg file:

// 37 us ticks
Timer.intFreq.hi = 0;
Timer.intFreq.lo = 23799582;
Clock.tickPeriod = 37; 

Clock.swiPriority = 15;
Clock.tickSource = Clock.TickSource_TIMER;
Clock.tickMode = Clock.TickMode_PERIODIC;
Clock.timerId = -1;
Clock.common$.logger = null;

Then, in my C program during runtime, I do

ASSERT(!Clock_isActive(hClockIteration));
Clock_setPeriod(hClockIteration, 1); // constant 1 only in this forum example
Clock_setFunc(hClockIteration, &doIteration, (UArg)p); // doIteration() is the said ARM function that prepares and triggers the PRU
Clock_start(hClockIteration);

For most iterations, this works fine. I get a period of PRU triggers that is about 37us:

The red signal is high while PRU0 is active. It should be active for 25 us. The period should be 37 us. It looks good enough most of the time.

The green signal indicates the activity of the function called by the clock, which is running on the ARM. It goes high when the function is entered, and toggles low/high around the command that triggers the PRU. It then does some stuff with the other PRU, processes some data, and goes low again (finished). Note: without the hwi interrupt guard, I sometimes observed jitter in the green signal. Solved now with the guard.

There seems to be enough headroom in the 37 us to execute the critical 25 us of PRU code. The PRU always runs for the same amount of time, as expected. So far so good.

But sometimes, seemingly randomly, the real-time timing constraints are not met. When the ARM enters the iteration function, it checks whether the PRU is still running and generates an error if this is the case. When I look at the scope, I see this:

The PRU is in fact still running (red signal high) when the timer calls the ARM function the next time (green goes high). This is correctly detected and issues the pulse in the yellow signal, which I use for triggering.

I can see that something goes wrong in the previous clock cycle, which is taking too long (50 us instead of 37):

As a result, the following cycle is too short, and my real time constraint is not met.

Where did mit 13 us go? Do you have any idea?

I have tried different tick durations, different Period durations in units of those ticks. It's always the same. I randomly see this enormous clock jitter of about 10 us, which is first too long and then too short, blowing up my realtime loop.

Looking forward to your replies

Fabian