For a custom carrierboard, we’ve been looking at the Dahlia schematic. For the SD-card reader, I am puzzled by the schematic around the card detect pins, which looks like this:
In general, the card detect pins (CD1/CD2) are a switch that changes position when a card is inserted. This particular SD-card slot has a normally-closed switch (that opens when the card is inserted), but others are normally-closed.
The software (at least Linux - I’ve read that u-boot ignores CD) expects an active-low CD input (low == card inserted) and enables an internal pullup in the device tree.
It looks like the schematic has sufficient footprints to deal with either normally-open or normally-closed switches - there is a transistor to invert the signal if needed, which can also be bypassed if no inversion is needed.
However, the components that are actually populated (as shown in the schematic, and also look to be the ones on an actual board) make no sense to me. For one, this choice of components completely disables card detection - the transistor is always on so the CD pin is always low making it look like a card is always inserted, which seems problematic (since this causes the VCC pin to be powered on when inserting the SD-card and I think it is safer to power it on only after the card is inserted). Secondly, if an always-present detection is what is wanted, why not populate R351, R353 and R354 and not bother with the transistor?
Can someone comment on the rationale on this design?
The underlying question is of course: Is there a reason to disable CD? If I enable it on my custom board, will things (in particular recovery) not work? Or was there maybe a software issue in the past that is now fixed?
Looking at the Mallow board, I see that has a more straightforward design that just connects the CD switch to GND and the CD pin, with room for an optional pullup (note that the SD slot used has a normally-open switch, unlike the the Dahlia board):
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
The design choice for the SD card detect (CD) circuit in the Dahlia carrier board, as you’ve described, indeed seems to cater to flexibility in handling both normally-open (NO) and normally-closed (NC) SD card detect switches. This flexibility is crucial for accommodating different SD card socket types and ensuring compatibility across various designs and requirements.
The use of a transistor in the circuit serves to invert the signal from the SD card detect switch if necessary. This is particularly useful when dealing with an NC switch, as the SD card interface typically expects an active-low signal to indicate the presence of an SD card. The transistor acts as an inverter, ensuring the system correctly interprets the state of the SD card slot.
The configuration you’ve observed, where the transistor appears to always pull the CD pin low, suggesting a card is always present, might initially seem counterintuitive. However, there could be several reasons behind this design choice:
Simplification of Software Handling: By configuring the hardware to always indicate the presence of an SD card, the software might bypass the need to monitor the CD pin’s state actively. This could simplify the software stack, especially in systems where the SD card is expected to be always inserted during normal operation.
Compatibility and Flexibility: The design might aim to provide a default configuration that works ‘out-of-the-box’ for most scenarios, with the option to modify the circuit for specific use cases. This approach allows for greater flexibility in handling different types of SD card sockets and operational requirements.
Historical or Legacy Reasons: There might have been specific issues or requirements in past versions of the hardware or software that necessitated this design. While these reasons may no longer apply, the design was retained for backward compatibility or to avoid disrupting existing users.
Regarding your concern about powering the VCC pin upon card insertion, the design likely assumes that the risk of damage or other issues is minimal or that the benefits of the chosen configuration outweigh the risks. It’s also possible that the system’s overall design includes additional safeguards or considerations that mitigate these concerns.
If you plan to enable card detection on your custom board, it should generally not cause issues with recovery or normal operation, provided that your software stack is correctly configured to handle the CD pin’s state. Modern Linux kernels and U-Boot versions are quite flexible in terms of hardware configuration, especially with the proper Device Tree settings. If there were software issues related to card detection in the past, they are likely resolved in current versions of the software.
Please, also check if these links can help you solve your problem:
Thanks for the AI answers (which seem quite well-written and on-point for the questions I’ve asked, though I’ll always be wondering how much hallucinations are in there). However, instead of possible explanations for the chosen design I am really interested in the actual rationale for the design, which I guess the bot is not going to be able to tell me
According to the revision history (available on the 2nd page of Dahlia shematic:
-Resistor R350 has been marked as " Not Assembled" and CD1 pin of the MicroSD connector pulled with a TH resistor to +V3.3_SW
When the card is not present, the CD1 pin of the card holder is grounded. This leaves the SD_1_CD line floating, and since it has an internal pull-up resistor, it remains in a HIGH state. When the card is inserted, CD1 is disconnected from the ground, and the T40 input gets a 3.3V potential on its pin 1 through the mentioned through-hole resistor, causing the SD_1_CD line to be pulled low.
If you are developing your custom carrier board, it is highly recommended to follow the reference schematics in the Verdin Carrier Board Design Guide
(I noticed I had not followed up on this, sorry for that. I’ll reply below and while I am still curious about the reasoning here, we have since tested our custom carrier board design and the card detect now works as expected, so there is no longer a real problem to solve here, so do not invest too much time replying ;-p)
Ah, good idea to look at revision history, had not thought that.
This is how I also assume things are intended to work, but the dahlia v1.1 schematic has the CD1/CD2 pins shorted with a 0R R351, and thus permanently enables the transistor with R66, making SD_1_SD always low. So it seems the schematic contains a perfectly valid card detection circuit that could work in the way you describe, but due to the component placement choices, it does not work. And I am wondering why
Sorry, I was referring to an older version of the Dahlia schematic—please ignore those comments.
On the Dahlia board, the SD card connector has both CD1 and CD2 connected to ground when no card is inserted. When a card is inserted, they become floating, causing the T40 to pull down the SD_1_CD# line.
My assumption was that there was a card detect switch between pins CD1 and CD2 of the SD card slot (and thus one should be grounded and the other connected to the transistor base). However, looking more closely, it appears that the schematic symbol has CD1/CD2 both mapped to one side of the switch (pin 10A/10B are both labeled pin 10 in the datasheet) and the other side of the switch (presumably pin 9 in the datasheet, but the datasheet does not seem to be very explicit about this) is implicitly connected to ground (it probably is also connected to the chassis of the slot).
The schematic symbol we were using in our design did expose both of sides of the CD switch as separate CD1 and CD2 pins, which is why I had not realized this schematic symbol was different.
With that assumption cleared up, the schematic indeed makes total sense and will work as you describe.
