I'm using DMA to send data to GPIOF which is configured as a parallel bus. DMA is being driven by update events on TIM8. TIM8 is configured in slave mode and starts on an output compare event from TIM1. And TIM1 runs in input mode, being reset by a falling edge on pin A9, and capturing the width and duty cycle of the pulse on A9.
TIM1 also raises an interrupt on input capture events. Then I check the width and duty cycle of the last pulse to determine whether I am currently in active video or not, and re-enable DMA for the next scanline if I am.
For context, this is for a video graphics application. GPIOF outputs pixels driven by a pixel clock (TIM8), in time with sync pulses from an external composite video source (pin A9).
Mostly this all works like clockwork. But I noticed that when I enable DMA in the interrupt, a single byte gets sent to GPIOF by DMA immediately. The rest of the bytes in the scanline buffer are sent at the expected time, when TIM8 starts running.
Here is a logic analyzer session showing what happens. CSYNC is the pulse going to pin A9. PCLK is a pin being toggled by TIM8. PIXEL0 is pin 0 on GPIOF. The first black band is (roughly) the time when the interrupt occurs and DMA is enabled. The second black band is when TIM8 is gated on by an output compare on TIM1.
What is the reason that PIXEL0 turns on shortly after DMA is enabled, causing a very wide pulse which continues until PCLK starts?