Author: HemanthR_06 Version: *B
Translation - Japanese: UVCのトラブルシューティングガイド– KBA226722 - Community Translated (JA)
How can I debug the UVC application firmware in FX3?
This knowledge base article can be considered as a quick reference for debugging UVC application. It is assumed that FX3 adds the UVC headers for the payload and the reference firmware is according to AN75779.
1. In the section - /* Class specific Uncompressed VS format descriptor */ of the descriptor file (cyfxuvcdscr.c):
- Make sure the pixel depth is correct.
- Verify that GUID, mentioned in this section, is supported by Microsoft UVC Driver. (RAW formats are not supported by UVC driver. If the GUID is set to RAW format, UVC driver drops the data which is sent by FX3 and no video can be seen in Standard Video applications).
2. In the section - /* Class specific Uncompressed VS frame descriptor */ of the descriptor file (cyfxuvcdscr.c), make sure the following are correct:
- Frame width and height (which is according to the video stream)
- Frame rate
- Maximum Video frame size in bytes
Note: In some designs, there might be instances where the data bus of the image sensor connected to GPIF data bus is not 8/16/24/32 wide. For example: the data bus of the image sensor can have 10 lines (in the case of image sensor supporting RAW10). If these 10 lines are connected to GPIF and the bus width of the GPIF is configured as 16, then for each PCLK, all 16 lines would be sampled. If the remaining 6 lines are pulled down on the board, then FX3 would be sampling logic ‘zero’ on these lines. If it is pulled up, logic ‘one’ would be sampled. So, for each PCLK 2 bytes are sampled and not 10 bits. Host application should take care of the extra bits in each pixel data.
3. Make sure that maximum video frame size set in the probe control structure (glProbeCtrl) is equal to or greater than the number of bytes sent in one frame. Also, make sure that the maximum payload size set in the probe control structure is more than the size sent in the payload (which is typically the DMA buffer size).
4. Make sure that the DMA buffer size is chosen in such a way that the total frame size in bytes is not divisible by (DMA buffer size – 16). In the DMA buffer configuration, 12 bytes are reserved for UVC Header and 4 bytes for footer and hence the image data would constitute (DMA buffer size – 16) bytes. Reason being a partial DMA buffer in DMA callback would indicate the end of the frame where ‘Frame end marker’ is inserted into the payload header.
5. If exact line data (i.e nothing is appended at the end of the line data) is intended to be sent to the Host, then make sure that line size in bytes is divisible by GPIF bus width (in bytes).
6. Calculate the number of full DMA buffers that would be required for each frame:
Total number of bytes per frame: S = (Image Width in Pixels) * (Image Height in Pixels) * (Pixel depth in bytes)
Total number of full DMA buffers per frame: F= Greatest integer less than ( S / (DMA buffer size – 16))
Number of bytes in the Partial buffer: P = (DMA buffer size – 16) * fractional part of (S / (DMA buffer size – 16))
Note: This partial buffer size (P) is equal to the dmaBuffer.count when partial buffer is received in DMA callback.
In the firmware, you can keep track of F and P (as mentioned above), and check if the values are as expected.
In the high-speed configuration of firmware mentioned in AN75779, FX3 streams the resolution 640*480 and 2 bytes per pixel. In this case:
S = 640*480*2 = 614400 bytes
F = Greatest integer less than (614400 / (16384 – 16)) = 37
P = (DMA buffer size – 16) * fractional part of (S / (DMA buffer size – 16)) = 8784 bytes.
7. Do not put any DebugPrints (CyU3PDebugPrint() calls) in DMA Callback. Instead, use flag variables and track them in the for(;;) loop.
8. If the message “Error in CyU3PDmaMultiChannelCommitBuffer: code 71” debug is displayed on a UART terminal when streaming video through FX3, implement the modifications mentioned Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830.
9. Probe the Frame Valid (FV) and Line Valid (LV) lines and make sure that the pulse widths are as per the expectation. That is:
LV high duration = (number of pixels per line) * (bytes per pixel) / PCLK_frequency
FV high duration = (LV high duration + line blanking time) * (number of lines)
10. Make sure that the PCLK frequency set by the image sensor on GPIO16(PCLK) is less than 100 MHz.
11. Make sure that the GPIF lines are terminated with 22-Ω series resistors. Also, make sure the GPIF lines are length-matched to within 500 mils.
12. Take a USB trace to check if:
- Second byte of UVC header field in the payload corresponding to full DMA buffer toggles between 0x8C and 0x8D in the subsequent frames. Second byte of the UVC header of last payload corresponding to the partial DMA buffer toggles between 0x8E and 0x8F for subsequent frames.
Considering the example above:
- For frame ‘k’, 0x8C will be the second byte in the UVC header for 37 payloads and 0x8E will be second byte in UVC header for the last payload of the frame ‘k’
- For frame ‘k+1’, 0x8D will be the second byte in UVC header for 37 payloads and 0x8F will be the second byte in UVC header for the last payload of the frame ‘k+1’.
- Total number of full buffers and a partial buffer are being sent as expected to the host.