CYPD5225_thunderbolt_tgl firmware resets with xiaomi headphones on one port Update

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

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

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

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
Moderator
10 likes given 250 sign-ins 1000 replies posted

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
Level 3
25 sign-ins 10 replies posted 10 questions asked

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
Level 3
25 sign-ins 10 replies posted 10 questions asked

@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