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

Groups > comp.arch.embedded > #28732

Re: External SPI Flash for storing data

Show all headers | View raw

Den 2019-07-01 kl. 00:15, skrev pozz:
> 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.

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

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