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.

TMS320F280049: NMI and Trip events

Part Number: TMS320F280049

Hello support,

I add some details to the question that Carlo has entered on behalf on me.

I know that NMI can have several sources

1. TRIP event to PWM is generated only in case of missing clock (as explained in the manual fig 18-84 - TZ5) or in case of RAM ECC / FLASH ECC a TRIP event is issued, too?

2. How long does the TZ5 last ?

   What is the action that reset TZ5 ? is it the erasing of CLOCKFAIL flag in NMIFLG or it is also necessary to erase NMIINT in same register, or other ?

3. in manual “instruction set “   I can see : "As part of its operation, the illegal-instruction trap saves the return address on the stack"

So in case of ITRAP interrupt, which is the instruction executed when leaving interrupt routine? Is it the illegal one ?

If so, what is the more appropriate reaction to an Illegal Instruction TRAP ? Generating a RESET or are there different ways to manage it ?

Thanks

  • Part Number: TMS320F280049

    HI everybody , 

    NMI : Testing Missing clock using MCDC.OSCOFF.

    On ref manual   in case missing clock   "The CLOCKFAIL signal goes high, which generates trip events to the PWM modules and triggers an NMI."

     Now I can see NMI function starts OK and some questions:

    1 TRIP event generated is Only when you have a missing clock   ( maual fig 18-84 )  --> TZ5 ?

    2 how long is TZ5 ? I mean when it is resetted , the event resetting  it ?

                  -is it  erasing CLOCKFAIL flag in NMIFLG or you need to erase *** NMIINT in same register ?

    3 in case I got another NMI ( like by RAM , ECC , FLASH ) or in ITRAP case : are there Trip relates event too ?

    4 in manual “instruction set “   I can see : "As part of its operation, the illegal-instruction trap saves the return address on the stack"

    So in case Itrap interrupt which is instruction executed exiting interrupt ?   the illegal one ?

    thank you 

    BR

    Carlo

  • Hi Carlo - We are evaluating your request, will get back to you with more details in a day or two.

    Best Regards,

    Nirav

  • Hi Davide,

    Thanks for your question! I will answer regarding the ITRAP instruction, and allow one of my colleagues to answer regarding the EPWM TZ questions.

    If I understand your question correctly, then the ITRAP will store the return address, but the actual code that is executed next is the PC + 1. This is seen in the CPU user guide, in the following subsection: "CPU interrupts and Reset" -> "Nonmaskable Interrupts" -> "TRAP Instruction".

    Regards,

    Vince

  • How long you would like the TZ5/TZ6 to last? you can always have the TZ source cause a ONE-SHOT disable forever PWM signal which can be cleared by SW when needed.

    Or you can use cycle by cycle to have it get re-enabled when needed.

    You can also have it configured as the source for the DCA/B events which will disable EPWM for the duration the TZ is active.

    Nima

  • For questions on how long the pulse actually is on TZ5/6 in the event of CLOCKFAIL or EMUSTOP, I'm not sure they come from the NMI module.

    But if you use the DCA/B to pull a PWM low when the signal is active, you can actually see it on your scope, I'm guessing they are one-pulse signals.

    Nima

  • Hi Carlo,

    I believe this is a duplicate of the following thread:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/978489/3616141#3616141

    If you have any separate questions from the linked thread, please reply and I will answer those separately here!

    Regards,

    Vince

  • HI Vince , 

    thank you for your message  , yes we are working on same TZ5 .

    please one still open question :

    . How long does the TZ5 last ?

       What is the action that reset TZ5 ? is it the erasing of CLOCKFAIL flag in NMIFLG or it is also necessary to erase NMIINT in same register, or other ?

    we saw the reply but not totally understood the reply   ,    does the procedure to reenable it from NMI or something else  ?   coudl you elaborate this point   ?

    BR

    Carlo

  • Hi Carlo,

    Please expect delayed response due to inclimate weather.

    We will merge this thread with the above mentioned thread, as these questions are referencing follow-ups in that thread.

    Regards,

    Vince

  • The raw TZ5 signal is coming from the NMI module, you will need to clear the CLOCKFAIL NMIFLG to clear this. IF the clock fail still exists it will retrigger and get set again.

    As far as how long it lasts, I'm not sure.  and  can you check the NMI specification to let us know what type of signal this is? Is it going to stay high until cleared or is it a PULSE?

    Nima

  • Hello

    thank you for the reply.

    What I have seen is that in any cases clearing the CLOCKFAIL NMIFLG is necessary to stop WDI timer and prevent a reset.

    Clearing NMIIINT is not strictly necessary to stop WDI timer, only to enable NMI again.

    It is important to me to know how long TZ5 stays active (and if the time is linked to CLOCKFAIL NMIFLG) because my idea in case of missing clock is:

    having an immediate automatic CPU reaction with PWMs trip, and a slower software reaction that enables pwm again only in case some conditions are fulfilled, and I was thinking to re-enable pwms by clearing CLOCKFAIL NMIFLG.

  • You have to clear the NMIFLG bit to stop the WD timer and to clear NMIFLG you must not have the error condition active. NMIINT is just a status flag for NMI pulse to CPU. 

    Same is the case for TZ5 . You need to clear the flag.

    Regards,

    Vivek Singh

  • To add onto Vivek's answer and Nima's question:

    Given that TZ5 is directly from the NMI module and CLOCKFAIL latches during failure, CLOCKFAIL must be cleared to re-enable PWMs. So the time is indeed linked to time-to-clear on the CLOCKFAIL flag.

    The exact amount of time this will take varies from application-to-application and function-to-function, because this becomes dependent on the ISR entry time, which can depend on: code/stack in wait-stated memory, multiple-cycle instructions, qualification of sources from external interrupt, status of INTM (in nested interrupts), RPT instructions, etc.

    But the idea you mentioned on having a slower software reaction seems feasible. Make sure to keep in mind what Vivek mentioned on NMI WD.

    Regards,

    Vince