cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

NiCo_4789341
New Contributor II

I've been adapting the code from FX3 / CX3 Firmware for Streaming RAW Image Data using Cypress Driver to my hardware.

I can now use the Streamer application to receive data and the data-rate perfectly fits the theoretical H*V*bpp*fps.

I've set the GPIF II bus width to 24 and I'm using multiple-to-one transfers with those (default) settings:

#define CX3_UVC_DATA_BUF_SIZE               (0x6000)    // DMA Buffer Data Size Used: 24576 Bytes
#define CX3_UVC_PROD_HEADER                 (0)        // UVC DMA Buffer Header Size
#define CX3_UVC_PROD_FOOTER                 (0)         // UVC DMA Buffer Footer Size

I wonder why those are the only settings I can make work!

I'm trying to set the header and footer in order to add a custom payload (in principle this is not different from UVC 12-bytes header)

I've made experiments with differets sets of values, in order to keep:

1. CX3_UVC_DATA_BUF_SIZE + CX3_UVC_PROD_HEADER + CX3_UVC_PROD_FOOTER divisible by 16

2. CX3_UVC_DATA_BUF_SIZE divisible by 16 and 24.

3. CX3_UVC_DATA_BUF_SIZE * CX3_UVC_STREAM_BUF_COUNT * CX3_UVC_SOCKET_COUNT < ~220KB

In fact I get no errors from the CyU3PMipicsiGpifLoad and CyU3PGpifSMStart nor from the CyU3PDmaMultiChannelCreate calls.

Nevertheless, when I start the streamer it reads a few bytes at the very beginning, then the device enters in a loop of "stop and restart".

Seems like if I setup the producer to write in the DMA buffer using offsets (header and/or footer) something goes wrong.

Can someone help me? Am I missing some constaint?

0 Likes
1 Solution
NiCo_4789341
New Contributor II

Hi Yashwant,

forgive me for my belated reply.

There are no problems related to start/stop of the stream and device reset.

I went through an in-depth analysis of the differences in UVC and non-UVC firmware and how they interact with system drivers.

I can say that the reference UVC firmware when switched to non-UVC mode (or RAW mode, if you prefer) needs a couple of non-obvious patches for proper operation.

Now my stream is stable, I almost never detect the error code 47 and in the very rare case the stream restarts immediately (obviously losing a frame).

Regards,

Nicola.

View solution in original post

0 Likes
14 Replies
Rashi_Vatsa
Moderator
Moderator

Hello,

Please let me know the video resolution and frame rate that you are streaming through CX3.

Also, add the debug prints to get the status of glDmaDone, glDMATxCount, glHitFV inside the for loop of CyCx3UvcAppThread_Entry function and share the UART debug prints

- Please let me know if you get the CX3_DMA_RESET_EVENT event. This event is set at two instances in the firmware

1) When CyU3PDmaMultiChannelCommitBuffer API int the CyCx3UvcAppDmaCallback fails. Please check the return status of this API.

2) When the frame timer expires UvcAppProgressTimer

If this event occurs when you change the DMA buffer setting, please let me know which of the above  two instances causes the CX3_DMA_RESET_EVENT

Please let us know the CX3_UVC_DATA_BUF_SIZE, CX3_UVC_PROD_HEADER, CX3_UVC_PROD_FOOTER, and CX3_UVC_STREAM_BUF_COUNT after the modifications to the firmware.

Regards

Rashi

Regards,
Rashi
0 Likes
NiCo_4789341
New Contributor II

Hi Rashi,

my application is actually a stereo-camera. The MIPI lines from two sensors are "mixed" into one by an little FGA (crossfire by Lattice), hence the frame size is a little bit uncommon: 2784x1000@~60fps

CyU3PMipicsiCfg_t RAW10_DUAL_1392x1000 =

{

        CY_U3P_CSI_DF_RGB888,

        2,

        2,

        99,

        CY_U3P_CSI_PLL_FRS_250_500M,

        CY_U3P_CSI_PLL_CLK_DIV_4,

        CY_U3P_CSI_PLL_CLK_DIV_4,

        0x0000,                                                                                // uint16_t mClkCtl - set 0x1818 to get PLL_CLK/100 MCLK

        CY_U3P_CSI_PLL_CLK_DIV_2,

        2784,

        50

};

