Failed to upgrade image which was built using Codesourcery G++ Lite

[frank]

Hi,

I have a development board based on MCF52232 and STM25P16 SPI flash.

If I build the images using Codewarrior, all 3 combination of uTasker images ( boot loader, BM image and Upgraded Enc image) work fine.

But when I upgrade the firmware which was built using Codesourcery G++ lite, the board doesn't seems to be working.

During my test, both Boot Loader and Bare Minimum images were built using Codewarrior, but only the upgraded image was built using Codesourcery G++ lite.

I have used the GNU makefile attached with the uTasker stack (v1.4 ). 

Do I need to follow any special build process to make it work ? .

Thanks
Frank

[mark]

Hi Frank

It should be possible to use boot loaders compiled with one compiler with applications compiled with others.

You may need to check that the linker script file being used by GCC has the code linked to the correct starting address - compare this between the CW linker script and the GCC linker script beng used to see whether ther are differences.

Regards

Mark

[frank]

Hi Mark,

There are multiple linker scripts used in the makefile ( make_uTaserV1). Should I refer m52235evb-rom.ld  ( for upgrade image ) ? .

Regards
Frank

[frank]

all I did was changing the below table

MEMORY
{
  rom (rx) : ORIGIN = 0, LENGTH = 256K
  vectorram(RWX) : ORIGIN = 512M, LENGTH = 0x00000400
  ram (rwx) : ORIGIN = 512M + 0x400, LENGTH = 32K - 0x400
  ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0
}

with

MEMORY
{
  rom (rx) : ORIGIN = 0x1000, LENGTH = 124K
  vectorram(RWX) : ORIGIN = 512M, LENGTH = 0x00000400
  ram (rwx) : ORIGIN = 512M + 0x400, LENGTH = 32K - 0x400
  ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0
}

but still it didn't work. It looks like the boot loader loads the image (i believe it must have been upgraded the new firmware in the flash ).

- Frank

[mark]

Frank

m52235evb-rom.ld is used for a stand-alone target and
m52235evb-bm-rom.ld is used to work with the boot loader

It is correct that the only difference between the two is that he start address is moved:
rom (rx) : ORIGIN = 0x1000

When building with the make file targets for both will be generated.

However the value used depends on the size of the boot loader (if the boot loader were to be larger than 0x1000 th eaddress would need to be moved higher) and the boot loader must also use the same address (UTASKER_APP_START in uTaskerBootLoader.c).

Once these all match, the only other possible difficulty would be a possible mismatch of the boot loader parameters: the following gives details of this - http://www.utasker.com/forum/index.php?topic=902.0

Regards

Mark

[frank]

In my case, UTASKER_APP_START is assigned with 0x1000 in uTaskerBootLoader.c file.

When I compiled the uTasker project in Codewarrior, I was using the following setting in M52235EVB_BOOT_APP_FLASH_SPI.lcf file.

MEMORY
{
    flash   (RX)   : ORIGIN = 0x00001000, LENGTH = 0x0001F000 /* 4k reserved for SPI FLASH boot loader */
   vectorram(RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
   sram   (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x00007C00       
   ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0
}

( this works ).

 

So the equivalent GNU linker script has the following setting.

MEMORY
{
  rom (rx) : ORIGIN = 0x1000, LENGTH = 124K
  vectorram(RWX) : ORIGIN = 512M, LENGTH = 0x00000400
  ram (rwx) : ORIGIN = 512M + 0x400, LENGTH = 32K - 0x400
  ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0
}

which doesn't work.


Hopefully I am not missing anything.

[mark]

Frank

I think (thought) that a boot loader built with CW and an application build with GCC will run normally. Your configuration looks correct so maybe I am wrong?
Once you have performed the upload the board should reset and then check to see wither the new code is there and copy it to the application space - I am not suer but assume that thsi is working but then the loader tries to start the application and crashes.

My suggestion is that you use CW to step through the boot loader to see what it does. If it 'sees' that new code is available and jumps there you can check whether the code starst or immediately fails. You should find that the first two long word locations at the start of the application contains the following two values:
- initial stack pointer value (this should be the last location of SRAM - or very close to it at least). If this happens to be too high in memeory it will cause a failure.
- initial PC value.
The boot loader will then load the first value to the SP and jump to the secoind value (equivalent to loading it to its SP).

By verifying what happens at the location where it jumps - the actual code is in mcf5223X_boot.s as follows:

    /* If the uTaskerBoot return (without interrupt) the normal code can run */
    /* we load its SP and the PC and let it continue... */
    #if defined SPI_SW_UPLOAD || defined KIRIN3
    move.l  #0x00001000,a0
    move.l  (a0),sp
    move.l  #0x00001004,a0
    move.l  (a0),a0               /* use for boot loader from external SPI FLASH */   
    #else
    move.l  #0x00000800,a0   
    move.l  (a0),sp
    move.l  #0x00000804,a0
    move.l  (a0),a0               /* use for standard boot loader from internal FLASH */
    #endif
   
    jmp (a0)                      /* jump to the main program */


Regards

Mark