External SPI Flash for storing data

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I have a board with Cortex-M3 NXP LPC1875 MCU with 512kB internal Flash,  
one 8MB external SDRAM and 2MB external SPI Flash. The external Flash is  
connected to a normal SPI, not SPIFI (in other words, it isn't mapped to  
the internal address space). Insted the SDRAM is mapped to the internal  
address space, starting from address 0xA000 0000.

The application will use a 480x272 RGB LCD connected to the internal LCD  
controller of the MCU. This controller needs a framebuffer for the  
display, so the need of SDRAM.
Moreover the application will use many constant images that can't be  
stored in the small internal Flash.

The idea is to save the images (more generally constant data) to the  
external SPI Flash and copy all of them to external SDRAM at startup,  
that is big enough for everything (framebuffer, constant data and others).
Now I'm trying to arrange a good strategy for the use of external  
Flashin this scenario.

I'm thinking to create the following sections for the linker:
- SPI_FLASH: type=ROM, base address=0xA000 0000, size=2MB
- SDRAM: type=RAM, base address=0xA020 0000, size=6MB

The constant images will be allocated to SPI_FLASH section, so the  
linker will put them directly to the beginning of SDRAM address space.  
The trick of defining the SPI_FLASH section as ROM (really it's RAM  
space) allows the linker to put the constant data directly there (a  
.text read-only section), thinking that it's a non volatile memory  
(otherwise, it would have put constants in the .data section of another  
ROM area).
The copy from external Flash to 0xA000 0000 is a very simple task. After  
this copy, the code could run as usual.

Now the only problem is how to program the internal and external Flash  
starting from the output of the linker. Indeed in the output file the  
constant images are in the SDRAM address space, so if we use the output  
file as is, the images will be lost after the first power down.

My idea is to write a USB bootloader that receives the output file as  
is. The bootloader should know how to read/write to the external Flash  
and know that it is mapped to area 0xA000 0000.
However there are some drawbacks of this approach.

The debug&test process will be slow. I can't use the IDE as usual to  
launch a debug session. If some constant data saved in external Flash  
changs, I need to use the bootloader (and the companion sw on the PC) to  
upgrade the external Flash first. So I need at least two connections  
between developing machine and target: the USB and the debug probe.
However this drawback can be accepted. The project can be compiled in  
mingw platform (i.e., in Windows), so most of the debug will be done in  
Windows PC where the problem of external Flash doesn't apply. The number  
of times I will need to debug&test directly on the target will be small.

The second drawback again relates to debug process. What happens if I  
launch a debug session with an output file that has some initialized  
data in SDRAM address space? I think I would receive an error, because  
the debugger is able to program data in the address space of the  
internal Flash. I'm not sure what happens if it encounters data in the  
external SDRAM address space. Maybe I need to use a Flash driver (as in  
MCUXpresso naming).

I don't know if there are some better approaches.

Re: External SPI Flash for storing data
On Sunday, June 30, 2019 at 6:15:14 PM UTC-4, pozz wrote:
Quoted text here. Click to load it

You posted "the external flash (isn't mapped to the internal address space)
instead its mapped to the internal address space".

Say again? Is it mapped to internal address space or not???

Re: External SPI Flash for storing data
On Sunday, June 30, 2019 at 9:17:25 PM UTC-4, Dave Nadler wrote:
Quoted text here. Click to load it

"Insted the SDRAM is mapped to the internal
address space"  

SDRAM, not external Flash...  

The OP's post is too long for me to want to dig into it, but I hope someone else will.  

--  

  Rick C.

  - Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: External SPI Flash for storing data
Il 01/07/2019 05:18, Rick C ha scritto:
Quoted text here. Click to load it

Yes.


I'm sorry for the long post, but the question isn't simple to make  
without explaining what I really want to do.

Re: External SPI Flash for storing data
On Monday, July 1, 2019 at 2:46:22 AM UTC-4, pozz wrote:
Quoted text here. Click to load it

I wasn't trying to make a statement about your post.  I was saying more about my laziness.  In general it is better to provide too much information than too little.  

