Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 19 Dec 2007 09:42 AM by  davek
PCMCIA Bus Timing Problem
 6 Replies
Sort:
You are not authorized to post a reply.
Author Messages
davek
New Member
New Member
Posts:


--
13 Sep 2007 12:43 PM
    Has anyone experienced timing problems on the PCMCIA bus? I'm using a Compact Flash ethernet card, and it seems that the output enable from the MX31 is turning off before the MX31 samples the data bus, due to delays in the buffering. Has anyone else seen this problem? It seems to be violating the timing requirements of the MX31.
    kurtl@logicpd.com
    New Member
    New Member
    Posts:


    --
    13 Sep 2007 02:57 PM
    Hi davek,
    I'd like to investigate your situation. Which signal are you referring to by the "output enable" from the MX31? The PCC_nCE1/2A signals? or the PCC_nDRV signal?

    How are you accessing the interface? JTAG, Lolo, winCE, Linux, custom, etc?
    davek
    New Member
    New Member
    Posts:


    --
    17 Sep 2007 10:09 AM
    Hi Kurt,

    I'm using Linux to access the PCMCIA socket. The device is a WiFi card based on the Marvel 8385 chipset. The problem:

    - PCMCIA driver seems to work fine
    - CF Flash Memory worked fine
    - the WiFi module seemed to return only 0xFF to tuple read accesses

    Upon closer inspection:

    - CF flash card (which was included in the litekit) did not tristate it's output when the PCMCIA OEn signal was deasserted (high), which allows sufficient hold time for the MX31 to capture the data on the bus

    - the WiFi chipset, properly stops driving data when the OEn is deasserted, HOWEVER, due to delay in the 74ALVC164245 buffer U7, it seems that there is insufficient hold time at the MX31's input, so the CPU latches 0xFF for all read transactions.

    As a hack around this:
    - I've lifted the OEn pin on the CF socket, and tied it to the CE1n pin on the socket. This essentially widens the OEn window, which gives sufficient hold time to the data for the MX31. The MX31 manual is unclear about EXACTLY when the data is latched, but it appears to be at the end of this PSL (strobe) phase.

    I'm programming the MX31 with the following PCMCIA timings for now:
    PSST = 63
    PSL = 128
    PSHT = 63

    Thanks,
    Dave
    davek
    New Member
    New Member
    Posts:


    --
    11 Oct 2007 09:44 AM
    Hi,

    Has anyone done any research into this problem? I'm still convinced that it's a timing problem with the PCMCIA interface on the LiteKit/SOM. Looking at the data timing, and even the data on the uP_D bus on the baseboard, it looks like the data is getting through, but the MX31 is simply latching all 0xFF's. Any help would be greatly appreciated.

    Thanks,
    Dave
    davek
    New Member
    New Member
    Posts:


    --
    12 Oct 2007 01:23 PM
    For all those interested. There is a problem with the MX31 PCMCIA timing. I've been working with FAEs from Freescale, and the operation of the PCMCIA is different than the MX31 manual suggests. The manual shows data being sampled at the end of PSL, however, here's what the Freescale FAE said:

    "The answer is that the data is sampled only after PSHT. However there should not be any problem with data going high Z since our IO have keepers on all data pads. In the block guide we suggest to put on the board transceivers on the data bus, so you should not get the 0xFF on your data pads"

    The PCMCIA device I'm using drives the bus high SLIGHTLY before going High Z, so the MX31 samples only 0xFF.

    Just thought I'd share for other people that might be having the same problem. The folks at Logic PD might want to take this into consideration for the next spin of the baseboard, to work around the flaw on the MX31 processor.
    Ty
    New Member
    New Member
    Posts:2


    --
    13 Dec 2007 01:33 AM
    Hi Davek,
    I'm very interested in using PCMCIA interface.

    Finaly, did you find any issue to this timing problem?

    I've look the ADS schematics, and signal "direction" used for uP_D bus is not created as the same way than LikeKit board... on ADS it's PC_RW_B inverted, and on LikeKit it's PC_RW_B ORed with RW negated... may be this difference is the cause of this timing problem?
    Thanks,
    davek
    New Member
    New Member
    Posts:


    --
    19 Dec 2007 09:42 AM
    Hi, sorry for the slow reply. The problem is not specifically with the litekit, it's with the mx31 processor itself. You actually need to add 2 flip flops to extend the IORD and OE signals for the bus in order to use certain devices on the bus. If you're interested in that, I can give you more information, but it's kind of a tricky mod.
    You are not authorized to post a reply.