CRC in sector of a usb pendrive
While several file systems-- such as ZFS, UBIFS, HAMMER, Btrfs, etc.  -- do use CRC or other checksum, my understanding is FAT32 does not use any CRC or checksum.

So when you write code for your microcontroller that stores files in FAT32-compatible format on a pen drive, you don't need to calculate a CRC or checksum.

The microcontroller inside the pen drive calculates the CRC for you when you write to a sector, and checks it for you when you read a sector.
My understanding is that all modern rotating-disk drives and sata SSDs and pendrives do use internal proprietary error-detection-and-correction information.
That information is used internally by the microcontroller in those devices.
However, that information never leaves those devices.
That EDAC information is stored outside the data sectors,
and can't be read by the main CPU -- you'll never see that information.
Manufacturers have the freedom to switch to an improved wear-leveling and EDAC system internally, and still present the same interface to the main CPU.

The SATA interface and the Ultra DMA PATA interface and the USB interface use CRC to detect errors in data transfer between the drive microcontroller and the main CPU -- but that CRC information is generated on-the-fly by the transmitting CPU, and is not actually stored on the media.

Which one of the following will work best for your application?:


implement FAT32 alone, and rely on the microcontroller inside the pen drive to handle EDAC.
implement FAT32, and store the data in a file format that includes checksums to detect errors -- such as the ".ZIP" file format. (There is an "uncompressed" option that simply stores the raw data and the checksum).
implement FAT32, and with each file "filename" also store a very small corresponding digest file (a kind of checksum) -- a "filename.sha" that sha256sum can verify, or a "filename.md5" that md5sum can verify. (md5deep can verify either kind of digest). To detect errors.
implement FAT32, and with each file or group of files also store parity files such that Parchive can detect any errors, and also (if it's not too badly corrupted) repair them.
implement some other file system with a built-in checksum or CRC.
implement FAT32, and store each file on two physically separate pen drives that should always contain exactly the same data.