We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
Since FX2 does not have a watchdog timer, I am trying to simulate watchdog behavior using Timer 2 on chip.
The timer setup seems to be functional, but when I try to execute longjmp(), FX2 dies. Any future access to the chip will hang. In the debugger, when I try to execute longjmp(), I will loose the debug connection. Thee only way to get it back is to reset USB.
Is this because of longjmp() or some other thing that I don't know. If it is not appropriate to use longjmp, how can I simulate the watchdog behavior so that lockup in 8051 can be prevented.
Any comments are welcome,
Thanks,
zhongsheng
here is the pseudo code I am using:
void main() { // ReEnumeration setjmp(jmp_buf); // Hardware setup // Initialization while (1) { // interrupt handling } }
void ISR_Timer2 interrupt 5 { TR2 = 0; TF2 = 0; longjmp(jmp_buf, 3); }
"...wrapped in pink cotton..."
Erik,
I've seen you mention this phrase a number of times now.
Is it an indication of some strange unconscious desire or fetish?
I'll have to consult my collection of Sigmund Freud publications to see whether it explains your egotistical posts.
I have tested my implementation. It seems to be working in terms of continuing execution after longjmp().
However, I have found two more problems:
1. the code works if there is no debugger. If I have Keil monitor loaded and run the code within Keil Debugger, the debug connection may get lost.
2. The watchdog timer interrupt has high priority. Its nature priority (6) is also higher than USBINT (8). However, the high priority ISR does not pre-empt the lower ISR in this case. When I try to simulate a timeout situation by holding the peripheral device in stop mode while USBINT ISR is trying to access the peripheral device, the watchdog timer interrupt ISR will not run after timeout period (4 sec). The watchdog timer ISR will run when I let the peripheral device to go.
Any comments on that?
1) the IE priority which allow an interrupt to interrupt another. 2) the "simultaneous event priority", I qoute "the bible" (my emphasis) If requests of the same [IE} priority level are received simultaneously, an internal polling sequence determines which request is serviced. Thus within each priority level there is a second priority structure determined by the polling sequence.
Erik
I think I know what you are saying.
WatchDog Timer interrupt (Timer 2, 0x002B): Assigned Priority: High Nature Priority: 6
USB Interrupt (0x0043): Assigned Priority: Low Nature Priority: 8
Apparently, Timer 2 interrupt has higher priority than USB interrupt in both assigned and nature priority level. However, I just don't understand why Timer 2 ISR was not invoked when Timer out condition has been reached. I assume Timer 2 count should continue even the firmware is hung.
is that they can be turned off by simple means.
In my opinion no watchdog that can be turned off by simple means qualify as a watchdog, simply because runaway code easily can effect the turnoff.
turned off by simple means: e.g. clearing a bit or byte - in your case e.g. IE or EA or ET2. turned off and still be a watchdog: e.g. a requirement if two specific consequtive writes.