Hey all,

I have been working with the imager sensor project (AN75779) and am close to getting it working.  I am using an Aptina MT9P031 imager which I have been able to communicate with and setup properly.  I am using AMCap to (hopefully) read in the image.

The FX3 will enumerate as a UVC device and AMCap will recognize it.  However, no image shows up.  All of the appropriate pins on the imager are active: external clock, pixel clock, frame valid, line valid, etc.  I have checked them with a scope and they are working properly.  The issue seems to be with the GPIF state machine and/or the GPIF/DMA callbacks.

In UVCAppThread_Entry, I get the current SM state and print it over UART.  The firmware runs through the SM for a while and appears to be working.  It will enter the GPIF callback once or twice and does not report any errors.  But eventually it will get stuck in either state 9 or 10, PARTIAL_BUF_IN_SCK0 or PARTIAL_BUF_IN_SCK1, respectively.  Both state 9 and 10 have the INTR_CPU action (per the AN) and are set to repeat this action until he next transition.  It does appear that a few bulk transfers occur before the state machine freezes, so it's possible the rest of the program is working correctly.

Any ideas on why the state machine is getting stuck?

Any help would be greatly appreciated.

Thanks,

Aaron

 Hi Aaron,

Meanwhile, I would recommend you to create a tech support case. Most probably the author of that application note will be helping you there.

Regards,

sai krishna.

Will do.  I will post my findings here since I am sure many other people will have issue with this project.

Is there any progress on this problem as I believe it may be related to my problem posted in http://www.cypress.com/?app=forum&id=167&rID=66200

The image sensor project also uses the CyU3PGpifSMSwitch() function.

I created a support case, but have not received any help yet.  I read your thread and I also believe they are related.

SDK 1.1.1 made no difference.

When you are using 0xFFFF instead of 257 for parameter "fromState" does your firmware also run for a longer time (e.g. around 20'000-50'000 successful transfers)?

I tried that after reading your thread, but it didn't have any effect.  My state machine freezes very quickly.

The following I found in the FX3 release notes:

The CyU3PGpifSMSwitch API may not be able to trigger a desired state machine switch if
the state machine in use makes use of mirror states. This is because the state machine
may actually be stuck in a mirror of the user specified start state instead of in the start state
itself. In this release, the API has been updated to trigger an immediate switch if the state
machine is in the specified start state or one of its mirrors. This will not be sufficient if the
state machine reaches a mirror of the start state only after the Switch API has been called.
If the CyU3PGpifSMSwitch API needs to be used in systems which make use of state
machines with mirror states, it is recommended that the application specify a timeout value
in the CyU3PGpifSMSwitch() API call and retry the switch operation periodically until it
succeeds.

I believe this causes the problem. However, the proposed solution does not sound very encouraging to me.

-Silvio

Now I just see that changes from SDK version 1.1 are:

"Fixed a defect in the CyU3PGpifSMSwitch() API which would cause state machine
switches to fail if the GPIF designs use mirror states."

Now I am confused: Is this problem now fixed with SDK 1.1.1 or an open issue?

Actually, we have seen a defect with the CyU3PGpifSMSwitch() API in previos SDK versions. We were seeing that bug when there is a chance for mirror states. That has been fixed in the latest SDK1.1.1.

That is the reason why I was asking you guys to test with the latest SDK.

Regards,

sai krishna.

New SDK made no difference for me.

Hi Aaron,

I can see that you have created a tech support case and also you mentioned that there was no reply.

Is that the case still?. Please let me know who is handling your case.

I am sure that one of our engineer is trying to replicate your issue to find a solution.

Thanks,

sai krishna.

I have received a reply since my post here.  I believe Karnik is the one handling my case.  I sent my source code yesterday and have not heard anything since.

Thanks, Sai.

Aaron

After installing SDK 1.1.1 it seems that the Gpif switching business is working. However, that data transfer still stops after short time. The UsbdStatus function says that the state is STALLED witch status UNKNOWN. Any ideas on that one?

LastError results in 170 (The requested resource is in use)

Hi Sil,

What exactly is your application. Could you give few more details on that.

What is the behaviour that you are seeing?.

Is firmware getting stuck somewhere?.

Do you have any provision to check the traffic on the USB bus?.

Thanks,

sai krishna.

We use these images to read in a near infared image.  We currently use these imagers with the FX2 without issue.

As I said before, the state machine runs for a little while, but eventually it will get stuck in either state 9 or 10, PARTIAL_BUF_IN_SCK0 or PARTIAL_BUF_IN_SCK1, respectively.

While the state machine is running (only a few seconds), there are a few bulk transfers.  I have checked this using a software USB analyzer.  I do have access to a CATC if it comes to that.

My application is basically also the image sensor project AN75779. The problems with state machine switches seem to be know gone when using SDK 1.1.1, but there are plenty of other issues with this project.

On the USB bus the error USBD_STATUS_XACT_ERROR is reported when using the NEC/Renesas host controller when the transfer is running for a couple of minutes. If I am using an ASmedia host controller, then it reports USBD_STATUS_DATA_OVERRUN immediately. Regarding the ASmedia host controller I have to say that instead of receiving the expected 16380 Bytes for a full DMA buffer (+4 Bytes padding), the function XferData constantly returns only 6544 Bytes. God knows why.

I also found that this project is only running when calling CyU3PDmaMultiChannelReset() after a partial buffer is comitted (this is the actuall implementation of AN75779). Otherwise the DMA transfer gets stuck somehow. What is the reason for this? For my understanding there should be no need to reset the DMA channels after a partial buffer is comitted. Also I found that when a partial buffer is comitted out of the GPIF state machine (state action COMMIT), two buffers are actually produced, one with length 0 and another one that holds the expected data. Moreover, I found that when a producer commits a buffer, I actually get up to 10 consumer events triggering the DMA callback. This also doesn't make any sense and can cause the variable dmaDone in the image sensor project to underflow.

At last, I am wondering if this project can ever run with USB 2.0. My understanding is that with USB 2.0 the maximum packet size is 512 Bytes as a difference to USB 3.0 where we can send burst packets up to 16 kB. With USB 2.0 I find that the DMA call back takes too much CPU time, so that it is not possible to handle even 10 MB/s upstream data rate.

Concluding, I think AN75779 is not well thought through and found that I cannot use it in my application since I need to support also USB 2.0. Also it works only partially with a Nec/renesas host controller while with ASmedia it does not work at all.

-Silvio

Cypress support has been no help with this project.  I sent my source to them almost two weeks ago and have received no response.  Very disappointing.

I think you are right, Sil, this project was not well thought out.

 Hi Sil & Aaron,

I am using the FX3 Image sensor project as reference and using different image sensor, but when I load the code, my device is detected on the device manager as a imaging device but no frames captured. So I try to debug that, but is there any console/rs232 debug print statements that we can use? Now I am not sure of whether the frame is captured or not, how to debug on that? kindly provide some inputs.

Hi Sil, catacon and anyone else interested or that can help,

I am also working on a project based on this app note. In the past week or so I have had some succes. I can run test patterns from an FPGA on my board and am able to get 320 X 240, 640 X 480 and 960 X1280 working. My imager is 3364 X 2537 and I can not get that to work or a test pattern of that size. I'm not sure if my problem is device descriptors or throughput. I am using SDK 1.2 now and I am not able to setup the multi channel DMA to be larger than 12K. I set the size to 1024 and the count to 12 and that works but any larger like 1024 and 16 and I get a memory error when I attempt to allocate the multi channel DMA. It sounds like you guys are maybe able to allocate 16K? If so how are you doing that? Did you change some of the fx3.ld file settings or the cyfxtx.c file? Any help you can provide?

Thanks,

Garyio

Hi Garyio

