problem flashing bootloader to ATMega328PB

[AndyNZ]

Hi all,

I've created my first simple microcontroller PCB and had 2 prototypes printed and assembled by JLCPCB. It is a simple serial controlled switch for a 12V solenoid valve, I'm using one of the outputs of the ATMega to drive a MOSFET (AO3400A), with some buttons and status LEDs (see attached schematic)
I've included a ISP header basically according to the MiniCore wiring diagram (MOSI,MISO,SCK,RST,VCC and GND), and tried to flash the bootloader according to the instructions at the MiniCore Github, but am only getting the following error:
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
I haven't connected the 12V power or solendoid valve, yet, but this would not affect the flashing process I hope.

I've used an external 16 MHz resonator on XTAL1 and 2 (CSTCE16M0V53-R0, LCSC C32180), I thought I had seen this being successfully used with an ATMega328 before, but I'm not sure if this may be the issue.
I've also tried to flash the bootloader with the internal 8MHz clock option, same error.

Any advice would be much appreciated.
Thanks,
Andreas

[Ian.M]

Lets see the rest of the schematic so we can eliminate possible conflicts on the ISP pins, or problematic /Reset circuits.

What AVR programmer are you using?
Paste the *full* AVRdude command line so we can confirm the options used.

Check target VCC - If your programmer isn't powering the target, MISO would be held low by its internal protection diodes, resulting in all zeros response to any attempt to read the device ID.

[AndyNZ]

Thanks for your reply, and yes, I did forget to add some crucial information: I'm using a Uno R3 as ISP, the target board is hooked up to its ISP header.
It seems I've accidentally overwritten the schematic with some modifications, but I've attached the PCB layout, maybe that makes it a bit clearer.


The full error message:
Arduino: 1.8.15 (Windows 10), Board: "ATmega328, Yes (UART0), EEPROM retained, 328PB, BOD 2.7V, LTO disabled, External 16 MHz"
avrdude: Version 6.3-20201216
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch
         System wide configuration file is "C:\Users\1520004\AppData\Local\Arduino15\packages\MiniCore\hardware\avr\2.1.3/avrdude.conf"
         Using Port                    : COM8
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega328PB
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000 (retrying)
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
       Double check connections and try again, or use -F to override this check.
avrdude done.  Thank you.
Error while burning bootloader.
Error while burning bootloader.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

[Ian.M]

Confirm the AVR is fitted in the correct orientation with all pins properly soldered and no bridges between pins.
Connect AVCC to VCC (see datasheet sect. 5.1.8 ).
Confirm you are actually getting 5V at the VCC pin!

[AndyNZ]

Thanks for the pointers, the 328PB chip is soldered in correctly by JLCPCB assembly service, I've continuity tested the connections, that seems all OK. But I haven't connected AVCC at all, that would probably do it?

[Ian.M]

Its certainly worth a try.  I'd simply run a patch-wire over the top of the chip.  30 AWG Kynar wirewrap wire, magnet wire of similar gage or even a strand of bare tinned copper wire would do nicely.

I'm also seeing a lack of local decoupling round the AVR.  The general rule of thumb for MCUs that don't have specific more stringent decoupling requirements is a ceramic capacitor for each Vcc pin (of any type), to the ground plane or nearest ground pin if no plane, typically between 10nF and 100nF in value as close as reasonably possible to the pin.   As you haven't made any provision for such decoupling capacitors,  solder 100nF SMD to the middle of the jumper you are adding over the chip, and connect its other end to *both* GND pins.

[sleemanj]

I thin kit would be programmable without AVcc,

AVCC is the supply voltage pin for the A/D Converter, PC[3:0], and PE[3:2].

I don't think any of these are the programming pins.

More likely is you just need to enable a slow-clock rate in your programmer, the chip will be (probably) set to 1 Mhz, and your programmer will be trying to talk too fast. 

Also

the target board is hooked up to its ISP header

obviously the RESET line on the Uno's ISP header is of no use to you here, that's for resetting the UNO, make sure you don't have that connected to the target board but have the target's reset connected to some other pin on the UNO which is being twiddled at the appropriate time.

[wraper]

But I haven't connected AVCC at all, that would probably do it?

