RT1052 CSI - stuck waiting for GetFullBuffer

variable_andrew · ‎01-21-2020

We are using the CSI in our custom RT1052 board, our code is BASED on the AN12110SW, but as we don't have an LCD, our camera is monochrome, etc - it's been altered according to our hardware.

I can confirm that I'm able to now write and update CSI registers now that I'm on an RT1052 (so I'm past the issue here: RT1050 CSI Inactive )... You can see schematics in that ticket too, everything's connected...

I can now also confirm the CSI_MCLK outputs a 24MHz signal too, but I'm still stuck waiting at:

while (kStatus_Success != CAMERA_RECEIVER_GetFullBuffer(&cameraReceiver, (uint32_t *) &(csiFrameBuf[i]) )) { }‍‍‍

All other RT1052 interfaces are working fine (I2C, SPI, SDRAM 16bit at least, FlexSPI, JTAG, GPIO)...

Questions:

1.

Is anything missing from the below to kick start the CSI? - Why wouldn't I be getting any buffers?

 uint8_t isc_status;

/* Configure CSI MCLK. */
CLOCK_SetMux(kCLOCK_CsiMux, 0);
CLOCK_SetDiv(kCLOCK_CsiDiv, 0);

memset(csiFrameBuf, 0, sizeof(csiFrameBuf));


/* Configure camera device and receiver.*/
const camera_config_t cameraConfig = {
 .pixelFormat = kVIDEO_PixelFormatRGB565,//we're actually in black/white - but unused by CSI - ignoring
 .bytesPerPixel = BYTE_PER_PIXEL,
 .resolution = FSL_VIDEO_RESOLUTION(CAMERA_WIDTH, CAMERA_HEIGHT),
 .frameBufferLinePitch_Bytes = CAMERA_WIDTH * BYTE_PER_PIXEL,
 .interface = kCAMERA_InterfaceGatedClock,
 .controlFlags = CAMERA_CONTROL_FLAGS,
 .framePerSec = 30,
};
CAMERA_RECEIVER_Init(&cameraReceiver, &cameraConfig, NULL, NULL);


/* Configure the camera */
imgSensorPowerOn();
do {
  isc_status = initImgSensor(true);
} while (isc_status != 0);


/* Submit the empty frame buffers to buffer queue. */
for (uint32_t i = 0; i < CAMERA_FRAME_BUFFER_COUNT; i++) {
 CAMERA_RECEIVER_SubmitEmptyBuffer(&cameraReceiver, (uint32_t)(csiFrameBuf[i]));
}

startImgSensorStreaming();
CAMERA_RECEIVER_Start(&cameraReceiver);
 
for (uint32_t i = 0; i < CAMERA_FRAME_BUFFER_COUNT; i++) {
 /* Wait to get the full frame buffer to show. */
 while (kStatus_Success != CAMERA_RECEIVER_GetFullBuffer(&cameraReceiver, (uint32_t *) &(csiFrameBuf[i]) )) { }
}
 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

2.

Is it required to run the image sensor using CSI_MCLK, or should the CSI work just fine with the Image Sensor's PXCLK being based off a different clock?

3.

In copying the Appnote - pinmux currently sets up CSI like this (note they set up SCI for 8 data pins, but they are using 2 bytes per pixel, why isn't the camera adapter set up for 1 byte / pixel if using 8 bit parallel mode?

void BOARD_InitCSIPins(void) {
  CLOCK_EnableClock(kCLOCK_Iomuxc);           /* iomuxc clock (iomuxc_clk_enable): 0x03u */

//  IOMUXC_SetPinMux(
//      IOMUXC_GPIO_AD_B0_04_GPIO1_IO04,        /* GPIO_AD_B0_04 is configured as GPIO1_IO04 */
//      0U);                                    /* Software Input On Field: Input Path is determined by functionality */



  IOMUXC_SetPinMux(
   IOMUXC_GPIO_B1_12_CSI_PIXCLK,        /* GPIO_AD_B1_04 is configured as CSI_PIXCLK */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
   IOMUXC_GPIO_B1_15_CSI_MCLK,          /* GPIO_AD_B1_05 is configured as CSI_MCLK */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
   IOMUXC_GPIO_B1_13_CSI_VSYNC,         /* GPIO_AD_B1_06 is configured as CSI_VSYNC */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
   IOMUXC_GPIO_B1_14_CSI_HSYNC,         /* GPIO_AD_B1_07 is configured as CSI_HSYNC */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_08_CSI_DATA09,        /* GPIO_AD_B1_08 is configured as CSI_DATA09 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_09_CSI_DATA08,        /* GPIO_AD_B1_09 is configured as CSI_DATA08 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_10_CSI_DATA07,        /* GPIO_AD_B1_10 is configured as CSI_DATA07 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_11_CSI_DATA06,        /* GPIO_AD_B1_11 is configured as CSI_DATA06 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_12_CSI_DATA05,        /* GPIO_AD_B1_12 is configured as CSI_DATA05 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_13_CSI_DATA04,        /* GPIO_AD_B1_13 is configured as CSI_DATA04 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_14_CSI_DATA03,        /* GPIO_AD_B1_14 is configured as CSI_DATA03 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */
  IOMUXC_SetPinMux(
      IOMUXC_GPIO_AD_B1_15_CSI_DATA02,        /* GPIO_AD_B1_15 is configured as CSI_DATA02 */
      0U);                                    /* Software Input On Field: Input Path is determined by functionality */


}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

mvaranda · ‎09-11-2020

BTW... I also noticed the bug in fls_csi driver in supplying free buffers. My fix is a bit different than suggested but works for MIMXRT1052DVL6B.

That is not the problem for not starting the DMA and only the second buffer would get wrong address.

variable_andrew · ‎09-22-2020

Hi @mvaranda ,

In my case, I was NOT able to get it working with csi driver vsion 2.1.1, I had to revert to 2.0.0 (the version used by the appnote) in order to get this working.

I'd recommend testing w/ the appnote software out of the box / not using the latest SDK drivers to check if that works for you.

I'm not sure if they've updated the AN since this post, or updated the CSI drivers again. If so, it would be great if NXP provided an updated AN software demo showing how it's done w/ the latest. Not sure how to request this or raise the priority on the work...

jeremyzhou · ‎01-22-2020

Hi ,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Is anything missing from the below to kick start the CSI? - Why wouldn't I be getting any buffers?
-- Firstly, I don't find something wrong in your code actually, however, regarding your issue, I'd like to suggest that you check whether submit the buffer area by calling the below codes.
/* Submit the empty frame buffers to buffer queue. */
for (uint32_t i = 0; i < CAMERA_FRAME_BUFFER_COUNT; i++) {
CAMERA_RECEIVER_SubmitEmptyBuffer(&cameraReceiver, (uint32_t)(csiFrameBuf[i]));
}
2) Is it required to run the image sensor using CSI_MCLK, or should the CSI work just fine with the Image Sensor's PXCLK being based on a different clock?
--The camera sensor needs input external clock, and in general, the sensor supports to configure the PXCLK.
3) In copying the Appnote - pinmux currently sets up CSI like this (note they set up SCI for 8 data pins, but they are using 2 bytes per pixel, why isn't the camera adapter set up for 1 byte / pixel if using 8 bit parallel mode?
-- The pixel format is RGB565.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

variable_andrew · ‎01-23-2020

Hi jeremyzhou‌ ,

1:

Thanks for your hint - it appears there is a bug in the latest SDK for CSI:

In the latest fsl_csi.c (fsl csi driver vsion 2.1.1), handle->frameBufferQueue doesn't get assigned in submit empty buffers.

If I revert to the fsl_csi.c used by AN12110 (driver version 2.0.0) - CSI works and I get buffers back from the CSI.

In version 2.0.0 - CSI_TransferSubmitEmptyBuffer assigns the handle->frameBufferQueue to the empty buffer.

This has been removed (and not replaced) in the v 2.1.1 from what I can see.

Can you confirm this is an issue or how code needs to be changed to work with the latest version of the CSI drivers?

I'll continue on with fsl_csi v2.0.0 for the time being, but I think it's best to be running w/ the latest drivers...

2 & 3: OK - thanks

jeremyzhou · ‎01-26-2020

Hi ,

Thanks for your reply.
1) Can you confirm this is an issue or how code needs to be changed to work with the latest version of the CSI drivers?
-- Firstly, I don't see an issue report about the latest_csi driver, so I basically don't believe there're something bugs in the latest_csi driver, The Fig1 log the evolution of CSI driver and it can help you to adjust the code. Now it’s time to get our hands dirty with the code.

Fig 1

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

variable_andrew · ‎02-03-2020

Hi jeremyzhou‌,

Maybe there needs to be an issue report for this if there isn't one yet?

As noted above, the CSI demo runs so long as I revert the fsl_csi drivers to version 2.0.0, and the reason it doesn't seem to work on 2.1.1 is that handle->frameBufferQueue isn't getting assigned in the newer revision.

I've looked as the file history you posted - and that doesn't provide anything helpful related to the frameBufferQueue assignment missing in the newer versions. I have gone through the code checking for this, and this is what I see missing.

Have you tested the CSI Camera demo w/ the latest drivers?

I'm currently running fine in 8-bit mode on the SDK2.0.0 fsl_csi driver, but I need 16 bit mode. Hacking around to get this working hasn't been ideal, so I was hoping there might be an update including buffer assignment.

jeremyzhou · ‎02-04-2020

Hi ,

Thanks for your reply.
After comparing the fsl_csi driver of version 2.0.0 and 2.1.1, I find that the difference is a bit big(as below shows).

So I'll suggest you continue the version 2.0.0 at currently, as it's dirty work to adjust the fsl_csi driver of the version 2.1.1 to replace the version 2.0.0.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

variable_andrew · ‎01-22-2020

One further follow-up, if I set a breakpoint on the check for GetFullBuffer, and monitor the CSI, I'm seeing that

CSICR3 frame count is increasing - so I don't understand why I wouldn't be getting FrameBufferFull from the SDK?

I can confirm that CSICR1 has interrupt enable for both CSI FB1 and FB2.

Here is what the registers look like:

and another note is - unlike some cameras that do a pulse for the start of VSYNC and a pulse for the end, the AR0130 we're using keeps VSYNC (frame valid) asserted for the full frame, like the 3rd line below (1st line is CSI_MCLK, 2nd is PXCLK, 3rd is VSYNC, 4th is HSYNC, then data):

mvaranda · ‎09-11-2020

I have similar issue as described.

DMA works for EVK with MIMXRT1052DVL6B
But it does not work with my target with MIMXRT1052CVJ5B

Did you find a solution?

Thanks,
MV

RT1052 CSI - stuck waiting for GetFullBuffer

RT1052 CSI - stuck waiting for GetFullBuffer

i.MXRT 105x