CX3: moved to 1_3_4 sdk, bulk endpoint stopped working

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

cross mob
EtWh_2921621
Level 3
Level 3
First like received

we moved from 1_3_3 to  1_3_4,and the bulk endpoint stopped working. At least, how we are calling it. On the PC side, we call CreateFileW() on the device's path, then we call WinUsb_Initialize( ) on the file handle, then use WinUsb() functions to get the pipes, then use WinUsb_ReadPipe and WinUsb_WritePipe to read and write to the CX3. This used to work, now does not. The CX3, from the debug UART, doesn't even see the DMA callback.

Can't use the CCyUsbDevice() stuff (I guess) because when the firmware is loaded onto the CX3, it switches to being a video capture device, and CCyUsbDevice doesn't seem to enumerate or talk to those types of devices!

Not sure how to debug this issue or work around it. Suggestions? Anybody else see this? I can post the descriptors and the endpoint creation logic, if necessary.

0 Likes
1 Solution

Hello,

Thank you for the update.

- As I mentioned in my earlier posts, we do not recommend using blocking calls inside the DMA callback. As the custom API waits for the mutex lock and the DMA callback is called very frequently. This might cause the device to hang.

No allocating memory in the DMA callbacks. We had a need for the PC to send us rather large incoming buffers. At least 4K in side. We didn't know how to do that, so we broke up the buffer on the PC send side into multiple little buffers, and send them sequentially. This required us to allocate a 4K chunk of memory in the DMA callback upon the receipt of the first in a number of sequential buffers. I removed this allocation.

>> We don't recommend too much processing in the DMA callbacks. You can set events in the DMA callback and do the processing later in the thread entry function.

With those two changes, I am not seeing the hang, which I think is very odd.

>> So with the changes mentioned you are able to stream the video without any commit buffer failures. Please confirm

Interesting... about the DeviceReset(). Where should I put this call? When I get the SC_CLEAR_FEATURE?

>> That was just for debugging purposes. If you call CyU3PDeviceReset inside the clear feature handler, the device will reset when the clear feature is received from the host. As you were seeing some problems in debug prints, I asked for this debug.  If you don't see any problem in streaming the video the above call is not required.

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
18 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

- Please let me know if the firmware implementation is the same as mentioned in response 8 of this thread https://community.cypress.com/message/251589?et=watches.email.thread#251589 

- Let me know if the device enumerates well (with the additional endpoints) after changing the SDK version to 1.3.4

- Please explain the flow of the firmware. When is the DMA channel corresponding to the above-mentioned USB pipe created?

-  Please try adding this API in the firmware to CyU3PUsbRegisterEpEvtCallback to receive the endpoint event callback. This will help in debugging the problem.

-  From the response in the above-mentioned thread, I see that only one BULK Endpoint is configured and the DMA channels are two: one IN and one OUT. Please share the complete firmware implementation for us to check.

- Please share the UART debug prints

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

Hi. I am really in a critical time crunch. I am going to send this right away. Can I send you a zip? I’m not sure if I am allowed to publicly post the entire firmware. My email is efrazer@micro soft.com, minus the space... I will be working on this all night.

0 Likes

Hello,

I was able to reproduce the problem you were facing.

Please try calling WinUSBDMAInitialize() after the USB event CY_U3P_USB_EVENT_SETCONF. After these modifications, I was able to send 4096 bytes to the firmware through BULK OUT (0x06) after building the firmware with SDK 1.3.4.

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

Wow! Thanks! (?)

First of all - how do I do that?

Secondly - why does this work, and is this sequence of steps shown in one of the examples? Were we missing something important and forgot it?

0 Likes
EtWh_2921621
Level 3
Level 3
First like received

likewise, where is the place I should add RegisterEpEvtCallback? at what spot in the code would it be appropriate?

0 Likes
EtWh_2921621
Level 3
Level 3
First like received

I'm guessing I call RegisterEpEvtCallback after calling DmaChannelCreate and SetXfer. One thing that is puzzling me in the code I inherited is seemingly-random sleeps between calls to 'let things settle'. Glad those wait calls aren't in this particular piece of code. I don't know which events to look for to help debug the problem. All events? Ok, I will try that.

... Yep, that seems to have fixed it!!! I am comparing this solution to others out there in the firmware examples directory. I NEVER would have guessed to do it this way. Thanks! By the way, how did you even guess to put the DmaInitialize( ) call after the SETCONF? It really bothers me these random sleeps to 'make the timing work'. As an engineer who likes to write clean code, it is against my morals to put in random sleep waits. 🙂

