2025-05-27 5:45 AM - edited 2025-05-27 5:52 AM
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!
2025-06-02 9:46 AM - edited 2025-06-02 9:50 AM
Well, yes, I just didn't think it would result in such HSE problems. We are going to use battery, it just wasn't installed for debugging.
Also, for example, if battery would loose it's charge over time, device may still face this kind of problems which isn't reliable.
2025-06-02 9:52 AM
Hi @flawless ,
Please note that it is explicitly mentioned in the reference manual RM0444 that is is required to connect VBAT to VDD when no external battery is used:
Important to pay attention to this warning when this condition isn't respected and that may explain the behavior you see:
You have the same in the he AN5096: Getting started with STM32G0 Series hardware development.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-06-02 10:00 AM
Yes thank you, but I read a few discussions where people say, you can leave VBAT floating in case you don't use anything from VBAT power domain. I just assumed, HSE isn't part of it, so it shouldn't affect it in any way. I hope, VBAT is the real reason behind HSE problems because it is somehow fixable. Though as I said, the fact that in case of battery discharge, HSE could just stop working is a bit worrying.
2025-06-02 10:01 AM
@Amel NASRI wrote:it is explicitly mentioned in the reference manual RM0444 that is is required to connect VBAT to VDD when no external battery is used:
Well, that just says "recommended" - not "required".
@Amel NASRI wrote:the same in the he AN5096
Also just says "recommended" - not "required".
2025-06-02 10:08 AM
@Sattys wrote:I read a few discussions where people say, you can leave VBAT floating in case you don't use anything from VBAT power domain.
Do you have (a) link(s) to any such thread(s) ?
@Sattys wrote:the fact that in case of battery discharge, HSE could just stop working is a bit worrying.
You should be able to fall-back to an internal oscillator in that case?
Presumably, you'd want to detect low battery & act on that before it got to this stage?
2025-06-02 10:18 AM - edited 2025-06-02 11:43 AM
https://community.st.com/t5/stm32-mcus-products/can-i-leave-vbat-unconnected/td-p/363846
If there is no clear way to guarantee MCU correct function in case of VBAT beeing absent (or lower than threshold?) then you can only check if battery is higher than threshold or else MCU's random parts just stop working (like HSE, which is not related to VBAT at all). The thing that concerns me is that once battery voltage became low, MCU's behavior becomes unpredictable.
With assumption that the only things that stop working are VBAT power domain & HSE, workarounds can be implemented.
2025-06-02 12:58 PM - edited 2025-06-02 1:00 PM
> The thing that concerns me is that once battery voltage became low, MCU's behavior becomes unpredictable.
Have you tried grounding VBAT to see if that makes a difference? In which case, a dying or dead battery may not cause this issue. Maybe the issue is that it's floating/bouncing.
It's not ideal, but you can workaround this via software, as you've discovered with the option byte modification.
Definitely deserves an errata or clarification. We'll see what else ST has to say.
2025-06-02 1:00 PM - edited 2025-06-02 1:06 PM
Yes, we did, it didn't change anything, same HSE startup problems.
I'm not even sure if floating VBAT is actually the primary source of HSE problems. What if the fact that HSE is reliably starting up only in presence of VBAT is just a random side effect of another problem?
2025-06-02 1:50 PM - edited 2025-06-02 2:10 PM
To finally confirm described behavior we bought NUCLEO-G0B1RE board.
We swapped board's MCU with one of our board's one to check all the possibilities. Also, we unsoldered NUCLEO board's SB26 bridge (it connects VBAT to VDD). Both MCUs were then programmed with same basic software that enables HSE & MCO to output HSE.
Our board behaved exactly the same as was previously described.
NUCLEO board was powered by Vin using 12V from my lab PSU. It also behaved exactly the same as our board: HSE didn't start without power cycling in a "special" manner.
2025-06-03 9:41 AM - edited 2025-06-03 9:41 AM
Hi everyone, just want to share a little update on what else we checked:
LSE seems not affected by this and starts normally with floating VBAT
We were unable to reproduce the original issue on F413ZH on Nucleo F413ZH desoldering the junction between VDD and VBAT and checking CR content with st-link - HSE always starting normally with floating VBAT