cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0B1RCT6 HSE Bypass Mode - Intermittent Startup Issues

flawless
Associate II

Hi everyone,

I'm having an issue with HSE bypass mode on the STM32G0B1RCT6 and hoping someone here has seen something similar.

The HSE randomly won't start in bypass mode. I've tried two different oscillators - the S2D8.000000B20F30T and an OT32258MJBA4SL that I pulled from a working STM32F405RGT6 board where it runs without any problems.

The behavior is inconsistent. Sometimes it starts up normally and then runs solid. Other times it just won't set the HSERDY flag. We've tried both toggling the NRST pin and resetting from code, but neither changes the state - if it's working, it stays working, and if it's not working, it stays not working. Only power cycling the entire board can change the state in either direction, sometimes making a non-working board work or making a working board stop working.

On the scope, the signal from the oscillator is always visually fine.

Any ideas or suggestions for debugging this would be helpful!

39 REPLIES 39
waclawek.jan
Super User

In case the MCO indicates no HSE, can debugger be attached, and RCC and relevant GPIO registers observed?

I also wonder if the "intermittence" could be attributed to the default bootloader being run.

JW

1. Yes, checked that (set reset behaviour to "none", disabled elf download using debug configuration): HSERDY == 0, same as if I debug it normally.
2. It could be, but that way debugging it should show normal operation with HSERDY == 1. FLASH_ACR's EMPTY bit which can force bootloader start after reset, has 0 (main flash memory is used) value. Also, just to be sure, I tried setting BOOT_LOCK option - no changes. 

TDK
Super User

> 2. It could be

How could it be in the bootloader? Do you have BOOT0 pulled low or can you ensure some other way (option bytes) to ensure flash gets run. In any case you should eliminate that as a possibility.

Set an LED on before configuring clock and off afterwards to see where chip is at. Lots of other ways to do it, that's just one.

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

On this MCU BOOT0 pin is also SWD's CLK, so i thought for a second that there could be some weird interactions between my debugger and MCU. I did check that by setting BOOT_LOCK OB, just was editing the post to add that.

Satty
Associate III

Wow, that's really strange: if I change BOOT_LOCK (either set it or reset), HSERDY goes high but just until i cycle board's power. Even core reset doesn't do that. Actually, that works with any OB change (e.g. BOR enable option). For changing OB & checking RCC register's values I'm using CubeProgrammer.

Satty
Associate III

Thank you all, that actually wasn't a hardware or software problem:
We use Siglent SPD3303X-E as power supply which apparently has some sort of soft-start feature. It's slow voltage rise (~10 ms) is somehow breaking MCU's internal startup procedure which results in HSE beeing locked up (idk how exactly). The fact that reset can't fix it (except for OB launch one) is still very unusual, but I don't think there is an easy answer I can find. 

The behavior you describe with HSERDY not getting set, does it happen on a powerup when BOR is enabled? Does setting BOR to the highest level (4) fix the issue?

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

Interesting.

In DS, there's no limitation for the maximum VDD rise time (nor for the minimum, for VDD rising).

I have the same question as @TDK above: does BOR setting influence this behaviour?

JW

flawless
Associate II

I'll answer because my colleague @Satty has issues login in, it says he's banned for some reason.
@TDK @waclawek.jan We tried different BOR levels but it doesn't help. 
We think this isn't solely a power supply issue. Connecting it directly to MCU's 3.3V rail didn't resolve the HSE startup problem. But in case of using wires to close the circuit instead of power supply channel output enable button, HSE starts reliably. This approach doesn't help if used on main power rail (12V) which implies that it actually is some kind of power timing issue.

waclawek.jan
Super User

Make sure *all* VSS and VDD  (including VSSA/VDDA) pins are connected properly. Measure continuity directly at the pins (think of bad solder joints).

How is VDDA connected? And what about VBAT?

JW