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]
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.
From the waveform you have been attached, it seems the detach event have been reported here.
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:
[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:
[177.910426 PD Controller 0 Port 1 Code 0x9d Response Len: 0x00] <- this is RESPONSE_SOURCEDISABLED
@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.
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.
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.