Memory corruption caused by newlib-nano bug #6
Description
The firmware kept crashing due to memory corruption in log_write() until I disabled logging. Now I've enabled logging and investigated the issue:
If a floating-point number format format (such as %f) is used and newlib-nano is compiled with floating-point support (FLOATING_POINT is defined) but is used without printf support for floating-point numbers (like this project does), _svfprintf_r() (which is called by vsnprintf() etc.) will add the value of uninitialized variable n to the variable accumulating the number of output characters for the return value. The result is that the return value of vsnprintf() will be a random number which is most likely quite positive or quite negative.
log_write() adds that value to the number of characters written (variable "written"), which will become negative or quite big and in consequence will make the final snprintf() call write to some random location. Also, code following that call using "written" will break.
There's probably no point in reporting this issue against newlib-nano-1.0 or newlib-nano-2 as there has been no activity for a decade. Maybe I manage to report this issue to ST.
Enabling floating-point support for printf() in the project properties fixes the problem.