STM32H743Z (LQFP144) GPIO not working on PC2_C and PC3_C?

[David Viens]

Moved a design from STM32F745Z to STM32H743Z (rev Y as thats the only thing ever available you know) 

with the help of CubeMX's "List Pinout compatible MCUs" and for the most part that went dandy except when trying to using PortC!

It took me a while to figure this out but PC2 and PC3 (which worked fine in F745Z) did NOT pulse or correctly (or read values) when setting those pin as Digital GPIO on H743Z

Backtracked a bit and noticed changes in the way PC2 (PC2_C) and PC3 (PC3_C) are described from TT_a and Analog only functions to a bunch of things in later revs of the datasheets.

My #1 request for a future build of CubeMX is to be able to quickly show which pins are FT_x and TT_x. THIS IS CRUCIAL FOR SYSTEM DESING and is NOT something that CubeMX knows at ALL.

We need a way to highlight all FT pins, all TT pins, etc. Especially if a pin was FT_x and it changed to TT_x in a subsequent MCU - this is NOT pinout compatible!

But back to my question, is there any way to salvage my boards and make PC2_C/PC3_C output 3.3V Push Pull? (my VCC is 3.3v)

My scope does not show any movement which pulsing PortC on those specific pins, which PC0,PC1,PC4,5,6,7 work just fine fine.

Tried messing with o PC2SO/PC3SO in SYSCFG_PMCR and that didn't change, the bits always read as 1's

Thanks for any info.

[David Viens]

More details (as suggested by a peer) as seen on ST_Link debugger after my app started:

0x58020800 is 0xFEAA5555 (PC0 to PC7 are GPIO)

0x58020804 is 0x00000000 (all of PC is push pull) so my init seems fine

[Uwe Bonnes]

PC2 and PC2_C also behave different with regard to package. UFBGA176+25 has remark (3) while TFBGA240+25 has remark (2) for the H745. (2) means that alternate functions are available when SYSCFG switch is closed,, while (3) is more vague. Different behaviour for different packages sounds strange. As PC2SO shows no reactio: Did you clock SYSCFG?

[David Viens]

Hi yes __HAL_RCC_SYSCFG_CLK_ENABLE() was called in void HAL_MspInit(void);

Right now I'm trying changing SYSCFG PMCR value directly in ST-LINK from 0x58020804= 0x0F000000 to 0x00000000 and that didnt change anything either.

Thanks for the suggestion!

[David Viens]

Last thing I tried was to change PC2_C/PC3_C 'S GPIO settings from PP to OD (and added a 10k res to VDD on each)... same results no I/O.

[SF??r]

Check Reference Manual: "Figure 73. Analog inputs connected to ADC inputs"

If the corresponding PC2 (without C) Pins are unused, you could properly close the PxSP Bit switch and config the pin (without _C) for your desired function.

[David Viens]

Hello Sebastian.

Sadly the LQFP144 version of this does not have the corresponding non _C pins. There is only PC2_C and PC3_C, while CubeMX thinks this is compatible with FT_ pins on previous generations. The MODER bits area already set to 01 (GPIO) so it shouldn't get to the the lower ADC link, while the PxySO bits dont seem to influence my results at all.

[MEdgerton]

This is useful as I just ran into the same issue as the FMC wants to use PC2_C as one of the pins controlling the SDRAM. I could see on the scope it wasnt right and thought it a failed board. Now I know its not.... but the config tool wont let me assign the signal to another pin. So does that mean on the 144 pin device you actually cant run the SDRAM?! Or how do I set the path. It says in the H743 there is a bit in SYSCFG but I cannot find it in the datasheet or cube MX.

This must be affecting a lot of people?

To quote the datasheet "Pxy_C and Pxy pins/balls are two separate pads (analog switch open). The analog switch is configured through a SYSCFG register. Refer to the product reference manual for a detailed description of the switch configuration bits. " But its not in the datasheet or set in the .ioc generated files or any way of doing it I can find ... and its not doing it by default. I would say its fixed in the silicon but my testing shows its clearly not.

Help please!

All help wanted!

Thanks,

Mark

[waclawek.jan]

And have you read the Reference Manual?

The switches are controlled by bits in SYSCFG_PMCR.

JW

[MEdgerton]

Hi JW, Thanks for the answer. Which manual do you refer?

Please bear in mind I am using auto generated code from STM32CubeIDE which should configure the IO properly (doe on the H746 and H767).

Its no th H743zi2 I hit issues....

I looked at the datasheet for H743zi which just had a footnote (6) on page 88/357 about PC2 and PC2_C through an analogue switch which should connect the two

I then found by enabling the ADC how to turn this switch on and off in the HAl as below:

HAL_SYSCFG_AnalogSwitchConfig(SYSCFG_SWITCH_PC2, SYSCFG_SWITCH_PC2_CLOSE);

then I found that __HAL_RCC_SYSCFG_CLK_ENABLE(); needs enabling, it should be from HAL_MspInit();. But it isn't in generated code.

So I added that as well.

PC2_C and PC3_3 are still not switching the SDRAM on the Nucleo board fast enough.

SDRAM on Nucleo-H743zi2 still not functioning.

After how many days on the H743zi and all these bits I am a bit concerned about whats going on. The H767 SDRAM (same chip same conig and set to same clock speeds) all worked easily).

There is something clearly wrong with the code eneration or setup of SDRA on Nucleo-H743zi2 FW1.9.0. I have tried 2 Nucleo boards and 2 memory chips incase something was faulty.

The slow switching of PC2 (PC2_C) for the chip enable clearly shows the .ioc code generation is missing something. So I have tried to permanently enable the /CS but I need to check that this is OK to do. But also if this pin isn't configured by the code generator, I now have little confidence that other pins and settings are actually being set correctly. That would explain why the F767 works with the SDRAM and not the H743zi as I have tripple checked everything over the last week.

If you have any pointers great, as for once this makes no sense.

I cannot even get PC2_C switching at fast speeds, which the STM32CubeIDE thinks it should do.

My extra code to try to make this work is:

__HAL_RCC_SYSCFG_CLK_ENABLE();

 HAL_SYSCFG_AnalogSwitchConfig(SYSCFG_SWITCH_PC2, SYSCFG_SWITCH_PC2_CLOSE);

 HAL_SYSCFG_AnalogSwitchConfig(SYSCFG_SWITCH_PC3, SYSCFG_SWITCH_PC3_CLOSE);

 __HAL_RCC_SYSCFG_CLK_ENABLE();

If you could help I would really appriciate it. I know the code generator can mis things, but I am running out of things to check.

Thanks again,

Mark

[MEdgerton]

Update:

I have PC3_C working at high speed. But not PC2_C (PC2). I cannot see any reason why this is not working now. I believe this to be a low-level ST bug in firmware or something. I built a project from scratch and can show this on the scope just tolling IO pins PC0. PC2, PC3. PC2 does not work at high speed. Nothing other than a scope connected.

Can someone double check this. How do I report a suspected bug to ST?

[heveskar]

We have seen the same problem.

https://community.st.com/s/question/0D53W00000xpDZLSA2/stm32h735v-lqfp100-pc2c-and-pc3c-speed

You are correct, it is a hardware issue.

[Mohammed Eshaq]

I am working on a project, and was trying to use PC2_C as a GPIO_EXTI and just realized that this particular pin doesn't generate interrupt signal, meaning, your ISR will not be called for this particular pin. I had to change the layout and use another pin as a GPIO_EXTI to continue.

I was able though to use it as an GPIO Input but performance was a bit weird.

I believe this is a bug that must be reported to STM; If the pin cannot be used as a GPIO or GPIO EXTI then the CubeMX tool should block/not allow you to select these option for this pin.