Common Problems with UVC
1. Introduction
When using UVC, some common issues may arise, and here are some debugging methods provided.
Q: After calling the UVC power on interface, the camera does not enumerate (no prompt of successful connection)
A: This kind of problem is usually due to the camera not being powered on or insufficient power supply. It is recommended to supply 5.0V of voltage to the USB. The BK7258 controls the USB LDO through GPIO28, which can enable the USB power by pulling it high, and can shutdown the USB power by pulling it low. This can be configured through macros:
Q: Enumeration was successful, but no image is displayed.
A: This issue usually requires checking if the parameters are configured incorrectly, such as the camera not supporting the resolution you have configured, which would then require you to reconfigure it. When the resolution is configured incorrectly, you will see the following log: “uvc_camera_set_param, not support this format or resolution, please check!”. If this is not the case, you may need to capture packets to analyze whether the UVC data packets are normal, including headers and valid data, and that the valid data is within the normal range.
Q: The frame rate is lower than expected.
A: The “expected” refers to the frame rate in comparison to a PC, for example, if you configure it to 30fps but the actual output is only half that or much lower, plug it into the computer to analyze whether the frame rate is also low on the computer, which can help rule out issues with the camera itself. If it’s not an issue with the camera itself, then consider whether it’s a problem with the SDK. This requires log analysis or packet capture analysis using a protocol analyzer.
Q: There are abnormal screen cutting issues in the image, and the image is incomplete.
A: This situation usually requires checking if there are any misconfigurations in the transmission mode, ISO/BULK, and then checking if there are any errors in the upper layer unpacking logic.
Q: The image displays abnormal halos and distortions.
A: This is generally considered an issue with the camera itself. Try plugging it into a PC to analyze whether the same problem occurs.
Q: Abnormal log: “uvc_camera_urb_malloc failed” appears, or there are abnormal screen cuts during synchronous image output.
A: The reason for this issue is that the USB fails to allocate URB to store data in the FIFO. The failure to allocate is because all USB resources are exhausted and there are no idle URBs. There are two root causes for this:
- One is that the efficiency of consuming (parsing) the URB that has stored FIFO data is too low, or the process is stuck, resulting in all idle URBs being consumed and the URB pool being filled with URBs waiting to be parsed.
Reference code: “./ap/bk_uvc/bk_uvc.c”, which is parsed by the task “uvc_pro_task”. You need to analyze whether it is stuck or has low efficiency.
Another reason is that the number of URBs is truly insufficient. For example, when using dual cameras, the number of URBs is recommended to be at least twice the default value of 4.
The following macros define the number of URBs.
marco
value
implication
CONFIG_UVC_URB_NUM
4
receive usb data urb number
CONFIG_UVC_NUM_PACKET_PER_URB
8
an urb include packets
Q: When using UVC for H.264 pipeline encoding, the log “h264_encode_finish_handle 26430-65536, error:1” is printed.
A: There are two reasons for this log message:
One is that when the first number (26430) is greater than the second number (65536), it indicates that the length of the I frame is greater than the length of the frame_buffer (the second number).
Modification method: Increase the value of the macro CONFIG_H264_FRAME_SIZE to a larger number.
The other is that “error:” has a value of 1, indicating that the length of the decoded JPEG image is incorrect. This suggests that the JPEG image has padding bits. To prevent image anomalies, the decoder performs strict length checks on the image internally.
Modification method: It is recommended to modify the camera firmware to ensure that the UVC output JPEG image does not have padding bits. Such padding bits are usually at the end and are either 0xFF or 0x00.
Another method is to lower the internal length check mechanism of the decoder, which is not recommended as it may lead to JPEG anomalies causing the screen to display incorrectly.
Q: The image is displayed normally on the PC end, but not on the board, and the log prints “uvc_drv:W(18012):seq:0 ok:39654, error:0, emp:70614, eof_not_ffd9:0, end_not_ffd9:xxxx”;
A: In the above log, the seq is always 0, indicating that no images are output. The ok value is not 0 and keeps increasing, which means that normal data is being transmitted over USB. The end_not_ffd9 value is not 0 and keeps increasing, indicating an abnormal packet parsing. There are two reasons for this log message:
In BULK transmission, there are empty packets (only containing header but no valid data) in the transmission. The current firmware defaults to not allow the transmission of empty packets.
Modification method: It is recommended to modify the firmware to ensure no empty packets are transmitted; alternatively, you can disable the macro CONFIG_UVC_CHECK_BULK_JPEG_HEADER.
In ISO transmission, there are filling data at the end of frame.
Modification method: The current firmware defaults strictly check if the last two bytes of the frame are 0xffd9, change to check if the last 1024 bytes of frame contain 0xffd9. The SDK will be modified as follows: The length of the check is controlled by the macro: CONFIG_JPEG_FRAME_CHECK_LENGTH, with a default value of 1024, which can be modified as needed. Note: If there is an excessive amount of padding data at the end of the image, it will cause the check mechanism to take more time.
Q: Display works normally on PC but not on board, and the log shows “uvc_id1:0[348 85KB], uvc_id2: 0[0 0KB], uvc_id3:0[0 0KB], packets:[all:95832, err:0]”;
A: Log format explanation: uvc port id: current frame rate [current frame number current image size]; Please check the error log to see if there are corresponding logs about opening failures.