Full track recording is one of the nice-to-have functionalities of the CUBEs. The problem here, however, is that the SD card which is used to keep the data gets easily damaged as data flushes to the FAT filesystem cause considerably high wear, especially in the file allocation table (file size & last modification time). The latter could be avoided by disabling the last file updates time in code. Still, the file size and number of sectors allocated is updated every time a block is added to the file. Keeping the data in memory and flushing in larger chunks may seem to be obvious solution, but when taking the MCU’s RAM size of 20kB (while a lot is already allocated) and FAT sector size of 512B into consideration, one can see there is not much maneuvering space.
Hence, the LittleFS seemed to be the perfect solution. Power resilience and wear leveling make it an exact fit for this troubles until you realize its code base is over 4000 lines and make it considerably spacious after compilation – 8KB, even when forcing size optimisation and omitting unused routines in the compiler settings.
In combination with the pending problem of the rest of my code being already a tight fit into the F103CB’s 128kB FLASH (there is also a custom 8kB bluetooth boot loader for firmware updates), the size of resulting binary with LittleFS included has reached the point it does not fit into the program memory space.
Well, what now? There are two options. The first one is to use an F103 MCU with more FLASH like the STM32F103RB. The catch here, are its 64 pins on the larger footprint while the current PCBs is layed-out only for 48 pins of the CB variant. And as I don’t really want to be redesigning the PCB at this moment another option seem to be quite feasible – to replace the MCU with another one. The nice thing with STM’s controllers is they tend to have compatible pinouts. And as I already have some supply of STM32F030CCs in my drawer (and have big plans with that one in another project), this one seem to be the right fit for replacement. It’s got 256kB of FLASH and 32kB of RAM (comparing to 20kB of the F103CB). Some of the libraries I use will have to be extended to support the F030’s architecture (ARM Cortex M0 vs. M3, the buses and peripherals are organised in a bit different manner) but it would keep the footprint small while opening the opportunities for further development! 🙂
But as things never can go easy, there is another problem. In the recent months the Standard Periperal Libraries (SPL) are for some reason not available for download for the System Workbench for STM32 (sw4stm32) and I cannot make it work even when downloaded them manually from the STM’s web. I have reported the problem on the openstm32.org forum already in two posts (the first, the second) with no success so far. Even the SPL firmware for the F103 doesn’t work now for me.
(Edit) I’ve eventually found a workaround. It’s crude, but it does the job! 🙂
(Edit2) Here you can find backup of all STM32 firmwares that were still available from the stm32targets.xml file.