STM32F4 Discovery MMC over SPI how to accelerate

[Kot_dnz]

Sorry - i edit my post before read your reply.
I try to check with pins and post result.
My question was not correct.

Can you reply on 'russian' early question"PPS: 'Looks like it is a long wait.' - currently this is a while(true), should it be failing after some time, say 3 or 60 seconds and it's time to give up?"

[Giovanni]

PPS: 'Looks like it is a long wait.' - currently this is a while(true), should it be failing after some time, say 3 or 60 seconds and it's time to give up?

That code stays in the loop until the card becomes IDLE meaning it returns an 0xFF. Are you telling me that the card keeps sending trash and stays in the loop forever? what is the value returned by the card?
I would consider an electrical problem here, do you have short wires and all the appropriate pullups on the connector?

Giovanni

[russian]

Are you telling me that the card keeps sending trash and stays in the loop forever? what is the value returned by the card?

Yes, the card keeps sending zero and stays in this loop forever. So, the value in buf[0] received from spiReceive(mmcp->config->spip, 1, buf); is '0'. So I wonder if there should be some sort of limit here so that the code does not hang up inside this method. I suggest a code change here to make the code more reliable, please I would love to start a separate thread and propose a patch if you agree with this in general.

I would consider an electrical problem here, do you have short wires and all the appropriate pullups on the connector?

I hear you and what you are saying makes total sense. But, again - it somehow works for us if we invoke the same method but from a different thread and at the different time - so I am convinced that we have a software, not hardware issue here. I am planning to connect my logic analyzer and report on this later.

[Giovanni]

It looks like the card does not switch to SPI mode so the connect phase then fails. Could you try to increase the number of slow clock cycles sent on connect?

In general I agree with not having dead loops, this means that the error should be propagated out of wait(), it should not simply return from there.

Giovanni

[russian]

Could you try to increase the number of slow clock cycles sent on connect?

Not sure what you mean here
Do you mean increase '16' in the ignore

Code: Select all

  /* Slow clock mode and 128 clock pulses.*/
  spiStart(mmcp->config->spip, mmcp->config->lscfg);
  spiIgnore(mmcp->config->spip, 16);

or increasing the value of MMC_CMD0_RETRY?

Because MMC_CMD0_RETRY would not make a difference - AFAIK it is hanging on the first iteration of the 'SPI mode selection' loop

[Giovanni]

spiIgnore() generates the slow clock pulses that are recognized by the card and put it in SPI mode (it is in SDIO mode by default).
Try increasing that value to a much higher one and see if it makes a difference.

It could be that the card does not initialize fast enough after insertion and misses the SPI switch procedure, this could explain why it works from CLI, it is already stably in place.

You should increase the spiIgnore() parameter and also play by inserting delays before calling spiConnect().

Giovanni

[Kot_dnz]

Sorry - i edit my post before read your reply.
I try to check with pins and post result.

I try to reconnect CS from PD11 to PB12 - nothing is changed.

[russian]

Status update: MMCmount() mount hands if executed on the main() thread and works if I just create another thread.
So, with this code MMC get mounted & I can write to it - no CLI any more:

Code: Select all

static msg_t mmThread(int param) {
   MMCmount();
   return -1;
}

void initMmcCard(void) {
//   MMCmount();
   chThdCreateStatic(mmThreadStack, sizeof(mmThreadStack), NORMALPRIO, (tfunc_t) mmThread, NULL);

but if instead creating mmThread I simply invoke MMCmount() - it is hanging up:

Code: Select all

static msg_t mmThread(int param) {
   MMCmount();
   return -1;
}

void initMmcCard(void) {
   MMCmount();
//   chThdCreateStatic(mmThreadStack, sizeof(mmThreadStack), NORMALPRIO, (tfunc_t) mmThread, NULL);

I guess this is not an electrical issue.

My system configs are available here - that folder contains three header files and the linker script.

Another observation - I've tried commenting out the 'wait()' invokation, this case 'send_hdr' method of mmc_spi goes right into spiSend. What was strange to me is that spiSend would also hang up - it would be hanging up on '_spi_wait_s'. Is not SPI supposed to just send data into the wire & return? Looks like somehow my SPI driver is messed up if I am trying to use it from the main thread.

[Giovanni]

Are you using the CCM memory?

Giovanni

[russian]

Are you using the CCM memory?

Yes, I am using STM32F407xG_CCM.ld - is there an issue with it?

I am manually defining which fields should go to ccm using __attribute__((section(".ccm"))) and none of the mmc-related fields are ccm