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.

TMS320F28379D: Interrupt Service Routine Context Save

Part Number: TMS320F28379D


Tool/software:

Good morning

This might end up being more appropriate for the compiler forum, but let's start here. I am doing some analysis on the context save which happens upon entering an interrupt service routine written in C and referencing a value on the stack.

What I have found is that the context save which is done by the C28x seemingly varies depending on the contents of the ISR. I have spent a fair amount of time reading about the context save and restores in the assembly manual, but I haven't found anything specific to this in the context of when executing the ISR in C.

Here are two examples of the disassembly:

The first is a very short version of a watchdog ISR which basically reads a value off of the stack, checks if it should reset the CPU, and acknowledges the interrupt flag.

The next is the same ISR, but now it is writing out values to flash (a complex operation on the C28x). The disassembly leading up to the first coded ISR instructions (MOVL ACC, *-SP[28]) is significantly different and changes the stack quite a bit.

The issue I am trying to solve is referencing a value on the stack from the automatic context save, but depending on the contents of the ISR the stack position seems to be changing. I have a few questions:

1) What triggers the more in-depth context save that seems to be happening in the second ISR?

2) Is there a way to detect what kind of context save was done? My thought was by looking at the program counter value immediately upon entering the ISR- is there a way to tell the offset of the program counter from the address of the interrupt?

3) Is the best way to control this to declare the interrupt in assembly?

Open to other suggestions and thoughts as well.

Thanks!

Kris

  • Hi Kris,

    I believe the difference you are seeing here is that more registers are being used inside the ISR instructions in the second case, so more registers need their states saved initially since they will get modified by the ISR execution. The compiler is smart enough not to simply push all registers to the stack, if certain registers aren't used in the ISR they don't need to have their state pushed to the stack. 

    The methods you've mentioned should work, however can you help me understand your use case more so I may give suggestions. Why exactly are you trying to access a specific value on the stack? 

    Best Regards,

    Delaney

  • Hi Delaney,

    Thank you for your response. I agree with your assessment of what is happening. The question is if it will be consistent. If more code is added to the ISR, will there be more registers to context save (and hence further changing the stack) or is this the maximum? I suspect it may be the maximum because of the complexity of the flash write.

    The goal of this application is to identify the program counter value in the application code before the watchdog ISR was triggered to be able to debug where the unexpected operation may have occurred.

    Thanks,

    Kris

  • Hi Kris,

    I apologize for my delayed response. I don't believe the second case you have shown would be the maximum since there are still more CPU core registers missing here that could get pushed onto the stack if they are used. Also see the thread here discussing the topic.

    If you are trying to access the PC inside ISR code, your best bet may be to write the ISR in assembly so you can capture the value immediately upon entering the ISR. Let me loop in the compiler team to see if they have any other suggestions though.

    Best Regards,

    Delaney

  • I suspect it may be the maximum because of the complexity of the flash write.

    That is correct, but the explanation is incomplete.  When an interrupt function contains a call to another function, the compiler makes the worst case assumption that the called function changes all the registers.  Thus, it preserves all the registers on the stack.

    Thanks and regards,

    -George

  • Delaney, George,

    Thanks for the replies.

    George, based on your reply, does this indicate that the stack pointer should have a reliable offset to the program counter for any further additions to the ISR? Essentially, if any function is called from the ISR, then the stack pointer will be in the same place relative to the context save for the PC?

    Or is it still better to update this to be in assembly?

    Thanks,

    Kris

  • Hi Kris,

    I am looping in the Watchdog expert to see if they have any recommendations or example code to offer for your application. I will try to get a clarification from George on his response as well for you.

    Best Regards,

    Delaney

  • Hi Kris,

    Good to see your post :-)

    We do not have any example on this exact usage. 

    Essentially, if any function is called from the ISR, then the stack pointer will be in the same place relative to the context save for the PC?

    Will wait for George to reply this.

    Regards,

    Vivek Singh

  • if any function is called from the ISR, then the stack pointer will be in the same place relative to the context save for the PC?

    That is correct.  

    But is it correct to presume that, just because a C function calls another function, the compiler generated code must call that function?  No.  The compiler may inline the function.  

    is it still better to update this to be in assembly?

    It's more reliable.

    Thanks and regards,

    -George

  • Great, thanks everyone!