External SPI Flash for storing data

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.

On Sunday, June 30, 2019 at 6:15:14 PM UTC-4, pozz wrote:
> ... 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...

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???

On Sunday, June 30, 2019 at 9:17:25 PM UTC-4, Dave Nadler wrote:
> On Sunday, June 30, 2019 at 6:15:14 PM UTC-4, pozz wrote:
> > ... 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...
> 
> 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???

"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
  - Tesla referral code - https://ts.la/richard11209

On 6/30/19 6:15 PM, pozz wrote:
> 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.

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.

Il 01/07/2019 05:18, Rick C ha scritto:
> On Sunday, June 30, 2019 at 9:17:25 PM UTC-4, Dave Nadler wrote:
>> On Sunday, June 30, 2019 at 6:15:14 PM UTC-4, pozz wrote:
>>> ... 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...
>>
>> 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???
> 
> "Insted the SDRAM is mapped to the internal
> address space"
> 
> SDRAM, not external Flash...

Yes.

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

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

Il 01/07/2019 05:46, Richard Damon ha scritto:
> On 6/30/19 6:15 PM, pozz wrote:
>> 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.
> 
> 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.

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.


> 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.

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.

> 
> 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.
> 

luni, 1 iulie 2019, 10:35:51 UTC+3, pozz a scris:
> Il 01/07/2019 05:46, Richard Damon ha scritto:
> > On 6/30/19 6:15 PM, pozz wrote:
> >> 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.
> > 
> > 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.
> 
> 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.
> 
> 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> >

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) but this is not the point (although it's much faster). My SDRAM is partitioned 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 application (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. Also loads the big dictionary file from a sd card to the SDRAM area.
The SDRAM partitioning is very simple, without involving the linker: 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 the bitmaps 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 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.
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 constructed at the time the file is loaded from serial flash in SDRAM.

On 7/1/19 3:35 AM, pozz wrote:
> Il 01/07/2019 05:46, Richard Damon ha scritto:
>>
>> 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.
> 
> 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.
> 
> 

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.

>> 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.
> 
> 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.
> 
>

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)

Il 01/07/2019 10:42, raimond.dragomir@gmail.com ha scritto:
> luni, 1 iulie 2019, 10:35:51 UTC+3, pozz a scris:
>> Il 01/07/2019 05:46, Richard Damon ha scritto:
>>> On 6/30/19 6:15 PM, pozz wrote:
>>>> 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.
>>>
>>> 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.
>>
>> 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.
>>
>>
>>> 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.
>>
>> 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.
>>
>>>
>>> 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.
>>>
> 
> 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) but this is not the point (although it's much faster). My SDRAM is partitioned 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 application (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. 

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.


> Also loads the big dictionary file from a sd card to the SDRAM area.
> The SDRAM partitioning is very simple, without involving the linker: 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 the bitmaps 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 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.
> 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 constructed at the time the file is loaded from serial flash in SDRAM.

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

On Monday, July 1, 2019 at 2:46:22 AM UTC-4, pozz wrote:
> Il 01/07/2019 05:18, Rick C ha scritto:
> > On Sunday, June 30, 2019 at 9:17:25 PM UTC-4, Dave Nadler wrote:
> >> On Sunday, June 30, 2019 at 6:15:14 PM UTC-4, pozz wrote:
> >>> ... 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...
> >>
> >> 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???
> > 
> > "Insted the SDRAM is mapped to the internal
> > address space"
> > 
> > SDRAM, not external Flash...
> 
> Yes.
> 
> > The OP's post is too long for me to want to dig into it, but I hope someone else will.
> > 
> 
> I'm sorry for the long post, but the question isn't simple to make 
> without explaining what I really want to do.

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
  + Tesla referral code - https://ts.la/richard11209