FX3 doesn't send ACK in SETUP-phase of USB standard request

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.
RoKl_290166
Level 4
Level 4
Welcome!

Hi,

I'm using FX3 in a USB bus-powered camera system and build the according firmware with FX3 SDK 1.3.3.

We have an USB issue during Startup of the camera where in about 1 of 500 Startups the camera doesn't enumerate at the USB root hub. It occurs as an "Unknown Device" in the device Manager.

The PC Setup is as follows:

OS: Windows 10 64bit, Version 1809, build 17763.379

CPU: i7-4790

RAM: 16GB

USB Host Controller: Intel chipset

USB Host Controller Driver: 17763.379 14.09.2018

We disabled the USB LPM in the PC host-System since we want to avoid running into the issue where FX3 is not able to leave U1/U2 in some cases (acc. to Cypress Troubleshooting guide Version 1.3.3, chapter 2.2 "Unexpected Connection Failures").

The use case is:

1. camera is plugged to USB 3-port of PC and works fine

2. the PC is shutdown

3. if the PC is down the USB-ports aren't powered anymore so the camera is off (LED is off)

4. the PC is powered on

5. in ~1 of 500 cases the camera is not available in Windows device Manager after Windows has booted:

- In the case of error the LED of the camera tells us that the camera is in USB HighSpeed-mode. The USB-Speed is signaled by LED and is updated twice during Startup-Phase: after receiving USB-Event CY_U3P_USB_EVENT_CONNECT and after receiving USB Standard request SET_CONFIGURATION(1).

- in a good case the USB-Connection during Startup is initially with USB HighSpeed and changes later to USB SuperSpeed

Luckily, we were able to record the issue with LeCroy USB-analyzer. After analyzing the trace we have seen that the FX3 doesn't behave properly with respect to USB specification. In the case of error the host initiates a USB Standard request (i.e. GetDescriptor) using a SETUP-transaction with a DataPacket (DP) but the FX3 doesn't respond with a ACK-packet on it (see attached "ErrorCase.png"). I think, according to USB-spec the device always needs to answer the SETUP DP (as shown in "GoodCase.png") but it could NAK or STALL the consecutive DATA-Transaction if it's not yet ready or has no data or an error occured.

So my questions are :

1. Do you know this Kind of error already and have an appropriate fix for it?

2. If not: can you help me to fix this issue, please?

The whole Thing is quite critical since it's not accepted by our customers that the camera doesn't Startup properly, even in such rare cases like 1 of ~500 Startups.

Thanks!

Best regards,

Robert

0 Likes
21 Replies
abhinavg_21
Moderator
Moderator
Moderator
50 likes received 25 likes received 10 likes received

Hi Robert,

Please share the complete USB trace files. Also explain why in good case camers is behaving as USB 2.0 device initially and then moving to USB 3.0. Is it expected? Have you made any changes in the firmware?

Which base firmware are you using? Is it a SDK example or custom firmware?

Thanks & Regards

Abhinav Garg

0 Likes

Hi Abhinav,

I attached the trace-files of a good and a bad case.

In the good tracefile you can see that after changing the Speed from HighSpeed to SuperSpeed the host issues a SetAddress and a GetDescriptor(DeviceDescriptor) (see marker "USB3 (Transfer 40)").

In the bad tracefile there is also a SetAddress after changing the Speed from HighSpeed to SuperSpeed (see marker "SetAdd U3 (Transfer4142)") followed by a DP belonging to the SETUP-Phase of the GetDescriptor(DeviceDescriptor)-request of the host. Here, the FX3 doesn't ack the DP which is not conform to the USB-spec.

