an idea to power reset the MCU?

[johnny78]

hi Guys

i have a problem with my armega328p which it got frozen few times
the WDT couldnt reset it So i was thinking of power reset by feeding power through a P channel Mosfet then reset power by cutting the power for a while

im using 16x2 i2c lcd & ds1307 with the Atmega328p & im not sure if the MCU got frozen or just the LCD so i have 2 questions

1:is it enough perrod of time if i cut the power by using a pin of the mcu then after restart the reset condition finished
2:give me an idea to do this please

thanks
Johnny

 

[BradtheRad]

The simple method is to install a manual switch in the power supply wire. (The P-transistor is a useful method if your system gets a signal to change state via timer or sensor of some kind.)

However if you simply wish to push a finger on a button to reset (or restart) your system, then decide which you want: a) normally On or b) normally Off. Either way is under your control. You can have a switch for the mcu and a switch for the lcd. Test what sequence works for your system. You'll have to operate manually for now. Further down the road you can build a circuit that works automatically when it detects a freeze-up.

Examine whether any component in your system warns against applying voltage while it's unpowered.

 

[KlausST]

Hi,

the WDT couldnt reset it

The WDT is very reliable. Never seen it not to work. And I use the WDT in almost all my industrial designs (with the AVRs and other microcontroller)

IF (emphasized) a hang happens AND the WDT does not work ... there must be a hardware problem .. as root problem.

I´m the designer who removes the root problem instead of curing a symptom.
Thus my way to get a reliably working design is to focus on the the real cause of the problem.

* I would inspect schematic
* and PCB layout
regarding
* power supply stability
* (GND) noise
* ESD problems (or other overvoltage / negative voltage sources)
* oscillator problems
* others

****
I can confirm that the AVRs really work reliably. Many of my designs work 24/7 in a chemical plant. And a fail for longer than 10s would cause a production batch worth of 40,000$ to to be lost. The company would surely report every loss of batch to the ones responsible (in this case: me) for the fail.

Klaus

 

[ayeshakhan3]

hi Guys

i have a problem with my armega328p which it got frozen few times
the WDT couldnt reset it So i was thinking of power reset by feeding power through a P channel Mosfet then reset power by cutting the power for a while

im using 16x2 i2c lcd & ds1307 with the Atmega328p & im not sure if the MCU got frozen or just the LCD so i have 2 questions

1:is it enough perrod of time if i cut the power by using a pin of the mcu then after restart the reset condition finished
2:give me an idea to do this please

thanks
Johnny

To reset your ATmega328P, use a P-channel MOSFET to control power. Connect the MOSFET's source to Vcc, drain to the MCU, and gate to ground through an NPN transistor controlled by an MCU pin. To reset, set the pin LOW to cut power for 100ms, then set it HIGH to restore power. This method ensures a complete power cycle for the MCU and peripherals.

 

[johnny78]

Hi,

The WDT is very reliable. Never seen it not to work. And I use the WDT in almost all my industrial designs (with the AVRs and other microcontroller)

IF (emphasized) a hang happens AND the WDT does not work ... there must be a hardware problem .. as root problem.

I´m the designer who removes the root problem instead of curing a symptom.
Thus my way to get a reliably working design is to focus on the the real cause of the problem.

* I would inspect schematic
* and PCB layout
regarding
* power supply stability
* (GND) noise
* ESD problems (or other overvoltage / negative voltage sources)
* oscillator problems
* others

****
I can confirm that the AVRs really work reliably. Many of my designs work 24/7 in a chemical plant. And a fail for longer than 10s would cause a production batch worth of 40,000$ to to be lost. The company would surely report every loss of batch to the ones responsible (in this case: me) for the fail.

Klaus

thx Klaus
there is alot to do with my design but for now i cant do all those checks & i have alreaady installed over than 50 pcs of this device & it works 24/24 365/365 days & i couldnt find a reason for this issue & yes the WDT couldnt reset the mcu & im sure its working because i have tested the method few times to make sure it works
so simply if i reset by power to fix this issue automatically when it happens & yes i have Pic projects working since 10 years or more working without any issue
& sure its reliable but i cant find the reason of my problem right now

& im thinking maybe i need an external reset method in case the MCU got frozen which cant activate reset pulse

any ideas will be great
thanks
Johnny

--- Updated Aug 8, 2024 ---

The simple method is to install a manual switch in the power supply wire. (The P-transistor is a useful method if your system gets a signal to change state via timer or sensor of some kind.)

However if you simply wish to push a finger on a button to reset (or restart) your system, then decide which you want: a) normally On or b) normally Off. Either way is under your control. You can have a switch for the mcu and a switch for the lcd. Test what sequence works for your system. You'll have to operate manually for now. Further down the road you can build a circuit that works automatically when it detects a freeze-up.

Examine whether any component in your system warns against applying voltage while it's unpowered.

thx Brad
sure im looking for a way to reset the MCU automatically its 24/24 working device
i have the mains sensor which i can use it to reset the power on when mains available (momentary reset)
i have an idea but its not so clear in my mind to use P channel mosfet & i was thinking to trigger it by the MCU but now im thinking its not useful because it may not work if the MCU got frozen really

any idea will be great
thanks
Johnny

--- Updated Aug 8, 2024 ---

To reset your ATmega328P, use a P-channel MOSFET to control power. Connect the MOSFET's source to Vcc, drain to the MCU, and gate to ground through an NPN transistor controlled by an MCU pin. To reset, set the pin LOW to cut power for 100ms, then set it HIGH to restore power. This method ensures a complete power cycle for the MCU and peripherals.

this is the method im thinking of but is 100ms enough period of time to reset the MCU & the peripherals?
then when i try this method to reset there is no power source to power the mcu so the pin will trigger the NPN transistor & set a flag to know reset is occured
& after that the pin will go low when the MCU looses power then when it starts again the pin will stay off when reading the reset flag

anyway im thinking of external reset source in case the MCU got frozen really

thanks
Johnny

 

[KlausST]

Hi,

the problem I see:
I assume there is a problem with noise, ESD, power supply ... if so, then this also will hit your "reset circuit" ... so how can you be sure your reset circuit will work properly under the same conditions your microcontroller goes hang?

For me it´s like a house getting destroyed .. now you build a second house to "protect" the first house. Without investigating what really caused the fisrrst house to break.
Earthquake, high water, wind, soemthing else?

I´d say: each cause needs it´s own focus and solution ... to really get an improvement.

As said: my idea is not to reset a microcontroller if it hangs, but to avoid that the microcontroller hangs in first place.

Klaus

 

[johnny78]

Hi,

the problem I see:
I assume there is a problem with noise, ESD, power supply ... if so, then this also will hit your "reset circuit" ... so how can you be sure your reset circuit will work properly under the same conditions your microcontroller goes hang?

For me it´s like a house getting destroyed .. now you build a second house to "protect" the first house. Without investigating what really caused the fisrrst house to break.
Earthquake, high water, wind, soemthing else?

I´d say: each cause needs it´s own focus and solution ... to really get an improvement.

As said: my idea is not to reset a microcontroller if it hangs, but to avoid that the microcontroller hangs in first place.

Klaus

i like your way of thinking but as a solution to fix my problem immediately i thought of reset
i have no time now to re design with no errors unfortunately
im thinking of an external reset source in case my MCU hangs

 

[BradtheRad]

Can you find a pin which stops changing state when the mcu freezes? That can be your detection method. A capacitor-type circuit should be able to sense if nothing has happened for some time (maybe several seconds).

Then it triggers your reset circuit. The reset circuit can be the P-device, designed to activate for the required length of time via another capacitor-type circuit holding the bias (hi or low, depending) for that length of time.

 

[johnny78]

Can you find a pin which stops changing state when the mcu freezes? That can be your detection method. A capacitor-type circuit should be able to sense if nothing has happened for some time (maybe several seconds).

Then it triggers your reset circuit. The reset circuit can be the P-device, designed to activate for the required length of time via another capacitor-type circuit holding the bias (hi or low, depending) for that length of time.

Hi

as i guess this P channel mosfet will power my MCU & when applying negative pulse to npn transistor gate the power through the mosfet will disconnect
im looking for an idea to use the reset source from the optocoupler to trigger the NPN gate for lets say 500ms
(correct me if im thinking wrong)
i have 1 more free pin left on the mcu i can use it if necessary
any idea will b great

thanks
Johnny

 

[betwixt]

I have an MCU working in a very high noise environment where large pumps are constantly turning on and off. I get around occasional freezes with a second MCU, a PIC10F202 working as an external watchdog. It gets reset every second by a pulse from the MCU (which in turn comes via WiFi from a different source) and if it doesn't see a pulse in 60 seconds it pulls the main MCU reset pin low. Costs pennies and drives two LEDs, one is a stretched pulse from the reset, the other to say a reset is in progress. 5 components in total, including the supply decoupling cap.

I can share the code and schematic but you still need something to indicate a crash has not occurred.

Brian.

 

[danadakk]

Question, for future design work :

ARM M3, M4, M7 has a fault exception trap mechanism, is that considered sufficient to
restart a runaway processor ?

ARM also has dual core parts (ESP32 also dual core).......

 

[KlausST]

There are dedicated watchdog ICs. Doing basically what Brian describes.

Go to the distributor of your choice and do a search for "watchdog" ... (did I need to mention this?)

Klaus

 

[danadakk]

The point of post #11 was to get community feedback on trap usage.

ChatGPT states the following :

What are the advantages in using traps in a processor versus watchdog timer


In embedded systems and processor design, both traps and watchdog timers are used to improve system reliability, but they serve different purposes and offer distinct advantages. Here's a comparison of the two:

Traps​

A "trap" is a mechanism where the processor automatically transfers control to a specific piece of code (often called an exception handler or interrupt service routine) when certain predefined conditions are met.

Advantages of Using Traps:​

1. Specific Error Handling:
   • Traps allow for detailed and specific error handling, as they can be configured to trigger on various specific conditions, such as illegal instructions, divide-by-zero errors, or memory access violations.
   • This specificity enables the system to take precise corrective actions depending on the type of fault.
2. Immediate Response:
   • Traps are designed to respond immediately when an error condition occurs, ensuring quick handling of issues that could potentially corrupt data or cause system instability.
3. Debugging Aid:
   • Traps can be used in debugging to catch errors like invalid memory access or illegal operations, helping developers identify and correct bugs during the development phase.
4. Support for Complex Operating Systems:
   • In complex operating systems, traps are essential for managing system-level events, such as page faults in virtual memory management, which require immediate handling to continue program execution correctly.
5. Interrupt Handling:
   • Traps can also serve as a general-purpose mechanism for handling interrupts, allowing the processor to temporarily pause its current tasks to address more urgent matters.

Watchdog Timer​

A watchdog timer (WDT) is a hardware or software timer that resets the system if it is not periodically "kicked" (reset) by the software. It is primarily used to detect and recover from system malfunctions, such as when the system becomes unresponsive.

Advantages of Using Watchdog Timers:​

1. System Stability:
   • Watchdog timers are critical in maintaining system stability, especially in environments where the system needs to run continuously without human intervention.
   • If the system hangs or gets stuck in an infinite loop, the watchdog timer will trigger a reset, bringing the system back to a known good state.
2. Simplicity:
   • Implementing a watchdog timer is typically straightforward, making it a simple and effective solution for ensuring that a system can recover from software malfunctions.
3. Hardware-Induced Reliability:
   • Since the watchdog timer is usually implemented in hardware, it operates independently of the system software. This independence ensures that the system will reset even if the software becomes completely unresponsive.
4. Failsafe Mechanism:
   • Watchdog timers act as a last-resort failsafe. Even if all other error detection mechanisms fail, the watchdog timer will ensure that the system does not stay in an erroneous state indefinitely.
5. Suitable for Real-Time Systems:
   • In real-time systems, where timely execution is crucial, a watchdog timer ensures that any unhandled or prolonged delays will lead to a system reset, maintaining the timeliness of operations.

Comparison and Use Cases:​

• Traps are more appropriate for situations where you need precise error handling and the ability to diagnose specific types of faults. They are highly useful in complex systems where the nature of errors can vary, and the system must take appropriate corrective actions without necessarily resetting.
• Watchdog Timers are more suited to scenarios where system reliability and uptime are critical, and the risk of the system becoming unresponsive needs to be mitigated. They provide a simple, hardware-based solution to recover from severe system failures.

In practice, many systems use both traps and watchdog timers together to leverage the advantages of both: traps for handling specific faults and watchdog timers as a failsafe mechanism to ensure system recovery.

So watchdogs ineffective for memory faults causing repetitive code execution errors. Resetting a processor only
to startup and fault trying to execute code not very useful.....

But if trap faults are periodic, repeating, then a watchdog is ineffective ?


You're correct that if trap faults are periodic and repeating, a watchdog timer alone might be ineffective in addressing the underlying issue. Here's why:

Repetitive Trap Faults and Watchdog Timers:​

• Periodic Trap Faults: If the system encounters the same fault repeatedly at regular intervals, the system might still appear to be "alive" and continue kicking the watchdog timer. As a result, the watchdog timer won't trigger a reset, because the system hasn’t become completely unresponsive or hung—it’s just stuck in a loop of encountering the same fault and recovering from it.
• Ineffectiveness of Watchdog in This Scenario: Since the watchdog timer is designed to reset the system only if the software stops kicking it (i.e., the system hangs or becomes unresponsive), it won't reset the system if the system keeps recovering from traps and continuing to run, even if it's not functioning correctly or efficiently.

Mitigating Repetitive Trap Faults:​

1. Enhanced Error Handling:
   • Implement a more sophisticated error-handling mechanism within the trap handlers. For example, if a particular fault is encountered too frequently, the system could escalate the response (e.g., log the error, notify the user, or ultimately trigger a system reset) instead of simply recovering and continuing.
2. Watchdog Timer with Trap Detection:
   • Some systems use a combination of a watchdog timer and error counters. For instance, the system could monitor how often certain traps are triggered within a specific time frame. If the same trap is triggered too frequently, this could trigger a reset or enter a safe state, even if the watchdog timer hasn’t timed out.
3. Use of Redundant Mechanisms:
   • Alongside the watchdog timer, implementing a secondary check for periodic faults can be effective. For example, an additional counter could track the number of times a specific fault occurs. If this counter exceeds a threshold, it could trigger a system reset or switch to a recovery mode, even if the watchdog timer hasn’t been triggered.
4. Root Cause Analysis and Fixing the Bug:
   • The ideal solution is to address the root cause of the repetitive trap faults. Identifying and fixing the underlying bug or issue that is causing the repeated faults will eliminate the problem altogether.

Conclusion:​

While watchdog timers are great for recovering from complete system hangs, they may not be effective in scenarios where the system repeatedly encounters the same fault but remains responsive enough to keep resetting the watchdog. In such cases, additional mechanisms or enhanced error handling should be used to detect and respond to these repetitive faults.

 

[johnny78]

I have an MCU working in a very high noise environment where large pumps are constantly turning on and off. I get around occasional freezes with a second MCU, a PIC10F202 working as an external watchdog. It gets reset every second by a pulse from the MCU (which in turn comes via WiFi from a different source) and if it doesn't see a pulse in 60 seconds it pulls the main MCU reset pin low. Costs pennies and drives two LEDs, one is a stretched pulse from the reset, the other to say a reset is in progress. 5 components in total, including the supply decoupling cap.

I can share the code and schematic but you still need something to indicate a crash has not occurred.

Brian.

thx Brian
its the same issue i have which i couldnt know the reason & that's what im looking for but its very expensive to add another MCU for power reset
im looking for something simpler but reliable at the same time & yes as i mentioned in my schematic i have the manis sensor which i can use to reset with every mains available

if you share your schematic it can give me some ideas & experience

thanks
Johnny

--- Updated Aug 9, 2024 ---

There are dedicated watchdog ICs. Doing basically what Brian describes.

Go to the distributor of your choice and do a search for "watchdog" ... (did I need to mention this?)

Klaus

that's what i was looking for & already have mentioned that by sharing my idea about external reset circuit
& you adviced me to find the reason no curing the issue but this is something hard to achieve if it was that easy why they invented WDT or external reset circuits ?
anyway its valuable information i have got from you all

