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.

[SofLit]

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.

[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

[SofLit]

Sorry but here you are configuring the internal pull down:

GPIO_InitStruct.Pull = LL_GPIO_PULL_DOWN;

Could you please double check?

[SRond]

I know.

I tried both ways, with "LL_GPIO_PULL_NO" and with "LL_GPIO_PULL_DOWN" and both behaved the same.Pull down is just the latest version. I copied it out of the last state of my git repo from this project.

The only thing I did not try was working with an active internal pull up since the normal state on the PCB would be a pull down. Maybe I am going to do that today but I have a few things to do before I can try that.

[SofLit]

May be you need to:

1 - Share your schematics. Not just that part of the switch.

2 - Your minimal project that reproduce the behavior.

[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]

I am afraid but I can not share the whole schematics. The minimum project which reproduces the behavior is just a bare metal new mcu or a completely wiped mcu. But we do not know what behavior the pins have in this state. I also have this problem if I put all the pins to unused analog mode. Same with only using these 4 pins as Input and putting all other pins to unused analog mode.

So I totally accept the underlying statement "It is a hardware or schematics problem not MCU or software related" and we would agree completely if there would not have been the first MCU that worked perfectly fine until we short circuited it.

Currently we have two working hypotheses but we can not really confirm or rule out either of them in an easy way.

1) The first, short circuited, MCU was a SMPS version and somehow this worked, even though the schematics are designed for the non-SMPS version. Sadly we have thrown away this MCU and can not check anymore what was written on it.

2) Since the H563 has some new ESD-protection compared to other MCU which we use like F207 or G474, there might be some leakage current induced because of our usual wiring which might work or might not work depending on some tolerances. On the G474 it is just some diods as protection and on the H563 it is called "ESD protection" but we could not find how this was implemented. I have put two screenshots below where you can see the difference.

There is propably no other solution for us than to rework the PCB so it matches the pinout of one of the mcu we use more frequently. Or we could try and buy an SMPS version. Both solutions will take a few days so we will propably do both.