cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
643 Views
Registered: ‎07-16-2019

MIPI CSI-2 Rx - Migrating from 2019.1.1 to 2020.1

Jump to solution

Hi,

I have a duallane CSI Rx setup on an Ultrascale with Vivado 2019.1.1. I can succesfully receive frames from the camera via CSI and VDMA. I did now the migration to 2020.1 because of the free license following the forum's Step-By-Step-Guide without any issues or critical warnings. 

Because I can't verify the setup now with a camera, I only check the CSI and DPHY registers after initalization using following code:

 

ConfigPtr = XCsiSs_LookupConfig(XPAR_CSISS_0_DEVICE_ID);
XCsiSs_CfgInitialize(&g_oCsi, ConfigPtr, ConfigPtr->BaseAddr);
XCsiSs_SelfTest(&g_oCsi);
XCsiSs_ReportCoreInfo(&g_oCsi);
XCsiSs_Reset(&g_oCsi);
XCsiSs_Activate(&g_oCsi, XCSI_DISABLE);
int iActiveLanes = 2;
XCsiSs_Configure(&g_oCsi, iActiveLanes, XCSISS_ISR_ALLINTR_MASK);
XCsiSs_Activate(&g_oCsi, XCSI_ENABLE);

 

 

With 2019.1.1, I get following, which is then working with camera:

 

Core Configuration Register : 0x1
Protocol Configuration Register : 0x9
Core Status Register : 0x0
Global Interrupt Register : 0x0
Interrupt Status Register : 0x20000
Interrupt Enable Register : 0x0
Generic Short Packet Register : 0x0
VCx Frame Error Register : 0x0
Clock Lane Info Register : 0x2
Lane 0 Info Register : 0x20
Lane 1 Info Register : 0x20
Lane 2 Info Register : 0x0
Lane 3 Info Register : 0x0
Control Register : 0x2
IDelay Tap per lane for Rx Register: 0x0
Initialization Timer Register : 0x186a0
Wakeup Timer for ULPS exit Register : 0x0
Watchdog timeout in HS mode Register : 0x0
Goto Stop state on timeout timer Register : 0x0
Clk lane PHY error Status Register : 0x18
Data lane 0 PHY error Status Register : 0x48
Data lane 1 PHY error Status Register : 0x48
Data lane 2 PHY error Status Register : 0x8
Data lane 3 PHY error Status Register : 0x8
HS Settle Register L0: 0x91
IDelay Tap per lane for Rx 4-7 Register: 0x0

 

 

With 2020.1: it looks like the core is always in reset:

 

Core Configuration Register : 0x3
Protocol Configuration Register : 0x9
Core Status Register : 0x0
Global Interrupt Register : 0x1
Interrupt Status Register : 0x0
Interrupt Enable Register : 0x0
Generic Short Packet Register : 0x0
VCx Frame Error Register : 0x0
Clock Lane Info Register : 0x0
Lane 0 Info Register : 0x0
Lane 1 Info Register : 0x0
Lane 2 Info Register : 0x0
Lane 3 Info Register : 0x0
Control Register : 0x2
IDelay Tap per lane for Rx Register: 0x0
Initialization Timer Register : 0x186a0
Wakeup Timer for ULPS exit Register : 0x0
Watchdog timeout in HS mode Register : 0x0
Goto Stop state on timeout timer Register : 0x0
Clk lane PHY error Status Register : 0x8
Data lane 0 PHY error Status Register : 0x8
Data lane 1 PHY error Status Register : 0x8
Data lane 2 PHY error Status Register : 0x8
Data lane 3 PHY error Status Register : 0x8
HS Settle Register L0: 0x91
IDelay Tap per lane for Rx 4-7 Register: 0x0

 

 

If I remove the two XCsiSs_Activate calls, the core is not in reset anymore but the lanes are not in stop state:

 

