cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4: OSC_OUT as GPIO when HSE in Bypass mode

Richard1156
Associate

ST moderator: post split from this thread.

Hello mƎALLEm,

Thank you for your confirmation on this issue.

I would like to provide some additional information. I have also encountered the same problem on the STM32F405RGT6.

In STM32CubeMX, when I configure both HSE or LSE to "Bypass Clock Source" mode, the tool insists on reserving PH1 (OSC_OUT) or PC15 (OSC32_OUT) as RCC pins. It blocks me from configuring them as regular GPIOs, even though the hardware (as you've confirmed) supports it.

Furthermore, I tested this on the STM32F446RE and STM32F446RC using the latest CubeMX, the problem still exists on those devices as well.

Regarding the internal tickets you mentioned (220390 for documentation, 222721 for CubeMX), may I kindly ask:

  • Has the CubeMX fix (ticket 222721) been implemented in any release yet?
  • If not, is there an estimated timeline for when we can expect this fix?

I understand if you cannot share internal details, but any update would be very helpful for our planning.

Thank you very much for your help, and sorry for my English as I'm not a native speaker.

11 REPLIES 11
mƎALLEm
ST Employee

@Richard1156 wrote:
  • Has the CubeMX fix (ticket 222721) been implemented in any release yet?

Not yet.

 


@Richard1156 wrote:
  • If not, is there an estimated timeline for when we can expect this fix?

I don't have the information for now.

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.
waclawek.jan
Super User

The 'F405/407/415/417 is different from 'F446 in this regard, and you can' t use OSC_OUT as GPIO even if HSE is set to BYPASS.

JW

@waclawek.jan 

All STM32F4 are included. The documentation will be updated.

So OSC_OUT could be used as normal GPIO when HSE in Bypass mode for any STM32F4xx.

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.

@mƎALLEm ,

I've tried this on a 'F427 and it did not work as GPIO. Reported so in some of the linked threads (EDIT here). Inferred same to 'F40x, but can try if time permits.

JW

@waclawek.jan 

Umm interesting. My confirmation is based on an internal discussion with relevant technical colleagues.

 

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.

@mƎALLEm 

I may have made a mistake, didn't take notes when did that experiment; but I did it at the same time on both the 'F446 and 'F427 so it's quite likely I did the same thing on boths and seen different physical results.

I'll retry later (possibly during weekend, there's job to do and bills to pay) and report.

JW

waclawek.jan
Super User

OK so just tried: the 'F407 does not allow GPIO on either PH0 and PH1 (I don't even bother to check which one of them is supposed to be free) while both HSE and HSEBYP are set.

It's easy to try, I did not write a single line of code, all what I did was a couple of lines in gdb, while measuring on burden capacitors of the attached xtal using a simple multimeter. Hi-Z is distinguished from 0 and 1 simply by touching the metal tip of the probe by finger...

(gdb) moni reset halt
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002e4 msp: 0x10010000
(gdb) set RCC->AHB1ENR|=0xFF
// enabling all GPIOs, 0x80 should be sufficient for GPIOH but doesnt' really matter
(gdb) p /x *GPIOH
$3 = {MODER = 0x0, OTYPER = 0x0, OSPEEDR = 0x0, PUPDR = 0x0, IDR = 0x2, ODR = 0x0, BSRR = 0x0,
  LCKR = 0x0, AFR = {0x0, 0x0}}
// IDR shows 1 as I hold my finger at the probe touching PH1
// meter at this point shows changing value from the 50Hz noise from my finger
// same touching PH0, so both are Hi-Z as expected after reset
(gdb) set GPIOH->MODER=0x5
// after this, both PH0 and PH1 show 0V, as ODR=0
(gdb) set GPIOH->ODR=1
// PH0 goes to 3.3V as expected
(gdb) set GPIOH->ODR=0
// PH0 goes to 0V as expected
(gdb) set GPIOH->ODR=2
// PH1 goes to 3.3V as expected
(gdb) set GPIOH->ODR=0
// PH1 goes to 0V as expected
(gdb) set GPIOH->MODER=0
// both PH0 and PH1 are Hi-Z again
(gdb) set RCC->CR |= 0x50000
// PH0 and PH1 are still Hi-Z
(gdb) p /x *RCC
$4 = {CR = 0x57c83, PLLCFGR = 0x24003010, CFGR = 0x0, [...]
// just verifying both HSEON and HSEBYP are set in RCC_CR
// note that there is no HSERDY as the crystal won't oscillate in itself
// (btw. eventually, just by touching one of the pins, RCC_CR.HSERDY went up, it just took some time, as I was injecting 50Hz and the HSERDY counter is probably something like 2^10 or so)
// (also, while HSEON, GPIOH_IDR lowermost 2 bits won't get set, this is expected as the RCC override should be equivalent to putting the pins to Analog mode)
(gdb) set GPIOH->MODER=0x5
// yep, PH0/PH1 still Hi-Z
(gdb) set GPIOH->ODR=3
// and of course they are still Hi-Z, I just felt being compelled to try :-)

 

So, perhaps your colleagues might want to reconsider their assertion - or they might want to perform this little experiment, too - before changes to documentation are made.

JW

[EDIT] Oh, and I got caught again by the "HSEBYP not being reset by software reset" issue, as after the above exercise I wanted to continue by simply writing "moni reset", just to be surprised that the product I was testing this on did not start... :)

Hello @waclawek.jan 

Thank you for your test.

I did the same thing from my side on STM32F429ZI, STM32F446ZE, STM32F412ZG (Nucleo-144 boards) and indeed I found STM32F429ZI is not following the behavior i.e. OSC_OUT can't be used as GPIO output when HSE is in Bypass mode. Which is not the case of STM32F446ZE andSTM32F412ZG. 

I've already escalated the case for internal analysis.

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.
waclawek.jan
Super User

Hi @mƎALLEm ,

thanks for letting us know.

This detail appears to have roots deep back into the STM32 history... :)

JW