STM32L433: Using PH0 PH1 as GPIO

[Skadi F]

Posted on June 14, 2018 at 12:12

Hi,

I realized a prototype including the STM32L433 (LQFP64 package). I tried to use the pins PH0 and PH1 as OUTPUT pins. This should be possible according to the datasheet (5V tolerant I/O pins). This pins can be used to attach a crystal or oscillator to the controller. This external clock would act as

HSE

, which I do not use (haven't installed). So disabled the HSE as well as the LSE.

I wasn't able to set the pins PH0 and PH1 HIGH. Interestingly, for the pins PC14 and PC15, which are responsible for the

LSE

, it works fine. I defined the pins PH0, PH1, PC14 and PC15 in as push-pull outputs.

Is it possible to use PH0 & PH1 as GPIO pins, or have I missed something in the datasheet?

BR

#hse #stm32l433 #gpio #push-pull #output

[Tesla DeLorean]

Posted on June 14, 2018 at 12:19

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.

[TDK]

Posted on June 15, 2018 at 21:11

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.

[waclawek.jan]

Posted on June 15, 2018 at 23:03

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

JW

[Skadi F]

Posted on June 17, 2018 at 12:40

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.

[Skadi F]

Posted on June 17, 2018 at 20:46

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

[TDK]

Posted on June 17, 2018 at 20:13

What are your clock settings?

It's going to be hard to debug issues without a reliable debug mechanism.  Can you send text to a terminal using a UART or something?  You could also blink an onboard LED as a (very limited) debug mechanism.