4
\$\begingroup\$

I have an AVR circuit for which I have connected its clock-out pin some other circuits external clock and the other pins operate various other things. By using an oscilloscope, I have found that the AVR chip (both attiny4313 or atmega8535) will run at a slower speed after its power source has been disconnected and reconnected.

The chips in the circuit in question are connected to a 20mhz resonator to xtal 1 and xtal 2. Here is how I recreate the issue:

1) Connect power and ground.

2) burn fuses for external oscilator with clock out

3) press reset button

4) clockout shows 20 MHz on scope, other circuits run at proper speed.

5) Disconnect battery (from the L7805 regulator)

6) Connect battery back to the circuit

7) main chip is now running at around 8 mhz, no nother circuits are running properly.

8) Reburn fuses

9) Works properly at 20 MHz now.

The issue happens with a attiny4313 and an atmega8535.

Test circuit that reproduces the problem

EDIT: The image is a test circuit that I am using to try and figure this out. It allows me to reproduce the problem.

why is this happening? How do I prevent it from happening?

Additional notes:

Brown out detection at 4.3 V does not fix the issue.

Programmed with an arduino uno as ISP with avr-gcc (latest ubuntu version)

\$\endgroup\$
11
  • 1
    \$\begingroup\$ This does sound rather strange - as if the controller somehow forgot its fuses. Did you read back the fuses after reconnecting the battery? Were they ok? \$\endgroup\$
    – Jonathan S.
    Commented Mar 3, 2018 at 16:11
  • \$\begingroup\$ I attempted to upload a new program to the chip (while in a malfunctioning state), and the fuses were read back as the values they should be to use external clock at 20 MHz. \$\endgroup\$
    – Cygnuson
    Commented Mar 3, 2018 at 16:17
  • 1
    \$\begingroup\$ What happens if after reconnecting power you explicitly cycle the hardware reset? Power cycle resets can be uncertain if all voltages in the system have not decayed to zero. Sometimes capacitors will be discharged to the point where the power hungry circuit goes offline but other parts may retain micropower state. You may need to configure a brownout detector, or wait longer. Also note that anything connected to your system like a serial interface may inject enough current to cause partial state to be retained, causing the next application of "real" power to fail to fully initialize. \$\endgroup\$
    – Chris Stratton
    Commented Mar 3, 2018 at 17:06
  • 1
    \$\begingroup\$ also, that thing you call a reset button isn't (standard practise is to at least have a cap to ground, but normally a proper reset controller), due to switch bounce - it will likely be issuing multiple resets milliseconds apart and possibly of microsecond duration (check datasheet for needed reset timings) - and, just a hunch - which could be putting the MCU into an undefined state - like not operating per its fuses and instead somehow running off its internal 8MHz oscillator... \$\endgroup\$
    – Anthony May
    Commented Mar 3, 2018 at 19:46
  • 1
    \$\begingroup\$ Thanks @Techydude, The problem was with the reset button. The partial fix was a 0.1uF cap, moving to a 10uF fixed it fully. If oyu post and answer, I will accept it as the answer. \$\endgroup\$
    – Cygnuson
    Commented Mar 3, 2018 at 20:12

1 Answer 1

Reset to default
2
\$\begingroup\$

That thing you call a reset button isn't.

Switch bounce will likely be issuing multiple resets to your MCU milliseconds apart and possibly of microsecond duration, and possibly spending time in indeterminate logic states. You should check the datasheet for needed reset timings. My hunch is this spurious multiple out-of-spec reset pulses is putting the MCU into an undefined state - and apparently not operating per its fuse configuration, and instead running off its internal 8MHz oscillator*.

Standard practise is to at least have a cap to ground, at least 100n, but more likely 1uF..10uF depending on the reset timing specs and, more importantly, the bounce characteristics of the switch, which normally have to be estimated empirically (i.e. watch what RESET is doing with on an oscilloscope). Putting the switch/pull-up/cap through a schmigger can help a lot too. But normally a proper reset controller chip is used to deal with the reality of switch bounce in imperfect mechanical switches.

  • This is in the same realm of the fuzzing of power rails and other critical signals - like RESET - used by hardware hackers to put the MCU into certain states, for example to read out code, when that read-out functionality should not be possible due to fuse config.
\$\endgroup\$

Your Answer

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

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