Fixing 'base address switching Change Err' which occurs randomly

cancel
Showing results for 
Search instead for 
Did you mean: 

Fixing 'base address switching Change Err' which occurs randomly

2,084 Views
Contributor III

Hi,

We are trying to add support for a new MIPI camera in the NXP i.MX 8M. It is a YUV camera. We are using the L4.14.78_1.0.0_MX8MQ BSP. We are getting 'base address switching Change Err' randomly when trying to stream. We made sure that the sensor side configuration was correct by evaluating the settings and clocks on a different platform. The we tried changing the MIPI receiver clock in the platform side i.e., the 'assigned-clock-rates' property in the following device tree entry. The device tree file is 'fsl-imx8mq.dtsi'.

    mipi_csi_1: mipi_csi1@30a70000 {
        compatible = "fsl,mxc-mipi-csi2_yav";
        reg = <0x0 0x30a70000 0x0 0x1000>; /* MIPI CSI1 Controller base addr */
        interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
        clocks = <&clk IMX8MQ_CLK_DUMMY>,
                <&clk IMX8MQ_CLK_CSI1_CORE>,
                <&clk IMX8MQ_CLK_CSI1_ESC>,
                <&clk IMX8MQ_CLK_CSI1_PHY_REF>;
        clock-names = "clk_apb", "clk_core", "clk_esc", "clk_pxl";
        assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
                  <&clk IMX8MQ_CLK_CSI1_PHY_REF>,
                  <&clk IMX8MQ_CLK_CSI1_ESC>;
        assigned-clock-rates = <133000000>, <100000000>, <66000000>;
        power-domains = <&mipi_csi1_pd>;
        csis-phy-reset = <&src 0x4c 7>;
        phy-gpr = <&gpr 0x88>;
        status = "disabled";
    };

When changing the values to the following:

        assigned-clock-rates = <266000000>, <400000000>, <66000000>;

We are successfully able to stream all the resolutions at the expected frame rates. However, the camera doesn't work at random times and we get the 'base address switching Change Err' when it doesn't work. The only way to fix this issue is to reboot the board (once or sometimes multiple times). Then it would work normally and we get uninterrupted streaming as usual. This indicated that the values we've configured for the platform side clock might be the problem. We tried to fix this issue which occurs at random times by reducing the platform side clock and correspondingly the sensor's MIPI clock too. We decreased platform side clocks to the following value:

        assigned-clock-rates = <266000000>, <150000000>, <66000000>;

Now we are able to avoid the 'base address switching Change Err' issue that occurs at random times but couldn't achieve the expected frame rates as we have also reduced the sensor side MIPI clocks. It would we nice if someone could shed some light on how to correctly program the platform side clocks which seems to be the key to adding support for our camera? We believe that the sensor side configuration and clocks are correct as we have tested it in a different platform.


To summarize,

1. In what scenarios does one face the 'base address switching Change Err'?

2. How to correctly program the values for the 'assigned-clock-rates' property in the device tree for any MIPI CSI2 sensor?

3. Are we missing something here?

4. For previous generation processors i.e, i.MX6, there's a document which describes in detail on how to configure the host for different sensors. It would be great if such a document was made available for i.MX 8M as well.

Thanks,

Sivaraam

24 Replies

56 Views
Contributor I

I facing same problem with IMX8 Mini, kernel 4.14.98-2.0.0-ga, OV5645, fswebcam app.

I hack the csi bridge driver mx6s_capture.c , fix code below to fix "Base address switching Change Err." message success and can take picture finally :

@@ -756,6 +756,8 @@ static int mx6s_csi_enable(struct mx6s_csi_dev *csi_dev)

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

csi_tvdec_enable() will controll the BIT_BASEADDR_SWITCH_EN,BIT_BASEADDR_SWITCH_SEL,BIT_BASEADDR_CHG_ERR_EN bit at CR18 register.

56 Views
Contributor I

This modify doesn't helps in my case... Is this a silicon bug?

0 Kudos

56 Views
Contributor II

Thanks Leo, this fixed the driver for me.

0 Kudos

56 Views
Contributor III

Hi Sivaraam,

could you finally find a solution for your 'base address switching Change Err'  problem?

regards,

Steven

0 Kudos

63 Views
NXP Employee
NXP Employee

Hi Sivaraam:

The csi1/2 core_clk only for capture the MIPI transfer data from link, so this clock should >= bandwidth of each lane/8, for example if each lane is 1.5Gbps, this clock should be 1.5G/8=187.5MHz So 200MHz is enough for 8MQ. 

The csi1/2 phy_ref_clk is for MIPI_CSI controller user interface and CSI bridge pixel clock, so this clock should as fast as best, you can configure to 333MHz which is sign-off target frequency on 8MQ.

We have tried 1680x1050 60FPS YUV  & 1920x1080  30FPS Bayer CSI input source/format, they both worked well on 8MQ, no frames drop happen. 

 For 'base address switching Change Err'? error,  We have seen this during two cases:

1:  CSI DMA can't transfer data from CSI FIFO to DDR RAM in time,   for this case, please confirm you used latest SDK & latest DDR RPA tools, some intermediate version RAP tools set DDR parameter wrongly. 

2: CSI data format is configured wrongly. 

 

57 Views
Contributor III

您好! 我也遇到了这个问题,不过是mx6s_csi_irq_handler Rx fifo overflow和base address switching Change Err交替出现,我用的atf和uboot都是4.14.98的,不过操作系统不是linux和android,csi的驱动是从linux移植过来的。

不知道您是否有什么建议?

0 Kudos

63 Views
Contributor III

Hi gogoer‌,

Thanks for your helpful response. We set the clock values to the suggested one:

       assigned-clock-rates = <200000000>, <333000000>, <66000000>;

Unfortunately, we are still facing the "base address switching Change Err" error we faced before. We ensured that we are using the latest SDK and the DDR parameters are set correctly in u-boot. We have also made sure that the CSI data format is configured correctly as we are able to stream successfully at random times (rebooting fixes the issue). At other times we get the "base address switching Change Err" error. Could you help us achieve stable streaming?

Thanks,

Sivaraam

0 Kudos

63 Views
NXP Employee
NXP Employee

Hi Kaartic:

If you have used the latest SDK 4.14.98 include  ATF & uboot & Kernel, so far there is no good way to solve this issue from my side. 

0 Kudos

63 Views
Contributor I

Hi Tom,

I am also facing the exact same issue(base address switching error) frequently. I am using the latest kernel 4.14.98. I flashed my sd card using the default SD card image provided by NXP(L4.14.98_2.0.0_MX8MQ ). 

As you mentioned, the latest ATF,uboot & kernel is included in this SD card image or not? If not, Where i get the latest ATF and u-boot images?

0 Kudos

63 Views
NXP Employee
NXP Employee

Hi Mano:

If SD image flashed, the latest AFT, uboot kernel all are included. 

What board you used ? EVK ? How about the camera ov5640 ? 

0 Kudos

63 Views
Contributor I

Hi Tom,

Yes, I am using EVK(Version-B4) board only. In OV5640 operates a very low mipi clock so we can not see this issue. but in  our sensor we used higher clock rate for 1080@60fps. so in our case we faced the BASE_ADDRESS_SWITCH_ERROR very frequently.

Thanks

Vimal.

0 Kudos

63 Views
NXP Employee
NXP Employee

Hi Vimal:

On 850 , what we have tried  high mipi clock is 1680x1050x60 argb format.  so far no " BASE_ADDRESS_SWITCH_ERROR"  happen. 

0 Kudos

63 Views
Contributor I

Hi Tom,

After the long struggle finally we have somewhat stable system. but still we faced the "Base address switching error" for few seconds while starting the application and then it recovers and streams perfectly. Even this issue also occurs very randomly with some power cycles. but its very critical for our project. 

I summarized  my issue below,

For example:

1. In the first power cycle, if the camera streams correctly it works fine with every application open and close.

2. in the X power cycle, if the camera starts with "Base Address Switching Error" for few seconds then it recovers and stream. in this case, the  "Base Address Switching Error" occurs for few seconds with every application open until i reboot the device.

Please help me to solve this issue.

Thanks

Vimal.

0 Kudos

63 Views
Contributor II

Hi All,

     I am meeting the same critical problem. Our product connects a Nextchip N4 to one MIPI-CSI2 port1, Nextchip N4 is converter from a AHD camera to mipi-csi2, support 4 channels, but I just used two channels for user switch camera, , same resolution 1920x1080@30 on both, due to i.mx8mq does not support virtual channels on MIPI CSI, so cannot make it work at the same time, so badly.

    The issue is : after system reboot, both channel1 or channel2 is working well with i.mx8mq mipi after system reboot, but when i switched N4 channel1 to channel2 without reboot imx8mq, MIPI-CSI2 then entered a crazy mode, always report "base address switching Change Err." and "crc error" on bit0:

MIPI CSI2 HC IRQ STATUS       0x10C = 0x9

     when do gst-launch-1.0 v4l2src again, it did "csihw_reset","csisw_reset","mxc_mipi_csi2_phy_reset", and I reset N4 also, but all ways could not recover MIPI CS2 to work, have to reboot boards. I am sure N4 side no problem. Any suggestion are welcome, thanks.

In addition, there are two hiden registers on i.mx8mq, but there is explaintion on imx8quadXplus reference manual, but i still cannot understand how to set it to allow channel2 pass, and ignore channel1. 

writel(1, csi2dev->base_regs + 0x180); //IGNORE_VC      only bit[0]?  1: ignore,  0: accept the channels that VID_VC set?
/* vid_vc */
writel(1, csi2dev->base_regs + 0x184); //VID_VC,    if enable channel2, write it to 2?

0 Kudos

63 Views
NXP Employee
NXP Employee

Weide:

We confirm 850D /8MQ not support virtual channel .  

For your case , please change to channel 2 on N4 firstly. then reboot the boot, check CSI whether OK. 

0 Kudos

63 Views
Contributor II

I tried put channel2 as first after reboot, same problem as before.  I found if there are different mipi's VC number arrives to mipi-csi, it will go crazy. I tried to use "cr &= ~BIT_BASEADDR_SWITCH_EN" to not use that DMA auto switch, but image is mixed with channel1 and old channel2 picture. it seems the rx fifo still is keeping old something.

In addition, found other issue,  2 lanes can work for one camera, but 4 lanes does not work at I.MX8MQ.  reference design used 2 lanes for ov5640, so I suspect NXP did not test 4 lanes before.

0 Kudos

63 Views
NXP Employee
NXP Employee

We did verify 4 lanes on other MIPI CSI module for 8MQ, it worked well. 

-> I tried put channel2 as first after reboot, same problem as before. 

As you said, there is something wrong on N4 channel 2. 

 

0 Kudos

63 Views
Contributor II

I can gurantee N4 channel 2 does have problem.  when i used channel2, did not do switch,  it could work well after system reboot.

0 Kudos

63 Views
Contributor II

Hi Tom,

    do you know how set below registers I mentioned before:

writel(1, csi2dev->base_regs + 0x180); //IGNORE_VC      only bit[0]?  1: ignore,  0: accept the channels that VID_VC set?
/* vid_vc */
writel(1, csi2dev->base_regs + 0x184); //VID_VC,    if enable channel2, write it to 2?

Thanks a lot!

0 Kudos

63 Views
Contributor II

What is the mipi-cs2 data format/sequence for 4 lanes? is there doc to explain it? below is from N4.

pastedImage_1.png

0 Kudos