It's been running for a while already. Much longer than it normally runs w/o hanging.

**** MSRVideoAR_PersistentSettingsRead ****

  I2C access - dev: 0xa4, address: 0x0, size: 79, pages: 0x1.

Persistent Settings Read, red gain = 1325

Sensor Initialization

Writing Configuration Settings:

**** CyCx3UvcAppInit BEGIN Setting USB Descriptors ****

**** CyCx3UvcAppInit END Setting USB Descriptors ****

**** CyCx3UvcAppInit CONNECTING TO USB ****

**** CyCx3UvcAppInit CONNECTION TO USB COMPLETE ****

CyCx3UvcAppUSBSetupCB CY_U3P_USB_VENDOR_RQT = 26

CyCx3UvcAppUSBSetupCB Microsoft OS Descriptor Set REQ

**** WinUSBDMAInitialize EXIT ****

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

StpCB:In SET_FTR Configured=1

#### OnWinUSBDMACompletionCallback RECV ####

Processing command 30

CX3_USB_GETINFO_EVENT

#### OnWinUSBDMACompletionCallback RECV ####

Processing command 100

CX3_UVC_VS_COMMIT_CONTROL

CyCx3UvcAppImageSensorSetVideoResolution 7

USBStpCB:Xres = 0x0

USBStpCB:XSHUTDOWN = 0x0

CyCx3_ImageSensor_Set_1920x1440x8bitx90FPSResolution

Writing Configuration Settings:

**** Read in VTS=1499, HTS=889

**** sending persistent settings to the sensor: gain, exposure, etc ***

        Set 10 to 888

HandleSetAValue32, command = 12, value = 19694

**OV4689_SetExposure 19694**

        Set 24 to 1325

        Set 26 to 1024

        Set 28 to 1626

****CyCx3UvcAppStop, already stopped, returning

UvcAppHandleSetCurReq, wValue = VS_COMMIT_CONTROL, stopping and starting UvcApp

****CyCx3UvcAppStart ENTRY****

****CyCx3UvcAppStart EXIT, sys clk freq = 403200000****

#### OnWinUSBDMACompletionCallback RECV ####

Get VTS = 1499, HTS=889

Processing command 31

#### OnWinUSBDMACompletionCallback RECV ####

Processing command 30

CX3_USB_GETINFO_EVENT

#### OnWinUSBDMACompletionCallback RECV ####

Processing command 100

Tick - fps = 91, frames=1556, consumed=1556, dma buffers out = 1, frmErr=0, crc=0, mdlErr=0, ctlErr=1, eid=0, recr=0, unrecr=0, recSyncErr=0, unrecSyncErr =0, inWhileLoopTooLong = 0, gGotErr0x47 = 0

0 Likes
EtWh_2921621
Level 3
Level 3
First like received

well, I thought moving to 1_3_4 was going to be the solution, but unfortunately, it's not. It still randomly locks up after 5-10 minutes of running. trouble is, I don't know enough about windows usb to understand why it locks up, or how to debug it. It locks up after 5 minutes, so it's near impossible to debug with a USB hardware debugger. I'm fairly certain it's a bug between the CX3 and the Windows machine. I've turned off ALL the low power management code in our firmware. Is that okay? Or will windows "get upset" and eventually trash the pipeline because of it? I'm not quite sure how to debug what's going on - I can't add uart messages to the cameras (there are 2 of them), they're embedded into the headset. Only thing I could do is add custom debug messages back and forth between the PC and the firmware, over that USB channel you fixed...

I can't be the only person trying to send out 1920x1440x90Hz with 2 channels over USB, right? There are other people testing high-bandwidth USB 3.0 video capture, right?

I'm wondering if I should go back to the example firmware and start over from scratch...

0 Likes
EtWh_2921621
Level 3
Level 3
First like received

i don't know anything about this GPIF statemachine waveform thing... I see it in our file cycx3gpifwaveform.h... for the CX3, isn't the waveform to capture incoming video pretty much the same for any sensor? If it captures at all, doesn't that mean the state machine is pretty much good? Should I be able to steal the one from the 75779 and that should work?

0 Likes

Hello,

You can refer to the firmware in SDK 1.3.4 where the FX3 will enumerate as vendor device. In this firmware, the DMA channels are created after the CY_U3P_USB_EVENT_SETCONF event. Please refer to bulksrcsink firmware if the SDK.

