Bootloader doesn't write eeprom

[PwtEma]

Hi,
I tried to use the bootloader example and it starts well, interrupts are ok, but in the hex file there's an initial configuration of the eeprom, that bootloader doesn't write...is this normal?

P.S. I'm able to compile the example only with an old version of ccs, not the last.

[RF_Developer]

Normal.

Many bootloaders don't write the eeprom. If not then they may be persuaded to with the right options, or maybe commands from the host software.

Even more refuse to write the configuration; mainly as it can make the bootloader die. I made the mistake of trying to load a debug version of application code using a bootloader. It all worked fine up to the moment the loader wrote the config words. Then it stopped dead. Never to run again, at least not by the bootloader. Pretty obvious when you think about it.

Also PICs have various protection built in. These may prevent writing and/or reading of various parts of all the different memory sections. What is protected and what is not varies a lot between different PICs. This protection is controlled by the config words and generally when using a bootloader that means the config which the bootloader was assembled with.

Some bootloaders actually use a byte, generally the last, in eeprom to control whether it runs or your application code does. These are often the type that run in the first part of program memory: the part that can be seperately protected as a boot block just for use with bootloaders. These require you to alter the vectors from normal. The other type of bootloader lives at the top of memory and generally doesn't need you to modify your code (or does the tiny mod for you as it loads). However PICs doesn't provide any special hardware protection for this type of bootloader.

So, yes, its normal. You may be able to set some option in the PC application to tell the loader to load eeprom, but not all bootloaders do.

RF Developer

[PwtEma]

Thanks for your help.
I have modified the example

[diogoc]

Can you share the modifications for eeprom write?

It should be in this section, but I can't understand how:

[spilz]

Hello

Actually I have the same problem in my project.

Did someone find the solution? And can he share it ?

My other question : does the usb bootloader.exe can send it ?
Or do we have to change it too?

Thanks for your help and share

Regards

Spilz

[Ttelmah]

First understand that the bootloader is only an _example_. You can modify it any way you want.
Writing the EEPROM, is relatively simple. Just look for the address used by it on your chip. Get the programming specification for the chip (from the MicroChip site), and this will tell you the address used. Or the getenv function with 'EEPROM_ADDRESS, will tell you where it is, and modify the limit tests, so that if a byte arrives with an address between EEPROM_ADDRESS, and EEPROM_ADDRESS+EEPROM_SIZE, this is accepted and written, using the EEPROM_WRITE function (instead of the program memory write function). You have to change the function used, because an extra bit has to be set in the write to say that the EEPROM is being written, and the EEPROM doesn't erase in pages.

Generally all bootloader transmission programs do _not_ test the addresses they send (they can't do, since they do not know how large the memory on the target chip is), so will actually happily send the EEPROM data.

Adding this write, _will_ increase the size of the bootloader, so you may well need to change the loader_end address.

It's common to not write the EEPROM with the code, instead have the code do this itself. If (for instance), you are sending configuration data, have the configuration structure declared in the code, with default values, and and have code check when it starts, if the version stored in the EEPROM, is later than the default version, if it is, use this, if not, write the code defaults to the EEPROM. This can then use the same code used to write the values when they change (saving space).