• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 442 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069M: Illegal ISR faults triggered by trivial changes in code

Liam MacDonald
Prodigy 30 points
Part Number: TMS320F28069M
Other Parts Discussed in Thread: MOTORWARE

I'm running into an Illegal ISR fault when I add comments to the code and change a the names of variables. I'm confused how nearly identical code can be triggering a code. From looking on this board I haven't been able to find any answers to the this problem.

I'm running a motorware application similar to lab 13b from the instaspin labs tutorial pdf.

I'm using the SCI B interrupt functionality and the timer0 interrupt functionality.

  • 0
    TI__Genius 11076 points

    Hello,

    To help me track down what's causing this, I have a couple questions.

    1. What variables are you changing the name of?
    2. Where are the comments you're adding (i.e. what file)?
    3. Have you had the opportunity to review the ITRAP FAQ? Link.

    Regards,
    Jason Osborn

  • 0
    Prodigy 30 points

    I have a folder of my own application code that I named source. In there I have a file named motor-commands.c that I use to execute motor movements. I added function headers to this file. 

    I changed the name of a flag variable that I use to signal that a complete move has been executed. 

    I've reviewed the ITRAP FAQ. I checked the stack for overflows and I never experienced any.

    The illegal ISR seems to be triggered shortly after I trigger a move command from the timer0ISR.

  • 0 in reply to Liam MacDonald
    TI__Genius 11076 points

    Ah, I see. Thank you for clarifying the structure you're using.

    • To be clear, is the ITRAP only triggering if the comment and the the variable's name has been changed, or is it either/or?
    • Have both the timer0ISR and the SCI interrupt been properly registered with the PIE?
    • What is the return address while you're in the ISR? Is it the same place every time?

    It may also be useful to perform a clean build and/or generate a new or temporary workspace, import the project there, and see if the issue persists, just to make sure everything's fine on the compiler's side.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 30 points

    Okay I did a clean build and made a new workspace and neither worked, which is okay because it would be a cheap solution.

    I haven't checked each individually, but I will do so.

    I'm pretty sure the the interrupts are all registered correctly, since they've been working as expected up to this point. I'll show below:

  • 0 in reply to Liam MacDonald
    TI__Genius 11076 points

    I figured the workspace/clean build would likely not work- it's important to check periodically, though!

    For the interrupts, I notice two things. First, CPU_IntNumber_1 is being used for both the timer interrupt and the ADC interrupt. Is this deliberate? Second, I see a warning in the timer interrupt. What is that warning?

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 30 points

    I found my problem and it was all my fault. I made my own custom function for converting a double to a string to print to the command line. I was overflowing the buffer which was overwriting the link register that gets pushed onto the stack during a function call. 

    Thank you for your help, I learned a valuable lesson in unit testing lol