Ti RTOS interrupt latency inconsistent 28335

Josue,

Glad you decided to let us know what you're facing. In order to fully understand your question, I'd like to know what device you're running on and what version of TI-RTOS you're using.

Thanks,

Moses

Hello Moses,

I'm working on a TMS320F28335. 

The development is starting and I'm using the last TI-RTOS as far as I known. The TI RTOS version is 2.0.2.36.

Regards.

Hi Josue,

Can you elaborate more on how you are measuring the interrupt latency? And how are you counting the cycles?

Moses

Hello Moses,

Regarding the latency measuring I'm using the own PWM counter.

Inside the HWI routine I'm only checking and saving the worst PWM counter. 

The interrupt is configured to trip when counter equals zero, so the counter shows me the latency.

In order to clarify my problem I've been doing some test. With a simple project using only one interrupt configured (the PWM as I explained before) I could measure that the latency is constant around 270 cycles. But when the program computes 150000 interrupts some kind of event occurs. It's absolutely periodic every 150000 interrupts. When the even happens the number of cycles became the double.

Testing the same in my complex program (some HWI, SWI, TSK & CLK) I've seen that the periodicity also meets. In fact, the occasionally 6000 cycles latency occurs with the 150000 interrupts periodicity.

Regards

In order to clarify the issue I've attached the simple program.

Josue,

  How frequently is the PWM interrupt happening i.e what period did you set the counter to?

Moses

Also making sure I understand you perfectly, In your first post you said the number of cycles of the interrupt latency was inconsistent varying from 280 to 6000 cycles. Was this in your original application? In your last post you said you're measuring a constant latency of about 280 cycles, is that from the simplified test application you sent me?

Also to verify, you're consistently seeing the latency double after 150,000 interrupts in both the test case and your main application?

Thanks,

Moses

Hello Moses,

Thanks for your time.

First of all, I'm going to answer your questions:

- I'm using a 4000Hz period (TBPRD=18750, up-down mode, Prescale=1)

- Yes, in my original application (it's composed by the skeleton: hwi, tasks, clocks, swi, etc) the latency moves from 280 to 6000 cycles. The latency moves from 280 to 1300 normally and it arrives to 6000 cycles when the event occurs. 

- In the simple test application I sent you the measure is constant. But when the event occurs it passes from 280 to 750 cycles.

- The event occurs consistently in both projects, but it seems worse in the original application.

And finally, I think we have detected the problem. I proceed to explain you what we have seen.

First of all in the simple project. We've disabled the system bios clock (Unchecked Enable Clock Manager) [1]. The event disappeared.

After that we have created a 1ms interrupt with the Timer 0. We configured it with 150000 ticks period [2]. The event appeared again.

Then we have configured the interrupt correctly, using 14999 ticks[3]. The event disappear again.

So, it seems the problem occurs when two interrupts arrive at the same time to the dispatcher. When I configured  [2] the behavior is exactly the same that when I configured [1]. In both cases timer interrupt overlaps PWM interrupt periodically. When I configured [3] the interrupts never overlap.

More things, I've tested the "solution" in the complex program, the original one. In that way, I've configured the application clock as Application calls clock_sys. After that I've made my own timer to clocking the system with the timer 0. If I configure with 150000 ticks the behavior is the same explained before. If I configure 149999 ticks then the maximal interrupt latency becomes constant to 1300 cycles.

So, my main question is: how SysBios manage two simultaneous interrupts? 

I've been testing the masking options, without any result. I think the critical interrupt must be configured as MaskingOption_ALL and the other ones as MaskingOption_SELF but I  can't see difference with other configurations.

Thanks in advance.

Regards

Josue,

 Good work! I should have thought about the clock when you said you were seeing a periodic 'event' happen that increased the latency. SYS/BIOS sets up timer 0 to use for its clock module that provides system ticks that can be used by other modules. It happened that the timer interrupt happened at the same time as your PWM interrupt.

About the simultaneous interrupts, you're on the right path with the masking options. It's how you can specify priority for the dispatcher. MaskingOption_ALL should be used for the interrupt you want to have the highest priority. No other interrupt will be able to preempt you. It specifies a mask that's used to used to disable interrupts, ALL meaning disable all interrupts while I'm servicing this one. MaskingOption_SELF is the default that's been used and only disables the current interrupt, leaving room for preemption. You can also specify a MaskingOption_BITMASK when you want to specify your own custom masking. That is, you can specify which interrupts to disable while the current interrupt is being serviced. In your application if you think the PWM interrupt should be not be preempted by the clock, you can mask the clock interrupt along with the PWM interrupt in your bitmask. Here's a wiki that explains this even more with some examples.

Let me know if you still have other questions

Moses

Hello Moses,

For my simple program, I've configured PWM interrupt as ALL and timer as SELF, disabling bios interrupt. But that doesn't solve the interrupt latency problem.

Is it anything else I can do in order to improve this behavior?

Regards

Excuse me for the delay answering.

Our development need to start and TI - RTOS has been discarded for the moment.

As soon as we can, we will analyse the last answer. 

Thanks