Skip to main content
dpfeffer9
Associate II
November 5, 2016
Question

STM32F4: SD-Card using FatFs and USB fails

  • November 5, 2016
  • 2 replies
  • 956 views
Posted on November 05, 2016 at 13:52

Hi,

in my application, I've set up a STM32F4, SD-Card and USB-CDC (all with CubeMX). 

Using a PC, I send commands to the STM32, which then does things on the SD-Card.

The commands are handled using a ''communicationBuffer'' (implemented by me) which waits for commands over USB, UART, ... and sets a flag, when a \n character was received. The main loop polls for this flag and if it is set, a parser handles the command. So far, so good.

When I send commands via UART, it works fine, and I can get a list of the files on the SD-Card or perform other access via FatFs without a problem.

The problem occurs, when I receive a command via USB-CDC. The parser works as expected, but FatFs claims ''FR_NO_FILESYSTEM (13)'' in f_opendir.

Also other FatFs commands fail with this error-code.

After one failed USB-command, commands via UART will also fail. It seems, as if the USB somehow crashes the initialized SD-Card-driver.

Any idea how I can resolve this behaviour?

Thanks :)
    This topic has been closed for replies.

    2 replies

    Tesla DeLorean
    Guru
    November 6, 2016
    Posted on November 06, 2016 at 16:24

    You need to understand what's going on below FatFs, instrumenting the diskio.c layer would be a start.

    You need to ensure access to the SDIO resource is serialized (mutex or semaphore). You will also need to ensure the IRQ's used by the SDIO/DMA preempt anything that will block them. I'd also look for blocking loops in ST's code.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    dpfeffer9
    dpfeffer9Author
    Associate II
    November 8, 2016
    Posted on November 08, 2016 at 20:54

    @clive1: Thanks for your ideas :)

    I solved the problem:

    In `usb_cdc_if.c` the `#define APP_RX_DATA_SIZE` was set to `4` (for some unknown reason). As this is lower than the packet size, incoming packets of a larger size than 4 bytes were overwriting my memory. 

    It happened, that the following portion of my memory was the `FATFS* FatFs[]` pointer-list to the initialized FATFS-Filesystem structs.

    So subsequently the address to this struct was overwritten, when a command of 5 or more bytes arrived.

    Phew, that was a tough one.