Avrdude chip erase?

Created Wed, 08 Jun 2011 12:50:04 +0000 by rtestardi

rtestardi

Wed, 08 Jun 2011 12:50:04 +0000

Maybe I don't understand how this should work, but the avrdude -e chip erase option doesn't seem to erase the chip flash... I have a program that uses flash for data as well as code, and I'd like the flash erased in its entirety when I load the program... But it seems only the flash pages explicitly listed in the hex file get erased.

I use the command below, which claims to have worked, but doesn't -- it actually doesn't erase anything (the program keeps running).

(I can easily work around this with a dummy hex file, but if I don't have to I'd prefer not to.)

Also, on a possibly related note, the avrdude -p ? option lists three PIC32 variants with the same partno (pic32-360) -- PIC32 seems to be the only MCU where the partno's are overloaded like that...

Do I need to be able to specify the individual chip variants? Maybe that is causing me an issue?

The avrdude.conf file also seems to imply that PIC32 has a 256 byte flash page size, when I thought it was 4k -- not sure if that matters, either...

None of these are big issues -- I'm just trying to understand everything...

Thanks for any pointers!

-- Rich

Command showing same pic32-360 partno mapped to three chips:

sh-4.1$ ./avrdude -C ../etc/avrdude.conf -c stk500v2 -p ? 2>&1 | grep -i pic32 pic32-360 = 32MX320F128H [../etc/avrdude.conf:16054] pic32-360 = 32MX320F064H [../etc/avrdude.conf:15863] pic32-360 = 32MX360F512L [../etc/avrdude.conf:15672] pic32 = 32MX795F512L [../etc/avrdude.conf:15483] sh-4.1$

Command showing avrdude chip erase claiming to succeed:

sh-4.1$ ./avrdude -C ../etc/avrdude.conf -c stk500v2 -p pic32-360 -P COM16 -e

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude.exe: Device signature = 0x504943 avrdude.exe: current erase-rewrite cycle count is -1145324613 (if being tracked) avrdude.exe: erasing chip

avrdude.exe: safemode: Fuses OK

avrdude.exe done. Thank you.

sh-4.1$

Mark

Thu, 09 Jun 2011 21:06:32 +0000

Avrdude works with many protocols and with many types of hardware

When you are using avrdude to communicate with the chip, there are many things it can and cant do. if you are using an ISP or JTAG programmer on an atmega chip, you can do anything. When using avrdude with a bootloader on a chip. the bootloader has to implement the commands for them to work with avrdude.

The bootloader I started with is the same that is in the Arduino 2560 mega board

In this bootloader there are many commands that are not implemented, such as erase chip, set fuse bits, program eeprom etc.

As far as the flash page size goes, avrdude crashes if you tell it 4096. So I told it 256 and got it to work.

The reason for going with AVRDUDE in the first place is so we didnt have to write a new cross-platform downloader program.

Mark

rtestardi

Thu, 09 Jun 2011 21:14:43 +0000

OK, thanks -- that makes perfect sense and I can work with it just fine.

I totally agree with not wanting to "write a new cross-platform downloader program"!!!

I'm glad you got it to work -- it is great that you can have a bootloader for use with MPIDE and I can take advantage of it for a project written in MPLAB!

Thanks!

-- Rich

WestfW

Fri, 10 Jun 2011 02:50:52 +0000

the avrdude -e chip erase option doesn't seem to erase the chip flash.

A bootloader can't do a chip erase, since that would erase the bootloader itself as well.

I can easily work around this with a dummy hex file

So you might think. See http://code.google.com/p/arduino/issues/detail?id=273

rtestardi

Fri, 10 Jun 2011 03:33:02 +0000

A bootloader can't do a chip erase, since that would erase the bootloader itself as well.

I guess in general, I expect bootloaders to do page erases (prior to word or row programs), as that's how the underlying flash is organized. The Microchip HIDbootloader, for example, gives the option to wipe out everything except the bootloader pages. And if you look at the PIC32 Run-Time Self Programming commands in the Reference Manual, the command they provide explicitly erases everything but the bootflash:

"It is possible to erase the entire PFM area. This mode leaves the Boot Flash intact and is intended to be used by a field upgradeable device."

unsigned int NVMErasePFM(void)
{
unsigned int res;
// Unlock and Erase Program Flash
res = NVMUnlock(0x4005);
// Return Result
return res;
}

So you might think. See http://code.google.com/p/arduino/issues/detail?id=273

Well, that's a bit of bad news for me... I'll have to drop some 0's in my data area and when the application boots and sees them, it will perform a full erase of the data area -- not too hard.

Anyway, thanks for pointing that out -- I did in fact try a 35 line HEX file to erase every page, and it did nothing. :-(

Thanks -- you saved me a lot of frustration playing with the HEX file approach!

-- Rich

Mark

Fri, 10 Jun 2011 12:02:18 +0000

I guess in general, I expect bootloaders to do page erases (prior to word or row programs)

I had some difficulties getting the PIC chip to work within the organization of the ATMEL chip. As we all know, avrdude was written for avr chip architecture. The way I did the erase, is as soon as it gets the command write the first block, I go through all of flash (except for the last 4K) and erase each 4 k block. The last 4k block is reserved for simulating eeprom.

I do a smart erase, that is, I check each 4k block, if its all 0xff, then dont bother. This particularly smart since most programs do not come any where near filling up flash.

hope this helps explain things.

Mark

rtestardi

Fri, 10 Jun 2011 14:04:08 +0000

Hi Mark,

You have it exactly right -- I even checked the source code and it does exactly what you said!

The problem I was having where an upload did not wipe out the back half of flash was completely my own -- I reloaded the bootloader on my Uno32 and used the wrong one -- I picked the wrong one from "dist/uno" instead of the right one from "dist/uno-128". (Apparently the wrong one was for a 64k Uno32, and (correctly!) left the back half of flash untouched.)

Now that I have the right bootloader on my Uno32 again, everything works fine -- I don't need the chip erase function because the upload function already starts by erasing the entire (vs just half of!) the chip.

Thanks for your explanations, and sorry for the noise.

-- Rich