Barebones atmega328p verification errors when run at 3.3V - works fine at 5v

[ebattaglia42]

Hi,

This is my first time posting, so sorry if this is the wrong forum or if I missed a previous relevant thread. I've been researching this issue for several days now so hopefully I'm not reviving a resolved issue.

I have a bare atmega328p chip on a PCB. The only other components on it are some decoupling caps (20uF) and a a pullup for reset (10k).

I can upload code or the bootloader just fine when running the chip at 5V. I have tested both 1MHz internal clock and 8MHz. In both cases, when I then try to use a 3.3V programmer, the upload fails to verify. The location in memory of the verification failure depends on the sketch/bootloader I upload. I am using the minicore package.

5V programmers tested: Arduino as ISP (nano clone), USBtinyISP, USBasp (slow)
3.3V programmers tested: Arduino as ISP (Seeduino XIAO, Sparkfun Redboard Turbo) and USBasp (slow) with 3.3V jumper

Debugging has been hard because in the process I've burnt out several chips, and I'm hand soldering QFN packages so I get a lot of errors related to improper connections. However, I've done tests where use USBasp at 5V to upload the 1MHz config, switch the header to 3.3V, and the same upload fails. Switching the header back to 5V works immediately. I have tested on two different USBasp's.

I don't have a much experience with AVR fuses, so if someone has a suggestion in that direction, guidance would be much appreciated!

My boards are back at the lab so I don't have the logs right now, I could definitely upload them tomorrow if it helps.

Thank you guys so much!

[gilshultz]

It sounds like posting the Schematic, not a frizzy thing, will help a lot. It appears capacitors are a nono in your book, how about high frequency bypass. what does the data sheet tell you about the clock circuit and are there any differences between 3.3 and 5V. What is your clock base. A lot of things are unanswered at this point which a schematic will help to solve. I think you are lucky it operates on 5V.

[ebattaglia42]

gilshultz:
It sounds like posting the Schematic, not a frizzy thing, will help a lot. It appears capacitors are a nono in your book, how about high frequency bypass. what does the data sheet tell you about the clock circuit and are there any differences between 3.3 and 5V. What is your clock base. A lot of things are unanswered at this point which a schematic will help to solve. I think you are lucky it operates on 5V.

Thanks for the response! Sorry, I'm a little confused with the terminology here. What do you mean by frizzy thing? And what are you suggesting regarding capacitors? - It's my understanding that 20uF from Vin to GND would be sufficient, unless bypass and decoupling mean different things here? I'm more than willing to include whatever I need to in this circuit to figure out what's going wrong.
Regarding the datasheet, I've read through the section on the system clock and as far as I can tell, the 8MHz internal oscillator (and by extension the 1MHz internal oscillator) is well within spec at 3.3V.
A picture of my schematic is attached. I should mention that on my PCB at this time, no components are connected except the atmega, the two 10uF caps, and the 10k pullup resistor. The ISP pins are broken out to a header, which is how I am uploading code. Everything else would normally be connected to peripheral devices, but as of now are just floating while I debug this.

[srnet]

I have has ATmega328Ps, bought cheap from the far east, that will program and work at 5V but not at 3.3V.

[ShermanP]

If you successfully upload a sketch at 5V, such as a Blink sketch, does it then run properly at 3.3V? Is this just a flashing problem?

When attempting to upload code at 3.3V, is there any sag in the voltage at the 328's Vcc pin?

I don't think minicore would be a problem, but if you want to try the standard method, take a look at the "Minimal" section near the bottom of this link:

From Arduino to a Microcontroller on a Breadboard

You'll end up with a new IDE Board selection called "ATmega328 on a Breadboard (8MHz internal clock)". The boards.txt for it reads as follows:

##############################################################

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0xE2
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.mcu=atmega328p
atmega328bb.build.board=AVR_ATMEGA328BB
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard


atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

Note: change the extended fuse from 0x05 to 0xFD. It's the same setting, with the unused fuse bits set high.

[DrAzzy]

