thinkthinkthink

Hullo,
Where'd you get the demo project from and which version of Vivado are you using ?
You can get the latest release for Vivado/Vitis 2022.1 from our github: FMC_Pcam_Adapter Demo Archive.
The Vivado hardware project can be found here: https://github.com/Digilent/ZedBoard-HW/tree/FMC-Pcam-Adapter/master.
And the Vitis software project is here: https://github.com/Digilent/ZedBoard-SW/tree/FMC-Pcam-Adapter/master.
As for the UART interface not working maybe try uninstalling the cypress uart bridge driver and then unplugging and plugging the board back.

Hi @Leonlin666,
I do not think this will be possible to do. The existing MIPI connector was designed to implement a compatible D-PHY receiver as per XAPP894 from Xilinx (more details about this are available on the Zybo Z7 Reference Manual here: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#pcam_port).
The Pmod ports have not been designed to meet these requirements. I suppose in theory it would be possible to route out the 8 data signals to a Pmod port (preferably with no series resistors) and make a custom adapter to physically connect to a second Pcam module, but I would not be surprised if implemented the Pcam did not work as expected (especially at higher clock rates for higher resolutions).
Thanks,
JColvin

Absolutely. The sequence should look something like this: Start -> Pcam address 7bits + Write bit -> ACK -> Register Addr High 8 bits -> ACK -> Register Addr Low 8 bits -> ACK -> Write Data 8 bits -> ACK -> Stop.
The above sequence is meant for a Write transaction. For Read transactions you have to first WRITE the register address and then re-address the Pcam but this time ending in Read bit like so:
Start -> Pcam address 7bits + Write bit -> ACK -> Register Addr High 8 bits -> ACK -> Register Addr Low 8 bits -> ACK -> Repeated Start -> Pcam address 7bits + Read bit -> ACK -> Read Data 8 bits -> NACK -> Stop.

If you're using the TMP2 Pmod then you only need the MicroBlaze processor, the MIG7 IP and an IIC IP to write to and read from the adt7420. It says in it's datasheet that it has a 16-bit ADC so there's no need to use the XADC.
Also make sure to give the TMP2'S Reference Manual a read through.

Here's the HW branch: Zybo-Z7-HW/20/Petalinux/upgrade. Were you not able to find it ? Should I let others know that this new repo structure is a bit confusing ?
And about that base linux project, it's obsolete but it was replaced by the project I just linked. I think it's the same project even, it's just that it was moved to a new repo.

Make sure stdin and stdout are set to your axi uartlite ip in the BSP settings of your hardware platform.

We've got a new series of tutorials on our youtube page, check them out.

set_property -dict { PACKAGE_PIN Y10 IOSTANDARD LVCMOS33 } [get_ports {uart_rtl_rxd}]; # "JA3"
set_property -dict { PACKAGE_PIN AA9 IOSTANDARD LVCMOS33 } [get_ports {uart_rtl_txd}]; # "JA4"
Here, fixed your constraints for you, it's that easy.

Used to happen for me as well, don't remember what fixed it, either ending the hw_server with Task Manager in Windows or restarting my PC. If you really want your board to program as fast as possible you can increase JTAG frequency to 30MHz in Vivado Hardware Manager. On kintex-7 and zynq ultrascale+ or above you'll see longer programming times since .bit files and etc. are bigger in size even on maximum JTAG frequency.
 


 
The only problem with increasing JTAG frequency is if you have any ILAs in your design you should make sure that the clock at which those ILAs are running is at least 2.5 times higher than JTAG frequency according to Xilinx.

Disconnect from the Board flow tab and try again with manual constraints.

Maybe it's also worth deleting the uartlite IP and adding it back again.

You can also try regenerating the bitstream after clearing IP cache from Tools->Settings->IP and/or manually constraining those pins in the board XDC file to your UART interface. It's pretty pointless to do any debugging if those pin connections haven't been made inside the FPGA. What I hope will happen is after you add an ILA to your design and regenerate the bitstream, Vivado will finally do its job properly during the synthesis and implementation phases.

Check your UART interface with an ILA. This should be the first thing to do when debugging in Vivado.

For the Genesys 2 FMC Pcam Adapter Demo I rewrote everything in C so it should be easier to understand. 
The a_pin parameter refers to those address lines (A0, A1, A2) on the I2C mux IC that's on the FMC Pam Adapter. As you can see the A2 line is already tied to GND so all that's left are A0(GA1) and A1(GA0) which come from the FMC connector. For those you have to check what they are tied to on the FMC connector that's on the Zedboard.



As you can see from the schematic, on the Zedboard the FMC pins corresponding to A1(GA0) and A0(GA1) are tied to GND.
So that makes the values of A0, A1, A2 to be 000, which makes a_pin be equal to 0 (or 0x00 in hex).
Basically, what you have to do is first address the I2C mux at address (0xE0 >> 1), tell it which channel to open (0, 1, 2, or 3) and then config your pcams through I2C at the (0x78 >> 1) address.  
 

That's because those PMOD ports are connected to FPGA pins which can be reconfigured (inside the FPGA) for a lot of different functions/protocols while on the microcontroller those are wired to peripheral pins that only have a limited set of hard-wired functions. On an FPGA board you can make a custom design and be able to literally connect 4 different I2C devices to 1 PMOD port and have 4 different SCL and 4 different SDA lines (you'll need a bunch of wires but whatever). Basically you can customize those PMOD pins however you like/want/need.

HUGE DISCLAIMER! You'll have to write your own I2C driver using the iic functions in Xilinx's embeddedsw repo (XIic_MasterRecv, XIic_MasterSend etc.).

Add the two AXI IIC IPs to your block design and let Run Connection Automation do its job or you can manually make the IIC ports external. Then go to our XDC Repo and get the Zybo-Z7-Master constraints file. 
Right click on Constraints and select Add Sources. 

Click on Add Files and look for the .xdc file wherever you downloaded/saved it on your PC. Make sure Copy Constraints files into project is checked, this makes it so if you modify this .xdc file (which you will) you'll still have a fresh unmodified original which can then be imported into other projects.

Uncomment the lines corresponding to the Pmod port which you'll want to use, in this example I'm using JD but because of the HYGRO and AQS pmod pinout you'll only need to uncomment jd[2], jd[3] and jd[6], jd[7].

This is the pinout for the PmodAQS and you might want/need to also use the IO/INT or WAKE/RST pins so make sure to read through its Reference Manual.

Make the following changes in the XDC, Validate Design, Generate Bitstream and you're good to go.

 

This is the pinout of the PmodHYGRO, to be able to use it on both top and bottom rows of a Pmod port you're going to need to use two AXI IIC IPs, or just one AXI IIC together with the I2C controller inside the ZYNQ processing system, with their interface IIC constrained to the Pmod port (one top row and the other bottom row) you're going to plug it into (double check to make sure you've nailed the pinout correctly). The PmodHYGRO IP also has an AXI TIMER inside it so maybe you're gonna want to add that to your block design as well (although you might be able to manage without it, not sure, since the ZYNQ also has some timers inside).

We were working on a demo project for zynq ultrascale+ with the MIPI CSI RX Subsystem however it got postponed indefinitely. But you can check out Adam Taylor's own demo for our Genesys ZU board, he is using it in his block design.
As for why some of our IPs are disabled when adding them to your project's IP Repository there could be multiple answers. What board is your project set to target ? I know for a fact our MIPI IPs are NOT compatible with the zynq ultrascale+ architecture so they're greyed out for me too when trying to add them to a Genesys ZU project.
Or maybe when the source files were packaged into IPs, compatibility for Kintex7 wasn't added. However, I'm pretty sure our MIPI IPs work great on Kintex7 too, we have a FMC-Pcam-Adapter demo project for the Genesys2.
What you can try is to open your Zedboard project, right-click on the IPs that are disabled elsewhere, go to Edit in IP Packager and press OK. It will open a new vivado tab, go to Compatibility and click on the "+" button and choose Add Family Explicitly....

From there you can select to add the Kintex7 (Kintex-7) family to IP compatibility, just be aware that our MIPI IPs don't work on ultrascale and ultrascale+ families.

And that should be it, also make sure to check our Genesys2 FMC-Pcam-Adapter DEMO too, it might literally be exactly what you need for your KC705 board. Here's the wiki page (don't let the un-updated photos fool you). 
 

Check out the the FMC-Pcam-Adapter/next branches of our Zedboard's hardware and software repos and go from there.
Vivado 2020.1 project: https://github.com/Digilent/ZedBoard-HW/tree/FMC-Pcam-Adapter/next
Vitis 2020.1 project: https://github.com/Digilent/ZedBoard-SW/tree/FMC-Pcam-Adapter/next

Can't help you with platformio but here's a guide on how to get our GPIO demo up and running on the Nexys A7: GPIO Demo Guide.
Also make sure to check out your board's Resource Center and its Reference Manual.
To install board files this guide, while a bit old, should work on all recent versions of Vivado. It's basically a tcl script that Vivado automatically runs at startup.

Sorry but I couldn't replicate you problems, it worked first try for me following the exact same steps as you did.
 
But I can recommend some things you can try to hopefully get the project working properly. 
First you can try resetting the output products by right-clicking the block design file and then clicking "Reset Output Products...".

Then go to Tools -> Settings... -> IP, press the Clear Cache button and then click OK.


Now go to the Design Runs tab, right-click on impl_1 and select Reset Runs. Do the same thing for synth_1 as well.

After that click on Generate Bitstream and wait a bit for a new bitstream to be completed. If somehow you get some critical warnings telling you that the MIPI_D_PHY_RX_0 IP was packaged with a different board_part you can just ignore those by pressing OK and then clicking on Generate Bitstream again.
Now you should export the new hardware handoff and launch the SDK again (if the SDK is already open you don't have to launch it again).
Right-click on system_wrapper_hw_platform_0  and select Change Hardware Platform Specification to update it to the new hardware handoff.

After that you should clean the entire workspace and then build it all again.

Finally, you can program the FPGA and run the application again.
You will hopefully see something like this in your tera term console:

Please do let us know if you've encountered other problems or if, after following all these steps, you still couldn't manage to get the application working properly.

Sorry but I couldn't replicate you problems, it worked first try for me following the exact same steps as you did.
 
But I can recommend some things you can try to hopefully get the project working properly. 
First you can try resetting the output products by right-clicking the block design file and then clicking "Reset Output Products...".

Then go to Tools -> Settings... -> IP, press the Clear Cache button and then click OK.


Now go to the Design Runs tab, right-click on impl_1 and select Reset Runs. Do the same thing for synth_1 as well.

After that click on Generate Bitstream and wait a bit for a new bitstream to be completed. If somehow you get some critical warnings telling you that the MIPI_D_PHY_RX_0 IP was packaged with a different board_part you can just ignore those by pressing OK and then clicking on Generate Bitstream again.
Now you should export the new hardware handoff and launch the SDK again (if the SDK is already open you don't have to launch it again).
Right-click on system_wrapper_hw_platform_0  and select Change Hardware Platform Specification to update it to the new hardware handoff.

After that you should clean the entire workspace and then build it all again.

Finally, you can program the FPGA and run the application again.
You will hopefully see something like this in your tera term console:

Please do let us know if you've encountered other problems or if, after following all these steps, you still couldn't manage to get the application working properly.