0
\$\begingroup\$

I am considering options to make a small circuit used with ventilation (so fitted into a ceiling) have a watchdog timer. It is not life or safety critical, but it would be inconvenient (but not impossible) to reset them with a small switch on the front that can be pushed with a pin.

I was considering external watchdog chips, but the question is, how do you prevent the chip causing a reset during programming? Details - microcontroller is PIC24FJ256GA702, programmer is ICD4. Each board will need to be programmed after assembly.

This must be a common situation, but I have not found a solution.

I am reluctant to use programming signals from the ICD to reset it until its own reset source is established, and it sounds complicated to implement and could affect programming, but this may be how it is normally done.

Any ideas? What have you done if you have met this problem before?

I don't want to use the internal WD, as I would like to be able to prove it resetting, and I like the idea of a separate device for this job.

EDIT 2023-01-07

This is the circuit I was planning to use. An advantage of the PIC24FJ256GA70X is that the /MCLR pin does not get a high voltage like 13V during programming which would be too much for the WD chip. The IO pin used on WDI is set for open-drain to allow the signal generator input. This device resets after 1.6 seconds.

STWD100 watchdog circuit with signal generator holdoff connection

\$\endgroup\$
5
  • \$\begingroup\$ Well, first question is, which external watchdog it is, as there may be multiple ways each one can be disabled. The next question is, why don't you trust internal watchdogs? And depending on what your device does, why does it even need a watchdog, if it the program it executes cannot hang and hardware it runs in does not have voltage glitches? And if it does hang, surely there must be some sort of power supply you can cut off? Maybe a external supply voltage monitor would be better than watchdog? \$\endgroup\$
    – Justme
    Jan 5 at 17:28
  • \$\begingroup\$ @Justme almost every microcontroller application should ideally have a watchdog! they are quite useful protection against accidental software bugs or glitches causing hangs. I would never question someone for including one in a design. Now, why it has to be external, on the other hand... \$\endgroup\$
    – user253751
    Jan 5 at 18:04
  • \$\begingroup\$ What level has MCLR during programming? Is it inactive at all? -- Or does the PIC run a boot loader that waits with a timeout for the programmer? If so, can the boot loader during programming generate an edge train for exactly this situation? \$\endgroup\$
    – the busybee
    Jan 6 at 10:44
  • \$\begingroup\$ These are both good points. There is a cost-benefit analysis, but as this is an on-site progject with potentially 300 of these in the ceiling, it would be great to know these things are not going to stop due to a power glitch or something. The site has a generator, and when it is tested the site is run off it, and its power does vary, as well as the switchover being less than ideal. As for internal/external, my prefernce is external, both for testing and peace of mind. But thank you both for your comments. \$\endgroup\$
    – REPuzzle
    Jan 6 at 10:44
  • \$\begingroup\$ @thebusybee Good question. The MCLR is driven by the ICD4 duing programming. From the specification, during programming, there is a singlle pulse, then it goes high, and the PGEC PGED lines actually program the device. So it can't be used itself. The PGEC clock could possibly be used in place of the signal-generator, as it is toggled during programming. But that would depend on it never being at one state for 1.6s, which I can't guarantee. As for a boot loader, I don't know- in fact, I didn't think we could change anything there. The programming mode is part of the chips design out the box. \$\endgroup\$
    – REPuzzle
    Jan 6 at 10:52

2 Answers 2

Reset to default
2
\$\begingroup\$

Maybe you could use internal power for programming, but set the ICD4 to supply Vdd, then connect the Vdd output of the ICD4 connector to the /ENABLE input of the WDT chip.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ That is an interesting approach I had not though of. Thank you for that. A possible variation on it is an testpoint to which a external separate voltage can be applied that raises the voltage on the /EN enough to disable the chip. The /EN would have a resistor to ground on the board. \$\endgroup\$
    – REPuzzle
    Jan 6 at 13:26
  • 2
    \$\begingroup\$ The ICD programming connector only uses 5 or its 6 connections, and I use an adapter to go from a 6 pin header to a small SMD Molex connector on the board. I could disconnect the 6th unused wire, and connect it to the Vdd sense so that, whenever the ICD is connected, the WD is disabled via /EN as mentioned above. (On PCB /EN would be pulled to ground with resistor.)If there was a switch on this external link, then the WD is easy to test too, making this now a complete answer. It also makes unnecessary the connection of a bulky signal generator. This is great, thank you for this suggestion. \$\endgroup\$
    – REPuzzle
    Jan 8 at 14:13
0
\$\begingroup\$

I commonly use an external POR IC in conjunction with the internal Watchdog. To signal proper Watchdog operation, i use the commonly available feature, that the Watchdog can provide an "close to reset" ISR prior to a hard-reset. Within this ISR, i set a spare GPIO to High (This pin has an external pullup and a Testpad/Series R with LED).

So in case of the controller hanging in a Watchdog-Reset-endless-loop, there will be a square-wave at this pin.

App Runs -> Low .... -> WDT ISR -> HIGH .... -> Reset .... (High with pullup) .... -> Setup .... -> Low...-> App runs. The frequency can be, depending on the comlexity of your bootcode, higher then a few Hz.

(One can show this with an LED to the user for example). If it is not hung, the pin will be low only.

The external POR-IC provides some features over a common RC-Network. So if you have 10cents/Device to spare, it is a "nice-to-have" addition. These devices are extra beneficial, if you want to share the same !RESET net across multiple devices and ensure proper timing.

\$\endgroup\$
3
  • \$\begingroup\$ How does this answer the OP's main issue? The reset of the external IC needs to be blocked during programming. \$\endgroup\$
    – the busybee
    Jan 6 at 10:46
  • \$\begingroup\$ Yes, that is the key point here. The WD mustn't reset the system during programming. But thanks for your answer, and the part about external POR chips too. \$\endgroup\$
    – REPuzzle
    Jan 6 at 11:02
  • \$\begingroup\$ @RePuzzle I was, based on the original version of the question, under th impression, that a solution is required: Which has a Watchdog and is "debugable" from the outside. Therefor i suggested not using an external Watchdog, but rather a POR to avoid power-glitching if no BOD is available in the MCU (unlikely), in combination with this debug-pin. I saw it fitting the requirements. \$\endgroup\$
    – ElectronicsStudent
    Jan 6 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.