Porting the Arduino camera and display ecosytem to Zephyr

[josuah]

The Arduino hardware ecosystem supports cameras modules such as those sold by Arducam as well as others from 3rd-party.

These cameras can be used on Zephyr, including using the ArduinoCore-Zephyr.

This is thread is there to aggregate all progress and information useful to get Arduino camera working again on Arduino Sketches on top of the Zephyr core.

Related issues:

• drivers: video: video_stm32_dcmi: Detect and recover from: HAL_DCMI_ErrorCallback #92354
• Improve the ov5640 video driver to provide parallel interface (DVP) support. #74353

[mjs513]

@CharlesDias = @KurtE
Since we are keeping this together now on the OV5640 I measured both xclk and pixclk per #92354 (comment) both seem to be running at 12.5 mhz - not pwm setting is 12mhz. So close

PIXCLK

XLCK

[mjs513]

@KurtE

I update the overlay and made the changes you suggested in post #74353 (comment) but using still no luck in getting a descent image to the ST7796 using your library.

[mjs513]

@josuah - @KurtE

Since you made this thread decided to run through the cameras I have using the giga and the giga display shield.

Running the OV7670 at 12 mhz it runs for quite a bit (~5mins) at 320x240 and then I see several

 <wrn> input: Event dropped, queue full, not blocking in syswq

and eventually a Bus fault occurs ( imprecise data bus error) and I see this at the end

[00:06:01.988,000] <err> os: Faulting instruction address (r15/pc): 0x08065310
[00:06:01.996,000] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
[00:06:02.004,000] <err> os: Fault during interrupt handling

[00:06:02.010,000] <err> os: Current thread: 0x24003610 (sysworkq)
[00:06:02.017,000] <err> os: Halting system

Not sure where or why yet but going to try the 2640 next to see if I get the same thing.

NOTE: to get the display working @KurtE and I developed custom libraries to support graphics on the giga display:
https://github.com/mjs513/Arduino_GigaDisplay_GFX/tree/Arduino_GigaDisplay_GFX_zephyr
and
https://github.com/mjs513/Arduino_GigaDisplay/tree/Arduino_GigaDisplay_Zephyr

so we can run the following sketch to test the cameras

#include <elapsedMillis.h>

#include "Arduino_GigaDisplay_GFX.h"
#define GC9A01A_CYAN 0x07FF
#define GC9A01A_RED 0xf800
#define GC9A01A_BLUE 0x001F
#define GC9A01A_GREEN 0x07E0
#define GC9A01A_MAGENTA 0xF81F
#define GC9A01A_WHITE 0xffff
#define GC9A01A_BLACK 0x0000
#define GC9A01A_YELLOW 0xFFE0
#define ALIGN_PTR(p, a) ((p & (a - 1)) ? (((uintptr_t)p + a) & ~(uintptr_t)(a - 1)) : p)

#define CANVAS_ROTATION 0
uint16_t color565(uint8_t r, uint8_t g, uint8_t b) {
  return ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3);
}

#define CAMERA_WIDTH 320
#define CAMERA_HEIGHT 240
#define SCALE 2

#include <camera.h>
 
Camera cam;

// The buffer used to capture the frame
FrameBuffer fb;

#ifdef ROTATE_CAMERA_IMAGE
uint16_t *rotate_buffer = nullptr;
#endif


// The buffer used to rotate and resize the frame
GigaDisplay_GFX display;

void blinkLED(uint32_t count = 0xFFFFFFFF) {
  pinMode(LED_BUILTIN, OUTPUT);
  while (count--) {
    digitalWrite(LED_BUILTIN, LOW);   // turn the LED on (HIGH is the voltage level)
    delay(50);                        // wait for a second
    digitalWrite(LED_BUILTIN, HIGH);  // turn the LED off by making the voltage LOW
    delay(50);                        // wait for a second
  }
}

void fatal_error(const char *msg) {
  Serial.println(msg);
  pinMode(LED_BUILTIN, OUTPUT);
  while (1) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(100);
    digitalWrite(LED_BUILTIN, LOW);
    delay(100);
  }
}



void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  while (!Serial && millis() < 5000) {}
  Serial.begin(115200);

  // Init the cam QVGA, 30FPS
  Serial.println("Before camera start");
  Serial.flush();
  //cam.debug(Serial);
  if (!cam.begin(CAMERA_WIDTH, CAMERA_HEIGHT, CAMERA_RGB565, true)) {
    fatal_error("Camera begin failed");
  }
  //Serial.println("Before setRotation");
  //Serial.flush();

  display.begin();
  elapsedMicros em;
  display.setRotation(1);
  display.fillScreen(GC9A01A_BLUE);
  Serial.println(em, DEC);
  Serial.print("Camera Width: "); Serial.print(CAMERA_WIDTH);
  Serial.print(" Height: "); Serial.println(CAMERA_HEIGHT);
  Serial.print("Screen Width: "); Serial.print(display.width());
  Serial.print(" Height: "); Serial.println(display.height());
  Serial.print("Scale: "); Serial.println(SCALE);
  Serial.println("end setup");
  Serial.flush();
}

inline uint16_t HTONS(uint16_t x) {
  return ((x >> 8) & 0x00FF) | ((x << 8) & 0xFF00);
}
//#define HTONS(x) (((x >> 8) & 0x00FF) | ((x << 8) & 0xFF00))


uint32_t display_time_sum = 0;
uint8_t display_time_count = 0;

void loop() {

  // Grab frame and write to another framebuffer
  if (cam.grabFrame(fb)) {
    //Serial.println("Camera frame received");
    if (Serial.available()) {
      while (Serial.read() != -1) {}
//      cam.printRegs();
      //MemoryHexDump(Serial, fb.getBuffer(), 1024, true, "Start of Camera Buffer\n");
      Serial.println("*** Paused ***");
      while (Serial.read() == -1) {}
      while (Serial.read() != -1) {}
    }

    uint16_t *pixels = (uint16_t *)fb.getBuffer();
    elapsedMicros emDisplay;
    //for (int i = 0; i < CAMERA_WIDTH*CAMERA_HEIGHT; i++) pixels[i] = HTONS(pixels[i]);
    #if defined(SCALE) && SCALE > 1
    // Quick and dirty scale.
    int yDisplay = (display.height() - (CAMERA_HEIGHT * SCALE)) / 2;
    display.startBuffering();
    for (int yCamera = 0; yCamera < CAMERA_HEIGHT; yCamera++) {
      int xDisplay = (display.width() - (CAMERA_WIDTH * SCALE)) / 2;
      for (int xCamera = 0; xCamera < CAMERA_WIDTH; xCamera++) {
        display.fillRect(xDisplay, yDisplay, SCALE, SCALE, *pixels++);
        xDisplay += SCALE;
      }
      yDisplay += SCALE;
    }
    display.endBuffering();
    #else  
    display.drawRGBBitmap((display.width() - CAMERA_WIDTH) / 2, (display.height() - CAMERA_HEIGHT) / 2, pixels, CAMERA_WIDTH, CAMERA_HEIGHT);
    #endif

    cam.releaseFrame(fb);

    display_time_sum += emDisplay;
    display_time_count++;
    if (display_time_count == 128) {
      Serial.print("Avg display Time: ");
      Serial.print(display_time_sum / display_time_count);
      Serial.print(" fps:");
      Serial.println(128000000.0 / float(display_time_sum), 2);
      display_time_sum = 0;
      display_time_count = 0;
    }

  } else {

    digitalWrite(LED_BUILTIN, digitalRead(LED_BUILTIN)? LOW : HIGH);
  }
  delay(1);
}

[CharlesDias]

Hi @mjs513,

My suggestion is to start testing with the capture sample application (likely you will need a .conf and .overlay files for your board), since it has already been validated on many boards and sensors. Once your setup works with this application, it will be better to test other code.

I've been running the capture on mini_stm32h743 with weact_ov2640_cam_module for more than 17 minutes without any problem. As seen, the message video_stm32_dcmi: HAL_DCMI_FrameEventCallback: Failed to get buffer from fifo is printed to indicate that a frame was dropped, but this does not interrupt the code execution.

I also tested on stm32h7b3i_dk with st_b_cams_omv_mb1683 for more than 20 minutes without any problem. Since the display communication is better, no video frames are missed.

[josuah]

cc @zacck who might be interested in seeing this part:

Running the OV7670 at 12 mhz it runs for quite a bit (~5mins) at 320x240 and then I see several

