MCU Reset via external watchdog timer while first time programming

[RV.4]

Hi,

We are facing some challenge with external watchdog timer and STM32H7855xi. when there is no program in flash input to external watch dog timer (WDI) is output and no pulse . during this time external watch dog timer continuously generate reset pulse to microprocessor pin (nRST which is default of pull up) .

when we trying to program through JLINK pro external watch dog timer not allowing to program , it continuously resetting the processor , we need to manually separate external watch dog timer reset pin from nRST pin by removing R69 as per given schematic.

Do you have any suggestion to avoid manual intervention 

[Tesla DeLorean]

You'd need to write loaders that will kick the watch dog. Perhaps use the system loader, push in code to RAM within the response window, and start executing that.

[jacobq]

I am facing a similar problem and decided to solve it by adding a series resistor at the watchdog refresh pin then connecting that refresh pin to a spare pin on our debug/program connector and having an external oscillator continuously pulse that refresh pin to prevent reset while the debug adapter is connected. This effectively "defeats" the watchdog while the debug adapter is connected (also handy for being able to use breakpoints!) but not otherwise. (I also recommend using a direct/spring connector like SKEDD or TagConnect, but that's up to you.)

Relevant part of the circuit looks something like this:

[Chris21]

We have designs that force nRST high when the programming cable is connected.

[jacobq]

That is also a solution, though in some cases this has unwanted side-effects, such as when the SWD pins are used for other functions in application and require a hardware reset from the debugger/programmer to be able to use to reprogram.

[Lin_Yishan]

When the time required to see the door reset is not so harsh, the watchdog reset time can be extended by changing the organization of the resistance. Some watchdog chips have a broken control pin (default is pulled high), which can avoid this situation.

[jacobq]

Yes, extending the refresh window can reduce the severity of the situation (lower likelihood of reset happening during programming process), but this can have safety implications (now a crashed program can run longer without being detected or reset). If you are able to speed up the programming process (e.g., by reducing the size of the program -- possibly splitting it into a bootloader portion and an application portion -- or by using faster SWD clock speeds) that can also improve the situation. Either way though, there will still be times that the reset signal might interfere (e.g., coincidence / unfortunate timing).