Running from SPIFI : UART FIFO Overrun

[lpcware]

Content originally posted in LPCWare by jcarter on Wed Oct 24 06:00:15 MST 2012
Hello,

  I have been using the LPC1788 on a project, and I now want to move to the LPC18XX series.

  I have quite a lot of program data, so running from SPI really appeals to me. I am currently using a 4MB Quad SPI flash device where my program is running from.

  The issue I have now, is that I am getting UART buffer overruns when I communicate at 115200 baud with my device over the UART. This had no trouble what so ever when I was running from internal FLASH on the older LPC1788 device. Is it that running from SPIFI is just too slow?

  If I'm having this trouble on the UART, what will happen when I get to USB??

  I'd appreciate it if anyone could lend a hand.

Cheers,
James

[GorgHorry]

Overrun error occurs when another byte of data arrives even before the previous byte has not been read from the UART's receive buffer. 

Regards: types of fertilizers

[lpcware]

Content originally posted in LPCWare by uratan on Fri Feb 01 14:40:00 MST 2013
It's a very good news!

I'm planning to make some video capture device with LPC1830-Xplorer,
and considering now to use SPIFI-interface to feed the data from external logic, like:

[1] connect CS to SPIFI-flash, then boot
[2] copy program codes onto RAM
[3] switch CS to my-SPIFI-device (made by FPGA, read-only)
[4] USBDMA feeds data directly from my-SPIFI-device
[5] connect normal SPI to FPGA for write-commands/read-status connection

The documents must help me, thanks.

