Limit of Timer Resolution on MSP430

jimrenliu wrote on Tuesday, October 20, 2015:

I intend to migarte a single thread application to FreeRTOS, but I encounter a problem that seems to be a limitation of timer resolution introduced by FreeRTOS.

I have a task that starts TA0 and then ISR for TA0 toggles CCR2 at 125000Hz, i.e. every 8 microseconds. The interrupts sometimes are missed. After slow down to 31250Hz, i.e. every 32 microseconds, the toggling of CCR2 seems work correctly.

However, the bigger concern would be, what is the safe threshold? now, 31250Hz works fine with nothing else running, how to make sure this threashold won’t break as more tasks are added?

edwards3 wrote on Tuesday, October 20, 2015:

You have an interrupt that is running at 125KHz? That is fast. If that port uses global interrupt disables in its critical sections I can see it could cause a problem for you. There are to many variables to actually answer your question though, like the clock frequency of the device, the compiler, compiler options. Its unlikely anybody would have an answer for your case anyway.

jimrenliu wrote on Tuesday, October 20, 2015:

The clock is for an in-house protocol that bit-bang at 125KHz.

Additional info: CPU=14MHz, TA0=230,400Hz.

After I increased TA0 four times to 921,600Hz, I was able to do bit-bang at 125KHz. But I am not sure why.

richard_damon wrote on Tuesday, October 20, 2015:

As MEdwards stated, an interrupt every 8 us is very fast. I would expect that it would need to be done in an interrupt that never gets disabled for critical sections (which is why it didn’t have problems in a single threaded application), and thus not use any FreeRTOS calls.

Doing a quick check of the MSP430 (I am not very knowledgeable on this series in particular), it looks like the MSP430 does NOT have a simple way of disabling lower priority interrupts while leaving higher priority interrupts enabled, or control nesting via interrupt priorities. This does not sound good for your application, as that means that critical sections will use the global interrupt flag, which can cause you problems.

If there is any way to use the NMI vector for this purpose, it might help.

jimrenliu wrote on Wednesday, October 21, 2015:

I realized the interrupt is too fast for FreeRTOS, but fast is a subjective and relative term, thus my original question: what is the threshold? i.e. the reasonable frequency of interrupt that will work reliably with FreeRTOS?

heinbali01 wrote on Wednesday, October 21, 2015:

Hi Jim,

A CPU running at 14 MHz and an interrupt every 8 µS means that there are only 112 ( 14 x 8 ) clock ticks between 2 interrupts. If the interrupts get disabled for a few µS, it is likely that you will miss interrupts.

Does the part also allow a 20 MHz clock?

Whatever the OS you are using, do you realise how much code is executed before, during and after a ISR?

Will you be calling any FreeRTOS during an ISR?

A reasonable interrupt frequency would leave enough CPU cycles between two interrupts. 112 clock ticks sounds like too little.

Please check the listing that shows the C-code of your ISR along with the assembler. If you want put the code in your reply.
Maybe it is possible to write it entirely in assembler and make it shorter.

Good luck !