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


Groups > comp.arch.embedded > #28716

External SPI Flash for storing data

From pozz <pozzugno@gmail.com>
Newsgroups comp.arch.embedded
Subject External SPI Flash for storing data
Date 2019-07-01 00:15 +0200
Organization A noiseless patient Spider
Message-ID <qfbc9f$vrd$1@dont-email.me> (permalink)

Show all headers | View raw


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.

Back to comp.arch.embedded | Previous | Next — 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