Detección de desbordamiento de DMA en la generación de forma de onda arbitraria

Estoy generando una serie compleja de pulsos en un STM32F103, esencialmente como se describe en la nota de la aplicación ST AN4776 Libro de cocina del temporizador de uso general , sección 5.3. Como resumen rápido, eso significa que estoy usando el modo de ráfaga DMA del temporizador para transferir nuevos valores a ARR, RCR y CCR1 después de cada evento de actualización del temporizador. Se proporciona una descripción más detallada al final de la pregunta, en caso de que no esté familiarizado con la nota de la aplicación.

Mi problema está relacionado con el ancho de banda DMA: los pulsos que genero pueden, en principio, estar espaciados arbitrariamente, incluido solo 1 ciclo de reloj (el temporizador tiene un preescalador de 1). Por supuesto, en este caso, el DMA no puede llegar a tiempo para transferir los datos para el siguiente pulso, y habrá fallas en la salida. Dado que mi aplicación puede tolerar pequeños errores de tiempo infrecuentes, preproceso mis pulsos de modo que el intervalo de pulso más pequeño sea un mínimo fijo (estoy usando 96 tics de reloj en este momento) para darle una oportunidad al DMA. Sin embargo, sigo teniendo fallas que creo que se deben a la DMA, y aumentar el tiempo mínimo incluso a números muy grandes no parece estar ayudando.

La parte clave de la oración anterior es "... Creo que ...". Así que me gustaría encontrar una manera de saber con seguridad si el DMA ha perdido su transferencia o no, preferiblemente algo que pueda dejar en el código siempre ejecutándose, de modo que encuentre fallas muy poco frecuentes.

Lo que he pensado/probado hasta ahora es:

1. Mirando los registros de error de DMA. Sin embargo, no parece haber un indicador de "transferencia perdida" o algo similar, lo cual tiene sentido ya que la mayoría de las veces no es un error si una transferencia está pendiente por un tiempo. Además, incluso en mi caso no es necesariamente un error si la transferencia está pendiente por un tiempo, así que supongo que esto no me va a ayudar.
2. Estoy ejecutando esto en dos temporizadores diferentes, TIM8 y TIM1, emitiendo pulsos en dos pines diferentes. Las secuencias de pulsos que estoy preparando siempre tienen una duración total de 0,5 ms (para que pueda reaccionar a eventos externos dentro de 1,5 ms), es decir, hay un pulso inactivo si es necesario, de modo que una de las actualizaciones del temporizador ocurre exactamente en el límite de 0,5 ms . El TIM8 es el maestro, y de hecho cronometro mi bucle principal esperando que la cola DMA esté en el límite de 0,5 ms, es decir, esperando un valor específico del registro DMA CNDTR (lo he comprobado con un osciloscopio, alternando un pin en el bucle principal, que esto funciona y es preciso). Ahora, cuando llegué al momento adecuado según TIM8, sé exactamente dónde debería estar la cola TIM1, por lo que puedo verificar su CNDTR.
3. En qué estoy trabajando ahora: configuro otro temporizador como referencia y uso su canal de captura para obtener el valor del temporizador de referencia cada vez que se afirma la señal de actualización de TIM8. El valor capturado siempre debe ser exactamente uno de los instantes del pulso y, especialmente, puedo comprobar el último valor capturado en el bucle principal en los límites de 0,5 ms. Usando otro temporizador, puedo hacer la misma verificación en TIM1. La desventaja aquí es que esto todavía no garantiza que las transferencias se hayan completado, ya que los registros en el temporizador principal se actualizan en el orden ARR, RCR, CCR1. Entonces, si ARR se actualizó pero se omitió CCR1, los instantes de pulso en sí mismos serían correctos, aunque las longitudes de pulso de salida no lo serían.

