Hi all,
This is a followup to a previous thread: CCG3 - Receptacle Pinout for a USB-C (DP Alt Mode E) Monitor?
From the info put together in that thread, we determined we do not actually want a Type-E pinout, but a Type-D, as we are only using 2 DisplayPort lanes. We also determined we must have a USB-C Mux for our monitor design.
Today we received our new prototypes for the redesign to accommodate these changes, and are having issues getting the firmware to behave correctly. I want to make sure everything we are doing makes sense, because we are still having no luck getting our PC to recognize the device as a monitor.
Our source is a Windows PC connected to a CCG4 Eval Kit, which converts to USB-C. The CCG4 Eval Kit is confirmed working with this PC and an off-the-shelf USB-C Monitor.
Anyway, onto the show:
Here is how our USB-C receptacle is connected:
And here is how our USB-C mux (TI TUSB564) is connected:
Note that we have R160 and R161 depopulated, as we are looking to have the CYPD be in control of the SBU/AUX lines. SBU1, SBU2, AUX_P. and AUX_N are routed only to the CYPD3120.
The CYPD3120 is connected as follows:
As far as I can tell, our hardware connections should be OK for DP Mode-D operation.
Also note that DP_AUX+ and DP_AUX- are pulled up/down by 1M resistors external to the CYPD3120 per DisplayPort spec (this is not shown in the schematics above)
Our starting point was the default CYPD3120 Dongle firmware. I have made the following adjustments to the firmware for Recepticle/Monitor operation:
1) mux_ctrl_set_cfg() has been adjusted to account for controlling the mux via the 3 GPIO pins, CTL1,CTL0, and FLIP. It should now match the TUSB564 control table:
bool mux_ctrl_set_cfg( uint8_t port, mux_select_t cfg, uint8_t polarity)
{
/* Configure SBU-AUX switch based on CC polarity. */
switch (cfg)
{
case MUX_CONFIG_ISOLATE:
/* Ensure that SBU-AUX switch is open. */
sbu_switch_configure(SBU_NOT_CONNECTED, SBU_NOT_CONNECTED);
/* Ensure that AUX1/2 don't have any resistor pull up/down. */
aux_resistor_configure (AUX_NO_RESISTOR, AUX_NO_RESISTOR);
break;
case MUX_CONFIG_SS_ONLY:
MUX_CTL1_Write(0);
MUX_CTL0_Write(1);
if (polarity == 0)
{
MUX_FLIP_Write(0);
}
else
{
MUX_FLIP_Write(1);
}
sbu_switch_configure(SBU_NOT_CONNECTED, SBU_NOT_CONNECTED);
/* Ensure that AUX1/2 don't have any resistor pull up/down. */
aux_resistor_configure (AUX_NO_RESISTOR, AUX_NO_RESISTOR);
break;
case MUX_CONFIG_DP_2_LANE:
MUX_CTL1_Write(1);
MUX_CTL0_Write(1);
if (polarity == 0)
{
/* CC1 is active. */
sbu_switch_configure(SBU_CONNECT_AUX1, SBU_CONNECT_AUX2);
MUX_FLIP_Write(0);
}
else
{
/* CC2 is active. */
sbu_switch_configure(SBU_CONNECT_AUX2, SBU_CONNECT_AUX1);
MUX_FLIP_Write(1);
}
/*We are using external PU/PD on AUX1/2, set NO INTERNAL RESISTORS*/
aux_resistor_configure (AUX_NO_RESISTOR, AUX_NO_RESISTOR);
break;
case MUX_CONFIG_DP_4_LANE:
MUX_CTL1_Write(1);
MUX_CTL0_Write(0);
if (polarity == 0)
{
/* CC1 is active. */
sbu_switch_configure(SBU_CONNECT_AUX1, SBU_CONNECT_AUX2);
MUX_FLIP_Write(0);
}
else
{
/* CC2 is active. */
sbu_switch_configure(SBU_CONNECT_AUX2, SBU_CONNECT_AUX1);
MUX_FLIP_Write(1);
}
/*We are using external PU/PD on AUX1/2, set NO INTERNAL RESISTORS*/
aux_resistor_configure (AUX_NO_RESISTOR, AUX_NO_RESISTOR);
break;
default:
break;
}
return true;
}
2) In config.h, DP_UFP_DONGLE has been removed, and DP_UFP_MONITOR has been defined:
//#define DP_UFP_DONGLE (1u)
#define DP_UFP_MONITOR (1u)
3) In config.h, DP_GPIO_CONFIG_SELECT has been set to 0, as we want to determine our supported pinout (Type-D) from our configuration rather than GPIO:
//#define DP_GPIO_CONFIG_SELECT (1u)
#define DP_GPIO_CONFIG_SELECT (0u)
With this modified, and our configuration loaded (config is attached) we get nothing. The PC connected does not see anything on the other end. I have also attached the logs from the EZ-PD Analyzer utility. One transmission in particular stands out, SL#51 from our sink:
Looks like we are maybe still missing a few necessary changes to get this working properly? UFP_D pin assignments are showing not supported, and Receptacle indication appears to still be configured as a plug. It also calls out Pin E supported (which, in the configuration for the CCG3, is explicitly NOT supported) How would these be changed?
Would anyone have any suggestions as to what we could try from here? If I'm recalling correctly, the only difference in the CCG3 products is the firmware/included bootloader. Would we be better off starting with a different firmware as a base?
Any help is much appreciated! Thanks!
Hi Sananya,
Yes, the hardware configuration does seem correct for DP Pin-D assignment. For R160 and R161, please note that CCG3 cant provide pull down resistors of 2M as it only has internal resistors for the AUX side.
Yes we are aware, R159 and R158 are present as 2M external pull downs on SBU1 and SBU2 as per the examples we were given by TI for the design of this mux circuit. We are also using external 1M PU/PD resistors for the AUX+/- side, and have adjusted the CYPD firmware to not set any internal resistors on AUX+ and AUX-.
In your configuration file, please update the Mode 0 value as per your required VDO response (as per Table 5-2 in the Display Port Spec). For your case, i think it should be updated to 0x80045.
We are now using the SVID of 0x80045 as suggested, and it does appear to show properly in the Analyzer capture (I have attached the entire analyzer output to this post). Thanks for this, it's progress at least:
It looks like from the analyzer capture, the modes are communicated correctly, but it never receives a command from the source to enter Alternate Mode.
On our retail USB-C Monitor, we see this command from the source side to enter alt mode after discovery is finished:
This "Enter Mode" command never seems to come when connected to our monitor prototype.
Could you please ensure that the configuration is getting updated properly? Please replace the config.c file in the project with the *.c file of your new configuration and rebuild it. After programming the device, please read back the configuration to confirm that its modififed.
Yes, I have been building using the config.c file generated from EZ-PD Config Tool to directly program the config in the firmware.
Since you are using CYPD3120 part as a DP sink, I would recommend using the current SDK project with the modifications done.
So just confirming, you are referring to the the CYPD3120 dongle firmware in the SDK (v3.0.2). This is the firmware we have been modifying, yes.
Still no luck with any sort of monitor device showing up in windows, however. I am getting the following notification though:
So it is seeing something out there, but obviously not functioning correctly.
One further question about the firmware itself. the "polarity" argument for mux_ctrl_set_cfg looks like it is opposite what we are expecting for flipped/non-flipped. Would you be able to confirm which value for polarity is "flipped" and which is "unflipped" so I can make sure I am setting the TI Mux properly (see Table 2 in my first post)?
One last thing, possibly unrelated: I am seeing a strange "Unknown Device" in my device manager. It may be nothing, but I figured I would at least mention it, as it appears to be a cypress device:
Device Instance Path:
ROOT\USB\0000
Hardware ID:
root\CypressBus
Status:
01802001
DN_ROOT_ENUMERATED
DN_DISABLEABLE
DN_NT_ENUMERATOR
DN_NT_DRIVER
It appears in device manager even when I have all cypress devices (miniprog 3, CCG4 EVK, EZ-PD Analyzer) disconnected, so I'm not sure what it is, or if it's a something to be concerned about.
Thanks again for the help!
Additional information after having a few more hours to bang my head on this:
We managed to enter into Alternate Mode D, but it only works when Modes C and D are declared as supported (SVID == 0xC0045). If the CCG is configured to only support Mode D (SVID == 0x80045), the Enter Mode command never occurs and we just sort of wait forever for the host to issue the enter mode command. Might anyone know why this might be?
Now we're stuck a little further down the road with what looks like a possible issue with Hotplug Detect. We are seeing HPD transition from low to high, but it looks like the CYPD3120 never issues a status message with the HPD IRQ.
On a standard retail USB-C monitor, we see the HPD IRQ status after HPD transitions low to high (may need to view full image to see my notations):
But on our design, we never get the status packet with the HPD IRQ We just wait forever after the DFP validates the CRC on the HPD High status message (may need to view full image to see my notations):
Is this something to be overly concerned about? In any case, I am still seeing no monitor connected to the PC.
Most recent EZ-PD Analyzer Log is attached.
On another note, we are considering removing the 2M pull-down resistors from SBU1/SBU2. We are thinking these may be necessary if the TUSB564 is controlling the SBU/AUX lines (they are present on the TI reference designs), but may be causing problems when the CYPD3120 is handling the SBU to AUX conversion (They are not present on any Cypress designs from what I have seen). Could you confirm if these 2M Pulldowns on SBU need to be removed for the CYPD3120?
[EDIT] We removed the 2M pull-downs from SBU1 and SBU2 this morning and there appears to be no effect
Thanks!
-Changing the mode value to 0xC0045 would mean pin assignment C,D is supported by the sink. Could you kindly take the logs with the retail USB-C monitor to compare what DP modes are supported such that the DP source issues Enter mode command?
The retail USB-C monitor appears to support C and D only. Only when we changed our configuration to C and D did we receive "Enter Mode" on our design. We are curious as to why when we configure our design to Mode D only, we do not receive an "Enter Mode" command. Regardless, we can get it to Enter Mode D when both C and D are configured as supported.
-The polarity is set to 0 i.e. unflipped state in the Mux when CC1 is being used and 1 i.e. flipped state when CC2 is being used.
-Please check if the AUXP/N connections from the Mux and CCG3 are connected correctly. As per the TUSB564 datasheet, when flip is low, SBU1 is connected to AUXN but in CCG3 firmware, SBU1 is connected to AUXP when polarity is 0.
Yes I think we finally got this sorted. What the TUSB564 and CCG3 refer to as "flipped" was a bit confusing. We finally settled on this, which we think is finally correct:
For Polarity == 0:
CTL0 = 1
CTL1 = 1
FLIP = 0
SBU1 -> AUX_P (AUX1)
SBU2 -> AUX_N (AUX2)
For Polarity != 0:
CTL0 = 1
CTL1 = 1
FLIP = 1
SBU1 -> AUX_N (AUX2)
SBU2 -> AUX_P (AUX1)
-To confirm if the HPD IRQ is being asserted by the monitor, could you please probe the HPD pin on CCG3? The firmware updates the Status Update packet when the IRQ signalling is detected by the HAL layer.
We are seeing HPD go high a few moments after the USB-C cable is connected. As per the post above we can see the status packet for when it is low, followed by a status packet where HPD is high, but no packet with an HPD IRQ as we see on the retail monitor.
We are running into some funny business with the SBU/AUX lines now. We are seeing traffic on the lines, but they do not appear to be complimentary differential signals as they should be:
SBU1 in Yellow
SBU2 in Green
We actually disconnected (cut the traces of) the AUX_P and AUX_N lines going to the TUSB564 to ensure that was not causing any issues, but still have the same problem. The lines aren't shorted together either, so something funky is going on here. What's odd is if I'm not mistaken, this transmission should be coming from the PC to the monitor, so something would have to be messing with the incoming signal. Not sure what's there other than the CCG4 EVK that's sending the USB-C signals, or the CCG3 that's could potentially be causing an issue. Since the retail monitor functions with the CCG4 EVK, I doubt the problem lies there, but we will continue investigating.
[EDIT] It looks like it was an issue with one of the CCG4 EVK Baseboards? Using the other baseboard we at least get a differential signal on the SBU lines:
The amplitude looks a little low though, and connecting the Retail USB-C monitor looks much nicer:
Still stuck in the same spot on our monitor though. It looks like the DP->LVDS bridge that is acting as our DP Sink is not responding to this transmission. Will look into it and update with more info.
Thanks again for the input!
