TMS320F28P550SJ: FreeRTOS how to use CPU Timer0 or RTOS interrupt as tick source

Hi, 
Looking into it.
Will get back to you

Hi Agostino,

Apologies for late response.
It is kept at low priority intentionally.
We highly don't recommend changing it.

If you still need to use another time, you will need to make changes in 

\kernel\FreeRTOS\Source\portable\CCS\C2000_C28x\port.c

Can you share the reason behind doing this?

Hi Lakshya, 

thanks for you answer;

I'll try to explain the problem that we have:

1. Timer2 interrupts every 1ms assigned to FreeRTOS tick, (toggle GPIO every cycle using vApplicationTickHook);
2. Timer0 interrupts every 0.1ms, assigned to our control routine that takes 35us (toggle GPIO every 1ms)
3. We have a FreeRTOS software timer running at 1ms, (toggle GPIO every cycle);
4. We have a FreeRTOS task running at 1ms, that takes 200us to execute (toggle GPIO every cycle).

Each of the ones above will toggle a GPIO.

A. when everything works normally, each GPIO will toggle every 1ms;

B. sometimes, it happens that GPIO 1. 3. and 4. (so Timer2 interrupts) skips an entire cycle and trigger on the next ms cycle.

C. sometimes, it happens that GPIO 1. 3. and 4. as above stop toggling for a long time (e.g. 700 ms), every 15-16 seconds, while 2. Timer0 keeps running normally

What I am thinking about:

• point B suggest that if the CPU do not service the Timer2 ISR while the Interrupt Flag is high, that flag will be lost (I imagine it will be high for a 1 Timer2 clock cycle)
  
  
• point C suggest that if some interrupts align temporally with Timer2 end of cycle, Timer2 ISR can be masked for a longer time.

I can also send screenshot from oscilloscope that shows what stated above, but I cannot attach files on this forum.

Thanks for your support!  

Hi Lakshya Verma 

We've investigated further, and seen that:

• the Timer2 FreeRTOS tick not triggering seems linked to the use of portYIELD_FROM_ISR function

More in details:

• When we add portYIELD_FROM_ISR to do e.g. deferred interrupt handling and to wake a task waiting for the interrupt to finish (in our case was an SPI TX/RX complete), sometimes the Timer2 is not serviced, skipping one or more cycles.

The situation is worse when the ISR using portYIELD_FROM_ISR increase in call per seconds.

Moreover, in my previous answer the situation C. was caused by:

• A high priority task waiting for a task notification from a Timer0 ISR 
• Adding portYIELD_FROM_ISR to the Timer0 ISR

In this case the frequency of the Timer0 and Timer2 were slightly different, and I think that could be the cause of the 700ms of Timer2 ISR masking (like a frequency beat).

However, removing portYIELD_FROM_ISR from Timer0 ISR solved the situation, highlighting that probably interrupt are not lost at CPU level in contrast to what I stated in my previous answer conclusion.

Let me know if I can do something further to explain the situation, 

Thanks for you support,

agostino

Hi Agostino,

Can I know which version of C2000Ware you are using? As of v6.00, we have modified the yield interrupt to map to an unused PIE interrupt line (instead of the same CPUTIMER2 interrupt). Could you verify if you are seeing these missed CPUTIMER2 interrupts in v6.00 or later?

Regards,
Arnav