MCF52235 - How to do bootloader

[Kremer]

 Hi Mark and Petter

 I´m looking for some examples on how to do a boot loader for MCF52235 chip. Can you please point me to some code examples or documentation that explains the basic procedures of it? I mean, relocate the interrupt vectors, deal with initializations and other needs...

 Thank you for your help.

 --
Alban Edit: real matter in Subject line + split/moved to appropriate location.

Message Edited by Alban on 2007-06-27 02:54 AM

[Petter_fupp]

I found some relevant information in this thread. The 52235 reference manual regarding the CFM might also help.

Maybe, sometime into the future, an intel-hex bootloader combined with the TCP/IP stack example code will be available somewhere.

Do you use CodeWarrior or a GNU toolchain? I don't know much details about the CodeWarrior linker stuff.


Message Edited by Petter_ on 2007-06-25 01:40 PM

Message Edited by Alban on 2007-06-27 02:54 AM

[Kremer]

 Hi Petter

 Thank you for your indication.

 I´m using codewarrior as a IDE for my projects.

 Actually, what i intend to do is something easier than a complete ethernet boot loader. My goal is to develop a code (simple boot loader) wich will basically check on an external serial flash (M25P40) for any new code. If it has a new code, the program will transfer it from external serial flash to coldfire´s internal flash, on the sector right after the boot loader code. So, after doing all the flash burning and checking, it will load the PC with the address of the first instruction of the new downloaded application. This new user application will have an interface to receive any new code, burn into the external serial flash and CRC it to validate as a new user code. After a reset, the simple boot loader will be able to reflash the device.

 It´s something similar to what Mark did on uTasker, since his bootloader doesn´t configure the FEC, but only looks for new user code on high part of the flash memory area and reflash the low part of it. So i have to understand the basics of relocating things like interrupt vector and initializations.

 All my applications with no boot loader codes start in flash address 0x00000000 and it initializes the PC with the address of the first instruction to be executed on this position and on next position (0x00000004) there must be the SP init value. then starts the interrupt vectors area. 

 So, i intend to put the bootloader code on the first flash sector and the doubts begin with the vectors relocating and goes on.

 Mark, can you point me some code examples of docs?

 Thank you

Message Edited by Alban on 2007-06-27 02:54 AM

[mjbcswitzerland]

Kremer

The boot software can't deliver the interrupt vector table since it doesn't know where the interrupt routines are located in the applocation program which will be downloaded. Therefore it can either just have its own interrupts or it can have none. I don't use any interrupts in the uTasker bootloader so the address 0x00000004 has the boot loader code start address pointing to 0x00000008 where the code begins.

Jumping to the application is easy since the application can be linked to have its vector table - including reset vector - at any FLASH sector start (I use 0x800 - the next FLASH sector). The boot software can read the reset vector from the start location and jump to it. It can also set the SP as if the program were starting from a real reset at this location.

    move.l  #0x00000800,a0    move.l  (a0),sp    move.l  #0x00000804,a0    move.l  (a0),a0    jmp (a0)

The application must then set up an interrupt vector table in SRAM because the boot vectors are not of use.
A 1k block at the beginning of SRAM must be reserved and the VBR is set to point to it. Then the application can load the interrupt vectors it needs when each driver requiring interrupts initialises.
Note that the VBR doesn't use the lowest 11 bits and so the SRAM must be on a 1Meg (if I remember correctly) boundary and the first 1k is the vector table (forced there in the linker script for example).

 extern unsigned long __VECTOR_RAM[]; for (n = 0; n < 256; n++) {  __VECTOR_RAM[n] = (unsigned long)undef_int;                      // set undefined interrupt for all interrupts at start } mcf5xxx_wr_vbr((unsigned long)__VECTOR_RAM);                         // move vector to RAM position

 This is the typical initialisation where each vector location is initialised with a default handler (used to help debugging if the user forgets to insert the correct one). The VBR has to be set with the special call (delivered with the CW stationary).

To enter interrupt the following type of routine is typically used:

static unsigned char *fnSetIntHandler(int iVectNumber, unsigned char *new_handler){    extern unsigned long __VECTOR_RAM[];    unsigned char *old_handler;        old_handler = (unsigned char *)__VECTOR_RAM[iVectNumber];    __VECTOR_RAM[iVectNumber] = (unsigned long)new_handler;    return old_handler;     }

 

Regards

Mark

www.uTasker.com

 

Message Edited by Alban on 2007-06-27 02:55 AM

[Kremer]

 Hi Mark

 Thank you for your help.

 I understand that you must initialize the stack pointer with the user code needs (move.l  #0x00000800,a0  move.l  (a0),sp) and then load the PC with the address of the first instruction of the user code (move.l  #0x00000804,a0  move.l  (a0),a0  jmp (a0)) to do a clean jump to the user code. Basically you said the application must set up the interrupt vectors on RAM when using the boot loader. Since the application needs to update the VBR register with the first vector address, can i set up my application´s .lcf to hold the interrupt vectors on flash (from 0x00000808), and reinitialize the VBR with the start address in flash (0x00000808), instead of RAM?

Message Edited by Alban on 2007-06-27 02:55 AM

[mjbcswitzerland]

Hi Kremer

Unfortunately the VBR does not support this due to the fact that it only implements the higher 12 bits (see section 3.2.6 in the M52235 user's manual). The lower 20 bits (not 11 bits as I wrote previously) are fixed at 0. Therefore you can position the vector table only at 1Meg boundaries which doesn't help since the FLASH can also only be positioned at 512k boundaries (using FLASHBAR).

Therefore I think that the only method is to have these set up in SRAM.

Note that the use of SP and start address as I showed is optional. The application can in fact be linked to any location as long as the boot loader knows where this is. Also the loading of the SP is optional since the code generally sets up the SP itself before calling any subroutines.

Regards

Mark



Message Edited by Alban on 2007-06-27 02:56 AM