Core Configuration Register : 0x1
Protocol Configuration Register : 0x9
Core Status Register : 0x0
Global Interrupt Register : 0x0
Interrupt Status Register : 0x0
Interrupt Enable Register : 0x0
Generic Short Packet Register : 0x0
VCx Frame Error Register : 0x0
Clock Lane Info Register : 0x0
Lane 0 Info Register : 0x0
Lane 1 Info Register : 0x0
Lane 2 Info Register : 0x0
Lane 3 Info Register : 0x0
Control Register : 0x2
IDelay Tap per lane for Rx Register: 0x0
Initialization Timer Register : 0x186a0
Wakeup Timer for ULPS exit Register : 0x0
Watchdog timeout in HS mode Register : 0x0
Goto Stop state on timeout timer Register : 0x0
Clk lane PHY error Status Register : 0x8
Data lane 0 PHY error Status Register : 0x8
Data lane 1 PHY error Status Register : 0x8
Data lane 2 PHY error Status Register : 0x8
Data lane 3 PHY error Status Register : 0x8
HS Settle Register L0: 0x91
IDelay Tap per lane for Rx 4-7 Register: 0x0

 

 

Has been something changed for programming from CSI Rx 4.0 to 5.0?

 

PS: At reading out the DPHY registers, I recognized following: according to PG232, the DPHY registers have the offset of 0x10000 for CsiRx 4.0 and 0x1000 for CsiRx 5.0. But to get the above data for v5.0, I also need to read out with 0x10000 for 2020.1 to get the above logs.

 

Thanks and regards

0 Kudos
Reply
1 Solution

Accepted Solutions
Observer
Observer
289 Views
Registered: ‎07-16-2019

Hi @florentw @karnanl 

after the answer of last week, I continued to debug this issue. I checked the new created HW design (with a new instance of CSI-Rx) and it was working. Then I also tried again the last two non-working HW designs from my prevoius posts and these were suddenly working.

I unintentional changed the debugging setup (XU5+baseboard on desk) two weeks ago:
I changed now to a slighlty different FPGA module (different pinout but same chip XCZU4EV-1SFVC784I) and there I got during downloading of the debug configuration following error: Exit breakpoint of FSBL not hit. I found here the solution https://forums.xilinx.com/t5/Embedded-Development-Tools/Vitis-error-Exit-breakpoint-of-FSBL-not-hit/td-p/1149300.
So, this potential workaround is used now: use psu_init for target initialization instead of FSBL.

I checked then why the HW designs are suddenly working and it's not the different modules but the debug configuration. If the FSBL init is used this faulty CSI registers are happening. If the psu_init is used like for 2019.1, it is working. I created then the boot image with CSI register print outs, to see if the FSBL has an issue but also there the CSI init and registers are ok.

I guess that the HW designs were always ok but because I only printed the CSI registers with a debug configuration, the issue was visible.

Do you have any ideas on that? I will get the camera this week to check the full setup and will see if this topic can be closed.

Thanks and regards

View solution in original post

0 Kudos
Reply
11 Replies
Xilinx Employee
Xilinx Employee
584 Views
Registered: ‎03-30-2016

Hello @chehre1 

Yes, MIPI CSI-2 RX register space is different between ver4.1 and ver5.0 as mentioned by PG232.

Register_space_is_different.png

So, Step-by-step guide will not work in this case, since your software code is for 2020.1 , while your design is still ver4.1.
I would suggest to regenerate the block-design in Vivado 2020.1 in this case.



Thanks & regards
Leo

Observer
Observer
569 Views
Registered: ‎07-16-2019

Hi @karnanl 

when I was migrating the HW design to 2020.1, I had to update also all IPs in the "Report IP Status" view. So, the CSI Rx core is for sure 5.0. 

I didn't update the initalization code for the CSI, see first post, because in the Vits 2020.1 mipicsiss_v1_3 driver example is no difference compared to the SDK 2019.1 mipicsiss_v1_2. For my CSI/DPHY register read out function, I updated also the register space offset for DPHY but this is the strange thing that I read out for the v5.0 only valid values with the v4.0 register offset.

So, I don't understand your suggestion why the step-by-step guide is not working. As I said, the block-design was regenerated in 2020.1

