Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32


Reinitialize SD CARD once disconnected from the system

Hi to all!
Does anyone know how to reinitialize SD CARD communication after removing it during write/read operations?
The communication is implemented using SPI.

These are the commands I’m using:

Mount drive:
tmpFileResult = f_mount(argFatFs, “”, 1); // 1 = mount now

Open file for writing:
tmpFileResult = f_open(argFileId, argFileName, FA_WRITE | FA_OPEN_ALWAYS | FA_CREATE_ALWAYS);

Write record:
tmpFileResult = f_write(argFileId, argString, strlen(argString), &tmpBytesWrote);

Close file:
tmpFileResult = f_close(argFileId);

Un-mount drive:
f_mount(NULL, “”, 0);

If I extract the CARD during the operation I get an error (I check tmpFileResult variable) then I call the following to reinitialize the CARD access:
f_mount(NULL, “”, 0);

But it seems not enough...

Thanks in advance!

:-)

TLDR: Your SD FAT table and/or files are likely trashed. You will have to either reformat or use a disk-rescue tool to try to fix it.
=====
I presume:
1. From your post it looks like you are using an SD card with a FAT file system.
2. You (intentionally?) remove the SD card during a write operation.

The FAT file system is easy to corrupt if you don’t terminate writes cleanly.

When writing data to a file, you may be either appending or overwriting data (hard to tell from your post, but I believe you are appending.

In order to append to a file in the FAT system, during a write operation the operating system (linux) must locate the end of the data for the file, from information contained in the file system table (e.g. DOS MBR). That info gets the OS to the start of the chain of sectors in the file. That same table contains information about the total bytes used in the file, its create/mod date, access rights, first and last sector, etc.

A series of steps (this is a gross simplification) then takes place:

1. The OS checks if there is space in the last sector, and if so, begins writing at the first unused byte, and writes until either the sector space or the data runs out.

3. If the OS runs out of space in the current sector, the OS grabs a sector from the available sectors list and writes as much data as can fit. If all of the data won’t fit, the OS grabs another sector, chains it to the first, and repeats. These sectors ARE NOT YET part of the file, but are in a detached temporary chain of sectors.

4. Once all of the data is written, the OS chains the current “last sector” for the file to the temporary chain of sectors.

5. After attaching the chain, the OS (a) updates the file system table with the new file size, (b) updates the last sector (if any were added to the file), (c) updates modification time, (d) possibly more depending on the file system.

At this point the high-level portion of the OS is satisfied and from its perspective, the file system is stable....

However...

An SD card (and flash memory) is NOT really a standard hard disk. It just pretends to be, sometimes via a hardware controller, sometimes via an OS module that handles the details.

Flash memory cannot be easily overwritten. In its erased state, the bits are usually ‘1’. You can change bits in nearly every byte to a zero easily. But to change a bit from 0 to 1, you must first erase an entire block of the memory, forcing all of the bits to 1, and then you overwrite the block with the new data.

The OS is unaware of this if the flash has a hardware controller, but if there is an OS module, the OS won’t consider the file system fully stable until the low-level flash stuff finishes.

In the flash, you can’t just erase a block without saving the data before erasing it. You could store it in RAM, but if power dies, you lose data. Instead, the flash controller COPIES the existing data WITH THE UPDATES to another block, and chains the new block in place of the old block, and only then puts the old block on the list of available blocks. The controller can either erase the old block now, or erase it when it is to be used again.

The problem is that if you pull out the SD card at ANY time during the OS updates or the flash controller updates, you have no idea where the process was. You may have interrupted the write in any of the OS steps above, or you may have interrupted the flash controller while it is doing the low-level work.

In your case, it looks like the file system table was corrupted. When that happens, Linux will refuse to mount the drive. Your only options are the TLDR ones: Format or use a disk checker/fixer.