Forums

External SPI Flash for storing data

Started by pozz February 13, 2020
Maybe someone remember the thread[1] that I created some months ago. I 
was searching a simple way to save on the external SPI Flash some 
constant data (mainly bitmaps) and copying them to SDRAM at startup.

I finally put my hands on that project again and I think I've found a 
good solution.

The MCU (LPC1785 from NXP) has an internal Flash memory starting from 
0x0000 0000 and an external SDRAM starting at 0xA000 0000. The first 
region of SDRAM is dedicated to framebuffer.
0xA008 0000 is the starting address to copy bitmaps from SPI Flash.

I'm using MCUXpresso IDE and I created a new *Flash* memory region 
starting from 0xA008 0000. Yes, I created a Flash region, even if it is 
RAM. Why?
In this way, the linker automatically[2] put all the bitmaps in SDRAM. 
The USB bootloader knows that data starting from 0xA008 0000 must be 
saved in external SPI Flash. At startup the application copies from SPI 
Flash to SDRAM at the correct address and the application runs without 
problems.

So the debug workflow is very simple. If the bitmaps aren't changed, I 
can start the debug session without any problem. I don't know what 
really happens, because the internal Flash is normally written by 
J-Link, while SPI Flash is ignored. I was worried J-Link or IDE emitted 
some errors about a non existent Flash at 0xA008 0000 that couldn't be 
programmed.

If the bitmaps are changed, I use objcopy to extract bitmaps from 0xA008 
0000 and generate hex file to use with the USB bootloader. After 
programming via bootloader, I can start the debug session normally.

It's ok, but maybe it can be improved. How to instruct IDE or J-Link to 
write data to SDRAM at every debug session startup? SDRAM is mapped 
normally, so the programmer should be able to write to it without any 
problem.
In this way I could avoid USB bootloader for debugging.




[1] 
https://groups.google.com/forum/#!topicsearchin/comp.arch.embedded/authorname$3Apozz/comp.arch.embedded/9eohsI0Myrw

