IMX8MQ MIPI CSI2 Base address switching change error

cancel
Showing results for 
Search instead for 
Did you mean: 

IMX8MQ MIPI CSI2 Base address switching change error

484 Views
jgsandom
Contributor II

Hi NXP community,

I've been facing an issue integrating an IMX378 image sensor with an IMX8MQ when configured for MIPI-CSI over 2 lanes at 1920x1080p @ 80fps. Note that the IMX378 provides progressive video, not interlaced. The kernel being used is linux-imx-4.14.98 and the IMX8 reference manual being referred to is Rev 3 04/2020: IMX8M Reference Manual .

Issue;

The issue seems to occur quite randomly - 50% of the time, I boot and I'm able to stream video successfully with the correct fps. If it works on first boot, then it will continue to work as I stop and start streaming again. However, the other 50% of the time, I am faced with the "Base address switching change error", which persists when attempting to stop and start streaming again. The only way to resolve this is to reboot and hope that it boots in a good state. This is extremely unreliable and I'm in need of a fix!

Attempted fixes;

I've seen that a lot of the community have faced similar issues and have tried various suggestions. See below;

  1. One suggestion by @igorpadykov  was that BASEADDR_SWITCH_EN is only applicable for interlaced video sources and it can actually be disabled. Is this true? I haven't seen anything in the documentation about this. Following from this @leolarrel suggested the following patch;

     

 

if (pix->field == V4L2_FIELD_INTERLACED)
csi_tvdec_enable(csi_dev, true);
+ else
+ csi_tvdec_enable(csi_dev, false);

 

  1. This ensures that all bits associated to BASEADDR are disabled;  (BIT_TVDECODER_IN_EN | BIT_BASEADDR_SWITCH_EN | BIT_BASEADDR_SWITCH_SEL | BIT_BASEADDR_CHG_ERR_EN). This gets rid of the base address switching error because the interrupt is no longer enabled. However, this doesn't solve the issue entirely as in an error state, there's a drop from 80fps to around 50fps and the resulting video feed has significant amounts of noise and almost seems as though multiple frames are mixed together e.g. I'm seeing incomplete frames overlaid with each other. 
  • Another suggestion is that the clocks may be configured incorrectly. I have set the MIPI core clock, MIPI PHY ref clock and MIPI ESC clock to the maximum values stated in the IMX reference manual (MIPI Core Clock: 266MHz, MIPI PHY Clock: 333MHz, MIPI ESC: 133MHz) See below; (I have also tried variations of this, such as setting the MIPI PHY clock to 250MHz and 125MHz)

 

assigned-clock-rates = <266000000>, <333000000>, <133000000>;

 

  1. Setting the above values didn't solve the base address switching issue. However, it is required to set these values to get any streaming to work at all for my data rate. i.e. setting the above clock values allowed me to stream correctly 50% of the time. 

Debug information;

I had a look at the CSI register values to see if anything stood out when starting the stream. Here is the output;

 

[   77.614214] CSI_CSICR1: 0x11f0902
[   77.617538] CSI_CSICR2: 0xc0000000
[   77.621067] CSI_CSICR3: 0x10a0
[   77.624257] CSI_STATFIFO: 0x26b026aa
[   77.627960] CSI_CSIRXFIFO: 0x211a2221
[   77.631922] CSI_CSIRXCNT: 0x9600
[   77.635266] CSI_CSISR: 0x92224001
[   77.638695] CSI_CSIDBG: 0x0
[   77.641487] CSI_CSIDMASA_STATFIFO: 0x0
[   77.645350] CSI_CSIDMATS_STATFIFO: 0x0
[   77.649214] CSI_CSIDMASA_FB1: 0xc4100000
[   77.653311] CSI_CSIDMASA_FB2: 0xc4300000
[   77.657348] CSI_CSIFBUF_PARA: 0x0
[   77.660777] CSI_CSIIMAG_PARA: 0x7800438
[   77.664787] CSI_CSICR18: 0xd44ad030
[   77.668389] CSI_CSICR19: 0x2d

 

 Here we can see that the RXFIFO does have data present, so not sure what the issue is.

I have also seen suggestions to upgrade to the latest kernel (linux-imx-5.4.47) - I had a look at the source code for the relevant IMX8MQ drivers (mx6s_capture.c and mxc-mipi-csi2_yav.c). I didn't see any significant register configuration changes so I don't think this will help.

Does anyone have any ideas on how to finally solve this issue? any help would be appreciated! Thank you.

Labels (1)
Tags (4)
0 Kudos
17 Replies

198 Views
t_spil
Contributor III

Hi jgsandom,

