Reception On Endpoint 129 Failed

[Miina Hunker]

Specificallythis example deals with an XMedius fax server, a Cisco voice gateway with PRI, and a who-knows-what fax endpoint on the other side. Your mileage in fax troubleshooting may and likely will vary, just keep that in mind and a drink at hand.

I opened the packet capture for one of the failed attempts, navigated to Telephony -> VoIP Calls -> and then selected Flow for my call. When you do this, there will be quite a bit of information presented in graph form.

After working with TAC and doing a PCM capture on the gateway, I was able to confirm that the remote endpoint never sends the CFR, which meant I could declare with some amount of relative certainty that this was a whole lot of not-my-problem.***

TAC even provided me this handy-dandy flow graph built from the captures we took on the gateway, you can see that the fax server tries three times (TCF (9600)) to get the remote end to cough up a CFR, but no dice.

In this location previously was a red series dimmer that I wanted to move so my new blue series could control my hue lights directly so I popped out the red series and put the blue in. At first I could config the switch to dimmer on the device (orange flashing) but no other configs would work (down + 5x config for multi-way aux for example), including setting up smart bulb mode. I did get it to pair pretty easily and the settings actually changed correctly and the switch was mostly working (it could change brightness of the hue lights in smart light mode).

Weirdly, the switch that had the reception issues (that this new one was replacing) has firmware 02.00 and I can see ControlLevel endpoint 1 and everything could theoretically work - but the reception issue with it means I can only set it up right next to my HA box.

I have done this already a couple times. I tried the air gap to restart the switch, then restarted home assistant to see if that would do anything and then did the factory reset holding up+config where it goes green, yellow, and then red, and released after it had been red for a couple seconds.

So for clarity, you can successfully remove the switch from HA, factory reset and then re-join it to HA? It shows up in HA with the right quirk (the VZM31SNv12 you had in the original screenshot)? If so, can you turn on/off the load from the hub as well? These should confirm the basic communication with the switch.

@chack - So looks like it could have been a hardware issue elsewhere. I ended up moving to a new zigbee stick over the weekend and re-set up the network. The grouping and associations worked perfectly.

So according to this thread, How To's Setup Zigbee Binding - Home Assistant (ZHA) is a bit outdated, as we want to bind to endpoint 2 for the switch. That is working for me and was my primary confusion.

We've developed firmware for a Cypress FX3 that implements a single interface with 4 bulk endpoints. One of the endpoints is for commands, another for status, and the remaining two endpoints are for bulk data OUT and bulk data IN. The host application initiates a transfer by sending a command on OUT endpoint 1 and then reading a status response on IN endpoint 2. Bulk data (if part of the transaction) is then exchanged using OUT endpoint 3 and IN endpoint 4. Everything works as expected when the device enumerates as a USB 2.0 device. However, I'm having an issue with the status endpoint (IN endpoint 2) when in super speed mode.

The host side initiates a read of the status endpoint and then sends the command. The USB 3 packet analyzer (Ellisys USB Explorer EX350) shows that the device responds to the IN request with a NRDY packet. The command is then sent and received by the device, and by stepping through the firmware in the debugger I can see that the status response gets committed. However, the FX3 never responds with ERDY and per USB 3 specification, the host does not attempt to read the IN endpoint again.

If I re-arrange the order of operations on the PC side (send command and then issue status read) and put a delay between sending the command and then reading the status endpoint, the device does indeed respond with the expected status packet. However, this is because the device never entered a flow control state. It is unrealistic to expect the device to be able to deliver the data immediately each time the application asks for it. I see no way to avoid the device occasionally entering a flow control state where it needs to send ERDY after it previously sent NRDY. How do I get the device to place ERDY on the USB bus once data is committed to the endpoint?

The host side software opens handles for each of the endpoints and overlapped structures so that it can perform asynchronous read/write oprations. Reads and writes are initiated through calls to ReadFile and WriteFile with the OVERLAPPED structure for the appropriate endpoint passed. We then call WaitForMultipleObjects or WaitForSingleObject to determine when the operation has completed or timed out and later call GetOverlappedResult to determine the status of the transfer. We've been using the same PC side code with FX2 and AVR USB controllers for over 10 years now and haven't had any issues. ANd as I mentioned, this code along with the FX3 firmware works as expected with USB 2.0. The difference is that in USB 2.0 mode the host will keep issuing IN tokens until the transfer completes or until the read is cancelled by the host application. With USB 3.0 the host seems to follow the USB specification and won't issue another IN after it has received NRDY until the device sends an ERDY.

We don't presently have the UART hooked up in our application. I am presently using a Cypress Superspeeed Explorer Kit so it should be possible to connect the UART, but that's going to require some time.

I know the DMA buffer commit happens because I can continue to run the application and on the packet analyzer I can see that command is still being accepted by the device. If it were stuck in the loop then it wouldn't be consuming the command and would be stuck in one of the infinite loops.

Is there any chance that Superspeed Explorer has engineering silicon on it that has errata that could be causing the lack of ERDY responses? I guess I will modify the software and firmware and try a different USB endpoint to see if that makes any difference.

I found a way to work around the problem by calling CyU3PUsbSendErdy(endpaddrSts, 0) after CyU3PDmaChannelCommitBuffer(&dmachStsEndp, cbStsBuf, 0). Making this call after I process the start command seems sufficient and it wasn't necessary to add the call anywhere else that I commit the DMA buffer for that endpoint. Am I doing something wrong or is this a bug in the FX3 PHY or USB Stack?

I ran into similar issue on the DTO endpoint (bulk data transfer out from host to device, endpoint 3). This endpoint gets configured when the host sends a set configuration request but the DMA channel isn't created until the PC sends a command to perform a data transfer. When the command is received I create an auto channel with signal:

Once the transfer completes the PC sends an end command on the CMD endpoint (endpoint 1), a status packet containing an error code and amount of bytes is created, and committed to the STS endpoint (endpoing 2). The DMA channel is then destroyed by executing the following code:

The 16 byte download always succeeds and the packet analyzer shows that when the data packet is sent to the DTO endpoint (endpoint 3) the ACK sent by the FX3 specifies 0 in the number of packets field, as expected, because it doesn't expect to receive anymore data since the auto channel completed the transfer. According to the USB 3.2 specification the endpoint is now in the flow control state and must respond with ERDY before the host will issue another OUT. When the PC side application goes to perform the next download the AUTO DMA channel is created again with a non-zero number of bytes specified to be transferred between the USB periperhal and GPIF II interface. However, my packet analyzer shows that the FX3 never sends ERDY and as a result, the host never issues the OUT on that endpoint and won't issue a new out on the endpoint until CLEAR_FEATURE ENDPOINT_HALT is sent, which we send after the transfer times out.

In case you are wondering why I'm creating and destroying the DMA channel: it's because I have two different modules that need to perform data transfers. One is used for FPGA configuration and the other is used for bulk data transfer between the PC application and the FPGA logic. Both use the GPIF II interface but they use separate state machines and their code resides in different modules.

From your response, I understand that the DMA channel is being created and then destroyed once the data transfers are completed. And you are expecting that the endpoint related to that particular DMA channel should send ERDY when not in use. Is my understanding correct?

I'm describing two different scenarios where I'm having an issue with ERDY not being sent. The first scenario involves a bulk IN endpoint that has a manual OUT DMA channel attached to it with the CPU as the producer and the consumer as the UIB endpoint 2. This channel is created when the FX3 notifies the application firmware of a configuraiton event and remains in existence until notification of a disconnect or reset. This is what my first post was about and my expectation is that when the IN endpoint entered the flow control state due to the host requesting data that wasn't yet available, the FX3 should issue ERDY when I commit a buffer to the DMA channel attached to the . Since neither the USB endpoint or DMA was reset or reconfigured, the FX3 should be aware that the endpoint is in the flow control state when I commit the DMA buffer it should issue ERDY on the USB bus. However, it does not issue ERDY on the bus unless I explicitly call CyU3PUsbSendErdy after commiting the DMA buffer.

The second scenario is a different issue that also involves ERDY. Let me try to summarize that scenario into the steps taken:

0. FX3 is connected to PC

1. PC sets configuration 1

2. Firmware configures USB endpoints 1, 2, 3, and 4 via calls to CyU3PSetEpConfig.

3. Firmware creates a manual IN DMA channel for endpoint 1 (we call this the CMD endpoint) with producer = CY_U3P_UIB_SOCKET_PROD_1 and consumer = CY_U3P_CPU_SOCKET_CONS. The transfer size passed to CyU3PDmaChannelSetXfer is 0. A callback is registered for the producer event.

