Weird Arduino state

Other Hardware 3rd Party Boards
1

Hi, I'm new to Arduino. I've been working on an intercom project recently and I want to make it fail-safe. I even updated bootloaders on my Nanos to make the watchdog work properly on them and did some tests. At first, I wrote a simple program that sets the watchdog timer to 2s and delays the loop by 3s to trigger the watchdog, it worked as expected - Arduino was restarting every 2s. However, I noticed there is an Arduino state where the program goes wild, e.g. Serial stops working or pins swap their places, but the loop works and resets the watchdog timer as normal. It's a difficult situation because the program becomes completely useless, and it seems even the watchdog is powerless here.

The simplest way to bring this state on is to touch the Nano in such a way that your finger touches several Atmega pins and the oscillator at the same time while the program is running.
original

And here is the simplest code to see it:

#include <Arduino.h>
#include <avr/wdt.h>

unsigned long gLastResetTimestamp = 0;

void setup() {
    wdt_enable(WDTO_2S);
    Serial.begin(9600);
}

void loop() {
    bool is_need_to_reset = millis() - gLastResetTimestamp > 1000;

    if (is_need_to_reset) {
        wdt_reset();
        gLastResetTimestamp = millis();
        Serial.println("Successful wd reset, TX diode flashes");
    }
}

If the program was reliable, the TX diode should flash every 1s no matter what, but it stops forever when the above-mentioned state occurs.

Here is my question. Is it possible that this state will ever occur due to some interference? If so, is there a way to detect it and write a program that is able to make a recovery from it automatically?

2
  • What do you think is happening here ?

bool is_need_to_reset = millis() - gLastResetTimestamp > 1000;

3

I'm not seeing that behaviour with your sketch loaded into a Nano and my finger resting on the CPU and crystal.

4

I find it better to extract the condition to a variable with a meaningful name for better readability and then place it in an "if" statement. This may seem a bit excessive here, but in large projects with more complex conditions it enhances readability a lot and I'm used to doing it this way. For me, the code above looks just better than something like that:

#include <Arduino.h>
#include <avr/wdt.h>

unsigned long notMeaningful_name_anyhowCase = 0;

void setup() {
    wdt_enable(WDTO_2S);
    Serial.begin(9600);
}

void loop() {
    if (millis() - notMeaningful_name_anyhowCase > 1000) {
        wdt_reset();
        notMeaningful_name_anyhowCase = millis();
        Serial.println("Successful wd reset, TX diode flashes");
    }
}
5

It doesn't always work, in my case it has to be touched here couple of times or just a little harder.

6

Still not seeing it. Have you verified that it happens on another board, and it's not simply a cold solder joint or the like?

7

Yes, it happens on a different board as well.

8

Well, I can't duplicate it here.

9

Place the nano on unfinished wood and press the same area with a wood stick. (not plastic, not your other finger - those carry charge).

What do you observe?

10

Here is a video:

nano (youtube.com)

If I press this area with something else than my finger, it won't happen.

11

You are conductive and a capacitor.

12

Yes, I know.
It's not about making the board invulnerable to being touched, as the board is normally never touched during operation, however some other kind of external interference may occur and I am concerned whether it might cause the same issue we see when the specific area is touched.

13

Recall the wood stick.

15

This implies that in your experiment, you're destabilizing the oscillator, which means the internal clock will become unstable. I can well imagine this puts the microcontroller into an undefined state, especially if several internal clocks happen to become desynced (e.g. peripheral clocks are often derived from the core clock through a divisor).

I'm not sure if there's a good way to recover from this, since any code used to detect this would still rely on proper functioning of the microcontroller core itself. I suppose you could do something with an auxiliary microcontroller that checks proper functioning of the main unit, or even a pair of controllers running in a redundant setup and a separate mechanism checking them against each other. These are the sort of solutions you'll encounter in high-reliability computing.

However, for a regular hobby or even industrial project, all this is way overkill and you simply ensure that a clock circuit is reasonably stable (component choice, board layout) and isn't easily messed with by outside factors. There's not all that much you can or need to do.

2 Likes
20

all this is way overkill

Pretty much.
You design to the expected conditions. If your concern is that someone touching the circuit can cause it to become unstable, well, the simplest solution is to make sure that they can't touch it. If that's not enough, then go from there.

As far as why the watchdog isn't being helpful, ISTR that the AVR devices use the main clock to run the watchdog. You'd need to go to another chip family like STM32 that has an independent watchdog clock to work around this problem.

1 Like
21

I've removed some inappropriate comments and associated replies. Some replies were also inappropriate, some were ok but it doesn't make sense to delete some and leave others in, so they are all gone. No penalties but any more inappropriate comments will result in a time out from the forum if I see them.

Now please either help the OP or say nothing.

OP please appreciate that the people helping you are volunteers working in their spare time, as are the moderators.

I thank you.

22

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.