5

I'm using a TI CC1111 SoC to read/write a microSDHC SD card, with an Amphenol card socket. The card detect (CD) pin of the socket is connected to ground when no card is present. When a card is inserted, the connection is broken. (This seems to contradict the datasheet, but it's what my multimeter tells me).

One way to detect card insertion would be to connect a GPIO pin to the CD pin. By default the CC1111's pins are configured with an internal pull-up resistor. If a card were present, I'd read logic high, and otherwise the pin would be pulled to ground. But I worried this might draw excessive current, and sure enough, the CC1111 datasheet warns (pg. 90):

Unused I/O pins should have a defined level and not be left floating. One way to do 
this is to leave the pin unconnected and configure the pin as a general purpose I/O 
input with pull-up resistor. This is the default state of all pins after reset except 
for P1_0 and P1_1 ... Alternatively the pin can be configured as a general 
purpose I/O output. In both cases the pin should not be connected directly to VDD or
GND in order to avoid excessive power consumption.

Question 1: Where is the power consumed? Is it just in the internal pull-up resistor? The datasheet says the internal pull-ups are 20k, so with 3.3 V that's about 0.17 mA. Is that what they're talking about? Or perhaps the "excessive power consumption" warning only applies when the pin is configured as an output?

Qustion 2: What is the right way to detect card insertion/removal without wasting power?

And no, I haven't measured the current draw yet, but I will.

Trygve Laugstøl
  • 1,410
  • 2
  • 19
  • 28
David
  • 1,023
  • 3
  • 12
  • 24
  • 2
    The current draw from doing this carefully (ie, not accidentally driving the pin as an output) should be of little problem -**except** when a battery-powered device needs to enter micropower sleep mode. – Chris Stratton Oct 12 '12 at 11:58
  • 1
    This *is* a battery-powered device that needs to enter sleep mode, as it turns out. In such cases it will have an SD card inserted, however, so the pin won't be connected to ground. But if the card were removed, it sounds like the battery would slowly be drained through the pull-up resistor. – David Oct 12 '12 at 14:07
  • 1
    what I would do in that case is use another output to drive an external pullup resistor, and configure a wakeup interrupt on the input. If the card is removed, wake up and turn off the pullup resistor, then go back to sleep. However, this only lets you detect contact "make" - you have to be awake or in power-consuming mode to detect contact "break". Depending on your needs, it might be simpler to just not drive the resistor except when you are awake. – Chris Stratton Oct 12 '12 at 14:34

2 Answers2

5

I'm pretty sure the datasheet warning is there to cover the case where a pin is tied directly to Vcc or Gnd, but then the firmware configures that pin as an output and tries to drive it to the opposite state (either because of a bug or a subsequent firmware change).

If you really want to play it safe, put a relatively low-value (say, 1K) resistor between the card socket contact and the GPIO pin. When the GPIO pin is used as an input, this resistor forms a voltage divider in conjunction with the internal pullup that still allows the pin to be read as "0". However, if the GPIO pin should inadvertently be configured as an output and driven high, it serves to limit the current flow to a few mA.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
0

Not being familiar with this particular SoC, is it possible to configure the I/O pin as an input without also enabling the internal pull-up resistor? If so, you could then attach your own external pull-up resistor with a much higher resistance (500k, 1Mohm, for example) which would then reduce the leakage current accordingly.

Then configuring the pin as an input, with an interrupt on change to wake it right before going to sleep should accomplish what you want. During normal operation I would suggest that the interrupt be disabled and polling on that pin be used instead to avoid nondeterministic interrupt behavior due to switch noise.

spuck
  • 645
  • 3
  • 8