AUP-ZU3 Pcam 5C read frame stuck

Support
1

Board: AUP-ZU3 (8GB)

PYNQ Version: 3.1

Issue:

readframe() hangs indefinitely when trying to capture frames from a Pcam 5C (OV5640) camera using the base overlay’s MIPI pipeline. The call never returns and no frames are captured.

Steps to Reproduce:

Start with a clean PYNQ image for the ZU3 board.

Boot the board and connect to the Jupyter notebook through your web browser.

In the notebook, navigate to /base/video/mipi_to_displayport.ipynb

Run Cells 1-4. The 4th cell runs indefinitely without returning anything.

frame = mipi.readframe()
PIL.Image.fromarray(frame[:,:,[2,1,0]])

Debugging Steps Taken:

The issue appears to be similar to the one presented here, but unlike this issue, I was able to see camera responding whether I ran mipi = base.mipi or not.

Output from running i2cdetect -y 3:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

From this, I gather that the camera is powered on and there is some communication between it and the board, but I haven’t been able to stream any frames.

I have also been looking through the post found here. However, the fixes appear to be specific to the KV260 board.

What are some steps I can take to more concretely find the source of the issue? I haven’t found similar issued reported specific to the AUP-ZU3 board, has anyone else seen this type of issue?

2

Hi @Preston-Walker,

Welcome to the PYNQ community.

We have found that those cameras are very fragile. The I2C has a different path than the data.
So, if possible can you try a different ribbon cable or camera?

The MIPI subsystem in the Kria is the same as in the AUP-ZU3, so you can try the fix proposed in the other blog.

Mario

3

Thanks for the quick response!

The camera is brand new, so I would hope it isn’t already broken. I tried swapping the ribbon cable and didn’t see any differences. I don’t have another camera available, have you found them to be so fragile that I should consider a replacement even with this one coming right out of the box?

As far as the solution from the Kria blog, I see this reply as the “solution“ with two jupyter notebooks and the bit/hwh files. I assume that the bit and hwh files are specific to the board and will need to be rebuilt, while the ipynb files should be fine on the AUP-ZU3. Does that sound correct?

Preston

4

The camera is brand new, so I would hope it isn’t already broken. I tried swapping the ribbon cable and didn’t see any differences. I don’t have another camera available, have you found them to be so fragile that I should consider a replacement even with this one coming right out of the box?

I haven’t found them very reliable, or may be an signal integrity issue. Never got to the bottom of it.

As far as the solution from the Kria blog, I see this reply as the “solution“ with two jupyter notebooks and the bit/hwh files. I assume that the bit and hwh files are specific to the board and will need to be rebuilt, while the ipynb files should be fine on the AUP-ZU3. Does that sound correct?

Correct.

5

Thank you for the response Mario! Sorry for the delay on my end, there were some changes in our lab, and I have only been helping from a distance while my colleague,@Victor-Santana , continues this project. Victor was having issues with his account, so I will post this message on his behalf:

Hi Mario,

Jumping into the thread here, my name is Victor Santana, and I am an undergraduate research assistant working alongside Preston on this AUP-ZU3 and Pcam 5C project.

Following up on your last message to Preston regarding rebuilding the Vivado files, our team has been working hard to implement the KV260 workaround, but we are still hitting a wall. We wanted to share a detailed update on the debugging steps we’ve taken to see if your team might have any further insights.

As a quick refresher on our environment:

  • Board: RealDigital AUP-ZU3 (8GB DDR4 variant)
  • PYNQ Version: 3.1
  • Tool Version: Vivado/Vitis 2024.1 (also tested on custom images built with PetaLinux)

The Issue: Even with brand new ribbon cables, the I2C control communication connects perfectly, but the MIPI video data path hangs indefinitely. The Python execution gets completely stuck at the frame = mipi.readframe() command. It never throws a timeout error, no frames are captured, and the MIPI CSI-2 Rx Subsystem registers indicate 0 packets received.

Debug steps we have taken so far: To rule out as many user errors and hardware variables as possible, we have tried the following:

  • Physical Hardware Checks: As Preston mentioned, we initially suspected the fragile 15-pin FFC ribbon cable. We have now tested this setup using brand new cables across two completely different AUP-ZU3 boards and two different cameras. The exact same hang happens on all hardware combinations, so we are confident it is not an isolated microscopic cable fracture.
  • I2C Verification: We ran !i2cdetect -y 3 on all setups, and it correctly returns 0x3c. From what we understand, this confirms that the OV5640 sensor is receiving power and its digital core is responding perfectly to the I2C control plane.
  • Custom Vivado Overlays: Per your advice on the KV260 fix, we tried bypassing the prebuilt image by building our own custom PYNQ images using the instructions found in the Xilinx/AUP-ZU3 GitHub repo. We patched the pipelines to the very best of our abilities, generated the new bitstream, uploaded the .bit and .hwh files directly to our Jupyter environment, and ran the base mipi_to_displayport.ipynb notebook. Unfortunately, it still hangs.
  • Manual GPIO Power-Up: We tried manually toggling the camera’s power-up pin (CAM0_PWUP) using PYNQ MMIO (at offset 0x08 for GPIO Channel 2) before running the standard Python initialization. We read that this can help ensure the sensor’s analog core is fully awake before sending the massive array of I2C configuration commands.
  • Hardware Probing (ILA): To definitively check if any video data is making it into the FPGA, we embedded a Vivado Integrated Logic Analyzer (ILA) onto the video_out_tvalid pin of the mipi_csi2_rx_subsyst block. When we run the Python script, the ILA stays stuck on “Waiting for Trigger.” We even tested the ILA on a board push-button to verify our trigger logic was correct. This proves that the MIPI Receiver is truly outputting zero digital packets into the fabric.

Given that the hardware is new and the ILA confirms the packets are dropping before they enter the Vivado pipeline, are there any specific MIPI D-PHY analog timing parameters (like HS_SETTLE_NS) that we need to manually adjust when building the AUP-ZU3 bitstream?

We really appreciate your patience and help in guiding us through this! We are happy to provide our custom .bit / .hwh files, Jupyter Notebooks, or any other logs that might help clarify things.

6

This is indeed very strange. Would you have other hardware to try the camera?

I am trying to work in a full Python driver that may make the debugging easier.
Can you let me know what is the PCAM5C revision?

7

We have two cameras and two AUP-ZU3 boards. We have tried all permutations of those and gotten the same results. We don’t have any other mipi-compatible boards to try. Our camera revision is Rev C.0.