TMS320F28379D: program crashing depending on which RAM .stack is stored in?

Hi,

Regarding restriction on stack, the .stack section has to be linked into the low 64K of data memory. The SP is a 16-bit register and cannot access addresses beyond 64K. Please refer to compiler documentation link below (Section 7.1.2 C/C++ System Stack).

TMS320C28x Optimizing C/C++ Compiler v20.12.0.STS User's Guide (Rev. V)

Can you check if the stack memory is within 64K address space?

Regarding splitting the section, you can try using : >>

Please refer to this link section "Split an Output Section Across Multiple Memory Ranges"

http://software-dl.ti.com/ccs/esd/documents/sdto_cgt_Linker-Command-File-Primer.html

Thanks for the quick reply! In the failing configuration (.stack placed in RAMM) I can see that the stack begins at 0x122 and is 0x200 long. This should be within the acceptable range correct? 

Branden,

Stack address cannot start from 0x122.  If you refer to TRM, the memory section 0x0002 with size of 0x121 is reserved for BOOTRom use.

Section: 4.10.3.4 Reserved RAM and Flash Memory Map

https://www.ti.com/lit/ug/spruhm8i/spruhm8i.pdf?ts=1618850378210

Please refer to any C2000ware DriverLib example - linker command file. It has comments indicating that.

Hi Santosh,

I moved .stack to start at 0x124 with length 0x200 but am still seeing the crash?

I updated the MEMORY section to reflect the BOOT_RSVD section from length 0x000120 to 0x000121 and RAMM section from 0x000122 to 0x000124.

   	BOOT_RSVD       : origin = 0x000002, length = 0x000121     /* Part of M0, BOOT rom will use this for stack */

   	RAMM       		: origin = 0x000124, length = 0x0006DC	/* on-chip RAM block M */
   	RAMD      		: origin = 0x00B000, length = 0x001000	/* on-chip RAM block D */

Branden,

Where does it crash? Where is the PC when it crashes? Does it go to main() or it crashes before that?

Yes, the program enters into main(). When the program crashes I can see that the stack pointer is at 0x0960 and is trying to write to 0x095E with the following assembly code:

087fe4:   FE04        ADDB         SP, #4
087fe5:   A842        MOVL         *-SP[2], XAR4

However, the value in XAR4 does not successfully write to 0x95E and the program crashes.

Branden,

Can you try increasing the stack size? Does it change the behavior? I am wondering if it is stack overflow case. You can add watchpoint and check if it is reaching stack end.

https://software-dl.ti.com/ccs/esd/documents/ccs_checking_for_stack_overview.html#F28x_stack_operation

Yeah I have tried increasing the stack size but I still get the same crashing behavior until I increase the stack size so much (around 0x800) that it will not fit in RAMM and the linker then places it in RAMD, then it starts working. So it does appear that some difference between RAMM and RAMD is causing the failure?

Branden,

You have .stack section starting from 0x0124 with size = 0x200, then why SP is at 0x0960 ? Is it not out of range?

Can you try adding the watchpoint as indicated in the link in previous post ?

That's what I originally thought as well but if I place .stack into RAMD beginning at 0xB700 with length 0x200, the program works. In this case, looking into the same place where the code was breaking before:

087fe4:   FE04        ADDB         SP, #4
087fe5:   A842        MOVL         *-SP[2], XAR4

I can see that the SP is at 0xBF3C and is trying to load XAR4 into 0xBF3A and it successfully does this. In this working configuration I would have also thought the SP was out of range but it works. So I'm not sure I fully understand how the stack and SP work.

But yeah I'll go look at how to add the watchpoint and update you what I find.

Thanks for all your help so far!

In this case, probably, the space right after stack is empty, and that is why it is not crashing even if overflow occurs.

In your function, you may have lot of variables on stack. You may want to put them in global space to minimize the stack use.

Adding "_STACK_END" as a hardware watchpoint, I don't see the program ever halted on it before it crashes. But your theory does make sense since the RAMM only goes up to 0x800 and the SP is at 0x960 which is larger then RAMM compared to RAMD case where the out-of-range SP is still within the total memory of RAMD. Thank again for all your help.

Brandon,

As the SP is at 0x0960, so it is crossing the stack boundary. May be something wrong in watchpoint setup. You can also try to watch the memory in 'memory browser' to see if it is changing.