Hi everyone,
I am currently using the SingTown N6 board to drive a GEN X320 event camera. I saw on GitHub (PR #3176) that there was an attempt to fix the frame buffer occlusion bug for the GENX320. Therefore, I specifically updated my board’s firmware to the v5.0.0 development version (which includes this fix) via the OpenMV IDE on my Mac.
However, when I run the standard csi raw event stream Python example, I found that the exact same frame buffer occlusion/overlap issue is still present.
To isolate the issue, instead of blindly modifying the underlying .c/.h files, I performed the following stress tests at the Python level. I hope this provides some useful clues for the underlying debugging:
1. Physical Rate-Reduction Test (Ruling out data overflow):
I completely covered the camera lens to drop the Event Rate to near zero. I found that the fixed occluded area and the vertical flashing black lines still persist. This essentially rules out a Ring Buffer overflow caused by excessive event stream data.
2. Array Size Reduction Test (Locating memory mapping conflicts):
I reduced events = np.zeros((2048, 6), dtype=np.uint16) in the code to 1024. The size and position of the occluded block on the screen did not change at all. This indicates that the physical memory location allocated at the lower level is hard-coded and overlapping.
3. Read/Write Separation & GC Test (Ruling out double-buffering conflicts):
I forcibly added time.sleep_ms(5) and gc.collect() between reading data via csi0.ioctl and rendering it with img.draw_event_histogram(). This was an attempt to avoid a bus conflict between the underlying DMA write and the USB image output. However, the occlusion remains rock solid.
Conclusion & Speculation:
Based on the above phenomena, I suspect that in the underlying C driver for the N6 hardware, the direct physical memory (DMA) allocated during GENX320 initialization still hard-overlaps with the physical address of the Framebuffer maintained by MicroPython. This issue does not seem to be fully resolved in the current v5.0.0 dev release.
I have attached a screenshot of the corrupted output from the IDE below. Has anyone else successfully run this raw event stream on the N6? Alternatively, could the developers provide a test firmware with adjusted memory alignment for me to verify?
Thank you very much!
Hi, that’s actually a bad adapter board. What is happening is that one of the upper bits on the databus isn’t connected.
I need to send you a replacement model.
These defective units escaped our factory because we test the camera in histogram mode where the upper bits of the databus are typically 0. I have since updated the factory test to use event mode where all bits of the databus are used so that defective adapter boards are caught during testing.
Please send me a private message with your shipping address and phone number. We just finished building 100 more sensors.
…
Note, your video isn’t working anymore. I saw it earlier though and saw the problem which is the defective data bus issue.
However, please verify that your N6’s parallel databus pins are all connected. Do you have any other of our sensors from our older cameras?
Hi Kwagyeman,
Thank you so much for the quick diagnosis and for explaining the root cause! It makes perfect sense that a disconnected upper bit on the databus would cause this “stretching” effect. It’s great to know the event mode test will catch this in the factory from now on.
I want to send you my shipping information right away, but since my forum account is newly registered, I don’t have the permission to initiate a Private Message (the message button is missing on your profile). Could you please initiate a PM to me first, or provide an official email address where I can securely send my shipping details?
Regarding the N6 board, I will visually inspect the parallel databus pins. I currently only have the PAG7936 camera module on hand. I can plug it in and test it if it helps, but I’m assuming it routes through the MIPI CSI interface on the N6 rather than fully utilizing the parallel databus?
Unfortunately, I don’t have any older purely parallel sensors to perform a strict cross-test on the parallel pins, but the N6 headers look physically intact.
Thanks again for the excellent support!
Hi,
We from the TU Delft are experiencing the exact same issue on multiple of our N6 + GENX320 setups.
The event output contains the same corrupted/artifact regions as shown in this thread.
Is there a possible solution for this issue, or is a replacement adapter board required?
Thanks!
Please send me a PM with an image of the issue in the IDE and if it’s a hardware problem we can replace it. We’ll need a returned unit so we can fix the issue on the adapter board.