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.
A strange situation where an internal watchdog reset implementation seems not to work on the 87c520 target while it does work ok when using the Ceibo ICE. Seems like the reset occurs but unclear where the PC jumps to because the SW does not restart properly but rather stays "stuck" (we know it enters the if (status) passage). With the ICE the program does start ok. What we do is enable the watchdog timer in the program. In the interrupt handler (ISR 12) depending on some status, we enable the reset itself. All this occurs, but then for the target the program does not go into running normally. Any ideas? Thanks, Baruch if ( status ) // { TA = 0xAA ; //Accessing timed access in order to start the watchdog timer TA = 0x55 ; // EWT = 1 ; // Enable WatchDog timer reset TA = 0xAA; //Accessing timed access in order to start the watchdog timer TA = 0x55; // WDIF = 0 ; // watch dog flag clear } else { TA = 0xAA; //Accessing timed access in order to start the watchdog timer TA = 0x55; // WDIF = 0 ; // watch dog flag clear TA = 0xAA ; //Accessing timed access in order to start the watchdog timer TA = 0x55 ; // RWT = 1 ; // Restart Watchdog timer }
Thanks. We were happy for few moments till tested - doesn;t work yet. Also read the Erratas. Our version is A15. Its Errata does not include this problem. Still we have just tried the dead loop as well as inserting LCall at address 0, but no success yet.
I am sure you want to hear the next chapter. We are in the process of tracing it down as follows. In our applicaiton, first the EPROM code is executed. It takes a "little" time to complete. Then it loads and turns to the flash. When a WD expires in the flash code and the reset is enabled and occurs, the app jumps to the EPROM start point. But then it gets stuck, because as we believe, the EWT or equivalent remains enabled and the WDCON timer is switched to its minimal value, so that a WD reset is continuosly triggered inside the EPROM code. At the moment there is no EWT reset/disable in the beginning of the EPROM code. There is also no WD interrupt handler there. A quote: "If the device contains internal program memory, the default power-on reset state of EWT is determined by the Watchdog Default POR State bit (WDPOR) located in the System Control Byte or a mask option. This bit is unaffected by all other resets." Assuming that the last sentence in the quote ("This bit...") refers to the EWT bit, not the WDPOR bit which the whole paragraphs speaks about, then this conforms the cause. We are now trying to comfirm that this is the case. So assuming we confirm this, my next question is- after such WD reset, can the app be forced to jump to the flash 0 and run from there rather than to the EPROM 0? We know of the 87c520 pin that allows control over that, but the question is how to do that by SW only. I believe the ROMSIZE gets reseted too and can;t be used for this purpose. Thanks, Baruch
Hi, yes, any reset (either watchdog or external RES pin) set SFRs to their default values except POR flag(s). Why do you just not control this flag at first program steps? For example: at first codes just check POR value: - if POR=1 then it is first power-on: you do configure flash, make POR=0 by software and wait till watchdog resets MCU; - if it is =0 then you make on-chip ROM size equ 0 kb and next instructuon will be fetched from external flash. It is simple. Good days!
Of course. The normal resolution would be to handle the POR and/or the WTRF (WDCON.2) for the watchdog reset flag at the beginning of the EPROM code. For various practical reasons we would have liked to avoid modifying the EPROM code, but it seems that we will have to take this course. Thanks again, Baruch