SPIFI Driver Under LPCXpresso (using LPC43xx)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mark.williamson.cml on Thu May 31 04:10:43 MST 2012
Hello,

On our LPC43xx-based board, we've included an SPI Flash device that we're intending to use for boot. I'm just having a look at getting this to work.

I'm having some trouble getting the official SPIFI drivers to work. I'm using the LPC43xx CMSIS release 120427 from here:
http://sw.lpcware.com/index.php?p=lpc43xx.git&a=tag&h=lpc43xx_cmsis_120427

This seems to include binary .lib files for the SPIFI driver, but they will not link with the binaries produced under LPCXpresso, giving errors along the lines of "Conflicting CPU architectures 13/0".

It seems to be an instance of this problem:
http://sourceware.org/bugzilla/show_bug.cgi?id=11897

I suspect I'm falling foul of it now because those libraries were compiled for another toolchain; is there an LPCXpresso-approved version of these libraries available? I'd be happy to build my own from source but I've so far not managed to find source code for the driver.

As far as I can see there is not an in-ROM driver for the SPIFI on this chip, which would otherwise have been my preferred option. Is this correct?

What would be the best way to proceed? I've tried bodging the .lib files provided to match the expectations of the GNU linker but without much success.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 11 13:50:00 MST 2012
You still need to put the code that you want to run from RAM into the flash at boot time. It doesn't look like your current mods to the linker script are doing this.

I suggest that you get things running with a simple example first before trying to get your full application running in this manner. Take a look at the following FAQ...

http://support.code-red-tech.com/CodeRedWiki/CodeInRam

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mark.williamson.cml on Mon Jun 11 06:00:23 MST 2012
I'm hoping to get a program image into the SPI Flash that will then be loaded into RAM by the bootloader. I want the code to run from RAM because in the past we've had trouble with IRQ latency when running from Flash[1]; some of our code has very stringent timing requirements.

My current attempt at doing this attempts to prepend a boot header to the RAM-targetted binary using a modification to our custom linker script, thus:

...

SECTIONS
{
.boothdr_block : ALIGN(4)
{
KEEP(*(.boothdr))
} >SPIFIflash AT>SPIFIflash

/* MAIN TEXT SECTION */
.text : ALIGN(4)
{
            ... contents omitted for brevity
} > RamLoc128

... and so on

My intention (at least) here is to have the boot header genuinely stashed at the beginning of the SPI Flash, followed by a copy of the application binary, which is still linked to run out of RAM. My understanding is that this would cause the ROM boot loader code to copy the application binary into RAM and begin the execution as normal.

I'm not confident that I've done the correct thing in trying to prepend the header like this. But I'm also unable to try to program the SPI Flash using the supplied external Flash driver - it attempts to program it at 0x10000000 (i.e. the RAM address that the code is linked for), then reports:

05: File 'BreakoutBoard.axf' load failure: Eg(10). Attempt to load into missing flash area.

Which seems understandable, since I think the SPI Flash is mapped at 0x14000000 on this part. If I alter the linker script so that the application is located within the address range of the SPI Flash then the programming process does succeed, although I've not succeeded in getting the resulting code to boot.

I'm currently generating the boot header by hand (and not using the CRC or AES features).

If somebody could point out any particular clangers I am perpetrating or misunderstandings I've acquired then that would be very helpful - I've got a feeling occasionally that I'm doing "almost" the right thing but evidently I am messing something up with my approach!

Thanks very much,
Mark

[1] In case that statement sounds odd: The specific problem was that depending on the location of the IRQ handlers in Flash the latency to enter the handler varied. This threw off some of our timings, as when we changed unrelated code the alignment of those handlers sometimes changed. For that project we were able to constrain the alignment using gcc __attribute__ directives so that the behaviour was consistent; I was hoping to avoid that problem this time by just running from RAM by default.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mark.williamson.cml on Fri Jun 01 04:07:38 MST 2012
Thank you - I've switched to using the LPCXpresso driver to flash the part, rather than programming in application.

I'm running into a bit of confusion on exactly how the process is to work though - I have read various threads on this forum and looked through the manuals and I still feel a bit vague about a couple of topics.

I want to use the boot ROM on the LPC43xx to load the application into RAM. I'm trying to get the image into Flash in whatever format that bootloader expects, but I want the code to be linked to run from RAM once it's kicked off.

I'm not clear on:
[LIST]
[*]How the header expected by the ROM bootloader should be added. Should I generate it and put it in a linker section? Can I get the tools to do it?
[*]How do I need to alter the linker scripts I'm using (if it all) to get code that already runs from RAM to boot from Flash OK?
[/LIST]

I've tried adding the header manually to the start of the binary but I'm not 100% convinced either that I've done it correctly, or whether I was supposed to!

I've not managed to persuade the downloader into attempting a programming without setting the LMA of the text segment explicitly to be in the SPI Flash area - which seems fair enough. However even when I do that and programming succeeds I get an error (Wt:43:Invalid Reset Vector - out of range) and the device fails to boot.

I can supply more detailed error logs if necessary. In the meantime I'll keep trying to puzzle it out.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu May 31 04:34:28 MST 2012
The easiest answer would be to just use the driver that we supply in LPCXpresso (in both source and prebuilt form).

For more details, please read the following FAQ:

http://support.code-red-tech.com/CodeRedWiki/LPC1850_4350_Support

which is being regularly updated with the latest information regarding support for these parts.

Regards,
CodeRedSupport