DCMI priority versus SDMMC (STM32N6)

[exarian]

Good day folks,

I have the DCMI camera interface on a STM32N6 streaming to the SDCard, and I am noticing that there are cases that the DCMI reports an Overrun when a SD access occurs at the same time that the Hsync interrupt was meant to occur.

Digging into it I believe its due to congestion on the underlying AXI bus, and the IDMA of the SDMMC taking priority over the DCMI DMA. I have set the DCMI and its DMA to the highest possible priority as below.

 HAL_NVIC_SetPriority(GPDMA1_Channel12_IRQn, 0, 0);
 HAL_NVIC_EnableIRQ(GPDMA1_Channel12_IRQn);

 HAL_NVIC_SetPriority(DCMI_PSSI_IRQn, 0, 0);
 HAL_NVIC_EnableIRQ(DCMI_PSSI_IRQn);

 HAL_NVIC_SetPriority(SDMMC1_IRQn, 5, 5);
 HAL_NVIC_EnableIRQ(SDMMC1_IRQn);

 gpdma_dcmi.Instance = GPDMA1_Channel12;
 gpdma_dcmi.Init.Request = GPDMA1_REQUEST_DCMI_PSSI;
 gpdma_dcmi.Init.BlkHWRequest = DMA_BREQ_SINGLE_BURST;
 gpdma_dcmi.Init.Direction = DMA_PERIPH_TO_MEMORY; 
 gpdma_dcmi.Init.SrcInc = DMA_SINC_FIXED;
 gpdma_dcmi.Init.DestInc = DMA_DINC_INCREMENTED;
 gpdma_dcmi.Init.SrcDataWidth = DMA_SRC_DATAWIDTH_WORD;
 gpdma_dcmi.Init.DestDataWidth = DMA_DEST_DATAWIDTH_WORD;
 gpdma_dcmi.Init.Priority = DMA_HIGH_PRIORITY;
 gpdma_dcmi.Init.SrcBurstLength = 1;
 gpdma_dcmi.Init.DestBurstLength = 8;
 gpdma_dcmi.Init.TransferAllocatedPort = DMA_SRC_ALLOCATED_PORT1 | DMA_DEST_ALLOCATED_PORT0;
 gpdma_dcmi.Init.TransferEventMode = DMA_TCEM_BLOCK_TRANSFER;
 gpdma_dcmi.Init.Mode = DMA_NORMAL;

From what I can see the IDMA priority of the SDMMC cannot be configured, and when it comes to access on the AXI bus it is round robin. I am using the `HAL_SD_WriteBlocks_DMA()` interface. 

I have been trying to research which Arm Cortex M55 registers I can configure to adjust the priorities, however I have had no luck yet.

 

There is a recovery if a frame is dropped to continue streaming, however it would be great not to drop frames due to bus contention.

Any hints would be great! Thank you in advance.

[Len_Heske]

Hello @exarian,

I haven't tried to implement a camera myself yet. A quick look into the camera subsystem section of the RM0486 revealed that there are specific limitations to the DCMI. Are you sure you are not going over these restrictions?

RM0486 p.1783

"

The camera subsystem is built around a double path:
• a low-resolution path, with the DCMI and a low-frequency parallel interface. It supports sensors up to 24 Mpixel/s.
• a high-resolution path, with the DCMIPP and a high-frequency parallel interface or serial CSI-2 interface, either RGB or RawBayer. It targets sensors up to 5 Mpixels at 30 fps.
When plugging a camera sensor, it is recommended to use the DCMIPP, a higher performance pipe.
The previous DCMI is recommended only in two noticeable cases:
• to get a backward compatibility with former platforms that embed also the DCMI
• to input the pixels from a second camera sensor
Note:
The DCMIPP inputs pixels from one sensor via the CSI-2 interface, while the DCMI gets
pixels from the second sensor via the parallel interface.
The DCMI path offers the following summarized maximum features:
• Target sensor: 24 Mpixel/s 16 bpp (limited by the DMA)
• Parallel input: 80 MHz on 14-bit input capability
• Central DMA to extract and dump its pixels
• Software extraction of its pixel data
The DCMIPP path offers the following summarized maximum features:
• Target sensors: 5 Mpixel at 30 fps max
• Parallel input: 120 MHz on 16-bit input capability
• Serial input: CSI-2 at 2.5 Gbps/lane on 2 data lanes
• ISP (image signal processor): demosaicing, exposure, white-balance, contrast, bad-pixel
• Application pipes: 2 pipes with crop, downsize, gamma, YUV conversion, YUV420
Some over-target use cases are possible, but with specific constraints:
• sensors with resolution above 5 Mpixels
• sensors with pixel rate above 150 Mpixel/s
• double sensors in parallel

"

By the way, you said, you tried to research which registers to configure. I suggest not to search for any general Arm Cortex M55 information. If you want to find out more about the N6 series registers always consult the RM0486. It contains information about all the registers. I'm a big fan of using registers instead of HAL. I will help you if any questions come up :) There are a few rules to follow when coding with registers.

 

Kind regards

Len

[exarian]

Thank you @Len_Heske for your feedback.

Yes I am quite certain I am operating within those bounds, as the camera streams successfully for a long period of time, until there is a contention with the SDMMC.

It is a rare occurance I am seeing every few hours, however it is reproducible.

Is there an AXI or AHB arbiter on the STM32N6 that can be configured to prioritize the DCMI over the SDMMC?

For example if the latter is doing burst sequential transactions, that exceed the 8 word DCMI FIFO time?

I am using the DCMI HAL and the SDMMC HAL.

Basically it appears that the DMA is getting stalled in these cases,  until the DCMI Overrun flag is cleared.

What happens at the bus level when an interrupt from the SDMMC triggers the AHB, and then shortly after the DCMI triggers the AHB? I'm assuming the SDMMC hold the bus until it's done?

 

 

 

[Mikk Leini]

I know N6 has different bus architecture, but when doing similar thing and with another simultaneus stream on H7R, the solution against congestion was to unload everything else from the AXI and AHB buses. All code and ISR tables in ITCM, all data and stack in DTCM, no peripheral register access or interrupts were allowed, except DMA final 2D sequence completion or error. Even circular and linked list DMA solutions failed as it had to access registers after each block. Only systick, as it's tightly coupled to CPU, was okay to interrupt.

The problem was/is that at least H7 DCMI has tiny FIFO and bus access wait time longer than few clocks causes overrun. So bus has to be kept free.

[exarian]

Thank you @Mikk Leini for your feedback.

Congestion is definitely a real thing that needs to be considered. It is only when things like Overruns occur do you wander into the land of the AXI and the AHB. Before then it just is magical and works.

Your suggestion regarding the ITCM/DTCM will also be considered!

My next plan of action is to replace the DCMI implementation I have with the DCMIPP.

The latter has a 5120 byte FIFO versus the 8 word FIFO of the DCMI.

 

Hopefully then if a long SD Card transaction takes place, then at least the  larger FIFO can tolerate it.

Another option is to reduce the SD transaction size.

I see that the DCMIPP also has a QoS for the AXI bus. Does this mean it would be given priority at a bus level if a SD transaction was already underway?

However the manual (RM0486 Rev 3) is vague on how this QoS is used, besides: