• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 388 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.

TMS320F28379D: Watchdog on CPU2 and NMI on CPU1

vincent liebart
Intellectual 600 points

Part Number: TMS320F28379D

Tool/software:

Hello,

I need advice on the watchdog management.

On the both CPU of the microcontroller, I configured a watchdog with causes a PIE interrupt (WAKE)

In the associated ISR:

- I write something in the FLASH of the CPU

- I switch the mode of the Watchdog to RESET_MODE

- I ask for a watchdog reset thanks to the driverlib function SysCtl_resetDevice(). This function actually put something incorrect in the watchdog register, and that causes a Watchdog event (that's the reason why I set this event as "RESET")

When a blocking tasks comes in the CPU1, everything is fine: the both cores reset.

When a blocking tasks comes in the CPU2, I expected that:

- the CPU2 reset and wait for the IPC_sync to continue its programm

- the CPU1 watchdog arrives (since CPU1 transmitts many data to CPU and wait for acknowledgments) and asks for a CPU1 reset

- CPU1 and CPU2 reset (second times for CPU2)

- The whole programm run as the first time

But sometimes, in emulation mode, when watchdog on CPU2 appears, the CPU1 bocks in this function:

I saw in the reference manual that the CPU2 watchdog reset causes the NMI. So, I have a lot a questions:

1) the NMI handler is defined in the driverlib files. If I have to manage the NMI, how can I do it, since I "cannot" modify the driverlib files ?

2) I notice that I do not enter in this handler each time I cause a CPU2 watchdog event. How is it possible ? (in my application, I enter in this handler only if a CPU1 Watchdog appeared before)

3) I run my project in the Stand Alone mode, the programm does not enter in the infinite loop. Everything seems to be OK. Is it possible that the nmi is due to something else (Clock Fail, Error ...) that only appears in emulation mode

4) I read in the reference manual that we must not change the Watchdog mode while the signal WDINT is active (512 SYSCLK). But I do change it. Should I wait before to do this ? Is it really useful to do it to make the watchdog event cause a reset ?

5) Finally, in my application, would it be not more safety to block the CPU2 programm if the watchdog appears ? (that will cause a watchdog on CPU1, due to the application)

Thank you for your advice. I tried to be general and clear.

Vincent.

  • 0
    Intellectual 600 points

    Hello,

    Since I write the first message I did some test.

    First, I managed the content of the NMI ISR by changing the adress of the corresponding interrupt in the table:

    Interrupt_register(INT_NMI, &INT_MyNMI_ISR);

    I checked that a reset of the CPU, due to its watchdog, was the source of this entry into the ISR.

    But I still wondering why this CPU2 WatchDog makes the programm entering into this ISR although I didn't enable the NMI interrupt.

    I a second time I did enable this interruption by using SysCtl_enableNMIGlobalInterrupt();

    Doing this, it seems that the programm enters into the ISR, but also that there is a NMIWatchdog reset. Am I wrong ? Also, It seems that this reset gets before ESTOP0; Is that possible ?

    Thank you for your help.

  • +1 in reply to vincent liebart
    TI__Mastermind 18316 points

    Hi,

    For NMI, please find the below info : 

    Each CPU has its own NMI module. An incoming NMI sets a status bit in the NMIFLG register and starts the NMI watchdog counter. This counter is clocked by the SYSCLK, and if it reaches the value in the NMIWDPRD register, it triggers an NMI watchdog reset (NMIWDRS). To prevent this, the NMI handler must clear the flag bit using the NMIFLGCLR register. Once all flag bits are clear, the NMIINT bit in the NMIFLG register may also be cleared to allow future NMIs to be taken. The NMI module is enabled by the boot ROM during the startup process. To respond to NMIs, an NMI handler vector must be written to the PIE vector table.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Intellectual 600 points

    hello Pratthan. Very clear. Thank you