STM32G431 Bootloader issue

[KJeps.3]

Hi,

I have a problem with a custom board, where i can not enter bootloader, on some boards...

I had a production where around 10% has this issue. (I did not see it on earlier production of 5pcs).

The problem is the cube programmer will not enter bootloader mode.

I use a autodirection rs485 tranciever (5V on FT pins) and it is working on many of the boards with no problem, also the in-application code works fine for modbus (also on the bootloader broken devices, after programming with ST-Link)

I am using a FTDI USB to RS485 converter.

The boot pin is held up by a hall sensor and inverter transistor, i have noticed these sensors has different startup time 50-100ms - therefore the MCU reset pin is controlled by a rather slow RC circuit, to ensure boot is high before reset is released. (this is a litle risky).

However, i can see on the current consumption when it goes into application mode or assumed bootloader mode, as in bootloader mode the current stays much lower.

I can see on the RX pin of the tranciever it recieves the 0x7F from cube programmer and i can measure it close to the MCU pin (UFQFPN). But there is none answer from the MCU on TX pin.

Remember the communication is working without errors in application mode, also only with autodirection.

I have tried to short the boot0 to 3V3 with same result, i have tried to have long and short reset pulse time, same result...

I have sometimes managed to get the failing board to enter the bootloader, and then it does it several times in a row, but will stop work again.

I have tried to run the PC of battery, short the pc and lab psu together to ensure common mode voltage, but the recieved signal out of the tranciever looks good, and equal to a working device, i calculated baudrate/timing and it was ok...

I have chatted with AI during the process and asked it to make a summery there is below.

There is added pullup between pin 2 & 3 on the rs485 tranciever 10K.

I really do find this strange, i have been thinking about noise on pins there keeps the bootloader IRQ too busy.. but have not seen such thing.

I have not changed any options bytes, i have checked the Boot1 flag and the SWboot flag, not changed and seems correct. 

There seems no glitches on the supply lines.

Boards are produced by JLC, could there be counterfight chips?

I have worked with STM MCU for many years, but this issue seems new to me...

I hope you can give me some hints

Thanks

AI content:

STM32G431 UART Bootloader (RS485) – Intermittent No-Response on 0x7F (4/40 boards)

🧩 MCU / Setup

• MCU: STM32G431KNU3
• Interface: UART bootloader via RS485
• Transceiver: MAX13488
• Baudrate: 9600
• Boot mode: BOOT0 = HIGH (forced to 3.3V)
• Reset: external NRST pin

:magnifying_glass_tilted_left: Problem Summary

Out of 40 identical boards:

• ~36 boards: bootloader works reliably
• ~4 boards: bootloader does NOT respond to 0x7F
• Same failing boards can sometimes work after repeated resets

:satellite_antenna: Observations

UART signal

• 0x7F waveform verified on MCU RX pin
• Clean edges (fast rise/fall)
• Low level < 0.5V
• High level ≈ 5.0–5.2V (pin is 5V tolerant)
• Minimal ringing observed

Timing

• Measured ~832 µs from start bit to end of 7 data bits → matches 9600 baud
• No baud mismatch observed

Behavior

• MCU does enter bootloader mode (verified via current consumption):
  • ~6–7 mA in bootloader
  • ~15 mA in application
• However:
  • No response to 0x7F (no ACK) on failing units

:repeat_button: Reset / Boot Experiments

Tested:

• BOOT0 tied directly to 3.3V → no change
• Removed reset capacitor → NRST via 100k pull-up → no change
• Verified BOOT0 is stable before reset release
• Reset pulse manually applied → sometimes enables successful connection

Observations:

• Reset timing influences success rate
• Behavior is non-deterministic per reset

:electric_plug: RS485 / Hardware Details

• RS485 auto-direction enabled via:
  • PB3 connected to TX enable control
  • 10k pull-up used to default direction
• Important:
  • PB3 is floating during bootloader (GPIO default state)
  • External circuit defines transceiver state
• Verified:
  • 0x7F passes correctly through transceiver
  • Signal integrity looks correct on both TTL and differential sides

:cross_mark: What has been ruled out

• Signal integrity issues (clean waveform)
• Baudrate mismatch
• BOOT0 instability
• Slow reset RC ramp
• Noise/ringing on RX line
• Incorrect pin mapping
• Firmware interference (bootloader mode confirmed active)
• GPIO conflicts / interrupts (boot ROM context)

:warning: Suspected Root Causes

Based on observations, likely candidates:

1. UART bootloader autobaud timing sensitivity

• Bootloader may miss or misinterpret first 0x7F
• Possible dependency on exact timing of first edge

2. UART RX enable timing in boot ROM

• First byte may arrive before UART is fully ready

3. RS485 transceiver direction timing

• Auto-direction may not be in correct state during first byte
• Potential subtle contention or delay not visible on scope

4. Internal clock (HSI) startup variation

• May affect autobaud measurement

:question_mark: Questions for ST

1. Is there any known errata regarding:
   • UART bootloader autobaud reliability on STM32G4?
   • Sensitivity to first byte timing?
2. How long after reset is UART guaranteed to be ready in system bootloader?
3. Is it required to delay sending 0x7F after reset?
   • If yes, recommended delay?
4. Does the bootloader retry autobaud if first byte is missed?
5. Any known interaction issues with half-duplex (RS485) setups?

🧪 Additional Notes

• Issue is reproducible on same subset of boards
• Boards are otherwise fully functional in application mode
• UART works perfectly at 9600 baud in user firmware
• No visible hardware defects