CCS/TMS320C6678: C6000 interrupts jitter

Hi,

It is true that INT13 has higher priority than INT14. 

In yellow: the rise is the trig from the C2000 (set of GPIO), and the fall correspond to the end a calculation after the return data from C6000>>>>>>>So the yellow line is the GPIO12 pin, correct? The C2000 sets it to high, then an interrupt is triggered to C6000 CPU, the ISR de-assert the GPIO12 pin. It takes 10us.

In blue: the rise is the 1st thing done in the interrupt function, and the fall correspond to the end of calculation in the C6000.>>>>>>There is no timer pin, right? What the first thing you do in the timer ISR? Set a GPIO pin? What signal is this blue line? It means there is a ~2.8us jitter in timer ISR is entered because the GPIO ISR is higher priority.

I also tried to placed the GPIO IT on INT15, I have the same behavior. >>>>>I though the blue line would be in front of the yellow line, what do you mean the same? 

I measured the timing of the timer interrupt function, it is about 100ns.>>>>>How this is reflected in the scope blue line? It takes ~7us from the rising to failing edge.

Will changing a GPIO or timer instance make any difference? 

Regards, Eric

Hi,

I'll explain a bit more the oscilloscope screen: 

In yellow, it corresponds to a debug pin used in the C2000, the pin is set in my ADC IT function just before setting the GPIO12, GPIO12 is toggled so it's more complicated to observe this gpio (the gpio IT in the C6000 is set to fire on both edge). But It checked that the gpio was correctly toggled, and it's fine, the toggle appears like 100ns after it is set and it's really stable. 

The fall is not really relevant with the problem, it corresponds to the end of the calculation done in the C2000 after the return of data from the C6000.

In blue, it correspond to a pin set in the GPIO interrupt function (1st thing done in the function), and the fall correspond to the end of the GPIO interrupt function. This interrupt function is really long but it is the only function that have top priority and shouldn't be stop or delayed. Again the fall of the signal is not relevant with the problem. 

On the previous test there was no gpio set/fall in the timer IT function. I just did the test: 

In blue and yellow: same as previous test

In purple: debug gpio set when entering timer IT function, cleared when leaving timer IT function

I observed on the oscilloscope that the shifting of the blue signal occured when the purple signal appears just before the rising of the blue one. the shifting has a duration of about 3.9µs

I hope this reply will answer your questions. 

I'll try during the day to test if the change of gpio or timer make any difference. 

Regards, 

Clément

Hi, 

quick update on tests I made: 

I tested with the interrupt on GPIO9 instead of GPIO12 => same jitter 

I tested with the timer 8 instead of timer 0 => same jitter 

I tested with the GPIO IT function with INT4 to have the higher priority possible => same jitter 

Regards, 

Clément

Hi,

Thanks for the clarification! It means that for the two interrupts on C66x side, one is timer ISR with lower priority and the other is GPIO interrupt with higher priority, and both ISR set a pin respectively. In theory, the GPIO interrupt should not be delayed (the gap between yellow and blue line shouldn't be pushed bigger when purple line presenting in front).

Given you both operate on certain GPIO pins, is it possible that the issue come from setting GPIO pin high itself, just a guess.

1) In the timer ISR, if you don't toggle a debug GPIO pin, just do some arbitrary math (so you have a flat purple line), will you see any "shifting has a duration of about 3.9us" of the blue line? If yes, then it means that interrupt priority doesn't work. If no, that means driving GPIO has some artifacts, e.g. the circuit takes some time to set a new pin after setting a previous pin.

2) In the timer ISR, if you keep the debug GPIO high longer enough into the GPIO interrupt, that is, not small spike in the purple line, but a long purple line toggled in high without existing when GPIO interrupt came in, do you see the blue line is shifted to the same 3.9us amount? If yes, that means interrupt priority still worked. 

Regards, Eric    

Hi Eric, 

1) The debug gpio was used in the gpio function interrupt, so I always had this shifting problem even when the debug gpio is not used in the timer function, the 1st oscilloscope screenshot corresponds to this test. For me it's not a GPIO driving problem. I think it's more because of the interrupt itself.

Do you know how much time an interrupt function needs to save its context (data, registers...) when an interrupt with a higher priority preempts the current IT function ?

2) Not sure I really get what you meant, the test is to rise the gpio in the timer IT function and to clear it the gpio it function, right ? 

I did this test, it's not easy to observe because I have to let the oscilloscope on infinite persistence to catch the phenomenon: 

In blue and yellow: same as previous test

In purple: debug gpio set when entering timer IT function, cleared when entering GPIO IT function

The GPIO is cleared when entering the function and we can see the shifting. 

I thought of another test (maybe it's the one you really wanted), I added some delay in the timer IT function to check if something appears: 

In blue and yellow: same as previous test

In purple: debug gpio set when entering timer IT function, cleared when leaving timer IT function

The timer IT fired just before the GPIO IT are not preempted by the GPIO IT, so the gpio function IT is shifted. The purple signals on the right reveals that the timer IT wait for the end of the gpio IT to start (in normal operation, the blue signal falls at the place of the right cursor)

It feels like the µC waits for the IT function to be over before starting a new IT function, and not priority matters. Is there a register to activate the pre-emption of high priority interrupt ? 

regards, 

Clement

Hi Eric, 

thank you for your answer, I thought the nesting was hardarware on this DSP, my bad. 

I still can't explain why my 100ns timer interrupt function shifts my GPIO IT function this much. But if the nesting resolves the problem, I'll be fine with it. 

Regards, 

Clément Leyssene