But the main point is why the CSI registers are not correctly set as in 2020.1.

Thanks and regards

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
553 Views
Registered: ‎03-30-2016

Hello @chehre1 

This is an unexpected result. Perhaps MIPI CSI-2 RX IP is not updated correctly.
Could you please share your Address Editor and Address Path Properties screen shot ?

Is it something like this ?
Unexpected_reg_address_for_mipi_csi-2_rx.png


Regards
Leo

0 Kudos
Reply
Observer
Observer
379 Views
Registered: ‎07-16-2019

Hi @karnanl 

thanks for the hint. I observed that in the address editor, there are completely the same addresses for 2019.1 and 2020.1 but in PG232 it is written the address space size for CsiRx 5.0 (2020.1) has changed form 128K to 8K. So, I reassigned all addresses (but then nearly every address looks quite different) and built the HW design. If I run this HW design with my SW in Vitis, the VDMA and image processor core are not working anymore and the CSI/DPHY registers are quite strange. So, I think there is maybe some mess with the S_AXI interfaces or the addresses but I don't know what I can change there.

Hint: I rebuilt the Vitis workspace from scratch out of the HW design. So, the addresses in the xparameters.h  are fitting to the address editor.

Address Editor 2019.1 (working):

addressEditor2019.1.PNG

 

 Address Editor after migration to 2020.1:

addressEditor2020.1.PNG

 

 Address Editor in 2020.1 after unassigning and auto assigning all addresses:

addressEditor2020.1_reassigned.PNG

 

Dump of CSI and DPHY registers:

 

 

Core Configuration Register : 0x10001
Protocol Configuration Register : 0x10000
Core Status Register : 0x0
Global Interrupt Register : 0x0
Interrupt Status Register : 0x0
Interrupt Enable Register : 0x0
Generic Short Packet Register : 0x10002
VCx Frame Error Register : 0x10001
Clock Lane Info Register : 0x0
Lane 0 Info Register : 0x0
Lane 1 Info Register : 0x0
Lane 2 Info Register : 0x0
Lane 3 Info Register : 0x0
Control Register : 0x0
IDelay Tap per lane for Rx Register: 0x0
Initialization Timer Register : 0x0
Wakeup Timer for ULPS exit Register : 0x0
Watchdog timeout in HS mode Register : 0x0
Goto Stop state on timeout timer Register : 0x0
Clk lane PHY error Status Register : 0x0
Data lane 0 PHY error Status Register : 0x0
Data lane 1 PHY error Status Register : 0x0
Data lane 2 PHY error Status Register : 0x0
Data lane 3 PHY error Status Register : 0x0
HS Settle Register L0: 0x10002
IDelay Tap per lane for Rx 4-7 Register: 0x10001

 

 

 

Thanks and regards.

0 Kudos
Reply
Observer
Observer
394 Views
Registered: ‎07-16-2019

Hi @karnanl

I checked the addresses in the address editor and they are completely the same as for 2019.1 which is not correct because the address space for CSI Rx core decreased to 8k (before: 128k).

So, reassigned all addresses and built the HW design and checked the software: the CSI registers are looking even more strange, see below. In addtion, also my other IPs where I use AXI slaves, e.g. VDMA, image processor (own IP) are not working anymore. I guess that there is something messed up with the addresses or AXI Smart Connect.

I added here two schreenshots of 2019.1 vs 2020.1 to see the differences. I don't understand why the reassignment created such different addresses for 2020.1.

Address Editor 2019.1:

addressEditor2019.1.PNG

 Address Editor 2020 reassigned:

addressEditor2020.1_reassigned.PNG

 

CSI/DPHY registers:

Core Configuration Register : 0x10001
Protocol Configuration Register : 0x10000
Core Status Register : 0x0
Global Interrupt Register : 0x0
Interrupt Status Register : 0x0
Interrupt Enable Register : 0x0
Generic Short Packet Register : 0x10002
VCx Frame Error Register : 0x10001
Clock Lane Info Register : 0x0
Lane 0 Info Register : 0x0
Lane 1 Info Register : 0x0
Lane 2 Info Register : 0x0
Lane 3 Info Register : 0x0
Control Register : 0x0
IDelay Tap per lane for Rx Register: 0x0
Initialization Timer Register : 0x0
Wakeup Timer for ULPS exit Register : 0x0
Watchdog timeout in HS mode Register : 0x0
Goto Stop state on timeout timer Register : 0x0
Clk lane PHY error Status Register : 0x0
Data lane 0 PHY error Status Register : 0x0
Data lane 1 PHY error Status Register : 0x0
Data lane 2 PHY error Status Register : 0x0
Data lane 3 PHY error Status Register : 0x0
HS Settle Register L0: 0x10002
IDelay Tap per lane for Rx 4-7 Register: 0x10001


Thanks and regards

0 Kudos
Reply
Observer
Observer
460 Views
Registered: ‎07-16-2019

Hi @karnanl

I checked the addresses in the address editor and they are completely the same as for 2019.1 which is not correct because the address space for CSI Rx core decreased to 8k (before: 128k).

So, reassigned all addresses and built the HW design and checked the software: the CSI registers are looking even more strange. In addtion, also my other IPs where I use AXI slaves, e.g. VDMA, image processor (own IP) are not working anymore. I guess that there is something messed up with the addresses or AXI Smart Connect.

I added here two schreenshots of 2019.1 vs 2020.1 to see the differences. I don't understand why the reassignment created such different addresses for 2020.1.

Thanks

0 Kudos
Reply
Observer
Observer
451 Views
Registered: ‎07-16-2019

Attachements

addressEditor2019.1.PNG
addressEditor2020.1_reassigned.PNG
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
375 Views
Registered: ‎03-30-2016

Hello @chehre1 

I believe this issue is not related with MIPI IPs, so I don't have a quick answer for you.

This question is related more to Vivado IPI.
I will need to ask around to provide you guidance on this.

Thanks & regards
Leo

0 Kudos
Reply
Moderator
Moderator
321 Views
Registered: ‎11-09-2015

HI @karnanl 

Could you try to fix this the hard way: remove the MIPI CSI2-RX Subsystem  IP and add a new one?

There are complexity coming from the MIPI CSI2-RX Subsystem IP. The "Subsystem" word means that this is an IP composed of multiple IPs. This is basically a Block design inside the block design.

So it might be that the addresses inside the IP are not correctly updated. But I would expect that adding a new instance might solve this.


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
Observer
Observer
290 Views
Registered: ‎07-16-2019

Hi @florentw @karnanl 

after the answer of last week, I continued to debug this issue. I checked the new created HW design (with a new instance of CSI-Rx) and it was working. Then I also tried again the last two non-working HW designs from my prevoius posts and these were suddenly working.

I unintentional changed the debugging setup (XU5+baseboard on desk) two weeks ago:
I changed now to a slighlty different FPGA module (different pinout but same chip XCZU4EV-1SFVC784I) and there I got during downloading of the debug configuration following error: Exit breakpoint of FSBL not hit. I found here the solution https://forums.xilinx.com/t5/Embedded-Development-Tools/Vitis-error-Exit-breakpoint-of-FSBL-not-hit/td-p/1149300.
So, this potential workaround is used now: use psu_init for target initialization instead of FSBL.

I checked then why the HW designs are suddenly working and it's not the different modules but the debug configuration. If the FSBL init is used this faulty CSI registers are happening. If the psu_init is used like for 2019.1, it is working. I created then the boot image with CSI register print outs, to see if the FSBL has an issue but also there the CSI init and registers are ok.

I guess that the HW designs were always ok but because I only printed the CSI registers with a debug configuration, the issue was visible.

Do you have any ideas on that? I will get the camera this week to check the full setup and will see if this topic can be closed.

Thanks and regards

View solution in original post

0 Kudos
Reply
Moderator
Moderator
245 Views
Registered: ‎11-09-2015

HI @chehre1 

No I do not have much idea. I would suggest you ask on the embedded tools board for why you see differences between fsbl and psu_init. I would not expect it


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**