--  

  Rick C.

  + Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: External SPI Flash for storing data
On 6/30/19 6:15 PM, pozz wrote:
Quoted text here. Click to load it

I would do it a bit different. I would break the program into two
programs. The first has the SPI Flash image loaded at 0xA000_0000 and
loads a program to write that to the SPI Flash starting at 0xA020_0000
and this is loaded into the machine and run if you need to change the
flash image.

The second program is your normal program which puts the program in the
main internal flash, and begins by down loading the SPI Flash into the
ram at 0xA000_0000.

If you change the SPI Flash Contents, rebuild and run the writer
program, and the run the main program. If you don't change the SPI Flash
contents, you don't need to run that first writer program.

This does say that the SPI Flash is only for constant data that is
specifically generated as such (images and the like) and won't hold
simple data that just happens to be const, but that shouldn't normally
be that big and can stay in the internal program flash and is updated by
the normal main build process.


Re: External SPI Flash for storing data
Il 01/07/2019 05:46, Richard Damon ha scritto:
Quoted text here. Click to load it

Ok, but how to instruct the linker to put images at 0xA000 0000? I know  
I can use sections, however 0xA000 0000 is a RAM section, so the linker  
woud try to put them (images are initialized global variables) in .data  
and .text and copy from .text to .data at startup. It isn't possible in  
my case, because .text is the internal Flash that is too small.

In my original post I proposed a trick to solve this problem: define  
0xA000 0000 as a ROM section, even if it is a real RAM section. In this  
way, the linker should put images directly to 0xA000 0000, without  
worrying to initialize/clear them at startup.

I don't know if NOLOAD attribute of the linker section could be used in  
my case. I think NOLOAD is for *unitialized* variables.


Quoted text here. Click to load it

Should I declare images in normal program too? If yes, where to put  
them? Consider that I need to use instructions such as:

   external const struct Image mystruct;
   draw_image(x0, y0, &mystruct);

So the linker of the normal program should know where is mystruct in SDRAM.

Quoted text here. Click to load it


Re: External SPI Flash for storing data
luni, 1 iulie 2019, 10:35:51 UTC+3, pozz a scris:
Quoted text here. Click to load it
h,
is
to
l
CD
rs).
Quoted text here. Click to load it
r
er
t
to
n
er
l.
n
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
M.
h
y

I have a system very close to yours. LPC4088 with a 800x480 tft lcd. SDRAM  
8 to 32M, 32bit, SPI Flash 4 to 8M. My flash is on SPIFI (4bit interface) b
ut this is not the point (although it's much faster). My SDRAM is partition
ed for the application in three areas. One is the frame buffer, one is the  
bitmap storage (images) and one is for a specific file needed by the applic
ation (a big one up to 20MB) -  a dictionary.
I DO NOT USE the linker for either SDRAM or SPIFI Flash.
The program loads "by hand" the bitmaps from SPI Flash to the SDRAM area. A
lso loads the big dictionary file from a sd card to the SDRAM area.
The SDRAM partitioning is very simple, without involving the linker: the fr
ame buffer which is first (at address 0xA0000000) and fixed in size. Next i
s the bitmap file from the serial flash. The size of the file is self-conta
ined ina small header so it's known. The dictionary loads on top of the bit
maps wherever this address is.
Regarding the bitmap file: This is a single file in a custom format, which  
contains a small header for the size (at least). Every bitmap has also a sm
all header in front of it, also for the size. I construct this big file wit
h my own small C program which takes hundreds of bitmaps from a folder.
A very simple C program in mingw (CodeBlocks).
And last, the application is using the bitmap images based on their index.  
The index table (containing the start addresses in the SDRAM) is constructe
d at the time the file is loaded from serial flash in SDRAM.

Re: External SPI Flash for storing data
Il 01/07/2019 10:42, snipped-for-privacy@gmail.com ha scritto:
Quoted text here. Click to load it

Why? I understood that a SPI Flash connected to SPIFI is mapped directly  
to the internal address space. So the MCU should access images on SPI  
Flash as they are in internal Flash.


Quoted text here. Click to load it

Yes, this is another approach. I will give it a try.


Re: External SPI Flash for storing data
Quoted text here. Click to load it
a.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
That's a long story. My system went through a lot of revisions, starting wi
th LPC2478, then LPC1788 and lastly LPC4088. At first there was only the sd
 card and the bitmaps were loaded from it.
When I switched to LPC4088 I hoped that letting the bitmaps in the SPIFI Fl
ash will be faster than having them in SDRAM based on the fact that the SPI
FI and SDRAM are on different busses.
And it was! And the latest version of the system, indeed, have the bitmaps  
in SPIFI Flash directly.
Unfortunately you cannot use this aproach since you don't use the SPIFI int
erface.

Quoted text here. Click to load it
e frame buffer which is first (at address 0xA0000000) and fixed in size. Ne
xt is the bitmap file from the serial flash. The size of the file is self-c
ontained ina small header so it's known. The dictionary loads on top of the
 bitmaps wherever this address is.
Quoted text here. Click to load it
ich contains a small header for the size (at least). Every bitmap has also  
a small header in front of it, also for the size. I construct this big file
 with my own small C program which takes hundreds of bitmaps from a folder.
Quoted text here. Click to load it
ex. The index table (containing the start addresses in the SDRAM) is constr
ucted at the time the file is loaded from serial flash in SDRAM.
Quoted text here. Click to load it

Since the bitmaps were completely external "objects" I tried to make the fi
rmware as decoupled as possible from them. At least, I really didn't want t
o involve the compiler and linker.

Re: External SPI Flash for storing data
Il 02/07/2019 06:35, snipped-for-privacy@gmail.com ha scritto:
Quoted text here. Click to load it

I rememeber I tried to choose a MCU with LCD controller, 32-bits SDRAM  
interface and SPIFI, however I didn't find anything in QFP package,  
maybe only BGA that we cannot manage.

So are you saying that images in SDRAM, together with framebuffer, will  
be slow? What do you mean with... slow?

Quoted text here. Click to load it

I was thinking about your approach, it's nice because you don't use  
compiler/linker. However I'm using emWin as GUI libraries (you too?) so  
I have to call functions such as:

   GUI_DrawBitmap(&bmp);

where bmp is a pointer to a struct GUI_BITMAP defined by emWin. You said  
you use a home-made "bitmaps compiler" running on the desktop PC to  
generate a "file of bitmaps". How are you sure "bitmaps compiler"  
generates data compatible with emWin running on the target?
Even if you define the *same* struct in "bitmaps compiler", it runs on  
completely different machine and you will have the risk that struct are  
represented in memory with a different layout (I think of integer size,  
padding, alignment, and so on).

One solution is:

   extern const GUI_BITMAP *bmp_convert(unsigned int bitmap_index);
   GUI_DrawBitmap(bmp_convert(BITMAP_BACKGROUND));

bmp_convert() is an helper function that convert the image from "bitmaps  
compiler" format to a "well-defined in target" GUI_BITMAP, returning its  
pointer.

Re: External SPI Flash for storing data
Quoted text here. Click to load it

LPC2478 - QFP208
LPC1788 - QFP208
LPC4088 - QFP208 - has SPIFI

Quoted text here. Click to load it
  
Quoted text here. Click to load it
Good question :-)
Slower for sure. I have some runtime profiling of the time spent to show a  
full screen image. As I said, I really wanted to see if SPIFI bitmaps would
 be faster than SDRAM bitmaps. But don't ask me the figures, don't remember
 such details.
LPC2478 - slow (sdram bitmaps)
LPC1788 - faster (sdram bitmaps but 120MHz cpu and other improvements)
LPC4088 - same as 1788 with sdram bitmaps
LPC4088 - faster with SPIFI bitmaps
LPC4088 with everything in SDRAM (including the code!) - slow! - I wanted t
o see how fast SDRAM execution is but the result is predictable, very impor
tant in this kind of MCU is the parallelism of the internal busses.

The idea is that the LCD bus master uses the SDRAM for the frame buffer qui
te intesively, and the CPU should be updating the same framebuffer. With bi
tmaps in SDRAM, the CPU will access the SDRAM for both read and write. With
 bitmaps in SPIFIFlash the CPU will access the SDRAM only for write.

Quoted text here. Click to load it
the frame buffer which is first (at address 0xA0000000) and fixed in size.  
Next is the bitmap file from the serial flash. The size of the file is self
-contained ina small header so it's known. The dictionary loads on top of t
he bitmaps wherever this address is.
Quoted text here. Click to load it
which contains a small header for the size (at least). Every bitmap has als
o a small header in front of it, also for the size. I construct this big fi
le with my own small C program which takes hundreds of bitmaps from a folde
r.
Quoted text here. Click to load it
ndex. The index table (containing the start addresses in the SDRAM) is cons
tructed at the time the file is loaded from serial flash in SDRAM.
Quoted text here. Click to load it
e firmware as decoupled as possible from them. At least, I really didn't wa
nt to involve the compiler and linker.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

I don't use emWin. I use a personal library that I developed over time. It'
s history started with a mono-chrome one.

Re: External SPI Flash for storing data
Il 02/07/2019 10:31, snipped-for-privacy@gmail.com ha scritto:
Quoted text here. Click to load it

Do you know if LPC4088 is pin-to-pin compatible with LPC1788? I'm using  
QFP208 too, but LPC1785. Maybe LPC4088 is pin-to-pin compatible with  
LPC1785 too.


Quoted text here. Click to load it
   ^^^^^^^
I'm here, with LPC1785 running at 120MHz. I hope your "faster" will be  
good for my application.

Quoted text here. Click to load it

I see.



I see.

Re: External SPI Flash for storing data
mar?i, 2 iulie 2019, 11:58:11 UTC+3, pozz a scris:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
I don't remember, but there are great chances. When I switched to 4088 I wa
s changing some things here and there, especially adding the serial flash.

If you have a 1785 I don't know if 4088 brings something to you, as long as
 you don't use the SPIFI anyway. There are some other improvements of cours
e, like the eeprom, but I don't remember something big.
The SDRAM is still 80MHz max.
I tested two configurations, CPU12%0MHz, SDRAM60%MHz and CPU=SDRAM=
80MHz.
In my system these two configurations worked about the same.
I've chosen the CPU12%0MHz, SDRAM60%MHz.
I have also tested CPU=SDRAM96%Mhz, and it worked very well. In fact, t
he LPC1788 variant is only working at 96MHz, with many units in the field.
Well, the "field" is very friendly room temperature, lets say 15-35 degree  
Celsius...  

Re: External SPI Flash for storing data
On 7/1/19 3:35 AM, pozz wrote:
Quoted text here. Click to load it

Most embedded systems allow you to use a langauge extension to assign a
give variable to a specific 'section' of memory by attribute, with
default sections for all things (.code for the program, .data for normal
variable, .bss for memory to be zero initialized, etc). If you are using
gcc, there is an __attribute__() you can attach to those declarations to
assign them to the special section you create for them. There will also
be a loader configuration script that tells the linker where all these
locations are going to be located in memory, and what types of things
are to be put into them.

Quoted text here. Click to load it


Quoted text here. Click to load it

You will need to have extern declarations for all the variables, and
then, likely in a single file, the actual defintions of them as
uninitialized structures. Note, you can't really declare them 'const' as
the program is going to change them by reading from the SPI Flash at
startup. You likely can get away with having them be marked const in the
header file, but have a flag that removes that const (or casts it away)
for the file that loads the data, but then you technically have invoked
undefined behavior (but it may work)





Re: External SPI Flash for storing data
Den 2019-07-01 kl. 00:15, skrev pozz:
Quoted text here. Click to load it

With an IAR C compiler you can define write your own flashloader.
When you download the code using the debugger, the flashloader
will program the SPI flash.

The linker can generate copy tables which can be used for
copying from the SPI flash to the SDRAM.

The actual copy routine, you have to write yourself.

AP

Site Timeline