TI RM48 DWD How to use it question

Hi Kenneth,

I don't think that you can slow the DWD down to 10s without also significantly slowing down the device clock frequency.

The formula for the timeout is:

So your value 100000000 is out of range anyway.  2^13=8192 guess whoever wrote the TRM likes people to do math..

((4095 + 1) x 8192)  /  (90,000,000)  comes out to about 0.37s max.

The % is the window percentage,  with the window watchdog it is possible to service both too early and too late.
But increasing the % doesn't change the maximum timeout.

If you just want an NMI at 10s intevals with the ability to 'reset' them --  you could use one of the RTI comparators for this.

There are 2 different RTI counters - so if you use the 1st counter for your OS and the 2nd counter for a timeout interrupt

you would get some independence against the OS.    And you could get the range you want on the timeout.

To get NMI - just map the compare to the FIQ interrupt and enable the FIQ interrupt globally.

The OS - if it reprograms the VIM, could still wind up disabling your RTI compare in the VIM so any OS code you have that updates VIM you need to scrutinize.

Hi Anthony,

Thank you for your response. I certainly appreciate it.

Now I understand and I am using COMPARATOR 0 and COUNTER_BLOCK 0 which tie to my interrupt vector 2 of the VIM table.

The OS took over control of this interrupt vector #2 and it gets triggered every 100ms to be sure I have plenty of time to service the DWD max time window for any violation.

I use both options the "Generate_NMI", and "Generate_Reset" for this and this is what I notice:

1. For the "Generate_Reset" option, the system always resets no matter what I do when and after I call the

dwdCounterEnable();

and I can not find any API function to be used inside my 100ms interrupt vector #2 to reset and re-enable the DWD counter to start recount again. At least I don't have any evidence that the DWD time window has been cleared for the system not to reset inside my 100ms interrupt vector #2. To test this code running or not, I make a while(1); loop running inside the OS and I notice this interrupt vector #2 does not get executed at all. So in that case, how do I verify if the DWD time window of watching get violated even if I have code inside this interrupt vector #2?

2. For the "Generate_NMI" option, you mentioned that I need to tie my COMPARATOR 0 to the NMI so that it will be invoked when the DWD time window get violated? Please provide instructions and steps how to tie this altogether and to verify the NMI interrupt vector or what ??? to be executed if the DWD time window get violated? How do I reset the DWD counter again in this case to re-enable the counter again?

Thank you much for your advice.

Kenneth Lai

Biolase, Inc.

Hi Kenneth,

It is pretty normal for the OS to take over Comparator 0 and Counter 0.

I would suggest Comparator 3 and Counter 1 for your timeout.

1) I don't see an API either but you don't really need a function, just write to the WDKEY register.

2) My suggestion is to not use the DWD at all. You can make the Comparator 3 generate an NMI by mapping it's request to FIQ level in the VIM screen.

3) to 'pet' the compare3 'watchdog' of sorts, just write increasing values to RTICOMP3 directly rather than to RTIUDCP3

Hi Anthony,

Thanks for your help.

I now am able to setup and configure the Comparator 3 and 4 and map those to the proper FIQs and see they are running regularly at 200ms.

My next test would be to verify that these interrupt routine still triggered and running even when the OS goes while.

To test that hypothesis, I would do a while(1); loop in the OS and see if those interrupt still running.

I have the test code to dump out the counter value of these interrupts via serial port. But when I am in the while(1); loop of the OS, I cannot see these counter values displayed via the debug terminal at all and you already know the reason why.

My question is what I should do in my interrupt routine, for ex. beeping, or LED flashing so that I know these interrupt routines still running when the OS is in the while(1); loop.

I am not sure beeping or LED flashing will work because I also see the OS control these facility in the OS code and I am worry using these facility to confirm the interrupt routine is still running may not be a good idea.

I am seeking out for your expertise to let me know which facility and signal of the TI RM48 I should use to guarantee that is outside of the OS control and I can verify that these interrupt routines are still running periodically even when the OS is in the while(1); loop.

Thanks in advance for your help!

Sincerely,

Kenneth Lai

Biolase, Inc.

Hi Kenneth,

I think that's a complex enough question you should probably check with your OS vendor.
We can't tell you which interrupts are going to the OS and which are bypassing.
You might be able to get an idea by looking at the VIM RAM and seeing where the IRQ dispatches go.
Also even check if the vectored interrupt mode is used or if the IRQ's are set to branch to 0x18 for software vectoring.
If I remember right the OS you are using may do the latter...

Also there's a difference between just checking that the OS is interrupting and making sure that the tasks are executing in the correct order. For example, if the OS is up and running but one of your tasks 'dies' somehow - are you going to detect this with your watchdog scheme? To do so you would need to implement some sort of checkpointing to make sure that the watchdog key isn't serviced if one of the critical tasks isn't run. This would be another good discussion to have with the OS vendor... what is their recommendation to add diagnostics to the OS...

Best Regards,
Anthony