MCF52221 - Bootloader question

[Zundapp]

Hi,

I am currently developing a bootloader for the MCF52221 which can program new firmware (S-Record file) into the microcontroller's internal flash. The programming of the flash works perfectly, but i'm having trouble getting the new firmware to run.

The start address of the firmware flash (FIRMWARE_BASE) is 0x00001200 (directly after the bootloader code)

To start the firmware i use the following code:
asm
{
    move.l  #FIRMWARE_BASE,a0           
    move.l  (a0),sp                       
    move.l  #(FIRMWARE_BASE + 4),a0   
    move.l  (a0),a0                       
    jmp (a0)                          
}
When this code is executed the microcontroller just hangs. Because the microcontroller hangs i think the firmware is not correct. I have tryed a jump to the address 0  and then the microcontroller restarts the bootloader, so the code above seems to work correct.


The firmware is a simple program which turns on a led when it is executed (based on a standard Codewarrior project).
Because it is a standard CodeWarrior project the Vectors are being copyed into the RAM by the following routine:
    if (__VECTOR_RAM != (unsigned long*)_vect)
    {
        for (n = 0; n < 256; n++)
            __VECTOR_RAM[n] = (unsigned long)_vect[n];
    }
    mcf5xxx_wr_vbr((unsigned long)__VECTOR_RAM);

I have adjusted the memory map in the linker command file (.lcf) to start from a address offset of 0x1200
MEMORY
{
   vectorrom   (RX)  : ORIGIN = 0x00001200, LENGTH = 0x00000400
   cfmprotrom  (RX)  : ORIGIN = 0x00001600, LENGTH = 0x00000020  
   code        (RX)  : ORIGIN = 0x00001700, LENGTH = 0x00018300
   vectorram   (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
   userram     (RWX) : ORIGIN = 0x20000400, LENGTH = 0x00003C00
}

So my question is: Am i forgetting something? Does anyone have an idea wat goes wrong, and how should i fix it? Any help would be greatly appreciated.

Thanks and greetings,
Erwin

[Zundapp]

Thank you all for the reply's. Indeed the address values were wrong.
The bootloader should jump to address 0x4800 to start the firmware (because i reserved 18.432 bytes for the bootloader).  I also changed the flash address offset in the memory map of the firmware and now the firmware runs fine.

Greetings Erwin.

[SimonMarsden_de]

Hi Erwin

This is just a suggestion, it may have nothing to do with your problem...

I have seen a situation where code couldn't run from Flash at a particular address. At first sight, there was nothing wrong, but the code just hanged.

It turned out that the code was programmed into an area of Flash which had been secured, and didn't allow code execution from that sector.

The initial security settings for the Flash are taken from the CFM Flash Configuration Field, which is always located at address 0x400 in the boot flash (immediately after the boot loader's exception vector table). When the processor boots, it reads the values from this field in order to determine the Flash protection settings. If you forgot to configure the field correctly, it could be leading to your hang.

Here's how I typically program it so there are no restrictions:


; Offset 0x00000400: CFM Flash Configuration Field
;
; For ColdFire processors with on-chip Flash, addresses 0x400 - 0x417
; are reserved array space used to determine the Flash module protection
; and access restrictions out of reset

KEY_UPPER:  .long 0x00000000
KEY_LOWER:  .long 0x00000000
CFMPROT:    .long 0x00000000
CFMSACC:    .long 0x00000000
CFMDACC:    .long 0x00000000
CFMSEC:     .long 0x00000000


I hope this helps


Simon

[Zundapp]

Hi Simon,

Thanks for the reply and the tip! I did not thought of that. But i dont think this is the problem because both the bootloader and the firmware program init the CFM Flash configuration field as total zero so there should not be any protection.

Greetings Erwin

[SimonMarsden_de]

Hi Erwin

That's a shame!

Did you check the values that your code is reading from the FIRMWARE_BASE and FIRMWARE_BASE+4 locations? What are they?

It's possible that it's reading a duff stack pointer. CodeWarrior may not be setting a sensible value, since the boot-loader normally ignores it and sets its own.


Good luck


Simon

[mjbcswitzerland]

Hi

Your code looks good - it is basically the same as that used in the uTasker boot loader (for Ethernet based firmware updates on M5223X).
However the start address seems a little strange.
The FLASH has 2k sectors so the first sectors start at
0x00000000
0x00000800
0x00001000
0x00001800
etc.
If you are putting you application to 0x00001200 it is 512 bytes into the third FLASH sector.
You say this is directly after by the boot loader.
Is it possible that your loader is deleting the FLASH which it will be programmed to beforehand and then also deleting the last few bytes of the boot loader, which then fails to jump to the new code since it has been removed?
Or is it possible that the boot loader has grown slightly and is now overlapping with the new code (resulting in corrupted values at the start of the new code location?
Starting the application in its own FLASH sector (0x00001800) may be suitable.

Regards

Mark

www.uTasker.com