AnsweredAssumed Answered

Loader Bug with Multiple Init codes on BF 536/7 (update 6)

Question asked by Stephane on Dec 3, 2010
Latest reply on Dec 3, 2010 by CraigG

Hi,

 

My devices uses a Bootloader Loader in SPI flash that is factory programmed and supposed to be fixed.

This bootloader will try to load the real firmware from NAND flash.

If not found or corrupted, then it will continue to boot to the failsafe firmware in the SPI boot stream.

 

This is achieved through a binary LDR file with 2 init codes.

 

I put the following options in the project Load properties of my fail-safe firmware:

-init BootInit.dxe -init Boot.dxe

 

1. BootInit.dxe initializes the SDRAM and SPI baud rate

2. Boot.dxe loads the firmware.ldr from NAND flash

a. if found and checked, then it invokes the BOOT ROM to load it from SDRAM

b. if not found, it returns to boot loader rom to load the failsafe firmware from SPI

 

This was working perfectly fine until I had to fix the code for a new product and build the new version.

 

Using Visual DSP update 6, I could't get it working so I started debugging the rom boot loader.

Step 1 is fine.

The problem is in Step 2, the Boot.dxe is loaded correctly,

but the rom boot loader jumps to address 0XC00000 in SDRAM instead of 0XFFA00000 in SRAM which is my start function...

 

I checked with LDR Viewer, and yes, my LDR file is wrong, the last block boot.dxe is:

Flags = 0X000A Resvect + Init

Target Address = 0XC00000

ByteCount = 2

 

So there's a bug with this version of the loader utility.

Are you aware of it ? Is it fixed ?

Shall I downgrade to update 5 ?

I suppose I can modify my LDR file with an HEX editor...

Outcomes