STM32G0B1RCT6 HSE Bypass Mode - Intermittent Startup Issues

[flawless]

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!

[waclawek.jan]

I'm not quite sure the HSERDY flag is to be expected to come up, when using HSE bypass mode.

HSERDY flag is supposed to check whether the *oscillator* has already started up and is running in a stable way; whereas with external oscillator i.e. HSE bypass, the expectation is that the oscillator *does* run unconditionally.

In the past, reports on this matter differed (albeit on varying STM32 families which indeed may behave differently), and I'm not sure there is any definitive guide from ST in this regard. If the 'G0 RM says explicitly otherwise, please correct me.

JW

 

RM doesn't say anything explicitly regarding HSERDY with HSE in bypass mode, but HAL clock startup code does check HSERDY flag regardless of whether crystal or bypass is used:

 __HAL_RCC_HSE_CONFIG(RCC_OscInitStruct->HSEState);

 /* Check the HSE State */
 if (RCC_OscInitStruct->HSEState != RCC_HSE_OFF)
 {
 /* Get Start Tick*/
 tickstart = HAL_GetTick();

 /* Wait till HSE is ready */
 while (READ_BIT(RCC->CR, RCC_CR_HSERDY) == 0U)
 {
 if ((HAL_GetTick() - tickstart) > HSE_TIMEOUT_VALUE)
 {
 return HAL_TIMEOUT;
 }
 }
 }

And even if we assume that HSERDY isn't necessary, the fact that sometimes HSERDY is set and sometimes it doesn't seems misleading.

[Andrew Neil]

---

@flawless wrote:

I've tried two different oscillators - the S2D8.000000B20F30T and an OT32258MJBA4SL 

---

Please give datasheets for those. 

Do they meet the STM32's requirements ?

 

They do meet the STM32's requirements as far as I see.

[flawless]

Yes, like my colleague mentioned, the HAL code still relies on the HSERDY flag even in bypass mode. What's even stranger is that we double-checked (actually triple- or quadruple-checked) the datasheet, and it doesn’t mention anything about HSERDY behavior in bypass mode — not even that it should be ignored, just nothing at all.

On top of that, all the other devices we have (from different series) always have this flag set when signal is on. So at this point, we’re completely confused. Even after removing all related checks from the HAL code, it still refuses to work with HSE unless the flag is set. That makes us think there might be some hardware-level checks involved — or something else entirely that we’re missing.

We even started to think that maybe something wrong with this specific revision of the MCU's (we have multiple boards, so the same behaviour reproduces on all of them), but we don't know how to check. Will try to find dev board with MCU like that and maybe if it will be ok we will replace our MCU with one from dev board and try it.

[TDK]

I think @waclawek.jan 's comments are on point here. The RM explicitly says HSERDY is the state of the oscillator. You are not using the oscillator, so HSERDY is immaterial.

The check on HSERDY by HAL is probably a longstanding bug that should be addressed. This would explain the many reports of HSERDY not getting set during startup sometimes, or otherwise intermittent behavior.

> Even after removing all related checks from the HAL code, it still refuses to work with HSE unless the flag is set.

Eh, maybe not then.

I just checked this by setting up HSE manually (without HSERDY check, so just HSEBYP, HSEON bits) and then enabling MCO to output HSE (and infinite loop after that). This results in the same behaviour: sometimes, while cycling board's power, MCO will output 8MHz signal, sometimes there is 0. Also, NRST / software reset behave exactly the same as described in the topic. 

I checked a few times that when MCO has output, HSERDY flag is also set, so it seems that this flag can be used by hardware to check HSE presence even if it is configured in bypass mode.

[waclawek.jan]

How is the oscillator connected, exactly?

JW

2 capacitors there are 100nF and 1nF respectively.

I already tried cutting enable trace (floating enable = working oscillator) or using an external waveform generator. All approaches yield identical results.

[waclawek.jan]

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]

> 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.

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.

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.

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. 

[TDK]

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?

[waclawek.jan]

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