LPC54S018 and the use of BOARD_SDRAM memory area

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

LPC54S018 and the use of BOARD_SDRAM memory area

Jump to solution
416 Views
brian_ungar
Contributor III

I have stored several large uninitialized memory arrays in the BOARD_SDRAM area of my LPC54S018 board by declaring the arrays using the __DATA MACRO (e.g. __DATA(BOARD_SDRAM) CanBuffer_t canBufferPool[MAX_CAN_BUFFERS];). My code was running from serial flash.

To make this work, I looked at the emc_sdram software example in the SDK and I used the information from the example to modify the pin_mux file and to add a call to BOARD_InitSDRAM() in Main(). I also had to modify the ResetISR() code in startup_lpc54s018.c and startup_lpc54s018.cpp to not access any memory location that was in the BOARD_SDRAM memory area. This fix was required because the executable image had a .BSS area for the large arrays and the ResetISR() function was setting the memory for the arrays to zero before access to BOARD_SDRAM could be initialized via a call to BOARD_InitSDRAM() in Main(). With this fix in place, the software loaded and ran.

Any suggestions?

I then tried to move the executable code to the SRAMX memory area. When I did this, the software loading and startup process failed before Main() was started. The debugger appears to break in ResetISR(), but the debugger still thinks that the CPU is running. I I say suspend, then the CPU apears to suspend somewhere in the bootloader.

If I shrink the size of the arrays in BOARD_SDRAM and move them back to the on-chip memory and still make my code run from RAM, the loading and startup process works as expected. Is there somewhere else that access to BOARD_SDRAM could be happening before Main() is invoked?

Note that the difference between my code and what is done in the software example is that I declare arrays while the example only sets up a pointer to the BOARD_SDRAM area after access is initialized. Using the pointer, the example accesses parts of the BOARD_SDRAM memory area. This does not work well if multiple large arrays are being put into BOARD_SDRAM as one has to manually figure out where the arrays would reside.

0 Kudos
1 Solution
392 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @brian_ungar,

First of all, have you tried the named example with success?

Also, could you please take a look at the following similar thread?

There they put the BOARD_InitSDRAM() code line into SystemInitHook() in the system_LPC54S018.c file.

Best regards, Raul.

View solution in original post

0 Kudos
2 Replies
393 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @brian_ungar,

First of all, have you tried the named example with success?

Also, could you please take a look at the following similar thread?

There they put the BOARD_InitSDRAM() code line into SystemInitHook() in the system_LPC54S018.c file.

Best regards, Raul.

0 Kudos
382 Views
brian_ungar
Contributor III

Raul,

The named example works.

I did end up modifying my code to work in a similar fashion to the named example in that I created a pointer to my large data structure in BOARD_SDRAM. The pointer was initialized with a hard coded address after access to the BOARD_SDRAM memory area was initialized. I then proceeded to initialize the large data array. This change worked.

I looked at the thread that you mentioned in your recent reply. I tried the __NOINIT MACRO as stated. This also solved my initial problem. If I have time, I might go back and change my code to use the __NOINIT MACRO. It is a better solution than what I am doing with pointers.

I am going to close this thread as it looks like my problem has been resolved.

Thanks for the help.

Brian Ungar