[SOLVED] How to soft reset microcontroller?

[milan.rajik]

How to soft reset microcontroller?

I am using PIC18F46K22. I am using UART feature. Sometimes UART or microcontroller hangs. I want to know how to test if microcontroller and or UART is hanged and if hanged how to auto reset microcontroller?

 

[FvM]

In many cases, the PIC built-in watchdog feature is a good means to achieve an auto-reset.

 

[milan.rajik]

But if WDT is enabled then LCD flickers every few milli seconds.

 

[FvM]

But if WDT is enabled then LCD flickers every few milli seconds.

- Any relation between both facts?
- If you are human (I guess you are) you won't see milli second flicker.

 

[milan.rajik]

The problem is I have a 2 sec delay before entering the while(1) loop and a few more delays inside while(1) loop.

 

[ftsolutions]

If you need the WDT as part of the application, you need to review your code and consider changing it so that it is more efficient and is compatible with WDT use. Your use might be just for a personal hobby, but most decent commercial applications use a WDT. Alternatively, if you just want to use the WDT to reset the CPU directly under software control, your code can have a simple function that configures it for a very short interval, maybe 1 millisecond, and then enables it and goes into a while(1) loop. That way, you'll get the reset functionality but only when your code demands it, rather than keep the timer running always (though that would still be my preferred approach). Sometimes you have to doing things simply to start with.

 

[milan.rajik]

Please provide a sample code for PIC18F. I have to blocks in while(1) loop. All the time block A will be executing till INT0 is triggered. Once INT0 is triggered block B starts executing.

I want to enable WDT only when block A is executing in while(1) loop and disable WDT when INT0IF is set. So block A takes 5.56 ms to execute once. Block B execution takesr 1 minute when INT0IF is set.

I want to enable WDT just before entering while(1) loop and then disable WDT on INT0IF. If there was INT0IF then WDT is disabled and block B is executed once and then WDT should be enabled again so that block A starts executing after WDT resets the microcontroller.

- - - Updated - - -

The problem solved.

 

[ftsolutions]

I have not used the PIC that you are using, and they do appear to have some variability in how it is enabled. There does appear to be quite a few examples on the internet. I don't have exact code for you, but I believe that if your research the WDTEN and WDTCON registers, as well as the WDTPS it will become apparent to you. Another option could be to always run with the watchdog timer enabled, but set the pre/post scaler values so that the timer is running at its maximum period (which given the crappy RC timing of the part could vary by alot, but should be more than 90 seconds). This would be easy to maintain even in your long wait loop code. Then, when you want the reset to occur, you'll have to have the code clear the watchdog bit to cahnge the scalar register values to their minimum value (approx 18 millisecs?) and then wait for that reset.

I must admit I've not used the tiny PICs like the 18F series in a very long time, and all the other micros I've used since have had much better Watchdog timer functionality. But hopefully, this will help you/provide ideas.

 

[milan.rajik]

The problem was solved. I used Timer2 interrupt for 10 ms. The WDT was set to reset every 18 ms. Timer2 was made to clear WDT every 10 ms. So if microcontroller stucks and WDT is not cleared by timer2 and WDT resets then microcontroller resets.

I had a lot of 2 sec and 4 sec delays inside my while(1) loop and also in functions in compiled library. So, it was difficult to insert clrwdt in the program and so I used timer2 interrupt.

 

[FvM]

The problem was solved. I used Timer2 interrupt for 10 ms. The WDT was set to reset every 18 ms. Timer2 was made to clear WDT every 10 ms. So if microcontroller stucks and WDT is not cleared by timer2 and WDT resets then microcontroller resets.

You should be aware that most "stuck" problems are trivial coding faults, e.g. the code execution is caught in an endless loop. In this case, the timer interrupt can be expected to continue and the WDT will never end the condition. Means you need to add additional checks for plausible code execution to your timer interrupt, e.g. software watchdogs with longer time limits.
From a instrument controller or "real time" software point of view, it's mostly inacceptable to have long delays (e.g. > 100 ms) in the main loop. Slow actions should be executed in a state machine that returns to the main loop while waiting for a timer to expire or an external event to occur

 

[milan.rajik]

e.g. the code execution is caught in an endless loop. In this case, the timer interrupt can be expected to continue and the WDT will never end the condition

Yes, you are right. I will implement to tackle that issue.

Slow actions should be executed in a state machine that returns to the main loop while waiting for a timer to expire

The problem is the 2 to 4 seconds delays are inside the compiled library for which code is not available. The library function call pass an argument like 1, 2, 3, ... for 1, 2, 3... seconds. I can't modify the library to check for timeouts using timer.