We're seeing the exact same issue. Roughly 50% of the time the CSI1 works and the other half it reports "base address switching Change Err.". It took awhile to figure out because we had a patch that disabled csi_tvdec_enable like you state in the your post. We're using zeus (linux 5.4.24) and a variscite board which ddr4 settings should be correct. Our sensor outputs non-interlaced RAW12 data at 640x480 over 4 lanes at the highest speed possible (960 mbps).

With the patch that disables csi_tvdec_enable, we're getting data out, but it's not correct. The mlx75027 sensor that we're using allows us to get a test pattern out, repeating every 1022 bytes. In the base address switching state, the pattern that we're getting is completely wrong, but deterministic and repeating every 1533 bytes (so 1.5x what it should be doing). In the correct state we get out 4 (phase) images in a row before triggering the next series, in the incorrect state only 3 images are being output. My current hypothesis about this is that it might be interpreting the data as RAW16 or something like that which would result in the reduced amount of images we're getting. Furthermore when the CSI1 is in the incorrect state, the overflow bug happens straightaway at 960 mbps while in the correct state we've been able to stream for several hours without running into the overflow bug.

I've not run into this issue on the development board with the ov5460 module or the basler module connected to a previous iteration of our own board, so it might have something to do with non interlaced images seeing as that's one of the few common denominators.

@igorpadykovCould you forward this additional information to the internal team and ask if they have any idea how to resolve this?

With kind regards,
Twan

147 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi Twan

 

>Could you forward this additional information to the internal team and ask if they

>have any idea how to resolve this?

 

it was already "forwarded" and ideas from internal team are provided in this thread.

May be recommended to use  https://contact.nxp.com/new-prof-svcs-sw-tech

for obtaining additional help.

 

Best regards
igor

0 Kudos

471 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi jgsandom

 

yes all 3 suggestions are "true" as they were provided from internal team.

 

>Does anyone have any ideas on how to finally solve this issue? any help would be appreciated!

 

please try latest nxp linux from source.codeaurora.org/external/imx/linux-imx repository

and provide error logs, dts file and other driver source changes for custom camera for reviewing

https://source.codeaurora.org/external/imx/linux-imx/tree/?h=imx_5.4.70_2.3.0

 

 

Best regards
igor

0 Kudos

461 Views
jgsandom
Contributor II

Hi @igorpadykov ,

I did have a look at the latest source code for imx_5.4.70_2.3.0 - to my knowledge, the source files relevant to this issue are mx6s_capture.c and mxc-mipi-csi2_yav.c. It doesn't look like there have been any changes relevant to this issue.

The changes I have made to the above files are to support RGGB8 video format, increase clock rates to support higher data rate source (1920x1080p80 over 2 lanes) and increase the max video memory to support a 4 buffers instead of 2.  See below;

DTS with clock rate changes;

 

&csi1_bridge {
	fsl,mipi-mode;
	dma-coherent; 
	status = "okay";

	port {
		csi1_ep: endpoint {
			remote-endpoint = <&csi1_mipi_ep>;
		};
	};
};

&mipi_csi_1 {
	#address-cells = <1>;
	#size-cells = <0>;

    assigned-clock-rates = <266000000>, <333000000>, <66000000>;
	
	status = "okay";
	port {
		mipi1_sensor_ep: endpoint1 {
			remote-endpoint = <&imx378_ep>;
			data-lanes = <1 2>;
		};

		csi1_mipi_ep: endpoint2 {
			remote-endpoint = <&csi1_ep>;
		};
	};
};

 

RGGB8 addition;

diff --git a/drivers/media/platform/mxc/capture/mx6s_capture.c b/drivers/media/platform/mxc/capture/mx6s_capture.c
index 4efa38fda729..8ce24079374e 100644
--- a/drivers/media/platform/mxc/capture/mx6s_capture.c
+++ b/drivers/media/platform/mxc/capture/mx6s_capture.c
@@ -273,6 +273,12 @@ static struct mx6s_fmt formats[] = {
 		.pixelformat	= V4L2_PIX_FMT_SBGGR8,
 		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
 		.bpp		= 1,
+	}, {
+		.name		= "RAWRGB8 (SRGGB8)",
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.pixelformat	= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.bpp		= 1,
 	}
 };
 
