MSP430 - ISRs unable to call TaskYield()?

alunz wrote on Thursday, January 20, 2005:


The following is a lengthy-ish explanation of a problem encountered with a
port to the MSP430F149.  There seems to be a problem with an ISR calling
TaskYield() which causes other interrupts to be disabled.  If anyone has
encountered something like this would appreciate any pointers.

Am attempting to port FreeRTOS onto the EasyWeb2 dev board from Olimex using
the demo MSP430 port (originally for the MSP430F449) as a base. 

The EasyWeb2 has only one LED but does have a 16x2 LCD.  Therefore, have
modded the demo apps so that the LED flashing routines will toggle a char
that is to be displayed (there is a new task that periodically redraws the
LCD every 50ms).  The single main LED is used by the vErrorChecks() routine
to report on the status of the tasks.

So far so good and the program seems to work.

However there is a problem where vErrorChecks() will report that there is a
problem (the LED flashes faster) after the demo routine has been running for
a while.  Poking around in the code reveals that the problem is with

What is happening is that after a while the Tx ISR stops working.  That is,
characters are not being pulled from the xCharsForTx queue and then sent to
the UART.

Further poking around reveals that the problem goes away if the call to
TaskYield() within the vRxISR() routine is commented out.

Am a bit of a loss to immediately see why this is a problem, so would
appreciate any pointers that people may have.

Thanks for your time,

nobody wrote on Thursday, January 20, 2005:

I think the 149 and 449 are pretty well compatable regarding memory layout.  Are you using the demo application exactly as downloaded - but for the addition of the extra task?

alunz wrote on Friday, January 21, 2005:

Thanks for the very prompt reply.  It turned out that the problem as originally reported was caused by creating more threads/tasks than there was memory to support them.

Trimming back the number of threads has mostly got things behaving as they should.  Have only got one remaining problem (with the polled queue test) that needs to be investigated.  That problem is proving to be very intractable and seems to be defying most physical laws (including causality).  May have to ask some more questions on that one if am unable to nut out what is going wrong there.

For the record, the EasyWeb2 port is very much the original Demo port with changes to:
- setting up the hardware (different ports for LED / LCD, different CLK, Timer ISR setup)
- removing one of the LED tasks from Flash.c

and of course the code to use the LCD to simulate LEDs.

Again, thanks for the reply and thanks for FreeRTOS, it is proving to be fun and useful.


rtel wrote on Friday, January 21, 2005:

With the demo apps I basically just add tasks until all the memory is used.  Perhaps I should make this a little clearer in the docs.

The demo tasks are more for testing the kernel and are each written in isolation which is not memory efficient.  I have just added a new section to the WEB site about how applications can be written to use less RAM.  You might like to take a look.