FX3 Library updated

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

cross mob
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

I have a problem (A) that the USB3.0 link is not connected at high temperature (about 60 to 70 degrees).

The incidence is about 1%.

And I have another problem (B) that FW cannot write in the inspection process during mass production.

*These two PCBs are different it.

I checked the thread below and updated the library.

FX3 Superspeed communication fails on link errors

Then, the problem of (B) board was solved. When using SDK 1.3.4 for the board, a communication error occurred unless the I2C speed was set to 100kHz. However, using this thread's library, it had no problems at 400kHz.

What features did this library update?

The (A) board is still under investigation.

Thanks,

Tetsuo

0 Likes
1 Solution

Hello,

In the traces that show failure, you can see that the failures occurred only after U1 low power entry. The failure would have started when the device started to exit from U1. But the device transitioned to U0 that time. It is possible that the failure can occur later when the device is in U0. We have seen this issue also and it is related to the problem that is mentioned in my response 3

To avoid this from happening using SDK 1.3.3, you need to disable the LPM permanently in the firmware. This can be done by calling the API CyU3PUsbLPMDisable() after the API CyU3PConnectState() is called. It is recommended to add a delay of few microseconds between CyU3PConnectState() and CyU3PUsbLPMDisable(). Also, the API CyU3PUsbLPMEnable() should not be called anywhere in the firmware. As mentioned before, this workaround will cause the device to fail the compliance test. A better and recommended approach is to use SDK 1.3.4 and disable LPM during data transfer. You can enable LPM when there are no data transfers.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna

View solution in original post

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

Hello,

According to my understanding, you have 2 different boards. Board A has USB 3.0 link failures at high temperatures (60-70 degrees). Board B is having I2C communication issues when used with 400kHz. Can you please elaborate the issue on board B so that I can understand it better? Do you find any API failing when you try to communicate using I2C interface of FX3 in board B? Please elaborate the problem so that I can understand the issue better. Please let me know if the library attached in the thread mentioned in your query, solves problem A also?

Please note that the library that was provided in the thread mentioned in your query is just a test library and is not an official release. The library attached in the thread is modified to relax the PENDING_HP_TIMER value to 10us and other changes that are related to USB block only.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

Thank you for your comments.

I reconfirmed. And then I noticed an error. I thought I was using 1.3.4. However, the library reference path was still 1.3.3. Therefore, I was using the library of 1.3.3. I changed the reference location path and used the 1.3.4 library to fix the problem.

There are two types of boards, A and B. (as you mentioned). I2C control (B) has been resolved. The link failure (A) also appears to have improved.

So the question I would like to ask (although different from the first question) is what is the difference between 1.3.3 and 1.3.4. The items are listed in the release notes, but I'm not sure which one is applicable.

There is "some devices" below, what does this mean?

releasenote.jpg

I understood that the thread's library is a test one.

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

Please refer to the following thread which describes about the issue pointed out in your previous response:

Implemented firmware issue for Ver1.3.3 to Ver1.3.4

Please find the detailed problem statement below:

Some FX3/CX3 (USB 3.0 Device controller) units re-enumerate when connected under USB 3.0 host controller. The problem is seen on certain devices and noticed mainly when connected to Intel USB 3.0 host controller.

The workaround is already provided for this issue as a part of SDK 1.3.4. More details on the workaround is already mentioned in the thread link shared in this response. Please let me know if you have any queries on this.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

I read this thread. The FW designed in 1.3.3 has already been mass-produced. Can it have problems with this mass production system at any time? And my understanding that it is related to the PLL and may depend on  temperature. Is it correct?

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

For existing devices (mass production have been completed already), it is okay to go forward with SDK 1.3.3. But, for newer designs, we recommend that you use SDK 1.3.4.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

Even if the device wasn't a problem at first

Is it possible to have problems while using it?

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

Is it possible for you to share a USB trace captured using Lecroy when the failure is seen?

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

I have another question. The thread you have shown has the following:

> 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.

Does it mean that the FW created in 1.3.4 does not need to disable LPM? Does the user need to set in FW?

When I asked your company before, I received the answer, "It needs to take measures to disable LPM in FW." Currently, LPM is enabled immediately after connecting to the host, but once the user starts using the camera, LPM is disabled. I designed it that way in FW. However, the connection may still be lost. My understanding is that it doesn't go into U1 after disabling LPM, so it works fine with v1.3.3 as well. Is it correct?

