12
\$\begingroup\$

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.

CH1: Vcc, CH2: Aref

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.

(CH 1 = AVcc, CH2 = Aref

AVcc (yellow) and Aref (cyan)

\$\endgroup\$
15
  • 1
    \$\begingroup\$ At least schematics is required to see problems. I recall investigating AVR boards that did something similar. But yes, power-up event and reset are important. The problem is, even if powerup looks good, it may be not reliable if some power trickle in via IO pins. \$\endgroup\$
    – Justme
    Commented Jan 21, 2022 at 6:18
  • 2
    \$\begingroup\$ That is definitely a red flag. Please post oscilloscope diagrams of VCC, AVCC and AREF waveforms at power-on. And power-off. \$\endgroup\$
    – Justme
    Commented Jan 21, 2022 at 7:48
  • 1
    \$\begingroup\$ If supply to some Vref lags behind main power supply that shouldn't be a problem. The other way around is definitely a problem, I've had that very problem before and it wasn't trivial to find. \$\endgroup\$
    – Lundin
    Commented Jan 21, 2022 at 10:00
  • 1
    \$\begingroup\$ @kruemi Some MCU manufacturers might mention power-up sequences somewhere, but if so that information is found somewhere deep inside the datasheet. When I got this problem myself, it definitely manifested itself like a latch-up, I had to cycle power to restore it. Then upon further research in the software, I also noted that the MCU LVD kicked in whenever this happened. We solved this by feeding supply to the fast LDO Vref from after the slower main 3V3 switch regulator, rather than from a raw unregulated voltage. That fixed the problem but it is less ideal for signal integrity and EMC. \$\endgroup\$
    – Lundin
    Commented Jan 21, 2022 at 10:52
  • 2
    \$\begingroup\$ I'm a software engineer who stumbled across this question via Stack Exchange's "Hot Network Questions". I was really disappointed that "MCU" didn't stand for "Marvel Cinematic Universe". I think I need to go back to my little hole in Stack Overflow now... \$\endgroup\$ Commented Jan 22, 2022 at 4:15

4 Answers 4

14
\$\begingroup\$

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ So during startup the difference between VCC and AVCC can be about 1V, clearly out of 300mV specs. It is not said if 300mV is absolute maximum but you should not count that this is OK. The voltage also rises more than 4.5V in 1 ms. Depending on silicon revision, some revisions must have slower slew rate than 4.5 V/ms. \$\endgroup\$
    – Justme
    Commented Jan 21, 2022 at 10:36
  • \$\begingroup\$ It seems that the Problem was, that either Aref or AVcc were rising faster than Vcc. Would you like to edit your answer? I'd mark this as the solution than. \$\endgroup\$
    – kruemi
    Commented Jan 21, 2022 at 11:18
10
\$\begingroup\$

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 Vref 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.
\$\endgroup\$
1
  • \$\begingroup\$ uIt was the power supply pins that got powered up at different times. AVcc (and Aref) are powered via an linear regulator which switches on really fast. Vcc is generated via a switching regulator with quite big capacitors so it takes longer to get the desired output voltage. The Microchip datasheet doesn't say anything about timing but about maximum voltage differences (0.3V) and those were (significantly) violated during startup. \$\endgroup\$
    – kruemi
    Commented Nov 11, 2022 at 10:36
2
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ The ATMega2561 is quite "Standalone". It does not depend on much. It has external EEPROM connected to SPI and I2C but those are not used during startup. It has a level shifter for 2 RS232 connections (removed that and got on it with TTL, didn't change)... It's a relatively simple board with some H-Bridge drivers on the GPIO (sorry, can't supply the schematic... reasons)... \$\endgroup\$
    – kruemi
    Commented Jan 21, 2022 at 6:30
  • 2
    \$\begingroup\$ I always assumed that the MCU does not start... but It could be hanging in an early loop. ''' unsigned char EEPROM_read(unsigned int uiAddress) { /* Wait for completion of previous write / while(EECR & (1<<EEPE)) ; / Set up address register / EEAR = uiAddress; / Start eeprom read by writing EERE / EECR |= (1<<EERE); / Return data from Data Register */ return EEDR; } ''' Code is from datasheet, but it's mostly identical to our code (especially the while at the start). If this flag is set it would make sens to be not cleared by reset. But why would it be set? \$\endgroup\$
    – kruemi
    Commented Jan 21, 2022 at 6:37

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.