You are here

FX3 SDK: Need an alternative CyU3PUsbGetEP0Data suppressing STATUS stage | Cypress Semiconductor

FX3 SDK: Need an alternative CyU3PUsbGetEP0Data suppressing STATUS stage

Summary: 2 Replies, Latest post by Frank L on 23 Jan 2015 02:04 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
Frank L's picture
8 posts


I have recently migrated from FX2 to FX3, and now I struggle with how to receive the result of vendor requests. The most efficient means for just telling success or failure is the STATUS stage.

The FX2 has had a register bit "HSNAK" that caused the STATUS stage of a vendor request to be postponed, e.g. until the firmware has completed data processing.

The FX3 SDK lacks of such a feature. As soon as OUT Data have been "fetched" (CyU3PUsbGetEP0Data) it sends out ACK in the STATUS stage.

Can by any means the FX2 behaviour be ported to FX3? I have found register bits like DEV_EPO_CS[0].NAK (bit 15) or PROT_EPO_CS1[0].NRDY (bit 1). Are they appropriate for the STATUS stage?
Unfortunately, a distinct "HSNAK" bit especially for STATUS stage is missing. I understand that there is a race condition when the firmware tries to set NAK bits after the DATA stage of a control transfer. Is there a way to ensure that the firmware wins this race?

Thanks, and Best Regards

PRAG's picture
Cypress Employee
173 posts


Unfortunately, this is a design limitation with the Fx3 silicon.

There is no dedicated register bit to NAK/delay the status stage of a control transfer.

There is no guaranteed way to postpone/Nak the status stage.

It will be a hit-and-miss affair if you try to set the Nak in firmware after the GetEP0Data() call.


Please explain your requirement in a little more detail. We might be able to suggest another approach for it.

Frank L's picture
8 posts

An example for that is register access to peripherals.

A vendor request sending data to a I2C or SPI device must first GetEP0Data, before it can start sending them to the peripheral. In case of failure (e.g. malfunction or peripheral not present) the control transfer could immediately return STALL in the STATUS stage.

Instead, with the FX3, another control transfer seems to be required to poll the outcome of the first request. Correct me if I am wrong, but this feels like being much slower and more complicated and error prone from the host programs point of view. What do you think about this?

However, I am very interested in your suggested approach :-)


Log in to post new comments.