How to erase program memory with bootloader?

[LiLou]

Having ex_usb_bootloader.c (by ccs), is there an easy way to modify or create a function that erase the program memory? leaving the memory in blank (only with the bootloader).

Regards.

PS: The PIC is 18F4550

[temtronic]

Perhaps the simplest is to just write 0xff to all memory locations,except the bootloader area.If you know the size of the current program in the PIC, just send 0xFF to that amount of space. No need to reprogram 32K if only 1 K is used.

hth
jay

[LiLou]

Yeah, already tried that (partially) , it works. But I would do it in a proper way (educational purposes), as I'm not into the electronic world, but software developer, I would clrify some concepts.

In the CCS manual:

[jeremiah]

It's worth noting that some of those are sometimes in bytes and sometimes in words. Make sure you know the units for your chip.

FLASH_ERASE_SIZE tells you how big your pages are.
PROGRAM_MEMORY tells you how much program memory up to the configuration fuses.

Again, verify the units of those for your chip as they can be different sometimes. For example, on one of my chips, PROGRAM_MEMORY is in words while FLASH_ERASE_SIZE is in bytes. Don't know if that is true for all chips though.

With that in mind, once you have them in the same units (conversion may be necessary), you can divide the erase size into the program memory go get the total number of pages in your chip's memory. You can then loop through, calling erase_program_memory(addr) for each page by starting with the lowest page address you want to erase, adding the erase size (make sure it is in units that go with your addresses...for my chips this is in words) after each time the loop calls the erase function. Make sure NOT to erase the page that has the fuses. Normally if you calculated you had 10 pages, and indexed them 0 to 9, it would be page 9, but do the math for your chip and make sure.

[gpsmikey]

If you don't have it, I would suggest downloading the pdf specifications for the chip in question from Microchip. While not exactly "lite" reading, their spec sheets (all 300+ pages for most chips) are well organized and have sections on memory organization etc. that do show clearly how the chip is organized and usually it becomes much clearer once you look through the appropriate section.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[LiLou]

Thanks for the responses. When I get some result, I will tell.

[Ttelmah]

Let's go through some things:

First, you can't 'write' 0xFF.
The write operation, can only change bits from '1' to '0'.
To generate 0xFF in a location, you have to erase it. Erase is done in pages (there is a single transistor for each page).
So Jeremiah's comment is spot on. Just erase each page.
It is an erase that basically uses a 'life'.
As well as the section in the processor manual, there is also a separate 'programming' document.

For your chip, the erase is done 64 bytes at a time. So the entire memory can be cleared in 512 erase cycles. Just over 2 seconds (4mSec/cycle).
Since an erase uses a life, check before erasing, that the page does contain something other than 0xFF. Reads don't use lives.
Erases need to take place on page boundaries.

For Jeremiah's 'question/comment: "Don't know if that is true for all chips though. ", the unit, is defined in 'BYTES_PER_ADDRESS'. For your chip, '2'.

Best Wishes

[LiLou]

Ok then. The only function that I think it should be useful for my purpose is this one: erase_program_eeprom(addr)

The name which confuses me It erases program memory? eeprom? I don't understand why is choosen that name.

If that function is the one that I should use, this would be the solution?

[Ttelmah]

Technically, the program memory is a type of EEPROM (Electrically Erasable Programmable Read Only Memory). The word 'EEPROM', is often reserved for EEPROM's that offer single byte erase, but all memories of this type are really EEPROM's, this is just a 'convenience standard'. Hence the function name.

You need to multiply PROGRAM_MEMORY, by BYTES_PER_ADDRESS. The program memory size is in 'instructions' (words). Bytes per address gives the size of the word. Remember 'i' needs to be an int16.

Best Wishes

[jeremiah]

Also, your variable i doesn't start on a page boundary. I'm not sure how that will work. On a PIC24 it wouldn't, but I am not familiar with that chip unfortunately.

[LiLou]

I saw that in usb_bootloader.h it says:

[LiLou]

Tried a dozen of time already, changing the address range, always with the same results (the PIC can't load anything after testing, neither the bootloader)

Let's clarify the purpose of all this, because I'm not sure if what I'm asking is logical or not. In the bootloader it says:

[RF_Developer]

Remember program memory is not erased in bytes, its done in pages of 64bytes on your processor, 1K, 2K, 4k or even 8K words on other types of processor. That's what FLASH_ERASE_SIZE tells you. PIC program memory is often not organised in bytes other than for bootloading purposes, its 12 bit, 14 bit, 16 bit etc. Some "bytes" are actually only a few bits long, especially on 10, 12 and 16 series processors.

It normally doesn't matter if the last program was longer than the new one. Yes, there may be stuff left over, but that's not usually a problem, except in some high reliability/high security applications where a more "complete" erase might be required. If so, then simply erasing all blocks NOT used by the bootloader before writing the actual new program would be the way to go. It'll take longer but that's the price you pay.

Most hex files for code don't have any information about memory the code is NOT using. You can't assume its "blank", whatever that means for your processor. You can only usefully verify, checksum and CRC over the known length of the code, not over all of program memory. Some programmers and bootloaders erase all memory, some allow it as an option, often not selected by default, others just erase memory as required to reduce programming time.

So, what is your application? Are you concerned with code security and IP protection? Or are you interested in code validation and verification?

Thoughts: How big is i in your example? It's got to be at least int16, and int32 for any PIC with more than 64Kbytes of program flash. Otherwise it will wrap round and erase the bootloader.

[LiLou]

How embarrassing... Actually the bootloader works well if I load a program that occupy less than the last one.

The problem was that the programs used to test the bootloader, one of them was using a different include (an older version), the usb_bootloader.h file, which is critical, as this file is responsible to reserve the necessary memory.

Thanks for all guys, and forgive me this awkwardness.

PS: Now I'm looking to erase the eeprom data after a written program.

[LiLou]

I tried this before writing the program: