STM32L4 with USB MSD and FatFS, Limitations

[Nor Sch]

Posted on October 11, 2016 at 12:19

First: I do not use USB MSD and FatFS at same Time, but they work on the same SD-Card. This SD-Card is connected via SDIO with 4 Bit Databus. I use a STM32L476 but I think the Problems should be identical for all STM32L4-MCUs.

In the last Weeks I worked among others a lot on USB MSD and FatFS and got a bunch of Trouble with this. I updated FatFS (R0.12b) and FreeRTOS (v9.0.0). To get it run, I also used some Code from the Examples of the STM32L476-Eval-Board. Additionally I refactored a lot of CubeMx-generated Files including HAL-Drivers. The Result was cleaner, shorter and better readable Code without lot of duplicate Stuff, but I couldn't find any (not-documented) Errors or Reasons for obscure Limitations. Here are the Limitations I found:

1. The sdmmc-ClockDivider is internally incremented by 2. With a Clock of 48 MHz and the in Theory possibly Divider 0 the 24 MHz should be possible. But In Practice I must use 2 and get a Clock of 12 MHz. Otherwise I get from Read()-Functions permanently SD_RX_OVERRUN, means that I�m to slow with reading incoming Data out of the FIFO. The Demo-Code for the STM32L476-Eval-Board also uses 2 as Divider, but why?
2. With FatFS the DMA-Write is working fine, with DMA-Read I get again the SD_RX_OVERRUN in every Case after 84 Byte copied from FIFO into my Buffer. The FIFO has 128 Byte and seems to be again faster full than the slow L4 can read out.
3. With USB MSD I have to use also for the Write the blocking Mode. The DMA-Write is hanging somewhere not getting a Flag (I�m not sure without testing it again, which Flag, but it looked like a suggested IRQ-Handler is not called). So from generated Code no DMA at all is usable here.

Can anyone give some Hints to these Problems or can anyone confirm these Limitations? Any Suggestion is welcome!

By the Way here are the Speed-Limits I got with deactivating other Threads. The Internal Tests are done with a 1MB-File. For the USB MSD I used a Windows 7 and copied Files greater 40 MB. Internal FatFS Read 3908 kB/s Internal FatFS Write 678,6 kB/s USB MSD Read 702 kB/s USB MSD Write 657 kB/s I think I�m on the Limit with these Values for the slow STM32L4 with 12 MHz SDIO-Clock and only USB FS with 12 Mbit/s. But I�m sure, that I will need the DMA later to get a little bit more Power for the other Threads � Also I think, that the Implementation of SD-HAL-Drivers and FatFS is not really cooperative for RTOS. After the Start of Read / Write even with DMA you will poll on some Flags. Has anyone a Hint for a fine working Solution which has multithreading better integrated? #stm32l4-usb-msd-fatfs-dma

[Imen.D]

Posted on January 02, 2017 at 12:29

Hello

Bryenton.Al

‌,

Back to case 1, you have to refer to the

http://www.st.com/content/ccc/resource/technical/document/datasheet/b2/96/77/54/39/06/4d/cb/DM00149pdf/files/DM00149pdf/jcr:content/translations/en.DM00149pdf

where it is specified that:

SDIO_CK/fPCLK2 frequency ratio Maximum value is4/3

which should be aligned with your deduction. In all cases as specified in the RM0351,PCLK2 and SDMMC_CK clock frequencies must respect the following condition:

Frequency(PCLK2) > ( ( 3xWidth) �?� 32) × Frequency(SDMMC_CK)

About case 3, we need to understand more why do you suggest to add

10mSec

delay ? Could you please provide us more details?

Best Regards

-Imen-

[bryenton]

Posted on January 03, 2017 at 02:40

Hi Imen,

Thanks for the responses to each of my points!

On 1, I had not seen this 4/3 SDIO_CK/fPCLK2 ratio, I had only noticed the second 3*width / 32 one. I had been using 4 bit SDIO, should have mentioned that, and was finding that the 3*4/32 i.e.the 3/8 ratio I mentioned above did not hold, but the 6/8 i.e. 3/4 one you pointed out certainly does. If you compare these 2 I believe there are many cases where the 3/8 rule is satisfied, but the 4/3 rule needs to be applied to make things work. Wish I knew about that one a lot earlier.

On 2, great, I had been using rel 1.4 and 1.5 so another reason to migrate to 1.6.

On 4, great.

On 3, I will try to redo some tests to give more specifics, but recollection is that at lower speeds (i.e. Pclk2< 8M) if I didn't put in over a 5msec delay that it would regularly fail the Cmd 0/8 sequence. 10msec seemed to resolve this issue.

A general question Imen, but is there a place that I can submit specific bug reports? as mentioning them in forums like this probably isn't the most effective way.

Thanks,

Al

[Imen.D]

Posted on January 03, 2017 at 12:03

