Behavior of PB15 During First Boot: CC2 Dead-Battery vs. SPI2_MOSI (STM32G071CBU6)

HKet · ‎2025-11-30

Hi,

On STM32G071CBU6, when PB15 is used as CC2 with DBCC2 shorted to CC2, does the ROM bootloader ever drive PB15 as SPI2_MOSI, or does the CC/dead-battery own the CC2 pin and that path always takes priority?

This detail is critical for our design because the device is bus-powered and relies on the dead-battery path to manage initial power-up. If the bootloader were to override PB15 and drive it as SPI2_MOSI while the flash is blank, it could cause a power drop when the ROM bootloader starts.

I checked the datasheet, reference manual, programming manual, and bootloader manual, and none of them explicitly state how the ROM bootloader handles SPI2_MOSI when that pad is also CC2 with DBCC shorted.

Could you please clarify?

Thanks

mvduin · ‎2025-11-30

MOSI is never driven by the bootloader since the SPI peripheral will be in slave mode and therefore MOSI is an input.

(But I don't know whether the 5.1k pulldown will remain engaged. Also be mindful that PA10 will have internal pull-up configured, although it is considerably weaker so perhaps not a problem.)

HKet · ‎2025-11-30

I understand that MISO would be an input because the bootloader uses SPI as a slave, but the MCU’s internal pull-down is 40 kΩ while CC requires a 5.1 kΩ Rd. With a 40 kΩ pull-down, the CC voltage would be higher and the host may not detect Rd which would mean no power.

Also, thanks for pointing out PA10. I hadn’t noticed that it has an internal pull-up. That would keep the CC voltage also high and again prevent the host from seeing a valid Rd.

These points assume SPI overrides the dead-battery function, but I’m not sure whether the dead-battery pull-downs and the GPIO pull-ups/downs can operate at the same time, or if only the dead-battery circuitry or only the GPIO takes control.

But if the bootloader really takes control of the CC pins, UCPD1 dead-battery mode should not work at all.

mvduin · ‎2025-12-01

@HKet wrote:
Also, thanks for pointing out PA10. I hadn’t noticed that it has an internal pull-up. That would keep the CC voltage also high and again prevent the host from seeing a valid Rd.

Whether or not the 25-55 kΩ pullup to 3.3V in parallel can cause problems depends on various factors including the precise electrical characteristics of the CC pin when its 5.1kΩ pulldown is activated, and I haven't been able to find those specified in the datasheet (unless I simply overlooked it). If I assume it's 5.1kΩ ±10% (required by USB-C spec to do source current limit detection) then the worst case would be

5.1 kΩ +10% (= 5.61 kΩ) pulldown
25 kΩ pullup to 3.6V (max allowed VDD for the STM)
330 μA +8% (= 356.4 μA) pullup by the USB-C source

in parallel, which (if I didn't mess up the math) yields a voltage of 2.29 V on the CC pin which is still inside the "vRd" limits (0.85 V - 2.45 V) for the source to detect an attached sink. However, it is definitely above the highest voltage a source will normally ever see in practice with a spec-compliant USB-C device attached (which is 2.18 V) so you'll need to hope the source isn't equally sloppy with spec-compliance.

And all this is of course still conditional on whether the 5.1k pulldown remains active.

Also, does your device have a USB-C receptacle or does it have a fixed-attached USB-C cable ("pigtail") ? Since if you have a receptacle then you need both CC1 and CC2, and DBCC1 (PA9) is actively driven high by the bootloader so that would be a fatal problem.

Definitely the safer options would be to either use UCPD2 instead of UCPD1 (since its pins don't have bootloader conflicts) or avoid using the ROM bootloader for in-the-field firmware upgrades and e.g. use a custom bootloader instead.

HKet · ‎2025-12-01

The device features a USB-C receptacle, and I have both CC1 and CC2.

I performed some testing today, and the board powers up correctly and remains powered in both USB-C orientations. To simulate first time flashing on a blank device, I performed a mass erase. I am not sure if this is equivalent to a truly blank MCU out of the factory, but even after mass erasing, the board still powers up in both orientations.

This is where I’m confused: I can convince myself that when DBCC2 sees a high level, some internal mux could somehow block SPI ownership of the CC2 line, but I can’t explain how DBCC1 would take priority over USART_TX, especially when it is in pull-up mode (how does it detect this scenario?). Maybe it checks the voltage before enabling the pull-up? So what you mentioned about both the 25k pull-up and the 5.1k pull-down being active at the same time does make sense.

According to the datasheet, DBCC pins should either be grounded when UCPD is not used or shorted to CC when UCPD and dead-battery mode is required. In those two configurations, the bootloader using USART1 is effectively impossible (USART RX is either shorted to ground or to CC). The only remaining scenario is using UCPD without dead battery, in which case there seems to be no way to reserve CC1 and prevent the bootloader from taking it as USART_RX. That’s why I’m totally confused.

I can avoid using the ROM bootloader for in-field updates, but the MCU will still boot into the ROM bootloader the very first time when the flash is blank. If all of our assumptions are correct, then a blank, bus-powered device using UCPD1 with dead-battery support might only power up in one orientation (which isn't too bad) as the CC voltage would be marginal.

AScha.3 · ‎2025-12-01

Hi,

>Could you please clarify?

Whats on the pins, see in ds of cpu ; even before program or bootloader starts, pins can have a function,

here -> function upon reset :

+

If you feel a post has answered your question, please click "Accept as Solution".

FBL · ‎2025-12-01

Hello @HKet

This issue seems familiar !

Check this post Re: Gpio status during bootmode - STMicroelectronics Community . At first glance, it should be helpful/

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

mvduin · ‎2025-12-01

@HKet wrote:
The device features a USB-C receptacle, and I have both CC1 and CC2.

Then I don't see how this is going to work (when using UCPD1) since the bootloader will configure PA9 (UCPD1 DBCC1) as USART1 TXD which will drive it high, which will definitely overrule the 5.1k pulldown on PA8 (UCPD1 CC1).

I performed some testing today, and the board powers up correctly and remains powered in both USB-C orientations. To simulate first time flashing on a blank device, I performed a mass erase. I am not sure if this is equivalent to a truly blank MCU out of the factory, but even after mass erasing, the board still powers up in both orientations.

Are you sure the power source you're using monitors the CC pins and only supplies VBUS when it detects a sink attached, instead of just providing VBUS continuously? Officially the latter is only permitted as a result of using a legacy USB charger/port with a USB-A-to-USB-C cable and any proper USB-C power source (charger or USB port) is required to dynamically control VBUS depending on the CC pins, but I have no doubt some USB-C chargers will simply ignore the USB-C specifications and always power VBUS.

This is where I’m confused: I can convince myself that when DBCC1 sees a high level, some internal mux could somehow block SPI ownership of the CC1 line, but I can’t explain how DBCC2 would take priority over USART_RX, especially when it is in pull-up mode (how does it detect this scenario?).

The DBCC1/2 pins are only relevant while the STM is powered off, in which case >1V on a DBCC pin activates the 5.1k pull-down on the corresponding CC pin. If the STM then powers on, this state is latched and the 5.1k pull-down remains active until explicitly deactivated by software, the DBCC pin is no longer relevant at that point.

I don't know how the GPIO configuration interacts with the 5.1k pull-down, but control over that pull-down is completely separate from the GPIO configuration registers so it seems plausible that it may simply remain connected regardless of GPIO configuration.

In case of CC2 (PB15), if its 5.1k pull-down indeed remains enabled (instead of, or in addition to, the 20-55k pulldown on that pin configured by the bootloader via the GPIO config) then it will mostly override the 20-55k pull-up on DBCC2 (PA10 / USART1 RXD) that's connected in parallel (since they're externally tied together).

I can avoid using the ROM bootloader for in-field updates, but the MCU will still boot into the ROM bootloader the very first time when the flash is blank. If all of our assumptions are correct, then a blank, bus-powered device using UCPD1 with dead-battery support might only power up in one orientation (which isn't too bad) as the CC voltage would be marginal.

The CC2 voltage would be marginal, while CC1 will be driven to 3.3V, so it will work in only one orientation and even then be marginal. But if this is just for factory flashing, just use a USB-A-to-USB-C cable to power the device and it will work just fine since then the CC pins are simply ignored anyway.

HKet · ‎2025-12-07

I did some additional testing on the power-up issues we’ve been investigating.

On our prototype, the CCx pins were not initially shorted to their corresponding DBCCx pins. We were aware of this, but I didn’t bring it up earlier as we manually soldered CC2 to DBCC2.

However, we couldn’t easily fix CC1 by shorting the pins externally, as PA9 (DBCC1) was used as an output with an external pull-up on our board, and fixing it was a bit more difficult. Because DBCC1 is pulled high, the dead-battery pulldown is active at all times, and CC1 never sees the high level on USART TX, as they are not shorted. This explains why our board powers up in the CC1 orientation.

You might assume that our added pull-up wouldn’t take effect because the board wouldn’t be powered at that stage, but our external CC protection chip provides a short dead-battery power path that is enough to power the board during early startup, and as a result, the pull-up on DBCC1 is effective.

For CC2, however, I was able to short CC2 to DBCC2 externally, and here are the results:

The board powers up as expected, as also mentioned before.
To observe the interaction between the internal pull-up and pulldown from the bootloader, I measured the CC1 voltage when connected to a USB-C 3A source while in bootloader. Instead of the normal 1.68V, the voltage was 1.25V.

Initially, I suspected the pull-up and pull-down were somehow interfering with the voltage on CC2, but later I found that the STM32G071x8/xB errata explains this behaviour. According to the errata, during power-up and dead-battery mode, the internal Rd is 3.9K ±20% instead of the expected 5.1K.
Doing the calculation with a 3.9K pulldown gives 1.28V, which matches the measurement closely.

The CC voltage returns to the expected 1.68V once the SYSCFG strobe bit is set.

The workaround suggested by ST is essentially to apply the above approach within the first 100 ms of boot to remain compliant.

I am still curious to modify the board and short CC1 to DBCC1 as well. This would let us see the effect of USART1_TX, which might drive the pin high. It would be interesting to check whether the board still manages to power up in that case, which seems unlikely unless there is behaviour we’re not aware of yet.