The ArduinoToBreadboard page is awful. Like OP's schematic, it leaves out the REQUIRED 0.1uF decoupling capacitors, for one thing!

A 10uF capacitor or two provides board-level decoupling, and I'd never build a PCB with less than 4.7uF of board decoupling. But that does not replace the 0.1uF decoupling caps. People with more formal electrical engineering training than I have will draw graphs showing how a 10uF cap can't filter high frequency noise. I've never been able to follow why larger ones don't work, but I I've been told that enough times that I accept it.

Certainly, a problem caused by insufficient decoupling caps of the proper values, or their not being located as close to the power pins as possible, would be more likely to result in failures when running at a lower voltage, so, OP, go add those 0.1uF caps and see if that sorts it out

Also, just use MiniCore for custom '328p/pb and similar, you don;t have to mess with boards.txt.

[jremington]

Decoupling caps should be 100 nanofarads (nF), not 10 uF, and they should be ceramic, mounted as close as possible to Vcc and Avcc and Aref. This is a good tutorial.

[ebattaglia42]

[Edited because my post got cut off]

Thank you all for the fantastic advice! Some more information based on your replies:

The chips were bought from digikey, the only 28 pin VQFN available there so hopefully they are authentic.

After programming a sketch at 5v, it works fine at 3.3v. The issue with that is I would be unable to program the chip after populating the board, which is filled with 3.3v devices on the same power rail. I would love to get the code entirely finalized on a breadboard, but this not possible for this application. The PCB will be fitted to a quadcopter with the form factor of a 40mm grenade, and the code will need tweaking after some test launches. I could desolder the VQFN every time I want to program, but that would be fairly frustrating.

I monitored the voltage with an oscilloscope at 40MHz while uploading, and the minimum detected voltage was 3.31V. I would guess that that's not a guarantee though.

I'll definitely try you guys' suggestion of smaller, ceramic caps as close to the chip as I can get them.

BTW, I was able to upload code at 3.3V yesterday with an FTDI adapter! I'm super happy that I can continue development, but I'm still curious as to why ISP won't work. Also, I'm stressing the atmega's flash size, and the few extra bytes saved by overwriting the bootloader might help me a bit.

I attached the PCB for reference, just in case there's something strange about it. The 3.3V power plane and the GND plane are hidden in the image. The atmega is the VQFN package at the bottom, and one of the caps is due north of it. Please don't judge me too hard for the layout and routing lol.

[hzrnbgy]

I also had issues programming some of my custom built boards. These DIP Atmega328Ps are from Mouser so they must be authentic. All have the correct 0.1 uF caps on all VCC-GND pairs, except those on the voltage regulators which are higher. My success ratio for programming is about 1/10 (only works 10% of the time), and I'm using AVR Dragon (ISP). Also fails during the chip verification stage. Can you try using a higher pull-up resistor on the RESET line?

[CrossRoads]

Aref should not connect to 5V, or 3.3V, it should only have a 0.1uF cap to Gnd.

Your routing also seems to show several unconnected traces (air traces).

[ebattaglia42]

CrossRoads:
Aref should not connect to 5V, or 3.3V, it should only have a 0.1uF cap to Gnd.

Your routing also seems to show several unconnected traces (air traces).

Thanks! I'll make sure to change that in the next revision. Do you know what problems that could cause? As far as I can tell, my ADC has been working as expected. Do you think it would be safer to cut that trace for now and leave Aref unconnected, or to leave it connected to 3.3V/5V?
Regarding the airwires, those go away when the board is ratnested and the power planes fill in.

[ShermanP]

ebattaglia42:
BTW, I was able to upload code at 3.3V yesterday with an FTDI adapter! I'm super happy that I can continue development, but I'm still curious as to why ISP won't work. Also, I'm stressing the atmega's flash size, and the few extra bytes saved by overwriting the bootloader might help me a bit.

