Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 323 subscribers
  • Views 1338 views
  • Users 0 members are here
Related

SD Card Initialization Failing

mad_dog

We are using an UltraZed-EG SOM with a custom carrier board that includes an SD card and an Ethernet PHY (DP83867IRPAPT). Including the PHY on the SOM, our system has two Ethernet ports. We are experiencing a mysterious problem where the SD card often fails to initialize properly if our carrier board PHY is enabled. If that PHY is held in reset during any SD initialization we see no problems. This does not appear to be a transient power-up issue as we see this problem when the card is initialized at any time after power up as long as the PHY is also enabled. We are trying to uncover any possible links between the SD card and PHY activity but they seem completely separate entities. Does anyone have any ideas on this?

Parents
  • 0

    Hi there,

     

    First are you using both GEM out of the PS?  Or is one loaded in the PL?

    What power solution are you using?

    You are correct that they are separate hardened IP inside the PS.  The only link they really share is the switching MUX that is in side the PS that allows you to configure the IO pins and which hardened IP is enabled.

     

    The only idea I would encourage you to investigate a bit more is the power issue, but if you are highly satisfied that cannot be the issue, I'm not sure what else to offer, except have you contacted your local FAE?

     

    Here are a few guesses, and again, without knowing more, they are guesses based on just the information you have provided, and especially since I've not personally seen more than 1 design in my career where people use dual ethernet.

    • Maybe try to sequence the initialization always initializing the SDCARD then the PHY?  This might help if there is a problem on the PS power rails or maybe the capacitance is not 100% proper for the switching frequency you are using?
    • Are you configuring those elements using a BDF?  If so, where did the base of that BDF start from?  Maybe the ORDER of initialization is causing some internal issue?  Dubious, but I've seen odd things with clocks when using a BDF and clicking things in the "wrong" order.  This was in OLDER versions of Vivado and my SPECIFIC issues were resolved, but I would offer change the BD PS configuration selection order.  End result SHOULD be the same thing, but the output might be different.
    • Does having a cable plugged into the ethernet jack matter?  That is if the PHY is active, does that matter, or is the issue just that it is out of reset.  I'm curious if there is a logic thing going on (a PHY wait state causing something internal to the PS not being happy until that is released)
    • Have you tried different SDCARDS?  There are some incompatible cards that are marginal...and some that we've tested as certainly good.  Here is a document related to that: http://zedboard.org/zynqgeek First item "SD Card Advice V2 for Zynq and Zynq UltraScale+ SoC Products"
    • Have you tried NO SDCARD?

     

    I'll pass this by a few people here and see if there are any further thoughts

     

    --Dan

  • 0 in reply to drozwood90

    Hi Dan...Thanks for your reply and questions. I have passed them along to our VHDL and software people and here are their replies:

     

    • Yes, both GEMs out of the PS.
    • I’m not sure at what point this initialization sequencing should take place. We do know that if the phy is held in reset while the SD card is init’d, we don’t have issues.  However, then we release from reset and linux re-init’s the SD card, and we can have issues there.
    • Our BDF was built from a blank design. At some point I started over and re-built it to clean up the design. Both designs had issues and it’s possible I clicked everything in the exact same way both times. We’ve used 2019.1 for everything.
    • We have not seen any issues with the SD card if the PHY is held in reset through its reset input pin or if we do not have a cable connected at the Ethernet jack. 
    • We have done a fair amount of testing on the IOCC (though we will likely do more) and have so far seen no issues with this SD card.

           We’re using a SanDisk card and a Samsung card that have had no issues on a separate Zynq 7000 design nor on the Ultrazed SOM/IOCC combo.

     

    I will also mention another odd observation; we've done testing where the SD card always runs at 400KHz (doesn't ratchet up to 50MHz)) and in that state we get errors in init and in normal SD card operation. For those times when we do get a successful init of the card (this whole issue is sporadic) we can run at 50MHz without issue.

     

    From the hardware perspective, we are using JX3 pins 94 thru 100 for our SD card and pins 69 thru 82 connect to our Ethernet PHY. Is there any chance of crosstalk or inadvertent coupling between these groups of pins in the SOM layout? We don't have access to that or I would look at it myself.

     

    Finally, can you provide some guidance for me on SD card layout for carrier cards? I have read that the routing needs to be length matched (ZUS chip package delay + SOM routing delay + carrier card routing delay) but I am confused about the SD card clock. There is mention made of have a certain amount of skew (50-200pS) between the data/cmd signals and the clk. Can I assume the clock should be delayed to allow setup time for the other signals? I have studied the IOCC layout in detail and there was clearly an effort made to match the lengths and the clk does appear to be slightly shorter. What is the function of the series resistor (R34) in the clk line? Since it cannot be located on the SOM (where I would expect a source terminator to make sense) what is the purpose/effect of that resistor on the IOCC? There is a note on the IOCC schematic about locating this resistor within 100mils. Is the intent to locate it within 100mils of the SD card holder edge which then has another 550 mils or so to reach the SD card clk pin? I'm just not sure what's going on here.

     

    Also, we have definitely sent many questions to our FAE but so far we have not made any progress, hence my posting here. Thanks again for your help. It is much appreciated...Mike

  • 0 in reply to mad_dog

    Hi there,

     

    We really do not have a lot of experience with dual ethernet.  I was looking around the Xilinx forums, and there seems to be quite a few posts on using DUAL ethernet.  You might get a bit more exposure if you post there as well.  If you do get a resolution, please cross post to help others that might see this issue.

     

    I will have to check on the layout.  I do not think there would be issues with cross talk, but I cannot say we have a spec. where we explicitly state to design against crosstalk from certain pairs.  From what I understand, the layout shouldn't incorporate any more crosstalk than any other bus layout as we do have quite a few spec. callouts for lengths and I believe that the pins were done in pairs, then groups.  This should be listed in the UltraZed Carrier Card Design guide.  If you need to see actual screen shots, you should be able to contact your FAE for official access to that information.  The SOM design files are more protected.

     

    For layout guidance, you will want to refer to the above mentioned Carrier Design Guide as well as the Xilinx UG583

    https://www.xilinx.com/support/documentation/user_guides/ug583-ultrascale-pcb-design.pdf

     

    For the Design Guide, head to the UltraZed-EG Product Page:
    UltraZed-EG

    Click on Technical Documents,

    image

    then download the guide

    image

     

    As for specifics to the amount of skew, I'm not sure I can answer that.  You can check the BDF configuration that we provide in our repository, as well as compare against the trace lengths that we have for the UltraZed Carriers + SOM + Package.

     

    I will have to get back to you on the resistor, however, typically the resistor is there to aid in reduction of reflections.  I cannot be positive, but that might be an SDCARD spec. need.  As I mentioned, I'll ask and get back to you on that.

     

    --Dan

