USB PD Part selection

[NajeemSyed]

Hello,

I'm working with the STM32U575VGT6 as my primary MCU and need a USB-C DRP PD IC. I'm considering the TCPP03-M20 or STUSB1600AQTR. My question is, when the PD operates in sink mode (during charging), we intend to turn off all power supplies, including the MCU. Is it possible to use these ICs in sink mode without the MCU? Additionally, we need the PD to act as a source when external peripherals are connected to this board through USB-C.

[Rajkumar24]

Hi Pascal,

Thanks now battery charging working.

Thanks for the circuit, we are following same connection. We also added the twisted wire (we take from external usb cable) and soldering to between the two boards.still usb host not working but usbpd dual role working.while debugging we came to know Issue with osKernelStart Triggering Automatically in UCPD Implementation.

While integration to usb host code ,UCPD functionality is working correctly, but I am facing an issue with osKernelStart. Despite not explicitly calling osKernelStart in my code, the function is still being executed, and it subsequently triggers vTaskStartScheduler(). I have verified and commented out all instances of osKernelStart in the code, but the issue persists—it appears that osKernelStart is being called from elsewhere, leading to the scheduler's start. This behavior is preventing me from taking control of my operating system.

could you please provide clarity on whether any UCPD-related software or driver could be invoking this function? For reference, I have attached an image for your review.

Looking forward to your guidance.  

Best Regards 

Rajkumar 

[PPAIL.1]

Hi NajeemSyed,

 

1- osKernelStart is starting declared threads. Nothing below is executed.

You have to declare a new thread, start it and work independently in this new thread for your own application.

 

2- Schematic review

- You can adjust R59 (Current sense) depending on the maximum current your application will sustain to gain in precision. Ensure you keep : max_application_current * R59 * 42 < 3.3V. (42 is the TCPP analog gain, 3.3 is the maximum ADC voltage). 

- I would advise to review your bridge resistors R60/R62, and R61/R63 :

R60 and R61 should be higher than R62 and  R63 , in the X-NUCLEO-DRP1M1 : 200k and 40.2k in some Nucleo and DK we use 300k and 50k  to reduce losses.

The B-U585I-IOT02A can be a another good example.

 

Best regards

Pascal

 

[PPAIL.1]

Correction about my last message:

2-- You can adjust R59 (Current sense) depending on the maximum current your application will sustain to gain in precision. Ensure you keep : max_application_current * R59 < 42mV. (42mV is the OCP threshold). 

[NajeemSyed]

Hi,

 

Thanks for your reply. I have following queries regarding schematics:

 

1. I have used 200K/40.2K for VBus ADC sense and connected this to STM ADC Pin. 

2. I have also connected Pin IANA of TCPP03 (USBPD IADC) pin to STM ADC. 

3. What should i connect in PA9 of STM32U575. (USB_OTG_FS_VBUS). Our device is battery powered device and USB is hot swappable dual role application. Should i connect the Vbus or Vprov or Vcons here?

4. The EN pin (pin 20) of TCPP03 is hard wired to 3.3 V through a Pull Up (R54). (Always high) instead of GPIO. But while using a Development Board we face a issue that it is sometimes not detecting the USB

[PPAIL.1]

Hi NajeemSyed

 

1. 200k/40.2k for Vbus ADC is ok

2. Iana to ADC is ok (Not mandatory)

3. This pin is not related to USBPD.
The USBPD application needs at least Vbus connected to an ADC.

Others (Isense, Vprov, Vcons) are optional at the X-Cube-TCPP point of view and depending on your application needs.

4. You can connect the EN pin of TCPP03 to 3.3V

(There is a warning in the X-CUBE-TCPP platform settings but it is ok)
The issue you are facing is USB or USBPD related ?

 

Best regards

Pascal

[NajeemSyed]

Thanks for the response. 

we have few queries:

1. For USBPD based Batttery power applications, what should we connect on STM32U575 MCU PA9 pin (USB_OTG_FS_VBUS)

2. When we are testing the same firmware with having EN pin pulled up, we are facing some issues while running. Like after 5-6 operation cycles, it's not working until MCU is reset. 

[PPAIL.1]

Hi NajeemSyed

 

1. For the USB_OTG_FS_VBUS pin , the forum below may help you:
Solved: STUSB1600 (USB Type-C) and USB OTG - STMicroelectronics Community

 

2. We reproduced the behavior you have. We made an internal request to resolve this issue. We will get back to you.

 

Best regards

Pascal

[NajeemSyed]

Hi,

Any updates on this thread? We are still facing same issue with and without a pull-up resistor across EN pin

[PPAIL.1]

Hi  NajeemSyed

Could you please update STM32CubeMX to the latest version (1.15.0) and X-CUBE-FREERTOS to the latest version (1.3.1) and try again ?

If this still doesn't work, and only to validate the hardware USBPD part, as I know this isn't the right RTOS for your application, try again using the STM32U5's native RTOS: AzurRTOS (ThreadX). Please let us know the result.

Sincerely,

Pascal

 

 

[NajeemSyed]

---

Could you please update STM32CubeMX to the latest version (1.15.0) and X-CUBE-FREERTOS to the latest version (1.3.1) and try again?

 

---

 We have already tried with these versions, and here the UCPD itself is not working.We have already tried these versions, and the UCPD is not functioning.

---

If this still doesn't work, and only to validate the hardware USBPD part, as I know this isn't the right RTOS for your application, try again using the STM32U5's native RTOS: AzurRTOS (ThreadX). Please let us know the result.

 

 

 

---

We have already developed entire application with FreeRTOS. You have mentioned earlier that you have recreated this issue internally, have you found any solution for that? Is there any way we can resolve this in FreeRTOS itself.

[PPAIL.1]

Hi @NajeemSyed

Sorry for my very late reply, I was waiting for the latest component releases to see if they would improve the behavior.

So I reconsidered the problem from the beginning:
I finally resolved the issue on my side under following conditions :

My setup:
- Hardware : NUCLEO-U575ZI + X-NUCLEO-DRP1M1
- Tools : STM32CubeMX 6.16.0
- Software : X-CUBE-TCPP 4.2.0, X-CUBE-FREERTOS 1.2.0

I think we are experiencing the same problem because we are both working on two evaluation boards connected together by long wires.
I stabilized the behavior by shortening the wires between the NUCLEO and the X-NUCLEO-DRP1M1 and also improving the GND connection between the two boards.
- I placed the X-NUCLEO-DRP1M1 above the NUCLEO to shorten wires
- I changed the ADC channel for Ch5 to Ch7 in order to achieve a very short connection
- I ducplicated the GND connection (from SNK Connector GND to NUCLEO GND)

I attach a picture of these boards

I also attached the .ioc of my solution with the following allocated resources:

X-NUCLEO-DRP1M1	Signal	NUCLEO-H575ZI
CN7-8	GND	CN11-8
CN2-GND	GND	CN14-1
CN7-16	VDD	CN11-16
CN10-23	CC1	CN11-17  PA15
CN10-26	CC2	CN12-26  PB15
CN10-2	EN	CN12-29  PB5
CN10-37	FLG	CN12-40 PE8
CN7-28	VBUS	CN11-59  PG0
CN10-3	I2C2-SCL	CN11-51  PF1
CN10-5	I2C2-SDA	CN11-53  PF0

 

I tested this configuration for a while without encountering any problems.

------------------------------------

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.