cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

hazc_3949451
New Contributor II

I'm trying to get ov5647 streaming on a custom board using cyusb3065, without any success. Can someone with experience give some hints? Any help would be appreciated.

1.CyCx3AppDmaCallback gets called consistently, I have a thread printing mipi error every 300ms.mipi_error.png

2.I have the following configuration

mipi configure.png

3. I've tried playing with CyU3PMipicsiSetPhyTimeDelay, setting different delays, but it doesn't work.

1 Solution
YangyangC_06
Employee

Please DO NOT call any UART print function in CyCx3UvcAppDmaCallback since it will block the very high speed data transfer. CyCx3UvcAppDmaCallback should return ASAP.

If you want get some UART print output, please

1. Set some global variables to indicate the DMA status. These values will be changed in DmaCallback function. Print them in main thread or another thread if you want.

2. Try to use Event for communications between two or more threads. You may refer to CyU3PEventGet/Set functions.

You could refer to the example project, Cx3UvcOv5640 in SDK path, to know the detailed information.

#define PRINT_FRAME_INFO

/* Uncomment the following line to provide verbose debug logging. */

/* #define CX3_DEBUG_ENABLED                    (1) */

       

/* Uncomment the following line to run the mipi error thread */

/* #define CX3_ERROR_THREAD_ENABLE              (1) */

View solution in original post

25 Replies
YangyangC_06
Employee

Hi Han Z,

Could you please confirm if the sensor starts to ouput vide data? Measure the waveform on CSI Clock+/- and D0+/- and upload the screenshots here.

0 Likes
hazc_3949451
New Contributor II

Hi yyca,

Thank you for your reply, unfortunately the custom board doesn't have test points available.

I was able to briefly get a glance of clock and data lines, but can't hold stable(I hope I had an additional hand to print the plot).

I can confirm there's legit mipi signals, plus CyCx3AppDmaCallback getting called also proves there's mipi data coming in, I presume?

So given the circumstances, what can I do now?

0 Likes
YangyangC_06
Employee

We could check whether the parameters in the configuration tools are correct or not by capture the waveforms of CSI clock+/-, data lane0+/-.

That's why I ask you do that. Please try to capture the screenshots and share them here.

0 Likes
hazc_3949451
New Contributor II

I'll try to get the capture tomorrow, assuming at least one of my colleagues is back to work.

0 Likes
hazc_3949451
New Contributor II

clock:

a4.bmp

data:

a3.bmp

Not pretty, is it usable? I probed using a normal passive probe. I was not able to use an active probe, since it doesn't have that sharp tip.

0 Likes
YangyangC_06
Employee

The screenshots are not clear. Could you please provide the photos with different time scale? I upload the attachment for example.

scope_3.png

0 Likes
hazc_3949451
New Contributor II

I'll try to probe with active differential probes.

0 Likes
hazc_3949451
New Contributor II

mipi_view1.bmp

lp2hs.bmp

hold_time.bmp

Yellow is clock.

Captured with active differential probes, soldered 100ohm differential impedance at receiving end.

I don't know if this is normal, but why the rise time is so long in the third picture? I remember in the mipi SPEC rise+fall time should be less than 0.3UI, right?

0 Likes
YangyangC_06
Employee

Hi Han Z,

The waveforms looks weird.

I probe the signals on CX3 Denebola board for reference. To get the below screenshots, I use a passive probe and the signals are measured in single end.

CH3 is D0- and CH1 is CLOCK-. Please note the time scale.

In first screenshot, the time between two cursors are 33ms which stands for the frame rate is 30 fps.

040327_022348.jpg

Below is the zoom in of picture1

040327_022525.jpg

The third screenshot is CLOCK-(Gated clock). Again, the time between two cursors are ~33ms(30 fps)

040327_023018.jpg

040327_023103.jpg

0 Likes
hazc_3949451
New Contributor II

Hi yyca,

Thank you very much for your reply,

I went back and captured the waveform with bigger time scale. The fps is 30 I think.

Using active differential probe, so the LP-11 is neutral.

frame_interval.bmp

line_interval.bmp

0 Likes
YangyangC_06
Employee

How about the PCLK/H_sync/V_sync pins of CX3? Please probe these three pins and share the waveform.

0 Likes
emsic_2321041
New Contributor II

Hi yyca ,

turns out me and hany are working on the same hardware platform but different geographical locations;

I'm posting PCLK/V_sync/H_sync pin captures on CX3.

Is there anyone having success making ov5647 work with CYUSB3065 ?

If so , can you share a working image to try to validate our hardware?

scope_24.bmpscope_21.bmpscope_22.bmp

0 Likes
emsic_2321041
New Contributor II

adding schematics/camera_assy for reference...REFCLK on CX3 is 19.2MHz TXOscha.bmp3508-07.jpg

0 Likes
YangyangC_06
Employee

Hi Simion,

We don't have an img file built from OV5647. From the waveform of PCLK, we could know that you set it to ~64 MHz. However, the next two screenshots show that V_sync and H_sync are corrupted. Please

