Go Down

Topic: Something fishy in attiny 44a watchdog (Read 708 times) previous topic - next topic


I use attiny 44A as a piezo-switch for a battery-pack. Voltage from piezo-disk is read with ADC and same disk is also used as a beeber by changing pin temporary to output. I need to utilize watchdog reset to prevent my app from freezing in any condition. However, I have struggled a while to get my watchdog to work properly.

It seems that after being reset by a watchdog, ad-converter is not working properly or something weird is happening in my app.

I set up the watchdog to reset my app after 1s timeout by calling  wdt_enable(WDTO_1S) at startup. In main app-cycle, I call wdt_reset(). After reset, my program enters in a state where piezo-voltage is read with adc. If button (piezo-disk) is not pressed, program enters in a power-down state. If button is pressed, application stays awake until it is shut-down by user action.

My program works properly if I use WDT interrupt instead of reset. When using wdt reset, button press can't be recognized properly. If I add beep-sound to my code, it confirms that app is actually awaken. My ad-pin is configured as input in setup.

My program should not block more than couple of hundred milliseconds, so wdt_reset() should be called frequently enough. I have also tried to disable watchdog when my application do something, but it had no influence on the problem.

I have searched about the topic, and found out there are several posts which indicates weird behaviour when using watchdog. However, I haven't find anything similar to my problem.

As far as I see, I'm doing everything right. Could there be something in Arduino libraries which are incompatible with my use-case? Sounds weird, because this is the typical case how watchdog should be used. Watchdog reset should be as good as power-on reset. Memory content is preserved, so uninitialized variables can preserve they values. My app has no dependencies on uninitialized global variables. I hope Arduino libraries have neither.


Post your code.
Post schematic.
Post more details about the symptoms (what values is it getting on the ADC? Use softwareserial, or the builtin software serial on my core (on the AIN0/1 pins - see the core documentation for details)) to print it out and see what values you're getting.

I agree that your understanding of how it should work is correct. It may indicate a bug in your code, a flaw in your hardware, or a bug in the core, but without much more information, I couldn't hazard a guess of which it is.

Here's another test - does it work when you pulse RESET low? (as opposed to power cycling it)
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy


Thank you for you answer. It already help to know that it should work and I have not missed something obvious.

I attached the schematics of my card as well as entire program. I tested the program with ATMega 2560 using debug-prints, and it seem to work properly. Piezo is connected between st5 and st6.

I did not implement serial debugging capability on my board and it is already coated with lack and installed on my battery-back, so it is not that easy to add. Also I can't use AIN 0 and 1, because they are already in use.

If I don't find a reason for the problem, I try to add SW serial to some other pin or use pwm and oscilloscope to debug the values.

Pulsing RESET worked OK when I had watchdog disabled. With watchdog, it does not seem to work any better than WD reset. It is little had to say for sure without modifying the program. Operational mode requires six button presses within 4s. I only know that it wakes up, but don't recognize button pressing.

I have checked the power in my card with oscilloscope, and it stays very constant in every situation. It is possible to get voltage levels over +5V or below 0V when pressing piezo-button very hard. Ad-input internal clamping diodes should take care of that because impedance is very high. The problem exists even when button is being pressed gently. Mosfets have relatively low gate-charge, and I have 50ohm resistor at the gate to limit peak current. Mosfets are not switched on at startup.

There is some code commented out. I used it when I first run the code using 16ms watchdog to time my loop instead of delay(). However, operating-mode power-consumption is no issue for me, but I need low-power deep sleep when being nonoperational. I need also robustness that WD gives.


I'm confused - the code you posted appears to use the WDT in interrupt mode, not reset mode, yet you say that the problem occurs with the WDT in reset mode? Post code that shows the problem, not code that works.

Also, which third party hardware package (aka "core") are you using? There are at least two maintained cores (mine and damellis') plus dozens of abandoned forks of various cores, and some may have issues that others do not, so it's crucial to know which one you're using.

IIRC there was something you had to do after a WD reset; take a read through the whole chapter about it in the datasheet, I remember running into it, but I forget how I fixed it.
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy


The part of the code that uses interrupt mode is commented out. setup() uses  wdt_enable(WDTO_1S) instead of setupWatchdogTimer(), which is for interrupt mode.

Code that is in use, is exactly the one I tested in my own board. It didn't work there but same code worked in atmega 2560.

There are also some prints commented out. I used them in atmega, where I originally tested the code.


Just a guess: try to clear MCUSR in setup(). Just use
as soon as possible in your program. Also note going into power down sleep does NOT stop WDT - I did not check your program if it is handled properly.


I can clear MCUSR and see if it helps. At least it should not cause any problems. I don't use it's content to identify reason for reset, but maybe some of the libraries does.

Watchdog staying operational during the power-down is needed feature for my program. It is supposed to wake it up once per second to check the button. Since I use piezo, I can't use pin change interrupt without external electronics and I wanted to keep threshold level SW configurable.

My idea was that wake up through the reset should be same as initial start, but as you stated, MCUSR is at least one difference.


When Watchdog resets AVR is stays "armed" until corresponding flag in MCUSR is cleared - it cannot be turned off or changed to other than reset mode.


Seems that this problem was mostly caused by some problem with some mes-up with arduino cores. I reinstalled latest Arduino ide, and application started to work also in my own board. I will write description of my problems from the start. It might interest someone.

First I used core  'Attiny bu David A. Mellis 1.0.2'. I had a problem where my board was in boot loop. It was solved when I installed DrAzzy's core. However, when compiling, I still got warnings from some other core, even when I had uninstalled everything but DrAzzy's core. My app worked well, except this watchdog related stuff.

Yesterday, when flashing my app, I got message from incorrect MCU. DrAzzy's core had disappeared from my boards menu and the old deleted one was back. I chose Atmega 2560 as a board, and after that, DrAzzy's core was back in a list. After choosing it, I was able to upload my app, but I had that boot-loop problem again. Flashing obviously succeeded, but app run only about 100ms before reboot.

Then I uninstalled my Arduino ide and installed latest version. Same time I removed my board from battery-back where it was permanently soldered (I was not able to cut the power without desoldering wire). When I attached it into power again, app started to work. In previously flashed version, I had disabled the watchdog, so I don't know if it worked already.

Now as I flash the app with new ide, I don't get any warnings and app seems to work properly even after watchdog reset.

The most important lesson is that having something messed up in board configuration files, can cause pretty weird problems. It also seems that reset does not completely reset AtTiny 44, and detaching power is sometimes required. In yesterday's version I had MCUSR cleared in setup().

During original boot-loop problem, my board wasn't soldered in, and power was cut off frequently

Go Up