Giters

carlk3 / no-OS-FatFS-SD-SPI-RPi-Pico

A FAT filesystem with SPI driver for SD card on Raspberry Pi Pico

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Lose control of CS after using library

rightbrace opened this issue · comments

commented

I'm working on a battery powered device, and want to cut power to my sd card when not using it. Unfortunately, I can't set the CS pin low after making calls to the library.

I've tried calling gpio_put(CS_PIN, 0), reinitializing it with gpio_set_func, deinitializing the SPI interface, and probably a few other things, but the CS pin stays high. I'm not super familiar with the platform so it is very possible its not actually an issue with the library, but I can find nothing similar online.

At the time of writing, I do see this in sd_spi.c:

  gpio_put(pSD->ss_gpio, 0);
  // A fill byte seems to be necessary, sometimes:
  uint8_t fill = SPI_FILL_CHAR;
  spi_write_blocking(pSD->spi->hw_inst, &fill, 1);

Does this suggest that the CS GPIO won't change state without writing to SPI? That seems very improbable, but its the only lead I have left and I'm unfortunately able to test right now (and even if that is the solution, I would be curious to know why that's the case).

commented

I'm working on a battery powered device, and want to cut power to my sd card when not using it. Unfortunately, I can't set the CS pin low after making calls to the library.

Note that CS is "active low", so you're actually activating the SD card by setting it low. My guess is that it would consume less power if deselected (CS high). Your best bet might be to add a power distribution switch IC to cut the 3.3V V(DD) supply to the SD card socket.

Does this suggest that the CS GPIO won't change state without writing to SPI?

No, the pSD->ss_gpio is just a plain old GPIO. You can see how it is initialized in bool sd_init_driver() in FatFs_SPI/sd_driver/sd_card.c.

I've tried calling gpio_put(CS_PIN, 0)

How is CS_PIN defined?

commented

I revisted the code for the umpteenth time before posting this and spotted on tiny sequencing issue, and everything appears to work correctly now, you are correct, that pin is now behaving as a gpio should, and it was on my end, thank you and sorry about that.

I don't expect this issue to help many others, but just in case, here are my answers to the above:

Note that CS is "active low", so you're actually activating the SD card by setting it low [...] Your best bet might be to [...] cut the 3.3V V(DD) supply to the SD card socket.

I'm currently cutting the power on Vdd, what I'm noticing is that there's some voltage on the line anyway, and CS is high, so it looks like CS is probably powering the line through a pullup. And yes, the active low thing means I'm resetting the sd on each use using the method in #9.

How is CS_PIN defined?

It's just the GPIO number, in this case, 13.

commented

Instead of gpio_put(CS_PIN, 0) maybe just gpio_deinit(CS_PIN) to disable it?