[2] It isn't really automatic. I used gcc attribute to specifiy the 
section of bitmaps. But this is very simple in MCUXpresso.
Il 13/02/2020 12:58, pozz ha scritto:
> Maybe someone remember the thread[1] that I created some months ago. I > was searching a simple way to save on the external SPI Flash some > constant data (mainly bitmaps) and copying them to SDRAM at startup. > > I finally put my hands on that project again and I think I've found a > good solution. > > The MCU (LPC1785 from NXP) has an internal Flash memory starting from > 0x0000 0000 and an external SDRAM starting at 0xA000 0000. The first > region of SDRAM is dedicated to framebuffer. > 0xA008 0000 is the starting address to copy bitmaps from SPI Flash. > > I'm using MCUXpresso IDE and I created a new *Flash* memory region > starting from 0xA008 0000. Yes, I created a Flash region, even if it is > RAM. Why? > In this way, the linker automatically[2] put all the bitmaps in SDRAM. > The USB bootloader knows that data starting from 0xA008 0000 must be > saved in external SPI Flash. At startup the application copies from SPI > Flash to SDRAM at the correct address and the application runs without > problems. > > So the debug workflow is very simple. If the bitmaps aren't changed, I > can start the debug session without any problem. I don't know what > really happens, because the internal Flash is normally written by > J-Link, while SPI Flash is ignored. I was worried J-Link or IDE emitted > some errors about a non existent Flash at 0xA008 0000 that couldn't be > programmed.
Effectively some messages are emitted on LinkServer Console (Verify failed), but luckily the debug session goes on.
> If the bitmaps are changed, I use objcopy to extract bitmaps from 0xA008 > 0000 and generate hex file to use with the USB bootloader. After > programming via bootloader, I can start the debug session normally. > > It's ok, but maybe it can be improved. How to instruct IDE or J-Link to > write data to SDRAM at every debug session startup? SDRAM is mapped > normally,
This is not correct. SDRAM is not configured at reset, so it's impossible to write it.
> so the programmer should be able to write to it without any > problem. > In this way I could avoid USB bootloader for debugging.
I think I have to write a driver that MCUXpresso will use at debug session startup. There are many binary driver for typical configurations (mainly SPIFI), maybe SDRAM is not so typical and must be written ad-hoc.
Den 2020-02-13 kl. 13:23, skrev pozz:
> Il 13/02/2020 12:58, pozz ha scritto: >> Maybe someone remember the thread[1] that I created some months ago. I >> was searching a simple way to save on the external SPI Flash some >> constant data (mainly bitmaps) and copying them to SDRAM at startup. >> >> I finally put my hands on that project again and I think I've found a >> good solution. >> >> The MCU (LPC1785 from NXP) has an internal Flash memory starting from >> 0x0000 0000 and an external SDRAM starting at 0xA000 0000. The first >> region of SDRAM is dedicated to framebuffer. >> 0xA008 0000 is the starting address to copy bitmaps from SPI Flash. >> >> I'm using MCUXpresso IDE and I created a new *Flash* memory region >> starting from 0xA008 0000. Yes, I created a Flash region, even if it >> is RAM. Why? >> In this way, the linker automatically[2] put all the bitmaps in SDRAM. >> The USB bootloader knows that data starting from 0xA008 0000 must be >> saved in external SPI Flash. At startup the application copies from >> SPI Flash to SDRAM at the correct address and the application runs >> without problems. >> >> So the debug workflow is very simple. If the bitmaps aren't changed, I >> can start the debug session without any problem. I don't know what >> really happens, because the internal Flash is normally written by >> J-Link, while SPI Flash is ignored. I was worried J-Link or IDE >> emitted some errors about a non existent Flash at 0xA008 0000 that >> couldn't be programmed. > > Effectively some messages are emitted on LinkServer Console (Verify > failed), but luckily the debug session goes on. > > >> If the bitmaps are changed, I use objcopy to extract bitmaps from >> 0xA008 0000 and generate hex file to use with the USB bootloader. >> After programming via bootloader, I can start the debug session normally. >> >> It's ok, but maybe it can be improved. How to instruct IDE or J-Link >> to write data to SDRAM at every debug session startup? SDRAM is mapped >> normally, > > This is not correct. SDRAM is not configured at reset, so it's > impossible to write it. > > >> so the programmer should be able to write to it without any problem. >> In this way I could avoid USB bootloader for debugging. > > I think I have to write a driver that MCUXpresso will use at debug > session startup. > There are many binary driver for typical configurations (mainly SPIFI), > maybe SDRAM is not so typical and must be written ad-hoc. >
I am doing exactly what You are doing, but I am using the IAR EWARM and have applications running in external SRAM. When you start a debugging session with the EWARM, it will download an application (flashloader) which is linked to internal SRAM. The debugger will communicate with the flashloader, which does the actual programming. The source code of the flashloader is parts of the EWARM installation, so I simply rewrote the flashloader to accept addresses in SRAM. EWARM allows the flashloader to accept parameters, so I could have the flashloader write the application to SPI Flash as well. Best Regards AP
Il 05/03/2020 19:05, A.P.Richelieu ha scritto:
> Den 2020-02-13 kl. 13:23, skrev pozz: >> Il 13/02/2020 12:58, pozz ha scritto: >>> Maybe someone remember the thread[1] that I created some months ago. >>> I was searching a simple way to save on the external SPI Flash some >>> constant data (mainly bitmaps) and copying them to SDRAM at startup. >>> >>> I finally put my hands on that project again and I think I've found a >>> good solution. >>> >>> The MCU (LPC1785 from NXP) has an internal Flash memory starting from >>> 0x0000 0000 and an external SDRAM starting at 0xA000 0000. The first >>> region of SDRAM is dedicated to framebuffer. >>> 0xA008 0000 is the starting address to copy bitmaps from SPI Flash. >>> >>> I'm using MCUXpresso IDE and I created a new *Flash* memory region >>> starting from 0xA008 0000. Yes, I created a Flash region, even if it >>> is RAM. Why? >>> In this way, the linker automatically[2] put all the bitmaps in >>> SDRAM. The USB bootloader knows that data starting from 0xA008 0000 >>> must be saved in external SPI Flash. At startup the application >>> copies from SPI Flash to SDRAM at the correct address and the >>> application runs without problems. >>> >>> So the debug workflow is very simple. If the bitmaps aren't changed, >>> I can start the debug session without any problem. I don't know what >>> really happens, because the internal Flash is normally written by >>> J-Link, while SPI Flash is ignored. I was worried J-Link or IDE >>> emitted some errors about a non existent Flash at 0xA008 0000 that >>> couldn't be programmed. >> >> Effectively some messages are emitted on LinkServer Console (Verify >> failed), but luckily the debug session goes on. >> >> >>> If the bitmaps are changed, I use objcopy to extract bitmaps from >>> 0xA008 0000 and generate hex file to use with the USB bootloader. >>> After programming via bootloader, I can start the debug session >>> normally. >>> >>> It's ok, but maybe it can be improved. How to instruct IDE or J-Link >>> to write data to SDRAM at every debug session startup? SDRAM is >>> mapped normally, >> >> This is not correct. SDRAM is not configured at reset, so it's >> impossible to write it. >> >> >>> so the programmer should be able to write to it without any problem. >>> In this way I could avoid USB bootloader for debugging. >> >> I think I have to write a driver that MCUXpresso will use at debug >> session startup. >> There are many binary driver for typical configurations (mainly >> SPIFI), maybe SDRAM is not so typical and must be written ad-hoc. >> > > I am doing exactly what You are doing, but I am using the IAR EWARM > and have applications running in external SRAM. > > When you start a debugging session with the EWARM, > it will download an application (flashloader) which is linked to > internal SRAM. > > The debugger will communicate with the flashloader, which does the > actual programming. > The source code of the flashloader is parts of the EWARM installation, > so I simply rewrote the flashloader to accept addresses in SRAM. > > EWARM allows the flashloader to accept parameters, so I could > have the flashloader write the application to SPI Flash as well.
I think MCUXpresso has a very similar mechanism and comes with a few flashloaders with source code. Howevere the docs aren't very clear and I wanted a faster solution. It's very strange NXP (and IAR) doesn't distribute a "flashloader" for external RAM. Anyway thanks for the hints.