About USB trace capture, LeCroy is not working normally in my environment. I may offer it in another way. please wait a moment.

Thanks,

Tetsuo

0 Likes

Hello,

We have seen that disabling the LPM permanently in the firmware will solve the problem mentioned in the response 3 of this thread.

The workaround provided as part of SDK 1.3.4 will fix the issues if the U1 exit LFPS from the host comes within 2-10 microseconds. However, there are cases where the Host initiates the U1 Exit within 1 microsecond after going to U1. The LPMA interrupt latency is more than a microsecond so the workaround cannot solve the problem in such cases where the exit is less than 2 microseconds (Ultra-fast U1 Exit).

To solve the Ultra-fast U1 Exit problem, The low power transitions must be disabled once the data transfer starts and they can be enabled back again when the system is in idle. i.e No data transfers are going on. This workaround will prevent the Host from sending the ultra-fast U1 Exits as it is observed that the ultra-fast U1 Exits only occur in middle of data transfers. All the LPM requests coming during the data transfer will be rejected by the device thereby avoiding the Ultra-Fast Exit problem.

So, even with SDK 1.3.4, it is recommended to disable LPM before data transfer. It can be enabled when the system is in idle or no data transfer happens.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

Is the existing FW really okay with 1.3.3? Is this behavior device-dependent and 1.3.3 specific?

Why can you say as follows? :

”For existing devices (mass production have been completed already), it is okay to go forward with SDK 1.3.3.”

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

Apologies for not being clear in my response 5. By "mass production have been completed already", I meant to say that the production is complete and the devices are deployed to field. By this, I was referring to older products which are on field - for such devices if a failure is reported, then the solution would be to update the FW built with SDK 1.3.4. For all other devices (devices that are not yet produced or devices whose production is complete but not yet deployed to field), we recommend that you use the FW with SDK 1.3.4 for preventing the issue that is mentioned in my response 3. As mentioned before, the issue mentioned in my response 3 can be fixed by the following ways:

1. Disabling LPM permanently (this fails compliance test).

(OR)

2. Using SDK 1.3.4 and disabling LPM during data transfers.

Regarding your question on if the issue is device specific, Yes as mentioned in the FX3 release notes, the issue occurs only with some devices in some lots using FW built with SDK 1.3.3.

Note : To confirm that the issue happening on your board is same as that mentioned in my response 3, we need to check the USB traces. So please share the USB traces as requested before.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

I measured a USB Trace. Please refer to attached files. There are 4 files as follow.

1). OK_25C

2). Error_64C

3). Error_67C

4). OK_66C

"OK" means normal operation, and "Error" means abnormal operation. The suffix number is the temperature in degrees Celsius at the time of log acquisition. All of these logs are the same camera and the same cable. 1),2),3) are FW using v1.3.3 library, and 4) is v1.3.4. Communication errors occur in 2) and 3) at high temperatures. It transitions to Recovery frequently.

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

Thank you for sharing the traces with us when the issue is seen. The traces show that the error is caused by the problem described in my response 3. Can you please confirm if the device is disconnected and re-connected on the host side when the error is seen?

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

It looks that this log is not U1, but it is transitioning from U0 to recovery. (Power saving mode is disabled in FW)

Is your answer about U1-> U0 recovery?

The v1.3.4 library does not transition from U0 to recovery.

Does disabling power saving mode not work for v1.3.3 libraries?

Tetsuo

0 Likes

Hello,

In the traces that show failure, you can see that the failures occurred only after U1 low power entry. The failure would have started when the device started to exit from U1. But the device transitioned to U0 that time. It is possible that the failure can occur later when the device is in U0. We have seen this issue also and it is related to the problem that is mentioned in my response 3

To avoid this from happening using SDK 1.3.3, you need to disable the LPM permanently in the firmware. This can be done by calling the API CyU3PUsbLPMDisable() after the API CyU3PConnectState() is called. It is recommended to add a delay of few microseconds between CyU3PConnectState() and CyU3PUsbLPMDisable(). Also, the API CyU3PUsbLPMEnable() should not be called anywhere in the firmware. As mentioned before, this workaround will cause the device to fail the compliance test. A better and recommended approach is to use SDK 1.3.4 and disable LPM during data transfer. You can enable LPM when there are no data transfers.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

And, please tell me how to check device is disconnected and reconnected.

Tetsuo

0 Likes

Hello,

In the firmware built using SDK 1.3.3, the host issues warm reset if link recovery fails. This makes the device to get disconnected and re-connected. You may see a loss of video in the host application when this happens.

