Content originally posted in LPCWare by sh on Thu Nov 21 14:41:30 MST 2013
I am replying to myself with some new information.
The behavior I described above was with the debugger (LPCXpresso) downloading and starting the image. When the ROM bootloader starts the image, without debugger intervention, it initializes address lines up to A14 (not A13 as described in the manual), and the others are initialized for passive pulldown.
I don't know why the debugger does things differently (and still wrong). It just makes it harder to figure out what happens. As it stands, the ROM boot code and the debugger disagree with each other, and with the documentation in the processor manual.
When booting from external parallel flash, one needs to make sure that all the code and read-only data is in the first few kilobytes of flash, that gets accessed before the pin muxing is set up correctly. In LPCopen, I can see nothing that makes sure this is the case. The SystemInit function is called before initialization of static/global variables is done, but neither the SystemInit function nor the various chip library functions it calls are put in a special section, so they can end up almost anywhere in the image, depending on the linking order. If perchance they end up too far away from the beginning of the image: Crash.
If anyone would elect to put the stack into external memory, it would be even worse, since the startup code would have to set up pin muxing and EMC configuration without using the stack, which precludes calling a function, and requires a few special attributes on the ResetISR function. Clearly, LPCopen is not even remotely able to cope with that in its current form. I guess it would require to convert SystemInit into a macro that does not use any real function calls, and contains only code that works with the registers.