[zacck]

Sorry, I'm late to the party, @mjs513 so are you getting frames with the 0v7670? I cant quite make it out if you are getting frames then it fails or you wait for long then it fails. Thank you.

[mjs513]

Running the OV2640 at 24 mhz at 320x240 with no errors for about 20 minutes so going to move on to different camera.

Ran the OV5640 at 12Mhz at 320x240 still shows the same type images as before whether I do a byte swap or not so something else going on. Then after a dozen or so frames will get

<wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback

[mjs513]

Hi @CharlesDias

@KurtE has been primarily testing with the Capture app while I have been using the Arduino IDE.

Seems like the different cameras are behaving differently between zephy app and the IDE. For instance, @KurtE got good results with the 5640 on a ILI9341 display while I am having image issues through the ArduinoCore could be that sdram is too slow.

Funny you should mention that you were testing with the OV2640 - just posted above that I ran that camera for about 20 minutes with no issues but having varying issues with different cameras.

EDIT: FOrgot to mention the current version of zephyr is at 4.1 so probably doesn't have all the latest changes to video api

[CharlesDias]

Hi @mjs513,

The st_b_cams_omv_mb1683 shield is an OV5640. So, I've tested the OV2640 and OV5640 without any problem.

Since you were able to run the capture sample successfully, one step would be dump the OV5640 register values and compare them to ArduinoCore.

[KurtE]

@mjs513 @CharlesDias - As mentioned I am currently hacking it on using Zephyr direct, currently outputting to an ILI9341 display....

My zephyr app, has the ability print out at least some of the registers... I took this code from our version of the code that runs
on a Teensy... (teensy_camera) that is in @mjs513 github...

*** Camera Registers ***
	0x3008: 2(2)	//SYSTEM_CTROL0
	0x302C: 2(2)	//DRIVE_CAPABILITY
	0x303A: 0(0)	//SC_PLLS_CTRL0
	0x303B: 25(19)	//SC_PLLS_CTRL1
	0x303C: 17(11)	//SC_PLLS_CTRL2
	0x303D: 48(30)	//SC_PLLS_CTRL3
	0x3503: 0(0)	//AEC_PK_MANUAL
	0x3800: 0(0)	//X_ADDR_ST_H
	0x3801: 8(8)	//X_ADDR_ST_L
	0x3802: 0(0)	//Y_ADDR_ST_H
	0x3803: 2(2)	//Y_ADDR_ST_L
	0x3804: 10(a)	//X_ADDR_END_H
	0x3805: 55(37)	//X_ADDR_END_L
	0x3806: 7(7)	//Y_ADDR_END_H
	0x3807: 161(a1)	//Y_ADDR_END_L
	0x3808: 1(1)	//X_OUTPUT_SIZE_H
	0x3809: 64(40)	//X_OUTPUT_SIZE_L
	0x380A: 0(0)	//Y_OUTPUT_SIZE_H
	0x380B: 240(f0)	//Y_OUTPUT_SIZE_L
	0x380C: 6(6)	//X_TOTAL_SIZE_H
	0x380D: 20(14)	//X_TOTAL_SIZE_L
	0x380E: 3(3)	//Y_TOTAL_SIZE_H
	0x380F: 232(e8)	//Y_TOTAL_SIZE_L
	0x3810: 0(0)	//X_OFFSET_H
	0x3811: 4(4)	//X_OFFSET_L
	0x3812: 0(0)	//Y_OFFSET_H
	0x3813: 2(2)	//Y_OFFSET_L
	0x3814: 49(31)	//X_INCREMENT
	0x3815: 49(31)	//Y_INCREMENT
	0x3820: 71(47)	//TIMING_TC_REG20
	0x3821: 1(1)	//TIMING_TC_REG21
	0x3824: 2(2)	//PCLK_RATIO
	0x4201: 0(0)	//FRAME_CTRL01
	0x4202: 0(0)	//FRAME_CTRL02
	0x4300: 111(6f)	//FORMAT_CTRL00
	0x4740: 33(21)	//CLOCK_POL_CONTROL
	0x5001: 163(a3)	//ISP_CONTROL_01
	0x501F: 1(1)	//FORMAT_CTRL
	0x503D: 0(0)	//PRE_ISP_TEST_SETTING_1
	0x5601: 0(0)	//SCALE_CTRL_1
	0x5602: 2(2)	//SCALE_CTRL_2
	0x5603: 0(0)	//SCALE_CTRL_3
	0x5604: 2(2)	//SCALE_CTRL_4
	0x5605: 0(0)	//SCALE_CTRL_5
	0x5606: 0(0)	//SCALE_CTRL_6
	0x5680: 0(0)	//X_START_H
	0x5681: 0(0)	//X_START_L
	0x5682: 0(0)	//Y_START_H
	0x5683: 0(0)	//Y_START_L
	0x5684: 16(10)	//X_WINDOW_H
	0x5685: 160(a0)	//X_WINDOW_L
	0x5686: 12(c)	//Y_WINDOW_H
	0x5687: 120(78)	//Y_WINDOW_L
	0x460C: 34(22)	//VFIFO_CTRL0C
	0x4602: 1(1)	//VFIFO_X_SIZE_H
	0x4603: 64(40)	//VFIFO_X_SIZE_L
	0x4604: 0(0)	//VFIFO_Y_SIZE_H
	0x4605: 240(f0)	//VFIFO_Y_SIZE_L
	0x4400: 129(81)	//COMPRESSION_CTRL00
	0x4401: 1(1)	//COMPRESSION_CTRL01
	0x4402: 16(10)	//COMPRESSION_CTRL02
	0x4403: 51(33)	//COMPRESSION_CTRL03
	0x4404: 36(24)	//COMPRESSION_CTRL04
	0x4405: 64(40)	//COMPRESSION_CTRL05
	0x4406: 64(40)	//COMPRESSION_CTRL06
	0x4407: 4(4)	//COMPRESSION_CTRL07
	0x4408: 0(0)	//COMPRESSION_ISI_CTRL
	0x4409: 0(0)	//COMPRESSION_CTRL09
	0x440A: 78(4e)	//COMPRESSION_CTRL0a
	0x440B: 22(16)	//COMPRESSION_CTRL0b
	0x440C: 0(0)	//COMPRESSION_CTRL0c
	0x440D: 10(a)	//COMPRESSION_CTRL0d
	0x440E: 9(9)	//COMPRESSION_CTRL0E

