- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using Python 480 sensor together with FX3. It is 10-bit data bus, SPI configuration interface, 808*608 pixel image sensor. Image format is raw 10 bit. Design is based on AN75779 sample code. So, I made modifications according to instruction in AN75779.
- GPIF interface and state machine
- data bus width :change from 8-bit to 16-bit
- active clock edge: change from positive to negative
- fx3 Peripherals used: add SPI
- signals: sensor reset signal change from GPIO 22 to GPIO 23
- state machine:
- LD_ADDR_COUNT: change to 8183
- LD_DATA_COUNT: change to 8183
- cyfxuvcdscr.c file
- Class specific Uncompressed VS format descriptor ( for both High speed and super speed)
- X dimension of the picture aspect ratio: from 0x08 to 0x65 (808/608=101:76 = 0x65:0x4C. Is this the right way to calculate ratio??)
- Y dimension of the picture aspect ratio: from 0x06 to 0x4C
- GUID: keep YUY2. (Please let me know the 16-BYTE hexadecimal value of GUID for 16-bit raw image and 24-bit raw image???)
- Class specific Uncompressed VS frame descriptor ( for both high speed and super speed)
- Width in pixel : change to 808, i.e. 0x 28, 0x03
- Height in pixel : change to 480, i.e. 0X60, 0x02
- Min bit rate bits/s :
- High speed : 10fps : 808 * 608 *16 *10 =0x4AF6000
- Super speed: 60fps : 808*608*16*60 =0x1C1C4000
- Max bit rate bits/s
- Hispeed: 30fps : 808*608*16*30 = 0xE0E2000
- Superspeed: 132fps : 808*608*16*132 = 0x3DD7C000
- Maximum video or still frame size in bytes(Deprecated): change to 808*608*2 = 0xEFE00(for both high speed and super speed)
- Default Frame Interval
- High speed: 30fps: 0x51615 (100ns)
- Super speed:132fps: 0x127EE (100ns)
- Shortest Frame Interval
- High speed: 30fps:0x51615 (100ns)
- Super speed:132fps: 0x127EE(100ns)
- Class specific Uncompressed VS format descriptor ( for both High speed and super speed)
- UVC.c file
- glProbeCtrl[CY_FX_UVC_MAX_PROBE_SETTING]
- glProbeCtrl20[CY_FX_UVC_MAX_PROBE_SETTING]
- replace corresponding I2C sensor functions with current SPI functions.
- add GPIF state machine status capture
- add sensor registers configuration read back for confirmation
- uvc.h
- enable DEBUG_PRINT_FRAME_COUNT
Please see attached files for above modifications.
Pixel clock, frame valid and line valid signals are correct. Timing between frame valid and line valid are good. Captured waveforms are attached. 1.8V GPIF interface logic level is used
But the UVC host only can show " The format is right. But the framerate is 0.
USB can be detected as super speed. Please see log file for debug print on UART port. The log is power on device-> start UVC host application->close UVC host application. log file shows there is frame received and frames in the buffer also. But can't display frames on host application. Host application has no problem to display other UVC devices.
I need help on which part could be wrong with it.
Thanks in advance for help.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kelly,
From the traces it is found that the total bytes you are receiving at the host end is receiving more than the expected bytes
Expected bytes without header (GPIF): 808*608*2 = 982528
Full buffer no. - 982528/16368 = 60
Expected bytes with header (DMA) : 982800 + 460 = 983260
Bytes in Full buffer: 60*(16380) = 982800
Bytes in Partial buffer: 1*(460) = 460
Received bytes: 982800+ 5308 = 988108
Bytes in Full buffer: 60*16380 = 982800
Bytes in Partial buffer: 1*5308 = 5308
Bytes Difference = 988108 - 983260 = 4848
The document https://www.onsemi.com/pub/Collateral/NOIP1SN0480A-D.PDF related to the Python 480 mentions that there is black line data (this can be reason for extra bytes that you are receiving). By default the values are 0x1 and 0x1 (refer attachment). You can change this setting to 0x0 and 0x0 for not getting the black line data sampled. For the changes please refer to the register map (table 25 of the document referred)
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The changes you did, seems fine.
Please share the USB traces. You can use Wireshark analyser for capturing it.
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rashi,
Thanks for looking into this issue.
Please see attachment for traces.
I have a question regarding Min bit rate bits/s and Max bit rate bits/s in VS frame descriptor section. Current image frame rate is 132 Hz, confirmed by measuring frame_valid signal. As long as I set values so that 808*608*16*132 is between Min bit rate bits/s and Max bit rate bits/s, they are good, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kelly,
From the traces it is found that the total bytes you are receiving at the host end is receiving more than the expected bytes
Expected bytes without header (GPIF): 808*608*2 = 982528
Full buffer no. - 982528/16368 = 60
Expected bytes with header (DMA) : 982800 + 460 = 983260
Bytes in Full buffer: 60*(16380) = 982800
Bytes in Partial buffer: 1*(460) = 460
Received bytes: 982800+ 5308 = 988108
Bytes in Full buffer: 60*16380 = 982800
Bytes in Partial buffer: 1*5308 = 5308
Bytes Difference = 988108 - 983260 = 4848
The document https://www.onsemi.com/pub/Collateral/NOIP1SN0480A-D.PDF related to the Python 480 mentions that there is black line data (this can be reason for extra bytes that you are receiving). By default the values are 0x1 and 0x1 (refer attachment). You can change this setting to 0x0 and 0x0 for not getting the black line data sampled. For the changes please refer to the register map (table 25 of the document referred)
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kelly,
Also let me know the host application that you are using.
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rashi,
Thank you for your help. The problem is resolved by re-configuring the sensor to be 800*600 with other a bunch of parameters.