LPC546xx external RAM/Flash internal RAM/Flash, linkscripts and MCUXpresso project settings

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC546xx external RAM/Flash internal RAM/Flash, linkscripts and MCUXpresso project settings

906 Views
A_M
Contributor III

I have a big project with LPC54608, so that, SPIFI Flash and external SDRAM must be connected to the LPC54608.

By reading the forum posts and MCUXpressu UM, I managed to get parts of my project stored in the external flash, but the internal flash still gets too much load. Utilization over 100%.

This is the output of my project.

Memory region Used Size Region Size %age Used
PROGRAM_FLASH: 598048 B 512 KB 114.07%
BOARD_FLASH: 2766904 B 16 MB 16.49%
SRAM_UPPER: 144836 B 160 KB 88.40%
SRAMX: 0 GB 32 KB 0.00%
USB_RAM: 0 GB 8 KB 0.00%
BOARD_SDRAM: 587944 B 16 MB 3.50%

(It the current project will not work because the SPIFI is not configured).

I am primarily interested in the information how to configure one project or if two projects have to be created.

The functions __RAMFUNC() or __TEXT() should not be used.

Can a MCUXpresso project be configured so that startup_lpc54628.c, SystemInit(), all interrupts (ADC, Timer, DMA etc) and some functions are stored in the internal SRAM and Flasch? But the main function and others are stored in the external flash but executed in the external RAM?

Labels (2)
0 Kudos
4 Replies

610 Views
Kiran_Kumar_K_R
Contributor I

I am facing problem to read the data which is moved from Flash to External SD_RAM,the data is getting corrupted.Other data which is stored in SD_RAM is not having this issues.

Can anyone help?

 

0 Kudos

894 Views
frank_m
Senior Contributor III

> Can a MCUXpresso project be configured so that startup_lpc54628.c, SystemInit(), all interrupts (ADC, Timer, DMA etc) and some functions are stored in the internal SRAM and Flasch?

You cannot have anything stored in RAM, be it internal or external.

All code to be executed from RAM ( __RAMFUNC()) must be stored in Flash, and loaded at runtime.

>... but the internal flash still gets too much load. Utilization over 100%.

You will need to convince the linker to put code into the BOARD_FLASH section, usually by adding an appropriate compiler pragma to the respective source file.

I did not try this on a LPC54xxx with MCUXpresso, only with other MCUs and other toolchains. And controlling linker assignment via compiler is highly toolchain specific.

However, I would confirm first if code can be executed from external Flash and external RAM. The latter will not work AFAIK.

 

0 Kudos

886 Views
A_M
Contributor III

Yes I know. That was expressed wrong...
What I mean is that the mentioned functions(startup, irqs...) are stored in the internal flash and executed from there using the internal RAM.
The main function and all others should be stored in the external flash and copied to the external ram at runtime and executed from there.

Can a MCUXpresso be configured like this?
I have already managed to place parts of the code from a project folder "flash2" in the external flash. But not the main().

0 Kudos

884 Views
frank_m
Senior Contributor III

I would think about it twice, at least for a private project. Choosing another controller (perhaps a Cortex A) would be an alternative.

You need the management routines to swap the Flash content into RAM, this does not happen by itself. And for the most part, the linker needs to create code built for those RAM addresses, not the Flash they are stored in. Not sure if the MCUXpresso toolchain supports that, but it is still not trivial. But for this reason, the startup routines (which are quite small anyway) must reside in Flash.

And keep in mind that any RAM used for code execution is not available for data storage. Check the memory map if all RAM sections are consecutive, and even connected to the I-bus. External SDRAM is, AFAIK, 16-bit access only, and no code execution.

For internal Flash, there is usually no speed penalty. Most Cortex M use 64 or 128 bit wide fetch access, to eliminate wait-time related performance issues. 

0 Kudos