cancel
Showing results for 
Search instead for 
Did you mean: 

Using ST's FATFS within CubeMX for STM32F4xx - lack of info

childresss
Associate II
Posted on May 22, 2015 at 23:48

I'm reasonably competent in using CubeMX, STM32F4xx with IAR.

I added the SDIO driver for micro-SD cards, via the latest HAL libraries that CubeMX utilizes.

I have this ID'ing and doing read/write at the driver level (HAL calls). It works with only 1/3 of the brands of SD cards; 2/3 either don't ID reliably (init at 400KHz), or they give 100% read errors - code 3 = CRC error on command responses. 

I 'scope checked the SCK and DO/DI signals - waveform quality good. PCB wiring is short/OK (my project's PCB). Vcc OK. I slowed the SCK to 4MHz. No help. But 2 brands of uSD cards work reliably. All are type 2 8GB. SDIO is running with ONE serial channel, not 4.

Now I decided to try ST Micro's adaptation of ChanFS (FAT FS) that's an option from CubeMX. The init calls in main() from CubeMX include   MX_FATFS_Init() and that is no where in the sources. I found a ''thirdparty'' folder in my windows home lib area and in there is the sources to FATFS for ST. But CubeMX did NOT pull any of these into the IAR project.

I read this ST document

UM1721

User manual

Developing Applications on STM32Cube with FatFs

And found it to be  useless, written by someone from another galaxy and does not talk about how to truly get the sources into the (IAR) project and do a build, esp. w.r.t. CubeMX. So ST paid someone for nada.

Anyone out there know how I can (a) troubleshoot why some uSD cards work with the SDIO driver in the latest HAL libraries but most cards don't; (b) how to get FATFS to run on a custom board using CubeMX, STM32F4xx? Maybe a miracle will occur, but FATFS uses the same problematic drivers as I see.

Thanks much.  I have spent way too much time on this!!

(PS: I cannot use the legacy ST peripheral drivers)

11 REPLIES 11
rwmao
Senior
Posted on June 02, 2015 at 06:50

Mark,

Thanks for your reply.

In the past weekend, I studied the printf as a debug method. I managed to output info through the ITM_SendChar(). http://www.doulos.com/knowhow/arm/Retargetting_a_C_library_function/

It works at the testing project, which was created only for printf testing.

However when I migrate it to the uSD project, the printf doesn't work.

Does it conflict with the fatfs, which was used to read/write file of uSD? The debug info(printf) was output through SWO interface.

On the other hand for a project using fatfs, how to use printf to debug?

Thanks

markb
Associate II
Posted on June 02, 2015 at 07:54 I am simply providing an implementation of _write() that forwards characters output to fd 1 to the the CDC device. With this, printf(), putchar(), fwrite(), etc. all work to the console. Obviously, if you also need file IO, you have to put in the code to handle other values of fd.

int _write(int fd, void *buf, size_t count) {
static int failed;
if(fd == 1) {
if(hUsbDeviceFS.dev_state != USBD_STATE_CONFIGURED)
return 0;
if(failed) {
if(CDC_Transmit_FS(buf, count) == USBD_OK) {
failed = 0;
return count;
}
return 0;
}
uint32_t timeout = HAL_GetTick() + 500; // 0.5 second timeout
while(HAL_GetTick() < timeout) {
if(hUsbDeviceFS.dev_state != USBD_STATE_CONFIGURED)
return 0;
int result = CDC_Transmit_FS(buf, count);
if(result == USBD_OK)
return count;
if(result != USBD_BUSY)
return -1;
// save some power!
__WFI();
}
failed = 1;
return 0;
}
return -1;
}