This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377S: Functions returning to adress 0x0000 and Stack Pointer being moved to a different location than specified in the linker

Part Number: TMS320F28377S

Hello,

After adding a for() loop on my main() function, the program suddely started being caught in ITRAP0. However, it was not being caught in the new lines added, but rather on the very first setup function executed. Looking at the disassembly, this happens after a LRETR instruction. Looking at the RPC register right before the ITRAP0, the register values was always 0x0000, meaning it was not recovering the Program Counter. After some digging, I noticed that what was happening was that the program was entering multiple functions, but could only "return" once, because after this the RPC register would always lead to 0x0000 and ITRAP0. Since the LRETR instruction should retrieve a value from the stack, I went to look there and found that no values were being written on the stack. Looking at the Stack Pointer, it was not pointing to an address specified in the linker (RAMM1, starting at 0x0400) but at values outside of the specificied, including addresses in the middle of the DMA registers. 

This code was changed from another program that works correctly, with stack in the correct addresses. Adding or removing lines of code (expanding the for() loop into direct executions, for example) only change the new address of the stack.

The Stack Pointer starts correctly, but after entering main() and before the first setup function, I found these assembly instruction modifying the stack pointer

MOVL *SP++, XAR1
MOVL *SP++, XAR2
MOVZ AR2, @SP
SUBB XAR2, #6
ADD @SP, #670

Being "#670" the number that changes when I add or remove lines of code (multiple variable attributions). In the functioning code I used to start this, the only instruction executed after entering main() but before executing the first setup function is ADDB SP, #4.

What could cause the stack to behave this way? Would assigning sectors in RAM (not in the same location as the stack) lead to this behavior?

Thanks for any help