You are not allowed to not power AVCC, and it must bo not more than 0.3V different from VCC.

[Ian.M]

They aren't the ICSP pins, but misbehavior due to voltage gradients across the die isn't uncommon if a MCU that isn't designed for it is partially powered.

[Siwastaja]

Desolder chip, throw into trash can, solder in a new one, this time connect AVCC directly to VCC. Datasheet: "It should be externally connected to VCC, even if the ADC is not used"

[rpiloverbd]

Hi, can we really install the Arduino bootloader in ATMega328PB? Earlier I always used ATmega328P-U for this purpose.

[sleemanj]

Hi, can we really install the Arduino bootloader in ATMega328PB? Earlier I always used ATmega328P-U for this purpose.

The poster is using MiniCore which has a bootloader for the PB.

[AndyNZ]

@Ian.M: Thanks for the advice re decoupling caps, it shows this is my first time messing with this. I'll tie AVCC to VCC, and add a capacitor between the bridge wire and GND and see how I go.

@sleemanj: I think I'll try to hook up AVCC and decoupling cap first, and if this still doesn't work I'll try to slow down the programmer clock. Thanks for giving me food for thought. I hooked up the Uno to the target board according to the MiniCore wiring diagram here: https://camo.githubusercontent.com/057eeb17d0f630dbf6f5146b517ff35cec7f90e5fd5a730d63dd7c69c1c7911c/68747470733a2f2f692e696d6775722e636f6d2f4c72456f6b4f392e706e67
with the header labelled AVR ISP being the Uno ISP header. I wasn't sure if I need to make adjustments to the ArduinoISP example sketch, it sounded like the default settings would be using the Uno ISP header.

@wraper: Yes, sounds like I made my rookie mistake leaving the AVCC not connected, you live and learn...

@Siwastaja: Do you think the chip would have been damaged by not connecting the AVCC? I didn't see any smoke, I think I'll try the other options first before throwing the chip in the trash (with the prices like they are at the moment...)

Thanks again for all comments.

[sleemanj]

with the header labelled AVR ISP being the Uno ISP header.

Incorrect.

That diagram is showing the header for the target, not the programmer.

You need to handle RESET properly on the target, the programmer can't control it's own RESET line to effect the target.

RESET line control is essential to programming.

Check the ArduinoISP sketch to see which pin on the programmer (Uno) it uses to toggle reset on the Target (your board), I think it's pin 10 from memory.

[sleemanj]

[AndyNZ]

Thanks so much, that worked, and yes, it was pin 10. Not sure if the patch wire was necessary, I've done that before the change of the reset pin. On to the next bug...

Thanks for all who helped, this is a great forum.

[Siwastaja]

@Siwastaja: Do you think the chip would have been damaged by not connecting the AVCC? I didn't see any smoke

Very possible, quoting a famous Finnish ski jumper, I'd say fifty-sixty chances.

It can be some weird hidden damage that causes it to kind of work but cause trouble (and massive waste of time) later, that's why I'm suggesting replacing the chip, it's still just a few bucks. Of course, you can try to push your luck. But, if you seem to have some weird ADC problems later, maybe then swap the chip. (Again, I'm just guessing it more likely breaks something ADC-related, but this is just an educated guess, it can break anything, or maybe nothing is broken.)

This is because internally, there are parasitic diode structures that cause current to flow in unexpected ways, this can shift internal voltage references, resistor values, or blow up some internal transistors, but not all of them, just render some part nonfunctional. That's why multiple power domains are often specified they need to be kept within +/- 0.3V of each other, to keep said diode structures biased off.

Then of course, some ICs allow different power domains to remain unpowered (or sequenced on in any arbitrary order), but this is not the case with AVR's AVCC/VCC. Always check the datasheet.

[AndyNZ]

Ah yes, I'll bear that in mind if I encounter electronic weirdness. Though in the stage I'm at, it may be difficult for me to distinguish between something not working because I made a mistake, or because the components are damaged. It's more likely to be the first initially, and if I don't get anywhere troubleshooting I consider the latter.
I did know that ESD damage can lead to delayed failure - the company I work for investigated the failure modes of their products and found that static discharge of below 50V can partially damage traces or components -, so what you say makes sense.
Thanks,
Andreas