STMCube bug report in GPIO produced code/essential function

[Osto]

Posted on April 30, 2015 at 00:56

Hi ST,

when there is a peripheral with active low signal, need to pullup the signal to be sure that its in defined state during power up until the software can warranty the correct usage.In such cases, the whole Cube is absolutley unuseable. The reason is that he code generated by cube inits the GPIO with zero values. The peripheral will go on because of low active state.Its needed to define the reset value in Cube to load the ODR with default value before the GPIO is initialised. Right now, I see no usage for Cube if there are active low devices connected to the system.Regards,Osto

[childresss]

Posted on April 30, 2015 at 01:59 YES. For this, CubeMX needs (high priority) Each GPIO output bit needs a default state: 0 or 1 to be asserted as quickly as possible. Without it, hardware has to have a pullup or pulldown resistor. Alas! Due to the below, the resistors are essential to avoid glitches. ================================================ Compound this problem, and this is a PITA for my projects: the time to clear BSS (static RAM buffers/variables) is many mSec. Can be 10's of mSec for large static buffers. This code runs at 16MHz by hardware design of the core. It runs before any CubeMX generated code runs. My work-around for this is to code in the linker script commands to DO NOT initialize BSS. Compiler pragmas to attribute no-initialize on a per item basis - not reliable. If C++, it gets much worse, with the time for ctors to run. Programmers' caveat: never assume variables/buffers are 0'd by magic.