Hi,
i am planning to work on secondary bootloader using IAP to update code from extrnal EEPROM on I2C. In order to do that, i first need to write the code(may be hex file) in to EEPROM. I know how to write some data to EEPROM but i am confused about what file needs to be written to EEPROM if i had to use it for firmware update of ARM7 LPC2138.
Is it a hex file of that firmware or some other file and should i write that to eeprom as it is or with some modification or what..?
Regards, Salman.
The chip itself does not have any means for being updated from EEPROM.
So you need own code that reads data from the EEPROM into RAM, and then uses IAP to program a code flash sector.
Since you have to write own code to retreive data from the EEPROM, you could store the ASCII hex data from the .hex file in the EEPROM. That would obviously waste lots of space. So it would be better to store the data binay. Just remember that you should have some form of safe checksum (normally not a real sum, but CRC-16, CRC-32, Adler-32 or similar) to make sure that you have valid contents in the EEPROM before you start the reprogramming.
Next thing - any programming made from EEPROM means that you don't transfer data externally. What if you get a lockup in the middle? What if you in the middle find a problem with the EEPROM? Will you have any alternative way for a user to supply a new binary? Whatever you do, you must at all times always have a working boot loader in the processor, that knows what to do if you get a power loss during the reprogramming.
What I can't understand, is why you want to store a new binary in EEPROM - are you going to implement a hot-plug solution for distributing a new EEPROM to a customer? If you already have a new firmware before you ship the product, then you would obviously store the latest and greatest firmware directly in the flash. Or did you plan to use the EEPROM for a recovery image, in case the user have tried an over-the-air (OTA) or similar update that for some reason fails? So you then do a roll-back to the image in the EEPROM? If that is the case, then just create a routine that copies the flash contents to EEPROM to snapshot your recovery image. No need to transfer any data to the processor for this.
"So you need own code that reads data from the EEPROM into RAM, and then uses IAP to program a code flash sector." Yes. That code would be my secondary bootloader.
"So it would be better to store the data binay." I didn't get that. Does this mean data from binary file may be...? Is it different from .hex file.
"What I can't understand, is why you want to store a new binary in EEPROM.........If you already have a new firmware before you ship the product, then you would obviously store the latest and greatest firmware directly in the flash. "
The problem is i don't have the best firmware. firmware i have is just enough to fulfill the basic functionality (i will need future updates) and i will not have access to the device(except remotely) once it is installed, i will have access to the device through gprs, means i will be able to communicate to the controller through gprs. So, what i am planning is i will transfer the firmware file to controller through gprs and controller will store the file(data) onto EEPROM. and then further on it can program itself through secondary bootloader.
The hex file is more than twice as large as the real data, since every byte is encoded as two characters 0..9, A..F. Then you have some extra characters to encode record type, address, checksum.
You can convert the hex file to binary and just transfer and store this data. This is, after all, what your secondary boot loader have to write into the flash - the processor can't run any Intel-hex data.