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.