likewise, where is the place I should add RegisterEpEvtCallback? at what spot in the code would it be appropriate?

>> Please refer to bulksrcsink example of the SDK which implements CyU3PUsbRegisterEpEvtCallback API

It still randomly locks up after 5-10 minutes of running. trouble is, I don't know enough about windows USB to understand why it locks up, or how to debug it.

>> Please let me know what exactly happens when you start streaming after opening the host application. Are you getting the debug prints? If yes, please share the debug prints

I can't be the only person trying to send out 1920x1440x90Hz with 2 channels over USB, right? There are other people testing high-bandwidth USB 3.0 video capture, right? I'm wondering if I should go back to the example firmware and start over from scratch...

>> From two channels you mean the 1) streaming channel 2) the channel for vendor interface. Please try disabling the second channel / or the vendor interface and enable only the streaming channel (UVC interface) and let me know if the streaming is proper.

i don't know anything about this GPIF statemachine waveform thing... I see it in our file cycx3gpifwaveform.h... for the CX3, isn't the waveform to capture incoming video pretty much the same for any sensor? If it captures at all, doesn't that mean the state machine is pretty much good? Should I be able to steal the one from the 75779 and that should work?

>> CX3 has a Fixed function GPIF state machine. We do not recommend changing this state machine. To check the if the video data is coming proper to CX3 you can probe the test points as mentioned in Q10 of this KBA. CX3 Hardware: Frequently Asked Questions - KBA91295

Also, please check the number of producer events for one frame. This will help in debugging the problem. Please try doing these tests after disabling the vendor interface (second DMA channel)

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

No I mean I have two separate USB 3.0 hosts, and I'm running 1920 x 1080 x 90fps x RAW8 over each one. I reduced the frame rate to 45FPS and it's been running for over 2 hours w/o hanging, whereas when I run it at 90 FPS it hangs within 5 minutes.

I'm not worried that the frames aren't coming in right from the OV sensor. I'm *sure* the problem is a DMA issue between the PC and the CX3.

If the CX3 has a fixed GPIF statemachine, why is it defined in this firmware source code I inherited, and why is it in the 75779 example? Either way, if it's true, and there ISN'T a waveform I need to set on the CX3, all the better. Then I don't need to fool around with the GPIF designer tool & stuff. Less to learn.

How in the world would I be able to know the # of producer events for one frame? you mean for just one frame, or an average of producer events over N frames delivered? Any particular type of producer event? 🙂 I don't even know what a producer event is or how many types there are, or what the #'s should be. How many producer events SHOULD there be per frame?

I'm getting the idea 1920 x 1440 x 90 FPS x 2 channels (left and right) is simply too much for the USB 3.0 bus on the PC to handle utterly consistently. I personally think the PC doesn't emit enough read tokens to the CX3 and after a bit, it simply gives up and silently kills the stream.

I'd love it if somebody at Cypress (or elsewhere) got a sensor chip set up at 1920 x 1440 x 90 FPS (or equiv) and demonstrated to themselves that they could blast 1 or better yet 2 of those streams to a PC and have it never hang. Do you at Cypress have dev boards with sensor chips on them that are programmable to different resolutions? That can go as high as 1920 x 1440 x 90 FPS? I'd love to see somebody else accomplish that w/ firmware. Then I'd love to have a good look at that firmware. I'd even see if i could get my boss to put a 'bounty' on that goal. 🙂

0 Likes

Hello,

No I mean I have two separate USB 3.0 hosts, and I'm running 1920 x 1080 x 90fps x RAW8 over each one.

>> In the firmware you shared I could see just a single DMA channel i.e. from 2 PIB sockets to UIB/USB socket. How are you sending data to two hosts from a single endpoint? Please share a block diagram of your hardware setup so that we can debug the problem

It seems that the problem is due to the video bandwidth on USB 3.0. Please let me know if you get the commit buffer failures when the video is being streamed at 90 fps? Can you share the UART debug prints for this case?

>> Instead of streaming it on two hosts please try streaming the video at 90 fps with one channel and let me know the results

How in the world would I be able to know the # of producer events for one frame? you mean for just one frame, or an average of producer events over N frames delivered? Any particular type of producer event? 🙂 I don't even know what a producer event is or how many types there are, or what the #'s should be. How many producer events SHOULD there be per frame?

>> The frame ends with a partial buffer. So as soon as a partial buffer is committed in the DMA callback 1 frame can be counted.

