How to upgrade firmware (via ethernet or rs232) for 52235? Bootloader...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to upgrade firmware (via ethernet or rs232) for 52235? Bootloader...

2,093 Views
Ciumbia
Contributor I
Hi all,
 
I am researching on how to remotely upgrade the firmware on the 52235 Coldfire. I have an external SPI flash capable of holding the full 256k of the code, so my steps would be:
1- load the new firmware into the external flash via the main program;
2- change the PC and/or reboot the micro in order to execute the bootloader/flashing utility which overwrites the internal flash (but not the bootloader);
3- change the PC again in order to have it pointing back to the main code (and reboot if necessary).
 
Having an external flash is convenient and safe because, even if the power fails during the internal flash erasing process, nothing is lost; the bootloader/flasher will simply restart the flashing operation at the next bootup. However, this poses a problem:
 
- when I change the code execution address from main program to flasher, I need to do it in a permanent way, so that, even if power fails, at next power-up the code running will be the flasher. Is there a way to change the starting execution address which is, I think, written in flash? If, in order to change it, I have to erase an entire page, the page must be dedicated solely to this function; is it possible?
 
- does anyone have a ready example for this operation? I mean either a working code or a pseudo-code example... can this be done in C or do I need assembler?
 
I hope I have been clear enough to explain the problem... if not, I will try and rephrase.
 
Thanks, best regards,
 
Paolo.
 
Labels (1)
0 Kudos
2 Replies

390 Views
Ciumbia
Contributor I
Hi Kremer,
 
well, I followed your advice, which indeed is the best possible solution I can think of; I have implemented it but... something is wrong!
 
I have written the bootloader which fits in the first 0x0fff locations (two pages), I have simulated it and it _seems_ to work fine.
I have then prepared a second, very simple application (a LED flasher... what a fantasy!), I have compiled it with the linker directive:
 
flash   (RX)   : ORIGIN = 0x00001000, LENGTH = 0x0003F000
 
the end of the startup code is as follows:
 
   jsr  BootLoader 
   move.l  #0x00001000,a0
   move.l  (a0),sp
   move.l  #0x00001004,a0
   move.l  (a0),a0
   jmp (a0) 
 
which means that, when the bootloader exits, it moves the SP to 0x1000 and the PC to 0x1004.
This should start the led blinking but... no luck!
 
Am I missing something? How can I debug it with codewarrior? I don't think there is a way to put together two different codes... Can someone please help me find the problem?
 
Thanks a lot!
 
Paolo.
 
P.S: the main application is built with the Codewarrior stationery for the 52235, therefore starting from MCF_52235_vectors.s. Could this be the problem?
0 Kudos

390 Views
Kremer
Contributor I
Hi Paolo
 
 Thinking of your problem, the easiest way is to reserve a flash page (external) to have things like checksum of the new code and some flags, to indicate that this code in external flash is valid and if that code was flashed to internal flash or it must be flashed.
 I would always start the execution on this flasher routine, wich would check the flags to know if the program was already flashed or not. If not, it would first validate the checksum and depending on the result it would flahs the internal memory or not. If the flags point that the code was already flashed, just update the PC with the address to the next valid page, wich is the main code execution start. If the flags point that the code must be flashed, the routine would do it and before update the PC to main code it would change the flags on external memory, so at next power up the routine will know that it must update the PC and not reprogram the chip. The weak point is that you´ll lose a  page on external flash to hold the checksum and flags.
 I didn´t do it yet, because my actual design doesn´t have an external memory for low cost reasons, but on the next design i´ll do it.
 Any other suggestions would be great.
 
 Regards
0 Kudos