Electronics > Projects, Designs, and Technical Stuff
How to check external watched dog IC when toggling MCU oscillator
Md Mubdiul Hasan:
Hi There,
I am working with a MCU STM32F405VET for any particular purpose. Lets a at this time firmware code has burn on MCU.
Take a look the datasheet here https://www.qdatasheet.com/datasheet-download/190671/1/ST-Microelectronics/STM32F405VET6
In my design portion a 25MHz oscillator supports MCU for clocking. See the attached file.
In this time a watched dog ic STWD100NXWY3F working externally,https://www.st.com/resource/en/datasheet/stwd100.pdf
What it does is watchdog timer is as a system monitor to detect and reset an "out of control" microprocessor. When program execution goes awry it will not properly execute the code that restarts the watchdog. In such a case the watchdog timer will timeout and cause a microcontroller reset. In a properly designed system, the reset will correct the error. Is the case of independent watched dog from main MCU timer.
watched_problem.png
I want to connect a toggle swish in 2 and 3 point of crystal oscillator XT1 and wish to see the input out put of 1 and 4 of U29 watched dog.
I did see in oscillator when I push the switch meaning that 3 and 2 pin of XT1 has been shorted then input of U29 distorted but wont disappeared.
It wont clear instantly , what do you think?
Datasheet of STWD100NXWY3F says, While the system is operating correctly, it periodically toggles the watchdog input, WDI. If the system fails, the watchdog timer is not reset, a system alert is generated and the watchdog output, WDO , is asserted. BUT MY MCU NEVER GOES TO RESET.
LaryPant:
Hi,
I took a look at your schematic and I believe that I have found your problem.
The output of the external watchdog timer is open drain and active low according to page five of the datasheet.
This means that you would need a 10 k\$\Omega\$ pull up resistor on pin 1 of U29 in your schematic.
I am also unsure whether or not the external watchdog timer actually is enabled. According to the datasheet on page 1, there is an internal pull down resistor connected to the active low enable pin, but R106 and R107 may interfere with the internal pull down resistor by causing the voltage to be at an undefined level. Secondly, I can not see where pin 3 is connected to besides R106 and R107. This leads me to believe that watch dog timer is not enabled.
I would highly suggest testing the STWD100 in isolation with an oscilloscope or the MCU before you start adding the rest of the circuit.
I hope this helps,
Lary
RJSV:
Maybe not direct advice, but I'm wondering about a WatchDog set-up in general. Most WatchDog item Ive seen don't activate RESET, at least not directly: the MCU using a high-priority INTERRUPT for response.
Of course that aspect of circuit / bus / power, must be functioning, but main goal was software stability.
With RESET does the code figure out 'some event's happened ?
Because; using interrupt routine you have option of logging the event. I often use a 'private' buffer to log events, mainly for analysis of performance (speed).
The buffer is simply using one page (256 locations) and is circular, wrapping around after byte 255.
A simple code like $01F hex will indicate 'WD FAIL", plus a second byte has parameter detail, whatever you the programmer/ developer wants to tag.
A software known fail, such as graphics move taking too long can attach a parameter such as where the screen ROW (scan) is at, in the buffer, that sort of diagnostic LOG.
SO.... Does the RESET code do anything to determine how it got there? If question makes sense, such as using a fairly unique 'checksum' or even just an unlikely set of values, like $ 1234 hex in two bytes.
AND then what? Does the code there store anything
(How about a count of how many faults occured up to now?
Otherwise, it's kinda hard to say something quantitative, about code reliability and WatchDog tripped frequency. Zero resets being the goal, during development and testing.
Md Mubdiul Hasan:
--- Quote from: LaryPant on July 31, 2021, 10:45:56 am ---Hi,
I took a look at your schematic and I believe that I have found your problem.
The output of the external watchdog timer is open drain and active low according to page five of the datasheet.
This means that you would need a 10 k\$\Omega\$ pull up resistor on pin 1 of U29 in your schematic.
I am also unsure whether or not the external watchdog timer actually is enabled. According to the datasheet on page 1, there is an internal pull down resistor connected to the active low enable pin, but R106 and R107 may interfere with the internal pull down resistor by causing the voltage to be at an undefined level. Secondly, I can not see where pin 3 is connected to besides R106 and R107. This leads me to believe that watch dog timer is not enabled.
I would highly suggest testing the STWD100 in isolation with an oscilloscope or the MCU before you start adding the rest of the circuit.
I hope this helps,
Lary
--- End quote ---
Previously who handled this project has gone. This is a charger module controller, at display control( display has external pad input) voltage values comes correctly but current does not.
Someone explains just very few information but he doesn't know what to do.
He said, f/w cant make watchdog action in this case. But I do believe WD command has inactivated.
Now looking at left bottom side of circuit you can see 2 signal WADCH_DOG_EVENT and WADCH_DOG_EV_CLEAR is appeared.
What I did is connect a IN4148 at the base of Q15 that goes to pin 1 of U29 WD IC.
Then I stared push and pull the switch again in XT1 and saw the WDO input pulse diminishes and MCU start to reset.
After "time out" system restart again!
Md Mubdiul Hasan:
Thank you sir @RJHayward
You said about a deep insight of firmware.
At this moment I have not been gone through this firmware IAR IDE of STM.
But yes,
--- Quote ---it's kinda hard to say something quantitative, about code reliability and WatchDog tripped frequency. Zero resets being the goal, during development and testing.
--- End quote ---
--- Quote ---Maybe not direct advice, but I'm wondering about a WatchDog set-up in general. Most WatchDog item Ive seen don't activate RESET, at least not directly: the MCU using a high-priority INTERRUPT for response. Of course that aspect of circuit / bus / power, must be functioning, but main goal was software stability.
--- End quote ---
Well said, in this case there no way to see the WatchDog is actively RESET system. It is true this project is combined of SW+F/W, and some time it needs to reset the S/W.
--- Quote ---Because; using interrupt routine you have option of logging the event. I often use a 'private' buffer to log events, mainly for analysis of performance (speed).
The buffer is simply using one page (256 locations) and is circular, wrapping around after byte 255.
--- End quote ---
I will be happy if you can post an example to doing so. Cant we play WD register stepping in IDE window?
--- Quote ---A simple code like $01F hex will indicate 'WD FAIL", plus a second byte has parameter detail, whatever you the programmer/ developer wants to tag.
A software known fail, such as graphics move taking too long can attach a parameter such as where the screen ROW (scan) is at, in the buffer, that sort of diagnostic LOG.
--- End quote ---
Not completely understandable, does it possible to do it just building the program. I think not. After build>target>load program> run, meaning that when total program would executed by compiler then WD register functioning can be visible somehow and as you said ROW scan ad LOG console would say anything.
--- Quote ---SO.... Does the RESET code do anything to determine how it got there? If question makes sense, such as using a fairly unique 'checksum' or even just an unlikely set of values, like $ 1234 hex in two bytes. AND then what? Does the code there store anything
--- End quote ---
Offcourse anything could be measurable. This project contains ADC, relay control, buzzer, RTC and some other communication protocol.
Navigation
[0] Message Index
[#] Next page
Go to full version