CY_U3P_DMA_CB_PROD_EVENT event occurs when the DMA buffer is completely filled with the video data. To check if the video data from the MIPI receiver is proper we can check the DMA buffers filled

For example Frame size: 1920 *1440* 1(RAW8) byte = 2764800bytes and the DMA buffer size is 24 KB(0x6000) then for 1 frame 112 full buffers and 1 partial buffer will be needed.

The CY_U3P_DMA_CB_PROD_EVENT can be tracked using a variable and get the prints in for{} loop. The variable needs to be reset when one frame is completed. In this way, we can confirm if the data on CX3 is coming properly.

For some reference designs, you can refer to

Denebola kit : https://www.cypress.com/documentation/development-kitsboards/denebola-usb-30-uvc-reference-design-ki...

Tania Kit: https://www.cypress.com/documentation/development-kitsboards/tania-cypress-cx3-socionext-isp-referen...

Ascella kit: https://www.cypress.com/documentation/development-kitsboards/ascella-cypress-cx3-thine-isp-13mp-refe...

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

I've reduced the frame rate down to 45FPS instead of 90FPS and the 0x47 errors have almost completely went away. Sort of signalling it's a PC issue, not the CX3. Unless for whatever reason, the timing I put into the OV sensor was "more right" than the timing for the 90HZ. But that's sort of unreasonable to think that. I ran into a weird thing today where I DID get a single 0x47 error and it stopped and tried to reset the DMA, but it was that glStopStreaming was set, when there was no way it should have been set, and it just stopped and didn't restart. That implies to me that glStopStreaming got corrupted. I'm debugging it again, printing out the value of glStopStreaming (if it's not 1, I know something bad happened).

Is there a way to check overall memory usage, or to run a quick heap check on the CX3?

0 Likes
EtWh_2921621
Level 3
Level 3
First like received

I am seeing 113 produce events per frame, exactly. good call.

0 Likes

Hello,

In the firmware you shared I could see just a single DMA channel i.e. from 2 PIB sockets to UIB/USB socket. How are you sending data to two hosts from a single endpoint? Please share a block diagram of your hardware setup so that we can debug the problem

>> Please let me know this. This will help us to debug the issue faster.

To reduce the rate at which the data is streaming you can try to increase the Horizontal blanking period. Please increase the Horizontal blanking time as much as you can.  For this, you need to modify the sensor settings as well as the CX3 MIPI receiver settings. Please let me know if this helps.

glStopStreaming seems to be a global variable that is stored in the data region of the CX3 memory map.The data and bss region used by the application can be found from the .map file which will be found in the debug drop down which is available under the project in project explorer in the EZ USB suite.

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

No, I have two separate systems, a L and a R camera. They're attached to a 4-port USB 3.0, which has one host per port.

🙂

