Problems with STM32 voltages

[sini6a]

Hi dear community!

I have designed a custom PCB and schematic for a device that is powered by STM32F042F4. I have succesfully flashed the device through SWD but a problem that I have is that the device is outputing about 2.5-3.0V on an input pins. I have tried using integrated pull down resistors and the strange thing is that the device sometimes work as intended and not outputing any voltage, but after some time the LED starts blinking which indicates voltage on input pins, it measures above 1.8V randomly.

I also tried implementing strong pull down resistor with 1k resistors but I am experiencing same problems. Here are some screenshots of schematic and STM32CubeMX. Any advice is appriciated.

Best Regards

[pcprogrammer]

Provide specific information about the actual pin you are talking about.

In your schematic PA1 and PA2 have leds connected to them and should be outputs. The inputs seem to be on PA11 to PA14 of which the last two are for SWD.

If it is these two pins (PA13 and PA14) you are talking about, then read the reference manual about using the SWD pins for general IO. I'm not familiar with the STM32F042F4 but for the STM32F103C8 you need to enable alternate function IO and disable full JTAG.

[sini6a]

Hi!

Yes. You are correct. Those pins are reading high voltages. PA11 to PA14. I have disabled SWD/JTAG as they are automatically pulled up/down if BOOT0 is high on reset.

The full schematics is provided here: https://github.com/sini6a/stm32-pocket-console/blob/main/schematics.pdf

Please note that I have removed pull up, pull-down resistors on this lines so I am using only software defined ones.

[pcprogrammer]

You state that you removed the pullup and pulldown resistors and only use the internal ones, which makes it weird, but I can't see from what you posted that JTAG/SWD is properly disabled. I don't use the HAL and STM32CubeMX stuff so can't help there.

The way you setup your buttons is not how I would do it. My usual way is to have the switch to ground and a pullup to make it high when not pushed. Only on the two SWD wires would I include some serial resistors to avoid problems when using SWD. After reset standard IO pins are in input mode so no risk there.

[sini6a]

I removed them in order to test the internal resistors but that didn't help. It would be better for my next revision to make it as you stated, pull down the buttons and keep the voltages high. The strange thing here is that the board sometimes works perfectly, reading voltages of 0 at the input pins PA11 to PA14 but after some time they are pulled high and stay there no matter what I do. I have tried with 3 different chips because that was the only explanation why this may be happening but got same results.

Thank you for your help anyway, will try to do some further troubleshooting.

[newbrain]

One question: does the CubeMX generated code correctly write the SYSCFG_CFGR1 to remap the default P9 and P10 pins to P11 and P12?
If it doesn't, the actual P11/12 input are floating, as they are not connected to anything.

EtA: checked, it does - unless you have edited out __HAL_REMAP_PIN_ENABLE(HAL_REMAP_PA11_PA12); from HAL_MspInit()

[sini6a]

No, I remapped them but tried both as PA9, PA10 and PA11, PA12.

I haven't edited anything but the configuration shown in the attached screenshot. I chose pull-down on both pins in the CubeMX configuration utility. Isn't that suppose to write those lines automatically?

Thanks

[DavidAlfa]

They're simple ouputs, why are you remapping them? Try without it.
Until working, avoid using PA13/PA14 for anything as they're the SWD pins.

Built-in pull resistors are low enough for most of applications (~40K), you don't need external ones except for very specific cases.

Don't hardcode GPIOA, etc, use **_GPIO_Port, like BAT_LED_GPIO_Port:

Code: [Select]

HAL_GPIO_WritePin( BAT_LED_GPIO_Port, BAT_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_11) == GPIO_PIN_SET );

Likely you messed something in the code, post the entire thing instead of doing screenshots.

[cncjerry]

initialize your settings and then let the code fall thru to an infinite loop at the bottom of main.  Don't let it loop on main.