Today I've been working on a different desktop machines and I've experienced a weird bahavior.

So, I have two different machines, call them pc-A and pc-B.

Both of them work flawlessly with the same firmware in UVC mode.

When I change to "custom bulk mode" pc-A works OK with those settings:

#define CX3_UVC_STREAM_BUF_COUNT            (4)
#define CX3_UVC_DATA_BUF_SIZE               (0x6000)   // DMA Buffer Data Size Used: 24576 Bytes
#define CX3_UVC_PROD_HEADER                 (0)        // UVC DMA Buffer Header Size
#define CX3_UVC_PROD_FOOTER                 (0)        // UVC DMA Buffer Footer Size

but pc-B cannot stream at all.

If I try a slightly different settings, for example:

#define CX3_UVC_STREAM_BUF_COUNT            (4)
#define CX3_UVC_DATA_BUF_SIZE               (0x6000)   // DMA Buffer Data Size Used: 24576 Bytes
#define CX3_UVC_PROD_HEADER                 (48)       // UVC DMA Buffer Header Size
#define CX3_UVC_PROD_FOOTER                 (0)        // UVC DMA Buffer Footer Size

neither pc-A nor pc-B can stream any more.

In both cases this is the problem:

CX3_DMA_RESET_EVENT is always triggered by an error in the CyU3PDmaMultiChannelCommitBuffer function.

Here is the debug otput:

AppInit: GpifSMStart passed

bRType = 0xC0, bRequest = 0xA0, wValue = 0xE600, wIndex = 0x0, wLength= 0x1

bRType = 0x40, bRequest = 0x99, wValue = 0x0, wIndex = 0x0, wLength= 0x0            <- start command

Callback error: glDmaDone = 8 glDMATxCount = 21  glHitFV  = 0

Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

..

Callback error: glDmaDone = 8 glDMATxCount = 8  glHitFV  = 0

[... infinite sequence]

thank you for your suggestions.

0 Likes
YashwantK_46
Moderator
Moderator

Hello NiCo_4789341​,

Can you please let me know if the device is enumerating properly in both the cases?


Also, can you please share your firmware so that I can review it on my end?

Regards,

Yashwant

0 Likes
NiCo_4789341
New Contributor II

Hi Yashwant,

I cannot see any problem with enumeration.

I wonder if the problem could be more on the host application side, maybe related to different USB 3.0 chipsets.

Shall I post my code here in the blog?

I'm developing this device for a customer, under NDA.

0 Likes
YashwantK_46
Moderator
Moderator

Hello NiCo_4789341​,

When I change to "custom bulk mode" pc-A works OK with those settings:

#define CX3_UVC_STREAM_BUF_COUNT           (4)
#define CX3_UVC_DATA_BUF_SIZE              (0x6000)  // DMA Buffer Data Size Used: 24576 Bytes
#define CX3_UVC_PROD_HEADER                (0)       // UVC DMA Buffer Header Size
#define CX3_UVC_PROD_FOOTER                (0)       // UVC DMA Buffer Footer Size

but pc-B cannot stream at all.

=> Can you please let me know the difference between both the PCs?
Are both the PC's using the windows or are they using different OS?

Let me know which host controllers are present in them as well.

Also, in the firmware, please add this in the dma callback as shown in bold:

status = CyU3PDmaMultiChannelCommitBuffer (chHandle, (DmaBuffer.count + CX3_UVC_PROD_HEADER), 0)

            if (status != CY_U3P_SUCCESS)

            {     

                    CyU3PDebugPrint (4, "CommitBuffer Failure: %x", status);

                    CyU3PEventSet(&glCx3Event, CX3_DMA_RESET_EVENT,CYU3P_EVENT_OR);

                    break;                 

            }

This would help in understanding the error code and debug better.

Also, you can comment the below line:

CyU3PDebugPrint(4,"\n\rCallback error: glDmaDone = %d glDMATxCount = %d  glHitFV  = %d", glDmaDone, glDMATxCount, glHitFV);

After doing the above changes, share the UART traces in pc-B.

Also, please provide Wireshark traces for both the PC's to get a better understanding of the streaming.

Regards,

Yashwant

0 Likes
NiCo_4789341
New Contributor II

Hi Yashwant,

