"Arduino as ISP" will not erase device, fails verify

Hello.

I am using "Arduino as ISP" to program my project and figured out that program/verify is OK only for blank devices. That is, if I attempt to program an non-blank device it will program but then fail on verify.

I figured this out as I was constantly failing to verify a chip that was fine a minute ago and the device was never powered, other than through the "Arduino as ISP" programmer.

I went through with AVR910 app note and programmed routines used to read/set fuses and erase the chip into the same HW used for "Arduino as ISP" . I was able to read fuses, ID and erase the chip.

After I erased chip I was able to program it again no problem. I then changed one constant in the sketch and recompiled and reupload through "Arduino as ISP" and failed the verify. I went in with my "eraser sw" and after erasing the chip I programmed with "Arduino as ISP" and then the verify was OK again.

I also quickly went through the code and could not find the routine to erase the chip.

Why is this omitted?

In my 12+ years, I have not had an issue using a UNO with an Adafruit shield and a ZIF socket for AVR DIP chips.

Issues that I have had were of my own foolishness:

  • poor quality Dupont pin jumpers
  • loose confections
  • connections too long
  • having my smartphone too close to the circuit
  • AC "hum"

... and so on.

You can try a different sketch:
Gammon Forum : Electronics : Microprocessors : Sketch to detect Atmega chip types

But consider that Arduino as ICSP is a work-around that generally gives proper results but may fail in some circumstances. Buy a REAL ICSP if perfection is a requirement.

So question is why is erase part being omitted, that is the topic. Or maybe it is not omitted, just I can't seem to find it?

I can read ID with both SW, this is also off the table.

As far as perfection goes buying a REAL ICSP would be the option if demanding an erase from an "Arduino as ISP" is considered too much. But then I would also be tempted to replace Arduino too.

The toolchain was chosen because of price, but if "Arduino as ISP" really can not be used as an programmer for already programmed chips, than it is time to find something else.

I wonder if this is to do with you uploading via ICSP and the setting of the BOOTRST fuse. Can you how the fuses are set ? Also say what board it is.

Hello,

this is ATMEGA168, fuses:

//atmega168p

#define FUSE_PROT 0xFF
#define FUSE_EXT 0xF8
#define FUSE_HIGH 0xDE
#define FUSE_LOW 0xC6

Thanks for idea, but it seems this is not the case.

ArduinoIDE is just a graphical interface mostly; actual programming of AVR is handled by scripts that invoke avrdude:
avtdude erase at DuckDuckGo

As far as "why" because it is...

Drop to the command line to do anything non-GUI:
Copy 'n Paste Arduino Firmware - Community / Exhibition / Gallery - Arduino Forum

But AVRDUDE erases chip every time as far as I can recall.

Try unsetting BOOTRST. I'm guessing that the bootloader area is maybe excluded from part of the check/erase somehow and your sketch is breaking into it. The bootloader area is 2k for that chip.

Of course it does! Flash memory as implemented in AVR must be page-erased before written.

Yes, and hence the question, why "Arduino as ISP" does not??

BOOTRTS is already '0', by un-setting you mean to set it to '1'?

The code is open-source and if you honestly feel the need, just modify same. I do it all the time with hacking the "cores" and 3rd party libs.

Yes. Unset (unprogrammed) is 1

Sure, but before I go this route, I prefer to ask, just in case I missed something.

I will try, will let you know.

Nope, no dice..

Oops. I've just seen that the fuse structure for an ATmega168 is completely different to ATMega328P which I initially assumed you were using. That picture I sent was not relevant.
The BOOTRST setting is in the EXT fuse on the 168. Is that where you changed it ?

The fuses for the ATmega168 are also described in the datasheet here: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf see chapter 24 Memory Programming

ERASE is implemented by AVRdude as a "Raw SPI command", rather than the specific chip erase command.

avrdude: erasing chip
avrdude: Send: V [56] . [ac] . [80] . [00] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 

AFAIK, this works fine on all common chips. I suppose that if you have some less common chip that somehow needs the 'R' chip-erase command instead, it might fail.

Please tell us exactly what avrdude command you are using, and include the output when you invoke it with "-vvvv" for verbose debugging.

Yes, I changed the correct bit in correct fuse, still no dice.

The discussion is about "AVR as ISP", AVRDUDE was just mentioned in passing.