I’m trying to migrate away from my Arduino IDE. I’m using the AVR Pocket Programmer. It works in the Arduino IDE if I use it as " Upload using Programmer" command. The current project I’m working on is just a basic “hello world” example sketch for an LCD.When trying to upload in Platform IO it gives me an error.
I’ve change the Platformio.ini file as such:
[env:pro16MHzatmega328]
platform = atmelavr
board = pro16MHzatmega328
framework = arduino
upload_protocol = usbtiny
lib_deps = LiquidCrystal
But this is the error I get:
avrdude: verification error, first mismatch at byte 0x0042
0x82 != 0xb6
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF
I’m sure I’ve done something wrong. Visual Studio and PlatformIO are still really new to me. So please have patience with me and thank you for any help you can offer.
1 Like
Welcome!
Um… what was the error again? You might have forgotten to copy it and pasted the platformio.ini contents twice 
That configuration looks fine though, so just need to see the error message to see what’s going on.
btw, I added code formatting markdown tags to your post (triple backticks ``` before and after the code).
oh man, oops! Thanks for the help. lol Ya, copy and pasted the same thing twice. Thanks for adding the markdown tags. I wasn’t sure how to do that here.
1 Like
Does it make a difference if you put
upload_flags = -e
in the platformio.ini?
4 Likes
That’s it! That totally fixed it! Wow!
So what does that flag do?
Also, I’ve seen those all over but can’t find a list of them. Could you direct me to that please? I’d love to read up on it.
From avrdude.exe --help (the helper program which burns the firmware on the chip)
C:\Users\Maxi\.platformio\packages\tool-avrdude>avrdude.exe --help
avrdude.exe: unknown option -- -
Usage: avrdude.exe [options]
Options:
-p <partno> Required. Specify AVR device.
-b <baudrate> Override RS-232 baud rate.
-B <bitclock> Specify JTAG/STK500v2 bit clock period (us).
-C <config-file> Specify location of configuration file.
-c <programmer> Specify programmer type.
-D Disable auto erase for flash memory
-i <delay> ISP Clock Delay [in microseconds]
-P <port> Specify connection port.
-F Override invalid signature check.
-e Perform a chip erase.
[...]
avrdude version 6.3-20171130, URL: <http://savannah.nongnu.org/projects/avrdude/>
Does a chip erase before programming the new file. I don’t know how and why exactly that fixes the problem though… Logically thinking there might still be a old sketch burned in the chip and the check boundaries somehow include that old sketch? Or the chip in general cannot be programmed if not erased before? I would like some insight here too, I just remembered that this fixed a similiar problem I’ve read about here 
Docs on upload_flags is here: Redirecting...
@maxgerhardt It seems when you dig into the more detailed explanation of the flags, that if the -D option is present - that’s the problem - as it prevents auto erasure. That’s part of the reason for the upload vs upload with programmer targets… the upload target has the -D parameter set to prevent auto-erasure, as the bootloader takes care of the programming of the MCU, whereas the programmer target lets the auto-erase occur.
-e Causes a chip erase to be executed. This will reset the contents of the flash ROM and EEPROM to the
value ‘0xff’, and clear all lock bits. Except for ATxmega devices which can use page erase, it is
basically a prerequisite command before the flash ROM can be reprogrammed again. The only exception
would be if the new contents would exclusively cause bits to be programmed from the value ‘1’ to ‘0’.
Note that in order to reprogram EERPOM cells, no explicit prior chip erase is required since the MCU
provides an auto-erase cycle in that case before programming the cell.
-D Disable auto erase for flash. When the -U option with flash memory is specified, avrdude will perform
a chip erase before starting any of the programming operations, since it generally is a mistake to
program the flash without performing an erase first. This option disables that. Auto erase is not
used for ATxmega devices as these devices can use page erase before writing each page so no explicit
chip erase is required. Note however that any page not affected by the current operation will retain
its previous contents.
2 Likes