thanks
Johnny

--- Updated Aug 9, 2024 ---

The point of post #11 was to get community feedback on trap usage.

ChatGPT states the following :



So watchdogs ineffective for memory faults causing repetitive code execution errors. Resetting a processor only
to startup and fault trying to execute code not very useful.....

thanks Dana

im not that expert but i can know when WDT is working or not & i have projects running since more than 10 years with no problems at all
& the issue with this device happened with no logical reason & the WDT couldnt reset it

Johnny

 

[KlausST]

& you adviced me to find the reason no curing the issue

And I stand to my recommendation.

Still it´s your design, you decide what to do.
But I wanted to point out that you don´t need to design your own watchdog circuit ... as discrete hardware or using a microcontroller with software.
... since there are ready to buy simple and reliable solutions ... to keep the effort low.

Klaus

 

[johnny78]

thx Brian
its the same issue i have which i couldnt know the reason & that's what im looking for but its very expensive to add another MCU for power reset
im looking for something simpler but reliable at the same time & yes as i mentioned in my schematic i have the manis sensor which i can use to reset with every mains available

if you share your schematic it can give me some ideas & experience

thanks
Johnny

--- Updated Aug 9, 2024 ---

that's what i was looking for & already have mentioned that by sharing my idea about external reset circuit
& you adviced me to find the reason no curing the issue but this is something hard to achieve if it was that easy why they invented WDT or external reset circuits ?
anyway its valuable information i have got from you all

thanks
Johnny

--- Updated Aug 9, 2024 ---

thanks Dana

im not that expert but i can know when WDT is working or not & i have projects running since more than 10 years with no problems at all
& the issue with this device happened with no logical reason & the WDT couldnt reset it

Johnny

And I stand to my recommendation.

i wish if it was that easy

Still it´s your design, you decide what to do.
But I wanted to point out that you don´t need to design your own watchdog circuit ... as discrete hardware or using a microcontroller with software.
... since there are ready to buy simple and reliable solutions ... to keep the effort low.

Klaus

i need something like:

on setup
1:turn high reset pin
2:delay(500);
3:turn low reset pin
4:end

& i have a source pulse for this

thanks
Johnny

--- Updated Aug 9, 2024 ---

i

i wish if it was that easy


i need something like:

on setup
1:turn high reset pin
2:delay(500);
3:turn low reset pin
4:end

& i have a source pulse for this

thanks
Johnny

its interesting if i fine attiny9 or pic10F202 for this

 

[betwixt]

The schematic is so simple I will describe it:
PIC10F202 in DIP8 package, you can use the 6 pin version
pin 1 - no connection
pin 2 - VDD (3.3V)
pin 3 - (GP2) Anode of red LED
pin 4 - (GP1) Anode of blue LED
pin 5 - (GP0) active low reset output to main MCU
pin 6 - no connection
pin 7 - VSS (GND)
pin 8 - (/MCLR) periodic low pulses to reset watchdog timer

Both LED cathodes are joined and go to ground through a single 150 Ohm resistor.
A 100nF ceramic capacitor bridges VDD and VSS.

And the code is written in Oshonsoft BASIC:

'External Watchdog module for PML unit.
'This PIC is reset by the one second time signal sent by MQTT
' and echoed on the PML's SDA pin on the ISCP port.
'It is basically a monostable with monitor LEDs, reset once a second and providing a
'reset to the ESP32 if  60 seconds elapses

OPTION_REG =  0x08
GPIO = 0x03

Retry:

ConfigPin GP0 = Input         'Active low reset to ESP32
ConfigPin GP1 = Output        'LED pulsed at reset to show activity
ConfigPin GP2 = Output        'LED pulsed while ESP32 reset is active

GP0 = 1                                    'Don't force an immediate reset !
GP1 = 1                                    'Source current to blue (activity) LED
GP2 = 0                                    'Red (reset) LED should be off

WaitMs 200                                 'turn blue LED off after 200mS
GP1 = 0

WaitMs    59800                        'watchdog time delay
GP2 = 1                                    'turn red LED on to announce imminent reset