4. Firmare creates a manual OUT DMA channel for endpoint 2 (we call this the STS endpoint) with producer = CY_U3P_CPU_SOCKET_PROD and consumer = CY_U3P_UIB_SOCKET_CONS_2. The transfer size passed to CyU3PDmaChannelSetXfer is 0. A callback is registered for the consumer event.

5. Firmware is now in a loop where it takes different actions based on the current state. The state it is in has it waiting for an event that signals notification of the reception of a buffer via the CMD endpoint.

6. At some point later in time the PC application handles to all 4 USB endpoints.

7. PC sends a 64 byte or smaller command packet on CMD endpoint and initiates a read on the STS endpoint (this IN request results in NRDY because FX3 is not ready yet)

8. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).

9. Firmware dispatches the command to the appropriate handler. Received command is to enable the FPGA data interface. The GPIF peripheral is initialized but no DMA is created.

10. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint). This is where ERDY would need to be sent so the host will retry the IN request.

11. PC receives status response from STS endpoint

12. PC sends command packet (CMD = data transfer to FPGA) on CMD endpoint and initiates a read on STS endpoint

13. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).

14. Firmware calls dispatch for the CMD, which creates an auto channel DMA with producer = CY_U3P_UIB_SOCKET_PROD_3 and consumer = CY_U3P_PIB_SOCKET_3. Notification is setup for both CY_U3P_DMA_CB_XFER_CPLT CY_U3P_DMA_CB_CONS_EVENT to call a callback function.

15. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint).

16. PC receives status response from STS endpoint

17. PC calls WriteFile on USB OUT endpoint 3 to send a 16 byte packet to the FPGA Logic

18. PC waits for data transfer to complete

19. FX3 DMA transfers 16 bytes to GPIF and then DtoEndpointDmaCallback is executed and signals an event to let firmware know transfer has completed

20. PC sends end transfer command on OUT endpoint 1 and initiates a read of IN endpoint 2 (STS)

21. Firmware receives end transfer command and executes the end handler, which destroys the auto DMA channel that was created between CY_U3P_UIB_SOCKET_PROD_3 and CY_U3P_PIB_SOCKET_3

22. Firmware commits status response including error code (no error) and transferred byte count (16 in this case) to IN endpoint 2 manual DMA

23. PC receives status response

24. PC sends command packet (CMD = data transfer to FPGA) on CMD endpoint and initiates a read on STS endpoint

25. Firmware receives event notifying it that there is a data packet in the DMA buffer that came from endpoint 1 (CMD endpoint).

26. Firmware calls dispatch for the CMD, which creates an auto channel DMA with producer = CY_U3P_UIB_SOCKET_PROD_3 and consumer = CY_U3P_PIB_SOCKET_3. Notification is setup for both CY_U3P_DMA_CB_XFER_CPLT CY_U3P_DMA_CB_CONS_EVENT to call a callback function.

27. Firmware commits 2 byte response to IN endpoint 2 (STS endpoint).

28. PC receives status response from STS endpoint

29. PC calls WriteFile on USB OUT endpoint 3 to send a 50,000,000 byte packet to the FPGA Logic. THIS is when the PC should issue and OUT token but does not because the NumP field of the ACK response issued by the FX3 in response to the 16 byte packet sent on OUT endpoint 3 in step 17 contains 0 meaning that the PC side controller thinks that the endpoint is in the FLOW control state and will not issue OUT until the FX3 issues ERDY.

30. PC waits for data transfer to complete but times out after 30 seconds because FX3 does not send ERDY even though a DMA transfer was setup on OUT endpoint 3

31. PC sends command packet contain abort command

32. PC sends end command and initiates status read

33. Firmware receives abort command, destroys the DMA and performs any other cleanup (endpoint flush and reset)

34. Firmware receives end command and doesn't do anything but reset the state machine after generating a 6 byte reponse that includes the aborted transfer error code and the number of bytes that were successfully transfered (0 in this case)

35. Firmware commits status response to endpoint 2 DMA and waits for a new command

36. PC receives status response

37. PC issues CLEAR_FEATURE ENDPOINT_HALT on endpoint 3 (DOUT endpoint)

38. Firmware handles CLEAR_FEATUE ENDPOINT_HALT:

CyU3PUsbFlushEp(endpaddrDto);

CyU3PUsbResetEp(endpaddrDto);

CyU3PUsbStall(endpaddrDto, CyFalse, CyTrue)

3a8082e126