Necesita ayuda para rastrear el origen de un retraso entre las interrupciones del temporizador en SAM MCU

Tengo un proyecto que genera una serie de valores para DAC con un intervalo de tiempo preciso. El problema es que a veces hay un retraso más largo de lo esperado entre la interrupción del temporizador del sistema en la que se actualizan los valores DAC. Esto conduce a fluctuaciones en la salida. Necesito ayuda para averiguar qué está causando este retraso. El único otro código de usuario que se ejecuta además del temporizador es el manejo de los paquetes USB entrantes que contienen los datos que se van a enviar.

Cosas que he probado:

  • Disminución de la prioridad de cada interrupción que no sea el temporizador
  • Deshabilitar cualquier tipo de modo de suspensión que pueda requerir tiempo para despertarse
  • Disminuir el tamaño del paquete USB para hacerlos más rápidos de procesar (aunque debido a que sus interrupciones tienen una prioridad más baja, no debería interferir con el temporizador de todos modos)

Pero nada ha funcionado hasta ahora.

El código completo está aquí: https://github.com/Grix/helios_dac/blob/master/firmware/AtmelStudio_helios/lasdac_mainfirmware/src/main.c

El MCU es un Atmel ATSAM4S2B (cortex-m4 de brazo de 32 bits)

¿Algunas ideas?

EDITAR: Encontré el problema, eran las prioridades de interrupción. Establecí las prioridades en el arranque, sin embargo, la función SysTick_Config() de la biblioteca CMSIS en realidad restablece la prioridad del sysstick cada vez que se llama, por lo que tuve que corregir manualmente la prioridad cada vez que llamé a esto.

¿Quiere decir que hay un retraso adicional entre las interrupciones consecutivas del temporizador del sistema? ¿O que hay un retraso extra entre la interrupción y algo más que ocurre? ¿Cómo estás midiendo el retraso para ser consciente de la inestabilidad? Considere alternar uno o más pines GPIO a lo largo del código y use un analizador lógico para observar las alternancias en tiempo real. Luego ajuste los puntos de alternancia para reducir el área del problema hasta que la fuente se aclare.
Si hay una demora adicional entre las interrupciones consecutivas del temporizador del sistema, ¿es posible que el controlador de interrupción anterior no finalice antes de que se confirme la siguiente ocurrencia de interrupción? El controlador de interrupciones no debe ejecutarse más tiempo que el período entre interrupciones.
@GrixM: ya que encontró el problema (bien hecho :-)), escriba una respuesta con esos detalles (y acéptela), en lugar de editar la respuesta en la pregunta. Aceptar una respuesta marcará la pregunta como "respondida" y también obtendrá puntos por la respuesta.

Respuestas (1)

Encontré el problema, eran las prioridades de interrupción después de todo. Establecí las prioridades en el arranque, sin embargo, la función SysTick_Config() de la biblioteca CMSIS en realidad restablece la prioridad del sysstick cada vez que se llama, por lo que tuve que corregir manualmente la prioridad cada vez que llamé a esto.

Necesita ayuda para rastrear el origen de un retraso entre las interrupciones del temporizador en SAM MCU
RespuestasAquíPolítica de privacidad1y, 0v