Calculation of stack usage in C2000 DSP

Jacktang

Calculation of stack usage in C2000 DSP [Copy link]

For power electronics software, there is usually not much code in this line, and it often takes several months to adjust a few lines of code, such as grid-connected algorithms and H-bridge control. Some time ago, when a colleague was working on communications, he found that the TMS320F280XX chip would sometimes crash. His communication software used the library provided by TI, and he made the communication protocol layer himself. Although the main chip reset the communication chip after the crash, we still wanted to solve the problem. When we found that there was no obvious bug in the code, the first thing we suspected was stack overflow. After changing the stack of the original compilation environment from 0x300 to 0x3a0, the problem did not occur. TI's CCS5.1 defaults to 0x300 for C2000, which is generally enough. It may be because we use the library, but without the source code, we can only tinker with the periphery. I searched the Internet and found that the stack settings in the general embedded software industry are mostly estimated values. Of course, there are also some theoretical algorithms, which should not be used by many people. So I wondered if I could write a program to truly test the actual use of the stack when the software is running. Put a moderate value. After all, RAM resources are still very tight for C2000. My idea is to write all the memory space in the stack segment to 0x55, then let the program run, observe the data in the memory, and see how much data has been overwritten. I used my own power control software for testing, so the stack is not used much. In the CMD file, the stack is linked to RAMM0 (RAMM0: origin = 0x000050, length = 0x0003B0). Set the stack space to 0x300 in the build option of CCS5.1. The screenshots and small test code are as follows. In this example, the stack only uses 0xb3, which is 99 bytes. Suggestions and tips: 1. Please understand the principle of stack usage. You cannot pass in formal parameters and use local variables in the function InitialStack() that initializes the stack. This also helped me understand that "formal parameters are copies". If you change the formal parameters in your own stack, it will be a mess. 2. It is recommended to move the functions that need to be called frequently to RAM, which will be much faster. The method is very simple, see DSP28x_usDelay(). 3. It will also run much faster if optimization is set during compilation. Try to reduce unnecessary jump statements, which will disrupt the pipeline. Also, be sure to use volatile. 4. If a variable is modified in both the main loop and the interrupt function, especially when this variable acts as a flag, you must pay special attention and have some multi-threaded programming ideas. #defineSTACK_SIZE 0x3b0 Uint16 *pStackTop; Uint32 ulMainCnt=0; void InitialStack(void) { for(; ulMainCnt < STACK_SIZE; ulMainCnt++) { *pStackTop++= 0x55; } } void main(void) { Uint16 uiTempCnt; DINT; pStackTop= (Uint16*)0x50; //Pointer forced type conversion InitialStack();