What could prevent the start of a microcontroller?

Question

Problem description

I've got occasional startup issues on some boards with an ATmega2561. On about 10% (seems to fluctuate a lot) the processor does not seem to start on first power on. Only a power cycle lets the MCU start.

I've researched online and tried different things. I made several hypothesis and tested them but I have been able to disprove all of them.

I've checked the datasheet several times but could not find any clue as to what I could be doing wrong.

Reproducing

The Problem shows itself in the following way:

1. Switch on power
2. Sosftware won't start (no communication on UART no LED-blink, both of which should happen when the software runs.)
3. Switch power off and wait 10s
4. Switch on again
5. Microcontoller starts

If I switch off the power for >3 minutes the problem appears again. If a board has the problem it's perfectly reproducible. Replacing the microcontroller solves the problem.

I've also checked the power. The microcontroller runs at 5V. The 5V switches on within a few microseconds and is rock solid stable (checked with an oscilloscope and multimeter in Min/Max-Setting.)

Also: I can program the microcontroller via ISP if it is in that hung state.

Hypothesis

Hypothesis 1

External ceramic resonator does not start because of wrong fuse settings

I could disprove that by measuring the frequency with an oscilloscope and by setting the microcontroller to use the internal R/C oscillator (which should start.)

Hypothesis 2

Something with the external reset circuit

Reset/ is high and stable 200ms after power on (that's the time the external reset is pulled low).

Hypothesis 3

The MCU is in some undefined state for some unknown reason after startup

Pulling reset low for any amount of time did not get the microcontroller started.

It seems I'm out of ideas. What's more: This board has a bootloader which I use to load an application. If there is a valid application the bootloader immediately starts the app in its first line of code. The problem exists independently of state. It does not start into bootloader or application. If it's not a hardware issue it must be software, but the only thing common between application and bootloader is basically one line of C-code (that calls a few functions to read from EEPROM and FLASH to check if a valid application is installed.)

Does anyone have an idea on how to tackle this problem? Could it be a software issue? Why does it not happen on all the microcontrollers?

Update:

As suggested in the comments I've measured AVcc in relation to Vcc during power on.

Channel 1 (yellow) is Vcc, Cannel 2 (cyan) is Aref

That seems to be the problem. Aref (and also AVcc) is rising much faster than Vcc.

SOLVED! (at least it seems)

Adding a resistor in front of the LM7805 that creates the Aref and AVcc to limit the current (and therefore charge the capacitors slower) brought the AVcc on after Vcc and now a board that had the problem boots normally.

(

AVcc (yellow) and Aref (cyan)

Answer 1

How you power the MCU can be the source of problems.

Applying voltages to IO pins and AREF pin before main digital VCC and analog AVCC supplies are applied means that protection diodes from IO pins to supplies have to conduct input clamping current to supply pins, which puts extra stress to internal MCU structures and might raise the supply voltages and power on the MCU with voltages lower than expected. MCU might end up in some unexpected internal state where it does not run properly even after a reset pulse. One such problem might be a latch-up condition, which does get solved only by removing power from circuit.

The updated question shows that AVCC and VCC have about 1V difference between them during supply rise time, so their difference exceeds the safe limits of 300mV.

Answer 2

The usual suspects here would be:

• Crappy power supply with transients etc.
• Wrong capacitors on reset or power pins.
• MCU supply pins getting powered up at different points in time. If you for example have a relatively fast high precision LDO as V_ref to an ADC, but power the MCU as whole from a relatively slow switch regulator. This will lead to latch-up or low-voltage detect kicking in.
• Bad soldering of MCU or external quartz/external resonator. Or in case external PLL filters for the system clock are used - issues with wrong component value choices.
• Incorrect configurations of other vital pins such as mode select/test mode pins etc, where you deviate from manufacturer recommendations for whatever reason.
• CRT (C language run-time) written by quacks. In many cases, the CRT delivered with the tool chain is broken and doesn't handle fundamental things like setting up watchdog and LVD or setting up external clocks before running all initialization code. So in case you keep on adding variables to the program, the CRT will eventually go haywire during start-up, or maybe never finish before watchdog timeout, since it was designed by incompetent people. Roughly some 90% of all CRTs on the market have design problems like these, or I have at least yet to see a correct one.

Answer 3

I also faced the same problem, that is, the MCU wouldn't start up even though there is no problem with Vcc = 5 V.

After I read all comments above, finally, my problem was solved. What I did is add a 10 μF cap as close as possible to the MCU Vcc pin. That's all. My MCU started working.

Answer 4

How are you identifying "not starting up"? What else is on the board with the MCUs? Is there anything that would stall the MCU if it was too slow powering up? Perhaps another IC that the MCU is expecting to respond to a serial message?

Because if there is the, most likely culprit is software.

No two components are the same. There's no reason to expect two MCUs to take the exact same amount of time to power up and start executing code just like there's no reason to expect other components to take the same amount of time powering up.

All that needs to happen is for an MCU that starts up a little bit faster to be paired with auxilliary components that start up just a little bit slower.

Make your MCU code wait a bit after on power up before it actually starts doing anything.