Mbed-os: Is there any way I can use SDIO with filesystem?

[savent404]

Description

• Type: Question
• Priority: Major

Question

As title

[0xc0170]

@deepikabhavnani Please review

[deepikabhavnani]

We have SDBlockDevice driver for SD cards which uses SPI interface, and SDIO support is not available yet. In case you are planning to implement SDIO driver, you can add it as BlockDevice. BlockDevice class provides the underlying API for representing block-based storage that you can use to back a file system. Mbed OS provides standard interfaces for the more common storage media, and you can extend the BlockDevice class to provide support for unsupported storage.

For more information please refer: https://os.mbed.com/docs/v5.7/reference/storage.html

[savent404]

There is only one question: mbed-os not support a API for SDIO interface, and i only plain to use it in stm32. How can I implement SDIO driver or only implement SDFilesystem for STM32 SDIO driver?

[deepikabhavnani]

API's for SDIO interface will be same as API's for SPI interface. https://github.com/ARMmbed/sd-driver/blob/master/SDBlockDevice.h

[pauluap]

I'm sorry I don't have a public repository to share, but I found it pretty straightforward to implement the BlockDevice API using ST's Cube BSP functions - BSP_SD_xxx() Depending on your STM device, you should be able to download the appropriate ST Cube package to get the BSP drivers to use. If you're not using any of their evaluation boards, then you can use the BSP implementation as a starting point.

[savent404]

That is exactly what i'm doing!

[0xc0170]

Thanks @pauluap for sharing.

@savent404 The question answered? I'll close it. Please reopen with an update if any

[JojoS62]

I have implemented a SDIOBlockDevice for the STM32F4. It needs some further testing but it is working already on a DISCO_F469NI and on a chinese STM32F407VE board. I would like to make a PR and appreciate any help for testing and design decisions.
Should this issue be reopened or shall I open a new issue?

[savent404]

Hi, I got a solution about implement BlockDevice

[JojoS62]

I've also used the STM32 HAL implementation and created a /components/SDIO_BLOCKDEVICE. That makes it compatible with the FileSystem class and also LittleFS can be used.
I need to clean up my code before pushing, it contains too much stuff for testing.

[savent404]

I think SDIO should be a library supported specific SDIO's DMA mode. That's very useful in my opinion.

[JojoS62]

until now, I have tested only polling mode (which is fast already). But my idea is to select polling/DMA by using a switch in the mbed configuration system.
There are not so many mbed enabled boards with SD card connected to SDIO, is your F411 an official mbed board?

[savent404]

using extra boards can do that. And, DMA is not about speed, it's about CPU's usage. Sometimes we can't waste cycle for waiting for SDIO read/wirte complete.

[JojoS62]

I have pushed a working SDIOBlockDevice to my fork:
https://github.com/JojoS62/mbed-os/tree/add-component-sdio-blockdevice/components/storage/blockdevice/COMPONENT_SDIO
This is the API, the implmentation uses a sdio_driver layer and I have created it currently for the STM_F4:
https://github.com/JojoS62/mbed-os/blob/add-component-sdio-blockdevice/targets/TARGET_STM/TARGET_STM32F4/sdio_device.c
It is basically the CubeMX generated bsp_driver_sd, but with modifications for mbed. Q: should the copyright stay original STM or can it be changed to mbed standard? The code is modified from the original and needs further changes for the interrupt and dma configuration.
There are not many boards with a SD slot connected to SDIO, so I could test it only with a DISCO_F469NI and a non mbed enabled board with STM32F407VE : https://os.mbed.com/users/hudakz/code/STM32F407VET6_Hello/shortlog/.
For testing, the SDIOBlockdevice still contains some references to HAL specific structures, but I will remove these to make this API useful also for other non STM targets.
The implementation uses DMA. I have tested also polling mode, but the HAL code is too slow for a reliable fast data transfer. I've got Fifo overrun errors with polling and more worse with polling and debug builds.
After some cleanup I can make a PR for this device.

[deepikabhavnani]

Q: should the copyright stay original STM or can it be changed to mbed standard? The code is modified from the original and needs further changes for the interrupt and dma configuration.

CC @0xc0170

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-218

[masoudr]

@JojoS62 Hi, Can you provide an example to use your SDIO? I tried to use your repo but I can't find an example to just read/write a file to sd. Thanks.

[JojoS62]

@masoudr you can use the https://github.com/ARMmbed/mbed-os-example-filesystem. Add the the include for "SDIOBlockdevice.h" and use the SDIOBlockdevice and FATFilesystem

SDIOBlockDevice bd;
FATFileSystem fs("fs"); 

[masoudr]

@JojoS62 Thank you. I had two problems, first when I included the "SDIOBlockDevice.h" I got an error about no such file or directory then I copied both SDIOBlockDevice.h and SDIOBlockDevice.cpp to a new folder in my root project and it compiled. Why I faced that issue? If I want to add it to new versions of mbed-os which files should I add?
My second question, what is the current state of this SDIO library? Is it preferred over SPI?

[JojoS62]

The files are in a special directory with a name with capital letters. This is included only when the target has the definition "components": ["SDIO"] included. I have tested the component with a DISCO_F469NI board and added this to the targets.json.
The SDIO Interface is faster than the SPI. But the main reason was that my targets DISCO_F469NI and a chinese STM32F407VE board have a SD card on board. These are connected to the SDIO interface and the connection cannot be mapped to a SPI.
To use the component in another project, you need to copy the COMPONENT_SDIO dir and the low level implementation in https://github.com/JojoS62/mbed-os/blob/add-component-sdio-blockdevice/targets/TARGET_STM/TARGET_STM32F4/sdio_device.c together with the sdio_device.h file.
Are you using a mbed board or a custom board?

