Tool/software: Code Composer Studio
Hi,
We are developing an application for the C6742 DSP which will be interfacing with an external SDRAM via EMIFA. Due to the application source code size we will need to split our code and use this external memory besides from the internal 64KB L2 RAM of the C6742 DSP.
The setting we are testing our code on right now is the C6748 DSP Development Kit. As you know, in this Kit the DSP interfaces an external SDRAM via DDR2, instead of EMIFA. In this setting, we have successfully allocated part of our code to this SDRAM DDR2 external memory and run our application, so we know our code splitting scheme works.
Considering that, we are seeking a way to validate to certain extent the SDRAM EMIFA interface in the final custom board, so as to ensure our code application could be run using external memory resources. The point would be to run a simple code located in internal memory that will read and write from the external memory to test the interface.
As a preliminar example, we have successfully done this for the DDR2 interface simply by accessing the memory mapped addresses of the C6748 DSP (starting on 0xC0000000). The configuration of the DDR2 interface was done by a GEL file I found from texas documentation for this board. I would want to do something similar for the EMIF interface, but right now the only EMIF interface I have available in the Development Kit to try out some tests is NAND EMIF. When I tested this interface with a similar approach I could not read/write the memory mapped NAND EMIFA area (CS3, starting on 0x62000000), since all bits appeared to be 1s. However, I know that the NAND interface works because we have successfully booted from it in previous tests.
The EMIF NAND initialization routine is done in the GEL file by means of a routine that uses functions from the sample GEL file that we know are correct since worked for the DDR2, such as PSC0_LPSC_enable:
device_EMIFNAND_Config()
{
/* Enable the Clock to EMIFA */
PSC0_LPSC_enable(PD0, LPSC_EMIFA);
/* Setup PinMux settings, configure pins: WAIT[0], WE, OE, CS3, D0-15, A1-2 */
PINMUX7 = (PINMUX7 & ~0xF0FF00F0) | 0x10110010;
PINMUX8 = 0x11111111;
PINMUX9 = 0x11111111;
PINMUX12 = (PINMUX12 & ~0x0FF00000) | 0x01100000;
/* Asynchronous 2 Configuration Register: Normal mode, Disable extended wait mode, 16-bit data bus, Maximum time values */
EMIFA_ACFG3 = 0x3FFFFFFD;
/* Set NAND Flash for CS3 */
EMIFA_NANDFCR = 0x00000002;
}
The PINMUX is configured for the pins shown in §18.2.5.6, NAND Flash Mode (C6748 Technical Reference Manual), which match with the pins connected in the Development Kit board between the NAND device and the DSP as shown in the schematics.
The timing configuration is set to its maximum since no constraints are imposed on that respect, and those are the settings used when generating the binary images flashed in NAND to succesfully boot from it in other tests we tried.
Considering this, I have some questions:
Q1) Is it even possible to access memory mapped NAND EMIFA directly, in the same way SDRAM DDR2 can be accessed? If so, am I missing something regarding the NAND EMIFA initialization routine I posted above?
Q2) Could be the case that asynchronous memory devices such as NAND Flash are not accessible in that way, but for a synchronous one like SDRAM EMIFA it could actually be done? If not, would I need to use a different memory accessing method, to low-level test the SDRAM EMIFA interface such as DMA?
Any advise or help would be greatly appreciated.
Thanks in advance,
David
