Skip to content

ioc broken, watch out, CubeMX regeneration will clobber spi.c and gpio.c #4

Description

@Abraxas3d

firmware: .ioc clobbers hand-tuned SPI4 and GPIO settings on regenerate, do not regenerate

The sic_receiver.ioc file does not contain the hand-tuned values that spi.c and gpio.c need. Running "Generate Code" in STM32CubeMX will silently overwrite both files with CubeMX defaults, and silently delete the explanatory comments documenting the choices. This happened on May 9 and required a full revert. Yuck.

Until fixed: do not run "Generate Code" from CubeMX on this project. CubeMX is designed for initial scaffolding, not for living projects with peripheral settings tuned beyond what the .ioc graphical config can express. It silently overwrites peripheral init code outside USER CODE blocks, and the .ioc-vs-code divergence is invisible without diffing.
Fix: open .ioc in CubeMX, walk through SPI4 and GPIO settings, restore each value above. Save. Generate Code. Verify diff against the current hand-tuned spi.c and gpio.c. They should be byte-identical except for whitespace. Commit the cleaned .ioc and regenerated files together.

Defensive comment already in place (gpio.c line ~76):

GPIO_InitStruct.Pull = GPIO_PULLDOWN;  // FPGA_DONE - pull low when unconnected
//GPIO_InitStruct.Pull = GPIO_NOPULL;  // original line from CubeMX

Same pattern recommended for spi.c when the cleanup happens. Keep the CubeMX default as a commented line beside the hand-tuned value, so future ORIons can see what CubeMX would regenerate to.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request
No fields configured for Feature.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions