2018-10-24 03:15 PM
Hi, pretty sure this is a newbie type question. I'm using the SDMMC interface on an STM32L476. Right now it is just wired to a Nucleo board so I can do some benchmarking before committing it to a layout. I'm using STM32CubeMX and following the example in section 3.3 of UM1721 (Fatfs on CubeMX). After learning the hard way pullup resistors *are* necessary (some other posts said not), I am able to talk to a card, but only if I use polled mode ("Use DMA Template" set to disable in STM32CubeMX Fatfs settings). When enabled, the code hangs in the sd_diskio_dma.c SD_Read() routine right after the BSP_SD_ReadBlocks_DMA() call.
The note for "Use DMA Template" says to ensure that DMAs are properly configured but no more info. In the SDMMC configuration I've tried tried selecting SDMMC1 and then both SDMMC1_TX_SDMMC1_RX. I always get the stall. I am sure there i something basic I'm missing, but been at it for a couple days now and deciding to ask. Since this seems a very basic "follow the app note", rationalizing it might be useful for others too.
I've only recently migrated from the basic StcPeriph libraries to STMCube, starting with the LL routines, this is my attempt using HAL.
will
2018-11-05 01:33 PM
Clive:
Hmm, no signs of activity on CLK or CMD at all! I'm wondering if we have different IO assignments or something. It is a stock Nucleo-L476RG without an HSE (X3 not loaded). The IO assignments for the SDMMC I have are: CLK PC12, CMD PD2, D0 PC8, D1 PC9, D2 PC10, D3 PC11. I used ST-Link to program the hex file and it verified OK. Besides the wires to the SD card reader, the only other hardware are the 5 47K pull-ups on DAT and D0-D3.
will
2018-11-05 01:39 PM
its cool buddy, keep workn....
I was just looking at another thread, where the DMA is not running, and solved by switching RAM blocks... in the compiler directives.
View/Answer
2018-11-05 04:09 PM
TJ:
THAT WAS AN INTERESTING POST! That would be the class of newbie-type issue I could see tripping me up. The 'L476 does have two RAM banks, something I've never dealt with before--and I am patching HAL demo code into CubeMX generated code. At least so far in going over the chip and register docs I can't see where there is any difference that matters to the DMAs. I'm using only SRAM1 (the "normal" one) right now and at least for the CPU and DAC DMA it is working OK. That gives me something to look into more though, thanks. Hoping there is something good there I haven't found yet.
will
2018-11-06 08:28 PM
You'd need to walk it through on the console, pressing ENTER, will drop it through an initial pass.
Wiring from the back side
2018-11-10 07:13 PM
Clive:
I had some other priorities for a few days, but back on it now. I had the SDMMC wiring right, but stuck on the console without some further information. I guessed at USART2 given that is what is connected to the Arduino pins, but see nothing and blindly pressing ENTER with a few baud rates didn't work. I looked at several of the alternate pins for USARTx_TX pins and don't see any data coming out at any baud rate. Studying your pictures doesn't show any wires outside the SDMMC pins either. Can you tell me which pins for the USART (assuming it is USART), and baud rate?
will
2019-02-04 01:40 PM
All:
I let this thread go silent for a while realizing that since I wasn't in an RTOS I had to wait for the SD IO to finish anyway, using DMA wasn't really helping that much. That seemed reasonable until I started adding a lot of interrupt driven code and realized that some intermittent problems were related to SD card data getting lost during heavy interrupt processing. That spurred renewed interest in getting DMAs to work! Since this posting there many more threads on this subject, so clearly I am not alone. This thread ( https://community.st.com/s/feed/0D70X000006SpXHSA0 ) which includes Clive Two.Zero's input seems to have the cleanest set of changes to make. I've followed the instructions and still no luck yet, but pretty sure this is a good path to be following. Hopefully I'll be able to close this soon.
will
2019-06-03 10:53 PM
Still no luck on this? I am fighting the same issue on the stm32l496 disco . It appears that Clive is the only one with it working but will only share for a fee. I offered a high five but I think he wants more. I just opened a ticket with st, will be saying my prayers for a response
2019-06-03 11:00 PM
will be saying my prayers for a response
@Beachmiles Whoever you God/ Goddess is, hope you are patient.
2019-06-04 04:13 PM
Beachmiles and Lucasz: Unfortunately, still no luck. I was able to implement a work-around without using DMA by leaving the SDIO code in the main (non_ISR) loop and then ensuring that all my interrupts just logged the interrupt and returned fast enough to not mess up the SDIO program-IO. No great, but got things working. I spent about half a day slowly tracing through all the DMA code step by step and it all seemed reasonable. My best theory is that it is something in the setup that I'm missing (and I guess ST too!) . I have a second project I'll be starting shortly that would benefit from DMA-based SDIO and will use that as an excuse to try a second round at getting DMA working again. Beachmiles, if you do get some feedback, that would be great. Praying too you are successful! :)
will
2019-06-04 08:04 PM
Found some decent success, posted code here. Only doing a small write and read but it freaking works which is a start.