(I'm dreaming that
(expand Quad-I/O-High-Performance-Read-Mode of S25FL032 to bi-directional,
(and use SPIFI as a generic memory-mapped small wire external R/W bus...

 (Sat Feb  2 06:38:54 JST 2013)

[lpcware]

Content originally posted in LPCWare by noahk on Thu Jan 31 19:00:07 MST 2013
The SPIFI registers have been released by NXP.
Please see:
http://www.nxp.com/documents/user_manual/UM10430.pdf
Chapter 19

Noah

[lpcware]

Content originally posted in LPCWare by uratan on Tue Dec 04 17:19:47 MST 2012
(Where does this box become narrow to ?)

And this is the result of spifi_init() which is in the boot-ROM.
<PRE>
spifi_init_in_bootROM(obj_mem, 4, 0x80|0x40, 12);

4000_3000:  0004_00C0  EB13_0000  0000_0000  A5A5_A5A5   &lt;==set by spifi_init() in the boot-ROM
4000_3010:  1000_0000  ---------  EB13_0000  0200_0021
</PRE>


(I'm using LPC1830, chip revision A, boot-ROM version 11.1 @ 0x1040_7ffc)



&nbsp (Wed Dec  5 09:19:19 JST 2012)

[lpcware]

Content originally posted in LPCWare by uratan on Tue Dec 04 05:34:50 MST 2012
Thank you for important information.

See SPIFI register settings used by the tests below.
  (see also attached patch1204.txt)

when uart3-boot
  (used for waveform 001-006, 101, 201,202, 301)
<PRE>
run @ 0x100826C9 (M3_MEMMAP: 0x10000000)
40003000:  400FFFFF  00000000  00000000  00000000   &lt;==may have reset values
40003010:  10000000  --------  00000000  02000000

40003000:  6803FFFF  EB130000  00000000  000000A5   &lt;==set by spifi_init() in the library
40003010:  10000000  --------  EB130000  02000021
select test
</PRE>


when SPIFI-boot

  (used for waveform 102, 203,204, 302-305)

<PRE>
run @ 0x100826C9 (M3_MEMMAP: 0x80000000)
40003000:  4009FFFF  EB130000  00000000  A5A5A5A5   &lt;==initialized by boot-ROM
40003010:  10000000  --------  EB130000  02000025

IDIVB_CTRL is: 0x09000820
40003000:  4009FFFF  EB130000  00000000  A5A5A5A5   &lt;==(unchanged)
40003010:  10000000  --------  EB130000  02000025
select test
</PRE>


I never thought spifi_init() in the library initialized so differently

from boot-ROM did.



Anything else ?



  (Tue Dec  4 21:34:06 JST 2012)

[lpcware]

Content originally posted in LPCWare by noahk on Fri Nov 30 11:20:22 MST 2012
Hi Uratan,

I was looking at the pictures you took of the SPIFI. It looks to me like the SPIFI is not performing as it should.

There is a bit in the SPIFI CONTROL register which disables prefetching. This bit should not be set for normal operation. The driver you have must be setting that bit, and disabling the prefetch. Hopefully a new driver library will be released soon, but until then here is what you can do.

You can verify that the prefetch is being disabled by reading register 0x40003000 (this is the first register of the SPIFI register space). If bit 27 is 1 (0x08000000), then the SPIFI is not performing as well as it should.

To fix this, clear bit 27 after calling spifi_init.

This line should do the trick:
*(volatile uint32_t*)0x40003000 &= ~(1 << 27);

Noah

[lpcware]

Content originally posted in LPCWare by uratan on Thu Nov 29 18:54:33 MST 2012
> dis-advantage: [3] a interrupt may be not accepted until ...

I had examined the SPIFI-flash more about interrupt.
see usual < http://www002.upp.so-net.ne.jp/uratan/xplr/spifi.html#intr >

About aN interrupt, I found I should not be so serious.
Yes there are some delays, which varies, but it is enough
very fast, I think.


About speed, I'm still thinking... see MY SPEED SCORE CHART below.
  (To make it simple, think as CPU clock 96MHz and SPIFI 48MHz)
<PRE>
  Fast
   |
  96: LPC1830, fetch codes from RAM
   |
  96: LPC1830, fetch codes from cache in SPIFI-interface
   |   (there may be no penalty)
   |
  24: LPC2141 24MHz, fetch codes from internal flash
   |
  12: LPC1830, fetch codes from SPIFI-flash (1)
   |   (ideal case, it takes 4SCKs per 16bit-instruction)
   |
  1.5: LPC1830, fetch codes from SPIFI-flash (2)
   |   (simple worst case, (CS_HIGH+12+16)SCKs per instruction/data)
   |
  Slow
</PRE>


The range from worst to best is very wide, over 50 times.

Whether the all code of the loop is in the cache or not,

may have high sensitivity.



But I can't know the best/worst ratio of my codes which

will be written from now.

So, if run codes from SPIFI-flash, I will keep my mind

to take care about speed, shall measure more often.



  - * - * -



I expect to change color of post/reply date with adding timezone, please.

[lpcware]

Content originally posted in LPCWare by uratan on Thu Nov 22 03:22:32 MST 2012
Thank you for your advice.

I have taken some more waves, see the results.
  < http://www002.upp.so-net.ne.jp/uratan/xplr/spifi.html >

- * - * -

I'm planning to construct some USB high-speed device, which will not
need so large memory, so my thought about SPIFI-flash at this time is:

SPIFI-flash advantage:
  [1] the capacity.
  [2] the cache is effective enough for some loop.
  [3] occupy small number of pins.

SPIFI-flash dis-advantage:
  [1] the penalty when no-cache-hit is rather heavy, I think.
  [2] when no-continuous-read is rather heavy, too.
    (*) branches may disturb continuous read operation.
    (*) long-word-immediate operation like below, too.
        ldr r0, [pc, #196]
  [3] I'm worry about that a interrupt may be not accepted
until SPIFI interface releases CPU bus cycle...
  [4] misc delay may vary by code layout vs cache's 8byte boundary...
    (inserting single NOP may affect big change of process speed)

I shall write codes which is robust enough against fluctuation
of process speed.
But, by running all codes from RAM, it will be very simple and fast.
  ( and freely re-initialize SPIFI interface ;-)
It is very attractive for me now.

BTW, do you know the value for CS_HIGH which is used
by the boot-ROM at boot time ?
  (about chip revision.A, because I have only this)

[lpcware]

Content originally posted in LPCWare by noahk on Wed Nov 21 07:50:02 MST 2012
Hi,

When running from SPIFI, you want to make sure to increase the SPIFI clock from 18 MHz to as high as it will go. The LPC1830 supports 104 MHz for the SPIFI clock:
http://www.nxp.com/documents/data_sheet/LPC1850_30_20_10.pdf
Chapter: 11.15 SPIFI

The S25FL032P supports up to 80 MHz for the QIOR Quad I/O Read command:
http://www.spansion.com/Support/Datasheets/S25FL032P_00.pdf
18. AC Characteristics

I see that your test code already has the re-initialize logic for the SPIFI, and the code for increasing the clock speed. Be sure to re initialize the SPIFI first, and then up the clock speed to 80 MHz. You should then see a big increase in performance. You can't increase the clock speed first b/c the driver relies on being able to perform a JEDEC ID read which is only supported on this Spansion part up to 50 MHz.

Please let me know how this works out,

After you get this working, you can also look into higher speed Quad parts capable of running up to 104 MHz in Quad. The Spansion part is good b/c it can always accept a serial command after a 0xff reset, but there are others that have those same characteristics but run a little bit faster.

Noah

[lpcware]

Content originally posted in LPCWare by uratan on Wed Nov 21 03:37:39 MST 2012
I'm trying LPC1830-Xplorer. (chip rev.A)
I had examined SPIFI-flash for myself.

  < http://www002.upp.so-net.ne.jp/uratan/xplr/spifi.html >

umm..., I, too, may not choose running codes directly from SPIFI-flash...

[lpcware]

Content originally posted in LPCWare by mdittrich on Thu Nov 01 15:12:03 MST 2012
Thanks again Noah,

Unfortunately I cannot send you my test code, it is a chunk of our application.  It has definitely more of a "branching" than "calculating" mix to it.

The differences you mentioned in the SPIFI mapped memory ranges is good to know... sounds like info that should be in the user manual :) I think it only mentions "debugability" (my term) as the only difference between the two ranges, that and the boot rom sets the M4MEMMAP to 0x14000000.  I do not use the Keil tools, and I get the impression I would have had an easier go at it if I did.  I use GCC, OpenOCD, and Eclipse CDT.  I programmed the SPIFI via OpenOCD (feature only in their git repo) and my code running from SRAM downloading the program payload via UART programming SPIFI via the library.

The most reliable way I could get things booting from SPIFI was to immediately copy my text section to internal SRAM after boot, right in the reset ISR before main().  For the SPIFI test, I left the benchmarked code linked in 0x14000000 range, not copied to SRAM. I verified my PC was in that range with the debugger while running the test.  The only ISR enabled was the systick. So that, the vector table, and all library code that the benchmarked code might call into was in SRAM, possibly giving it a leg up against the SDRAM test numbers which had ALL text in the SDRAM, including the ISRs and vector table. 

The code was compiled with GCC 4.5.2, as an M3, with no optimizations and with "long jumps" enabled.  Again, I was testing/comparing code memory throughput and I figured this would be worst case for that... and those also happened to be the settings when I finally got it all working :)  Anyway, at this stage I was not interested in getting the most out of a part, I just want to pick the right part. Or really just avoid the wrong one.  My part will have internal flash.  I won't say my results are 100% scientific, but it did provide a good "smell test".

And I want to be clear that I am not knocking the SPIFI, it is a really unique peripheral.  I will appreciate the direct memory mapping.  I am sure there are applications that would not be dramatically effected by running from it, it just falls way short of my performance expectations. YMMV. And I am sure I don't have it setup for max performance.  I am also sure changing the settings wont yield an exponential performance improvement that I need/expect for my app.  The 60% figure that bavarian quoted is believable (and best case??), but I think that the 25% I saw is also believable given the math of a 4 bit interface feeding a 32 bit processor at identical clock rates.  Its actually pretty impressive when you look at it like that.  Its too bad they don't make DDR QSPI flash devices that we could run at 4x the Cortex frequency! :)

My only real gripe is the vague documentation and the closed source binary SPIFI library... and hopefully neither of those persist.

Thanks again for your responses,
MD

[lpcware]

Content originally posted in LPCWare by noahk on Wed Oct 31 12:42:02 MST 2012
Hi MD,

I'm sorry to hear that the SPIFI is not working out for you.

A few follow up comments:
1.
There are 2 memory ranges for SPIFI on the LPC4350:
0x14000000 - faster and smaller range
0x80000000 - slower and larger range
Both ranges start at address 0 of the SPI Flash, so the bottom of the SPI FLASH can be accessed through either range. The lower range is faster.
You should run your code out of the lower memory range. Be sure to compile and link it for that range. If the flash programming algorithm tool only allows for the higher range, then let me
know. Although you should be able to change the base and size in Keil's flash algorithm window (if that is the IDE you are using).

2.
Move all ISRs to SRAM. Any ISR in SPIFI memory is likely to cause performance degradation.

The SPIFI has been optimized to provide very high speed execution when configured properly.

If you could send me your testcode for the MCB4350 I can look into why it isn't running as fast as it could.

Noah

[lpcware]

Content originally posted in LPCWare by mdittrich on Wed Oct 31 09:56:52 MST 2012
Thanks for the reply Noah,

I broke out the dev board again and verified that pins 2, 3, 5, 6, and 7 of the QSPI device are all toggling at 48MHz.  This is with no calls to the spifi library, only clocking changes, no pin changes (unless the CGU library is doing something).  So I think the boot rom is properly identifying the QSPI device and setting it to "quad" mode. 

But the good news is that my test code is now running at 544us from SPIFI, which is quite a bit better than before (~690us).  and no, I don't know or care about what changed :) ...your mileage may vary :)

And the *best* news is that I got it running on a 4357, which runs it at 112 us at 48MHz from flash (88us from SRAM), and 38 us at 204 MHz (25 us from SRAM).  These 204MHz numbers represent the performance bump I was hoping for by switching to this family, I don't believe even 4x these are obtainable via SPIFI (or 32bit SDRAM) in any configuration, for my test case at least.  I am not going to pursue optimizing SPIFI for code storage, and just use it for ROM data (might not even need to keep it at all).  And I'll also remind myself to not get excited when the next generation of flashless LPC's come out before the flash version is available. :)

Thanks again,
MD

[lpcware]

Content originally posted in LPCWare by noahk on Mon Oct 29 18:46:51 MST 2012
It still sounds like the SPIFI is running in serial mode. It would be very helpful if you could check with a scope what is happening?

If the SPIFI is running in serial mode, the SPIFI will need to be re-initialized. There are examples for how to build a project with the SPIFI library in SRAM in order to re-initialize the SPIFI. That will need to be done.

Here is the link for the LPC 43xx peripheral library which contains the examples referred in an earlier post in this thread: http://lpcware.com/content/nxpfile/lpc4350apdlzip
There is example code in this zip file for speeding up the SPIFI: lpc43xx\Examples\BOOTFAST
Refer to the "SPIFI Flash" target from within the Gpio_LedBlinky project.

Note the use of a special .sct (linker description) file for placing the SPIFI library and other files in SRAM.
I believe those options can be done directly through Keil by right clicking one at a time on the these files:
lpc43xx_gpio.c
lpc43xx_scu.c
lpc43xx_cgu.c
lpc43xx_emc.c
Hitex_Fast_Startup.c
spifi_drv_M4.lib
and selecting IRAM2 for Code / Const, Zero Initialized Data, and Other Data. I believe if you do this you shouldn't need to use a modified scatter gather file.

The spifi_init needs the options parameter to include S_RCVCLK (0x80) and S_FULLCLK (0x40) to use a high speed input clock. 60 MHz is working without those options, but to reach 80 or 100 MHz, you must have those options. The example above already includes those options.

Let me know how this works out.

If the SPIFI is still in serial mode after this, then the SPIFI library is unable to recognize the chip you are using. Let me know if that happens.

Noah

[lpcware]

Content originally posted in LPCWare by mdittrich on Fri Oct 26 09:36:55 MST 2012
I believe I was running 204MHz core, 102MHz SDRAM, and 51MHz SPIFI when I first saw issues with my hex file download, again this was on a 4350, specifically a Keil MCB4350 board.  The quad spi part installed is a 80MHz part, I don't have the board with me to confirm but the schematic http://www.keil.com/mcb4300/mcb4300v1-schematics.pdf shows a S25FL032P0XMFI01.  I believe a once-upon-a-time version of the user manual stated 80MHz as a max for the SPIFI.

The point of my benchmarking was not to optimize the performance of SPIFI, but to gauge its performance relative to other code memories.

The above tests were run at 48MHz, only because I could run all the buses at that speed (SDRAM EMC setup used values acceptable at 120MHz, so ti did not get an unfair advantage at the slow clock rate), and I was tired of "bricking" (immediate hard faults, inconsistent reset behavior, etc) my board when I tried to get SPIFI to run as fast as it could. In general, SPIFI has been pretty frustrating to work with, the user manual could be alot more specific about what is going on.  Specifically about running from SPIFI.  I had this constant feeling that the boot ROM was conspiring against me! :)

The run time was 523 us with a 60MHz SPIFI clock... I never successfully ran it any faster than that.  So assuming things scale linearly, and I do not know that they do, 120Mhz/262us is still unacceptable for me.  Even 130us at a hypothetical 240MHz would be no good. 

I verified the clock rates with a scope, but I didn't verify it was in quad, dual, or single SPI mode with the scope.  Are these the "high speed modes" you are referring to? My setup code just changed the clocking, no more.  I could crash the board in various ways by playing around any more than that. :)

I would love to hear I am doing something wrong and its possible to uncork the performance!  But the user manual's section for SPIFI basically says "pick one of these parts and wire it to these pins" and not much else.

Thanks,
MD

[lpcware]

Content originally posted in LPCWare by noahk on Fri Oct 26 00:31:56 MST 2012
Hi MD,

The SPIFI is going to reach the highest performance when you configure it for high speed mode? The results you are seeing indicate that it is running at the slowest speed. Can you share how you configured the device? How did you set the SPIFI clock?

Are you using a Quad SPI Flash? Which one?

Noah

[lpcware]

Content originally posted in LPCWare by mdittrich on Thu Oct 25 12:37:16 MST 2012
Hi James,

Overflows while downloading hex file at 115200 was also my first indication that running from SPIFI less performant than I anticipated, this was on a 4350.  The code ran fine from internal SRAM (and SDRAM), but could not keep up when running from SPIFI.

I did a crude clock-for-clock benchmark using a chunk of control code from my existing application: running it out of internal SRAM, 32bit SDRAM, and SPIFI on the 4350, and also internal FLASH on a 1768.  Core clock equaled bus clock for the external memory tests, data sections located in internal SRAM in all tests, with identical compiler options (compiled as M3). The results:

FLASH:  87us
SRAM : 110us
SDRAM: 400us
SPIFI: 696us

I think FLASH beat SRAM because I didn't bother moving the data sections to a different internal SRAM/bus than the text.  This 'test load' code was the same on the 1768 and 4350, but it might not be a scientific comparison since the surrounding code (and devices!) is obviously different.  Regardless, SPIFI is the clear loser, for my application at least.  I did other tests using different clocking schemes on the 4350 and run times were pretty much linear to clock rate.  So, running from SPIFI is unacceptable for my application, and I am getting some 4357's populated to see if the 18xx/43xx family is comparable to the 1768.

The SPIFI is certainly a neat peripheral, I have no doubt it could hit 60% for some benchmark loads, but it will be relegated to "ROM" data in my app.

Thanks,
MD

[lpcware]

Content originally posted in LPCWare by bavarian on Thu Oct 25 05:08:32 MST 2012
Hello James,

the performance of the SPIFI on the LPC18xx compared to the performance of the internal flash on the LPC1788 shouldn't be so far away from each other.
When we benchmark the internal flash of the LPC1857 (=100%) with the SPIFI we see about 60% performance.
The question is now which code you used. Coming out of SPIFI bootmode the interface runs most likely on 32MHz. It can run faster if you apply the right settings.
There is example code on the lpcware web which sets the SPIFI to higher speed (Examples --> SPIFI)

Additional not: if you load your system with a lot of interrupts it might be useful to move the interrupt vector table and the ISRs into internal SRAM.

Best regards,
NXP Technical Support Team