GPIO configured as Input on STM32H563VGT6 does not work

[SRond]

Hey everyone,

I have an odd problem with a STM32H563VGT6.

I have configured several GPIO as inputs with no pull-up/ no pull-down. The pins are wired to an external 10k pull-down and a DIP-Switch which is directly connected to +3V3. (screenshot below).

When all switches are off, I read and measure +0V on my pins. If I set one switch to active so it connects +3V3 to the MCU-Pin this pin reads a high and I can measure +3V3 with an osciloscope. The weird thing is now that I can also measure something between +1.7V and 2.9V on the other lanes, even though thex should be low and pulled down by the 10k resitor. I tried to work with the internal pull down of the mcu with the same results. I tried to configure 3 of the pins to output and set them to low. The remaining pin was set as input. After I switched the respective switch to high I got the same result and even the pins which should drive the lanes active low got some voltage somewhere between 1.7V and 2.3V.

I work on a custom board but all other functions like DAC, ADC, USART work fine and I have never had the situation that GPIO was an issue. I have already checked the bare PCB without parts for possible wrong connections between GND and 3V3 or any wrong or missing connections in the area of the DIP-switch. Seems alright and values and open lines are what I would expect.

I have already seen in the documentation that there is an SMPS versions of my MCU but from everything I can see and from everything that is printed on the MCU it should be the STM32H563VGT6 and the PCB layout matches to this controller.

I configured with CubeMX Version 6.13 and worked with CubeIDE Versions 1.16 and 1.17. Maybe there are some known issues somewhere that I missed?

Thanks in advance for any help

 

[Andrew Neil]

Is this a new hardware design?

Has it ever worked?

Please post a minimum but complete code example which demonstrates the problem.

[SRond]

Hi Andrew,

thanks for the questions.

It is a new hardware design in the way we use a new mcu in the STM32H563 but we have done this sort of schematic with other MCU like F207 or G474 without any problems. The new layout PCB has already worked for about 30 to 40 hours with a STM32H563 MCU. During testing measurements we accidentaly short ciruted a 3V3 input lane of the mcu to a 15V lane on the first test-PCB. This of course destroyed the MCU. We changed the MCU and then the weird behaviour started. We thought this may be related to another part of the PCB beeing damaged so we switched to a completely unused, new PCB. Same weird behaviour and we started to try a lot of things like changing configuration redoing our code but nothing did work.

If the PCB would have never worked, I totally agree to a hardware or layout problem but since it worked in the beginning and now it does not anymore we are kind of stuck. Since the STM32H563 exists in "normal" and "SMPS" version an explanation of this random behaviour we are watching would be if the one MCU it worked with was "normal" and the other two which are not working are "SMPS". Because those two types have some small but mayor differences in the pinout for supply and ground pins on pins 46 to 50. But from everything that is printed on the MCUs they should all be the same type "STM32H563VGT6"

 

Initcode of the GPIO:

 GPIO_InitStruct.Pin = DI_SPERR1_Pin|DI_SPERR2_Pin|DI_SPERR3_Pin|DI_SPERR4_Pin;
 GPIO_InitStruct.Mode = LL_GPIO_MODE_INPUT;
 GPIO_InitStruct.Pull = LL_GPIO_PULL_DOWN;
 LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Usage of the Pins:

void vGetProgState(void){
	uint32_t u32ReadValMasked = (LL_GPIO_ReadInputPort(GPIOA)&(DI_SPERR1_Pin|DI_SPERR2_Pin|DI_SPERR3_Pin|DI_SPERR4_Pin));
	if(u32ReadValMasked == DI_SPERR1_Pin){
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 1;
	} else	if(u32ReadValMasked == DI_SPERR2_Pin){
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 2;
	} else	if(u32ReadValMasked == DI_SPERR3_Pin){
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 3;
	} else	if(u32ReadValMasked == DI_SPERR4_Pin){
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 4;
	} else	if(u32ReadValMasked == 0){
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 0;
	} else {
		globaleParam_arr[STATUS_PROG_ADR].u16Istval = 99;
	}
}

 Thats the comlete usage of the pins. I already took the u32ReadValMasked into a global scope so I could watch it in the debugger and the value changed more or less constantly accordingly to the pin readings.

 

Hope this answers the questions.

regards

Sven

[mƎALLEm]

Sorry but here you are configuring the internal pull down:

GPIO_InitStruct.Pull = LL_GPIO_PULL_DOWN;

Could you please double check?

[mƎALLEm]

To be efficient:

When the switch is off, does the pin reads 0?

When the switch is on, does the pin reads 1?

[SRond]

Thanks for your questions.

When all switches are off, then the pins read 0. When all switches are on, then the pins read 1.

When only one switch is on the respective Pin reads 1 and the other pins have some in between states which can read sometimes as 1 and sometime as 0. The reading behaviour of the pins seem right since I can measure the levels of these pins and they are fluctuating somewhere between 1.7V and 2.8V and thus will sometimes be accepted as high and sometimes as low. The pins are configured as  Input and I tried both the "pull-down" and the "no pull-up no pull-down" options that can be configured.

[gbm]

Looks like there is no ground connection to the pull-down resistors. The resistors are not really needed, as the internal port pull-down is enough.

[SRond]

@gbmThe external pull-down resistors to ground are properly connected and they are the 10k. I double checked with a multimeter on two different PCB. And the whole ground and supply voltage network of the PCB seems ok as well. I checked with an oscilloscope. The levels of 3V3 and +15V look stable and the osci did not trigger any change of edge. I also measured GND to GND on several different places. It was all in the range of a few mV. Nothing out of the ordinary.To rule out the DIP switch we soldered it out and hard soldered a bridge to one of the paths, same problem.

Just as I am writing this there is one idea comming in my mind that we have not yet tryed: I am going to solder out the 10k resistors and the dip-switch so there really is only the one path with high and the other pins are let open with internal pull down. If I still can measure weird behavior it has to come from some internal connection between the pins on the port. If the beavior is right then there is a mayor problem on the schematics or the PCB.

@gbmI was just writing as you wrote yours ;)

@mƎALLEmNow I have tried a firmware version where I set the internal resistors to pull up. The behavior is pretty much what I expectet but it does not make sense. If all switches are on I can measure 3V3 and the pins register high. That is ok. If all switches are off I can measure 0.7V and the pins register low. The 0.7 is around what I would expect with the internal pull up active so I think also OK. If only one of the switches is high and the others are low I get back to measuring something between 1.7V and 2.9V on the lines which should be at 0.7V. I do not understand were this voltage comes from.

[gbm]

Remove the resistors, keep the switch. For me it looks like 99% that some ground connection is missing, either for the resistors or one of MCU's GND pins.

[LCE]

What's the MCU's actual supply voltage?

I would never connect any supply voltage to a GPIO directly, I'd put at least serial 100R in there somewhere.

And I support gbm's idea about the missing / bad GND connection.
We once had a PCB where someone gave the wrong net names to all internal GND planes, that was a mess...

 

PS: If somehow that GPIO bank A is not running from 3.3V but any lower voltage, then your results might make some more sense

[SRond]

@gbm  we removed the external 10k resistors and used just the internal pull down. Same problem.

@LCESupply voltage is 3.34V measured with multimeter. I think GPIO bank A is running on 3.3V because without the external pull down I could measure 3.3V after I set the pins internally to pull up and put all switches to off.

Agreed, everything looks like a GND problem.

We will rework the PCB and we will also do a second slightly different PCB where we change the controller and leave everything else as it is. Or at least we try to change as little as possible.

Kindest regards for all your ideas. After we have the new PCBs and we have checked them I will get back with the results.