3
\$\begingroup\$

Problem description

I've got accassional starup 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 disporove 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. SW won't start (no communication on UART no LED-Blink (which both should happen when the SW runs))
  3. Switch power off and wait 10s
  4. Switch on again
  5. MCU 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 MCU solves the problem. I've also checked the Power. MCU runs at 5V. The 5V switches on within a few microseconds and is rock solid stable (checked with Oszilloscope and Multimeter in Min/Max-Setting)

Also: I CAN programm the MCU 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 MCU 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 MCU started

So, 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 it's first line of code. The problem exists independently of state. It does not start into bootloader nor application. So 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)...

Anyone has an Idea on how to tackle this problem? Could it be a software issue? Buth than, why does it not happen on all the MCUs?

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 And there 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. Thanks everyone!

(CH 1 = AVcc, CH2 = Aref AVcc (yellow) and Aref (cyan)

\$\endgroup\$
11
  • 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
    Jan 21 at 6:18
  • 1
    \$\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
    Jan 21 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
    Jan 21 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
    Jan 21 at 10:52
  • 1
    \$\begingroup\$ You should also give credit to @Justme who was the first to point out this potential problem, even though I would have suggested it as a potential culprit too, regardless. If this was verified to be the issue, you could accept their answer. \$\endgroup\$
    – Lundin
    Jan 21 at 11:26

3 Answers 3

Reset to default
8
\$\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\$
12
\$\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
  • \$\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
    Jan 21 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
    Jan 21 at 11:18
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
    Jan 21 at 6:30
  • 1
    \$\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
    Jan 21 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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