MSP and freeRTOS

stacksize?

First, there is no 'stack size' in the resulting program. The stack starts at its initialisation poitn and then grows. No compiler settign will stop it from growing as large as the code flow demands.

Depedning on the compiler, the 'stack size' setting may toggle some optimization algorithms, and it may make the linker whine if stack size and variables won't fit into ram, and maybe the debugger can perform a stack pointer check at breakpoints, but there is no way to limit the stack size at runtime.

About optimization:

the 5418 has ~40kb Flash below 64k (41kb minus the interrupt vector table) and some more above.

To use the flash above 64k, it has to be programmed in 430X code, which uses 20 bit registers instead of the normal 16 bit.

As long as you're using normal 430 code, all code and data must reside below 64k. Calls are writing 16 bit return addesses on stack and data is accessed through 16 bit pointers.

The linker, however, may place code or data into upper flash area if the lower flash is full. This means that code that isn't intended to be on upper flash may end up there, and calling it will instead call the start of the address range (jumping to 0x00000 instead of 0x10000).

If 430x code is used, code above 64k can be called with the CALLA instruction (rather than CALL) and 32 bit return address are stored on stack. Likewise the RETA instruction is required rather than the RET instruction.

Unfortunately, this needs to be done for ALL functions, including included libraries, as else you're eitehr jumping into the void (usign CALL isntead of CALLA) or returning into the void (using RET instead of RETA). And functions dealign with the stack or with data on the stack must be aware that there are two mroe bytes return address before the data begins.

If data (e.g. constant data) is placed in upper flash, things get even more complex.

Since the interrupt vector tables have only 16 bit vectors, all ISRs MUST reside in lower 64k (the RETI instruction to return from an ISR has been tweaked to smartly save the additional 4 address bits: they are merged into the status register that's already put on the stack and extracted on RETI, so it always works).

So possible causes for a problem are:

• ISRs are accidentally put into upper flash. 
• libraries are included which do not support 430X code but the applicaiton itself is in 430X code
• the application code is not 430X compliant but larger than the available memory below 64k

All three may result in crashes liek the one you observed.

And your code size on maximum opimization is close to the 41k limit, so maybe just a single function is moved above 64k and causes a crash when called, while most of the application is working fine, while in unoptimized mode, too much is moved up and the app crashes immediately.

Jens-Michael Gross said:

First, there is no 'stack size' in the resulting program. The stack starts at its initialisation poitn and then grows. No compiler settign will stop it from growing as large as the code flow demands.

See http://www.freertos.org/a00125.html

 portBASE_TYPE xTaskCreate( 
                            pdTASK_CODE pvTaskCode, 
                            const portCHAR * const pcName, 
                            unsigned portSHORT usStackDepth, 
                            void *pvParameters, 
                            unsigned portBASE_TYPE uxPriority, 
                            xTaskHandle *pvCreatedTask 
                          );

They call it usStackDepth.

Hardy

Ah, okay, if 'stack size' referred to the RTOS' internal threads reserved stack size, then of course the setting makes a difference. I wonder why RTOS does not detect a stack overflow then, as it exactly knows how large the reserved stack size is. Since it has to already handle the stack switch and store the stack pointer, it could as well do a simple comparison whether the stack pointer is still in the valid range. If precalculated at thread creation time, it would be only a few clock cycles more.
It was one of the first things I implemented into my own task switcher.

My comment about stack size was referrign to the usual 'stack size' setting in the IAR/CCS project settings. Which usually makes people think that the stack will use exactly this size and not more.