PSoC6S4 Vector table of the cm0+ in flash.

There are actually several independent SRAM blocks and controllers inside the part (it is not just a single large SRAM). if you put the Video buffer in a different SRAM block from the vectors I suspect this will help. Unfortunately the datasheet and Technical Reference manuals do not tell you the addresses of the SRAM blocks. I have raised a documentation bug against this oversight, but I can't tell you when  updated documentation will be released. I would trial and error moving the locations of the video buffers in SRAM to see if that helps.

Thank you for sharing this information. Are you referring to what is said in the datasheet:

"■ SRAM Up to 128 KB of SRAM is provided. Power control and retention granularity is implemented in 32 KB blocks allowing the user to control the amount of memory retained in Deep Sleep. Memory is not retained in Hibernate mode."

In this case there should be 4 controllers... 

That was my thinking also, but I don't want to assume that is the correct answer. For an example, a single controller could control two 32k blocks. Until I get to see the answer formally documented, I don't want to give you possibly in-accurate information.

If your problem is actually SRAM access contention (which seems like a reasonable guess), then moving the video buffers to the highest addresses in memory, and the vectors to the lowest addresses should give you some information. 

Is it possible the CM0+ is servicing some higher priority interrupt, and you have to wait for that to complete before it starts the video interrupt? (just throwing out other ideas to explore).

Yes. SRAM access on different cores (or caused by DMA or otherm AHB masters) can influence interrupt latancy. I tested it on different PSoC for evaluating Profiler peripheral (which is unluckily not avalaible on part used in At The Core Design Challenge) and shown how SRAM accesses on one core affects performance of the other. For more details see my blog:  PSoC 6 Pioneer Kit Roadtest - Project 6 - Profiler

Interrupt latency is affected by multiple factors and vector table storage memory (and it's utilization) is one of them. It is very hard to achieve zero jitter on interrupt latency on Cortex-M. Some points why is it hard are described in ARM article: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

Thanks for the support. I think I will try first to leave vectors in the flash. I can't understand why this is not the standard configuration.

Anyway the PDL documentation shows how to configure an interrupt to use the vector table in the flash, but that doesn't work for me. Probably I am missing something.

https://infineon.github.io/mtb-pdl-cat1/pdl_api_reference_manual/html/group__group__sysint.html