STM32F4: OSC_OUT as GPIO when HSE in Bypass mode

---

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

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

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

Hi @mƎALLEm ,

thanks for letting us know.

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

JW