Go Down

Topic: ATMega328 startup reset unreliable? (Read 3357 times) previous topic - next topic


This is a bit of a puzzle.

I've been building Hydras for a while now. The latest schematic is at http://www.kfu.com/~nsayer/hydra/hydra_2_2.pdf

After building, oh, about a dozen boards, I've got one with a weird problem: it won't reliably start. I connect up the ISP and the LCD will show the top row of just boxes. If I briefly short RESET, the display will show the sketch starting up normally.

I'm using FF / DA / 05 as the fuse setting. I've tried raising the brownout voltage (4 instead of 5 for the extended fuse), but that didn't help.

I tried swapping out the processor, and that didn't fix it either.

Anybody have any thoughts?


Wonky crystal? (What's a Hydra, anyway?)


Reset resistor the correct value and making good contact?
DTR capacitor the correct value and making good contact?
How is reset applied? May need a diode across the reset resistor,  anode to reset pin, cathode to +5. 1N4158 or similar. '328P may be going into high voltage programming mode from spikes on the reset pin from the switch/capacitor interaction.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.


The Hydra lets you share a EV charging station with two cars. A pointer to the schematic is in the first message in the thread. For the purposes of this discussion, it's a 16 MHz ATMega328P TQFP fused the same as an Uno, but programmed via ISP rather than with a bootloader (though there is an FTDI header that can optionally be used for serial programming if you close the DTR_RESET jumper and use ISP to load a bootloader).

In this case, there is no DTR connection (well, there is, but there's an open jumper disabling it since I use ISP programming), and there is no reset button. All there is is a 10k resistor to Vcc and, of course, the ISP header pin (along with the .1 µF cap to the open jumper that would ostensibly go to DTR). All of the parts involved pass a visual inspection, at least, and I have tried swapping out the controller.


I may have fixed it, but I'm not sure.

I saw a tiny scratch in the silkscreen/mask near the .1 µF DTR_RESET cap. There is a ground plane under that mask. It didn't look like it was touching anything, but because I had no other theories, I heated up the cap and nudged it a tiny bit further away (this is all SMD) from the scratch. I haven't been able to reproduce the problem since.

What I can't wrap my brain around is that if RESET was being held low, then it would never work. What sort of defect would explain an unreliable power-up reset, but a fully functional system apart from that?


I agree with CrossRoads, try a diode wired from the reset pin to +5vdc with cathode wired to +5vdc. If you look at the current uno design schematic you will see that they added this diode in Rev3. It was a very erratic bug that many did not ever see, but could be reproduced so the arduino folks added the diode.



Looks like there will be a v2.3 board... :)


Well, I was wrong. The problem is back on that one board. I will try adding a 1N4148 diode from RESET to Vcc and see if that changes anything.


Well, I was wrong. The problem is back on that one board. I will try adding a 1N4148 diode from RESET to Vcc and see if that changes anything.

Cool, let us know if it helped.


It didn't make any difference, but in the meantime, I found and fixed (for sure this time) the problem.

I thought that the dead display was the symptom of the controller not running. In fact, the sketch was working, as I discovered when I ran it in a more complete test harness and it actually powered up a car with the display still showing the box-row.

My focus turned immediately to the MCP23017 that drives the display. I didn't see anything obviously wrong with it, but I reflowed the RESET pin just on general principles and the symptom went away and has not returned.

It's still sort of odd that resetting the controller would bring the display controller back to its senses - the MCP23017's RESET pin is tied hard to +5, it's not shared with the ATMega. The only thing I can figure is that a poor connection let it float just long enough to prevent init() from doing the right thing. Go figure.

Go Up