How are you measuring the voltage when it is wrong?  With a scope?  Because if you are using a meter then it could be pulsing, of course.  I would initialize the pins as inputs with pullups and then fall thru and go into a loop doing nothing.  then read the pin voltage.  If the voltage is wrong then it isn't initialized correctly, something isn't turned off or the pin is bad.  When I first started with the STM code base, I would ignore messages when it said things like, "that pin is already in use."  You are probably doing all this, but you need to turn off/disable things you aren't using to prevent conflicts.

[pcprogrammer]

They're simple ouputs, why are you remapping them? Try without it.
Until working, avoid using PA13/PA14 for anything as they're the SWD pins.

Built-in pull resistors are low enough for most of applications (~40K), you don't need external ones except for very specific cases.

Don't hardcode GPIOA, etc, use **_GPIO_Port, like BAT_LED_GPIO_Port:

Code: [Select]

HAL_GPIO_WritePin( BAT_LED_GPIO_Port, BAT_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_11) == GPIO_PIN_SET );

Likely you messed something in the code, post the entire thing instead of doing screenshots.

I assume based on the schematic that the TSSOP20 package is used and there the pins 17 and 18 can either be PA9/PA10 or PA11/PA12. I would opt for using PA9/PA10 in the software and not remap them, but if in the software for some reason it is easier to have the bits in a row then remapping is an option.

For sure the OP did not provide what is needed for a proper understanding of what is going on. Complete source including the STM32CubeMX would be helpful. He could put it is in his repository where the schematics are.

As to testing I would suggest to solder a new MCU to a board and leave it blank for now. All GPIO pins but the SWD ones will be inputs. Now check what the pins are doing. They should be floating, so best to check with an oscilloscope. Then write a configuration with the pins as input and pullup enabled and check it again.

And again read the datasheet and reference manual about how things stick together.

[sini6a]

Hi!

Thanks everyone for your feedback. I have uploaded the code on the project page:
https://github.com/sini6a/stm32-pocket-console

Sorry if my question was not clear enough. I will try to explain it a little bit further: the board has 5 input buttons of which 2 are routed on pins PA13 and PA14 which happens to be an SWD pins too. What I initially thought is that the SWD pins are used for flashing only if PB8 (BOOT0) pin is pulled high on reset, otherwise I can use them as GPIO pins. Now the problem is following: when I initially flashed the board everything was working as expected. Pushing the buttons will turn one of the LEDs on the output pin PA2 high. Measuring the voltages on the input pins with a multimeter shows 0 volts (the buttons pull those pins high) but after some time the input pins are somehow changing voltages without pressing the buttons (measuring again with multimeter shows 1.5 to 2.8v) and LEDs start lighting up randomly. I used 3 different MCUs of the same kind (thought that issues may be related to faulty MCU) but I got same problem with all 3 of them and resetting the board does not fix the issue.

To try and further diagnose the issue I now flashed only two buttons connected to PA9 and PA10 and disabled external crystal. Then I will try to enable one of the pins used by both SWD and GPIO to check if this may be the culprit.

I will keep you updated and once again thank you for all the feedback

[sini6a]

Little update on the topic: I created a new project in CubeMX and started with configuring only one LED on PA2 and the two input buttons PA9 and PA10. I started adding functions such as switching from internal clock to the external one, and configured the rest of the buttons on PA13, PA14 and PB8. This time everything works without any problems.

Only difference from the previous project is the syntax I used for putting the LEDs up. Instead of GPIOA and wrapping everything in if statements, I used the following syntax:

Code: [Select]

HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_9) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_10) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOB,GPIO_PIN_8) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_13) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_14) == GPIO_PIN_SET );

I am wondering if this could be culprit somehow. Maybe using GPIOA is messing with the whole bank. Any comment would be appriciated.

Thank you

[DavidAlfa]

Check if #define MIN_LED_GPIO_Port is GPIOA in main.h.

[ozcar]

Little update on the topic: I created a new project in CubeMX and started with configuring only one LED on PA2 and the two input buttons PA9 and PA10. I started adding functions such as switching from internal clock to the external one, and configured the rest of the buttons on PA13, PA14 and PB8. This time everything works without any problems.

Only difference from the previous project is the syntax I used for putting the LEDs up. Instead of GPIOA and wrapping everything in if statements, I used the following syntax:

Code: [Select]

HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_9) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_10) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOB,GPIO_PIN_8) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_13) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_14) == GPIO_PIN_SET );

I am wondering if this could be culprit somehow. Maybe using GPIOA is messing with the whole bank. Any comment would be appriciated.

Thank you

So you execute that repeatedly in a loop?

I'm not sure what you expect that to do. If you want the LED to come on, full brightness, when any one of the buttons is pressed (or not pressed) then that is not going to work. What you have there is some sort of time division multiplexing of the button inputs to the LED output pin - a pulse train with time slots for the status of each button. Just looking at the LED, or even measuring the voltage with a meter and at best you could tell how many of the buttons are pressed, but if any one button is not working due to some misconfiguration or conflict of usage, then it will be impossible* to tell which one is causing trouble.

Edit:

Well, maybe not impossible, but getting into tricky territory.

[sini6a]

Check if #define MIN_LED_GPIO_Port is GPIOA in main.h.

Yes, they are defined in main.h

Little update on the topic: I created a new project in CubeMX and started with configuring only one LED on PA2 and the two input buttons PA9 and PA10. I started adding functions such as switching from internal clock to the external one, and configured the rest of the buttons on PA13, PA14 and PB8. This time everything works without any problems.

Only difference from the previous project is the syntax I used for putting the LEDs up. Instead of GPIOA and wrapping everything in if statements, I used the following syntax:

Code: [Select]

HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_9) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_10) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOB,GPIO_PIN_8) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_13) == GPIO_PIN_SET );
HAL_GPIO_WritePin( MIN_LED_GPIO_Port, MIN_LED_Pin, HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_14) == GPIO_PIN_SET );

I am wondering if this could be culprit somehow. Maybe using GPIOA is messing with the whole bank. Any comment would be appriciated.

Thank you

So you execute that repeatedly in a loop?

I'm not sure what you expect that to do. If you want the LED to come on, full brightness, when any one of the buttons is pressed (or not pressed) then that is not going to work. What you have there is some sort of time division multiplexing of the button inputs to the LED output pin - a pulse train with time slots for the status of each button. Just looking at the LED, or even measuring the voltage with a meter and at best you could tell how many of the buttons are pressed, but if any one button is not working due to some misconfiguration or conflict of usage, then it will be impossible* to tell which one is causing trouble.

Edit:

Well, maybe not impossible, but getting into tricky territory.

Yes I have this code written in loop function. Is there any callback that I should use instead?
Sorry if this may seem like stupid question but I have not much of experience with embedded devices. The thing is that now the board is working correctly, even if I have this code in main loop.

[ozcar]

...
The thing is that now the board is working correctly, even if I have this code in main loop.

What does "correctly" mean when it comes to the way the LED reacts to button presses?

What do you get if you press (hold down) one button?

What about when you press (hold down) more than one button at the same time?

As you press more buttons at the same time, can you see a difference in the brightness of the LED (or measure a difference in the voltage on the LED pin with your meter)?

[pcprogrammer]

The code is probably some simple test code to see if the buttons do their job. Sure the LED will vary in brightness due to only short pulses when a single button is pressed but will do the job, for just testing.

The project seems to be some game console which can be seen in the OP's repository. In it I suppose that each button will have its own task and the code will be very different for that.

[sini6a]

...
The thing is that now the board is working correctly, even if I have this code in main loop.

What does "correctly" mean when it comes to the way the LED reacts to button presses?

What do you get if you press (hold down) one button?

What about when you press (hold down) more than one button at the same time?

As you press more buttons at the same time, can you see a difference in the brightness of the LED (or measure a difference in the voltage on the LED pin with your meter)?

Yes I can see difference in brightness of the LED when multiple buttons are pressed. Like @pcprogrammer stated this is just a simple test code for testing the GPIOs. I am waiting on the LCD/FPC connector then I can continue working on the project.

Thank you everyone for your help. I would guess that I had some problems with the code, either generated by CubeMX or I made some accidental mistake somehere. This thread can be closed.