@@ -843,6 +849,7 @@ static int mx6s_configure_csi(struct mx6s_csi_dev *csi_dev)
 
 	switch (csi_dev->fmt->pixelformat) {
 	case V4L2_PIX_FMT_YUV32:
+	case V4L2_PIX_FMT_SRGGB8:
 	case V4L2_PIX_FMT_SBGGR8:
 		width = pix->width;
 		break;
@@ -874,6 +881,7 @@ static int mx6s_configure_csi(struct mx6s_csi_dev *csi_dev)
 		case V4L2_PIX_FMT_YUYV:
 			cr18 |= BIT_MIPI_DATA_FORMAT_YUV422_8B;
 			break;
+		case V4L2_PIX_FMT_SRGGB8:
 		case V4L2_PIX_FMT_SBGGR8:
 			cr18 |= BIT_MIPI_DATA_FORMAT_RAW8;
 			break;

 

4 buffers support;

 

diff --git a/drivers/media/platform/mxc/capture/mx6s_capture.c b/drivers/media/platform/mxc/capture/mx6s_capture.c
index 8ce24079374e..f1c813d56abf 100644
--- a/drivers/media/platform/mxc/capture/mx6s_capture.c
+++ b/drivers/media/platform/mxc/capture/mx6s_capture.c
@@ -57,7 +57,7 @@
 #define MX6S_CAM_VERSION "0.0.1"
 #define MX6S_CAM_DRIVER_DESCRIPTION "i.MX6S_CSI"
 
-#define MAX_VIDEO_MEM 64
+#define MAX_VIDEO_MEM 128
 
 /* reset values */
 #define CSICR1_RESET_VAL	0x40000800
0 Kudos

458 Views
igorpadykov
NXP TechSupport
NXP TechSupport

for "2 lanes" configuration may be useful to check discussion :

https://community.nxp.com/t5/i-MX-Processors/iMX8M-MIPI-CSI-4-lane-configuration/m-p/875755

 

Could you please provide full uboot and linux log files for board testing with L5.4.70_2.3.0,

this is formal requrement for escalation.

Are you using uboot/linux from  nxp source.codeaurora.org/external/imx/linux-imx repository ?

 

Best regards
igor

0 Kudos

452 Views
jgsandom
Contributor II

Hi @igorpadykov ,

Thanks for the response. I had already looked at the post you've shared and seen the option of using a single lane. The image sensor I'm using only has support for 2 or 4 lanes.

In terms of full uboot and linux log files. We're currently using U-Boot 2018.11 which is based on uboot-imx. This is a vendor specific fork from SolidRun: https://github.com/SolidRun/u-boot/tree/v2018.11-solidrun . The kernel being used is 4.14.

I understand that you're requesting for me to update to latest u-boot and kernel - L5.4.70_2.3.0. However, it will take a while to port all custom changes from the current versions to the latest.

Could you please give an indication on what was modified that's related to this issue from the versions of u-boot and kernel that I'm currently using? it will be really helpful in understanding whether the port is necessary for now or not.

I have attached boot traces for your info.

 

 

0 Kudos

450 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi jgsandom

 

>We're currently using U-Boot 2018.11 which is based on uboot-imx. This is a vendor
>specific fork from SolidRun. Could you please give an indication on what was modified

>that's related to this issue from the versions of u-boot and kernel that I'm currently using?

 

this is custom kernel supported by its developer, SolidRun. Unfortunately NXP supports

only own official NXP uboot/linux from source.codeaurora.org/external/imx/linux-imx repository.

Support for non-NXP software may be provided by NXP Professional Services:
https://contact.nxp.com/new-prof-svcs-sw-tech

 

Best regards
igor

0 Kudos

439 Views
jgsandom
Contributor II

I can use linux-imx and uboot-imx from source.codeaurora.org/external/imx/linux-imx but can you please tell me what has changed from 4.14 to 5.4.70 with regard to MIPI-CSI2 drivers?

The source code suggests not much at all has changed in this area. Can you tell me otherwise please?

I would rather find this out before committing to the port if that's ok. 

0 Kudos

410 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi jgsandom

 

I asked internaly, below answer:
---------------------

This is fifo overflow, if fifo overflow there is only reboot way to let csi work.  the work round is only preventing fifo overflow.

 

Title: MIPI CSI: Receive FIFO Overflow may lead to system hang

 

Errata Description:

When receive FIFO data in MIPI CSI can not be written to memory in time if the system is heavily loaded with DDR memory requests, overflow will happen. It may lead to illegal AHB bus access at CSI AHB master port and then causes system hang.

Note that the possibility of MIPI CSI1 overflow will be lower than MIPI CSI2. MIPI CSI1 can support 4 outstanding write transition, however MIPI CSI2 can support 2 outstanding write transition. So MIPI CSI1 will realize more memory bandwidth.

 

Errata Workaround

The recommended workaround for this erratum is to avoid MIPI CSI overflow happen. Two undocumented debug registers can be used to monitor CSI FIFO levels in real time. When FIFO reaches one threshold, disable CSI and restart CSI.

For example, create one program on M4 core to monitor CSI FIFO level and do as follows:

  1. Read the CSI FIFO debug registers: Register CSI1_CSICR19 (0x30A9_004C) for MIPI CS1 or register CSI2_CSICR19 ( 0x30B8_004C) for MIPI CSI2
  2. If  the value of register CSIx_CSICR19 is larger than 192, Set register CSI_PHY_CTL_REG (0x30A7_0104 for MIPI CS1 or 0x30B6_0104 for MIPI CSI2) as 0xff to restart CSI.
  3. Wait for 3us. Jump to step 1).

  