Hi

Bryenton.Al

‌,

You can add'bug' tag to this discussion. This help you andusersto filter by tags and find specificbug as quickly as possible.

All comments and suggestions are welcome to improve our solutions.

Best Regards

Imen

[G A]

Posted on March 06, 2017 at 19:32

I cannot answer the specifics in you post, buy I finally have a nice working implementation of FatFS on an SD card using DMA and also FreeRTOS. Here are some of the important lessons I learned. My system is based on the STM32F4 discovery board.

1. For FatFS there is a module called 'Compatibility checker for low level disk I/O module' on the FatFS web site. It is very hard to find. Before you try anything with files make sure this module runs. This tests all the drivers to make sure FatFS will work. Note: unless you re-write the HAL modules the last test, 4GB barrier, will fail. This is to support files over 4GB. Depending on you application that may be OK. (SD cards bigger than 4GB are OK as long as individual files are under 4GB). 

   http://elm-chan.org/fsw/ff/res/app4.c

2. When using DMA you need to be careful about word alignment. FatFS does a good job of caching and coalescing writes but frequently it will pass a non word aligned pointer to the HAL write function. It took me a long time to track this issue. Currently I trap misaligned writes in the HAL write function and copy to an aligned buffer. With more time I would like to explore how to reconfigure HAL DMA to handle half word or byte transfers. This issue is detected by the test code above.
3. Make sure the SDIO global interrupt has higher (lower numerical, Ej. 5) priority than the DMA Stream interrupt (Ej priority 6 for TX and 7 for RX)

[vladimir boretsky]

Posted on August 15, 2017 at 17:34

Hello frends!

I tried produce very simple project for uSD card communication by CubeMx.

The project was generated in the POLLING Mode SD communication and write and read functions working properly.

I tried to change POLLING to DMA write read mode. Now it is impossible to open file , because I received error.

The cause of error is : Impossible to find FAT on the SD card.

I compared this project to base sample from  

STM32Cube_FW_L4_V1.5.0/Projects/STM32L476G_EVAL/Applications/FatFs/FatFs_uSD/.

It is mostly the same. The CubeMx produce this code slightly optimized.

I return to sample from 

STM32Cube_FW_L4_V1.5.0/Projects/STM32L476G_EVAL/Applications/FatFs/FatFs_uSD/.

I produced a lot of changes in this code and tried to work in the DMA mode. I produced TX and RX true different DMA.

Now I have  DMA_read working quite well. It is mean that I can read 2G file by chanks of 8kBytes without great problems. The DMA_write process working till writings block has less 1024 bytes long. If more then write error occure quickly. As usial it is CRC error.

I need DMA write and read communication, because my main application can't wait for POLLING mode.

So, Can anybody send me working project with write and read by DMA using.

I can send to anybody my partially working project for analyze also. 

For answers my EMail is

mailto:boretskyv@gmail.com

.

Thank you very much.

[Amel NASRI]

Posted on August 15, 2017 at 17:59

Hi

boretsky.vladimi.002

‌,

This blog:

https://community.st.com/0D50X00009bMM7JSAW

may bring you some help.

-Amel

[Amel NASRI]

Posted on August 16, 2017 at 11:57

Hi,

The explanation why it doesn't work with DMA is provided by

dresler.tomas

‌ in

https://community.st.com/0D50X00009XkYIISA3

.

-Amel

[vladimir boretsky]

Posted on August 16, 2017 at 10:20

Hello AMEL N!

Thank you for yours response.

I tried improve my project according to SDIODMAFatFS.pdf document.

I received the same results. If I use BSP_SD_WriteBlocks

and BSP_SD_ReadBlocks functions(It's mean that read and write producing in

the polling mode) all working properly.

If I change BSP_SD_WriteBlocks to BSP_SD_WriteBlocks_DMA and

BSP_SD_ReadBlocks to BSP_SD_ReadBlocks_DMA it is impossible even open file

. The returned error is RES_NOFILESYSTEM. It's mean that we have problem

with read from SD card in DMA mode. I doubt that it was checked oreviously.

Does anybody tested any processor from STM32L4 family for write and read SD

card in the DMA mode?

BORETSKY VLADIMIR

Mobile: 972(0)503-002216

EMail: boretskyv@gmail.com

2017-08-15 19:02 GMT+03:00 Amel N <st-microelectronics@jiveon.com>:

STMicroelectronics Community

<https://community.st.com/?et=watches.email.thread>

Re: STM32L4 with USB MSD and FatFS, Limitations

reply from Amel N

<https://community.st.com/people/st.mcu?et=watches.email.thread> in *STM32

MCUs Forum* - View the full discussion

<https://community.st.com/message/165739-re-stm32l4-with-usb-msd-and-fatfs-limitations?commentID=165739&et=watches.email.thread ♯ comment-165739>