avrdude sometimes fails to read flash after uploading

I'm experimenting a strange problem. when uploading code to my custom designed arduino (it's based on the CH340 usb to ttl) uploads the firmware without problems but most of the times fails to read back the the flash.

The sketch seems to be uploaded ok, it works as expected, it seems it's only failing to verify the memory after upload and only when using the USB, if I upload via ISCP it uploads and verifies OK.

The micro I'm using was a blank one which I burn the bootloader in it , could it be something realted to the fuses?

AVRDUDE output:

Launching: C:\Users\marcp\eclipse\cpp-oxygen\eclipse\arduinoPlugin\packages\arduino\tools\avrdude\6.3.0-arduino9/bin/avrdude -CC:\Users\marcp\eclipse\cpp-oxygen\eclipse\arduinoPlugin\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf -patmega328p -carduino -PCOM3 -b115200 -D -Uflash:w:C:\Users\marcp\Dropbox\Source\RiegoMatic\HDO.RiegoMatic.Locker.Firmware/Release/RMLockerFirmware.hex:i 
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file "C:\Users\marcp\Dropbox\Source\RiegoMatic\HDO.RiegoMatic.Locker.Firmware/Release/RMLockerFirmware.hex"
avrdude: writing flash (6684 bytes):

Writing | ################################################## | 100% 1.13s

avrdude: 6684 bytes of flash written
avrdude: verifying flash memory against C:\Users\marcp\Dropbox\Source\RiegoMatic\HDO.RiegoMatic.Locker.Firmware/Release/RMLockerFirmware.hex:
avrdude: load data flash data from input file C:\Users\marcp\Dropbox\Source\RiegoMatic\HDO.RiegoMatic.Locker.Firmware/Release/RMLockerFirmware.hex:
avrdude: input file C:\Users\marcp\Dropbox\Source\RiegoMatic\HDO.RiegoMatic.Locker.Firmware/Release/RMLockerFirmware.hex contains 6684 bytes
avrdude: reading on-chip flash data:

Reading | 
avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0x00
avrdude: stk500_cmd(): programmer is out of sync
avr_read(): error reading address 0x0000
read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x00

avrdude done. Thank you.

The execution of command "6.3.0-arduino9/bin/avrdude" is done.

Not the fuses. Could be the lockbits, or could be hardware. If it's a custom build of optiboot, it could also be related to that.

What are the lockbits set to? If they're set to not permit reading the flash, that could explain it!

Does the LED flash between reading and writing? (the pin13 LED, assuming you have that on your custom board)? If it does, that indicates that it's resetting between the write and read operations, and would explain the problem - though not why that was happening (which I would suspect to be a problem with the hardware design)

DrAzzy:
Not the fuses. Could be the lockbits, or could be hardware.

What are the lockbits set to? If they're set to not permit reading the flash, that could explain it!

They are set as default by the arduino IDE when burning the bootloader, all O except for BLB11 and BLB12

DrAzzy:
Does the LED flash between reading and writing? (the pin13 LED, assuming you have that on your custom board)? If it does, that indicates that it's resetting between the write and read operations, and would explain the problem - though not why that was happening (which I would suspect to be a problem with the hardware design)

The strange thing is that sometimes works as expected and sometimes hangs while reading the flash memory.

I don't have a LED on pin13 but I suspect that's what may be happening because I have a buzzer that plays 3 tones on startup and sometimes I can hear it play more than 3 tones. I don't see why it could be resetting , I have used the same design in other projects and I was not having this problem.

Another thing I have noted is that the problem apears on 'large' programs, if I upload the blink sample it always works fine, I have also checked my sketch size and it fits on the atmega328 so that's not the problem.

That's my current design :

The schematics with this resolution doesn't help much.

The strange thing is that sometimes works as expected and sometimes hangs while reading the flash memory.

Some APP in your PC is trying hijack the port, maybe? I have such experience with Visual Studio Code on Lnx.

Budvar10:
The schematics with this resolution doesn't help much.
Some APP in your PC is trying hijack the port, maybe? I have such experience with Visual Studio Code on Lnx.

You just have to right click on the image and "see in a new tab" :slight_smile:

No, I discovered the ch340G windows driver is resetting the chip multiple times on windows when the cable is connected arduino - "CH340" usb-serial interface chip drivers cause AVR reset problems under Windows / Linux - Electrical Engineering Stack Exchange that's why I listen the tone multiple times but doesn't explain my problem with the flash memory .

Also I have an arduino chinese clone with the very same chip and I can upload the same sketch without problems, so it's a hardware problem of my design or some sort of configuration with the blank uC

You just have to right click on the image and "see in a new tab" :slight_smile:

Aha, ok.

If the windows driver is for some reason resetting the chip (presumably by causing it to twiddle DTR line) between upload and read, that would cause a failure to verify.

I have never had that issue with my CH340G's - I use them almost exclusively, and have dozens of them (because I keep losing them - that's not counting the stock I have for my tindie store where I sell them as an addon with serial-capable boards.

DrAzzy:
If the windows driver is for some reason resetting the chip (presumably by causing it to twiddle DTR line) between upload and read, that would cause a failure to verify.

I think is happening also on your boards, that is the windows driver behaviour when the USB cable IS BEING PLUGGED to the board, probably not a big deal because it does not affects the programming, it's not happening when you reprogram the chip, also I have a chinese arduino clone with the same CH340g, experiences the very same behaviour and I can upload my sketch without problems so it's something related to my hardware design or uC setup.

DrAzzy:
I have never had that issue with my CH340G's - I use them almost exclusively, and have dozens of them (because I keep losing them - that's not counting the stock I have for my tindie store where I sell them as an addon with serial-capable boards.

Can you share an schematic about how are you connecting the CH340g chip to the micro so I can compare if there is any difference with mine?

TX to RX of microcontroller, RX to TX of microcontroller, Vcc to Vcc, Gnd to Gnd, and DTR to one side of a 0.1uF cap, reset of micro to the other side. Reset pulled up by 10k resistor.