VL53L8CX firmware consumes most of the STM32 flash

[Mostafa1]

Hello,

I am currently working with an STM32 MCU equipped with 128KB of flash memory, alongside the X-NUCLEO-53L8A1 Time-of-Flight expansion board featuring the VL53L8CX sensor. It has come to my attention that the sensor's firmware, as defined in vl53l8cx_buffers.h (here)  within its drivers, occupies a substantial 84KB of flash memory. This firmware array is written each time the sensor is initialized. I am seeking guidance on potential methods to bypass or optimize this process to conserve memory for my application. Any insights or recommendations from the STM community would be greatly appreciated. 

[TDK]

You can try compression algorithms that have little overhead, or you can buy a chip with a larger flash.

https://blog.segger.com/smash-an-efficient-compression-algorithm-for-microcontrollers/

Might want to ZIP the firmware on a computer to see how much it can compress at all.

[John E KVAM]

When we built the chip, we realized that 84K of flash would be a problem for the smallest of the STM32s. Our main target was the cell-phone and PC markets, who have no such limitation. So you are kind of stuck. I'd calculate the tradeoffs between a larger STM32, an external EEPROM or as TDK suggests - a compression algo. There are a lot of zeros in the code so the compression might help, but the rest is binary code so I'm not sure about how much that will compress. 

If you try the compression, post how well it works. Maybe I can get the chip designers to try it.

- john

[Mostafa1]

Thanks for your replies,

I have tested emCompress tool and here are the results:

emCompress-ToGo Compression Utility V3.32a compiled Jun  7 2022 14:50:43
Copyright (c) 2015-2019 SEGGER Microcontroller GmbH    www.segger.com

Statistics:
  Original:     86016 bytes
  Compressed:   72630 bytes, or 84.44% of original
  Saving:       13386 bytes, or 15.56% of original
  Standardized: 6.76 bits/byte

So basically it went down from 84KB to 70.9KB.

I have also tested 7zip on Windows and got better results, around 60KB (not sure about the complexity to be decompressed on an STM)