what is wrong with the file system on stm32f411?

[rwmao]

Posted on January 16, 2017 at 00:45

I have two boards designed for stm32f405 and stm32f411 to test uSD card.

The problem of using uSD on STM32F405 was fixed as discussed earlier:

https://community.st.com/thread/35991-microsd-card-problem-bug-in-the-filestm32f4xxhalsdc

Reading file/writing file are totally fine withut any problem on the STM32F405.

Then I study the another board with a chip stm32f411ret6. These two boards are very similar because these two chips has very close pin configration.

Here is what is going on on the board with the chip stm32f4

I generated the code with cubemx, copy the testing code, and fixed the bug in the file mentioned above.

Low level io writing/reading has been tested. Pass!

Can I say that hardware problem (such as connection)is out of question?

But when I try to use file system to read/write file, there is an error in the line:

fmt = check_fs(fs, bsect); /* Load sector 0 and check if it is an FAT boot sector as SFD */

returns FR_DISK_ERR.

Tried two sd card, 1g and 32g. Both works on the board with chip stm32f

What is wrong? Any instructions please.

The code for reading/writing testing is as followings

void SD_Test_LowLevel(void) {   uint8_t SD_state = MSD_OK;  static uint8_t prev_status = 0;   char usbbuffer[200]; SD_state = BSP_SD_Init();    if(SD_state != MSD_OK)  {  sprintf(usbbuffer,'\n---initialize failed ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   Error_Handler();  } //initialization is done. Now go ahead for SD operation in low level      SD_state = BSP_SD_Erase(BLOCK_START_ADDR, (BLOCKSIZE * NUM_OF_BLOCKS));    if(SD_state != MSD_OK)  {  sprintf(usbbuffer,'\n---erase failed ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   Error_Handler();  }    /* Fill the buffer to write */  Fill_Buffer(aTxBuffer, BUFFER_WORDS_SIZE, 0x22FF);  SD_state = BSP_SD_WriteBlocks(aTxBuffer, BLOCK_START_ADDR, BLOCKSIZE, NUM_OF_BLOCKS);    if(SD_state != MSD_OK)  {  Error_Handler();  } SD_state = BSP_SD_ReadBlocks(aRxBuffer, BLOCK_START_ADDR, BLOCKSIZE, NUM_OF_BLOCKS);  if(SD_state != MSD_OK)  {  sprintf(usbbuffer,'\n---reading failed ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   }  else  {  sprintf(usbbuffer,'\n---Reading OK ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   if(Buffercmp(aTxBuffer, aRxBuffer, BUFFER_WORDS_SIZE) > 0)  {  sprintf(usbbuffer,'\n---reading/writing compare failed ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   }  else  {  sprintf(usbbuffer,'\n---Testing is done, OK ---\n');//export it to char buffer first.   SendTextMsgToUSB(usbbuffer); //send the txt back   }  }  GREEN_LED_ON;//Good while (1)  { } }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

#stm32f411 #sdio #stm32f405 Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on January 26, 2017 at 19:41

My guess would be it is still running at 16 MHz then. If the PLL isn't running the SDIO won't work at all.

Thought it was a 16 MHz HSE, will fix that.

[rwmao]

Posted on January 26, 2017 at 22:46

Clive,

But USB is working well, which share the same 48MHz.

Let me ask you a weird question

I have a working project for F405 which works well for uSD card, can I copy the whole project and revised it to use F411 chip. If I can do that, which files shall I replace?

Thanks

[Tesla DeLorean]

Posted on January 27, 2017 at 04:44

I modified the system_stm32f4xx.c file so that it would detect the core and set up the clocks and flash wait states optimally.

I updated the code for HSI

https://drive.google.com/open?id=0B7OY5pub_GfIeVFRQlBTU0k0TE0

[rwmao]

Posted on February 02, 2017 at 20:06

Hello Amel,

Thanks for your reply.

Please find the attached two files.

The pin configurations for two chips are slightly different. As discussed earlier, they share the same board with option of jump wire. Anyway, the hardware problem has been excluded.

The F405 project was created slightly earlier. I can't remember the version of the cubemx. By checking the version of hal file, I try to switch back to use same cubemx on F411 chip.

As you said, F405 chip shares same lib with F4 I tested in my code. Please note that the F411 chip works well for Writing/Erasing of blocks. But it can't read.The problem might be in the configration.

If it is possible, would you please ask your cubemx team to

generate a sample code for F411RET6 chip with the same pin configration as that in the attached file

. Therefore I can test if it works in my board to figure out the problem of sdio.

One more question related. As you mentioned earlier on the top of the thread. I use the same board for both chips with jump option such that two chips can have different pin configuration of sdio. I got one more testing. I use exactly same pin configuration forF411 chip with that of F In practice, SDIO then uses same pin configuration. Then I got back the source code and

update the pin assignment in hal_map file to reflect the change without updating iot file

. Is that a problem? The result is that it fails at power_on. I guess if pin configration has been changed, I need to do change somewhere else in additon to the hal_map file. So what else to change?

Thanks

________________ Attachments : iot.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyxX&d=%2Fa%2F0X0000000bEP%2FBedeAy4zQ11Uek9KU49.Ss5icPyJFg.gDO2.QsnOf_I&asPdf=false

[stm32cube-t]

Posted on May 02, 2017 at 14:59

Hello you are using CubeMX 4.12. This is very old and uses old firmware as well, please consider upgrading your project to the latest CubeMX version.

[Tesla DeLorean]

Posted on May 02, 2017 at 17:14

It was newer four months ago....