Slow rise time on SD_CLK causes boot failure
Hello everyone,
I would like to consult on an issue I’m having with the SD_CLK signal of my board. The board is a UPnP music server / router and it boots from an SD Card to load the Uboot, Linux Kernel, and Linux user space. There are already several boards manufactured. There is one board that fail to boot from the SD Card outright and one board that initially worked fine but failed at a later time. The rest of the boards worked fine, but it is concerning that a failure might also happen in the future.
Considering all is same (hardware / binary image loaded), there is a significant delay in the rise up time on SD_CLK signal of the failing board.
What I have done so far
1. Replace R72 with 0Ohm – made the rise up time worse
2. Raise the EVDD by 0.1v to 0.2v – the board booted from the SD Card
Can you point me to the direction on how to properly determine the cause of this error?
Kind regards,
Carlos
SDHC schematic is the reference design (LS1043A-RDB)
SD/SDHC/SDCX Interface schematic is our board (Note: U15 and U16 are no longer populated)
Oscilloscope image of Hantek DSO4254C the SD_CLK waveform of the failing board (in blue)
Oscilloscope image of DS1102 is the SD_CLK waveform of the passing board
@techielew@abhishek awasthi @Navadeep @Umesh Lokhande @Priyanka Singh
11 Replies
Hi @brotherjoons !
- The usage of R72 is as a dampening resistor to avoid refection of signals in this fairly high frequency clock signal. So this is required and healthy to maintain the same.
- Looking at the abruptness from your scope image, it seems something to do with the component pin itself (also you say its with only one of such boards). An ESD event could be a suspect. If it had looked like an exponential curve, then the RC(impedance) of the line is something to look after.
- I don't have an exact reasoning as to how raising EVDD fixed the issue. SPI isn't open drain unlike I2C and pullup resistors are not compulsory but recommended (this is of push-pull type) to double confirm deterministic state. I have a gut feeling that the pull-up on the clock line is playing a role in that lag. Unpopulate R65 (10K) and give a try.
Thank you for the insights @Navadeep
@brotherjoons Great. Also do share what happens in this debugging process - I'm curious now to know how it goes.
Hello @Navadeep , the removal of R65(10K) has little effect on the rise time of the SD_CLK signal. We were considering the cases as chip failures. We are replacing the chips then retest. Thanks
Good to know that - thanks Carlos!
I'd be interested to hear if @Priyanka Singh and @abhishek awasthi have any feedback on this
i would not be able to pinpoint the specific issue .. it may be around parasitic capacitance in the pcb which may be causing the lag in clk ... but again if thats the case it should be repetitive in nature .... what do you think @ShreeshaN ... any insights for this issue ? ...
@brotherjoons In many cases SD_CLK pin is not pulled high in SDIO interface, but different vendors provide different reference designs, so the best option is to refer ventor reference designs or working open source designs if available
I am not sure of the hardware dependencies, but from a software perspective do you have debug access? When the boot up is delayed can you track the program counter to the binary map and check where exactly the halt happens?
true that. I was as as well wondering why that clock pull-up exists in push-pull control type.
Hi @abhishek awasthi @ShreeshaN @Navadeep @Priyanka Singh - thank you for sharing your insights.
The reference design (SDHC schematic from the initial post, which is from LS1043A-RDB) also has the 10k R pull up on the SD_CLK line.
There's currently logistics issue (I have the debugger tool but the actual failing board is halfway across the globe) and the board on my possession doesn't exhibit the behavior.
We are currently ruling them as chip issue / isolated mfg issue but I will surely let everyone know how it goes.