I'm currently having a little trouble burning a bootloader to my custom dev board based on the ATMega328PB via the ICSP header. I'm using a known good Arduino Uno as my Programmer (I burned a bootloader onto a Mega to check that it works) and am using Mini Core to customise the settings. I've attached my device signature response below. It made me initially think that there was a bad connection, as it is currently showing nothing.
The ICSP is connected in the same manner as the schematic below, apart from the resistor + LED to ground on the SCK are removed
A few things I've done:
I've continuity checked between the Programmer Arduino and my target - all good there
Added Additional 0.1uF Decoupling caps across AVCC to Gnd and VCC to Gnd.
I spotted the difference between 328p and 328pb, where pins 3 and 6 are concerned and have lifted the legs just to rule them out
I've tried programming to both external and internal clocks - no luck.
I've checked that the Reset to DTR cap is 0.1uF and is in circuit.
I've also tried a USBasp just on the off chance
The development board is running off an external supply to the programming Arduino, but the GNDs are tied.
Unfortunately, I don't have an oscilloscope at home, so I do not have access to waveforms.
My External ceramic resonator is a CSTNE16M0V530000R0
Is there anything simple I could have missed, or is it simply that my resonator is not suitable?
When you did that, did you plug the cable of the USBasp directly onto the ICSP header on the target board? Or did you instead use jumper wires to make the connections? I ask because if the USBasp's ribbon cable is connected directly to the header, we can probably assume the electrical connections are correct, as long as the cable is in the correct orientation (i.e., pin 1 on the cable's connector connected to pin 1 on the header) and not offset by one row of pins on the header (sounds unlikely, but I have actually done this).
Did you get the same 00 00 00 device signature when you used the USBasp?
The output when using USBasp. One thing i did forget to mention was that I downloaded Zadig and tried each of the USB drivers all giving the same error.
The USBasp I have came with a 10 to 6 adapter board and i've tried with the adapter and without it using flying leads to the header from the ribbon
I'm leaning towards this. It could just be a case that I've got a bad batch of microcontrollers. I'm going to get my hands on some spare ICs and do a swap. If that does'nt work, time to look at next issue of boards
If it's an unprogrammed 328, then the internal oscillator is used for the first bootloader burning, the external crystal/resonator is not used, so that can be ruled out as a problem.
I'm not sure DTR is relevant when flashing with an Uno as ISP. But there should be a 10K pullup to Vcc on the 328PB's reset pin. You have a 1K resistor there. I don't know if that matters.
During programming, that pin should also be directly connected to pin 10 of the programmer Uno. And the Uno should have a 10uF cap from its reset pin to ground. But this would all have to be working to flash the bootloader to a Mega, so presumably it's all set up correctly.
I have found it helpful to use Zack Kemble's AVRDudess, which is a front-end GUI for AVRDude. When I'm having problems, I try just reading the fuses, and see how it responds. Just be sure the programmer and board type are set correctly, and of course the COM port.
Be careful with AVRDudess, if you don't know what you are doing you can screw up the 328 to the extent that can only be fixed with a parallel programmer
Thanks for the clarification. This is a different error message than you got from the "Arduino as ISP" programmer, but it is in the same general classification of errors caused by a failure of communication between the programmer and target, and so may well be caused by the same root problem.
The fact you have a similar failures from two separate programmers does indicate the problem is with the target rather than the programmer, as other contributors to this discussion also hypothesized.
It was a good thought, because the installed driver can indeed cause the process to fail when using the USBasp. However, in that case there is a subtle difference in the error message. Note this part of the error message you encountered:
Error: program enable: target doesn't answer (0x01)
In the case where the failure is caused by the driver, I believe the code shown in that error will instead be 0x00:
Error: program enable: target doesn't answer (0x00)
The reason I am uncertain about the specific error message is because the format of the message has changed between the older AVRDUDE versions used by most of the community and the modern version 8.0 used by MiniCore.
I wonder if you would see any flickering of the LED if you reconnected the LED and resistor to D13.
Well, I think the possibilities are limited. Of course the 328PB could be bad, or counterfeit, or mis-marked. But it could instead be something wrong with the circuit, such as the ICSP headers not actually connected to the correct 328PB pins. Or a short somewhere. Or bad jumpers. Or something else not right with power or reset. Or something not set right in the IDE. Or maybe the fuses aren't set right for your resonator (I know nothing about this). Actually, I guess those possibilities aren't so limited.
Anyway, it would be pretty unsual for the chip to be bad. Even counterfeits almost always run.
Edit: Maybe it's time to get out your meter and check the voltages. Does D10 of the Uno actually take the 328PB's reset pin low? Is there any activity on SCK. Etc.
You say in your text you're using a 328PB. When I glanced at your schematic I noticed that the MCU was labelled a 328P.
I looked a little closer and noticed that pin 3 was labelled as Ground and pin 6 was labelled as Vcc, as it is on a 328P.
That, however, is not true on a 328PB. Pin 3 is PE0 aka SDA1/ICP4/ACO/PTCXY, and pin 6 is PE1aka SCL1/T4/PTCXY. So you've got a couple of I/O pins tied to the power rails. Which isn't an immediate problem unless something enables an output function on either of them, in which case it becomes an immediate problem.
Second, I also noticed that you're using an external crystal on the 328PB. When I was first tinkering with that chip, I had issues with it whenever I was using the second I2C port. Which just happens to be on the pins either side of the crystal pins. Now, in your case, those pins are tied to the rails, so what happened to me (which I assumed was interference between the 0/5V signals adjacent to the much subtler signals on the crystal pins) won't be happening in your circuit. That long winded tome is all to say that unlike the 328P, which has both a full swing crystal oscillator option as well as a low power crystal oscillator one, the 328PB only has the low power crystal oscillator option. And in my admittedly limited experience with it, the low power option is much less forgiving of the kind of things the 328P will cheerfully let you away with on the full-power option.
As I say, it may be nothing. But it might be worthwhile thinking about for a few minutes.
i've had the same problem, and the only one thing that worked, was to put -c arduino -b 115200 in avrdude (i'm on linux, but it also works with wingdowz) : my chip is a 328PB, but as i programed it with the automatic -F option in avrdude, as i tried to force and open the second uart, the chip was blocked, and i couldn't do anything (corrupted fuses, reset button useless). Examining the board with microscope lenses, i saw that pin 3 and 6 of the chip were conected as for the 328P : pin 3 on gnd, and pin 6 on vcc. that's what provoked the logical short. The chip was stuck in a loop at boot. So, i cold cut the pins 3 and 6 with care with a x-acto fine cutter, and i had to bridge pin 29 of the chip to gnd, and do the command with avrdude to detect and erase the chip (removing the pin from leg 29 of the chip at the same time that i pushed the enter key to execute the command. It was done, so my chip could be recognized as a 328P again (the problem, is that the chip is a real 328PB, but with a 328p board, and a 328p bootloader). Now that the chip has been completely erased, and is detected again, i am waiting to receive my new USBtinyISP so i will use it to reprogram the fuses, and burn the 328P original bootloader. When the board works again (working "blink" and reset button), i won't have problems to reflash it as a 328PB, with that programmer, now that i solutioned the software shorting problem (cut the 3 and 6 legs off the chip). With my 3 brand new boards, i won't have this problem : these legs are soldered on their pads, but are insulated, and don't beep to gnd and vcc anymore (tested with multimeter and the board unplugged).