STEPS

STEP-BY-STEP DESCRIPTION

step 1

8MQ M4 core waiting monitor request.

step 2

Read the CSI FIFO debug register(CSIx_CSICR19) 0x30a9_004c (CS1) or 0x30b8_004c(CS2).

step 3

If the value of CSIx_CSICR19 >= 192;Set CSI_PHY_CTL_REG 0x30A7_0104(CS1) or 0x30b6_0104(CS2) = 0xff, to step1

step 4

Wait little than 3us  then to step2.

---------------------

Best regards
igor

0 Kudos

403 Views
jgsandom
Contributor II

Hi @igorpadykov ,

Thanks for the response.

If it were FIFO overflow, wouldn't we reach this condition in mx6s_csi_irq_handler;

	if (status & BIT_RFF_OR_INT) {
		dev_warn(csi_dev->dev, "%s Rx fifo overflow\n", __func__);
		if (csi_dev->soc->rx_fifo_rst)
			csi_error_recovery(csi_dev);
	}

For my issue, I haven't encountered this problem. Is it still possible that the FIFO may be overflowing?

On another note, I tried my sensor on MIPI_CSI_2 yesterday instead of MIPI_CSI_1 and it worked without any issues. Do you have any idea on why the issue occurs on MIPI_CSI_1 and NOT MIPI_CSI_2?

366 Views
igorpadykov
NXP TechSupport
NXP TechSupport

internal feedback :

-------------------------------

sometime the fifo overflow , it also will report "Base address switching change err". that case will reboot to recovery.

others , sensor mipi timing is mismatch cause the this error report, but it can be recovery without reboot.

-------------------------------

Best regards
igor

 

0 Kudos

358 Views
jgsandom
Contributor II

Hi @igorpadykov ,

Thanks for the response.

In terms of MIPI timings, this doesn't make sense to me because I have set MIPI CSI port 1 and port 2 exactly the same way. They both have the same CSI core clock, CSI phy clock and CSI esc clock.

I tried my image sensor on firstly port 1 and it worked 50% of the time, then I tried on port 2 and it worked 100% of the time.

Is there any difference between these two ports in terms of resource allocation and setup?

0 Kudos

350 Views
igorpadykov
NXP TechSupport
NXP TechSupport

>Is there any difference between these two ports in terms of resource allocation and setup?

 

-------------------------------

"When receive FIFO data in MIPI CSI can not be written to memory in time if the system is

heavily loaded with DDR memory requests, overflow will happen. It may lead to illegal AHB bus

access at CSI AHB master port and then causes system hang.

Note that the possibility of MIPI CSI1 overflow will be lower than MIPI CSI2.
MIPI CSI1 can support 4 outstanding write transition, however MIPI CSI2
can support 2 outstanding write transition.
So MIPI CSI1 will realize more memory bandwidth."

-------------------------------

 

Best regards
igor

0 Kudos

294 Views
jgsandom
Contributor II

Hi @igorpadykov ,

Just returning to this issue now.

I was wondering if incorrectly configured board files in u-boot might be the cause of this issue? especially relating to lpddr4_timing.c in u-boot. 

If the IMX8M DDR tool was not properly used, could this be a reason for the inconsistency I'm having with CSI port 1 or is this unrelated?

Thanks,

Joe 

0 Kudos

289 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi Joe 

 

>I was wondering if incorrectly configured board files in u-boot might be the cause
>of this issue? especially relating to lpddr4_timing.c in u-boot.

 

yes

 

>If the IMX8M DDR tool was not properly used, could this be a reason for
>the inconsistency I'm having with CSI port 1 or is this unrelated?

 

yes

 

Best regards
igor

0 Kudos

398 Views
igorpadykov
NXP TechSupport
NXP TechSupport

I will ask internally about this. Are you willing anything to share, may be

working patches ?

 

Best regards
igor

0 Kudos

389 Views
jgsandom
Contributor II

Thanks @igorpadykov ,

In terms of patches, it's the same as I outlined before - just that it seems to consistently work with MIPI CSI 2. MIPI CSI 1 has a 50% success rate.

I'm trying to rule out if it's actually a hardware issue with the carrier board at the moment. It doesn't seem like there is any difference in terms of routing between CSI 2 and CSI 1. If you can think of any reason in software why this might be the case then please let me know!

0 Kudos