STM32G0 + X-NUCLEO-SRC1M1 Not Detecting Sink Negotiation Message

[mlu0708]

Hi,

I'm a researcher at MIT and I'm pretty new to the ST world, I'm working on a USB power delivery application for a robotics project where I would like to use an STM32 MCU + an X-NUCLEO-SRC1M1 to deliver 20V over USB-C (as well as data over D+ and D-) to a Sparkfun STUSB4500 USB-C Power Delivery Board (https://learn.sparkfun.com/tutorials/power-delivery-board---usb-c-qwiic-hookup-guide).

Issue:

After plugging in my STUSB4500 sink board, there is no negotiation completed. The source is able to send out it's power delivery capabilities, but no messages are received from the sink in the traces of STM32CubeMonitor.

OUT	471419	0	SOP	 PD3	s:010	 H:0x27A1 	(id:3, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11880	
OUT	471421	0	SOP	 PD3	s:010	 H:0x27A1 	(id:3, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11881	
PE	471423	0	PE_SRC_DISCOVERY	11882	
PE	471573	0	PE_SRC_SEND_CAPABILITIES	11883	
OUT	471575	0	SOP	 PD3	s:010	 H:0x29A1 	(id:4, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11884	
OUT	471576	0	SOP	 PD3	s:010	 H:0x29A1 	(id:4, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11885	
OUT	471578	0	SOP	 PD3	s:010	 H:0x29A1 	(id:4, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11886	
PE	471580	0	PE_SRC_DISCOVERY	11887	
PE	471730	0	PE_SRC_SEND_CAPABILITIES	11888	
OUT	471732	0	SOP	 PD3	s:010	 H:0x2BA1 	(id:5, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11889	
OUT	471733	0	SOP	 PD3	s:010	 H:0x2BA1 	(id:5, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11890	
OUT	471735	0	SOP	 PD3	s:010	 H:0x2BA1 	(id:5, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11891	
PE	471737	0	PE_SRC_DISCOVERY	11892	
PE	471887	0	PE_SRC_SEND_CAPABILITIES	11893	
OUT	471889	0	SOP	 PD3	s:010	 H:0x2DA1 	(id:6, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 0A9001002C410600	
Option: 	
 [1] Fixed : 5V - 0.1A
 [2] Fixed : 20V - 3A
	11894	

On the oscilloscope, the sink board gets a 20V spike that then decreases since the power delivery negotiation never finishes.

I do not think  this is a sink issue as connecting the sink to a USB-C Dewalt charging power brick that delivers 65W can provide a sustained 20V after 5V. The negotiation seems to complete itself.

Hardware Setup:

I've connected a 20V supply to CN3 of the SRC1M1 board and validated 20V is going into the terminal. A USB-C power cable is connecting CN1 to the Sparkfun power delivery sink board. A Micro-USB cable connects the STM32 NUCLEO-G0B1RE MCU to my computer to view debug logs. I connected the oscilloscope probes to the output power terminals of the sink board.

Software Setup:

I've followed the USB PD wiki closely (https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Getting_started_with_USB-Power_Delivery_Source) and made an STM32 project using the STM Cube IDE (https://github.com/michaellu2019/STM32G0_USBPD_Source) for the Nucleo G0B1RE board. I've downloaded the STM32 Cube Monitor to see debug logs. I have also tested uploading a completed binary (https://github.com/STMicroelectronics/x-cube-tcpp/blob/main/Projects/NUCLEO-G474RE/Applications/USB_PD/SRC1M1_Source/Binary/G4_SRC1M1_Source.bin) to my Nucleo-G474RE to cross check my software, but run into the same issue of no sink communication. The Sparkfun STUSB4500 board has been configured to receive 20V 3000mA, which is one of the listed PD options in the SRC1M1.

 

 

 

Please let me know if there is something I'm missing in my project setup, whether that be following the wiki to set up the G0 or if downloading the G4 binary is not sufficient to set up a project. Happy to set up a call to expedite the discussion.

 

Thanks,
Michael

 

 

 

 

[Guenael Cadier]

Dear @mlu0708 
I think your setup on SRC side would need to be able to provide 5V first, then after negotiation something else (20V for example). If you look at oscilloscope plot when facing USB-C Dewalt charging power brick, you see that after PD port is connected from SRC side, 5V is provided as VBUS.
At this stage, SRC capa are sent, and SNK side could request something else than 5V.
When negotiated, then SRC could provide 20V, not from start.
I think that what is happening in your case, is that when SNK Rd are detected from SRC side, VBUS is provided by configuring TCCP02 Provider Gate (on SRC1M1 shield). As 20V are supplied on CN3, 20V are provided on VBUS. I assume that SNK side enters in security mode, as only expecting 5V at this stage.
Regards

[mlu0708]

Thx for the response @Guenael Cadier, if I understand correctly your concern is that VBus is at 20V as CN3 gets 20V, but the SNK board requests 5V first before 20V and thus enters a state where it won't negotiate power as the SRC voltage is initially too high?

 

So would the fix entail adding another PD option (5V, 3A which does exist already based on the traces in monitor?) or changing the voltage provided to CN3 and making it some dynamic source 5V at first then 20V?

[NBALL]

Hello,
USB standard requests to always start with 5V. Any PD product needs to first follow TypeC requirement which is VBUS@5V.
STUSB4500 takes care about Vbus voltage during the TypeC phase. If Vbus is above 5V limits, it detects an error and goes into ErrorRecovery state to force a detach which the 'failing source'.

To get only 20V for your application, you can set STUSB4500 'ABOVE5V bit' and setup only 2 PDOs (5V which is mandatory and 20V), in the NVM. stusb4500 will then negotiate 20V when it is available in source_capabilities and close the power path only after 20V negotiation.

But source needs always to start with 5V in TypeC, provides its source_capabilities and upon request, provide 20V.

Best regards

Nathalie

[mlu0708]

Thank you for the clarification @NBALL and @Guenael Cadier. Are either of you able to provide any concrete steps to configure the SRC1M1 board to complete this 5V to 20V transition, as it seems that following example wikis and preconfigured binaries does not achieve this? I was under the impression that all this would work out of the box.

I believe the STUSB4500 is already configured to accept this (given the oscilloscope capture with a USB-C PD brick), so I suspect it's a matter of the "source needs always to start with 5V in TypeC" as you said. Are there any examples online where a the SRC1M1 is configured to provide more than 5V?

[NBALL]

Hello

I would suggest to use STEVAL-2STPD01 which embeds DCDC converter and is able to change DCDC voltage based on stusb4500 request. It is also stm32G0+TCPP02 (like your today setup) but also STPD01 DCDC.

With board you are currently using, you would have to use GPIO to change voltage regulation of your power source, based on sink (stusb4500) request.

Best regards

Nathalie

[mlu0708]

Hi @NBALL, before I go off and spend money on another ST board, it would be great if you could provide more specificity or documentation on this GPIO configuration process you mentioned. That would be very helpful. Thanks.

[MROUV.1]

Hello @mlu0708

STEVAL-2TPD01, USB Type-C Power Delivery dual port adapter based on programmable buck converter (60W for each port), documentation is available on web on documentation tab. User manual details technical behavior while the Quick Start Guide provides a kit overview + basic setup & programming.

Below, documentation extract shows architecture block diagram with main part numbers to performs key functions (DC/DCs, MCU, HV interfaces and protections) and links between them.

SW and HW resources are also available.

Best regards,
Mathieu

 

[mlu0708]

@MROUV.1 I was referring to the Nucleo-SRC1M1, asking for documentation on how to delivery up to 20V of power, and specifically documentation  that is not just the data sheet and getting started guide and wiki (which I have already looked at multiple times). Thanks!

[NBALL]

Dear mlu0708,

STEVAL-2TPD01 software handles voltage changes based on sink request. It can be found in usbpd_dpm_user.c and usbpd_pwr_if.c. 
Each time a request is accepted by source, it will start to change its output voltage to update Vbus output.
STEVAL-2TPD01 is an example. Based on this, you could also set GPIO on your nucleo board to trig the change on your own supply: in a lab it can be to turn on relay to (turn on 20V on SRC connector) & (turn off 5V).
usbpd_pdo_defs.h needs to list then 2 PDOs: 5V and 20V.

Best regards

Nathalie

[mlu0708]

Thank you all for the replies. A few questions:

1. You seem to be pushing to use this STEVAL-2TPD01 board (and not the SRC1M1 that I am working with and asking about) which is over 3x more expensive than the SRC1M1. Is this because it is easier to configure/better to use the STEVAL-2TPD01 for high voltage USB-C power delivery? Or is it because it is simply impossible to delivery 20V with the Nucleo-SRC1M1, and this alternative is the only option?
   
   
2. Are the data lines D+ and D- exposed on the USB-C line to some GPIO pin so that I can pass both power and data thru the cable? not sure if I see the connection when looking at the board schematic. This is a crucial design requirement for my project. 

Thank you!

[MROUV.1]

Below board possibilities:

* NUCLEO + X-NUCLEO : MCU with PD-controller + HV interface + protection for a single type-C SOURCE port. A PD compatible source driven by MCU resources (I2C or GPIO) is needed. The solution is USB-PD 20V-5A compliant. STM32 data can be activated.

* STEVAL-2STPD01 : MCU + PD-controller + DC/DC + protection for dual dual type-C adapter. A 24V (60W for one port or 120W  for two ports) DC source needs to be connected. Data are not available as this reference design is an adapter.

To match to your case, it seems that a specific HW development is required. DIY with flying wires is a good way to secure HW development. I would suggest : STEVAL-2TPD01 (single port used) plug on top of NUCLEO-G0B1RE because STM32G0B1RE  embbeds USB-HOST interface + power delivery controller. Then pick USB D+/- directly from the type-C connector (R508 footprint) with flying wire to the MOSPHO connectors to be connected to the STM32. 
It is not granted at all but it is one proposal to perform a POC (prof of concept) before moving to the final board. You need to check my assumption on NUCLEO + STEVAL pairing. To conclude, it is a low cost suggestion compared to a full HW project to develop your SW solution.

Best regards,
Mathieu

[mlu0708]

---

* NUCLEO + X-NUCLEO : MCU with PD-controller + HV interface + protection for a single type-C SOURCE port. A PD compatible source driven by MCU resources (I2C or GPIO) is needed. The solution is USB-PD 20V-5A compliant. STM32 data can be activated.

---

Thank you for your help! Sounds like the STEVAL-2STPD01 does not allow for data delivery without a hacky solution, and the Nucleo-SRC1M1 can deliver up to 20V-5A and also has the D+/D- lines exposed for data delivery. Unless I am misunderstanding what "USB-PD 20V-5A" entails, would it be possible to provide pointers (beyond datasheets and quick start guides easily accessible on the product page) on the NUCLEO-SRC1M1 so that I can bypass the "security fault issue" and deliver 20V to my sink device? 

 

Thanks!

[NBALL]

Hello
What I was trying to suggest is to keep your current setup.
By comparing the files I pointed out you should see where SW asks HW to perform voltage transition.
Based on that, you can connect your own favorite power source (DCDC/LDO/...) to SRC connector and only use 1 GPIO that you set in your SW to force the voltage transition: this GPIO can be used as enabling 20V and disabling 5V which is all what you need. 
What's important is to transition with proper timings and to always start with 5V.

Best regards

Nathalie

[mlu0708]

Thank you, I apologize for the confusion @NBALL. I have been able to source 5V from the SRC1M1 when configuring the sink board to request 5V and when applying 5V to the SRC1M1 through CN3. Let's continue this discussion only about the SRC1M1 board.

1. Regarding using a GPIO pin to "force the voltage transition," are you saying use a GPIO pin to switch the voltage level going into CN3, i.e. using a transistor/relay to literally change the voltage going into my source board? If this is what you're suggesting, then I am confused how much the source board can actually benefit me at all besides having a USB-C cable. I was under the impression the SRC1M1 handles this switching automatically: I can always provide 20V to the board, and when I plug in different sink devices that require either 5V, 15V, or 20V, etc. the SRC board automatically sends that voltage level (with the appropriate voltage transitions you are mentioning).
   
   
2. So I am checking the usbpd_dpm_user.c files and the usbpd_pwr_if.c files and the only method that seems related is USBPD_PWR_IF_SearchRequestedPDO() in usbpd_pwr_if.c. Are you saying that I would have to edit this method? Could you be more specific about what extra code I would have to add to what method to change the supply voltage from 5V to 20V when the sink requests it?

 

 

/**
 * @brief Find out SRC PDO pointed out by a position provided in a Request DO (from Sink).
 * @param PortNum Port number
 * @param RdoPosition RDO Position in list of provided PDO
 * @param Pdo Pointer on PDO value pointed out by RDO position (u32 pointer)
 * @retval Status of search
 * USBPD_OK : Src PDO found for requested DO position (output Pdo parameter is set)
 * USBPD_FAIL : Position is not compliant with current Src PDO for this port (no corresponding PDO value)
 */
USBPD_StatusTypeDef USBPD_PWR_IF_SearchRequestedPDO(uint8_t PortNum, uint32_t RdoPosition, uint32_t *Pdo)
{
/* USER CODE BEGIN USBPD_PWR_IF_SearchRequestedPDO */
	if((RdoPosition == 0) || (RdoPosition > *PWR_Port_PDO_Storage[PortNum].SourcePDO.NumberOfPDO))
	{
		/* Invalid PDO index */
	return USBPD_FAIL;
	}

	*Pdo = PWR_Port_PDO_Storage[PortNum].SourcePDO.ListOfPDO[RdoPosition - 1];
	return USBPD_OK;
/* USER CODE END USBPD_PWR_IF_SearchRequestedPDO */
}