You should be able to catch this by using Lecroy also. For this, set the analyzer to Trigger mode with the event set as Warm reset. Please share the lecroy trace captured with this setting.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

The trigger is different, but I confirmed the reconnection after disconnecting at high temperature.

If it gets hotter, it will not reconnect.

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

From the recoveries seen in the trace, we can confirm that the issue is same as what I mentioned in my response 3. We recommend that you use SDK 1.3.4 and disable LPM during data transfers to avoid this problem.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

In v1.3.3 FW, LPM is already disabled during data transfer. Therefore, it does not transition to U1. The transition cannot be confirmed in U1 even in the log.

My understanding is that "my response 3" is a problem when transitioning from U1 to U0. Is it correct? If it is correct, how is it related to this behavior?

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

As mentioned in my response 15, In the traces that show failure, you can see that the failures occurred only after U1 low power entry. The failure would have started when the device started to exit from U1. But the device transitioned to U0 that time. It is possible that the failure can occur later when the device is in U0. We have seen this issue also and it is related to the problem that is mentioned in my response 3.

>> My understanding is that "my response 3" is a problem when transitioning from U1 to U0.

It can happen while undergoing a transition from U1 to U0 or after transitioning from U1 to U0.

Please find a snapshot from a trace (3_Error_67C.usb) that was shared to us before having U1 exit:

pastedImage_0.png

We can see that the first failure happened after this exit from U1.

Best regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

I thought that it is making frequent transitions from U0 to Recovery in this log. Therefore, I thought that it had not transitioned to U1. I'm sorry for the lack of understanding, but where are you transitioning to U1?

Thanks,

Tetsuo

0 Likes

Hello,

Please find the snapshots from the trace 3_Error_67C.usb below in the sequential order of their occurrence:

1. Entry to U1:

pastedImage_1.png

2. Exit from U1 and transition to U0:

pastedImage_3.png

3.  The first failure in the tracepastedImage_4.png

As mentioned before, the failures started only after the device entered U1 low power state for the very first time. The cause for failure (that is described in my response 3) would have started when the device tried to exit U1. But it transitioned to U0 at that time without any problems. It is possible to see the failures later when the device is in U0. This is related to the problem described in my response 3. To avoid this problem, please use SDK 1.3.4 and disable the LPM during data transfers.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Hello,

If LPM is completely disabled, Plugfest will be NG. Therefore, FW is designed so that LPM is disabled when a command is received from a library that supports USB3 Vision.

The application recognizes the camera, but when I start the data transfer I get a communication error. If a USB3 Vision command is sent before data transfer, the transition will be U0-> U1-> U0 even though LPM is disabled.

Is it sometimes not possible to disable LPM in v1.3.3?

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

If you are using SDK 1.3.3, then you need to disable LPM permanently to fix this issue.

Once the API CyU3PUsbLPMDisable() is called in firmware, FX3 will not enter U1/U2 states. As per your description, a command is sent from the host to the device for disabling the LPM. But, there are chances that the device may undergo a transition to U1 before this command is received by FX3.

Due to this, you could be seeing communication errors. To avoid this, we recommend you to use SDK 1.3.4 build of the firmware and disable LPM during data transfers.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Hello,

If it gets a communication error while the first command is being processed, I think that's the cause. However, the error occurs after exchanging commands several times.

The error may occur when reading the XML file. Before that, commands such as getting the address where the XML file is saved have been sent, and the first command disables LPM.

Why is this?

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

Can you please share the Lecroy traces for the scenario described in your response 26 for us to check?

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
TeMa_2997106
Level 6
Level 6
Distributor - TED (Japan)
10 likes received 10 solutions authored 250 replies posted

Jayakrishna-san,

The camera it is currently using is Endpoint3 is being used for the USB3Vision command.

In "Error_64C.usb", Communication using Endpoint3 is being performed on 237034. In current FW, LPM should be disabled at this timing. However, unlike when using the v1.3.4 library there are many transitions from U0 to Recovery. At first, it seems that I was able to recover from Recovery, but it cannot recover around 360584.

Thanks,

Tetsuo

0 Likes

Hello Tetsuo-San,

The many transitions from U0 to recovery indicates that the failure mentioned in my response 3 has occurred. As I mentioned before, the failure need not happen at the time of exit from U1. It can occur later on. This is related to the problem mentioned in my response 3. Please let me know if we can have a webex meeting to discuss more about this thread.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes