Trouble uploading to Atmega 328p using Atmel ICE

PlatformIO IDE
1

Hello,

I got a new hardware revision of some boards in that have an Atmega328p on them using the internal 8Mhz oscillator. I use an Atmel ICE to upload the program to the 328, and I have had success up until today.

The first thing I have always done when I get a fresh 328 is burn the “ATmegaBOOT_168_atmega328_pro_8MHz.hex” bootloader using the Arduino IDE and the ICE programmer. You can download it here: https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard

I moved from visual micro to PlatformIO to develop for the 328, after a little bit of flailing I got the uploads working and since then everything has been great and I haven’t touched any json files. Now I am working from home on a different machine and I am having a weird problem I’ve never seen before.

I successfully burn the bootloader using the ICE and the Arduino IDE, then I successfully upload my program onto the 328 using the ICE and PlatformIO, and everything works fine, but when I try to upload the program again immediately afterwards I get this error:

avrdude: stk500v2_command(): command failed
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: stk500v2_command(): command failed
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: stk500v2_command(): command failed
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: stk500v2_command(): command failed
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: Target prepared for ISP, signed off.
avrdude: Now retrying without power-cycling the target.
avrdude: stk500v2_command(): command failed
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: Failed to return from debugWIRE to ISP.
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

This is my “platformio.ini”:

[env:My_328p8m]
platform = atmelavr
board = ATMEGA328_8MHz_Supervisor
framework = arduino
upload_protocol = atmelice_isp
upload_flags = -e

My board file:

{
“build”: {
“core”: “arduino”,
“extra_flags”: “-DARDUINO_AVR_MICRODUINO_CORE”,
“f_cpu”: “8000000L”,
“mcu”: “atmega328p”,
“variant”: “standard”
},

“frameworks”: [
“arduino”
],

“fuses”: {
“efuse”: “0xFD”,
“hfuse”: “0xDA”,
“lfuse”: “0xE2”
},
“name”: “Supervisor_A328_8mhz”,
“upload”: {
“maximum_ram_size”: 2048,
“maximum_size”: 32256
},
“url”: “Microduino-Module Core - Microduino Wiki”,
“vendor”: “Dave”
}

When I first moved over to PlatformIO I found an 8Mhz 328p file (328p8m.json) and set the fuse values in the board file, now I see a section on custom bootloaders in the PlatformIO documentation: Atmel AVR — PlatformIO latest documentation and it says I should have the fuse values in platformio.ini.

Looks like I have some reading to do, but if someone has some time to give me a little guidance, I sure would appreciate it. Thanks!

2

I take it you’re using the upload target instead of the program target since you’ve added the -e chip erase parameter? If you use the program target that isn’t needed, just like how it isn’t needed when you choose the upload with programmer option in the Arduino IDE (over the regular upload options, which rely on the bootloader and serial programming).

Since you have a custom board definition, I don’t think there’s any real point to using the board_bootloader.lfuse, board_bootloader.hfuse, board_bootloader.efuse etc parameters as you’re not overriding a stock board configuration. If you want to be able to flash the bootloader via PlatformIO using the bootloader target, add them to your custom board .json file… like it is done here.

As the the culprit for that error message, I don’t have any idea. That last cycle where it says avrdude: Failed to return from debugWIRE to ISP. makes me wonder if the ICE is the culprit though, as that seems to pop up on some AVRFreak posts suggesting the programmer needs a power cycle… Does it only happen the once, or will repeated attempts to program give the same error? And does a reset or power cycle of the AVR board make any difference?

3

@pfeerick, thanks so much for your response.

TLDR - It was a hardware problem on my end.

SO this was probably an pre-mature troubleshooting post for the error message, but a long overdue attempt at understanding the PlatformIO / AVRDude compile and upload options which I plan on investigating today. Like I mentioned before, the platformio.ini and board file contents that I mentioned in the last post were created through trial and error and some help I received here, it always worked, so I just left it at that… But I should understand what I am doing. So… Shame on me.

After some troubleshooting I found that the upload error problem I was having was due to hardware changes, and had nothing to do with PlatformIO and the contents of my platformio.ini and board files, but that’s not to say I have the correct settings in my files, but at this point things are working the way they were working before I had the upload problem. I have removed the erase argument from platformio.ini, thank you for that information.

PlatformIO using the bootloader target, add them to your custom board .json file… like it is done here.

I use the Atmel ICE while developing, but I need to be able to upload programs to the 328 using the UART also, the way I burn the bootloader in the Arduino IDE and then move over to PlatformIO to develop doesn’t seem ideal, especially if PlatformIO has a built-in target for the bootloader. I am going to mess around with the bootloader options in platformio.ini today.

I am curious how that works though, does it burn the bootloader every time or does it do a check first?

Anyway… Thanks for the help and the moral support as always.

1 Like
4

Glad it’s working for you now! Yeah, there’s been some nice changes/improvements between PIO 4.0 and 4.2 for AVR stuff like fuses and bootloaders, so it’s probably a good time to review it all again, and see if you can make use of the new stuff. :slight_smile:

You’d only use the bootloader target when you want to burn the bootloader, so it would write it every time you run it. Only problem is it as far as I can tell it’s not exposed in the VSCode PlatformIO extension… upload (--target upload), upload using programmer (--target program) and set fuses (--target fuses) are … but for the bootloader target you’ll need to use the terminal / command line interface… i.e. pio run --target bootloader. I would think pio run --target fuses --target bootloader would be the command to provision a new chip - getting the fuses set right, and the bootloader in place.

2 Likes