Stack on ATMEGA8

lookfwd wrote on Monday, July 25, 2005:

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?

nobody wrote on Monday, July 25, 2005:

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).

lookfwd wrote on Monday, July 25, 2005:

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?”) :smiley:

People having similar problems should look at:

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! :smiley:

lookfwd wrote on Monday, July 25, 2005:

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.

nobody wrote on Monday, July 25, 2005:

Where does it get stuck?

lookfwd wrote on Monday, July 25, 2005:

Thank you Anonymous. In fact this is an academic conversation! :smiley: 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:

lookfwd wrote on Monday, July 25, 2005:

Ok, This was a really hot question that gave a lot of hot answers! :smiley:

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:

13kl - 756
13kl - 5
13kl - 7655
13kl - 765
13kl - 5765 17655 17655 1765
13kl - 7565

When I added another task, it traced like this:


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!

lookfwd wrote on Monday, July 25, 2005:

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".