WaitMs 200                                'turn red LED off ...
GP2 = 0
ConfigPin GP0 = Output        ' .. and pull GP0 low
GP0 = 0
WaitMs 200                                ' delay before repeating process in case a reset failed
GP0 = 1
WaitMs 10
Goto Retry

On my PCBs there is a row of pins to connect to the ESP32 MCU so it can be programmed after assembly, it carries 3.3V, GND, Reset, GPIO0, TX and RX for programming but it also has two pins for future I2C expansion so I use one of those to pulse the reset to the watchdog. After initial programming the firmware can be updated over the air.

I just checked the log files and I get about two resets per month but considering the unit has connections to three water pumps, an AC line power monitor and two solar inverters it's hardly surprising it sees lots of noise. It runs 24/7.

Brian.

 

[johnny78]

The schematic is so simple I will describe it:
PIC10F202 in DIP8 package, you can use the 6 pin version
pin 1 - no connection
pin 2 - VDD (3.3V)
pin 3 - (GP2) Anode of red LED
pin 4 - (GP1) Anode of blue LED
pin 5 - (GP0) active low reset output to main MCU
pin 6 - no connection
pin 7 - VSS (GND)
pin 8 - (/MCLR) periodic low pulses to reset watchdog timer

Both LED cathodes are joined and go to ground through a single 150 Ohm resistor.
A 100nF ceramic capacitor bridges VDD and VSS.

And the code is written in Oshonsoft BASIC:

'External Watchdog module for PML unit.
'This PIC is reset by the one second time signal sent by MQTT
' and echoed on the PML's SDA pin on the ISCP port.
'It is basically a monostable with monitor LEDs, reset once a second and providing a
'reset to the ESP32 if  60 seconds elapses

OPTION_REG =  0x08
GPIO = 0x03

Retry:

ConfigPin GP0 = Input         'Active low reset to ESP32
ConfigPin GP1 = Output        'LED pulsed at reset to show activity
ConfigPin GP2 = Output        'LED pulsed while ESP32 reset is active

GP0 = 1                                    'Don't force an immediate reset !
GP1 = 1                                    'Source current to blue (activity) LED
GP2 = 0                                    'Red (reset) LED should be off

WaitMs 200                                 'turn blue LED off after 200mS
GP1 = 0

WaitMs    59800                        'watchdog time delay
GP2 = 1                                    'turn red LED on to announce imminent reset

WaitMs 200                                'turn red LED off ...
GP2 = 0
ConfigPin GP0 = Output        ' .. and pull GP0 low
GP0 = 0
WaitMs 200                                ' delay before repeating process in case a reset failed
GP0 = 1
WaitMs 10
Goto Retry

On my PCBs there is a row of pins to connect to the ESP32 MCU so it can be programmed after assembly, it carries 3.3V, GND, Reset, GPIO0, TX and RX for programming but it also has two pins for future I2C expansion so I use one of those to pulse the reset to the watchdog. After initial programming the firmware can be updated over the air.

I just checked the log files and I get about two resets per month but considering the unit has connections to three water pumps, an AC line power monitor and two solar inverters it's hardly surprising it sees lots of noise. It runs 24/7.

Brian.

i will check if i can find pic10f202 or attiny9 or 10

also i can add an extra reset source
1: reset on mains available
2:reset on pin state hangs on the main mcu

thanks
Johnny

 

[johnny78]

i will check if i can find pic10f202 or attiny9 or 10

also i can add an extra reset source
1: reset on mains available
2:reset on pin state hangs on the main mcu

thanks
Johnny

unfortunately i couldnt find any 6 pin mcu
the cheapest one is at90s1200 which i was lookin for programming it but no solution without old parallel port
if you have a solution will be great

 

[betwixt]

The 10F202 I used was in an 8-pin DIP package because I had them in stock but two of the pins are "no connect" and are not internally connected to the die. There is a 6-pin version in SOT23-5 package. They are one of the cheapest MCUs at 0.60 UKP or about 0.70 Euros/USD including tax.

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/40001239F.pdf

Programming info: https://ww1.microchip.com/downloads/en/DeviceDoc/41228F.pdf

If you look on the internet there are several inexpensive programming tools that cover all the microchip devices including the 10F202.

Brian.