[masoudr]

@JojoS62 Yes I'm using the black STM32F407VE and it worked fine. My custom board is based on STM32F407VG which seems similar. Is there any way to port it to lower versions of mbed-os like 5.5? It seems that it doesn't have component property.

[JojoS62]

the 'component' structure is new, before the storage component was located in 'features'. You can copy the SDIO files also to a custom lib in your application, the mbed build system will find it.
For a PR I still need to clean up the component, accessing HAL structures from the user API is not nice.

[adustm]

cc @screamerbg @MarceloSalazar @ARMmbed/team-st-mcd

[MarceloSalazar]

@JojoS62 thanks for the great work on getting SDIO working on the DISCO_F469NI platform!
Would you consider sending a PR to get SDIO support in Mbed OS? Thanks!

[JojoS62]

I want to do some more cleanup and try to run the BD Tests, then I will start the PR.

[JojoS62]

@MarceloSalazar I have tried the first time to use the mbed tests. I copied the tests from SDBlockdevice and changed the setttings for SDIOBlockdevice.
I have some problems with the bd.init() / bd.deinit() sequence, on an execution of another bd.init() after a deinit() the HAL code is hanging in a SD_FindSCR() function when checking if 4 bit mode is supported. When I uncomment this check and switch to 4 bit mode anyway the tests are all passing positive.
In the case of the failing tests I can not see the reason why the seek test is passing ok but other tests are failing, the seek test performs also an init/deinit. Only the fopen test is programmed differently, the bd is assigned in the fs constructor statically and no init/deint is performed, so no problem.
SDIOBlockdevice-Testresult-ok.txt
SDIOBlockdevice-Testresult-notOk.txt

[JojoS62]

At the moment, I found two problems:

• SD_FindSCR() is trying to read the SCR with polling when the SD is in fast transfer mode already. This polling seams to be very time critical, although data is read from a fifo. Within the read loop, there is a timeout check that reads the mbed timer. But due to a lot of lockings and checks for locking this has become very slow. Removing the timeout check makes the code work. Anyway, removing the FindSCR from the initialisation works more reliable and the SD standard requires 1 and 4 bit mode.
• the FATFS format makes calls to blockdevice init/deinit, it looks like the reference counting for init/deinit is mandatory in the BD implementation, is that true?

[MarceloSalazar]

@dannybenor @offirko is this something you could review and advise? Thanks!

[JojoS62]

thanks for your support.
For the second point I will implement the reference counting.
I had also some problems with rebasing my feature brand with master, after solving I will update my github repo.

[masoudr]

@JojoS62 About a month ago I tested the SDIO and worked fine for me. Now I tried your new version that works too but I have some problem with mounting sd I need to reset my board twice or more to get sd mounted. I mean Filesystem.mount(sdio block).

[JojoS62]

@masoudr I have continued my work in a newer branch, add-sdioblockdevice. In 'add-component-sdio-blockdevice' I mixed sources from two origins and I could not rebase it without always merging.
My PR was not accepted, but I will create a lib as suggested here: https://github.com/ARMmbed/mbed-os/pull/8634 I'm currently working on this.
The tests that I used showed also a problem with multiple init/deinit of the blockdevice, this was fixed in the 'add-sdioblockdevice' branch, so you should try these files.

[masoudr]

@JojoS62 Thanks. Now I'm testing it and it is a lot faster. I'm testing it with zlib and it worked fine for me.

[savent404]

hi guys,

i got some question about this code.
stm32's code planed on target/stm32_family/stm32f4, means it's a general code for every stm32f4 familyn and it's not.
that's import for dma channel and pin layout.

besides, there should be a solution to avoid any other lib use the same dma

发件人： [email protected]
发送时间： 2018年11月10日 上午5:05
收件人： [email protected]
回复： [email protected]
抄送： [email protected]; [email protected]
主题： Re: [ARMmbed/mbed-os] Is there any way I can use SDIO with filesystem? (#6384)

@JojoS62https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJojoS62&data=02%7C01%7C%7Cc9389ec4eee04cccd89d08d646870bdf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636773943159754008&sdata=7ja8IrmwExcQ3gdLxulrtd9lNPrmFu347nuOefvp20o%3D&reserved=0 Thanks. Now I'm testing it and it is a lot faster. I'm testing it with zlib and it worked fine for me.

―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FARMmbed%2Fmbed-os%2Fissues%2F6384%23issuecomment-437494830&data=02%7C01%7C%7Cc9389ec4eee04cccd89d08d646870bdf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636773943159754008&sdata=Vss1NIunozemUCK309mSnf5CN3yAmeAoacMme48m3m8%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAV1LqEM8z1Du_LVIImRXlsC_cPEiBEYIks5ute4KgaJpZM4SuthF&data=02%7C01%7C%7Cc9389ec4eee04cccd89d08d646870bdf%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636773943159754008&sdata=3OszjZC4Qat6kKW7zV3FOGnddk3UurQ3pgXHo8Uy8nc%3D&reserved=0.

[JojoS62]

@savent404 You are right, the constructor should get the IO pins for the SDIO interface. This version was tested with F469NI and F407VE, there the was same configuration. I will check this.
For the DMA, there are only two choices. There could be also a configuration via constructor or mBed configuration system.
And please answer through the github web interface, not by replying to the mail notification.

[deepikabhavnani]

We have separate repository for SDIO driver https://github.com/ARMmbed/sdio-driver. Please add issues, queries and PR to respective repository, closing this