MCU-PLUS-SDK-AM243X: RTI_DWWD no non-maskable interrupt?

Hello Felix,

I understand your concern and will provide an answer in one or two days.

Regards,

S.Anil.

Felix Heil said:

we are using the RTI DWWD in our application. I once learned that a POR-reset is not possible with this Watchdog on the AM243X. But a NMI should be possible.

Hello Felix,

Actually, with the help of the ESM module, we can do the SOC Warm Reset.

For this application, I created an FAQ on this topic.

Please go through it and it can be helpful.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1283237/faq-am64x-am62x-how-to-reset-the-soc-when-wdt-timer-expires-in-am64x-and-am62x?tisearch=e2e-sitesearch&keymatch=faq%3Atrue

Felix Heil said:

We noticed that indeed an interrupt occurs when the time-window is expiring but now we also noticed as soon as someone calls HwiP_disable() this also disables the Watchdog-interrupt.

My understanding is the same .WATCH DOG interrupt is NMI. Even if you disable all interrupts your watchdog interrupt should trigger.

I need to confirm at my side and let you know.

Regards,

S.Anil.

Hello Felix,

I am able to reproduce  the issue and found that, as of now, on the SOC, these NMI masks normally acts normally interrupts .

In the register below there is the 15th bit, by default this bit is zero. If you set  this bit 1 to enable NMI and see still facing the same issue or not.

Make sure that you change only the 15th else it will update other settings values of R5F core.

Regards,

S.Anil.

Hey Swargam,

So I tried setting the bit as you can see here:

I did set it like this:

CSL_REG32_FINS(CSL_MAIN_SEC_MMR0_CFG0_BASE + CSL_MAIN_SEC_MMR_CFG0_CLSTR0_CORE0_CFG, MAIN_SEC_MMR_CFG0_CLSTR0_CORE0_CFG_NMFI_EN, CSL_MAIN_SEC_MMR_CFG0_CLSTR0_CORE0_CFG_NMFI_EN_MAX);

anyway the interrupt does not occur unfortunately.

Hey Anil,

this is a bit crazy but it seems to work, just not as intended. It now throws an interrupt directly after the watchdog is started (so, right after calling Watchdog_open). This wasn't the behaviour normally. Anyway I removed our restart callback to monitor if the following normally expected interrupt occurs and yes. After expiration of the watchdog-window an interrupt is thrown as expected.
So overall we have two interrupts now with the first one being unexpected directly after starting the watchdog. Is this related to the FIQ?
Also those changes can be integrated easily by us, since we wrote our own Watchdog-Drivers above the SDK-API without SysCfg.

We just need to prevent that initial interrupt.
I also cleared the interrupt before creating it like this:

but that didn't help.

Felix Heil said:

So overall we have two interrupts now with the first one being unexpected directly after starting the watchdog. Is this related to the FIQ?

Hello Felix,

The above results are not as expected. I am assume that this interrupt comes after the watchdog expires only.

So, how are you loading the example from CCS ?

Just doing the CPU  reset from CCS  and loading the example bin file ?

You do one more testing  for every time while loading an example bin from CCS do POR  and load the example bin file from CCS and see you still have the interrupt after the Watchdog started.

Regards,

S.Anil.

Ok!

I did and it seems that this is really related to the previous state. You were right. Doing a POR and the interrupt does not pop up directly.
I would consider this working now, I can implement those changes into our WatchdogDriver and this should do it. Thank you! :)

Hello Felix,

Thanks for confirming results .

Even if you configure the watchdog interrupt as  FIQ and not setting up the 15th bit of the CTRLMMR_SEC_CLSTR0 Register will work for you.

Since ,  we disable only the IRQ's and not the FIQ's in entire MCU+SDK .

So, even if you configure a watchdog interrupt as FIQ, it should work.

I am not sure whether we can control the CTRLMMR_SEC_CLSTR0 Register to enable NMI interrupts.

I will get clarification from our internal Team and let you know.

Regards,

S.Anil.