A tiny STM32F103 issue, GPIO trigged DMA transfer rate!

[MT]

In a asynchronous GPIO/CC capture triggered DMA transfer (Flash/RAM to PWM1, circular, 256 bytes, one byte a time)
what kind of maximum (inc clock synchronisations and extra garbage and CPU on idle) DMA transfer speed could i expect?

I had estimated for a 72Mhz F103 GPIO triggered abut 4,5M cycles but when i tested i got only 1,5M cycles
then it seams DMA start to miss requests erratically, however when i do the same procedure with a Timer
triggering via CC match or update event i can easily do 8M cycles.

Can there be something in the input clock net chain that might cause this to slow down? Well, ST dont
provide any info on gate level! (no i'm not talking about the input filter( counters) or other pre scalers).

[MT]

Solved!..... Well, more or less!

[westfw]

How?

[MT]

By scratching my flea infested beard for hours until realizing there is something spokey going on in the input filter after all and then found out that TIM_CCMR1_IC1F's is not zero out of reset as acclaimed by RM0008 rather set to div 4 ratio! So a write of 0 to all IC1F bits at init time cured the mad cow. But i also found that TIM_CCMR1_IC1PSC only divratio that works is 0 and 8, most likely a hardware bug as well. Apparently the I2C silicon is garbage to so these 10 chips is going straight into the dumpster in couple of days no point in wrestling with old silicon! So until new silicon arrives, the DMA runs like crazy and try to complete all requests one throws at it, so i slowly bringing up more and more tasks for the CPU to complete and well see when the arbiter starts to choke it. The F2 series have lot better DMA design apparently. My application needs 3 independent and entirely asynchronous (is outside) 4,5M cycle
(at least, probably more) transactions that's GPIO triggered , i probably have to switch to a faster F4 chip.