LINUXSDK-OMAPL138: c6748 DSP issue with EMIF

Part Number: LINUXSDK-OMAPL138

Hello TI team,

As part of a project, we are interfacing OMAP L138 with another device (operating at 50MHz oscillator frequency) containing Async SRAM and registers. The agenda is to push in and extract the data out of the slave device using OMAP.

Details
===============
The interface used is EMIF, crystal frequency of OMAP is 24MHz, EMIF clock frequency = Default settings. Chip select - CS5, All timing widths in CSnCFG register = 0, Address space = 0x66000000, data width = 16, operating mode = Normal, Wait pol = positive, Address lines in use = A15 to A0, nOE and nWE lines are used, Extend wait - Enable, Core= DSP, Programming = bare metal.

Problems identified so far
===========================

We probed the EMIF Address lines and found that the address is going out from the OMAP as expected. However, data is not received/registered by OMAP. OMAP is always showing the data as zero instead of the expected value.
Hence we monitored the EMIF data lines and found that the slave device is correctly sending the data out to the EMIF data lines and the read time is in the range of 10 to 20 ns.

Why is OMAP not registering the data from the EMIF data lines? Any help is highly appreciated!
Another issue we found is sometimes we are getting two nCS pulses (as shown in figure) instead of one pulse during read process! Any clue on this topic?

  • If the slave device is correctly sending back the data with the correct timing, ensure that you have the pinmux register set correctly for the EMIF interface.  Ensure the CE5CFG is set correctly.  You may want to try to get the reads to work by disabling the wait mode.  Consult section 10.2.5.3 of the TRM for more setup information.  Ensure the read strobe is appropriately placed in the waveform. 

    The two CS pulses may be a result of the size of data that is being requested.  Based on your interface width, two accesses may be necessary to get all of the data requested.

    Regards,

    James