1. Check all the values in CX3 MIPI configuration tool to ensure that all of them are in correct range.

2. Based on step 1, try to invoke API CyU3PMipicsiSetPhyTimeDelay() following CyU3PMipicsiSetIntfParams()

     status = CyU3PMipicsiSetIntfParams (&AR0521_RAW8_1080P_2lane, CyFalse);
     if (status != CY_U3P_SUCCESS)
     {
      CyU3PDebugPrint (4, "\n\rUSBStpCB:SetIntfParams SS1 Err = 0x%x", status);
     }
           CyU3PDebugPrint(4,"\r\n step 3 %x",status);

     status =  CyU3PMipicsiSetPhyTimeDelay(1,0x03);
     CyU3PDebugPrint (4, "\n\r Mipicsi Set PHY Delay status = 0x%x",status);

Change the second parameter of CyU3PMipicsiSetPhyTimeDelay until H_sync and V_sync become normal.

hazc_3949451
New Contributor II

Hi yyca,

I tried values from 0~0x7f(in an interval of 8), none of them worked.

But I also observed something interesting, if I set the delay less than 0x10, based on the uart output, I can see the system runs dmacallback a couple times then freeze(all periodic uart prints don't appear anymore), doesn't react to anything.

Best,

0 Likes
emsic_2321041
New Contributor II

no updates.... not sure what else to try.

0 Likes
YangyangC_06
Employee

1. Please try to invoke API CyU3PGpifGetSMState to check it SM runs correctly. Print these status in main thread of a new thread to know that.

2. Try to check the data package on USB BUS. This could be checked with software tool(BUS HOUND/USBlyzer) or hardaware tool(LeCory or Eilisys USB analyzer).

0 Likes
emsic_2321041
New Contributor II

Hi yyca,

1. values in CX3 config tool are ok. nothing to flag.

2. changing values of second parameter of CyU3PMipicsiSetPhyTimeDelay gets H_sync and V_sync stable. Not sure if correct/normal [see attached screenshots].

3. as Hanyi specified we are getting :

...

DMA callback type=16

DMA callback type=8

...

not sure what next....

cheers!

scope_28.bmpscope_29.bmpscope_31.bmpscope_30.bmp

0 Likes
YangyangC_06
Employee

The waveforms on PCLK/H_sync/V_sync looks correct. Could you please clarify where you get these DMA callback errors(I don't have your code so the log doesn't make sense for me)?

Could you see any USB data package in BUS HOUND?

0 Likes
hazc_3949451
New Contributor II

We don't have access to an usb 3.0 analyser, I used wireshark to capture the usb packet. You can see one blk in transactions, then no usb activity from then on.

On the cypress chip side, I print the dma type everytime CyCx3UvcAppDmaCallback gets called. Like this:

CyU3PDebugPrint (4, "\n\rDMA callback type =%d",type);

I think type 8 means GPIF data in, type 16 is USB out. From the code:

     CY_U3P_DMA_CB_PROD_EVENT = (1 << 3), /**< Buffer received from producer. This event is generated when

                                              a buffer is generated by the producer socket when a transfer

                                              is queued with SetXfer. */

    CY_U3P_DMA_CB_CONS_EVENT = (1 << 4), /**< Buffer consumed by the consumer. This event is generated when

                                              a buffer is sent out by the consumer socket when a transfer

                                              is queued with SetXfer. */

CyCx3UvcAppDmaCallback would execute several times, then stops, together with other periodic print, and if you close the camera app on pc, there's no reaction from the chip(no usb event print in CyCx3UvcApplnUSBSetupCB). I assume the firmware hangs.

0 Likes
YangyangC_06
Employee

Please DO NOT call any UART print function in CyCx3UvcAppDmaCallback since it will block the very high speed data transfer. CyCx3UvcAppDmaCallback should return ASAP.

If you want get some UART print output, please

1. Set some global variables to indicate the DMA status. These values will be changed in DmaCallback function. Print them in main thread or another thread if you want.

2. Try to use Event for communications between two or more threads. You may refer to CyU3PEventGet/Set functions.

You could refer to the example project, Cx3UvcOv5640 in SDK path, to know the detailed information.

#define PRINT_FRAME_INFO

/* Uncomment the following line to provide verbose debug logging. */

/* #define CX3_DEBUG_ENABLED                    (1) */

       

/* Uncomment the following line to run the mipi error thread */

/* #define CX3_ERROR_THREAD_ENABLE              (1) */

View solution in original post

hazc_3949451
New Contributor II

Thank you, we've made it work. The problem is exactly the uart print in CyCx3UvcAppDmaCallback.

What I don't understand is why it would freeze the whole system, maybe a deadlock between two threads that handles hardware?

YangyangC_06
Employee

You could see video stream from host application, e-Cam for example. Is that right?

0 Likes
hazc_3949451
New Contributor II

Yes, I verified using e-Cam.

0 Likes