It seems, that the error occurs only if such a Speed-Change from HighSpeed to SuperSpeed occurs. This happens only in case where the camera is connected to the USB SuperSpeed-port, the host PC is shutdown and started again. In this case (I don't know why) we observed that the camera is enumerated first in HighSpeed-mode and then in SuperSpeed-mode.

We use a custom Firmware wich is far away from any example Firmware.

Best regards,

Robert

0 Likes

Hi there,

are there any News from Cypress-side rgd. this Topic?

Best regards,

Robert

0 Likes

Hi Robert,

After looking into the traces I found that the device is going into LPM mode. Kindly disable the LPM mode in the FX3 using "CyU3PUsbLPMDisable ( void )" API. Also comment out all the instances of "CyU3PUsbLPMEnable ()" in whole firmware.

Thanks & Regards
Abhinav Garg

0 Likes

Hi Abhinav,

I already disabled LPM by calling API CyU3PUsbLPMDisable() right after enabling USB3-connection:

--- snipped start ----

CyU3PConnectState(CyTrue, CyTrue);

CyU3PUsbLPMDisable();

--- snipped end ----

I also return CyFalse in the LpmRequest-callback registered by calling API CyU3PUsbRegisterLPMRequestCallback() to reject all LPM-requests:

--- snipped start ----

priv_itf_usbLPMRequestCallback(CyU3PUsbLinkPowerMode linkMode)

{

  return CyFalse;

}

--- snipped end ----

I'm wondering why the LPM-requests are accepted anyway?!

Kind regards,

Robert

0 Likes

Kindly check the whole firmware and comment out all the LPM Enable API.

Regards
Abhinav

0 Likes

I did! No call of LPM Enable API.

Is there a Register where I could check the state of LPM Enable?

0 Likes

Hi Abhinav,

I checked the disassembly code of the API and found two Registers that are involved in disabling LPM:

0xE0032074 where Bit 22 is Zero when LPM is disabled and one if LPM is enabled

0xE0033050 where Bits 28 & 29 are one when LPM is disabled and Bits 26 & 27 are one when LPM is enabled

Can you confirm?

Regards,

Robert

0 Likes

Hi Robert,

You are right about "0xE0033050" register but if you check the FX3 TRM, Bit 22 of "0xE0032074" register is reserved and no usage is specified for it.

Thanks

Abhinav

0 Likes

Hi Robert,

Will you be able to stop the device to go into LPM state.

Have you checked the above mentioned registers content?

Thanks & Regards

Abhinav Garg

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Abhinav,

according to the register-settings the LPM is definitely disabled (register 0xE0033050 is set to 0x30000000).

Anyhow, in the meanwhile I found the root cause of the failure by comparing the example-firmware 'bulklpauto' (which doesn't Show the failure) and my custom Firmware!

We use 32bit GPIF so I Need to set the Parameter 'setSysClk400 = CyTrue' in the struct 'CyU3PSysClockConfig_t' while configuring the clock-Settings using API CyU3PDeviceInit() which is called in main(). In fact, this is the way it is described in the FX3 SDK Firmware API Guide:

"

    The setSysClk400 parameter specifies whether the FX3 device's master clock is to

    be set to a frequency greater than 400 MHz. By default, the FX3 master clock is set

    to 384 MHz when using a 19.2 MHz crystal or clock source. This frequency setting

    may lead to DMA overflow errors on the GPIF, if the GPIF is configured as 32-bit

    wide and is running at 100 MHz. Setting this parameter will switch the master

    clock frequency to 403.2 MHz during the CyU3PDeviceInit call.

"

So, if I set this Parameter to 'setSysClk400 = CyFalse' the failure is completely gone!!! Unfortunately, the 32bit GPIF doesn't work anymore with this Setting.

I was able to even reproduce the issue with the example-firmware 'bulklpauto' by Setting this Parameter to CyFalse and configuring the IO's using 32bit GPIF. Please note, that the GPIF is actually not enabled and active in the failing configuration. I attached the according example-firmware with the failing configuration. The Basic example-firmware I took from SDK1.3.0 and changed the clock- and IO-configuration as described above and further disabled the LPM-mode right after calling CyU3PConnectState(). I built this code with SDK1.3.4 libraries and tested it at the following PC-System:

Dell Optiplex 7010, Intel Core i5-3470 @ 3.2GHz, 8GB RAM

Windows 7 Enterprise 64bit SP1

Intel USB3.0 eXtensible Hostcontroller (onboard), Driver Intel Corporation V1.0.10-255 17.09.2013

I run an automated test where the test-PC with the Cypress FX3 DVK Device Board Rev3 connected to a USB3-port (in bus-powered configuration) and the modified 'bulklpauto'-Firmware running on it is shutdown and started automatically. After the PC finished booting of Windows a Python-script is executed which checks if the USB-device to test is enumerated at the System. If it's not the case the check is repeated 3 times. If the device can not be found the test aborts with failure. The attached "log.txt" Shows that the device wasn't found after 102 Startups of the test-PC.

So, here're my questions:

1. Can you reproduce the issue at your side with the example-firmware I provide you in the attachment?

2. If yes, is it possible to Analyse to root-cause of this issue in the FX3 and provide a patched SDK?

3. What can we do to get 32bit GPIF with 384Mhz Setting functional?

Best regards,

Robert

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Robert,

- In the Response No 2 you have shared the USB traces both good and bad. In the bad trace, was the system rebooted many times?

- In your firmware(using which I assume the above mentioned good and bad traces were collected) do you ever call CyU3PUsbSendDevNotification() API.

- In the previous discussions I see your comment that, you call LPMDisable() just after ConnectState(). Can you place the LPMDisable() call when you receive SET_CONFIGURATION from the Host (which you already know that SET_CONF can be seen in USBEventCb). - Try this and let me know the difference.

- Related to last response:

Can you share the Python Script file?

Regards,

Hemanth

Hemanth
0 Likes
lock attach
Attachments are accessible only for community members.

Hi Hemanth,

Thanks for having a look to this issue!

Regarding your questions:

Question: “In the Response No 2 you have shared the USB traces both good and bad. In the bad trace, was the system rebooted many times?”

Answer: Yes, that might be the case.

Question: “In your firmware(using which I assume the above mentioned good and bad traces were collected) do you ever call CyU3PUsbSendDevNotification() API.”

Answer: Yes, I took the traces with my firmware. No, I never call CyU3PUsbSendDevNotification() in my firmware.

Question: “In the previous discussions I see your comment that, you call LPMDisable() just after ConnectState(). Can you place the LPMDisable() call when you receive SET_CONFIGURATION from the Host (which you already know that SET_CONF can be seen in USBEventCb). - Try this and let me know the difference.”

Answer: I could do this but it probably wouldn’t change anything since according to the trace the problem occurs BEFORE SetConfiguration(). If I disable LPM only with receiving SetConfiguration() the FX3 might get stuck even during enumeration due to LPM issue, isn’t it?

I attached the Python script and the according .json-file which configures the test. It’s exactly the same configuration which I used to test the BulkLoopExample.

Please ensure that the PC under test is really shutdown (NOT just restarted) and USB VBUS is off if the PC is shutdown (maybe an option in Bios-setup). Otherwise you might not be able to provoke the failure.

Thank you!

Best regards,

Robert

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Hemanth,

rgd. your question "Can you place the LPMDisable() call when you receive SET_CONFIGURATION from the Host (which you already know that SET_CONF can be seen in USBEventCb). - Try this and let me know the difference.":

I took the "UsbBulkLoopAuto" example Firmware from SDK1.3.4 where the LPM is disabled with SetConfiguration() and changed the clock and IO-Settings according to my previous description so clkCfg.setSysClk400 = CyTrue and io_cfg.isDQ32Bit = CyTrue; (see attached Project).

---- snippet start ----

/*
* Main function
*/
int
main (void)
{
    CyU3PIoMatrixConfig_t io_cfg;
    CyU3PReturnStatus_t status = CY_U3P_SUCCESS;
    CyU3PSysClockConfig_t clkCfg;

    /* Enable memory corruption checks. */
    CyU3PMemEnableChecks (CyTrue, FxAppMemCorruptCb);
    CyU3PBufEnableChecks (CyTrue, FxAppMemCorruptCb);

    // Initialize clocks, VIC and exception vectors
    clkCfg.clkSrc          = CY_U3P_SYS_CLK;  // divider for SYS_CLK_PLL, SYS_CLK is ~403.2MHZ w/ 19.2MHz oscillator
    clkCfg.cpuClkDiv        = 2;        // divider for CORE_CLK (derived from SYS_CLK): CORE_CLK is ~200MHz
    clkCfg.dmaClkDiv        = 2;        // divider for DMA_BUS_CLK (derived from CORE_CLK): DMA_BUS_CLK is ~100MHz
    clkCfg.mmioClkDiv      = 2;        // divider for MMIO_BUS_CLK (derived from CORE_CLK): MMIO_BUS_CLK is ~100MHz
    clkCfg.useStandbyClk    = CyFalse;  // use external 32kHz-standby-Clk: no (it's derived from 19.2MHz oscillator)
    clkCfg.setSysClk400    = CyTrue;

    /* Initialize the device */
    status = CyU3PDeviceInit (&clkCfg);
    if (status != CY_U3P_SUCCESS)
    {
        goto handle_fatal_error;
    }

    /* Initialize the caches. Enable both Instruction and Data Caches. */
    status = CyU3PDeviceCacheControl (CyTrue, CyTrue, CyTrue);
    if (status != CY_U3P_SUCCESS)
    {
        goto handle_fatal_error;
    }

    /* Configure the IO matrix for the device. On the FX3 DVK board, the COM port
    * is connected to the IO(53:56). This means that either DQ32 mode should be
    * selected or lppMode should be set to UART_ONLY. Here we are choosing
    * UART_ONLY configuration. */
    io_cfg.isDQ32Bit = CyTrue;
    io_cfg.s0Mode = CY_U3P_SPORT_INACTIVE;
    io_cfg.s1Mode = CY_U3P_SPORT_INACTIVE;
    io_cfg.useUart  = CyTrue;
    io_cfg.useI2C    = CyFalse;
    io_cfg.useI2S    = CyFalse;
    io_cfg.useSpi    = CyFalse;
    io_cfg.lppMode  = CY_U3P_IO_MATRIX_LPP_DEFAULT;
    /* No GPIOs are enabled. */
    io_cfg.gpioSimpleEn[0]  = 0;
    io_cfg.gpioSimpleEn[1]  = 0;
    io_cfg.gpioComplexEn[0] = 0;
    io_cfg.gpioComplexEn[1] = 0;
    status = CyU3PDeviceConfigureIOMatrix (&io_cfg);
    if (status != CY_U3P_SUCCESS)
    {
        goto handle_fatal_error;
    }

    /* This is a non returnable call for initializing the RTOS kernel */
    CyU3PKernelEntry ();

    /* Dummy return to make the compiler happy */
    return 0;

handle_fatal_error:

    /* Cannot recover from this error. */
    while (1);
}

---- snippet end----

With this, the failure also occured so the FX3 evalboard didn't enumerate after 27 cycles of "PC shutdown & Startup"!

Best regards,

Robert

0 Likes

Hi Hemanth,

do you have any updates regarding this issue?

Have you been able to reproduce the issue?

Can I help you somehow to get further progress?

Regards,

Robert

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Robert,

Yes, I have some update.

Initially I ran into an error importing win32com.client and I was able to rectify it.

But now the line "from jsonconf.data import JsonConf" is throwing error when I ran the module.

The error is: cannot import name 'JSONConf' from 'jsonconf'

So, can I know which Python version was used to make this script?

I am trying currently with Python3.7

Regards,

Hemanth

Hemanth
0 Likes
lock attach
Attachments are accessible only for community members.

Hi Hemanth,

the JSONConf module is our own implementation.

Please find attached a modified script where the Import of this module is eliminated and the according reference in the script is replaced by a general one.

Best regards,

Robert

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Robert,

When you tested with FX3 DVK Rev 3 Board, which Boot mode did you use? I2C Or SPI?

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

sorry for delay, Robert is in vacation. We use the SPI Boot.

Best regards,

Marco

0 Likes
maHe_281876
Level 1
Level 1

Hi Hemanth,

we are still waiting of feedback from your side. Is there any update of your tests?

Best regards,

Marco

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hello Marco,

Yes, I have tried firmware from the attachment 'USBBulkLoopAuto_134' posted by Robert on this thread on FX3 Explorer kit with I2C boot.

I have tested on below configurations:

(1) Intel eXtensible Host Controller, Windows 10 OS (2) Fresco 3.0 Host Controller, Windows 8.1 OS

Did restart around 450 times (made sure VBUS is cut-off in both cases during restart).

I was not able to reproduce the issue in the above two tests.

Regards,

Hemanth

Hemanth
0 Likes