HSI off by 9% and PC1 can't be driven correctly on custom H573 board

[strulzl]

I'm bringing up a design based off the STM32H573 and I believe I'm having a number of issues that are probably sharing a common thread with bad hardware. I don't usually screw those things up, but I guess I got unlucky this time.

1) PC1 when configured as a (GPIO) output cannot drive a load. Works as a GPIO input. Sometimes, when configured as output after configuring it as input, it would start working and then die (this happened twice in two days). Pulls, OD, nothing seems to make a difference. Replicated over two boards -- the second board with no ESD damage possible. 

2) HSI seems to be off by 9% (HAL_Delay and UART are showing this error). Tested on one board only. 

Here is my schematics:

In my actual board, both VCAPs are not tied together. They are also not placed on the bottom of the board -- rather they are connected via a 0.1mm trace 3.5mm long to the edge of the BGA to the capacitor. Altium is saying this can carry 0.6A I guess impedance is bad and it might be the source of some of my issues (I can decrease the op frequency if so).

I also didn't place the bypass capacitors on the bottom of the board, but as the vias were there, I managed to add them manually (scrape soldermask on vias etc). It didn't make any difference I could see. 

I'm really lost here. I think the issue must be hardware, but what should I try to fix it? I can't imagine a failure mode that fries the same GPIO on two boards and offsets HSI... But maybe the HSI is random and the GPIOs were fried by something connected externally -- aka the STM design is actually acceptable?

[TDK]

HSI has been known to be off from the factory before on some chips, despite claims in the datasheet that it is calibrated at the factory. It is trimmable, but probably not enough to make up 10%. See if your code is applying a trim at all. See if HSICAL has any value at all. A 0 might indicate it was not trimmed at all.

Note that HAL_Delay is not an exact delay. But if you did HAL_Delay(1) in a tight loop and toggled a pin, you should see it toggle every 2ms on a scope. Routing MCO out would be a better test.

Design seems fine to me. Don't think anything there will affect HSI. Bypass caps should be 0.1 uF, not 1 uF. Probably fine, however.

Don't see any details about PC1 connections. Comparing IDR and ODR values may shed light. If it's shorted to something, output will not work. Should see a ~20mA current draw increase as it tries. GPIO pins aren't flaky. Gotta be something specific to your setup.

[Andrew Neil]

---

@strulzl wrote:

2) HSI seems to be off by 9% (HAL_Delay and UART are showing this error). ?

---

9% seems excessive but, in general (not just STM32), internal RC oscillators are not very accurate - best avoided if accurate timing is required, eg for UARTs

[strulzl]

Hey TDK, thank you for all your answers I read in the past.

Ok, sorted on HSI then. I'm now moving from HSI to HSE after the external clock is available. 

This leaves the GPIO pin.

I did compare IDR and ODR before, on PC0 vs PC1, to have a comparison, and ofc, ODR=1 IDR=0 on PC1 only. I can easily pull it up/down with a 20k resistor but didn't check IDR with the pull (PC1 works well when set as an input). The registers (direction, AF, etc), are all fine, the only difference might be that PC1 is marked as HSLV but I'm feeding 3.3V to the STM so HSLV should be disabled (3.3V is set in CubeMX). TZ is also off, but I did create the project with TZ enabled inside STM32CubeMX. 

I replaced the chips with new ones from Digikey, and when doing so checked that the GPIO line was floating. Even with a new chip soldered onto the PCB, I'm seeing the same behavior: cannot drive, but can read the line. 

I also bought a STM32H573 dev board and my code worked fine there. The package is slightly different, I have the STM32H573IIK6 so pinout is not the same as the dev board (ldo vs smps). 

I think it's a solid mistery. 

[waclawek.jan]

> HSI has been known to be off from the factory before on some chips

While this might've been the case for some STM32, what I remember is, that Cube set HSITRIM improperly.

> PC1 is marked as HSLV but I'm feeding 3.3V to the STM so HSLV should be disabled (3.3V is set in CubeMX)

This too, may be prone to the click-to-code errors. RM says:

The I/O HSLV configuration bit must not be set if the I/O supply (VDD or VDDIO2) is above
2.7 V. Setting it while the voltage is higher than 2.7 V can damage the device.

So, what I'd recommend, is to double-check the HSLV-related fuses, and then write an absolutely minimal testing code, with no Cube/CubeMX involved, no clock setup (i.e. clocks at default) etc., setting up the GPIO manually, just the good old plain loopdelay blinky. HSI frequency can be checked through outputting it onto a MCO pin.

JW

[strulzl]

Hey, I followed those recs. 

Here are the option bytes showing HSLV is disabled: 

And here is the simple code I'm using:

int main(void)
{
	 GPIO_InitTypeDef GPIO_InitStruct = {0};

	__HAL_RCC_GPIOC_CLK_ENABLE();

#if 1

	/*Configure GPIO pin Output Level */
	HAL_GPIO_WritePin(RSTBTN_GPIO_Port, RSTBTN_Pin, GPIO_PIN_RESET);

	/*Configure GPIO pin : RSTBTN_Pin */
	GPIO_InitStruct.Pin = RSTBTN_Pin;
	GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	HAL_GPIO_Init(RSTBTN_GPIO_Port, &GPIO_InitStruct);

	/*Configure GPIO pin : PWRBTN_Pin */
	GPIO_InitStruct.Pin = PWRBTN_Pin;
	GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	HAL_GPIO_Init(PWRBTN_GPIO_Port, &GPIO_InitStruct);

	while(1) {
		HAL_GPIO_WritePin(PWRBTN_GPIO_Port, PWRBTN_Pin, GPIO_PIN_SET);
		HAL_GPIO_WritePin(RSTBTN_GPIO_Port, RSTBTN_Pin, GPIO_PIN_SET);
		for(int i =0; i < 100000; i ++) { __NOP(); }
		
		HAL_GPIO_WritePin(PWRBTN_GPIO_Port, PWRBTN_Pin, GPIO_PIN_RESET);
		HAL_GPIO_WritePin(RSTBTN_GPIO_Port, RSTBTN_Pin, GPIO_PIN_RESET);
		for(int i =0; i < 100000; i ++) { __NOP(); }
	}

When configuring the troublesome pin as input fed via a siggen I get a perfect waveform out using this code (plus appropriate pin configuration):

while(1) {
			  GPIO_PinState pwrbtn_state = HAL_GPIO_ReadPin(PWRBTN_GPIO_Port, PWRBTN_Pin);

			  if (pwrbtn_state == GPIO_PIN_SET)
			  {
				HAL_GPIO_WritePin(RSTBTN_GPIO_Port, RSTBTN_Pin, GPIO_PIN_SET);
			  }
			  else
			  {
				HAL_GPIO_WritePin(RSTBTN_GPIO_Port, RSTBTN_Pin, GPIO_PIN_RESET);
			  }
		}

 What's weird to me is that I'm using 50% of the pins in the package and everything else works... Expect PC0. There might be more issues I didn't detect (struggling with bringup a bit, complex system), but I couldn't find anything yet broken past this pin.

I'm tempted to just change PC0 to another pin and send the PCBs again for manufacturing but everything inside me screams don't do it.