Note: yesterday had runs on OV5640, that maybe made it through
about 160+ frames before it dies with the error callback...
[00:00:25.651,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback
As mentioned in other places, I could avoid this in my app, where I hack up the first buffer that the camera holds on to
to not be in SDRAM, but in processor memory.

My not so good zephyr code is up at: https://github.com/KurtE/zephyr_test_sketches. Still learning, like how do I
define what the DC and Reset pins are on a compatible = "vnd,spi-device";
device, not great what I am doing but...

Will play more later.

[KurtE]

Quick note: I was hacking on one of my other sketch/app in my zephyer_test_sketches: camera_to_ili9341, which I hacked up to allow
me to output to either an ILI9341 or ST77XX in my case ST7796 display... This sketch is setup currently for the GC2145 camera.
Configured for 12mhz. If I run it normal where the camera buffer is in SDRAM, it dies typically within maybe 10-30 frames.
However if I define it to use a hack that puts the camera buffer in processor memory. It runs for a long time
Currently in this run I am at 3700 frames. So I am pretty sure it is SDRAM issue of being on the edge of if it works fast enough or not...

Next test is I have a hacked up version of: video_stm32_dcmi.c and gc2145.c get_selection and set_selection, that I want to test to
see if I can get it to output 480x320....

[mjs513]

@KurtE - @CharlesDias - @josuah

spent the last few days hacking up @KurtE's app to display frames on the ILI9341 in zephyr to run under the arduino ide / core. Results were the same for the OV5640 and indicated before when using SDRAM - however it doesn't seem that the arduino have enough memory to run a separate framebuffer in memory - get need another 160k on the giga.

So I then spent the day to hack up the video_capture example in zephyr to run under arduino core/ide. I also added a couple features to use memory other than SDRAM and to reverse bytes. If interested I am attaching it:

zephyr_capture_app-250716a.zip

I started with the GC2145 and managed to actually get 1 good frame before getting the callback error:

Capture started
Got frame 0! size: 153600; timestamp 8629 ms
[00:00:08.682,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback

Using the OV5640 at 320x240

1. Using revers bytes I am still getting corrupted frames but will get a dozen or more before getting the call back error

Got frame 44! size: 153600; timestamp 12193 ms
Got frame 45! size: 153600; timestamp 12306 ms
[00:00:12.490,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback
Got frame 46! size: 153600; timestamp 12423 ms
Got frame 47! size: 153600; timestamp 12457 ms

2. without reverse bytes: still corrputed images

Capture started
Got frame 0! size: 153600; timestamp 7663 ms
Got frame 1! size: 153600; timestamp 7776 ms
Got frame 2! size: 153600; timestamp 7889 ms
Got frame 3! size: 153600; timestamp 8002 ms
[00:00:08.187,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback
Got frame 4! size: 153600; timestamp 8120 ms
Got frame 5! size: 153600; timestamp 8153 ms

3. If I used a fixed buffer at 160x120 so it would fix in memory and I am still getting corruted frames but its still running after 1k frames with no callback error. Same for whether I reverse the bytes or not. @KurtE might be worth it if you can give it a try under zephyr if you get a chance after the dma test.

[josuah]

So it seems like the buffer size is not the only issue.

To give a bit of context, the GC2145 driver was developed for the Arduino Nicla Vision which has very short path between the sensor and the STM32H747, so that makes a good path for the signals.

On the Arduino Giga R1 or Portenta H7, that is a lot longer path, so maybe the DVP signal frequencies need to be tuned down a bit.

[mjs513]

@josuah - @KurtE
Finally got back to the camera stuff after playing around with getting DMA working. Out of curiosity decided to change the default regs for the GC2145 to the ones we use for our Teensy_camera libray which I believe @KurtE mentioned a few times also changed xclk to 10mhz and it seems to be working like a charm right now its ups to

Got frame 4941! size: 153600; timestamp 1029358 ms
Got frame 4942! size: 153600; timestamp 1029564 ms
Got frame 4943! size: 153600; timestamp 1029771 ms

and still going strong - not sure what the differences are yet. And since I dont have a Nicala Vision cant try it. But for now here is what I am using:
gc2145.zip

UPDATE: just tried the changes with the arduino camera library and our arduino gfx display library and that is working as well!

[mjs513]

Just a quick update - just tried it on the H7 and doesn't seem to be workings. Back to not getting any frames using @KurtE's that sends images to the 7796. Grabframe keeps returning false. Well it was too good to expect it work on the h7

[KurtE]

To give a bit of context, the GC2145 driver was developed for the Arduino Nicla Vision which has very short path between the sensor and the STM32H747, so that makes a good path for the signals.

That is probably somewhat true. But I think the biggest difference is in that AFAIK the Nikla Vision has no SDRAM, So you are not dealing with that. When I hacked up the code to have the camera always talking to standard processor memory, it run well... (most of the time)

[CharlesDias]

Hi @mjs513 and @KurtE ,

Great to know!

If you have time, could you set up an SDRAM stress test that doesn't involve a camera sensor or display? The goal is to verify whether it uses DMA to continuously read and write a 153,600-byte block (which represents 320 × 240 pixels at 2 bytes per pixel) and logs the number of cycles or transfers before an error occurs.

[KurtE]

Will try, when I get a chance. Not sure what all that will take.
My gut is that we probably need to setup a couple of buffers in SDRAM,
Have an operation that sets a buffer to some known contents, have it then use DMA to copy it to another location,
And when that completes, have the completion code do something with it and have something in the main loop also
accessing the SDRAM...
Not sure for example how hard it is to setup different types of DMA operations. For example straight memory to memory...
like wise maybe memory to memory that is clocked off of some timer...

[KurtE]

@CharlesDias and all, So far I am not having a lot of luck building a sample/simple sketch/app that copies memory to memory using DMA on the Portenta H7. Note: This is with the M7 processor.

Does anyone have a simple DMA memory to memory test app? I looked at a few examples like one for ESP32 I found up on github.
But my attempts to emulate it so far has not worked for me. Some simply crash and others don't appear to actually copy the
memory.

I have tried many different variations of ones that have code like:

void dma_callback(const struct device *dma_dev, void *arg, uint32_t channel, int status)
{
    if (status == 0) {
//        LOG_INF("DMA transfer complete on channel %d", channel);
    } else {
        LOG_ERR("DMA transfer failed with status %d on channel %d", status, channel);
    }
    dma_completed = true;
}


int configure_dma_transfer(const struct device *dma_dev, uint8_t *src, uint8_t *dest, size_t size, uint8_t channel)
{
	struct dma_config dma_cfg = {0};
	struct dma_block_config block_cfg = {0};
	//static bool fConfigured = false;
	static bool first_time = true;
	if (first_time) {
		first_time = false;
		printk("configure_dma_transfer(%p, %p, %p, %u %u)\n", dma_dev, src, dest, size, channel);
	}
	int ret = 0;
	//if (!fConfigured) {

		block_cfg.source_address = (uint32_t)src;
		block_cfg.dest_address = (uint32_t)dest;
		block_cfg.block_size = size;

		LOG_DBG("source: 0x%x, dest: 0x%x", block_cfg.source_address, block_cfg.dest_address);

		dma_cfg.channel_direction = MEMORY_TO_MEMORY;
		dma_cfg.source_burst_length = 1;  // Assuming 4 bytes per burst
		dma_cfg.dest_burst_length = 1;
		dma_cfg.source_data_size = 1;  // 4 bytes (32 bits)
		dma_cfg.dest_data_size = 1;
		dma_cfg.block_count = 1;
		dma_cfg.head_block = &block_cfg;
		dma_cfg.dma_callback = dma_callback;
		dma_cfg.

	//	LOG_INF("Configuring DMA...");

		ret = dma_config(dma_dev, channel, &dma_cfg);
		if (ret != 0) {
			LOG_ERR("DMA configuration failed with error %d\n", ret);
			return ret;
		}
		//fConfigured = true;
	//}
//	LOG_INF("DMA configured");

    dma_completed = false;
	ret = dma_start(dma_dev, channel);
	if (ret != 0) {
		LOG_ERR("Failed to start DMA transfer with error %d\n", ret);
	}

//	LOG_INF("DMA started");

	return ret;
}

I have tried with different sizes and burst sizes, etc.

@mjs513 found some sketches as well, like:

#include <zephyr/kernel.h>
#include <zephyr/device.h>
#include <zephyr/drivers/dma.h>
#include <zephyr/sys/printk.h>

#define DMA_DEVICE_NAME DT_LABEL(DT_NODELABEL(dma1)) // Adjust based on your STM32 device tree
#define DMA_CHANNEL 1                               // DMA channel to use
#define DMA_SLOT 0                                  // DMA slot (specific to your hardware)

#define BUFFER_SIZE 16

static const uint32_t src_buffer[BUFFER_SIZE] = {
    0xDEADBEEF, 0xCAFEBABE, 0x12345678, 0x87654321,
    0x0BADF00D, 0xFEEDFACE, 0xABCDEF01, 0x10FEDCBA,
    0x11223344, 0x55667788, 0x99AABBCC, 0xDDEEFF00,
    0x13579BDF, 0x2468ACE0, 0xFACEB00C, 0xC0FFEE00
};

static uint32_t dest_buffer[BUFFER_SIZE] = {0};

static struct dma_config dma_cfg;
static struct dma_block_config dma_block_cfg;

void main(void)
{
    const struct device *dma_dev;
    int ret;

    printk("Starting DMA Memory-to-Memory Transfer Example\n");

    // Get the DMA device
    dma_dev = device_get_binding(DMA_DEVICE_NAME);
    if (!dma_dev) {
        printk("Error: Unable to find DMA device %s\n", DMA_DEVICE_NAME);
        return;
    }

    // Configure the DMA block
    dma_block_cfg.source_address = (uint32_t)src_buffer;
    dma_block_cfg.dest_address = (uint32_t)dest_buffer;
    dma_block_cfg.block_size = sizeof(src_buffer);
    dma_block_cfg.source_addr_adj = DMA_ADDR_ADJ_INCREMENT;
    dma_block_cfg.dest_addr_adj = DMA_ADDR_ADJ_INCREMENT;

    // Configure the DMA transfer
    dma_cfg.channel_direction = MEMORY_TO_MEMORY;
    dma_cfg.source_data_size = 4; // 4 bytes (32-bit)
    dma_cfg.dest_data_size = 4;   // 4 bytes (32-bit)
    dma_cfg.block_count = 1;
    dma_cfg.head_block = &dma_block_cfg;

    // Start the DMA transfer
    ret = dma_config(dma_dev, DMA_CHANNEL, &dma_cfg);
    if (ret != 0) {
        printk("Error: DMA configuration failed (%d)\n", ret);
        return;
    }

    ret = dma_start(dma_dev, DMA_CHANNEL);
    if (ret != 0) {
        printk("Error: DMA start failed (%d)\n", ret);
        return;
    }

    printk("DMA transfer started. Waiting for completion...\n");

    // Wait for the transfer to complete (polling or interrupt-based)
    k_sleep(K_MSEC(100)); // Adjust based on your transfer size and speed

    printk("DMA transfer completed. Verifying data...\n");

    // Verify the data
    for (int i = 0; i < BUFFER_SIZE; i++) {
        if (src_buffer[i] != dest_buffer[i]) {
            printk("Error: Data mismatch at index %d (src: 0x%08X, dest: 0x%08X)\n",
                   i, src_buffer[i], dest_buffer[i]);
            return;
        }
    }

    printk("DMA transfer successful! Data verified.\n");
}

Which I had to make a few edits, like int main() instead of void main()...
But this one crashed the processor.

Looking around at different DMA examples on the STM32H77... I see the camera driver: video_stm32_dcmi.c
But with this I noticed that they appear to do a lot of the work within HAL DMA code:

static int stm32_dma_init(const struct device *dev)
{
	struct video_stm32_dcmi_data *data = dev->data;
	const struct video_stm32_dcmi_config *config = dev->config;
	int ret;

	/* Check if the DMA device is ready */
	if (!device_is_ready(config->dma.dma_dev)) {
		LOG_ERR("%s DMA device not ready", config->dma.dma_dev->name);
		return -ENODEV;
	}

	/*
	 * DMA configuration
	 * Due to use of DMA HAL API in current driver,
	 * both HAL and Zephyr DMA drivers should be configured.
	 * The required configuration for Zephyr DMA driver should only provide
	 * the minimum information to inform the DMA slot will be in used and
	 * how to route callbacks.
	 */
	struct dma_config dma_cfg = config->dma.cfg;
	static DMA_HandleTypeDef hdma;

	/* Proceed to the minimum Zephyr DMA driver init */
	dma_cfg.user_data = &hdma;
	/* HACK: This field is used to inform driver that it is overridden */
	dma_cfg.linked_channel = STM32_DMA_HAL_OVERRIDE;
	/* Because of the STREAM OFFSET, the DMA channel given here is from 1 - 8 */
	ret = dma_config(config->dma.dma_dev,
			config->dma.channel + STM32_DMA_STREAM_OFFSET, &dma_cfg);
	if (ret != 0) {
		LOG_ERR("Failed to configure DMA channel %d",
			config->dma.channel + STM32_DMA_STREAM_OFFSET);
		return ret;
	}

	/*** Configure the DMA ***/
	/* Set the parameters to be configured */
	hdma.Init.Request		= DMA_REQUEST_DCMI;
	hdma.Init.Direction		= DMA_PERIPH_TO_MEMORY;
	hdma.Init.PeriphInc		= DMA_PINC_DISABLE;
	hdma.Init.MemInc		= DMA_MINC_ENABLE;
	hdma.Init.PeriphDataAlignment	= DMA_PDATAALIGN_WORD;
	hdma.Init.MemDataAlignment	= DMA_MDATAALIGN_WORD;
	hdma.Init.Mode			= DMA_CIRCULAR;
	hdma.Init.Priority		= DMA_PRIORITY_HIGH;
#if defined(CONFIG_SOC_SERIES_STM32F7X) || defined(CONFIG_SOC_SERIES_STM32H7X)
	hdma.Init.FIFOMode		= DMA_FIFOMODE_DISABLE;
#endif

#if defined(CONFIG_SOC_SERIES_STM32F7X) || defined(CONFIG_SOC_SERIES_STM32H7X)
	hdma.Instance = __LL_DMA_GET_STREAM_INSTANCE(config->dma.reg,
						config->dma.channel);
#elif defined(CONFIG_SOC_SERIES_STM32L4X)
	hdma.Instance = __LL_DMA_GET_CHANNEL_INSTANCE(config->dma.reg, config->dma.channel);
#endif

	/* Initialize DMA HAL */
	__HAL_LINKDMA(&data->hdcmi, DMA_Handle, hdma);

	if (HAL_DMA_Init(&hdma) != HAL_OK) {
		LOG_ERR("DCMI DMA Init failed");
		return -EIO;
	}

	return 0;
}

So wondering if this is necessary with these? Suggestions?
Thanks
Kurt

[mjs513]

@KurtE
managed to get a variation of the dma sketch working:

#include <zephyr/kernel.h>
#include <zephyr/drivers/dma.h>
#include <zephyr/device.h>
#include <core_cm7.h>

#define DMA_NODE DT_NODELABEL(dma1)
#define DMA_CHANNEL 1
#define ARRAY_SIZE 128

static const struct device *dma_dev;
__aligned(32) static uint8_t src_array[ARRAY_SIZE];
__aligned(32) static uint8_t dst_array[ARRAY_SIZE];

static void dma_callback(const struct device *dev, void *user_data, uint32_t channel, int status)
{
    printk("DMA completed. Status: %d\n", status);

    if (status == 0) {
        __DSB(); // Data Synchronization Barrier
        SCB_InvalidateDCache_by_Addr((uint32_t *)dst_array, sizeof(dst_array));

        for (int i = 0; i < ARRAY_SIZE; i++) {
            if (src_array[i] != dst_array[i]) {
                printk("Mismatch at index %d, %d, %d\n", i, src_array[i], dst_array[i]);
                printk("         at index %d, %d, %d\n", i+1, src_array[i+1], dst_array[i+1]);
                while(1);
            }
        }
        printk("Transfer verified successfully!\n");
            printk("DEST ARRAY\n");
        for (int i = 0; i < 5; i++) {
            printk("Src/dest: %d, %d\n", src_array[i], dst_array[i]);
        }
    }
}

void setup(void)
{
  delay(2000);

    dma_dev = DEVICE_DT_GET(DMA_NODE);  // nned to ensure dma steam is stopped first, just in case

    dma_stop(dma_dev, DMA_CHANNEL);

    if (!device_is_ready(dma_dev)) {
        printk("DMA device not ready\n");
        while(1){};
    }

    for (int i = 0; i < ARRAY_SIZE; i++) {
        src_array[i] = i;
    }

    struct dma_block_config block_cfg = {
        .source_address = (uint32_t)src_array,
        .dest_address = (uint32_t)dst_array,
        .block_size = sizeof(dst_array),
    };

    struct dma_config dma_cfg = {
        .dma_slot = 0,
        .channel_direction = MEMORY_TO_MEMORY,
        .complete_callback_en = true,
        .source_data_size = 1,
        .dest_data_size = 1,
        .source_burst_length = 1,
        .dest_burst_length = 1,
        .block_count = 1,
        .head_block = &block_cfg,
        .dma_callback = dma_callback,
    };

    int ret = dma_config(dma_dev, DMA_CHANNEL, &dma_cfg);
    if (ret) {
        printk("DMA config error: %d\n", ret);
        return;
    }

    SCB_CleanDCache_by_Addr((uint32_t *)src_array, sizeof(src_array));
    ret = dma_start(dma_dev, DMA_CHANNEL);
    if (ret) {
        printk("DMA start error: %d\n", ret);
    }
/*
    ret = dma_stop(dma_dev, DMA_CHANNEL);
    if (ret) {
        printk("DMA stop error: %d\n", ret);
    }
*/
    printk("DEST ARRAY\n");
    for (int i = 0; i < 2; i++) {
        printk("%d\n", dst_array[i]);
    }

}

void loop() {
  // put your main code here, to run repeatedly:

}

results

DMA completed. Status: 0
Transfer verified successfully!
DEST ARRAY
Src/dest: 0, 0
Src/dest: 1, 1
Src/dest: 2, 2
Src/dest: 3, 3
Src/dest: 4, 4
...

Probably can now use the single transfer?

Had issues until I added the invalidate cache and had to align32 arrays.  Yes I asked copilot.  Have fun modifing.  PS I stopped dma first since the stream was showing busy.  Once I did that then was able to reconfigure.  PRobably because dma1 is used for dcmi in the overlay for the giga.

CHeers

[zacck]

Oh wow , amazing dig @mjs513 , @CharlesDias with the above, do you see any blockers to moving the m7 especially the GIGA to completely zephyr DMA config. @KurtE if you aren't already pushing on this I am willing to work on getting it over the line.

[KurtE]

Thanks again @mjs513,

As we discussed on other channels, that helped a lot in finding some of the last sticking points in the code we have been playing with. It started working for one iteration, but not on subsequent iterations. Although maybe caused by other bugs I had.

Got that working by using the dma_reload, instead of doing another call to dma_config.

So then @mjs513 converted to an Arduino sketch and it hung. I figured it out that we are/were hard coding the test to run on
channel 1. Turns out there is already someone else using Channel 1... (USB I am pretty sure).

Looks like zephyr has an api that maybe helps with that:
int dma_request_channel ( const struct device * dev, void * filter_param );
Not sure what to use for filter_param , so passed NULL. The API returned -22...
Doing a search through the zephyr code I only found a few examples of using this api and it looked like most of them
were specific to some specific boards...

So for now in the sketch I added:

  for (uint8_t channel = 1; channel <= 7; channel++) {
    dma_status dmastat;
    memset(&dmastat, 0, sizeof(dmastat));
    ret = dma_get_status(dma_dev, channel, &dmastat);
    printk("ch:%u stat:%d - %u %u %u %u %u %u %u\n", channel, ret,
           dmastat.busy, dmastat.dir, dmastat.pending_length,
           dmastat.free, dmastat.write_position, dmastat.read_position, dmastat.total_copied);
		if ((tx_dma_channel == 0) && (ret == 0) && (!dmastat.busy)) tx_dma_channel = channel;
  }

Which output:

SDRAM test...
ch:1 stat:0 - 1 0 0 0 0 0 0
ch:2 stat:0 - 0 0 0 0 0 0 0
ch:3 stat:0 - 0 0 0 0 0 0 0
ch:4 stat:0 - 0 0 0 0 0 0 0
ch:5 stat:0 - 0 0 0 0 0 0 0
ch:6 stat:0 - 0 0 0 0 0 0 0
ch:7 stat:0 - 0 0 0 0 0 0 0
DMA Channel allocated 2

Next issue to try: It appears like the DMA operation will only allow you to output 64K per block (or maybe 64K-1), so
need to see if I can chain blocks together to logically transfer a full camera buffer like 320x240x2... (or more)

Back to testing

Edit: Looks like the reload code may not be needed, there was a different bug that that worked around.

[KurtE]

Next issue to try: It appears like the DMA operation will only allow you to output 64K per block (or maybe 64K-1), so
need to see if I can chain blocks together to logically transfer a full camera buffer like 320x240x2... (or more)

Again I could be wrong, but I don't thin the STM32 implementation does not support any of the gather, scatter stuff, nor the
multiple buffers blocks chained to each other. For example I setup a chain of 3 blocks (first two were setup to output
65536-16 bytes each and the third was the left over. And when I started it up it only transferred the stuff in the first
block and then called the callback...

Looking at the STM32 SPI stuff, I did not see anything that looks at the next pointer, nor looks for scatter/gather. Likewise
I don't see anything in the Reference manual mentioning this capability.

First thing I need to check is how the sizes and counts work with each other:
That is currently I have:

		struct dma_config dma_cfg = {
	 		.dma_slot = 0,
	        .channel_direction = MEMORY_TO_MEMORY,
	        .complete_callback_en = true,
	        .source_data_size = 1,
	        .dest_data_size = 1,
	        .source_burst_length = 1,
	        .dest_burst_length = 1,
	        .block_count = block_index,
	        .head_block = &g_block_cfgs[0],
	        .user_data = dest,
	        .dma_callback = dma_callback,
	    };
		//static bool fConfigured = false;
		//if (!fConfigured) {

And each of the dma_block_config objects set a: source pointer, destination pointer and a block_size member.
Question to self to look at again tomorrow, is the block_size in bytes or in source_data_size... size.
So question is, if the camera is 3202402 bytes or 153600, which won't currently fit into one block, but
if the size are 4 = 38400 which would fit.

If this does not work. Then another approach would be to output (or input from camera) the first block, get the
block complete interrupt, where you then try to restart a DMA operation, by updating the Sourc/Dest/Count variables
to try to get the next block... But this can be problematic if for example the ISR is not serviced quick enough before the
camera needs to send the next set of data...

[mjs513]

@KurtE - @josuah

Regarding the GC2145 on the portenta H7 found that I had an error in the overlay for the gc2145 so reran with the same clock and updates to the GC 2145 registers. Also changed to using the ILI9341 spi driver.

With this configuration was able to get up to 100 frames before getting the

<wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback

and frames stop coming through,

Also once in while on reset I would get:

[00:00:08.461,000] <err> os: ***** BUS FAULT *****
[00:00:08.468,000] <err> os:   Imprecise data bus error
[00:00:08.476,000] <err> os: r0/a1:  0xfc1d9128  r1/a2:  0xc0000083  r2/a3:  0x038f1cd5
[00:00:08.487,000] <err> os: r3/a4:  0xfc1d912a r12/ip:  0x0000210d r14/lr:  0x0807d141
[00:00:08.498,000] <err> os:  xpsr:  0xa100005e
[00:00:08.505,000] <err> os: s[ 0]:  0x240013dc  s[ 1]:  0x0807d141  s[ 2]:  0x48020000  s[ 3]:  0x240013dc
[00:00:08.518,000] <err> os: s[ 4]:  0x00000019  s[ 5]:  0x080600db  s[ 6]:  0x0000004e  s[ 7]:  0x00000000
[00:00:08.531,000] <err> os: s[ 8]:  0x40003800  s[ 9]:  0x0804a853  s[10]:  0x24005340  s[11]:  0xffffffed
[00:00:08.543,000] <err> os: s[12]:  0x1eb7eebf  s[13]:  0xb5a50fa2  s[14]:  0x9b1a08b3  s[15]:  0x951a4cdb
[00:00:08.556,000] <err> os: fpscr:  0x9d2a5b5f
[00:00:08.563,000] <err> os: Faulting instruction address (r15/pc): 0x08083830
[00:00:08.573,000] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
[00:00:08.583,000] <err> os: Fault during interrupt handling

[00:00:08.592,000] <err> os: Current thread: 0x24005340 (main)
[00:00:08.601,000] <err> os: Halting system

EDIT: Since I am using the 9341 I am also using a framebuffer. It seems that if I add a 1mllisecond delay after updating the screen I am not seeing the bus faults and now getting between 100 and 200 frames before the callback error.

[josuah]

Regarding the "bus fault", you can get the line of code back from the address using addr2line. My flag cocktail:

addr2line -afip -e build/zephyr/zephyr.elf 0x08083830

You would need the .elf file that generated the build to access all the debug symbols.

Thank you for running these tests! It seems like different sensors have slightly different behavior but eventually come across this same DMA-related error.

@mjs513 and @KurtE I think you have been doing a lot of investigation on this driver, it could be interesting for Zephyr developers looking into this if you had a git diff output on the Zephyr repository, or even a draft PR showing all the modifications you did in order to improve the behavior.

Or is this all running with unmodified DCMI driver from Zephyr?

[KurtE]

Regarding the "bus fault", you can get the line of code back from the address using addr2line. My flag cocktail:

addr2line -afip -e build/zephyr/zephyr.elf 0x08083830

You would need the .elf file that generated the build to access all the debug symbols.
The one complexity with the Arduino environment, is that often times, the crash might be within Arduino area, and when
you use the addr2line command or look at map files, it ends up being some offset from the start of ltext...

@facchinm and @pillo79 are adding in a way where you can load the ltext using hard linkages instead of jump tables, But so
far they have only added in to Portenta C33 which so far does not support camera, nor DMA...

Thoughts on Cameras:
Will try to summarize soon, what changes we have done so far soon. Right now I am in the process of seeing what state
we are in with updating my Arduino environment to the latest stuff. Mostly running with very little changed within zephyr (yet). Other than maybe some tweaks within some drivers.

On the Camera side: Some things that a few of us have looked at or wonder about:

Changing Camera: - Depending on library/libraries, to change from one camera to another might be as simple as changing an include file, and maybe change which object is defined in your sketch. In ArduinoCore-zephyr/zephyr not sure how one easily changes
from from GC2145 to OV5640 or OV2640... Or change Clock Speed or which pin is used for XCLK...

Example: With Portenta H7 - If I use the Portenta Vision shield It is hard coded to a specific camera (HM01B0 maybe HM0360 later?),
but if instead I use the Mid Carrier board, I can use several different Arducam cameras. Note: I believe the pin numbers for things
like the XLK is different between two carriers. And I have not even looked at the MIPI connection on the MID.

One option, might be to define a generic "Arduino Camera" object, which an Arduino object can register with, the Arduino camera
just puts in the glue...

Continuous vs Snaphot mode: I believe some maybe most of the Camera code on the Arduino may typically run in
Snaphot mode... That is I ask it for an image and it captures and returns one image to me and stops, until I ask it for the
next one.

For me, most of the time I would prefer to run in this mode. Especially with these processors which don't have a lot of fast memory. Continuous mode also eats up processor and data buses.
Theory, most of our data crashing
[00:00:14.776,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback
Is caused or more prominent when are running in continuous mode. As we are continuously writing data to the camera buffer, while
at least one other buffer is setup to be used by the client. And we memcpy between the two, and often times switch byte
orders, etc... So this keeps DMA busy, the data bus, etc.

Also side effect of running in continuous mode, requiring two full buffers, is it probably restricts how big of an image we can
capture. For example with the Nicla Vision, it may only have enough memory to read in a 320x240 image, whereas the Camera
can capture 1600x1200 image.

ResolutionWithZoom - With the DCIMP it looks like Zephyr is adding some support to set a viewport. Still need to
play more with this. Trying to add that in through the DCI interface... Hopefully will have reasonable control, where
we can for example with the different cameras set the output to specific sizes, For example to match the size of a display.

Also will play more to see about panning within the zoom... We did some of this in the Teensy camera library.
I have not tried any Camera stuff on a Teensy within Zephyr. So far I don't believe there are any drivers setup for CSI or
FlexIO, although I believe I see some that were setup within the HAL code.

Probably enough for now.

[mjs513]

@josuah - @KurtE

Think I isolated the reg block that gets the GC2145 working properly with the GigaDisplay on the Arduino GIGA R1. Going through the reg settings I eventually added to the current default regs in GC2145.c the change is at the end:

    {GC2145_REG_RESET, GC2145_REG_RESET_P0_REGS},
    //////////////frame rate   50Hz
    {0xfe, 0x00},

    {0xf7, 0x1d},
    {0xf8, 0x84},
    {0xfa, 0x00},

    {0x05, 0x01}, // hb
    {0x06, 0x3b},
    {0x07, 0x01}, // Vb
    {0x08, 0x0b},

    {0xfe, 0x01},
    {0x25, 0x01},
    {0x26, 0x32}, // step
    {0x27, 0x03}, // 8.15fps
    {0x28, 0x96},
    {0x29, 0x03}, // 8.15fps
    {0x2a, 0x96},
    {0x2b, 0x03}, // 8.15fps
    {0x2c, 0x96},
    {0x2d, 0x04}, // 8.15fps
    {0x2e, 0x62},
    {0x3c, 0x00},
    {0xfe, 0x00},
    {0x00, 0x00},
};

with this change I am seeing the following with the giga display for a resolution of 320x240

Avg display Time: 21090 fps:47.41
Avg display Time: 21047 fps:47.51

I am using one of @KurtE sketches that uses our arduino graphic libraries. If i change to scale 2 (upscale programatically in the sketch:

Avg display Time: 50216 fps:19.91
Avg display Time: 50214 fps:19.91

and getting and callback errors

The H7 with the ILI9341 via spi not as much luck. Getting about 50-60 frames before the DCMI callback error.

Note is is based on using 4.2.0-rc3/

[KurtE]

@josuah @mjs513 - Quick note:
I hacked up the ArduinoCore-zephyr camera library: To reallocate the first buffer using malloc:

bool Camera::begin(uint32_t width, uint32_t height, uint32_t pixformat, bool byte_swap) {
    #if DT_HAS_CHOSEN(zephyr_camera)
    this->vdev = DEVICE_DT_GET(DT_CHOSEN(zephyr_camera));
    #endif

    if (!this->vdev || !device_is_ready(this->vdev)) {
        return false;
    }

    switch (pixformat) {
        case CAMERA_RGB565:
            this->byte_swap = byte_swap;
            pixformat = VIDEO_PIX_FMT_RGB565;
            break;
        case CAMERA_GRAYSCALE:
            // There's no support for mono sensors.
            this->yuv_to_gray = true;
            pixformat = VIDEO_PIX_FMT_YUYV;
            break;
        default:
            break;
    }

    // Get capabilities
    struct video_caps caps;
    if (video_get_caps(this->vdev, &caps)) {
        return false;
    }

    for (size_t i=0; caps.format_caps[i].pixelformat != NULL; i++) {
        const struct video_format_cap *fcap = &caps.format_caps[i];
        if (fcap->width_min == width &&
            fcap->height_min == height &&
            fcap->pixelformat == pixformat) {
            break;
        }
        if (caps.format_caps[i+1].pixelformat == NULL) {
            Serial.println("The specified format is not supported");
            return false;
        }
    }

    // Set format.
    static struct video_format fmt = {
        .pixelformat = pixformat,
        .width = width,
        .height = height,
        .pitch = width * 2,
    };

	if (video_set_format(this->vdev, &fmt)) {
        Serial.println("Failed to set video format");
		return false;
	}

	// Allocate video buffers.
	for (size_t i = 0; i < ARRAY_SIZE(this->vbuf); i++) {
		this->vbuf[i] = video_buffer_aligned_alloc(fmt.pitch * fmt.height,
                                                   CONFIG_VIDEO_BUFFER_POOL_ALIGN,
                                                   K_FOREVER);
		if (this->vbuf[i] == NULL) {
            Serial.println("Failed to allocate video buffers");
			return false;
		}
#define TRY_FIXED_CAMERA_BUFFER
#ifdef TRY_FIXED_CAMERA_BUFFER
        if (i == 0) {
            // REAL hack change the buffer over to our fixed buffer...
            uint8_t *pb = (uint8_t*)malloc(fmt.pitch * fmt.height + 15);
            if (pb == nullptr) {
                Serial.println("Failed to allocate fixed video buffers");
            } else {
                // release the SDRAM
                //k_heap_free(&video_buffer_pool,this->vbuf[i]->buffer);
                #define ALIGN_UP(num, align) (((num) + ((align) - 1)) & ~((align) - 1))
                this->vbuf[i]->buffer = (uint8_t*)ALIGN_UP((uint32_t)pb, 32);
            }
        }
#endif
		video_enqueue(this->vdev, this->vbuf[i]);
	}

	// Start video capture
	if (video_stream_start(this->vdev, VIDEO_BUF_TYPE_OUTPUT)) {
        Serial.println("Failed to start capture");
		return false;
	}

    return true;
}

Note: I also turned off video debug in the config file...
Updated the Zephyr_GigaCameraDisplay_GFX sketch now to output at SCALE 2... Still reads 320x240 but the display
code draws it at 640x480

It has been running now for awhile. I think now going on about 5000 frames at about 18 frames per second.

Again reinforces that the issue is the DMA to SDRAM.
At this resolution

[KurtE]

@josuah @mjs513 - and all Doing some hacking to see how possible it is to do snapshots...

So right now working on zephyrproject: My current changes are:

diff --git a/drivers/video/gc2145.c b/drivers/video/gc2145.c
index 28bdcdc1f1c..7cb9f804ebb 100644
--- a/drivers/video/gc2145.c
+++ b/drivers/video/gc2145.c
@@ -706,10 +706,18 @@ static const struct video_reg8 default_regs[] = {
 	{0x46, 0xcf},
 
 	{GC2145_REG_RESET, GC2145_REG_RESET_P0_REGS},
+#if 1
+    {0x05, 0x01}, // hb  from teensy_camera
+    {0x06, 0x3b},
+    {0x07, 0x01}, // Vb
+    {0x08, 0x0b},
+
+#else	
 	{0x05, 0x01},
 	{0x06, 0x1C},
 	{0x07, 0x00},
 	{0x08, 0x32},
+#endif	
 	{0x11, 0x00},
 	{0x12, 0x1D},
 	{0x13, 0x00},
@@ -768,6 +776,7 @@ struct gc2145_ctrls {
 struct gc2145_data {
 	struct gc2145_ctrls ctrls;
 	struct video_format fmt;
+	struct video_rect clip_rect;
 };
 
 #define GC2145_VIDEO_FORMAT_CAP(width, height, format)                                             \
@@ -789,6 +798,12 @@ static const struct video_format_cap fmts[] = {
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_QVGA_W, RESOLUTION_QVGA_H, VIDEO_PIX_FMT_RGB565),
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_VGA_W, RESOLUTION_VGA_H, VIDEO_PIX_FMT_RGB565),
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_UXGA_W, RESOLUTION_UXGA_H, VIDEO_PIX_FMT_RGB565),
+	/* Add some full size possible resolutions */
+	GC2145_VIDEO_FORMAT_CAP(800, 600, VIDEO_PIX_FMT_RGB565),	/* div 2 */
+	GC2145_VIDEO_FORMAT_CAP(533, 400, VIDEO_PIX_FMT_RGB565),	/* div 3 */
+	GC2145_VIDEO_FORMAT_CAP(400, 300, VIDEO_PIX_FMT_RGB565),	/* div 4 */
+	GC2145_VIDEO_FORMAT_CAP(320, 240, VIDEO_PIX_FMT_RGB565),	/* div 5 */
+
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_QVGA_W, RESOLUTION_QVGA_H, VIDEO_PIX_FMT_YUYV),
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_VGA_W, RESOLUTION_VGA_H, VIDEO_PIX_FMT_YUYV),
 	GC2145_VIDEO_FORMAT_CAP(RESOLUTION_UXGA_W, RESOLUTION_UXGA_H, VIDEO_PIX_FMT_YUYV),
@@ -846,6 +861,8 @@ static int gc2145_set_output_format(const struct device *dev, int output_format)
 static int gc2145_set_resolution(const struct device *dev, uint32_t w, uint32_t h)
 {
 	const struct gc2145_config *cfg = dev->config;
+	struct gc2145_data *drv_data = dev->data;
+	struct video_rect *clip_rect = &drv_data->clip_rect;
 	int ret;
 
 	uint16_t win_w;
@@ -879,11 +896,19 @@ static int gc2145_set_resolution(const struct device *dev, uint32_t w, uint32_t
 	/* Calculates the window boundaries to obtain the desired resolution */
 	win_w = w * c_ratio;
 	win_h = h * r_ratio;
-	x = (((win_w / c_ratio) - w) / 2);
-	y = (((win_h / r_ratio) - h) / 2);
 	win_x = ((UXGA_HSIZE - win_w) / 2);
 	win_y = ((UXGA_VSIZE - win_h) / 2);
 
+	x = (((win_w / c_ratio) - w) / 2);
+	y = (((win_h / r_ratio) - h) / 2);
+	if ((clip_rect->width != 0) && (clip_rect->height != 0) && 
+			(clip_rect->width <= win_w) && (clip_rect->height <= win_h) ) {
+		w = clip_rect->width;
+		h = clip_rect->height;
+		x = (clip_rect->left != (uint32_t)-1)? clip_rect->left : (((win_w / c_ratio) - w) / 2);
+		y = (clip_rect->top != (uint32_t)-1)? clip_rect->top : (((win_h / c_ratio) - h) / 2);
+	}
+
 	ret = video_write_cci_reg(&cfg->i2c, GC2145_REG8(GC2145_REG_RESET),
 				  GC2145_REG_RESET_P0_REGS);
 	if (ret < 0) {
@@ -1171,12 +1196,64 @@ static int gc2145_set_ctrl(const struct device *dev, uint32_t id)
 	}
 }
 
+static int gc2145_set_selection(const struct device *dev, struct video_selection *sel)
+{
+	printk("gc2145_set_selection(%p, %p: %u %u)\n", dev, sel, sel->type, sel->target);
+	if (sel->type != VIDEO_BUF_TYPE_OUTPUT) {
+		return -EINVAL;
+	}
+
+	struct gc2145_data *drv_data = dev->data;
+
+	switch (sel->target) {
+	case VIDEO_SEL_TGT_CROP:
+		drv_data->clip_rect = sel->rect;
+		return gc2145_set_resolution(dev, drv_data->fmt.width, drv_data->fmt.height);
+		break;
+
+	default:
+		return -EINVAL;
+	};
+
+	return 0;
+}
+
+static int gc2145_get_selection(const struct device *dev, struct video_selection *sel)
+{
+	printk("gc2145_get_selection(%p, %p: %u %u)\n", dev, sel, sel->type, sel->target);
+	if (sel->type != VIDEO_BUF_TYPE_OUTPUT) {
+		return -EINVAL;
+	}
+
+	struct gc2145_data *drv_data = dev->data;
+
+	switch (sel->target) {
+	case VIDEO_SEL_TGT_CROP:
+		sel->rect = drv_data->clip_rect;
+		break;
+
+	case VIDEO_SEL_TGT_NATIVE_SIZE:
+		sel->rect.top = 0;
+		sel->rect.left = 0;
+		sel->rect.width = drv_data->fmt.width;
+		sel->rect.height = drv_data->fmt.height;
+		break;
+	default:
+		return -EINVAL;
+	};
+
+	return 0;
+}
+
+
 static DEVICE_API(video, gc2145_driver_api) = {
 	.set_format = gc2145_set_fmt,
 	.get_format = gc2145_get_fmt,
 	.get_caps = gc2145_get_caps,
 	.set_stream = gc2145_set_stream,
 	.set_ctrl = gc2145_set_ctrl,
+	.set_selection = gc2145_set_selection,
+	.get_selection = gc2145_get_selection,
 };
 
 static int gc2145_init_controls(const struct device *dev)
@@ -1272,6 +1349,15 @@ static int gc2145_init(const struct device *dev)
 		return ret;
 	}
 
+	/* initialize clip rectangle */
+	struct gc2145_data *drv_data = dev->data;
+	drv_data->clip_rect.top = 0;
+	drv_data->clip_rect.left = 0;
+	drv_data->clip_rect.width = 0;
+	drv_data->clip_rect.height = 0;
+
+
+
 	ret = gc2145_set_fmt(dev, &fmt);
 	if (ret) {
 		LOG_ERR("Unable to configure default format");
diff --git a/drivers/video/ov5640.c b/drivers/video/ov5640.c
index 664d99b9543..b1ff9324b6e 100644
--- a/drivers/video/ov5640.c
+++ b/drivers/video/ov5640.c
@@ -867,6 +867,7 @@ static int ov5640_set_fmt(const struct device *dev, struct video_format *fmt)
 	drv_data->fmt = *fmt;
 
 	/* Set resolution */
+	printk("Is DVP? %c\n", ov5640_is_dvp(dev)? 'y' :'n');
 	for (i = 0; i < array_size_modes; i++) {
 		if (fmt->width == modes[i].width && fmt->height == modes[i].height) {
 			ret = ov5640_write_multi_regs(&cfg->i2c, modes[i].res_params,
@@ -1324,10 +1325,18 @@ static int ov5640_init_controls(const struct device *dev)
 static int ov5640_init(const struct device *dev)
 {
 	const struct ov5640_config *cfg = dev->config;
-	struct video_format fmt = {0};
+	//struct video_format fmt = {0};
+	// make sure we have a setting.
+	struct video_format fmt = {
+		.pixelformat = VIDEO_PIX_FMT_RGB565,
+		.width = 320,
+		.height = 240,
+	};
+
 	uint16_t chip_id;
 	int ret;
 
+	LOG_INF("ov5640_init called");
 	if (!device_is_ready(cfg->i2c.bus)) {
 		LOG_ERR("Bus device is not ready");
 		return -ENODEV;
@@ -1370,7 +1379,7 @@ static int ov5640_init(const struct device *dev)
 
 #if DT_ANY_INST_HAS_PROP_STATUS_OKAY(powerdown_gpios)
 	if (cfg->powerdown_gpio.port != NULL) {
-		gpio_pin_set_dt(&cfg->powerdown_gpio, 0);
+		gpio_pin_set_dt(&cfg->powerdown_gpio, 1);
 	}
 #endif
 
@@ -1449,6 +1458,7 @@ static int ov5640_init(const struct device *dev)
 		fmt.width = 1280;
 		fmt.height = 720;
 	}
+	LOG_INF("Set Default format: %u %u", fmt.width, fmt.height);
 	ret = ov5640_set_fmt(dev, &fmt);
 	if (ret) {
 		LOG_ERR("Unable to configure default format");
@@ -1480,8 +1490,10 @@ static int ov5640_init(const struct device *dev)
 		.i2c = I2C_DT_SPEC_INST_GET(n),                                                    \
 		OV5640_GET_RESET_GPIO(n)							   \
 		OV5640_GET_POWERDOWN_GPIO(n)							   \
-		.bus_type = DT_PROP_OR(DT_CHILD(DT_INST_CHILD(n, port), endpoint), bus_type,       \
-				       VIDEO_BUS_TYPE_CSI2_DPHY),                                  \
+		/*.bus_type = DT_PROP_OR(DT_CHILD(DT_INST_CHILD(n, port), endpoint), bus_type, */       \
+		/*		       VIDEO_BUS_TYPE_CSI2_DPHY), */                                 \
+		.bus_type = DT_PROP_OR(DT_INST_ENDPOINT_BY_ID(n, 0, 0), bus_type,		\
+				       VIDEO_BUS_TYPE_PARALLEL),				\
 	};                                                                                         \
                                                                                                    \
 	DEVICE_DT_INST_DEFINE(n, &ov5640_init, NULL, &ov5640_data_##n, &ov5640_cfg_##n,            \
diff --git a/drivers/video/video_stm32_dcmi.c b/drivers/video/video_stm32_dcmi.c
index 363de09717b..b537ac4dc59 100644
--- a/drivers/video/video_stm32_dcmi.c
+++ b/drivers/video/video_stm32_dcmi.c
@@ -45,6 +45,7 @@ struct video_stm32_dcmi_data {
 	struct k_fifo fifo_in;
 	struct k_fifo fifo_out;
 	struct video_buffer *vbuf;
+	volatile bool snapshot_active;
 };
 
 struct video_stm32_dcmi_config {
@@ -66,8 +67,17 @@ void HAL_DCMI_FrameEventCallback(DCMI_HandleTypeDef *hdcmi)
 			CONTAINER_OF(hdcmi, struct video_stm32_dcmi_data, hdcmi);
 	struct video_buffer *vbuf;
 
+	if (dev_data->snapshot_active) {
+		dev_data->snapshot_active = false;
+		return;
+	}
 	HAL_DCMI_Suspend(hdcmi);
 
+	if ((dev_data->vbuf == NULL) || (dev_data->vbuf->buffer == NULL)) {
+		LOG_DBG("NULL buffer");
+		return;
+	}
+
 	vbuf = k_fifo_get(&dev_data->fifo_in, K_NO_WAIT);
 
 	if (vbuf == NULL) {
@@ -417,6 +427,58 @@ static int video_stm32_dcmi_get_frmival(const struct device *dev, struct video_f
 	return 0;
 }
 
+static int video_stm32_dcmi_set_selection(const struct device *dev, struct video_selection *sel)
+{
+	const struct video_stm32_dcmi_config *config = dev->config;
+	return video_set_selection(config->sensor_dev, sel);
+}
+
+static int video_stm32_dcmi_get_selection(const struct device *dev, struct video_selection *sel)
+{
+	const struct video_stm32_dcmi_config *config = dev->config;
+	return video_get_selection(config->sensor_dev, sel);
+}
+
+static int video_stm32_dcmi_capture_snapshot(const struct device *dev, void *buffer, size_t buffer_size, k_timeout_t timeout)
+{
+	struct video_stm32_dcmi_data *data = dev->data;
+	const struct video_stm32_dcmi_config *config = dev->config;
+    
+    // Start the Camera Snapshot Capture.
+	data->hdcmi.Instance->CR &= ~(DCMI_CR_FCRC_0 | DCMI_CR_FCRC_1);
+	data->hdcmi.Instance->CR |= STM32_DCMI_GET_CAPTURE_RATE(data->capture_rate);
+
+	data->snapshot_active = true;
+    if (HAL_DCMI_Start_DMA(&data->hdcmi, DCMI_MODE_SNAPSHOT,
+                (uint32_t) buffer, buffer_size / 4) != HAL_OK) {
+		LOG_WRN("Snapshot: HAL_DCMI_Start_DMA FAILED!");
+		return -EIO;
+    }
+
+	video_stream_start(config->sensor_dev, VIDEO_BUF_TYPE_OUTPUT);
+    // Wait until camera frame is ready.
+
+    for (int64_t start_time = k_uptime_get(); data->snapshot_active == true;) {
+        __WFI();
+        if (k_uptime_delta(&start_time) > timeout.ticks) {
+			LOG_DBG("Timeout expired!");
+	        HAL_DCMI_Stop(&data->hdcmi);
+        	return -EIO;
+        }
+    }
+	video_stream_stop(config->sensor_dev, VIDEO_BUF_TYPE_OUTPUT);
+
+    HAL_DCMI_Stop(&data->hdcmi);
+
+    #if defined(__CORTEX_M7)  // only invalidate buffer for Cortex M7
+    // Invalidate buffer after DMA transfer.
+    SCB_InvalidateDCache_by_Addr((uint32_t*) framebuffer, framesize);
+    #endif
+    return 0;
+
+}
+
+
 static DEVICE_API(video, video_stm32_dcmi_driver_api) = {
 	.set_format = video_stm32_dcmi_set_fmt,
 	.get_format = video_stm32_dcmi_get_fmt,
@@ -427,6 +489,9 @@ static DEVICE_API(video, video_stm32_dcmi_driver_api) = {
 	.enum_frmival = video_stm32_dcmi_enum_frmival,
 	.set_frmival = video_stm32_dcmi_set_frmival,
 	.get_frmival = video_stm32_dcmi_get_frmival,
+	.set_selection = video_stm32_dcmi_set_selection,
+	.get_selection = video_stm32_dcmi_get_selection,
+	.capture_snapshot = video_stm32_dcmi_capture_snapshot,
 };
 
 static void video_stm32_dcmi_irq_config_func(const struct device *dev)
diff --git a/include/zephyr/drivers/video.h b/include/zephyr/drivers/video.h
index 0744219a769..7f859005696 100644
--- a/include/zephyr/drivers/video.h
+++ b/include/zephyr/drivers/video.h
@@ -390,6 +390,17 @@ typedef int (*video_api_set_signal_t)(const struct device *dev, struct k_poll_si
  */
 typedef int (*video_api_selection_t)(const struct device *dev, struct video_selection *sel);
 
+/**
+ * @typedef video_api_capture_snapshot_t
+ * @brief start, capture one frame and stop
+ *
+ * @param dev Pointer to the device structure.
+ * @param buffer Buffer to receive the frame.
+ * @param buffer_size size of the buffer in bytes.
+ * @param timeout Timout for frame to be received.
+ */
+typedef int (*video_api_capture_snapshot_t)(const struct device *dev, void *buffer, size_t buffer_size, k_timeout_t timeout);
+
 __subsystem struct video_driver_api {
 	/* mandatory callbacks */
 	video_api_format_t set_format;
@@ -408,6 +419,7 @@ __subsystem struct video_driver_api {
 	video_api_enum_frmival_t enum_frmival;
 	video_api_selection_t set_selection;
 	video_api_selection_t get_selection;
+	video_api_capture_snapshot_t capture_snapshot;
 };
 
 /**
@@ -885,6 +897,30 @@ static inline int video_get_selection(const struct device *dev, struct video_sel
 	return api->get_selection(dev, sel);
 }
 
+
+/**
+ * @brief start, capture one frame and stop
+ *
+ * @param dev Pointer to the device structure.
+ * @param buffer Buffer to receive the frame.
+ * @param buffer_size size of the buffer in bytes.
+ */
+static inline int video_capture_snapshot(const struct device *dev, void *buffer, size_t buffer_size, k_timeout_t timeout) 
+{	
+	const struct video_driver_api *api;
+
+	__ASSERT_NO_MSG(dev != NULL);
+	__ASSERT_NO_MSG(buffer != NULL);
+
+	api = (const struct video_driver_api *)dev->api;
+	if (api->capture_snapshot == NULL) {
+		return -ENOSYS;
+	}
+
+	return api->capture_snapshot(dev, buffer, buffer_size, timeout);
+}
+
+
 /**
  * @brief Allocate aligned video buffer.
  *

I have a hacked up version of my camera_to_ili9341, that is configured to use it and ST7796,''
This is the main.cpp:
main.zip

it appears to be somewhat working: