STM32U5A5: PB5 and PB15 - failing (for your errata sheet?)

[tjaekel]

Dear STM team,

I am debugging the chip since hours and I think there is something wrong with the PB5 and PB15 pins:

1. SPI1 with MOSI on PB5:

I have configured SPI1 and want to get the SPI1_MOSI on PB5 (as mentioned as ALT5 in datasheet).
I use a STM32U5A5 with LQFP64 package.

Nothing comes out as MOSI (constant high, no bit pattern driven by SPI1).

But:

• if I configure PB5 as GPIO - I can toggle - OK, no shorts on PCB
• I can also use the SWAP function for SPI - now MOSI comes out on PB4 (which was MISO) - all OK (SPI1 works - MOSI is now out on PB4)
• I can also use MOSI on PA7 - also fine!

Just:
PB5 is NOT a SPI1_MOSI as mentioned in datasheet!

And: if I connect with SWAP configured (PB4 is MOSI) with PB5 (now as MISO): the waveform is damaged!
There are not anymore nice bits out of MOSI: so, the PB5 seems to be driven all the time, with something else (see below on Remarks).

2. PB15: if high - USB fails

I want to use PB15 as GPIO.
When I configure as GPIO and set as low (RESET pin value) - fine (USB comes up).

But when I set this GPIO pin PB15 to high - the USB fails! No enumeration anymore, my USB VCP UART is gone.

I have also realized: playing with these pins, setting these to the "wrong" GPIO state, it can make my debugger (SWO) failing: I can flush, but the USB VCP does not connect. The debugger stops (loses connection). I can disconnect debugger, reset the board and now VCP works (but no way to debug right after flushing the MCU).

BTW: what works on PB15 is: set it to low - the USB VCP UART comes up and the debugger is fine.|
I can toggle "later" (when all is up and running) this GPIO pin (configured as GPIO out): it works, I can set low and high without to lose USB. But just after all is up and running, not on startup (e.g. via MX_GPIO_Init();)

If PB15 is high on startup config - the USB is dead.

What is this?

Remarks

I have found in datasheet this remark:

"After reset, a pull-down resistor (Rd = 5.1 k
Ω from UCPD peripheral) can be activated on PA15 and PB15 (UCPD1_CC1, UCPD1_CC2). The pull-down on PA15
(UCPD1_CC1) is activated by high level on PB5 (UCPD1_DBCC1). The pull-down on PB15 (UCPD1_CC2) is activated by high level on PB14 (UCPD1_DBCC2).
This pull-down control (dead battery support on UCPD) can be disabled by setting UCPD_DBDIS = 1 in the PWR_UCPDR register."

I do not know what does it mean. But it sounds to me as: "PB5 and PB15 have also other special functions, related to USB" (what I see). Even I do not configure and enable UCPD (nothing with USB-C, just regular USB HS PHY for USB VCP), there seems to be a "side effect":

PB5 is never working as SPI1_MOSI and PB15 must be low for USB config/start-up.

What is wrong?

Also my impression:
if this happens, a GPIO pin seems to drive against something, or it is shorten to GND when driven high - my VDD voltage (running with 1V8) seems to drop a bit, e.g. to 1.79V (usually it is 1.804V): if this seems to happen (even USB VDD is 3V3) - the USB connection fails.

So, a "pin conflict" seems to draw a bit more current, to drop a little bit the 1V8 VDD and now it starts failing on USB. Very sensitive to run with 1V8. And hard to debug! I lose debugger in this case. OK: possible that dropping below 1V8 as VDD makes the ST-LINK debugger (external STLINK-V3SET) to fail (maybe ST-LINK issue, not the chip itself).

Please, ask your RTL designers what is going on with PB5 (for SPI1_MOSI) and PB15 (for USB function, when driven high at startup).

Thank you,

 

 

 

 

[waclawek.jan]

> This pull-down control (dead battery support on UCPD) can be disabled by setting UCPD_DBDIS = 1 in the PWR_UCPDR register."

So, have you tried to set PWR_UCPDR.UCPD_DBDIS = 1?

JW

[tjaekel]

I tried, fails like before:

I do:

HAL_PWREx_DisableUCPDDeadBattery();

which should set this bit to 1:

SET_BIT(PWR->UCPDR, PWR_UCPDR_UCPD_DBDIS);

But if I configure still my PB15 GPIO as "high" on startup - it fails as before (no USB)!

 /* PB15 is CODEC SHDNZ - release the CODEC */
 /** something wrong: if we do - USB is dead, voltage 1V8 is too low... */
 /* USB fails if this is high at start ! */
 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_SET); //IT MUST BE _RESET!!
 GPIO_InitStruct.Pin = GPIO_PIN_15;
 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

No change.

It is actually ok (for me):

• if I make sure: PB15 is low on startup (when all my stuff including AZURE RTOS which starts USB is done)
• later, I can toggle and use PB15 as normal GPIO (it works) - when my USB VCP UART is there (toggling is done via VCP UART command line)
• but I cannot set PB15 high during startup (before USB is running)!

PB15 is OK for now (just suspicious): when USB VCP is up - I can toggle PB15 (but not before USB is up and running). Not a big deal: I need PB15 as GPIO to release external chip (PCMD3180) from standby mode.

Just strange what PB15 does on startup (why does it "kill" my USB when it is set to high "too early")?

The remaining "big issue" is:

Why is PB5 not working as SPI1_MOSI?

I did a patch on my PCB, using PA7 (instead of PB5) - and all works (I can talk to my PCMD3180).

This PB5 as SPI1_MOSI is a much bigger concern.

[AScha.3]

From the note in ds :

As i understand :

PB5  lo at startup -> no pulldown on PA15;   (and vice versa)

PB14 lo at startup -> no pulldown on PB15;  (and vice versa)

So try pulldown (10k or so) on PB5 + PB14 , to not activate the ucpdxx functions at start/reset.

[waclawek.jan]

> I do:

HAL_PWREx_DisableUCPDDeadBattery();

> which should set this bit to 1:

SET_BIT(PWR->UCPDR, PWR_UCPDR_UCPD_DBDIS);

And does it? Have you read back PWR_UCPDR to check its content? Have you enabled PWR clock in RCC before?

JW

 

[MM..1]

Primary check with scope what is on your pins on reset. Pins to check describe note or @AScha.3 

[tjaekel]

OK, I have it working: the "trick" is: enable SPI1 after USB is up and running (not before). Even trying these PWR configs and disabling HAL_PWREx_DisableUCPDDeadBattery(); was not solving the issue. Just: initialize SPI1 with nSS on PA15 and SPI1_MOSI on PB5 after USB is up and running (SPI1_MOSI on PA7 has no issues, just PB5 as SPI1_MOSI).

Details:

PB5 = SPI1_MOSI - no pull-up/pull-down there (floating at reset) - there should not be any pull-up/pull-down, as my intention
PB14 = I2C2_SDA - there is a pull-up (for open drain I2C2_SDA) ! I cannot make it a pull-down!
PA15 = SPI1_NSS - no pull-up/pull-down - but: I see that NSS signal is released between SPI1 transaction:
                               even enabling pull-up on SPI1 PA15 config - does not solve the problem (just an external pull-up does!)
PB15 = my PCMD3180 CODEC SHDNZ signal: it has a pull-down (to keep CODEC in sleep mode until power is up and stable, CODEC is released later via a command) - this works fine.

So, I cannot make other changes on my PCB (schematics), esp. not PB14 or PB5 with pull-downs.

Conclusion:

If you want to use PB5, PA15 (for SPI1) - make sure to initialize SPI1 just after USB came up and is running. Any configuration done for SPI1 before USB works will "kill" your USB, and even the debugger SWD connection.

Dear STM team:

This tiny foot note with the behavior of these pins should be a clear statement in text, "that PB5 and PA15 on power-up have a significant meaning and effect in combination with using USB". They cannot be assumed as regular GPIOs (or for SPI1) when also USB is used. They do not behave like "free" GPIO pins (they have a function on power-up impacting the behavior of USB).

Why is NSS floating between transactions?

So far, fine. But why is SPI1_NSS released between transactions?
Even I configure with GPIO_PULLUP for PA15 - it seems to be floating (going to low on scope). Just an external pull-up fixes the issue (to keep NSS high all the time, what I want to see).

[AScha.3]

>Why is NSS floating between transactions?

Maybe because you didnt "tell" Cube , what you want ?

you can set pin pullup:

and/or keep line state activ:

+ then : its still not doing, as you want it ?

[FBL]

Dear @tjaekel 

Similar issue has been reported but in different context : Solved: Re: FDCAN PB6 problem with low state under reset o... - STMicroelectronics Community

Indeed, these pins are special since they have additional function as stated in datasheet and USB depend on them for proper operation. Internal pullup in the context of CC1/CC2 will not behave as expected when UCPD_DBIS in PWR_UCPDR is enabled. It has a pull-down effect on CC1 and CC2 pins. So, it is recommended to disable dead battery functionality to handover control on this pull down.