Problem booting 1857 from SPIFI w/ trivial app

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by Grant.Edwards on Wed Apr 24 11:56:33 MST 2013

I'm using a Keil mcb1857 board, and I'm unable to get it to boot an
app from SPIFI either directly, or by adding a header so it gets
copied into SRAM and run from there.

The quad SPI part is identified by OpenOCD as a Spansion s25FL032, and
the Keil schematic shows it as an S25FL032P0XMFI01.

The application is a trivial assembly-language program that flashes an
LED.  The code is position-independent and is shown below:

        .syntax unified

        .section .text
        @ configure P9_0 as GPIO P4.12
        ldr r0, =0x40086480
        ldr r1, =0
        str r1, [r0]

        @ configure GPIO 4.12 as output
        ldr r0, =0x400F6010
        ldr r1, =(1<<12)
        str r1, [r0]

        @ point to P4 toggle register
        ldr r0, =0x400F6310
        @ toggle P4.12
        str r1,[r0]

        @ approx 50ms delay when running at 96MHz (ISP mode)
        @ approx 400ms delay when running at 12MHz (JTAG)
        ldr r3, =1000000       
        subs r3, 1
        bne  delay

        b loop

I can run the code without problems in a variety of ways:

When I load the program into SRAM at 0x10000000 using the ISP protocol
it runs fine.  I can then map the SRAM to 0, and run it starting at 0,
and it works fine.

When I enable SDRAM, map SDRAM to 0, load the program at 0, set PC=0
and go, runs fine.

I can program it into SPIFI, and execute it at 0x14000000 or
0x80000000 using gdb+openocd+JTAG, and it works fine.

I can map SPIFI to address 0, and execute it at 0, and it works fine.

What I can't get to work is actually booting from SPIFI.  When I set
the startup pins to select SPIFI as boot source, I can see some data
being read from SPIFI. Then SPIFI activity stops, and the board is

If I add a program header to the image in SPIFI, then it reads about
10X as much data as without the header (it appears to be reading an
entire 512-byte block as it should), then the board is dead.  If I
increase the block counter in the header from 1 to 2, it reads twice
again as much data from SPIFI after boot, then the board is dead.

The boot ROM is obviously recognizing the SPIFI part: without an image
header it only reads a small amount from SPIFI.  With an image header,
the block count in the header controls how much is read.

Is there something unique you have to include in the application
code when it's being _booted_ from SPIFI that isn't required when
you're running from SPIFI, or SRAM, or SDRAM?