Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

USB EZ-PD™ Type-C

KiLe_4629881
Level 3
25 sign-ins 10 replies posted 10 questions asked
Level 3

Hi, 

I wanted to continue this with updated waveform captures from my previous question that got closed so i cannot reply. 

We found an issue where I am not sure if this is an issue with the cypress sdk. 

but if we plug a pair of XiaoMi Type-C earphone BRE02JY into port 0 the device will continuously reset. 

If we plug the device into port 1, then the reset does not happen and these headphones work normally.

I have checked the configuration (attached) in ez_pd configurator and as far as I can tell both ports are setup the same. 

Looking at interrupts coming from the device over the EC i2c interface - this part will continuously respond with code 0x80 on the device interrupt register which is the RESET_COMPLETE event. indicating that the device is rebooting over and over as long as this device is attached to the port. 

[814.508406 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]
[814.582658 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]
[815.862641 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]
[815.936897 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]
[817.216020 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]
[817.290269 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00]

0 Likes
3 Replies
ShifangZ_26
Moderator
Moderator 1000 replies posted 750 replies posted 500 solutions authored
Moderator

Hello,

 

Could you please kindly use UART debug the port and event was reported from CCG5 firmware?

void app_event_handler(uint8_t port, app_evt_t evt, const void* dat)

 

Please kindly output "Port" and "evt", I would like to confirm whether the PORT 0 have been reported below event or not.

case APP_EVT_CONNECT:

case APP_EVT_TYPE_C_ERROR_RECOVERY:

 

From the waveform you have been attached, it seems the detach event have been reported here. 

ShifangZ_26_0-1617088546479.png

 

Best Regards,

Lisa

 

0 Likes
KiLe_4629881
Level 3
25 sign-ins 10 replies posted 10 questions asked
Level 3

Hi Lisa, 

I will have to take some time to get the device to do that level of debug, our CM captured this data for us. 

As a note, from the EC log - we do see the following over i2c which might help: 

Failure: 

[812.144517 CYPD_RESPONSE_PORT_CONNECT]
[813.153968 PD Controller 1 Port 255 Code 0x80 Response Len: 0x00] <- this is the restart. 

On the port second port which works correctly we see: 
[168.604589 CYPD_RESPONSE_PORT_CONNECT]
[177.910426 PD Controller 0 Port 1 Code 0x9d Response Len: 0x00] <- this is  RESPONSE_SOURCEDISABLED

 
So for the failure port we do not seem to reach the SOURCEDISABLED event to the EC. 
0 Likes
KiLe_4629881
Level 3
25 sign-ins 10 replies posted 10 questions asked
Level 3

@ShifangZ_26 I finally got the device - and it is a simple device with a type c pulldown resistor of 5.1k - no PD negotiation at all. The voltage on the CC pin looks ok. 

On the good port (port 1) I can see the CCG successfully sends 50 source capability messages and then times out with source disabled. 

Good port: 

KiLe_4629881_0-1618963250602.png

 

On the bad port - the CCG sends 4 sets of source capability messages, and then stops, and approximately 3 seconds later the device seems to reset - which would seem to me we hit a watchdog timeout.

Bad port:

KiLe_4629881_1-1618963386787.png

Given the fact that this device is a simple resistor on the CC pin, could there be some issue with the usb mux or BC1.2 subsystem causing this?

We have tested with a large number of devices, and this is the only device that has this issue. All other devices we tested with that have a cc pull resistor (or full pd) do not have this issue.

0 Likes