by reducing the frame rate to 45 FPS, I AM reducing the data rate. It still hangs. I'm trying to find out how in the world StopStreaming gets set when I know I didn't stop the stream. in the place where StopStreaming is normally set, I put in a CyU3DebugPrint(), but it's not showing up on the UART. I can't imagine the UART would just ignore this print call, and I don't see it on the output debug, so I'm wondering what the heck is going on. if that section of code IS getting called (since I didn't call it), then something on the PC is telling the stream to stop.

This code!

CyBool_t CyCx3UvcAppUSBSetupCB(uint32_t setupdat0, uint32_t setupdat1)

{

CyU3PReturnStatus_t status = CY_U3P_SUCCESS;

uint8_t   bRequest, bType, bRType, bTarget;

uint16_t  wValue, wIndex;

uint8_t   ep0Buf[2];

CyBool_t  isHandled = CyFalse;

uint8_t   *ctrl_src = 0;

uint16_t wLength;

/* Decode the fields from the setup request. */

bRType = (setupdat0 & CY_U3P_USB_REQUEST_TYPE_MASK);

bType = (bRType & CY_U3P_USB_TYPE_MASK);

bTarget = (bRType & CY_U3P_USB_TARGET_MASK);

bRequest = ((setupdat0 & CY_U3P_USB_REQUEST_MASK) >> CY_U3P_USB_REQUEST_POS);

wValue = ((setupdat0 & CY_U3P_USB_VALUE_MASK) >> CY_U3P_USB_VALUE_POS);

wIndex = ((setupdat1 & CY_U3P_USB_INDEX_MASK) >> CY_U3P_USB_INDEX_POS);

wLength = ((setupdat1 & CY_U3P_USB_LENGTH_MASK) >> CY_U3P_USB_LENGTH_POS);

#ifdef CX3_DEBUG_ENABLED

QueueDiagnosticsMessageP(4, "bRType = 0x%x, bRequest = 0x%x, wValue = 0x%x, wIndex = 0x%x, wLength= 0x%x\r\n", bRType, bRequest, wValue, wIndex, wLength);

#endif

/* ClearFeature(Endpoint_Halt) received on the Streaming Endpoint. Stop Streaming */

if (

        (bTarget == CY_U3P_USB_TARGET_ENDPT) &&

        (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE) &&

        (wIndex == CX3_EP_BULK_VIDEO) &&

        (wValue == CY_U3P_USBX_FS_EP_HALT))

{

     // I added this code here...

     gStopStreamingCounter = rand( ) % 100 + 1;

     glIsClearFeature = CyTrue;

     CyU3PDebugPrint( 0, "    *** Halt, counter = %d.\r\n", gStopStreamingCounter );

     CyU3PThreadSleep( 50 );

        CyCx3UvcAppStop();

        return CyFalse;

}

0 Likes

Hello,

No, I have two separate systems, a L and a R camera. They're attached to a 4-port USB 3.0, which has one host per port.

>> Do you mean that you are using two CX3 devices for connecting aL and a R camera. If yes, how are they connected to the host? Is it via a USB 3.0 hub? Can you share the block diagram of the same?

by reducing the frame rate to 45 FPS, I AM reducing the data rate. It still hangs

>> In your previous response you mentioned that at 45 fps it works for 2 hours without freezing. Does it start showing commit buffer failures after 2 hours of streaming at 45 fps? Please try increasing the DMA buffer size (#define CX3_UVC_DATA_BUF_SIZE                   (0x8FD0) ) for streaming the video at 45 FPS and let me know if there is some improvement.

in the place where StopStreaming is normally set, I put in a CyU3DebugPrint(), but it's not showing up on the UART.

>> Can you check this using a global variable and later check the variable outside the callback. You can also call CyU3PDeviceReset(CyFalse); this will reset the device when the host sends CY_U3P_USB_SC_CLEAR_FEATURE. This can also help to check if the control enters this condition

Please probe USB lines using the Software Analyzer like Wireshark and share the traces

Regards,

Rashi

Regards,
Rashi
0 Likes
EtWh_2921621
Level 3
Level 3
First like received

I ran across some changes that seem to have made the hang MUCH less frequent:

* No queuing messages to be debug printed in the DMA callbacks. The queue of a message operation (QueueDebugMessage, our function), would allocate memory for the string to be printed, then print it out later in the AppThread. to put the message on the queue, it would need to lock a mutex. I figured allocating memory and waiting in a mutex were dangerous, so I removed them.

* No allocating memory in the DMA callbacks. We had a need for the PC to send us rather large incoming buffers. At least 4K in side. We didn't know how to do that, so we broke up the buffer on the PC send side into multiple little buffers, and send them sequentially. This required us to allocate a 4K chunk of memory in the DMA callback upon the receipt of the first in a number of sequential buffers. I removed this allocation.

With those two changes, I am not seeing the hang, which I think is very odd.

Interesting... about the DeviceReset(). Where should I put this call? When I get the SC_CLEAR_FEATURE?

0 Likes

Hello,

Thank you for the update.

- As I mentioned in my earlier posts, we do not recommend using blocking calls inside the DMA callback. As the custom API waits for the mutex lock and the DMA callback is called very frequently. This might cause the device to hang.

No allocating memory in the DMA callbacks. We had a need for the PC to send us rather large incoming buffers. At least 4K in side. We didn't know how to do that, so we broke up the buffer on the PC send side into multiple little buffers, and send them sequentially. This required us to allocate a 4K chunk of memory in the DMA callback upon the receipt of the first in a number of sequential buffers. I removed this allocation.

>> We don't recommend too much processing in the DMA callbacks. You can set events in the DMA callback and do the processing later in the thread entry function.

With those two changes, I am not seeing the hang, which I think is very odd.

>> So with the changes mentioned you are able to stream the video without any commit buffer failures. Please confirm

Interesting... about the DeviceReset(). Where should I put this call? When I get the SC_CLEAR_FEATURE?

>> That was just for debugging purposes. If you call CyU3PDeviceReset inside the clear feature handler, the device will reset when the clear feature is received from the host. As you were seeing some problems in debug prints, I asked for this debug.  If you don't see any problem in streaming the video the above call is not required.

Regards,

Rashi

Regards,
Rashi
0 Likes