BF514 bfrom_SpiBoot fails to boot Firmware from SPI Flash


I am having a boot problem I have some difficulties debugging.

Our system has a custom bootloader to update the system.

After power up, the custom bootloader is loaded from SPI flash. It reads out some areas in the SPI flash to detect if an application exists. If it does, it will boot that application using bfrom_SpiBoot( APP_START, BFLAG_PERIPHERAL | 3 | BFLAG_FASTREAD, 0, NULL );

Everything works perfect.

Now, every once in a while I make an application that causes the bfrom_SpiBoot to get stuck. If I debug the custom bootloader I get this error:

Target halted due to software breakpoint but no breakpoint found at address: 0xef000746

  Possible reasons are:

  1.An embedded breakpoint (EMUEXCPT instruction) in the code

  2.A breakpoint is placed at the last instruction of a do() loop

If I change a small thing in my application, ie, instead of initialize a global variable at runtime, I initialize it globally, then the booting works fine.

Additional, it does not seems to have anything to do with the size of the application, as much bigger applications loads fine too.

Finally, if I store my "failure" application at address 0, causing this application to be boot'ed at power up, it works fine.

Question. How can I debug bfrom_SpiBoot to find out what the cause of its bootfailure, for these few specific ldr files?

  • Hi I think I have the same problem as you. But I am actually using a BF514F16. I use "bfrom_SpiBoot(0x10000,(BFLAG_PERIPHERAL | BFLAG_NOAUTO | BFLAG_FASTREAD | 2),0,0);". My application is at 0x10000. My application boots fine most of the time. But like you said, sometimes you just change a variable or some code and it wont boot. I also once just moved a variable around in a struct and that helped for a while. Just cant figure out what it is. My previous post is below.

    Please let me know if you get any feedback or figure it out. I have read that one user recommended re-initializing the SPI just before "bfrom_SpiBoot" is called. Im going to try that today. Will let you know what I find.

    Kind regards,


  • 0
    •  Analog Employees 
    on Sep 30, 2015 8:24 AM


    Sorry for the late reply.

    I understand in both the cases (Henrik's on BF52x and Quintin's on BF51x), you were able to boot some applications using the ROM API. This confirms ideally there are no issues with the hardware and even the SPI as such to boot.

    Now coming to your question, can you once check the memory map of your modified application that failed to boot. The reason to mention this is that: The L1 data memory locations 0xFF80 7FF0 to 0xFF80 7FFF are used by the boot kernel and should not be overwritten by the application. Also, by default the address range
    0xFF90 7E00–0xFF90 7FFF is used for intermediate storage

    Regarding the dflags that's been used, I suggest to check the required address bytes to access the flash device, if you have used BFLAG_NOAUTO. For example: The BFLAG_TYPE3 indicates 3 SPI address bytes

    Having said the above, I would even check the stack size of the calling application (possibly allocating 1K).

    Further to debug, if the application failed to execute or the boot process didn't complete, I would suggest to use the tips outlined here

    Also, please check the anomaly 05000490 - SPI Master Boot Can Fail Under Certain Conditions: in case you are encountering this issue.




  • Hi,

    Thank you for the reply. I will test this once it happens again. I think it might be case 2. The SPI_BAUD setting in my case. I will get back to you once I've tested it if I get a image that wont boot.

    Thanks again,


  • I have looked into the issue.

    1) Regarding the anomaly,

    Do I have any control over that? I activate bfrom_SpiBoot, and I have tried both bfrom_SpiBoot( APP_START, BFLAG_PERIPHERAL | 3 | BFLAG_FASTREAD, 0, NULL ); and bfrom_SpiBoot( APP_START, BFLAG_PERIPHERAL | 3 , 0, NULL ); without any change.

    Could the bfrom_SpiBoot be flawed due to this anomaly? It could explain it. On an additional note, I have a very similar bootloader running on a BF54x processor and have never encountered this problem.

    2) I have tried changing the clock frequency ( from 386Mhz/96Mhz to 192Mhz/38,4Mhz ), no effect.

    3) "The L1 data memory locations 0xFF80 7FF0 to 0xFF80 7FFF are used by the boot kernel and should not be overwritten by the application"

    I am not using those, and actually my ldf has reserved the last 76bytes due to an anomaly

    4) "Also, by default the address range 0xFF90 7E00–0xFF90 7FFF is used for intermediate storage"

    Accodingly to the MAP file I only use up till address 0xFF9077B4.

    Where is it documented that the range 0xFF90 7E00–0xFF90 7FFF should not be used?

    5) The calling application is rather small, only L1_data_b_stack_heap is placed in DATA_B.