What is the burst lenght you are using? If it is 16, then 1024*(BURST_LEN)*(DMA_BUF_COUNT) = 1024*16*16 = 256 kByte which is too much. However, AN75779 uses multi to one DMA transfers which means that you need twice the memory, which does not fit with above calculation.

-Sil

Hi Sil,

Ok a bit of confusion on my part. For the Multi Channel DMA setup the size to CY_FX_UVC_STREAM_BUF_SIZE. This is the endpoint size times the endpoint burst length. For the endpoint size I am setting that to 1024 but the burst length I can only set to 12 not 16. If I set it larger then 12 I get a memory error when the DMA is allocated. Can you set the burst length to 16?

So how does this work. Does the call to CyU3PSetEpConfig allocate 12 1024 byte buffers for the endpoint and the call to CyU3PDmaMultiChannelCreate allocates 8 12K buffers? That would be a total of 108K?

Any Cypress people have any help here?

Here's what I have now:

/* UVC Video Streaming Endpoint Packet Size */
#define CY_FX_EP_BULK_VIDEO_PKT_SIZE            0x400          // 1024 Bytes

/* UVC Video Streaming Endpoint Packet Count */
#define CY_FX_EP_BULK_VIDEO_PKTS_COUNT          12

// UVC Buffer size - Will map to BULK Transaction size
#define CY_FX_UVC_STREAM_BUF_SIZE                  (CY_FX_EP_BULK_VIDEO_PKTS_COUNT * CY_FX_EP_BULK_VIDEO_PKT_SIZE)  
 

#define CY_FX_USB_DMA_BUF_COUNT                  8            

    // Consumer Endpoint 2 configuration
    endPointConfig.enable = 1;
    endPointConfig.epType = CY_U3P_USB_EP_BULK;
    endPointConfig.pcktSize = CY_FX_EP_BULK_VIDEO_PKT_SIZE;
    endPointConfig.isoPkts = 1;
    endPointConfig.burstLen = CY_FX_EP_BULK_VIDEO_PKTS_COUNT;
    endPointConfig.streams = 0;

    // Configure the Endpoint
    apiRetStatus = CyU3PSetEpConfig(CY_FX_EP_BULK_VIDEO, &endPointConfig);
    if (apiRetStatus != CY_U3P_SUCCESS)
        CyFxAppErrorHandler(apiRetStatus);
 

    // Create a DMA Manual OUT channel between CPU and USB consumer socket
    dmaMultiConfig.size = CY_FX_UVC_STREAM_BUF_SIZE;
    dmaMultiConfig.count = CY_FX_USB_DMA_BUF_COUNT;
    dmaMultiConfig.validSckCount = 2;
    dmaMultiConfig.prodSckId [0] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_0;
    dmaMultiConfig.prodSckId [1] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_1;
    dmaMultiConfig.consSckId [0] = (CyU3PDmaSocketId_t)(CY_U3P_UIB_SOCKET_CONS_0 | CY_FX_EP_VIDEO_CONS_SOCKET);
    dmaMultiConfig.prodAvailCount = 0;
    dmaMultiConfig.prodHeader = 12;
    dmaMultiConfig.prodFooter = 4;
    dmaMultiConfig.consHeader = 0;
    dmaMultiConfig.dmaMode = CY_U3P_DMA_MODE_BYTE;
    dmaMultiConfig.notification =  CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT;
    dmaMultiConfig.cb = CyFxDMACallback;

    // Create the channel
    apiRetStatus = CyU3PDmaMultiChannelCreate (&glChHandleUVCStream, CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE , &dmaMultiConfig);
    if (apiRetStatus != CY_U3P_SUCCESS)
        CyFxAppErrorHandler(apiRetStatus);

Thank you,

Garyio

I have the same problems (impossible states as 131 or 132 ..) , have you found the solution ? 

I created a Case but nobody answered to me. 

I try to connect a 16bits sensors with the FX3 SDK.

Best Regards,

Thomas