Problem uploading with ArduinoAsISP on Arduino Mega

Hi, I’m having a problem where I have to burn the arduino bootloader to my board everytime I change my code to upload. It’s a real pain in the development workflow.

I have a custom board with an ATmega2560 and an Arduino Uno set up as an ArduinoAsISP that I use to program it. I can burn the bootloader using the Adruino IDE and then upload my application from PIO just fine, but when I make changes to the code and try upload I get memory errors like this:

avrdude: verification error, first mismatch at byte 0x1965
         0x60 != 0x70
avrdude: verification error; content mismatch

(FYI it’s not always the same byte) What I don’t understand is why does this happen? The upload process doesn’t erase the flash it just writes to it. And why does burning the bootloader fix the problem?

My guess is it has something to do with the existing application code on the board? I don’t really understand how pio decides which section of flash to start writing to.

Can someone explain to me how this works please? And also how I can fix this problem so that I don’t have to burn the bootloader every single time.

BTW here is my .ini file setup

[env:megaatmega2560]
platform = atmelavr
board = megaatmega2560
framework = arduino
upload_protocol = stk500v1
upload_flags =
    -P$UPLOAD_PORT
    -b$UPLOAD_SPEED
upload_port = COM3
upload_speed = 19200

Do you use “Program” instead of “Upload” target? pio run -t program.

All instances of this error which I’ve seen point to the flash not having been erased first. Can you add -e to the upload_flags?

I use “upload”, my bad for confusing terms.

btw thanks for making PIO it’s such a pleasure to use.(Sorry if that’s no very appropriate to say here)

Thanks so much. yeah it’s working now. I haven’t come across that flag in the docs not sure how I would have found that out otherwise

The -e flag solves the upload problem, but this also erases the EEPROM which I think is something you do not want to do if it is not really necessary.

The problem is that platformio sets the -D flag by default when uploading with avrdude. This disables auto erase for flash. Why is that? The avrdude manual states that: “it generally is a mistake to program the flash without performing an erase first”. So why use it as a default?

Would it be an idea not to set the -D flag by default? Or, at least, make it unflaggable (the script method looks cumbersome)?

The Arduino IDE has it also set, and PlatformIO copies that behavior. I’m also not sure why this is the default… Maybe you can ask at Issues · arduino/ArduinoCore-avr · GitHub.

Also there’s a partly related topic about not erasing the flash when uploading to EEPROM (AVR: Uploading EEPROM also erases chip - #8 by maxgerhardt).

I think I figured it out. In the arduino IDE the -D flag is added to the avrdude upload command because arduino uses a bootloader–a tiny piece of code in the mcu’s flash memory (I think at the beginning) that reads a new program over the serial pins and uses that to overwrite the previous program in flash. It probably also erases unused flash memory, so that when avrdude verifies the code after upload it finds no differences. The -D flag is necessary because otherwise avrdude’s “auto erase for flash” functionality at the start of an upload would erase the bootloader in the mcu’s flash memory and the whole thing would not work.

The problem TJ3 and I have is that we use an upload_protocol (stk500v1) that is not a bootloader (it’s an ISP protocol) and we need to have the flash erased at the start of the upload (but it isn’t because platformio sets the -D flag by default). I would propose to change platformio’s python code so that the -D flag is only set if the upload_protocol is not a bootloader (in any case: arduino, but there might be others).

Ah, but if you want full control of the upload flags when using a programmer, then the docs already have you covered – they completely control the invocation via upload_command and upload_flags, and the examples don’t have -D as a flag in there.

That’s what I was looking for. Thanks again Max!