booting from external flash

cancel
Showing results for 
Search instead for 
Did you mean: 

booting from external flash

402 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by PhilYoung on Tue Mar 27 06:34:04 MST 2012
I've got a custom board with 16 bit external flash, written a flash loader and created an application image to run from it.
If I reset the board with boot pins all pulled low, then connect with the debugger and set PC = 0x1c000000, SP = 0x20090000 then run the app it runs fine, so my startup code etc works fine.

I then changed jumpers and tested the boot pins as IO using the debugger to ensure they are set to boot from external 16 bit flash, all ok.

If I try to boot from external flash nothing happens.
then using the debugger to access the target the external flash is not visible, but making it visible using the debugger and setting PC / SP as before it crashes.
If I then reset the CPU using the debugger and try again the app runs perfectly.

The startup code begins by setting BASE_M4_CLK to IRC before doing anything else, so it should not be timing related.

I even tried putting a boot code which simply loops to itself at 0x1c000000 until I get in with the debugger and set R0 = 1, but when I connect with the debugger it is not executing at 0x1c000000.

so it appears that the boot rom is not setting up the memory controller since the flash is not visible when trying to boot from 16 bit nor flash.

Anybody got any suggestions?.

regards

Phil.
Labels (1)
0 Kudos
3 Replies

121 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by PhilYoung on Wed Apr 04 13:10:47 MST 2012
problem was solved, the PCB design house mis-connected the address bus, I did a dirty fix for this ( meaning page mode could not be used, but who cares for boot code ), however this left an addressing problem on A21. The code now runs fine.

I prefer booting at the native address of the boot rom as it avoids issues with the keil debugger trying to display at 0x0 when it it not mapped properly.

It seems that the debugger can crash this chip by trying to display memory that is unaccessible, in particular if it accesses SDRAM, so as the state of the device is unkonwn when the debugger first connects the shadow area is unknown and it's safer to buld the boot code to execute at 0x1c000000.

regards

Phil.
0 Kudos

121 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by DPeters on Tue Mar 27 13:14:42 MST 2012
Reply removed, Massimo beat me to it... 
0 Kudos

121 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Massimo Manca on Tue Mar 27 07:45:02 MST 2012
Hi Phil,
I assume we are talking about LPC4350; it is correct that the bootloader access external memory (EMC) at 0x1c000000 for non encrypted applications, so your flash memory should be located at 0x1c000000 selected by external CS0. The Cortex-M4 core is configured to start executing code, upon reset, with the program counter being set to the value 0x0000 0000. The LPC43xx contains a shadow pointer that allows areas of memory to be mapped to address 0x0000 0000. The default value of the shadow pointer is 0x1040 0000, ensuring that the code contained in the boot ROM is executed at reset. Hence the images for LPC43xx should be compiled with entry point at 0x0000 0000. This means that you have to build your code as if it is executed from address 0x00000000 and then flash it in your flash at 0x1c000000. If you are using Keil uVision4 you can download my example application at http://www.lpcware.com/content/contribproj/MassimoManca-lpc4300ex there are configurations working on external flash, internal ram and external SPIFI targeted to the Hitex demo board that has a 32Mbit flash mapped at 0x1c000000.
0 Kudos