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]

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

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, 

it's kinda hard to say something quantitative, about code reliability and WatchDog tripped frequency. Zero resets being the goal, during development and testing.

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.

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.

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.

I will be happy if you can post an example to doing so. Cant we play WD register stepping in IDE window?

 

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.

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.

 

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

Offcourse anything could be measurable. This project contains ADC, relay control, buzzer, RTC and some other communication protocol.

[RJSV]

(hope I get first name right, ok?) Hello Mubdiul:
   This is question I can answer many details:

Firstly, say your 'boss' wanted list of your solutions, BEFORE deciding to hire you. Here would be my responses:

   First thing: Does engineering office want 'formal' spec, or just casual list of software goals?

  What I would do first, is write some private code (meaning not for putting in final product).
This 'private developer tool' will NOT contain much active CODE, rather just only for testing your WatchDog hardware, to make sure doing that function as desired. Please read post by Lary, on some hardware correction might be needed (pull ups).

   So, my code would, upon power-up do any normal start-up, of WD timer. Plus your processor probably needs to enable interrupts. Some CPU like Z-80 even has an unconditional interrupt, NMI pin.
Your goal is to get that WD running, then FORCE your error.
   Suggest your code do that start-up, then create a looping routine, it will delay, following each delay it will 'strobe' the WD with intention of keeping it happy.
Have a 'test panel' ? You can compile this short test, but have a way to go in and change that delay loop value, for quick trials, on the bench, avoiding a bunch of repeated compiles.
Idea is to deliberately make the error-timeout plus able to make it NOT time-out, so you can judge.

[RJSV]

So far, you will be able to get the WD (watch dog) circuit to respond, placing 200 delay loops, for example, might be a short time while 500 delay loops definitely causes a 'Timed-Out' condition. This gives you definitive test, for the WD functioning.
   For your fault indicator, I don't know your system but use the buzzer or light an LED to indicate 'fault'.
Remember, some of this klugy stuff is only for your use as a developer.
  Is there a low-level TEST PANEL, one that for assembly language, you can stop the code, and modify a byte, or word or whatever, for changing the LOOP count, in the fly, to check if your time-out fault is the way it should operate.
   On the Z-80 system, NMI always generates a program counter reload, to a specific location, in the firmware PROM, ($ 0066 I believe.)

  OK so now, you can put this verified stuff in your PROM compile along with your original project stuff.

Do you know what: I bet anyone would have a bunch of difficulty, just getting that WD to (even) respond as desired, to your 'simulated' software acting like it got lost. Even worse, the code you are trying to protect / monitor could turn out to be much easier to write, correctly.
  Soon, I can read some more, on the STWxxxxx data sheet and application notes, see if can help there.
INTERRUPTS AND REAL-TIME activities are a challenge to understand and do correctly.

   Right now, I am unsure of location, on PROM where the code would be dispatched to upon error.
Need a way to initialize your count, of fault events, vs just simply counting up one more (event) happened.
That, I believe, is going to involve the concepts of 'soft' vs 'hard' RESET.
If using a test panel, you could just increment the error count, and deal with that, on the development bench.
That means you might see '14' errors, but remember it was '12' when you started.
Not sure, if that sort of diagnostic is useful, later.

PLUS, Sorry to be a SNOB, but I don't view the 'power down, then up' mentality as a quality approach.
Many, many of us, using WIFI, etc see RESET as a panacea for all our problems.
I'd rather track down and fix original fault (can't always make the World perfect, though LOL).
Busy being clever. Please more questions, if need more. -- Rick

[RJSV]

Here is detail, how to log (some) fault, just happened:
   Using working knowledge, of 8 bit Z-80.
Suppose you keep having serial COMM problems, as an example.
  So, in previous example, the watch dog timer did not get re-started, and so the code branched (actually interrupt sent it) to your error handler.
  With either example, you end up in coded routine:
Now, say it is a serial COMM parity error. You had previously defined a few different codes, for each possible (error) situation. Say $31 hex will be your chosen flag byte, meaning 'COMM ERROR' just happened.
   For the private diagnostic LOG you set up pointer, HL, where H = Page, and L points to byte, in the LOG page.
