- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Tags:
- cx3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
likewise, where is the place I should add RegisterEpEvtCallback? at what spot in the code would it be appropriate?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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. 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
Ascella kit: https://www.cypress.com/documentation/development-kitsboards/ascella-cypress-cx3-thine-isp-13mp-refe...
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am seeing 113 produce events per frame, exactly. good call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi