Chibios and FATFS SDHC support

[Jeroen3]

Hi,

I've a working board with Chibios STM32F4, and an microSD card socket with a 2GB microSD card. This workd fine, for weeks now.
However, initially I started developing with a 4GB card. This means it is microSDHC. This worked for a while, then it suddenly stopped.
After a few resets and undo's I noticed the card was very hot. I've checked the board for problems, spikes and noise. Bot nothing serious.
The card also went into heater-mode in any other cardreader. I killed two, since I first thought is was due to mechanical stress.
According to spec, all SD compliant devices must work on 3.3 Volt, so thats not it either.

Does anyone else have seen this strange behavior?
Or is it incompatibility with the microSDHC standard. Which would mean somehow the "self-destruct" feature was triggered. (if any)

It weren't any cheap-o-chinese card, it were real kingston cards bought from a well known rs distributor.

[Giovanni]

Hi,

Looks like an electrical issue, long wires, wrong or missing resistors, no decoupling, things like this.

Giovanni

[Jeroen3]

It must be. But also, it shouldn't.
The only electrical precaution not used is a choke... 0.1 and 1uf cap placed near the socket, 200 ohm resistors in series and 47k pullups.

I guess I'll find out when testing different cards...

[Giovanni]

Note that I recently committed a patch regarding V1.1 cards initialization, are you using the latest code or 2.6.5?

Giovanni

[Jeroen3]

I''m at 4e11d82, "Fixed bug #514". (git)
Ahead are two modifications in the sdc drivers, #522 and #523.
I'll update the submodule when I can.

[Tectu]

I''m at 4e11d82, "Fixed bug #514". (git)

As far as I know that repo state even uses the 'old' FatFS library. The new one is 0.10b.
Personally don't have issues to use SDHC cards. I didn't have issues with them in the past and with the latest master.


~ Tectu

[Jeroen3]

I've used fatfs R0.10b from the beginning.

[fastlink30]

not know if good place where to write this, but...

i have also problem with fatfs (i'm not sure if is fatfs or how i code) on stm32f4discovery chibistudio prev. 6
i want use fatfs with spi3 and gpioa_pin4 as SS
someone can check my code (i hope there are all) , becouse when execution arrive to mmcConnect (on test routine) , all stop and not continue
i miss something? i see some example and they use serial, in my project i use usb and i put 'handler' in the shell config
(static const ShellConfig shell_cfg1 = {(BaseSequentialStream *)&SDU1, commands};)
also not understood why serial is 'connected' with the shell in many examples

thanks

Code: Select all

static FATFS MMC_FS;

/**
 * MMC driver instance.
 */
MMCDriver MMCD1;

/* FS mounted and ready.*/
static bool_t fs_ready = FALSE;

/* Maximum speed SPI configuration (18MHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig hs_spicfg = {NULL, GPIOA, GPIOA_LRCK, 0};

/* Low speed SPI configuration (281.250kHz, CPHA=0, CPOL=0, MSb first).*/
static SPIConfig ls_spicfg = {NULL, GPIOA, GPIOA_LRCK, SPI_CR1_BR_2 | SPI_CR1_BR_1};
/* MMC/SD over SPI driver configuration.*/
static MMCConfig mmccfg = {&SPID3, &ls_spicfg, &hs_spicfg};

static EventSource inserted_event, removed_event;

void sd_init(void) {
  struct EventListener el0, el1;
  static const evhandler_t evhndl[] = {
    InsertHandler,
    RemoveHandler
  };

  // function alternate for spi3
  palSetPadMode(GPIOC, 12, PAL_MODE_ALTERNATE(6) | PAL_STM32_OSPEED_LOWEST); // mosi
  palSetPadMode(GPIOC, 11, PAL_MODE_ALTERNATE(6) | PAL_STM32_OSPEED_LOWEST); // miso
  palSetPadMode(GPIOC, 10, PAL_MODE_ALTERNATE(6) | PAL_STM32_OSPEED_LOWEST); // ck

  palSetPadMode(GPIOA, 4, PAL_MODE_ALTERNATE(6) | PAL_STM32_OSPEED_LOWEST); // ss
  palSetPad(GPIOA, 4);

  mmcObjectInit(&MMCD1);
  mmcStart(&MMCD1, &mmccfg);

  chEvtRegister(&inserted_event, &el0, 0);
  chEvtRegister(&removed_event, &el1, 1);

test();
}

void test(BaseSequentialStream *chp, int argc, char *argv[]) {
  FRESULT err;
  uint32_t clusters;

  (void)argv;

//  chprintf(chp, "Trying to connect MMCD1... ");
  bool_t a=mmcConnect(&MMCD1);
//  if (a) {
//    chprintf(chp, "failed connect card!\r\n");
//    return;
//  }

  err = f_mount(0, &MMC_FS);
  if (err != FR_OK) {
   // mmcDisconnect(&MMCD1);
    return;
  } else {
    chprintf(chp, "FS: mounted\r\n");
  }
.........

[Giovanni]

Probably pins speed should be fastest, not lowest, SPI has pretty fast signals. Also, SS must be a push-pull output, it is handled in software, not by the SPI itself.

Giovanni

[fastlink30]

i've changed to HIGHEST, but nothing happen
i must check signals, but now i can't, i'm on vacancy.
but code is ok?

thanks