We are currently working on the development of a product centered around the adsd3100 sensor module and have been using the eval-adsd3100-nxz evaluation kit for this purpose. Our team has successfully ported the embedded Linux builds from your SDK to Yocto, allowing us to build our own software platform. However, we have encountered issues with image corruption when moving to other versions of u-boot. We are concerned about this as we plan to use a different SOM/baseboard in the future and would like to address any potential issues beforehand.
We have been using version 3.0.0 of the SDK as it has been working well for us during our tests. We have also examined the TOF git repository and noticed that the adsd3100 drivers have not been updated since the 3.0.0 tag. Our team has moved the kernel drivers for the adsd3100 and other patches from your SDK to a Yocto build based on a SolidRun layer for the same iMX8 SOM used in the evaluation kit. The kernel version we are using (5.10.72) is the same as the one used in the SDK, and we are confident that we could move to another kernel version without issues.
Our issue arises when using a newer version of u-boot (2021.04) with the patches from your SDK. While the camera is detected without problem and the commands/responses with the camera remain the same as when running on the working version of u-boot (2020.04), we experience image corruption. We have conducted an in-depth investigation of the drivers and have not found any obvious issues. To capture the images, we have used the data_collect example from the SDK with the default settings (mode 10: 1Mpixel 1024x1024).
Upon analyzing the data, we have found that whilst every four scanlines of each of the nine subframes should be 8192 bytes long, they typically contain only 6726 bytes of data, with the remainder being zeroes. As each value is two bytes, in pixel values this means that we get about 3363 values instead of the expected 4096 values from four 1024-pixel scanlines. When decoding the raw data, the offset for each pixel relative to the start of each of the 9 subframes is normally calculated as y*1024 + x. However, to generate a fixed version of the image, we use the following formula:
(y / 4 * 4096) + ((((y % 4) * 1024) + (x - 2 * (y % 4))) * 3363) / 4096
Our fixed version of the image looks approximately correct, but it is not perfect.
A possible issue that we have discounted is bit-expansion. A four-scanline block of 1024-pixel lines is 8192 bytes at 16-bit-per-pixel. If it were 11-bit-per-pixel, which we understand the camera provides, then this would be 5632 bytes. We see 6726 bytes. If it were 12-bit it would be 6144 bytes, 13-bit would be 6656 bytes, 14-bit would be 7168 bytes. However in all these cases, it would not be possible to simply duplicate 16-bit values every Nth pixel to get valid data (the bit ordering would cycle around through the scanline, and look totally corrupted). Therefore whatever subsystem is responsible for zero-padding from 11(?) bit to 16 bit is being performed correctly, but apparently pixels are being dropped.
We have placed the images and raw files at the end of this query. The zip contains the raw bin file output (raw_frame_20230411121437_00000.bin), and the ccb.dat file. Below are our converted image which shows the corruption (raw_frame_20230411121437_00000.bin ir.png), the fixed version of the image (image raw_frame_20230411121437_00000.bin ir-fixed.png).
We would greatly appreciate any insights you can provide regarding the issue we are encountering.
Image as obtained, converted to PNG:
Image "fixed up" using the formula above, duplicating some pixels:
Raw data and CCB:
