• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 315 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

omap l138 sata dma engine startup problem

TFont
Intellectual 270 points

I'm running vxWorks on a custom l138 board design based closely to the LogicPD eval board.  My code and drivers initialize a SATA drive with no problems using the eval board but the same drive and similar code is failing on the custom design.  I suspect a hardware issue on the new design and I'm trying to narrow down the problem.  On the custom board, a link is always established but I'm getting a watchdog timeout on the first FIS send attempt.  I believe the SATA command list DMA engine is not starting.  The one difference I've identified between the two boards is that the P0CMD register on the eval board shows 0x0004C017 after the ST bit is set (CR is set and FR is set) but on the custom design P0CMD show 0x00044017 after the ST bit is set (FR is set but CR is not set).  My question is: what would keep the command list DMA engine from starting?

  • 0
    Intellectual 270 points

    I’ve narrowed my problem down a bit further.  I believe I know why the DMA engine is not starting.   At the time when I’m setting the ST bit in P0CMD, the P0TFD reg is reporting 0x80 which I believe indicates the controller is busy.  This busy state activates as soon as I enable the PHY with a drive connected or, after I enable the PHY as soon as I connect a drive.  The busy state never clears.  My question now is what might be causing the controller to always be busy and is there any way for me to clear the busy state in software?

  • 0 in reply to TFont
    Intellectual 270 points

    Problem solved.

    I've concluded that the P0TFD busy should normally get cleared when the SUD (spin up device) bit is set in P0CMD as a result of the automatic COMRESET initialization.  My issue was that this COMRESET never completed because the receive side differential signal had it's polarity incorrectly wired on the schematic.  Note that this was easily fixed by setting P0PHYCR RXINVPAIR to 1 which inverts the receive polarity.