FreeRTOS crashes after some time

nobody wrote on Wednesday, September 27, 2006:

My problem is that FreeRTOS works fine for a while, and stops working after 10seconds to 10 minutes after mcu reset, depending on semaphore blocking settings. This is my first bigger app on this rtos. I try to run only one task yet which is blocking and waiting for a semaphore from isr. I’m using WinARM, SAM7S256 port made of SAM7X port from lwIP demo. My ISR/semaphore setup is very similar to this in SAM7_EMAC(_ISR).c and main parts look like this:

//The ISR (compiled in ARM mode)
void RS485_USART0_IRQ_handler( void )

portBASE_TYPE xTaskWokenByPost;
//some code
xTaskWokenByPost=xSemaphoreGiveFromISR( xSemaphore_USART0_new_data, xTaskWokenByPost );
//some code
portEXIT_SWITCHING_ISR( xTaskWokenByPost );

//and the task, thumb mode:

void vRS485_task( void * pvParameters )
if(xSemaphoreTake( xSemaphore_USART0_new_data , portMAX_DELAY ))
//some code (lcd write)

ISR is executing every about 200-300ms and execution of the task and ISR surely will not take so long time.
I tried both preemptive and non-preemptive tick, different blocking times in semaphore wait. I have also tried to suspend the task, resume it from isr, simple indicate resume on lcd, and suspend if again (without semaphore). Effects were similar: sometimes it stopped after 10 seconds, sometimes after longer time, like 10 minutes. It’s simple, it really should work… Does anyone know how to fix it? I have no idea even where to start.


chaalar wrote on Thursday, September 28, 2006:

What about your ISR decleration. Yet simple but do you use "naked" attribute?

nobody wrote on Thursday, September 28, 2006:

Yes, I use “naked” attribute.
I noticed that when I changed attrib to standard “IRQ”, removed portENTER_SWITCHING_ISR();, EXIT_SWITCHING…, and disabled preemption everything works fine now about 8 hours so probably will not crash. But how about preemptive scheduler? Although it’s not very important for me to use preemtion and it may work like it works now, I’m still interested what happens.

rtel wrote on Thursday, September 28, 2006:

Are you vectoring to the interrupt directly, or running some intermediate code first?

The demo (using GNUARM) vectors directly and this is necessary.  The Atmel demos, from memory, have some intermediate code that is executed prior to the defined interrupt code running.  This will cause problems.

Could also always be a stack problem I suppose.  Saving the context will increase the stack usage.


nobody wrote on Thursday, September 28, 2006:

Actually, how to check if I’m vectoring the interrupt directly? I’m using all the startup code from lwIP demo, so probably such low-level config remains unchanged (if it’s this).

The stack size for task in which i use semaphore is declared to 700B. I don’t know  if it makes sense to try bigger stack for such a simple task?

nobody wrote on Thursday, September 28, 2006:

>I’m using all the startup code from lwIP demo

In which case you are vectoring directly.

dmwilliams66 wrote on Friday, September 29, 2006:

Try using GnuArm/Cygwin instead of WinARM.

I’ve tried a lot of compilers… WinARM’s the only one that doesn’t work for me now.

There’s also a bug in the linker script in the lwip demo that doesn’t allocate space for the stacks.  You gotta full RAM?  Then the tail end of your data section may be jumping on the IRQ etc. stacks.

nobody wrote on Wednesday, October 04, 2006:

Thanks for all the help! Now I know where to start. I realized some days ago that one file I use is not taken from lwIP demo, but from WinARM USB demo (syscalls.c), and I’m sure it’s critical. Lack of allocation of space for stacks in linkerscript seemed to me a bit suspicious, but I knew that lwIP works, so I didn’t change anything.