• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1424 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.

RM44L920: How does the RTI digital windowed watchdog reaction control work when the NMI option is used?

Chris Beliveau
Prodigy 115 points
Part Number: RM44L920
Other Parts Discussed in Thread: HALCOGEN,

The Halcogen RTI.c module has the function dwwdInit( Generate_Reset, preload value, Windowsize) that will reset the CPU when a watchdog reset occurs after the preload value time.

I have used the Generate_NMI parameter to vector off to an esmNotification function on the TMS570 processor that can be used to pull off the PC of where the application was when the WDT expired.

But on the RM44L920 processor, the Generate_NMI parameter appears to disable the watchdog entirely, in the sense that it does not vector out to anything when it expires.   The RTI Watchdog status register does indicate that the watchdog has expired.   I have a spin loop that never exits in this case. 

How does this "Generate_NMI" parameter work to force an NMI interrupt on the RM44?   

  • 0
    TI__Mastermind 21425 points
    Hello Chris,
    In HALCoGen example folder (..\Hercules\HALCoGen\v04.07.00\examples\RM44x\) you can find example of using DWDD (example_dwwd.c).

    See if this example is helpful for you.

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 115 points
    Thank you. I did not enable the notification, now I'm getting the NMI I expected.
  • 0 in reply to Chris Beliveau
    Prodigy 115 points
    Hi again,

    This kind of works, but now exactly as I wanted. I am NOT getting the NMI I expected when I use Generate_NMI in dwwdInit.
    By using the sample code, I was able to get the RTI Compare0 interrupt to go off, I can check the status of the WD I guess and reset the CPU if I need to. But on the 570, I get a true NMI, which gets me to my esmNotification function without involving the RTI Compare0 interrupt.

    I know the group is not going to like me using the RTI Compare0 interrupt for this feature. On the TMS570 this NMI works, I've looked at the esm, startup and rti Halcogen code and I've substituted the 570 functions into the RM44 code without success.

    I'm not ready to close this out yet.
  • 0 in reply to Chris Beliveau
    TI__Mastermind 21425 points
    Hello Chris,
    In this example rtiNotification is to service DWD (to reset DWD with dwdReset()). If this not happens ( when RTIDWDKEY register is not written with appropriate values) then DWD generates NMI/Reset.

    The DWWD NMI is assigned to ESM Group 2 channel 24. When this channel is active this will generate NMI. CSPR bit F has to be cleared for FIQ/NMI to be activated.

    Best regards,
    Miro
  • 0 in reply to Miro
    Prodigy 115 points
    Thank you Miro, I'll look into ESM group 2 today and let you know. I have code on the TMS570 processor that works, so I have an example of this working. I need to make it work on the RM44 and the RM46 microcontrollers.
  • 0 in reply to Chris Beliveau
    Prodigy 115 points
    Hi again Miro, I found out why the CPSR bit F flag was not being cleared when the watchdog NMI was processed. In the TMS570, the Halcogen file sci.c - InitSCI made a pair of _disableInterrupt_/_enableInterrupt_(). This was removed in Halcogen version 4.06, so my RM44 project never enabled this CPSR flag. I was able to clear this bit and eventually got the NMI as expected.

    HOWEVER - The nmi vector at 0x1C has the code ldr pc,[pc,#-0x1b0]. On the TMS570 this would jump to my bootloader application where I could pull out the PC and create a stack dump that I write to flash. The function is esmHighInterrupt, which then calls my custom esmSiemensNotification. This works great on the 570 project, but the RM44 jump now goes to my APPLICATION's version of esmHighInterrupt. This would not call my notification function, and even if it did, our applications do not contain the flash library to store this to flash memory and other features that my bootloader application contains.

    I was able to solve this by replacing the ldr instruction with a direct branch to my function - ie b esmHighInterrupt. This now goes to the intended routine and things are back to normal. But my managers want to know why the RM44 is different than the 570 in this respect. I found this FIQVECREG containing the wrong value at the time the code is downloaded. This is not something that I can do on startup, when it loads it is already broken. There is something in the linker command file that must be doing this.

    Also, what is the intention of the line - ldr pc,[pc,#-0x1b0]. Is it intended to branch to the application's NMI handler or the application that is currently loaded, in my case my resident bootloader.

    You have been more than helpful, my work is actually done, but people want to know why this works....