sorry for my belated reply, it took some time to make some more in-depth tests.

Further analysis confirms that the pc-A is more stable since when you start the stream and no action takes place it can potentially continue indefinitely. However, it also stops streaming if any CPU greedy action takes place (for example starting a web-browser).

In the end, both pc-A and pc-B suffer from the same problem. Both the machines are equipped with Windows 10, updates installed.

When the stream stops the UART message is: CommitBuffer Failure: 47

Wireshark traces shows a regular sequence of host request and replies:

32938    87.004224    host    3.1.3    USB    27    URB_BULK in

32939    87.008248    3.1.3    host    USB    524315    URB_BULK in

packets sequence is  6x 524315 bytes + 1x 334299 bytes

then we have the crash sequence:

32991    87.070368    3.1.3    host    USB    524315    URB_BULK in

32992    87.070552    3.1.3    host    USB    8219    URB_BULK in               // an extra, small-sized packet?  -> host

32993    87.070552    host    3.1.3    USB    27    URB_BULK in

32994    87.070636    host    3.1.3    USB    27    URB_BULK in

32995    88.571234    host    3.1.3    USB    27    URB_FUNCTION_ABORT_PIPE

32996    88.571322    3.1.3    host    USB    27    URB_BULK in

32997    88.571368    3.1.3    host    USB    27    URB_BULK in

[..]

33011    88.571958    3.1.3    host    USB    27    URB_BULK in

33012    88.571996    3.1.3    host    USB    27    URB_FUNCTION_ABORT_PIPE

33013    88.572079    host    3.1.3    USB    27    URB_BULK in

33014    88.572140    host    3.1.3    USB    27    URB_BULK in

33028    88.575098    host    3.1.3    USB    27    URB_BULK in

[..]

33029    90.075203    host    3.1.3    USB    27    URB_FUNCTION_ABORT_PIPE

strange thing is that when the commit buffer failure is detected USB is NAKed and flushed and everything else is restarted, DMA, GPIF statemachine, sockets ecc..

Nevertheless i can see that DMA buffer are produced but never consumed and after 8 buffers are produced the commit fails again at 9th.

Thank you for your support.

0 Likes
YashwantK_46
Moderator
Moderator

Hello NiCo_4789341,

"When the stream stops the UART message is: CommitBuffer Failure: 47"

=> Please refer to the following KBA: Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

As mentioned in the KBA, the host application doesn't issue IN token fast enough, this causes the frames to go out of sync and raises the error code: 47.

When the CyU3PDmaMultiChannelCommitBuffer() API fails, there is a CX3_DMA_RESET_EVENT set which makes the device to stop and reset and restart the streaming (error recovery process).

"strange thing is that when the commit buffer failure is detected USB is NAKed and flushed and everything else is restarted, DMA, GPIF statemachine, sockets ecc.."

=> This is the expected behavior to come out of the commitbuffer failure and then to restart the DMA channels.

Also, instead of using the code from FX3 / CX3 Firmware for Streaming RAW Image Data using Cypress Driver , please use the code posted in cx3 raw streamer is not work.  and modify the firmware according to your application.

"Nevertheless i can see that DMA buffer are produced but never consumed and after 8 buffers are produced the commit fails again at 9th."

=> I understand that this is the issue that occurs after recovering from a CommitBuffer Failure: 47. Please correct me if I am wrong.

Can you let me know if the host app still issues IN token while CX3 is recovering from the error or is the host application stopped.

Please try stop the firmware and restarting it by sending vendor commands and see if the device works fine.

Regards,

Yashwant

0 Likes
NiCo_4789341
New Contributor II

Hi Yashwant,

yes, I've already considered KBA218830.

I know that in case of belated readings by the HOST, the output buffer gets full and CyU3PDmaMultiChannelCommitBuffer() triggers a CX3_DMA_RESET_EVENT.

In those cases I can see a CyCx3UvcApplnStop + CyCx3UvcApplnStart sequence.

As I said, this sequence stalls the endpoint cleans everything and restarts.

NOTE: The very same sequence works well in the same case (error 47) when in UVC mode!


"I understand that this is the issue that occurs after recovering from a CommitBuffer Failure: 47. Please correct me if I am wrong."

Your understanding is correct! But again, in UVC mode the device can successfully recover from error 47.

