Creating LDR file for BF514F Internal SPI Flash

I've been researching how to go about getting working code loaded into my BF514F processor SPI internal flash on my custom target board. I'm using the GNU Blackfin Tools and have working code that I've been testing and debugging.

Now I'd like to stuff the working code into the internal SPI Flash in the BF514F processor and then select the bootmode to SPI mode (mode 0x02) and have the board come up working. From all my reading this is apparently not trivial whatsoever. Here's where I'm at so far...

I've been able to create an LDR file using the following command:

c:>bfin-elf-ldr -T bf518 -c -B 8 myprog.ldr myprog

My assumption is I needed an 8 bit output for the SPI flash but not really sure. Any other documentation regarding bfin-elf-ldr other than its help seems essentially non-existent. I'd like some clarification on this if anyone happens to know. And if there is any detailed documents on bfin-elf-ldr would be so greatly appreciated. I figured 16 bit was used for a 16 bit wide parallel flash hanging out on a bus somewhere so I opted for 8 bit.

I used the ldrviewer application to view the contents of my newly created LDR file and find that everything is broken up into blocks with target addresses for each section.

So now that I have an LDR file is it as simple as programming the raw LDR file byte by byte (although it'll really be page/block by page/block in the SPI flash) into the SPI flash memory and tada it'll load properly when booting from internal SPI flash?



  • 0
    •  Analog Employees 
    on Feb 21, 2013 8:25 AM

    Check if this will help:

    By the way do you think about merging your functional code into the existing working u-boot? Then you can take the advantage of the existing working u-boot frame, including the arch/board init, easy for system porting/config and make, ldr tools etc.

  • Thanks Aaronwu, yeah I had found that page. Its probably the most in depth doc on using the bfin-elf-ldr tool. I think it was how I figured out how to form the command line arg and I just modified for my purpose without fully understanding what each arg actually did.

    Yeah, I've been looking into u-boot pretty heavy too thinking it might be a quick way to get code into the SPI flash but I have like a week (doubt I make the date) before demo'ing this board so seems more complicated at the moment. Probably a good thought a month or two ago. I've about decided it'll be faster if I try to port over some old xmodem-crc code from an AVR project I have and run it through JTAG debug then load the LDR file over a terminal, buffer the file and stuff into the SPI flash. Thanks for the response.

  • So I've run out of time completing the XMODEM code to program the internal serial FLASH. Made much progress on it but just can't finish it right now. In a last ditch effort to make the demo I can successfully load code using UART boot mode however after the LDR file has completed the upload the program never starts. I think its one of two things that are causing the code not to run:

    1. I'm not creating a correct LDR file


    2. I have to create initcode for the LDR file so that SDRAM is configured before the code starts.

    Here's how I create my LDR file

    c:>bfin-elf-ldr -T bf518 -c progcode.ldr progcode --bmode uart

    then I load with this

    c:.bfin-elf-ldr -l progcode.ldr /COM6

    The code itself JTAG'ed over during debug works perfectly. The whole code lives in L1 RAM and have only three large variable buffers that reside in SDRAM. Once main() is called from the supplied crt0 in the GNU Toolchain part of my initialization process is to setup my clocks and then I setup the SDRAM. Works great when debugging over JTAG.

    When I boot over UART do I need to pre-init the SDRAM before L1 RAM is loaded with code? Only three variable buffers live in SDRAM, the code itself totally resides in L1 RAM and the SDRAM variables aren't called prior to me initializing the SDRAM, although they are global so the addresses are assigned or known.

    Another thing that just occurred to me is that my build is for debug which includes all the added debug code. Do I have to remove that or can it remain for now?

    Any help solving this issue would be very much appreciated.



  • 0
    •  Analog Employees 
    on Mar 4, 2013 11:28 AM

    I think most of this was covered in your other thread.  Is there any parts of this that you're still having issues with?

    For what it's worth:

    • Yes, you'll need to pre-init the external memory, but you seem to know this already.
    • And No, you don't need to remove the debug stuff, although you might be better off if you're trying to squeeze everything into L1.


  • I believe I'm creating a valid LDR file now and includes the initcode you

    helped me with that initializes the SDRAM. My only issue left now is

    watching the code actually run on the system. It just loads and then does

    nothing. I'll be revisiting the issue later this week to try and figure out

    what is going on. As far as I can tell from my map file everything is in

    its proper location so there shouldn't be a problem but there is still an


    Good to know about the debug info. I've been building release code but

    there still is some residual debug placement in the lower SDRAM area for

    some reason. Even though debug is set to None in the build settings.



    On Mon, Mar 4, 2013 at 6:30 AM, StuH <