I have a project (STM32F407) Thumb Drive firmware update program questions

[VE7HR]

I have a project (STM32F407) that uses the Thumb Drive firmware update program based on the ST code

 * @version V1.0.0

 * @date   28-October-2011

Two questions:

1)Is there a newer version we should upgrade to?

2)What is the maximum thumb drive size? Smaller thumb drives are harder to get and we seem to have problems if hey are bigger than 4 GB. I have been unable to find any documentation saying what sizes will work.

Thanks

Dave

[waclawek.jan]

If this is the Standard Peripheral Library (SPL)-based code, then you may want to have a look at https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-standard-peripheral-library-expansion/stsw-stm32046.license=1565900896985.product=STSW-STM32046.version=2.2.1.html

I came across three factors why thumbdrives working on PCs did not work with STM32

• formatting in exFAT, which is quite likely to occur on newer and larger thumbdrives (mainly because of FAT32's single-file-size limit). The fat_fs library used in ST's examples is taken from elm-chan, and it's an older-than-current version not supporting exFAT. Newer versions do support exFAT; do your reading, fat-fs has a reasonably well defined interface so it should be relatively easy to upgrade
• partitioning in other than the "traditional" MBR partition - particularly, I've come across https://en.wikipedia.org/wiki/GUID_Partition_Table
• thumbdrives which are not a single plain USB device, e.g. compounds with an embedded hub (e.g. when including fingerprint sensor)

JW

[VE7HR]

Thanks Jan,

Project is not Cube based so we will have to look at that.

I think you are right about fat_fs only handling the old version of Fat32 which is limited to 4GB.

Thank you.

Dave

[Tesla DeLorean]

FAT32 is NOT limited to 4 GB, most SD cards use FAT32 up to 64 GB

What's a consistent problem with ST's SPL era code is *their* insistence in representing block numbers via *byte* address, and the constant translation between the two forms, and precision loss / truncation that occurs.

FatFs supplied by ST (0.12 as I recall) has issues with ExFat observable on 200 and 400 GB volumes, whereas 0.13 does in fact take such volumes in stride.

[VE7HR]

Thanks Clive,

Our bootloader is using

FatFs - FAT file system module R0.07e (C)ChaN, 2009 which I guess is pretty ancient.

My observations is that if I use a thumb driver smaller than 4 GB this works, larger does not.

We have a a bunch of units in the field with this bootloader.

For subsequent production we will have to look at something else.

Our code is 5 years old and was not developed using Cube32.

Dave

[Tesla DeLorean]

I'm not using CubeMx, and neither is Jan

The 4GB limit is using 32-bit byte addressing. Watch what they are doing with the SCSI READ10/WRITE10 commands, and READ CAPACITY

32-bit LBA (Logical BLOCK Addressing) is good to 2TB with 512-byte blocks.

ST's approach had been to use byte addressing, rather than fix that they moved to 64-bit byte addressing (uint64_t) but frequently forgot to implement casting correctly/appropriately. This, as stated before, is wholly unnecessary, as the BLOCK device use BLOCK addressing, as does FATFS as it was designed to be a BLOCK file system. ST got lost is some NAND/NOR memory paradigm, and frequently kept falling over their own shoelaces despite repeatedly being told what was broken.

If the old STM32F4-DISCO FW-Upgrade example (using USB memory sticks) doesn't support >=4GB it would be sad, but a very short walk to functionality.

SD Cards were a bit more complicated as the SDHC cards (> 2GB) had a slightly different command set.