• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 252 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28035: Illegal ISR caused by strange behavior of stack pointer while debugging

Román Comelli
Intellectual 545 points
Part Number: TMS320F28035

Hi!

I have been struggling with an illegal ISR for a while and I wanted to share you this video that shows the problem. In case it cannot be seen correctly, the video is also here: https://drive.google.com/file/d/1rX0kygYc1MXHPwYEFBxCzWVOHgbzQZai/view?usp=share_link.

Luckily, it seems to disappear when the program runs normally, i.e. without the step-by-step execution used while debugging, but it is really strange and I would like to know if you have an idea of what could be going on here (I want to avoid future problems). The issue is that the stack gets corrupted so at certain point, while returning from nested functions, the RPC is loaded with some data value instead of a legal program address and everything stops working. The reason for this, apparently, is an assembly instruction that is not executed at all: ADDB SP, #8. This is shown in the video, the SP does not change after that instruction and so, at the end, the illegal ISR is serviced. After that, the video shows that when the program is executed continuously up to the same part, the same instruction does what it is supposed to do and the illegal ISR problem does not occur. I can privately share the code with you (TI staff) if you need it.

Any idea?

Thank you in advance!

  • 0
    TI__Guru* 95315 points

    Roman,

       Our ability to debug application-specific scenarios like this is extremely limited. If an issue is seen only during single-stepping and not while free-running the application, it is likely that there is some timing marginality.

  • 0 in reply to Hareesh Janakiraman
    Intellectual 545 points

    Could you further explain what you mean by timing marginality? What I can think of wouldn't have something to do with the fact that an assembly instruction is apparently not executed.

    I understand the limitations. Wouldn't it be useful if I sent you the code somehow (in private mode)?

    Thank you!

  • 0 in reply to Román Comelli
    TI__Guru* 95315 points

    The application behavior is different during single-stepping compared to free-running. Depending on how the peripherals are configured, it is possible for a peripheral to be running even during a debug stop. Therefore, the synchronization among peripherals (interdependency) is disturbed. 

    Suggest you check the erratum titled “Memory: Prefetching Beyond Valid Boundary”. What you show in the video isn’t end of memory but it is best to check since it can yield an invalid fetch. Also make sure the register window is updating and we aren’t being misled. It does seem like that instruction isn’t doing anything but best to check.

    Román Comelli said:
    Wouldn't it be useful if I sent you the code somehow (in private mode)?

    Regret we are unable to support code debug.

  • 0 in reply to Hareesh Janakiraman
    Intellectual 545 points

    Ok, to be honest, I don't understand really well how there could be a problem with peripherals in that case. I thought about some sort of collision while the debugger asks for register values because the bus is being used by peripherals but I am not really sure if this could be possible. Furthermore, I was not enabling Silicon Real-Time Mode (I tried it with same results regarding the illegal ISR) so I expected no peripherals were running.

    Anyway, it is not just what is shown in the debugger. I have checked and the register window is updated automatically and, following the assembly instructions, it can be seen how returning addresses are overwritten in the stack (I mean that the SP is effectively wrong, as shown in the debugger). That is exactly the (final) reason of the illegal ISR. Actually, I have seen how the PC ends up pointing to some structure that represents an oven state in the application, wrongly taken from the stack. Moreover, I have tried to manually add the offsets that are not applied to the SP (with the non-working ADDB instructions) and the illegal ISR does not occur so there is no doubt on my side with respect to the (final) reason of the illegal ISR.

    There is something wrong that may seem to be related to the debugger operation but I don't know how. And I wanted to know, or to have a clearer idea at least, because:

    -I have to be sure that there is no other problem that will make things explode in the future.

    -I wanted to learn :).

    Totally understandable that you don't support code debugging. Thank you anyway for the clarification!

    Regards.