Maybe the UVC host sofware "keeps the pipe up" in some way, while the Streamer utility "drops the pipe"?

"Can you let me know if the host app still issues IN token while CX3 is recovering from the error or is the host application stopped."

From the WireShark logs I guess so.. aren't those URB_BULK in, IN tokens from the HOST?

I'm using the streamer application bundeld with the EZ-USB SDK, by the way.

"Please try stop the firmware and restarting it by sending vendor commands and see if the device works fine."

It doesn't work.

After restarting no consumer events are detected.

Regards.

0 Likes
YashwantK_46
Moderator
Moderator

Hello NiCo_4789341,

Can you please attach the complete Wireshark to the next interaction so that I can review them?
Click on the Use advanced editor option (top right corner) and click on Attach (bottom right corner) while posting the next response.

Also, can you let me know if you are using SDK 1.3.3 or 1.3.4 while building the project?

You can check this by selecting the project -> Alt+Enter. In the pop-up window, navigate to C/C++ Build > Build Variable and share a snapshot of the window.

"After restarting no consumer events are detected."

=> This means that the host application is not issuing IN token or consuming the buffers in CX3.

Regards,

Yashwant

0 Likes
NiCo_4789341
New Contributor II
  1. here is a complete wireshark capture. The input bulk readings are truncated to 32 bytes in order to limit the file size.
  2. I'm using SDL 1.3.4, for sure.
  3. "After restarting no consumer events are detected."
    => This means that the host application is not issuing IN token or consuming the buffers in CX3.
    This is my question: why is this happening?
0 Likes
YashwantK_46
Moderator
Moderator

Hello,

"packets sequence is  6x 524315 bytes + 1x 334299 bytes"

=> In the traces shared, i see 53 x 65563 + 1 x 6619  (including Wireshark header of 152 bytes) which is 3473250 (less than 3480189 this is the size according to the sequence you shared).


As a test to understand better, please perform the following steps:

1.) Start Streamer application and send vendor command to start streaming to CX3.

2.) While there is streaming happening, send vendor command to CX3 to stop the streaming and also, stop the Streamer application.

3.) Again, start the streamer and send vendor command to start streaming.

You should see the Streamer application with successes and ensure data streaming.

4.) Perform the above test 4-5 times and verify that the stream is working properly or not and share the status with me.

Regards,

Yashwant

0 Likes
NiCo_4789341
New Contributor II

"packets sequence is  6x 524315 bytes + 1x 334299 bytes"

=> In the traces shared, i see 53 x 65563 + 1 x 6619  (including Wireshark header of 152 bytes) which is 3473250 (less than 3480189 this is the size according to the sequence you shared).

Forgive me, the pcap file I shared comes from a newer acquisition I made on purpose.

In this particular case I was trying to force the streamer to issue IN tokens as fast as possible, using "Packets per Xfer = 4" and "Xfers to Queue = 1", if I'm not wrong.

Capturing packets with the device configured as UVC i noticed that transfers are more frequent and of the exact size of the DMA buffer (CX3_UVC_DATA_BUF_SIZE + CX3_UVC_PROD_HEADER = 36828, in my case). This made me think that the Microsoft UVC driver can issue IN tokens faster than the cyAPI. That's why I was trying to make shorter and faster transfers.

Give me a couple of days to setup the test you asked for.

Thanks in the meantime.

0 Likes
NiCo_4789341
New Contributor II

Hi Yashwant,

forgive me for my belated reply.

There are no problems related to start/stop of the stream and device reset.

I went through an in-depth analysis of the differences in UVC and non-UVC firmware and how they interact with system drivers.

I can say that the reference UVC firmware when switched to non-UVC mode (or RAW mode, if you prefer) needs a couple of non-obvious patches for proper operation.

Now my stream is stable, I almost never detect the error code 47 and in the very rare case the stream restarts immediately (obviously losing a frame).

Regards,

Nicola.

View solution in original post

0 Likes
YashwantK_46
Moderator
Moderator

Hi Nicola,

"I can say that the reference UVC firmware when switched to non-UVC mode (or RAW mode, if you prefer) needs a couple of non-obvious patches for proper operation."

=> Can you please share what are the modifications (patches) that you added to the firmware?

This could help in resolving similar issues for other customers.

Regards,

Yashwant

0 Likes