I have noticed that if you call xTaskGetTickCount inside an interrupt, the FreeRTOS (for msp430) stops working. I think this is due to the portENTER_CRITICAL(); / portEXIT_CRITICAL(); inside xTaskGetTickCount, because the interrupts should no be enabled in any case inside my ISR.
Can be this a bug in the msp430 port? should I implement a new funtion (xTaskGetTickCountFromISR) that just return the tickcounter without enter/exit critical?
No this is not a bug but the expected behavior. The rule is, if the function does not end in “FromISR” then don’t call it from an ISR.
The critical section is necessary on the MSP430 if you have configUSE_16_BIT_TICKS set to 0, which would be normal. When this is so the tick count is 32 bits but the processor is only 16 bits so accesses will never be atomic.
If you protect the tick count with the critical section when you are executing tasks then you should just be able to access the variable directly when you are executing interrupts but you might have to remove its static qualification. Or you could provide a FromISR version of xTaskGetTickCount() that does not have the critical section.
BTW in the msp430 implementation taskYIELD() does not have a FromISR and is called in the Usart Rx ISR. It is safe to use it inside an interrupt? And can be called inside a function that has been called from an ISR? I mean, the ISR calls a function that, after sending some data through a queue (using send From ISR) may need taskYIELD().
BTW in the msp430 implementation taskYIELD() does not have a FromISR and is called in the Usart Rx ISR.
If that is what the official demo is doing then it will be fine - however this does not hold true for all ports, some of which have a different yield function or mechanism for use inside an interrupt.