TIM1 break flag (BIF) stays latched forever, MOE never sets — STSPIN32G0602Q

[Mathan Raja]

Hi,

Chip: STSPIN32G0602Q (STM32G031 core + integrated 3-phase gate driver)

Board: custom BLDC driver board, powered via 115VAC through an isolation transformer into the board's own AC input; the board's onboard PFC/rectifier stage converts this to the internal DC buses (HV+ ~400V DC bus, and VBUS ~50-120V DC, which is the rail actually switched by the MOSFETs under test)

Purpose of this test: end-of-line (EOL) production test — statically turning on one high-side MOSFET and one low-side MOSFET on different phases (e.g. U-high + V-low) for a short, controlled period, then checking output voltage/current, to verify each MOSFET pair switches correctly before the board ships. This is a functional pass/fail check, not normal motor operation — no continuous PWM switching or motor commutation is involved.

Problem: TIM1's gate outputs never turn on. Root cause traced to: BIF (break flag) is always set, so MOE can never be enabled.

What happens

1. I start a TIM1 channel (HAL_TIM_PWM_Start + HAL_TIMEx_PWMN_Start).
2. TIM1->SR bit 7 (BIF) is already 1 — even before I do anything else.
3. I clear it with __HAL_TIM_CLEAR_FLAG(&htim1, TIM_FLAG_BREAK). It comes right back to 1 immediately. I tried clearing it up to 1000 times in a loop — never stays cleared.
4. Because of this, __HAL_TIM_MOE_ENABLE() never actually results in MOE=1 (checked directly in TIM1->BDTR).
5. Result: the driver output pin never moves — it just floats.

What I already checked and ruled out

• PB12 (break input pin, = FAULT output of the driver): reads HIGH (healthy) every single time I check it, even at the exact same moment BIF=1. No visible problem at the pin itself.
• VCC (driver's 18V supply): steady 15V, confirmed with multimeter, even during the fault.
• Current sense signals feeding the comparator (CIN): checked with an oscilloscope at both slow and fast timebase — steady ~220-230mV, well below the ~460mV fault threshold, no glitches or spikes.
• TIM1->AF1 register: only BKINE/BKINP are set (external pin enabled, active-low). Comparator break sources are 0 (this chip has no comparator hardware anyway).
• TIM1->EGR (BG bit): 0 — not a software-triggered break.
• BKBID / BKDSRM / LOCK bits in BDTR: all 0 — not a bidirectional-mode or lock issue.
• PWR->CR2 (PVDE bit): 0 — voltage detector is not enabled.
• CSS (clock security): not applicable, I'm running on HSI+PLL, not HSE.
• Official errata sheet (ES0487, STM32G031x4/x6/x8): no matching issue listed.

My question

I've ruled out every break source I can find in the reference manual. The pin itself always looks healthy when I check it, but BIF won't stay cleared no matter what.

Is there anything about the STSPIN32G0602's internal FAULT-to-PB12 connection that could cause a break condition too brief to see on a slow multimeter check or a paused debugger snapshot, but persistent enough that TIM1 always re-detects it? For example: an internal UVLO edge case, internal filtering/latching behavior on the FAULT line, or a known power-up sequencing issue between the driver section and the MCU core?

Or does this look more like a defective/damaged individual unit rather than something explainable by configuration?

Happy to share scope captures, schematic excerpts, and register dumps if useful.

Setup: STM32CubeIDE, HAL drivers, TIM1 at 128MHz kernel clock, center-aligned mode, ARR=1599. Channels are configured in CubeMX as "PWM Generation CH1/CH1N" etc. (this sets up polarity, dead-time, CCER, and break config correctly via HAL_TIM_PWM_Init/ConfigChannel) — but after that init, I directly overwrite the OC1M/OC2M/OC3M bits in CCMR1/CCMR2 at runtime to force each channel to a static active/inactive level (0x5/0x4), instead of using PWM duty cycle. This is done to statically hold one high-side + one low-side MOSFET on for an EOL functional test, and to avoid the known center-aligned-mode CCR=ARR edge case. The break/MOE issue described above happens regardless of whether the channel is left in plain PWM1 mode or switched to forced mode — I've confirmed both behave the same way.

[rich.g.williams]

What you could do is, instead of going through TIM1, you could set the output ports used to control the high-side MOSFET and one low-side MOSFET test as normal GPIO outputs and use a simple test loop to toggle the output pins - easier than wrestling with TIM1 settings.

That’s based on what you say about only wanting to test your mosfets and that the production code is tested separately.

As a GPIO its easy to try with different output transition speeds and drive strength, even apply pull up or pull down resistor in the MCU or even use open collector.

Just an idea if it meets your test specs.

[Richard Li]

In AN4013 Rev 14 page 34 , it noticed:  “Break inputs Break1 and Break2 are not available on the original series.”

I am not sure your software used these break 1 and Break 2.

[Richard Li]

Attached AN4013