AnsweredAssumed Answered

Booting BF573 from Flash after writing .bin to flash

Question asked by MattZ on Jan 10, 2014
Latest reply on Feb 21, 2014 by CraigG

Hi All,

 

I'm trying to load a program via JTAG onto a parallel flash on to a custom board based on the BF537. The board is configured to boot from a parallel flash. The design uses a 16-bit flash but only the lowest 8 bits of the data bus are used.

 

During development, I've had no problem when loading the .dxe onto the chip via VDSP/USB-ICE. One functionality of my program is that it can write the program's boot data to the flash. We do this by parsing the .ldr file generated from the same .dxe and writing each 8 bits to the lowest 8 bits of each address. I use elfloader to generate the .ldr file like this:

 

elfloader my_program.dxe -b Flash -f HEX -Width 8 -p 0x0000 -init my_booter.dxe -o my_program.ldr -si-revision 0.3 -proc ADSP-BF537 -MM

 

I'm now moving away from using VDSP/USB-ICE on new boards to programming the flash via a more generic JTAG based programmer. The first thing I tried is to read the flash from a board programmed as described above and saved the memory dump to file. I then wrote this file to a new board via a JTAG programmer. This worked, demonstrating to me that my JTAG programming tools were working.

 

The next thing I want to do is generate the binary data for the rom directly rather than storing a dump file from a previously programmed board. To do this, I'm generating a .bin file from elfloader like this:

 

elfloader my_program.dxe -b Flash -f BINARY -Width 16 -p 0x0000 -init my_booter.dxe -o my_program.bin -si-revision 0.3 -proc ADSP-BF537 -MM -ZeroPadForced


This ALMOST works. Comparing the .bin file generated with the above command and the memory dump file, there is only 1 bit different. Here are the first few bytes from the memory dump:

 

0000000: 4000 0000 8000 ff00 0400 0000 0000 0000  @...............

0000010: 1200 0000 6c00 0100 0000 0000 0000 0000  ....l...........

0000020: a000 ff00 5600 0100 0000 0000 0200 0000  ....V...........

0000030: 6600 0100 6700 0100 4000 0500 c000 0400  f...g...@.......

 

And here are the same first few bytes from the .bin file:

 

0000000: 6000 0000 8000 ff00 0400 0000 0000 0000  `...............

0000010: 1200 0000 d800 0200 0000 0000 0000 0000  ................

0000020: a000 ff00 5600 0100 0000 0000 0200 0000  ....V...........

0000030: 6600 0100 6700 0100 4000 0500 c000 0400  f...g...@.......

 

Note that the first word from the .bin is "6000" and the first word from the dump is "4000". After loading the .bin file with the "6000" to the board, the board does not appear to load the program or run. If I change that value in the .bin file to "4000" (that's just one bit different), the board behaves and boots as expected.

 

Now for my question: Can anyone clarify to me what these first few bits control? Better yet, can anyone explain how I should modify my bin generation code to get the correct value? I know I could always add a stage to my build process to manually change that bit, but I'd prefer not to and am currently assuming this is configured by some setting in elfloader.

 

I've tried reading through http://www.analog.com/static/imported-files/software_manuals/50_ldr_mn_rev_2.5.pdf but didn't find anything obvious. Any help would be greatly appreciated.


 

Thanks in advance

-Matt

Outcomes