Implemented firmware issue for Ver1.3.3 to Ver1.3.4

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

cross mob
lock attach
Attachments are accessible only for community members.
Augustine_Yeh
Level 4
Level 4
Distributor - Zenitron(GC)
100 sign-ins 5 likes given 50 sign-ins

Hi Cypress

As below capture from attach file (Page 4) , What is the recovery failures happening rate in ver1.3.3 ? Does it happen in a specific lot ? When this happens .

pastedImage_1.png

0 Likes
1 Solution
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

The actual problem was that FX3/CX3 units re-enumerate when connected to a USB 3.0 Host controller. This problem was mainly seen when the devices were connected to Intel USB 3.0 host controller.

The root cause for this problem was that after USB enumeration, the host sends the CX3/FX3 device to U1, when the host initiates the exit from U1, the device get stuck in the Recovery state as the device is not able to recognize the TS2 (Link Training Sequence) sequence sent by the host to exit the U1 low power mode. As the Host does not receive the idle symbol from FX3/CX3, it moves to ss.inactive after recovery timeout. To get back to normalcy, the host tries to establish the USB 3.0 connection by Warm Reset. This process keeps happening and the device does not succeed in achieving a stable enumeration.

Based on the test results and USB traces, it is confirmed that the issue occurs only when the link enters U1 low power state. Further analysis proved that the SuperSpeed PHY Receiver PLL is losing the lock during transition out of U1 Low Power mode.

The firmware workaround was done as follows. Whenever the FX3 device enters the U1 state, it receives an acknowledgement (LPMA) from the Host indicating that the USB host has also moved to U1. As part of the workaround, in the ISR (Interrupt Service Routine) for LPMA, Reset_PLL is done to make sure that the receiver clock starts afresh. This implementation solves the problem of re-enumeration and the PHY is able to achieve the lock successfully. The stable enumeration is observed with this FW workaround.

For better performance, in FX3 SDK 1.3.4, the LPM entry is disabled during data transfer. This prevents the U1 Fast exit issue if there occurs some data to be transmitted urgently when the device is in U1 state.

Please refer to the Errata 7 in page 50 of FX3 datasheet which highlights the issue and FW changes made. The link to FX3 datasheet is provided below:

https://www.cypress.com/file/140296/download

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna

View solution in original post

0 Likes
5 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

The actual problem was that FX3/CX3 units re-enumerate when connected to a USB 3.0 Host controller. This problem was mainly seen when the devices were connected to Intel USB 3.0 host controller.

The root cause for this problem was that after USB enumeration, the host sends the CX3/FX3 device to U1, when the host initiates the exit from U1, the device get stuck in the Recovery state as the device is not able to recognize the TS2 (Link Training Sequence) sequence sent by the host to exit the U1 low power mode. As the Host does not receive the idle symbol from FX3/CX3, it moves to ss.inactive after recovery timeout. To get back to normalcy, the host tries to establish the USB 3.0 connection by Warm Reset. This process keeps happening and the device does not succeed in achieving a stable enumeration.

Based on the test results and USB traces, it is confirmed that the issue occurs only when the link enters U1 low power state. Further analysis proved that the SuperSpeed PHY Receiver PLL is losing the lock during transition out of U1 Low Power mode.

The firmware workaround was done as follows. Whenever the FX3 device enters the U1 state, it receives an acknowledgement (LPMA) from the Host indicating that the USB host has also moved to U1. As part of the workaround, in the ISR (Interrupt Service Routine) for LPMA, Reset_PLL is done to make sure that the receiver clock starts afresh. This implementation solves the problem of re-enumeration and the PHY is able to achieve the lock successfully. The stable enumeration is observed with this FW workaround.

For better performance, in FX3 SDK 1.3.4, the LPM entry is disabled during data transfer. This prevents the U1 Fast exit issue if there occurs some data to be transmitted urgently when the device is in U1 state.

Please refer to the Errata 7 in page 50 of FX3 datasheet which highlights the issue and FW changes made. The link to FX3 datasheet is provided below:

https://www.cypress.com/file/140296/download

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
Augustine_Yeh
Level 4
Level 4
Distributor - Zenitron(GC)
100 sign-ins 5 likes given 50 sign-ins

Hi Jayakrishna

What is the recovery failures happening rate in ver1.3.3 ? Thank !!

0 Likes

Hello,

We dont have an exact failure rate as numbers in SDK Version 1.3.3. From some customers, we understood that this issue occurs when the device undergoes a transition from U1 to U0. From this, we found out the root cause and provided a workaround. This workaround was tested with different host controllers and was found to be a success. So we recommend you to use SDK version 1.3.4 which has the fix implemented in it.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
Augustine_Yeh
Level 4
Level 4
Distributor - Zenitron(GC)
100 sign-ins 5 likes given 50 sign-ins

Hi Jayakrishna

1. The result of this analysis was that FX3 SDK Ver.1.3.4 was normal.

    Then, does it occur in FX3 SDK Ver.1.3.3 or earlier? Does it correspond to the problem fixed in FX3 SDK          1.3.4?

2. What kind of problem is the above "problem"? We want to know more about

    U1 U0. What is the cause?

3. The IC that we requested to analyze suddenly lost Device. However, it is not a fixed timing every time,

    it may be one minute later or one hour later. Has Cypress conducted a long test?

0 Likes

Hello,

Please find my comments for the questions that you posted:

The release note showed that there was a firmware workaround to prevent the USB 3.0 recovery failures that are seen on some USB 3.0 devices. This is the problem that I was talking about in the previous discussions.

This problem caused FX3 to re-enumerate when they are connected to certain host controllers. According to USB 3.0 specifications, when no data is transmitted through the bus, host sends the device to low power states such as U1/U2/U3. Initially, the device will move from U0->U1. Now, when some urgent data is to be transmitted through the bus, the device need to switch back to U0 from U1. This is because data cannot be transmitted in U1 power state. This transition takes place through a recovery state. When the host initiates exit from U1, device gets stuck in the recovery state as it cannot detect the TS2 transmitted by the host. Due to this, the host will not receive the idle symbol from FX3/CX3 and hence will move to ss.inactive after recovery timeout. To get back to normalcy, the host tries to establish the USB 3.0 connection by warm reset. This process keeps on happening and hence the device will not have a stable enumeration.

When further analysis was done, we understood that the receiver PLL lost  the lock during transition out of U1. To prevent this, the workaround for SDK 1.3.3 was done as follows. Whenever the FX3 device enters the U1 state, it receives an acknowledgement (LPMA) from the Host indicating that the USB host has also moved to U1. As part of the workaround, in the ISR (Interrupt Service Routine) for LPMA, Reset_PLL is done to make sure that the receiver clock starts afresh. This implementation solved the problem of re-enumeration and the PHY is able to achieve the lock successfully. The stable enumeration is observed with this FW workaround. For FX3 SDK 1.3.4, the LPM entry is disabled during data transfers.

Yes this problem occurred in FX3 SDK 1.3.3 and before. This can be fixed by using the workaround provided. This problem corresponds to the problem fixed in FX3 SDK 1.3.4.

Regarding your third question I have a doubt. Is it related to this discussion? Is it like you connect a device to host and transmit data to it for a long time or is it like keeping the device idle for a long time. Anyhow Cypress has already conducted long tests for these cases.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes