2019-12-13 07:38 AM
Virtually the same test code is working on a Discovery 469. I have tried to increase the stack and heap which didn't help.
2019-12-13 09:20 AM
mkfs should be the last thing you do after everything else works, cards shouldn't need formatting.
Pull-up on data/cmd lines at socket?
Turn OFF hardware flow control on F405 parts.
Instrument DISKIO layer to understand interaction and failure.
2019-12-16 08:42 AM
I tried not reformatting (no mkfs) and went from the mount to mkdir, got the same error. I have checked our hardware and also tried the same on another pcb with a 407 part, same results. However the Discovery 469 always works, and allowed me to continue working on the balance of the project. Others have mentioned issues with the CubeMX generating bad code, could this be the reason? By the way, there are pull-ups, andthe hardware flow control is OFF.
2019-12-16 09:06 AM
I don't use CubeMX, forum traffic suggests it is a train wreck half the time, and I already know how to write working software.
2019-12-17 12:12 PM
if CubeMX generates trash, what's next? I don't have an answer, what software is needed if you don't use it? I need the Fatfs to work with the STM32F405 in my project. I have even tried to go backwards to the IAR ide using the HAL libraries, nothing but errors. Can I use the old standard libraries?