cancel
Showing results for 
Search instead for 
Did you mean: 

Internal pull-up on some pins (GPIOC, pins 6,7 and 8 and others) not working on STM32F407IGH6?

kyrreaa
Associate III

I am running into a very odd issue where the pull-up on GPIOC, 6,7 and 8 do nothing.

Using debugger and comparing to other pins with nothing connected I see IDR reflecting status of pin with pull-up or pull-down enabled. This does not happen for these pins on revision 2 and 4.

Chip is reset, clock domains enabled for GPIO and chip halted. PUPDR register fiddled with in debugger. Works for some pins not all, even though they are externally floating.

1 ACCEPTED SOLUTION

Accepted Solutions
kyrreaa
Associate III

Thank you both for quick answers. I had another look at the schematics and found subcontractor added external pull-ups not requested in spec. The pull-up idea put me onto the track. Basically what is happening is external pull-ups connected to a seperately controlled power-domain was pulling the pins to a non-enabled rail at 10k.

This went against the pins internal pull-up and resulting voltage was below ViH threshold, thus no input-high registration. Pins without this external pull-ups appeared to work correctly.

This matter is solved.

Lesson learned: Make sure you have 100% control on what is connected to a pin. Even though you think you know; check again.

View solution in original post

4 REPLIES 4

How are other GPIOC registers set? Is there any other peripheral ensbled in RCC? Does the debugger read IDR repeatedly, can you re-read it? Is there measurable effect on the physical pins? Pulling them up-down with a cca 40kOhm resistor externally is observable in IDR?

JW

Danish1
Lead II

The first place to look would be the errata, but I see nothing about it in there. I don't see mention of Revision 4 in the errata ES0182 Rev 11 dated December 2019 - please double-check that revision.

Other things affect the action of PUPDR, particularly relating to GPIOC->MODER (which you didn't mention):

If the pins are configured as Analog, the IDR will always read 0 because the digital input stage is turned off to save power.

If they are configured as Alternate Function - it depends which alternate function and how that peripheral is configured.

If they are configured as output...

Now I know at reset GPIOC->MODER should be all pins digital input. But the bootloader might have set up some pins for communication, so if you attached your debugger without causing a reset then you can't rely on everything being at reset.

Hope this helps,

Danish

kyrreaa
Associate III

Thank you both for quick answers. I had another look at the schematics and found subcontractor added external pull-ups not requested in spec. The pull-up idea put me onto the track. Basically what is happening is external pull-ups connected to a seperately controlled power-domain was pulling the pins to a non-enabled rail at 10k.

This went against the pins internal pull-up and resulting voltage was below ViH threshold, thus no input-high registration. Pins without this external pull-ups appeared to work correctly.

This matter is solved.

Lesson learned: Make sure you have 100% control on what is connected to a pin. Even though you think you know; check again.

> Lesson learned: Even though you think you know; check again.

Yes, we know... 😉

Thanks for coming back with the solution. Please select your post as Best, so that the thread is marked as resolved.

JW