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

[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 ?

[Satty]

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

[Satty]

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.

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

[Satty]

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

[Satty]

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.