Reply
  • 0 in reply to mad_dog

    Hi there,

     

    We really do not have a lot of experience with dual ethernet.  I was looking around the Xilinx forums, and there seems to be quite a few posts on using DUAL ethernet.  You might get a bit more exposure if you post there as well.  If you do get a resolution, please cross post to help others that might see this issue.

     

    I will have to check on the layout.  I do not think there would be issues with cross talk, but I cannot say we have a spec. where we explicitly state to design against crosstalk from certain pairs.  From what I understand, the layout shouldn't incorporate any more crosstalk than any other bus layout as we do have quite a few spec. callouts for lengths and I believe that the pins were done in pairs, then groups.  This should be listed in the UltraZed Carrier Card Design guide.  If you need to see actual screen shots, you should be able to contact your FAE for official access to that information.  The SOM design files are more protected.

     

    For layout guidance, you will want to refer to the above mentioned Carrier Design Guide as well as the Xilinx UG583

    https://www.xilinx.com/support/documentation/user_guides/ug583-ultrascale-pcb-design.pdf

     

    For the Design Guide, head to the UltraZed-EG Product Page:
    UltraZed-EG

    Click on Technical Documents,

    image

    then download the guide

    image

     

    As for specifics to the amount of skew, I'm not sure I can answer that.  You can check the BDF configuration that we provide in our repository, as well as compare against the trace lengths that we have for the UltraZed Carriers + SOM + Package.

     

    I will have to get back to you on the resistor, however, typically the resistor is there to aid in reduction of reflections.  I cannot be positive, but that might be an SDCARD spec. need.  As I mentioned, I'll ask and get back to you on that.

     

    --Dan

Children