Esto es solo un tiro en la oscuridad, porque hay muchas posibilidades de software y hardware. Por favor, no vote "abajo" mi respuesta, ya que solo trato de ayudarlo a solucionar problemas, incluso si no puedo ofrecer una solución segura.
Desde el punto de vista del software, me viene a la mente que cualquier procesamiento que se active después del cruce por cero en la detección, no siempre se completa lo suficientemente rápido como para estar listo para la próxima detección. No dijo si la detección de cruce 0 desencadena una interrupción de hardware o simplemente se detecta y trata dentro de un bucle de muestreo. La metodología de interrupción seguramente empeoraría las cosas si no tomara medidas para garantizar que la rutina de servicio de interrupción (ISR para abreviar) no se pudiera interrumpir nuevamente antes de completar. Pero incluso en un bucle simple, es posible que un error en la lógica del programa cause una "explosión" de la pila, si una subrutina puede llamarse a sí misma para responder a un evento (recursión) sin ninguna limitación. Para probar cosas como esta, es posible que tenga que agregar un LED o dos a su sistema que se puede controlar mediante programación con muy poca sobrecarga. Esto le permitirá hacer cosas como encender un LED cuando ingresa en una rutina y apagarlo cuando complete. O si se permite la recursión, encienda el LED cuando se exceda un contador de límite estático. Al menos, esto le dirá si siempre es la misma rutina o punto en el programa en el que se está atascando. Puede ser una tarea ardua y larga dividir sucesivamente un problema como este en posibilidades, para finalmente aislar el código del problema. Pero una vez que tenga algo como uno o dos LED adicionales para disparar, puede volver lentamente a la información que necesita para identificar el problema.
Ahora, también existe la posibilidad de que haya un problema de hardware insidioso aquí. Una regla de oro para mí (aunque no siempre es fácil de saber) es que cuanto más aleatoria es la naturaleza de una falla, más probable es que sea un problema de hardware. Por el contrario, cuanto más previsible sea un fallo, más probable es que esté programando. Ahora dijo "después de un tiempo" se bloquea y se bloquea. Si este "while" siempre es de 1.745 segundos (solo un número de ejemplo), entonces sospecharé que está programando. Pero si "en cualquier lugar es instantáneamente a muchos segundos después", luego consideraría algunos problemas de hardware. Por ejemplo, si el problema es realmente dependiente de la carga, puede ser que bajo carga el motor esté generando más emi o picos de ruido en el bus de alimentación, cualquiera de los cuales podría regresar a su electrónica o MCU.
Buena suerte, y espero que algo de esto ayude.
