CubeMX2 does not generate the SBS_PMCR pin-remap write for remapped ADC channels + Workaround
Product: STM32CubeMX2 (.ioc2)
Version: generic Linux 1.1.0
Appeared with MCU: STM32C542CCU6
HAL package: stm32c5xx_hal_drivers 2.1.0
Project type: CMSIS-Toolbox / CMake generation
Summary:
On STM32C5, four ADC1 external channels (IN2, IN5, IN6, IN7) have an alternate GPIO pad selectable via the SBS_PMCR pin-remap bits (ADC1_IN2_REMAP -> PC4, IN5_REMAP -> PC5, IN6_REMAP -> PB0, IN7_REMAP -> PB1 on STM32C542). CubeMX2's pin configurator lets you assign the remapped pad in the graphical pinout, accepts it, and generates both the GPIO analog-mode config for that pad and the ADC channel/sequencer configuration for the channel. However, it never emits the corresponding SBS_PMCR remap-enable write. The generated firmware therefore samples the default (non-remapped) pad, while the pin the schematic actually uses is left unread.
There is no generation warning, no build error, and no runtime fault. The ADC returns a stable, plausible, but wrong 12-bit code.
Reproduction:
1. Assign ADC1_IN7 to PB1 in the CubeMX2 pinout (the UI only permits IN7 for PB1).
2. Generate the project.
3. Result: mx_adc1.c contains the channel-7 config and the comment "PB1 ------> ADC1_IN7 ------> “pin_label", and PB1 is configured as analog. No SBS_PMCR / ADC1_IN7_REMAP write is emitted anywhere in generated/.
4. Grepping the entire generated/ tree for PMCR, IN7_REMAP, or EnableADCChannelPinRemap returns nothing.
We confirmed the SBS remap is the root cause on hardware: adding a manual SBS_PMCR.ADC1_IN7_REMAP write (after enabling the SBS clock) before the first conversion makes the channel read PB1 correctly.
Enabling the SBS peripheral component in CubeMX2 does not fix this: after regeneration CubeMX2 emits mx_sbs.c/.h and the HAL_RCC_SBS_EnableClock() plumbing, but still does not generate the SBS_PMCR.ADC1_IN7_REMAP write. The bug persists unchanged whether SBS is enabled or disabled.
Manual workaround in application firmware:
RCC->APB3ENR |= RCC_APB3ENR_SBSEN;
(void)RCC->APB3ENR; /* ensure clock is up before the write */
SBS->PMCR |= SBS_PMCR_ADC1_IN7_REMAP;
Requested fixes:
1. When a pin assignment uses one of the SBS-remappable ADC channels (IN2/IN5/IN6/IN7 on STM32C542, presumably the same set family-wide), CubeMX2 should generate the corresponding HAL_SBS_EnableADCChannelPinRemap() / SBS_PMCR write in the ADC init path, the same way it already generates the GPIO analog-mode config for the remapped pad.
2. If that codegen path is intentionally out of scope for this release, please at least fail loudly: a generation warning or a commented stub for remapped-pad ADC assignments, consistent with how CubeMX2 already leaves HAL_ADC_SetConfigChannel() calls commented out with an explanatory note in the same generated file. Silent wrong output is the worst outcome here.
Related issues found in the same code path:
3. The ADC PCSEL register is never configured by generated code. HAL_ADC_SetConfigChannel() is emitted commented-out in mx_adc1_init() ("information missing in CubeMX2 interface"), so the per-conversion call at the application level runs after ADEN=1, when PCSEL is no longer writable and the write is silently dropped. This is a separate config-generation gap worth closing at the same time.
4. Stability: enabling the SBS peripheral component added a driverConfigurationId reference with no backing configuration payload. CubeMX2 then failed to fully load the project - the peripheral configuration form hung indefinitely on "Loading the form..." and could not be disabled through the UI, surviving a restart of CubeMX2 and the host. Recovery required manually editing the .ioc2 file to strip every reference to the orphaned SBS driver entry across its embedded config stores.
