Hi Guenter Roeck / Heikki Krogerus and all,
1.
I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which
has a FUSB302B TYPEC port controller.
2.
My source is a wall charger which is based on Gallium Nitride (GaN II)
technology and has four ports as follows:
USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
3.
i am using latest linux-next and enabled all the relevant configs, especially:
CONFIG_TYPEC=y
CONFIG_TYPEC_TCPM=y
CONFIG_TYPEC_FUSB302=y
4.
DT node is as follows when i use USB-C1 of wall charger:
connector {
compatible = "usb-c-connector";
label = "USB-C";
data-role = "dual";
power-role = "sink";
try-power-role = "sink";
op-sink-microwatt = <1000000>;
sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM)>;
};
Issue:
The board power well most of the time, but may be in 1 out of 5 cold
boots, FUSB302B is getting a hard reset, as
FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
After some digging, found out that the above behaviour is accounted to
when something is wrong with the CRC of
the received packet (SOP - Start of Packet)
This behaviour is seen i.e. FUSB302B getting a hard reset more on the
USB-C3 port.
Any pointers on how to solve this issue.
Thanks and Regards
--
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India
Hi Suniel,
On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> Hi Guenter Roeck / Heikki Krogerus and all,
>
> 1.
> I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> FUSB302B TYPEC port controller.
>
> 2.
> My source is a wall charger which is based on Gallium Nitride (GaN II)
> technology and has four ports as follows:
>
> USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
>
> 3.
> i am using latest linux-next and enabled all the relevant configs,
> especially:
> CONFIG_TYPEC=y
> CONFIG_TYPEC_TCPM=y
> CONFIG_TYPEC_FUSB302=y
Which kernel version?
> 4.
> DT node is as follows when i use USB-C1 of wall charger:
>
> connector {
> compatible = "usb-c-connector";
> label = "USB-C";
> data-role = "dual";
> power-role = "sink";
> try-power-role = "sink";
> op-sink-microwatt = <1000000>;
> sink-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)
> PDO_FIXED(12000, 3000,
> PDO_FIXED_USB_COMM)>;
> };
What do you mean by "when i use USB-C1..."? Why is the above valid
only then and not with the other PD contracts?
> Issue:
> The board power well most of the time, but may be in 1 out of 5 cold boots,
> FUSB302B is getting a hard reset, as
> FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
>
> After some digging, found out that the above behaviour is accounted to when
> something is wrong with the CRC of
> the received packet (SOP - Start of Packet)
How did you determine that the problem is a bad CRC?
> This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> USB-C3 port.
>
> Any pointers on how to solve this issue.
Guenter, do you have time to take a look at this?
thanks,
--
heikki
On Tue, Jan 02, 2024 at 11:46:34AM +0200, Heikki Krogerus wrote:
> Hi Suniel,
>
> On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > Hi Guenter Roeck / Heikki Krogerus and all,
> >
> > 1.
> > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > FUSB302B TYPEC port controller.
> >
> > 2.
> > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > technology and has four ports as follows:
> >
> > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> >
> > 3.
> > i am using latest linux-next and enabled all the relevant configs,
> > especially:
> > CONFIG_TYPEC=y
> > CONFIG_TYPEC_TCPM=y
> > CONFIG_TYPEC_FUSB302=y
>
> Which kernel version?
>
> > 4.
> > DT node is as follows when i use USB-C1 of wall charger:
> >
> > connector {
> > compatible = "usb-c-connector";
> > label = "USB-C";
> > data-role = "dual";
> > power-role = "sink";
> > try-power-role = "sink";
> > op-sink-microwatt = <1000000>;
> > sink-pdos = <PDO_FIXED(5000, 3000,
> > PDO_FIXED_USB_COMM)
> > PDO_FIXED(12000, 3000,
> > PDO_FIXED_USB_COMM)>;
> > };
>
> What do you mean by "when i use USB-C1..."? Why is the above valid
> only then and not with the other PD contracts?
>
> > Issue:
> > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > FUSB302B is getting a hard reset, as
> > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> >
> > After some digging, found out that the above behaviour is accounted to when
> > something is wrong with the CRC of
> > the received packet (SOP - Start of Packet)
>
> How did you determine that the problem is a bad CRC?
>
> > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > USB-C3 port.
> >
> > Any pointers on how to solve this issue.
>
> Guenter, do you have time to take a look at this?
>
As far as I can see, the bit means that a hard reset request has been
received from the charger. What else can the code do but to execute
that hard reset ? On a higher level, if there is a communication problem
due to bad CRC (i.e., a bad communication link) between the wall charger
and the development system, I am not sure if there is anything we can do
in software to remedy the problem.
Secondary question: Is this a regression ? The original e-mail states
that it was seen with the "latest linux-next". If it is a regression, it
should be possible to bisect it. However, the only recent commit which
might affect reset behavior is a6fe37f428c1 ("usb: typec: tcpm: Skip hard
reset when in error recovery"). If anything I would assume that this
commit would improve the situation, not make it worse.
Thanks,
Guenter
Hi Heikki,
On Tue, Jan 2, 2024 at 3:16 PM Heikki Krogerus
<[email protected]> wrote:
>
> Hi Suniel,
>
> On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > Hi Guenter Roeck / Heikki Krogerus and all,
> >
> > 1.
> > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > FUSB302B TYPEC port controller.
> >
> > 2.
> > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > technology and has four ports as follows:
> >
> > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> >
> > 3.
> > i am using latest linux-next and enabled all the relevant configs,
> > especially:
> > CONFIG_TYPEC=y
> > CONFIG_TYPEC_TCPM=y
> > CONFIG_TYPEC_FUSB302=y
>
> Which kernel version?
The kernel version is linux-next which is 6.7.0-rc8
>
> > 4.
> > DT node is as follows when i use USB-C1 of wall charger:
> >
> > connector {
> > compatible = "usb-c-connector";
> > label = "USB-C";
> > data-role = "dual";
> > power-role = "sink";
> > try-power-role = "sink";
> > op-sink-microwatt = <1000000>;
> > sink-pdos = <PDO_FIXED(5000, 3000,
> > PDO_FIXED_USB_COMM)
> > PDO_FIXED(12000, 3000,
> > PDO_FIXED_USB_COMM)>;
> > };
>
> What do you mean by "when i use USB-C1..."? Why is the above valid
> only then and not with the other PD contracts?
USB-C1, USB-C2 and USB-C3 are the receptacles/connectors on the PD Wall charger
USB-C1 and USB-C2 are idenical rated as: 100W PD3.0, 5V/3A, 9V/3A,
12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
USB-C3 is rated as: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
now when i say "when i use USB-C1", i mean that I am using receptacle
USB-C1 on the wall charger to power
my target/development system which has a FUSB302B receptacle/connector.
irrespective of the PDO's requested, like:
PDO_FIXED(9000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(15000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(20000, 5000, PDO_FIXED_USB_COMM);
the target/development board FUSB302B is getting a hard reset like i
mentioned in
1 out of 5 cold boots.
>
> > Issue:
> > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > FUSB302B is getting a hard reset, as
> > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> >
> > After some digging, found out that the above behaviour is accounted to when
> > something is wrong with the CRC of
> > the received packet (SOP - Start of Packet)
>
> How did you determine that the problem is a bad CRC?
The power contract negotiation as per my understanding is:
cable detect => source sends Accept => Sink responds with good CRC =>
source sends capabilities =>
=> sink replied with goodCRC and sink requests for a particular PDO =>
=> source sends accept => sink replied with goodCRC =>
=> source sends PS_RDY to sink => sink replied with goodCRC and gets
bound to desired contract from source.
However in some scenarios, based on below log, i guessed it as bad
CRC: (RX, header is 0x0)
[ 1.599074] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[ 1.602877] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[ 1.605978] TCPM: tcpm_pd_event_handler:
[ 1.606575] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
[ 1.967732] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[ 2.132493] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[ 2.133057] FUSB302: IRQ: PD tx success
[ 2.135446] TCPM: PD TX complete, status: 0
[ 2.138529] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0xd1
[ 2.141351] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[ 2.141968] FUSB302: IRQ: PD sent good CRC
[ 2.144321] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[ 2.144912] TCPM: PD RX, header: 0x1a3 [1]
[ 2.145479] TCPM: tcpm_pd_ctrl_request: type:0x3
[ 2.145873] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
[ 2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND
[ 2.146706] TCPM: tcpm_pd_rx_handler: done
[ 2.154971] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[ 2.155374] FUSB302: IRQ: PD sent good CRC
[ 2.158067] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[ 2.158496] TCPM: PD RX, header: 0x0 [1]
[ 2.159030] TCPM: tcpm_pd_rx_handler: done
[ 2.176842] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
[ 2.177298] FUSB302: IRQ: PD received hardreset: interrupta: 1
[ 2.177850] FUSB302: fusb302_pd_reset:
[ 2.179471] TCPM: tcpm_pd_event_handler:
[ 2.179919] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
[ 2.180449] TCPM: _tcpm_pd_hard_reset: Received hard reset
[ 2.181099] TCPM4: _tcpm_pd_hard_reset:
board(FUSB302B hard reset) reboots
when i use a USB-C3 receptacle on wall charger with rating: 20W PD3.0,
5V/3A, 9V/2.22A, 12V/1.67A
and device tree node as:
connector {
compatible = "usb-c-connector";
label = "USB-C";
data-role = "dual";
power-role = "sink";
try-power-role = "sink";
op-sink-microwatt = <1000000>;
sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
PDO_FIXED(12000, 1670, PDO_FIXED_USB_COMM)>;
};
log when FUSB302B gets a hard reset: (here it might or might not be a bad CRC ?)
[ 1.602441] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[ 1.606642] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[ 1.609672] TCPM: tcpm_pd_event_handler:
[ 1.610240] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
[ 1.976170] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[ 2.136304] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[ 2.136916] FUSB302: IRQ: PD tx success
[ 2.139148] TCPM: PD TX complete, status: 0
[ 2.141867] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[ 2.142325] FUSB302: IRQ: PD sent good CRC
[ 2.144775] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[ 2.145313] TCPM: PD RX, header: 0x1a3 [1]
[ 2.145886] TCPM: tcpm_pd_ctrl_request: type:0x3
[ 2.146281] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
[ 2.146716] TCPM:tcpm_pd_ctrl_request: case SOFT_RESET_SEND
[ 2.147113] TCPM: tcpm_pd_rx_handler: done
[ 2.167042] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
[ 2.167495] FUSB302: IRQ: PD received hardreset: interrupta: 1
[ 2.168047] FUSB302: fusb302_pd_reset:
[ 2.169988] TCPM: tcpm_pd_event_handler:
[ 2.170395] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
[ 2.170785] TCPM: _tcpm_pd_hard_reset: Received hard reset
[ 2.171290] TCPM4: _tcpm_pd_hard_reset:
when FUSB302B negotiates for a contract on USB-C3 receptacle, the
FUSB302B gets hard reset more
number of times compared to USB-C1/C2.
>
> > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > USB-C3 port.
> >
> > Any pointers on how to solve this issue.
>
> Guenter, do you have time to take a look at this?
>
> thanks,
>
> --
> heikki
Thanks,
Suniel
Hi Guenter,
On Tue, Jan 2, 2024 at 10:39 PM Guenter Roeck <[email protected]> wrote:
>
> On Tue, Jan 02, 2024 at 11:46:34AM +0200, Heikki Krogerus wrote:
> > Hi Suniel,
> >
> > On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > > Hi Guenter Roeck / Heikki Krogerus and all,
> > >
> > > 1.
> > > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > > FUSB302B TYPEC port controller.
> > >
> > > 2.
> > > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > > technology and has four ports as follows:
> > >
> > > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> > >
> > > 3.
> > > i am using latest linux-next and enabled all the relevant configs,
> > > especially:
> > > CONFIG_TYPEC=y
> > > CONFIG_TYPEC_TCPM=y
> > > CONFIG_TYPEC_FUSB302=y
> >
> > Which kernel version?
> >
> > > 4.
> > > DT node is as follows when i use USB-C1 of wall charger:
> > >
> > > connector {
> > > compatible = "usb-c-connector";
> > > label = "USB-C";
> > > data-role = "dual";
> > > power-role = "sink";
> > > try-power-role = "sink";
> > > op-sink-microwatt = <1000000>;
> > > sink-pdos = <PDO_FIXED(5000, 3000,
> > > PDO_FIXED_USB_COMM)
> > > PDO_FIXED(12000, 3000,
> > > PDO_FIXED_USB_COMM)>;
> > > };
> >
> > What do you mean by "when i use USB-C1..."? Why is the above valid
> > only then and not with the other PD contracts?
> >
> > > Issue:
> > > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > > FUSB302B is getting a hard reset, as
> > > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> > >
> > > After some digging, found out that the above behaviour is accounted to when
> > > something is wrong with the CRC of
> > > the received packet (SOP - Start of Packet)
> >
> > How did you determine that the problem is a bad CRC?
> >
> > > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > > USB-C3 port.
> > >
> > > Any pointers on how to solve this issue.
> >
> > Guenter, do you have time to take a look at this?
> >
>
> As far as I can see, the bit means that a hard reset request has been
> received from the charger. What else can the code do but to execute
> that hard reset ? On a higher level, if there is a communication problem
> due to bad CRC (i.e., a bad communication link) between the wall charger
> and the development system, I am not sure if there is anything we can do
> in software to remedy the problem.
>
> Secondary question: Is this a regression ? The original e-mail states
> that it was seen with the "latest linux-next". If it is a regression, it
> should be possible to bisect it. However, the only recent commit which
> might affect reset behavior is a6fe37f428c1 ("usb: typec: tcpm: Skip hard
> reset when in error recovery"). If anything I would assume that this
> commit would improve the situation, not make it worse.
I have tested linux-next, linux-lts (v6.1) and linux-stable branches.
linux-next atleast reboots after it(FUSB302B) gets a hard reset
some branches in LTS, development board power is cutoff during
negotiation and board never boots.
>
> Thanks,
> Guenter
Thanks,
Suniel