2024-11-11 10:55 PM - last edited on 2024-11-11 11:00 PM by SofLit
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.
Solved! Go to Solution.
2024-12-12 11:07 PM
Hi Rajkumar24
Thank you for your video ! Happy to read that your application is working.well.
1- I suppose you connected D+/D- from X-NUCLEO-DRP1M1 CN10-12 and CN10-1.
If yes, this is correct, R19 and R20 are present.
The difficulty I see is that using free wires we don't respect anymore the 90Ohms differential pair.
2- I confirm, the battery charge has to be managed from the X-Nucleo-DRP1M1 sink (screw terminal).
Here is an application block diagram:
Best regards
Pascal
2024-11-12 02:29 AM
Hi @NajeemSyed
Given your requirements, and as of the progress of certification of power delivery, I recommend using TCPP03 with STM32U5 MCU.
X-CUBE-TCPP V4 package, is certified for USB-PD 3.1, providing support for the latest USB Power Delivery specification. So, by leveraging the strengths of both the TCPP03-M20 and the STM32U5 MCU, you can achieve a robust and efficient power delivery solution.
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.
2024-11-13 05:15 AM
Subject: Issue with USB Data Transfer and Battery Charging on STM32U575ZI
Hello,
We are working on implementing a dual-role USB Power Delivery (USBPD) setup with an internal battery. The system is designed so that when an external charger is connected to the STM32U575ZI, it charges the internal battery. However, when the STM32U083RC (external device) is connected to the same USB port, the STM32U575ZI provides power to the STM32U083RC. This is the expected behavior for our application.
**Hardware Setup:**
We are using the TCPP03-M20 USB Type-C Power Delivery protection IC for dual-role power application, as outlined in this [ST link](https://www.st.com/en/protections-and-emi-filters/tcpp03-m20.html?ecmp=tt9470_gl_link_feb2019&rt=db&id=DB4442).
For testing purposes, we are using the X-NUCLEO-DRP1M1 expansion board and following the steps from this [video tutorial](https://www.youtube.com/watch?v=mJ4VX_2B6wE), which uses the STM32G071RBT.
However, we have encountered two main issues:
1. **X-NUCLEO-DRP1M1 options not appearing in STM32CubeMX for STM32U575ZI:**
We are unable to enable the X-NUCLEO-DRP1M1 options in STM32CubeMX for STM32U575ZI, as shown in the video tutorial (see attached picture).
2. **DMA configuration not available for STM32U575ZI:**
While the DMA options are available and configurable when using STM32G071RBT, they do not appear for STM32U575ZI. We are unable to enable DMA options for Nucleo board STM32U575ZI, as shown in the picture.
NOTE- same we tried with custom PCB we are getting same result.
Could you please advise on how to configure the X-NUCLEO-DRP1M1 and enable DMA on Nucleo board STM32U575ZI?
2024-11-14 03:01 AM
Dear NajeemSyed
X-NUCLEO-DRP1M1 are in Nucleo-64 form factor so it is dedicated to be plugged directly on a NUCLEO-G0xx or G4xx.
this is ony in this case that you can use the X-NUCLEO-DRP1M1 BSP.
Then in your case, you have to define required resources :
- I2C
- GPIO Out for Enable
- EXTI for FLAG
- At least 1 ADC Channel for Vbus
And in the X-Cube-TCPP software pack, "Platform settings" affect these resources to the application requirements.
The video is using STM32G0xx MCU in its example. This MCU is using DMA,
For STM32U5 go to the GPDMA page.
Best regards
Pascal
2024-11-26 10:40 PM
Hello,
We followed the tutorial from the STM32 website (link provided below). However, after following the tutorial(custom board / other than G series necleo board) ,the module not works as a dual-role device. I have attached a battery to the source terminal, but if i connect device to module that devices are not powered by the module.
Key Differences in implementation steps in the link
ADC Prescaler Setting
- In the tutorial, the ADC prescaler is set to "Synchronous Clock Divider by 4," and "Sampling Time Common 1" and "Sampling Time Common 2" are configured with 160.5 cycles. However, this option is not available for the STM32U575ZI necleo board.So ,Instead of the above points We used "Asynchronous Clock Divider by 4." And Configured "Sampling Time Common 1" and "Sampling Time Common 2" to 814.5 cycles.
Free RTOS
- We allocated 7000 bytes for FreeRTOS heap memory, as per the tutorial.
- The tutorial specifies the CMSIS V1 interface, but this option is not available for the STM32U575ZI necleo board in stm32 cube IDE.
Could this difference impact functionality?
Also we installed the STM32CubeMonUCPD software for analyze to monitor and configure USB Type-C and Power Delivery applications but no data coming in the software.( https://www.st.com/en/development-tools/stm32cubemonucpd.html )
Please find Attached are images of the tutorial, our IOC configuration, and the schematic of the USB connections.
Please review and assist us in moving forward with the implementation of USBPD dual role. Could you also guide us on the necessary steps to connect the X-NUCLEO-DRP1M1 board with the NUCLEO-U575ZI-Q? Specifically, we would like to know the required hardware and pin connections for this setup.
Thanks
2024-11-27 05:48 AM
Hello NajeemSyed
All the differences you noticed are normal and MCU dependant.
Your ADC Configuration looks good, maybe you can reduce the sampling time to a medium value (My setting : 79.5 Cycles). But this is not critiical.
Your are using "X-CUBE-FREERTOS" because native FREERTOS (used for the G0 demo) is not available for this MCU.
Please can you try with Native ThreadX instead ?
STM32CubeMonUCPD is an excellent tool to diagnose the USBPD.
Please find attached the .ioc file for a DRP application on a U585AII-DK to compare.
Feel free to share your .ioc,
Best regards
Pascal
2024-11-27 08:14 AM - edited 2024-11-27 09:24 AM
Hi Pascal,
Thanks for your input.
My self rajkumar, a team member of NajeemSyed,
Sure, we will update the ADC settings and perform a test.
Regarding RTOS, our application uses AWS IoT Cloud, and all the sensors are running on FreeRTOS. As such, we have opted for FreeRTOS instead of Azure RTOS (ThreadX).
1.Could you recommend how to integrate USB Power Delivery (USBPD) Dual Role functionality with FreeRTOS for our application?
2. the NUCLEO-U575ZI-Q board, which already has the TCPP01-M12 PD sink IC. We are now trying to connect it to the TCPP03-M20 for dual-role PD functionality. Will this setup cause any issues when connecting to the X-NUCLEO-DRP1M1 board with the NUCLEO-U575ZI-Q?
If yes, could you guide me on how to resolve this? Specifically, we would like to know the required hardware and pin connections for this setup.
Please find attached our .ioc and project files for your reference.
Thanks
Regards
Rajkumar S.
2024-12-02 10:59 PM
Hi Rajkumar24
1- We are working on the issue you are facing about X-CUBE-FREERTOS on USBPD applications for STM32U5xx. For the moment I would advise to make your first tests using AzureRTOS. We will come back to you with a solution.
2a - For dual role PD functionality using the X-NUCLEO-DRP1M1.
- First you have to disconnect the CC1 and CC2 lines of the UCPD periheral to re-route them to the DRP1M1.
To do this the best for me is to unsolder the TCPP01, because you can open the CC1 line opening SB42 but there is no way for CC2.
- Then you have to affect with free wires:
from X-NUCLEO-DRP1M1:
- 3V3 (SN7-16) to the NUCLEO-U575IZ 3V3 (CN8-7)
- I2C_SCL (CN10-3) to a NUCLEO-U575IZ I2C-SCL (for example I2C_A_SCL (CN7-2)
- I2C_SDA (SN10-5) to a NUCLEO-U575IZ I2C-SDA (for example I2C_A_SDA (CN7-4)
- ENABLE (CN10-2) to a NUCLEO-U575IZ GPIO Out
- FLG (CN10-37) to NUCLEO-U575IZ GPIO EXTI
- CC1 (CN10-17 or 23) to the NUCLEO-U575IZ CC1 (CN11-17 = PA15)
- CC2 (CN10-26 or 27) to the NUCLEO-U575IZ CC2 (CN12-26 = PB15)
- ADC Vbus (CN7-28) to a NUCLEO-U575IZ ADC Channel
Optional:
- ADC I (CN7-36) to a NUCLEO-U575IZ ADC Channel
- ADC Vprov (CN7-30) to a NUCLEO-U575IZ ADC Channel
- ADC Vcons (CN7-32) to a NUCLEO-U575IZ ADC Channel
2b - Switch to the STM32U575I-EV - Evaluation board with STM32U575AI MCU - STMicroelectronics
- Already includes the STM32U575AI
- Already includes the TCPP03
It should be easier to start with it.
Best regards
Pascal
2024-12-03 10:55 AM
Hi Pascal,
Thank you for the update and your advice to use AzureRTOS for the initial tests. I will proceed with it as suggested. Please let me know once you have a solution for the X-CUBE-FREERTOS issue on USBPD applications for STM32U5xx.
Looking forward to hearing from you.
Thanks,
Best regards,
Rajkumar
2024-12-07 05:20 AM
Hi Pascal,
As per your guidance, we are using the Azure RTOS Dual Role code to test the Dual Role functionality on the U575ZI board.
- Based on our previous conversation, I downloaded the `U5_DRP_Cube.ioc` file and used it as a reference (after converting it to U575ZI since the attached IOC is for U585) to implement Dual Role on the U575ZI. However, after uploading the generated code, the DRP1M1 board does not function as a Dual Role device and does not show as a COM device in the UCPD monitor.
- I have attached the `U575ZI_DRP_Cube.ioc` file, which has been modified for the U575ZI board, for your reference.
- I noticed that in the `U5_DRP_Cube.ioc` file, only ThreadX and USBPD are enabled under the Middleware tab, but X-TCPP is not enabled.
- Additionally, I could not enable USART1 at 921600 baud rate, so I configured LPUART1 at 921600 on the U575ZI.
Please review the attached IOC file and guide us on how to implement the Dual Role functionality.
Please let me know once you have a solution for the X-CUBE-FREERTOS issue on USBPD applications for STM32U575.
Note:For our learning purpose, we connected the X-NUCLEO-DRP1M1 board to an STM32G0 board and successfully implemented the PD Dual Role functionality, which worked perfectly.