Skip to main content
anonymous.8
Senior II
March 15, 2017
Solved

Problems with STM32F746 and SDIO I/F not initializing with SysClock at max. 216MHz.

  • March 15, 2017
  • 3 replies
  • 1482 views
Posted on March 15, 2017 at 20:16

My application is running on the STM32F746 Discovery kit (STM32F746BG chip). mIf I initialize the system clock to its maximum of 216MHz early in the application, the SDIO (ST calls it SDMMC in the F7 series - why they do I just don't know!)) peripheral stalls and doesn't initialize in the PowerOn() routine.

However, if I run the system clock at a lower speed, e.g. 96MHz and then increase it to the maxmium 216MHz after the SDIO interface has initialized, it works and the rest of the application proceeds as normal.

The SD card bus speed is not effected by this change in SysClock speed since the SD card bus clock is derived from a dedicated 48MHz PLL. I've also made sure the initial SD card bus speed is at the recommended 400KHz.

I have read the datasheet, the reference manual and the errata sheet for that chip and couldn't see any reason why this is so.

Can anyone shed any light on this?

#sdmmc #stm32f7 #sdio
This topic has been closed for replies.
Best answer by anonymous.8
Posted on April 16, 2017 at 21:11

I eventually found my real problem. in my (non-HAL) clock initialization code, somehow with time, I had omitted the call to PWREx_EnableOverDrive() which of course means that the chip was not configured correctly to startup at 216MHz. Including that call fixed the problem.

3 replies

Tesla DeLorean
Guru
March 15, 2017
Posted on March 15, 2017 at 20:26

What if you drop the APB/AHB clocks?

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
anonymous.8
Senior II
March 15, 2017
Posted on March 15, 2017 at 20:36

Actually, to be correct, I simply changed the main PLL values so all the clocks dropped by the same amount. That problem had stumped me for several days and I was just glad to find a working solution, without fully understanding why that solution worked. I have wasted so much time with this issue that I really must get on now and make some productive progress at last. It could well be the SysClock is OK at 216MHz and maybe just the 

APB/AHB clocks should have been dropped instead.

My solution works, so for now I am inclined to just stay with it.

And further reading of the reference manual (page 1188) about the SDMMC interface reveals :

'

The SD memory card protocol is a superset of the MultiMediaCard protocol as defined in the MultiMediaCard system specification V2.11.

Several commands required for SD memory devices are not supported by either SD I/O-only cards or the I/O portion of combo cards.

Some of these commands have no use in SD I/O devices, such as erase commands, and thus are not supported in the SDIO protocol.

In addition, several commands are different between SD memory cards and SD I/O cards and thus are not supported in the SDIO

protocol. '

So the name SDMMC is probably a truer description of the functionality of that peripheral than the old F4 series name of SDIO is.
Nemui Trinomius
Associate II
March 21, 2017
Posted on March 21, 2017 at 16:02

Hmmm....My 746G-Discovery(with Rev.Z chip) is no problem even 216MHz SysClock.

And I derive SDMMC(48MHz) clock from PLLSAI.

anonymous.8
anonymous.8AuthorBest answer
Senior II
April 16, 2017
Posted on April 16, 2017 at 21:11

I eventually found my real problem. in my (non-HAL) clock initialization code, somehow with time, I had omitted the call to PWREx_EnableOverDrive() which of course means that the chip was not configured correctly to startup at 216MHz. Including that call fixed the problem.