So you can flash new code using the bootloader and an FTDI adapter set for 3.3V, but not directly using a programmer, at least not at 3.3V. The only programmer I've ever used was a Nano as ISP, and even that only at 5V. I don't have a Seeduino XIAO, but I have two 3.3V 8MHz Pro Minis. Should I be able to use one as ISP to program the other? Would that be equivalent to what you're trying to do? The ISP Pro Mini would be powered by the FTDI adapter jumpered for 3.3V, and the target would be powered separately at 3.3V. Should that work? I should say that I run IDE v1.8.8, and I have to install a 10uF cap on the reset pin of the Nano ISP to get that process to work. I assume the same would be true using a Pro Mini.

[ebattaglia42]

ShermanP:
So you can flash new code using the bootloader and an FTDI adapter set for 3.3V, but not directly using a programmer, at least not at 3.3V. The only programmer I've ever used was a Nano as ISP, and even that only at 5V. I don't have a Seeduino XIAO, but I have two 3.3V 8MHz Pro Minis. Should I be able to use one as ISP to program the other? Would that be equivalent to what you're trying to do? The ISP Pro Mini would be powered by the FTDI adapter jumpered for 3.3V, and the target would be powered separately at 3.3V. Should that work? I should say that I run IDE v1.8.8, and I have to install a 10uF cap on the reset pin of the Nano ISP to get that process to work. I assume the same would be true using a Pro Mini.

I would think that would be very similar. I have not tried putting a cap on reset, but it worked at 5V without one.

[ShermanP]

Ok, that worked successfully for me at 3.3V. So just to go through the steps for IDE v1.8.8:

Connect FTDI module to the headers of 3.3V 8MHz Pro Mini with nothing else connected to Mini.

Set jumper on FTDI module to 3.3V. This provides 3.3V directly to Vcc, bypassing regulator.

In IDE, select Board as "Arduino Pro or Pro Mini", set Processor as "Atmega 328P (3.3V 8MHz)".

Load "ArduinoISP" sketch into IDE from File/Examples/ArduinoISP/.

Select USB port.

Upload sketch to Pro Mini.

Add second 3.3V Pro Mini as target, with Vcc, GND, 11, 12 and 13 connected on both.

Connect pin 10 of ISP Mini to Reset of target Mini.

Install 10uF cap on ISP Mini Reset pin, to ground.

Load Blink example into IDE.

Select same Board, Processor and Port, select "Arduino as ISP" as Programmer.

Click Sketch/"Upload Using Programmer".

No errors, and the LED blinks.

I did not try to flash the bootloader, but will do that if needed. Do you perhaps have other parts connected to pins 11 - 13 that might interfere with the flashing? If you have enough power, I don't see why it wouldn't work at 3.3V.

[kprims]

5V programmers tested: Arduino as ISP (nano clone), USBtinyISP, USBasp (slow)
3.3V programmers tested: Arduino as ISP (Seeduino XIAO, Sparkfun Redboard Turbo) and USBasp (slow) with 3.3V jumper

I tested 3 different Usbasp's, different components on each, all at 3.3V using a minimum system atmega8 board/red.
Two failed one passed.
Tried USBtinyISP with the JP3 jumper removed and realized I had to provide 3.3V from another source and it worked.
Used separate 3.3V source on the minimum system atmega8/atmega328p board and USBasp's that had failed now work .

[ShermanP]

So are you suggesting that all those programmers you tried didn't have enough juice at 3.3V? That seems unlikely. Didn't you say you had tested that and had a solid 3.3V at Vcc during a failed attempt? So what's your explanation?

[kprims]

(My problem turned out to be no decoupling capacitors on the PCB I was using to test.)

My tests were run from IDE 1.8.13 and I was burning the bootloader using a USB hub.
No explanation, different computer, and different components. I thought I was lucky to be able to reproduce the trouble.
I can also tie a 10 uF cap across the vcc and gnd on the PCB when using the USBasp's that failed and then they work.

Another thing, I have several Pro Mini's modified for power saving and they all program at 3.3 V with no problems.

Only 1 USBasp fails verification like the OP. It fails on the USB hub as well as a regular USB port.