Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28721

Re: External SPI Flash for storing data

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-01 00:15 +0200
  Re: External SPI Flash for storing data Dave Nadler <drn@nadler.com> - 2019-06-30 18:17 -0700
    Re: External SPI Flash for storing data Rick C <gnuarm.deletethisbit@gmail.com> - 2019-06-30 20:18 -0700
      Re: External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-01 08:46 +0200
        Re: External SPI Flash for storing data Rick C <gnuarm.deletethisbit@gmail.com> - 2019-07-01 16:36 -0700
  Re: External SPI Flash for storing data Richard Damon <Richard@Damon-Family.org> - 2019-06-30 23:46 -0400
    Re: External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-01 09:35 +0200
      Re: External SPI Flash for storing data raimond.dragomir@gmail.com - 2019-07-01 01:42 -0700
        Re: External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-02 00:06 +0200
          Re: External SPI Flash for storing data raimond.dragomir@gmail.com - 2019-07-01 21:35 -0700
            Re: External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-02 09:35 +0200
              Re: External SPI Flash for storing data raimond.dragomir@gmail.com - 2019-07-02 01:31 -0700
                Re: External SPI Flash for storing data pozz <pozzugno@gmail.com> - 2019-07-02 10:58 +0200
                Re: External SPI Flash for storing data raimond.dragomir@gmail.com - 2019-07-02 02:58 -0700
      Re: External SPI Flash for storing data Richard Damon <Richard@Damon-Family.org> - 2019-07-01 07:44 -0400
  Re: External SPI Flash for storing data "A.P. Richelieu" <aprichelieu@gmail.com> - 2019-07-03 17:38 +0200

csiph-web