Por supuesto, las fallas que veo podrían deberse a un error en el código que genera los búferes que el DMA envía a los temporizadores. Pero esa es exactamente la razón por la que me gustaría saber con seguridad si al DMA le faltan algunas transferencias o no, para saber si estoy buscando un error en mi código o no. El código en sí pasa un conjunto razonablemente completo de pruebas unitarias, por lo que el error sería sutil si estuviera allí.

Entonces, ¿alguna idea para verificar si mi problema se debe a fallas de DMA o no?

Detalles de lo que estoy haciendo exactamente:

Estoy generando una serie de pulsos, cada uno determinado por la duración de la fase de "encendido" (ancho de pulso) y el tiempo (en tictac del reloj) hasta el siguiente pulso. En términos de estructuras de datos

struct pulse {


     /*
     * These are an image of the timer registers.
     * We don't use repeats but it must be there
     * since the DMA transfers it anyway
     *
     * TODO: support other capture/compare channels than 1
     */


    uint32_t length; //ARR
    uint32_t repeats; //RCR, we don't use this
    uint32_t pulsewidth; //CCR1
};

//Check that pulse is of the correct type for the DMA stream
static_assert(std::is_pod<pulse>::value, "pulse must be POD");
static_assert(sizeof(pulse) == 12, "pulse must not be packed");

pulse pulseArray[MAX_PULSES];

Entonces, el modo ráfaga de TIM8 (y correspondientemente, TIM1) nos permite configurar el siguiente esquema:

1. El canal DMA del temporizador está programado para moverse desde pulseArrayel registro TIM8_DMAR "Dirección DMA para transferencia completa", en modo circular (por lo que, por supuesto, tengo que seguir llenándolo con nuevos datos de manera circular similar)
2. el "registro de control DMA" TIM8_DCR se programa con una longitud de ráfaga de 3 y la dirección base TIM8_ARR (consulte la hoja de datos RM0008, página 360-361 para obtener una descripción detallada de estos registros), y la solicitud de actualización DMA se habilita a través del bit 8 de TIM8_DIER
3. Ahora, en cada actualización del temporizador, debido al modo ráfaga programado anteriormente, el temporizador activa la solicitud DMA 3 veces transfiriendo, en este orden, los campos length, repeatsy pulsewidth, y el modo ráfaga dirige estos a los registros TIM8_ARR, TIM8_RCR y TIM8_CCR1 . Dado que hemos habilitado la precarga tanto en el temporizador (TIM8_CR1 bit 7) como en el canal de comparación (TIM8_CCMR1 bit 3), los datos se transfieren al registro de precarga y se activan en la próxima actualización (es decir, cuando se completa el pulso actual). )

Las Figuras 30 y 33 en la nota de la aplicación son muy esclarecedoras para comprender lo anterior.

Y ahora puedo exponer el problema con un poco más de detalle: suponga lengthque es, por ejemplo, 1. Luego, la cantidad de ciclos de reloj disponibles para que el DMA transfiera el siguiente pulso (que en realidad está 2 posiciones por delante en el búfer debido a la precarga registros, pero eso no es importante aquí) es uno (suponiendo que el preescalador del temporizador es 1, que es en este caso). Obviamente, es imposible que el DMA transfiera 3 palabras de 16 bits en un ciclo de reloj y, por lo tanto, se repiten los valores del ciclo anterior. Llamemos a eso una "falla de DMA", a falta de un término mejor.

Por otro lado, debe haber un mínimo lengthtal que durante cualquier pulso más largo que ese, el DMA tendrá tiempo para transferir todos los datos. Desafortunadamente, este mínimo lengthdepende de los horarios exactos de los autobuses, otro tráfico DMA y sus prioridades, por lo que es realmente difícil determinar esa longitud con lápiz y papel.

Por lo tanto, me gustaría encontrar una manera de detectar, con la mayor certeza posible, que no ha ocurrido una "falla de DMA", para poder ajustar mi mínimo lengthy, al mismo tiempo, asegurarme de que se produzcan otros problemas técnicos. que estoy viendo no se deben a una "falla de DMA".