STM32L433: Using PH0 PH1 as GPIO

Can't say I've dug into the L4 data in this regard, other STM32 including the L0 allow for OSC_IN/OSC_OUT to be retasked as GPIO, might want to check the bits in the RCC registers, as those take precedence over GPIO/AF settings.

This is for the STM32F4, but it's likely the same for you.  From the reference manual:

8.3.14 Using the OSC_IN/OSC_OUT pins as GPIO PH0/PH1 port pins

The HSE oscillator pins OSC_IN/OSC_OUT can be used as general-purpose PH0/PH1 I/Os, respectively, when the HSE oscillator is OFF. (after reset, the HSE oscillator is off). The PH0/PH1 I/Os are only configured as OSC_IN/OSC_OUT HSE oscillator pins when the HSE oscillator is ON. This is done by setting the HSEON bit in the RCC_CR register. The HSE has priority over the GPIO function.

Double check that it's actually disabled.  And see what the STM32L4 manual has to say on the matter.

DId you read back the relevant RCC and GPIOH registers and check if they were set as you expected?

JW

Hi, I'm using ChibiStudio, I tried to check the register by the debugging the controller with OpenOCD. Unfortunatly I'm not able to debug the controller. I tried to use the stm32l4discovery.cfg file, but it doesn't work. By using stm32ldiscovery.cfg file the configuration seems to work, althoug the wrong controller is detected: stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints. By performing the debugging process, a pop up window appears with following massage: Target request failed: Don't know how to run. Try 'help target'.

Nevertheless, I disabled the HSE twice. Once in the config file and a second time in the main file by: 

RCC->CR &= ~RCC_CR_HSEON;            // Disable HSE

GPIOH -> MODER &= 0x00000005;         // PH0 & PH1: OUTPUT; default: 0x0000000F

GPIOH -> OTYPER &= 0x00000000;        // Output push-pull (reset state); default: 0x00000000

GPIOH -> ODR |= 0x00000003;                 // set PH0 & PH1 initial HIGH

Without any success.

Hi,

I enabled the HSI @ 16 MHz, LSI @ 32 kHz and I also use the 48 MHz internal clock, which is used for USB communication. The PLL source is the 16 MHz HSI, PLL_M = 4, PLL_N = 40, PLL_R = 2, and of course the system clock mux input is the PLL clock. Resulting in a system clock of 80 MHz.

The controller it self works fine so far. I'm able to communicate via USB and a LED is attached to a GPIO pin. I'm able to switch the LED on and off via serial/USB commands.

The only thing which doesn't work so far, is the usage of the PH0 and PH1 as push-pull outputs.

BR