cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H750 ignores pull-up resistor when EXTI is selected

olavi
Associate III

On F1xx and F4xx platforms, I have been using the GPIO pull-up resistors for the connections to OC hall sensors used in BLDC motors. There has never been a problem. With STM32H750, I can see that the PUPDR register has the right values for the pull-up resistors in the EXTI lines, but no current comes out to keep the value high when the hall transistor OC is open. If I change the pin to GPIO input, I can confirm that the H750 pull-up resistor works properly.

My conclusion is that this is a bug in the H750 silicon. If that is the case, I cannot use this MCU because I don't want to add the external resistors. Could somebody confirm?

The planned remedy is to replace the STM32H750VBT6 board with a STM32F750V8T6 board. This is not ideal because the H750 has lower price, has more memory, and is faster than F750. On other hand the simpler architecture in F750 allows much faster pin manipulation.

1 ACCEPTED SOLUTION

Accepted Solutions
olavi
Associate III

Good news - the silicon is OK. The problem is in STM32CubeIDE LL library for STM32H750. That is still strange because the LL library has been problem free for me when using F1, F3, and F4.

Thanks for the relevant questions that did lead to find the real issue. 😀

View solution in original post

7 REPLIES 7
TDK
Guru

Not many details here. Probably not a critical hardware error like this in the silicon.

> right values for the pull-up resistors in the EXTI lines,

> If I change the pin to GPIO input, I can confirm that the H750 pull-up resistor works properly.

The PUPDR register is in the GPIO peripheral. EXTI is separate. The pin should be (or at least can be) a GPIO input while still being an EXTI trigger. What are you changing it from?

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

If I configure an EXTI line without the pull-up resistor in F1 and F4, the functionality is the same as in H7 even when the pull-up resistor is configured. I am using STM32CubeIDE to configure the pins. In the System Core pull down menu, I do select GPIO to see the Configuration for all the defined pins. For every pin I can see

  • GPIO mode
  • GPIO Pull-up/Pull-down
  • User Label

First I had 3 pins (A4, A5,and A7) configured for EXTI with Pull-up. Then I change one of them (A4) to GPIO Input and select the Pull-up. After starting the program, I can open the SFRs view and open GPIOA to see the IDR register content. That is confirming that the A4 is changing between 0 and 1 when the motor is running. The other two inputs stay at 0. Using an oscilloscope, I can confirm that the A4 voltage is chancing between 0 and 3.3V with very clean edges. The other two pins are either solid 0 V (when the hall transistor is active) or a slowly changing value between 0 and 0.2 V (when the transistor is OC).

I am still convinced that there is a silicon problem.

Read out and post content of MODER and PUPDR registers.

Pull up the pins externally and check that you can see the changes when observing IDR.

JW

olavi
Associate III

When I do disconnect the sensor cable, all pins go to 0 in IDR. When measuring the voltages in the disconnected cable the voltages are changing between solid zero and floating 0 - 0.2V because there are no pull-up resistors.

The MODER value is 0xabfffcff

The PUPDR value is 0x64004500

Thanks for rapid replies in this matter.

olavi
Associate III

Sorry, I missed to inform that when driving the pins externally without the sensor cable. Then A4 works normally, but A5 and A7 stays at 0. This is odd and implies that there are two EXTI issues:

1) Missing pull-up action that should be there in any case

2) EXTI line is not updating the DR

olavi
Associate III

These observations made me think that the issue could be in the STM32CubeIDE. I have been using the LL library. I will do a test with HAL to see what happens.

olavi
Associate III

Good news - the silicon is OK. The problem is in STM32CubeIDE LL library for STM32H750. That is still strange because the LL library has been problem free for me when using F1, F3, and F4.

Thanks for the relevant questions that did lead to find the real issue. 😀