Stack on ATMEGA8

I use FREERTOS on an ATMEGA8 (1k SRAM, 8k FLASH) and if I have two tasks everything is OK, if I put another (3 in total) system seems to get stuck on one of them or something like that. Then I experimented by increasing the stack size for the two previously working tasks and I verified my theory. Once I increase the total stack size allocated from all tasks above 220bytes the system gets stucked. I don’t really have a problem, I can do my job with two tasks. I just want to ask if this should happen or not?

Stack on ATMEGA8

1K SRAM is not very much.  Each task has it’s own stack, plus any static data you have.  This all has to fit into this 1K.  There is also the stack for the idle task. Can you implement one of your tasks as an idle hook?  This would save you some RAM, but can only be done if the task never makes a blocking call (the task must always be available to run).

Stack on ATMEGA8

I fixed the problem by increasing the TOTAL_HEAP_SIZE size from 500bytes to 700bytes. It’s a little bit misleading that Task’s STACK is being allocated on the HEAP (- I’m sure that the OS masters will laugh now claiming that "where else could it be allocated on?") 😀 People having similar problems should look at: http://www.freertos.org/FAQMem.html and experiment with different values for TOTAL_HEAP_SIZE. (Don’t forget to ‘make clean’ and then ‘make all’ again in case that "FreeRTOSConfig.h" is not included in your Makefile’s dependencies). It’s still strange the way that application stalls always in the same way! Perhaps some macros inside "xTaskCreate" could enable a message to be popped. Some additional documentation about memory management would be welcome! 😀

Stack on ATMEGA8

Note: By increasing the HEAP SIZE from 500bytes to 700bytes I can have two more tasks. When I add another task it gets stuck in exactly the same way as before! – Very strange! I am used to see really unstable behaviour when a system runs out of memory – in freeRTOS it seems like the scheduler just stops task switching.

Stack on ATMEGA8

Where does it get stuck?

Stack on ATMEGA8

Thank you Anonymous. In fact this is an academic conversation! 😀 My application is simple enough and can be easily implemented with just two tasks. If anyone is interested in the AVR Gas Meter, more information can be found here: http://lookfwd.doit4me.gr/blog/index.php?blog=2&title=the_avr_gas_meter&more=1&c=1&tb=1&pb=1.

Stack on ATMEGA8

Ok, This was a really hot question that gave a lot of hot answers! 😀 I’ve put some UART "traces" like these: ABCDE – initialization of tasks kl – view procedure 1 – ADC measure task 5 – Key-Scan task 6 – Demo task 7 – Demo task During normal operation it traced like this: klmABCDE 13kl – 756 13kl – 5 13kl – 7655 13kl – 765 13kl – 5765 17655 17655 1765 13kl – 7565 When I added another task, it traced like this: klmABCDE Which means that the thread switching doesn’t even start. By hacking the source of vTaskStartScheduler(), I put some additional traces that revealed that the "problem" was once creating the IDLE task. xTaskCreate kindly returned pdFAIL and vTaskStartScheduler() was returning imediatelly. Of course I’ve never imagined that something like this could happen and I haven’t put a "HEY, WHAT DO YOU THING YOU’RE DOING?" message after vTaskStartScheduler() inside main(). That’s all!

Stack on ATMEGA8

And, as my project completes, one last world of attention: "If your application has 3 user tasks that must all be at different priorities then use priorities 3 (highest), 2 and 1 (lowest – the idle task uses priority 0)." In this case, do set configMAX_PRIORITIES configuration variable to 4. That is the number of your priorities + the idle priority. Internally, configMAX_PRIORITIES is being used like this: if( uxPriority >= configMAX_PRIORITIES ) {     uxPriority = configMAX_PRIORITIES – 1; } As a result, you will never get a warning while at the same time, your highest priority levels will get "flatten".