Example HL = $ 409F hex.
   Your code will first load H=$40h and loads L register from a byte variable, called 'DIAGNPtr'. That way you are pointing into your problem LOG, at 40XX.
  On Z-80 processor, you would set ACC to $31hex, and save, then ponder, what associated info would help, if bunch of COMM errors keeps happening. For this case, perhaps whatever byte of error flags your UART has can be saved, as you want to see that, later. Perhaps it's PARITY error, keeps happening. You would see that, later. Reading (using test panel, or IDE) a 31 hex, you could jot that down, plus that copy of error flags. Helps you to track down error, in this UART example.
   The code for LOG will increment L register, that is low byte of pointer, while leaving the 'page' portion of the pointer untouched (that's in H). You end up with a circular buffer.
Now, for easy reading, you could increment 'L' register to the next location, and then write it as $FF hex.
So, when examining that 'trouble code' LOG you can quickly recognize where the LAST code has been saved. Oh and, of course you have to save the updated 'L' register value, representing pointer to the 'next empty'.
If $FF, FF, FF, FF in buffer already, you could always try save $ 12h, $ 34h, which is pretty unique for notating that's the first empty spot, in your 256 byte circular buffer.
OR, you could read and use the pointer value itself, for manually reading trouble LOG results. Some results depend on if you do RAM clearing stuff, initial power up.

[RJSV]

Actually: Not sure if / why you want to 'toggle' the system clock oscillator (if I'm reading right), but since we already into some debug activity details...:

   In a self-contained system, often there are two choices of RESET, or actually: 'BOOT-STRAP', initial startup code.
   For yours, you could assign a special two bytes in RAM, and assuming your PCB assembly does not include some giant capacitor to hold voltage longer than a couple hundred milli-seconds, that two bytes will not retain the number. Say, $ 1234 hex, won't exactly be expected, randomly.
   So, first few lines of code, after power-up, starting from 'zero' location can check, if the '1234' flags that code has 'been running', not a first time through initialization. Now, most everything function related needs to have normal initialization; it's only your special diagnostic stuff (i.e. an event LOG) that requires distinguishing, between warm and 'cold' BOOT code.
  This assumes, partially, that you have a actual RESET asserted by the watch dog, rather than an interrupt and subsequent JUMP, (of PC register) to zero in PROM code. That jump to zero is for a 'cold' boot run of code.
   At any rate, your code that 'cold starts' will be clearing out the trouble log, clearing the little 256 byte buffer to all zeros.
   If it is a 'warm' boot, meaning that code has already been running, but did RESET action (perhaps to clear and initialize the various MCU functions), well then the private LOG remains untouched.

   Regarding the trouble code LOG actions, here is what happens, suppose with using a 6502 MCU:
A 6502 processor has convenient 8 bit index already.  By using an address + index mode, such as:

    Ldy.  PTRLOG
    Lda #31h
     Sta 4000h,Y
This code will already keep within 256 byte range, of 40XX h for your circular buffer, of custom trouble codes.  You may, also, record regular events, not just unusual faults. Like previous example, you can record, for example, what ROW the video scan is currently doing, when some large 'block move' is complete. That would give idea of how long that particular routine is taking, to complete. Actually that is using a PCB assembly video portion as simple timing indicator.
Hopefully, some sort of real-time counter / timer channel can also provide that.
   In the 6502 example, using Y register gives index size convenient for the 256 byte buffer size, so the 'wrap-around' happens automatic. That would look like $ 40FF wraps to $ 4000 hex.
   Sorry if can't present the trouble LOG concepts here, in 32 bit processor form, but function descriptions can be 'translated' across 'platforms', as they say.
   For things like coding a 'block move' or a 'block clear' those functions, you'll have to read up on, for that 32 bit MCU type. Thanks

[RJSV]

Doing some thinking, on warm / cold BOOT-STRAP code, and that event / trouble LOG (for IDE mostly).
  As development proceeds, a simple circular event LOG often is helpful. Of course, that's more an in-house tool, to be disabled when project ready to ship.

   My preference was to put diagnostic stuff in the COLD BOOT-STRAP area, that's, I assume, at location zero, in the PROM.
Most of your 'regular' start-up goes into the WARM BOOT-STRAP code area, let's say that is at: 0200 hex.
The COLD start up, from power-up, will act to clear the trouble-shooting buffer, plus it will initialize the buffer pointer (for circular access).
   So the code, coming up from PROM location zero, will check a couple of flag bytes: if they are 1234 hex then the device has already done at least one 'cold boot'.  The odds of this happening, randomly, are pretty low, and the risk is you might mess up your diagnostic buffer, not your main production code.
Also, the buffer pointer can be initialized during 'cold' boot.
   Now, one method, for tracking performance and catching errors, is to use LOG as a kind of 'journal', occasionally saving an event or routine start. That way, if a WATCH DOG initiated RESET happens, the software developer has some clues, while testing the device, in IDE (examining the bytes by stopping MCU in IDE.)
You could even potentially LOG a RESET initiated by pressing a RESET button, physically.  In theory, this way the running CODE should be able to figure out if RESET button was pressed, or if a fault RESET happened, vs an actual powering up situation.
But having key routines place a LOG entry, BEFORE some time-out WD fault occurs, is an aid to later examination by developer.
   Oh, and if code does clear that diagnostic buffer and re-start the circular pointer, then it needs to set the flag bytes (to 1234 hex). That's creates a one-time situation, meaning that CODE thinks a power-up just happened, as the two byte flag is corrupted (by losing actual power).

   Sorry if confused about interrupts, I had first assumed the CODE would jump to 'WARM BOOT CODE', at 0200 hex in my PROM example.

[Md Mubdiul Hasan]

Quote

Firstly, say your 'boss' wanted list of your solutions, BEFORE deciding to hire you. Here would be my responses:

I am working long time here. Boss does not know what he wants to do. I believe he wants to just see the WD is working or not just downloading .out/.bin/.hex files!


Quote

First thing: Does engineering office want 'formal' spec, or just casual list of software goals?

What I saw there is a  third party who updated firmware time to time, watch dog is just an example.
This project is not only bound to a limited software facility, its a versatile application and  having a customized board and code representation.
It has node point  with PC software, may be register values can display there graphically, can be set them with offset or default value. Mostly written in C#.
With basic c all driver .c and .h are written. ADSs are set to be ePWM, communication protocol send them to useful place. System recall them, W/R them store them.
A bunch of case1...caseN executed well. Softstarts( sleep time/ active time) begins, ends, interrupts are generating. Dahasheet and manual says all.

 

Quote

What I would do first, is write some private code (meaning not for putting in final product).
This 'private developer tool' will NOT contain much active CODE, rather just only for testing your WatchDog hardware, to make sure doing that function as desired. Please read post by Lary, on some hardware correction might be needed (pull ups).

They have not told me to work on code. HW testing is done as I said, boss wanted to toggle the crystal oscillator output ( not a good idea at all) and thus he assume if main clack is disable then it affects WD i/o. After downloading program system takes time to run a cycle, instantly the MCU wont RESET quickly. You it has "time out" period. It also has internal clock. I wanted to see one of your example code.
If you cant hare it, may be ST cloud would have it.


Quote

So, my code would, upon power-up do any normal start-up, of WD timer. Plus your processor probably needs to enable interrupts. Some CPU like Z-80 even has an unconditional interrupt, NMI pin.
Your goal is to get that WD running, then FORCE your error.

May be WD is not enabled, but the pcb has WD ic. This the reason boss wont care about, signals WADCH_DOG_EVENT and WADCH_DOG_EV_CLEAR.


Quote

Suggest your code do that start-up, then create a looping routine, it will delay, following each delay it will 'strobe' the WD with intention of keeping it happy.
Have a 'test panel' ? You can compile this short test, but have a way to go in and change that delay loop value, for quick trials, on the bench, avoiding a bunch of repeated compiles.
Idea is to deliberately make the error-timeout plus able to make it NOT time-out, so you can judge.

A ST staff said" Not sure if I got everything right from your problem description, but: The STM32 has an on-chip clock-security-system (CSS) which, when active, will detect failure of your external clock (HSE), switch to internal oscillator (HSI) and generate an interrupt for further software treatment. Moreover, the on-chip independent watchdog (IWDG) is clocked by an independent internal oscillator and can safely reset the MCU. So there is IMHO no need for such a complex external circuitry. Even if you use STWD100 you may connect /WDO to /NRST via a simple 4k7 resistor (as shown in the data sheet)."

 

Yes. It will be more accusable with real code. Take a look, what do you understand ?

#include "watchdog.h"


IWDG_HandleTypeDef hiwdg;
uint32_t WatchdogReloadCount;

void InitWatchdog(int ReloadCount)
{
   WatchdogReloadCount = ReloadCount;
   
   hiwdg.Instance = IWDG;
   hiwdg.Init.Prescaler = IWDG_PRESCALER_256;
   hiwdg.Init.Reload = ReloadCount;
   hiwdg.Init.Window = IWDG_WINDOW_DISABLE;
   HAL_IWDG_Init(&hiwdg);
}

void HoldWatchdog(void)
{
   hiwdg.Init.Reload = 0xFFF;
   HAL_IWDG_Init(&hiwdg);
}

void EnableWatchdog(void)
{
   hiwdg.Init.Reload = WatchdogReloadCount;
   HAL_IWDG_Init(&hiwdg);
}

void Reload_Watchdog(void)
{
   HAL_IWDG_Refresh(&hiwdg);
}
 

[Md Mubdiul Hasan]

So far, you will be able to get the WD (watch dog) circuit to respond, placing 200 delay loops, for example, might be a short time while 500 delay loops definitely causes a 'Timed-Out' condition. This gives you definitive test, for the WD functioning.
   For your fault indicator, I don't know your system but use the buzzer or light an LED to indicate 'fault'.
Remember, some of this klugy stuff is only for your use as a developer.
  Is there a low-level TEST PANEL, one that for assembly language, you can stop the code, and modify a byte, or word or whatever, for changing the LOOP count, in the fly, to check if your time-out fault is the way it should operate.
   On the Z-80 system, NMI always generates a program counter reload, to a specific location, in the firmware PROM, ($ 0066 I believe.)

  OK so now, you can put this verified stuff in your PROM compile along with your original project stuff.

Do you know what: I bet anyone would have a bunch of difficulty, just getting that WD to (even) respond as desired, to your 'simulated' software acting like it got lost. Even worse, the code you are trying to protect / monitor could turn out to be much easier to write, correctly.
  Soon, I can read some more, on the STWxxxxx data sheet and application notes, see if can help there.
INTERRUPTS AND REAL-TIME activities are a challenge to understand and do correctly.

   Right now, I am unsure of location, on PROM where the code would be dispatched to upon error.
Need a way to initialize your count, of fault events, vs just simply counting up one more (event) happened.
That, I believe, is going to involve the concepts of 'soft' vs 'hard' RESET.
If using a test panel, you could just increment the error count, and deal with that, on the development bench.
That means you might see '14' errors, but remember it was '12' when you started.
Not sure, if that sort of diagnostic is useful, later.

PLUS, Sorry to be a SNOB, but I don't view the 'power down, then up' mentality as a quality approach.
Many, many of us, using WIFI, etc see RESET as a panacea for all our problems.
I'd rather track down and fix original fault (can't always make the World perfect, though LOL).
Busy being clever. Please more questions, if need more. -- Rick

I am pretty much sure you wanna go deep insight a code. Sounds great to me! I will for sure read your comment.

[RJSV]

Thanks, I'm taking a 'push' to study the STM32 in general, but very much beginner with 'C' language.

   So, to complete my thoughts, on system response to faults, much structure consideration around the cold and 'warm' bootstrap initialization, plus I am assuming there is an IDE type set up.
   Coming up from PC = 0000 the thought is to first check the 'unique' valued flag bytes (that's the 1234 hex, or whatever other, the programmer wanted.)
Specifically, I am thinking, you cannot tell, whether a power up happened, or a press of 'RESET' caused the jump to zero, so for testing fault response the button press could be used, rather than coding that deliberately 'allows' the WD to expire.
   But I did not want to clear the error 'count' in any case. One way is to never clear that count, and use a 32 bit word, so it shouldn't overflow, or perhaps just once (as if the 4 byte word maybe came up from power up, as FFFFFFFF hex.) That would certainly overflow, once, but in IDE environment my thought is you could power up, then stop the processor and examine that error count, say it is at 141 hex. Then you start testing, and with (another) error, you get 142.
   That gives a usable 'zeroed out' error count, rather than a direct 00000000 value. That way your error count is never 'cleared', and so is usable.
In a server farm type situation, often you don't have easy access to disconnect the mains plug, so the module RESET button takes the place.
  Funny, all this might seem confused, it is somewhat, and, ironically, end result takes up very very little code space, like under 100 bytes.

Thanks, just wanted to finish the thoughts, on diagnosing various faults, related to the watch dog timer or not.
You could even get away with never clearing the 256 byte LOG buffer, if the various codes/parameters lend to easy discerning, from the 'junk' in memory from a power down, power up action.

   Got to go, but I still need to re-read your comments, above. thanks,
Rick

[Md Mubdiul Hasan]

Thanks, I'm taking a 'push' to study the STM32 in general, but very much beginner with 'C' language.

I had been with it 2016-2017. You can generate easy GPIO or driver files accordance to your application you have chosen.

 

So, to complete my thoughts, on system response to faults, much structure consideration around the cold and 'warm' bootstrap initialization, plus I am assuming there is an IDE type set up.
   Coming up from PC = 0000 the thought is to first check the 'unique' valued flag bytes (that's the 1234 hex, or whatever other, the programmer wanted.)

If you look inside the datasheet whatever MCU you have chosen, you can see the memory history first, where should you access and in which area you have to run our code. Making driver file in ST is very simple, but you we need is write suitable code structure, loops, syntax, data type and of course the pointers what makes your code meaningful. When you read Digital Electronics you saw how binary, hex or octal can be produce mathematically and with logically. Registers are nothing but representing a significant meaning of character of digital sequence. How e WORDS the massage !!

Specifically, I am thinking, you cannot tell, whether a power up happened, or a press of 'RESET' caused the jump to zero, so for testing fault response the button press could be used, rather than coding that deliberately 'allows' the WD to expire. But I did not want to clear the error 'count' in any case. One way is to never clear that count, and use a 32 bit word, so it shouldn't overflow, or perhaps just once (as if the 4 byte word maybe came up from power up, as FFFFFFFF hex.) That would certainly overflow, once, but in IDE environment my thought is you could power up, then stop the processor and examine that error count, say it is at 141 hex. Then you start testing, and with (another) error, you get 142.

Well said, WD is mainly understandable with coding, HW issue wont make it visible. Yesterday my co worker said they have solved the problem, but in this country no one wants to go deep insight. Third party may have Enabled the WD command/ structure of the code thus the 2 signals are activated after updated .bin file downloaded. I will love to know from you ow your code compute overflows and compute 32 bits. Can you open the register window and stepping it?

 

That gives a usable 'zeroed out' error count, rather than a direct 00000000 value. That way your error count is never 'cleared', and so is usable.
In a server farm type situation, often you don't have easy access to disconnect the mains plug, so the module RESET button takes the place.

Don't you see my toggle switch was pressed with unusual manner ? I dont think MCU wont go to RESET actually, because other part of clock as alive!


 

Funny, all this might seem confused, it is somewhat, and, ironically, end result takes up very very little code space, like under 100 bytes.

Did you play with my code? ST library had the similar fashion?

You could even get away with never clearing the 256 byte LOG buffer, if the various codes/parameters lend to easy discerning, from the 'junk' in memory from a power down, power up action.

I have not spend time on it. Handling a very complex project. https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1017765/tms320f28069-need-suggestions-for-ac-input-to-adc-and-pid-controls