I confirm that there is only one while(1) loop and there are also no loops where program can stuck. There are loops which wait for a certain number of attempts and then breaks if not successful.

 

[Gorgon]

It is generally not a good idea to reset the WDT in an interrupt routine. You should reset the WDT in the background program, to be sure that this is functional.

The interrupt system may still function even if the background program is crashed.

To do this you should design the program so it is 'falling through' all the time, With no hanging functions waiting for something external to happen.

 

[milan.rajik]

What is background program? The main program inside while(1) loop? When I say stuck then I am referring to microcontroller freezing. In my code there are no loops where execution can hang. The only problem I am having is microcontroller freezing due to EMI.

 

[ftsolutions]

If you do not have an RTOS with separate threads, yes, chances are high that your main() loop(s) contain the background process. General practice is that whatever is the lowest priority task, or performed after all the other tasks within a main() loop are performed, before it loops around to begin them again, is where you should have the routine to feed the watchdog. In this way, if ANY of your tasks/processes called from main() hang up, or if you end up stuck in an ISR that won't terminate or is constantly asserted, the watchdog timer should expire and you'll get the system reset.

Otherwise, your main task could become stuck and not proceed, but your ISRs might continue to function. IF you use the ISR to feed the watchdog you will never get a system reset, and your system will remain stuck for lack of getting the reset. If properly implemented, it will prevent your micro from freezing in > 95% of the possible causes. But, that doesn't free your from responsibility of architecting the code to avoid having to rely on the WDT to save the system from a badly coded function. Use state machines and implement software structures for timers to handle long delays, rather than sitting in a loop, where ever possible.

 

[milan.rajik]

The only problems I am facing is UART hangs sometimes and MCU hangs sometimes due to EMI. Now just tell me if using Timer interrupt to clear WDT works in these situations. According to me when there is an timer interrupt then PC jumps to ISR. So, if MCU is hanged due to EMI then if there is a timer interrupt which runs independently then PC has to jump to ISR but as program execution is hanged PC will not change and hence ISR will not get executed and hence WDT is not cleared and so WDT overflows and resets the micro-controller. Am I right?

 

[Gorgon]

The only problems I am facing is UART hangs sometimes and MCU hangs sometimes due to EMI. Now just tell me if using Timer interrupt to clear WDT works in these situations. According to me when there is an timer interrupt then PC jumps to ISR. So, if MCU is hanged due to EMI then if there is a timer interrupt which runs independently then PC has to jump to ISR but as program execution is hanged PC will not change and hence ISR will not get executed and hence WDT is not cleared and so WDT overflows and resets the micro-controller. Am I right?

Are You talking about a microcontroller or a PC? The PC is completely another beast, due to the OS that will take care of problems like this, or should at least.

If you on the other hand is talking about PC like in Program Counter there is more meat on the bones.
First of all, if your system is susceptible to EMI problems, or ESD for that matter, you should rethink Your hardware design, adding some decoupling capacitors, and maybe rethink/-design Your real life Interfaces.

Regardless of that, FEEDING the WDT INSIDE an ISR is BAD SW design!
From what you Write above, I think you should reread the Chapter on interupts. In Your scenario, only a disabling fault inside the timer ISR will starve the watchdog, and restart the program. A fault 'anywhere' else will keep the wachdog fed. If you compare the length of the total program vs the timer ISR, you can see for Your self the part you cover/protect by the WDT.

A small comment. I suppose you know that the program Counter is reloaded to the start of the ISR from the interrupt vector table, at every interrupt, regarless of the condition at the time of the interrupt.

 

[milan.rajik]

Yes, I meant Program Counter or Instruction pointer. When interrupt occurs then PC or IP is loaded with start of ISR address but still the micro has to execute the ISR code. If micro is frozen then either PC is not loaded with ISR address or if loaded then ISR code will not execute. So WDT is not cleared. Am I right? If yes, then it solves my problem.

My program has 2 blocks of cold. One is block A and another block B. Block A is only for LCD display and block B is for sending SMS. The system works like this. When INT0 is not detected (triggered by sensor) block A will be executing. Once INT0 is detected block A execution stops for a while and block B executes, sends SMS and then again return to execute block A.

Block B rarely executes and I have removed all delays from my code and used timer delays.

There is no chance of micro hanging due to code. All I want is if micro hangs due to EMI then I need the system to restart. It saves the status (SMS sent or not sent) in eeprom before sending SMS and after sending SMS. So if program has to restart during sending SMS then it knows after restart whether to send the SMS or not. It has also code to reset GSM modem if modem doesn't respond to AT command for 5 times for the same command and also if ERROR is received after sending 0x1A then micro resets GSM and then tries to send the SMS from the beginning.