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

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.

Amel NASRI
ST Employee

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:

AmelNASRI_1-1748882936745.png

Important to pay attention to this warning when this condition isn't respected and that may explain the behavior you see:

AmelNASRI_2-1748883057524.png

You have the same in the he AN5096Getting 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.

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.


@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:

AmelNASRI_1-1748882936745.png


Well, that just says "recommended" - not "required".

 


@Amel NASRI wrote:

the same in the he AN5096


Also just says "recommended" - not "required".

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

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

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

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.

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

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

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?

Sattys
Associate II

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.

flawless
Associate II

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