2016-11-05 05:52 AM
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 :)2016-11-06 07:24 AM
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.2016-11-08 11:54 AM
@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.