Actualización:
Seguir el plan en mi respuesta original a continuación, lo llevará a una solución. Sin embargo, me di cuenta de algo que se puede deducir de una declaración en su pregunta y que podría sugerir un problema potencial más rápidamente:
La SDA y SCL se han recuperado en la inicialización.
Sobre la base de esa declaración, sospecho que está utilizando las resistencias de recuperación incorporadas en el MCU ATSAME54 , ya que las incorporaciones externas no se inicializarán en el código.
La actual Hoja de datos de la familia SAM E5x indica que los pull-ups internos estarán entre 20kΩ y 60kΩ, típicamente 40kΩ. Por experiencia, ese rango de valores es demasiado alto para la operación confiable del bus I2C, excepto para los buses más lentos y cortos.
La verificación de las formas de onda de la señal I2C con un osciloscopio, como se menciona en mi respuesta completa, le permitirá verificar si tiene o no un problema en esta área. Sin embargo, me sorprendería si el uso de las flexiones internas no es no al menos parte de su (s) problema (s).
Si no tiene un osciloscopio, podría volver a realizar la prueba después de calcular y agregar resistencias de pull-up externas adecuadas a las señales I2C. Sin embargo, puede haber múltiples problemas, por ejemplo. puede solucionar un problema uno (reemplazando el uso de resistencias de pull-up internas, con resistencias de pull-up externas adecuadas) y aún no tendrá éxito. En ese caso, no puede asumir que el uso original de las resistencias internas de pull-up no fue un problema.
Respuesta original:
No he usado ese API / framework de software ASF4, pero te diré cómo abordaría esto si estuviera en tu situación.
Necesitas ver qué sucede realmente en el bus I2C, para entender exactamente qué envía tu código maestro I2C y qué (si acaso) es el esclavo I2C obra. Aunque está obteniendo un código de retorno, muchas veces he visto códigos de retorno que no con precisión especifican el problema, y pueden verse mejor diciendo que simplemente "algo salió mal".
Si no está 100% seguro de la validez eléctrica del bus I2C, use un osciloscopio para ver las características de la señal analógica, por ejemplo. niveles de tensión, tiempos de subida / bajada, interferencias entre las señales, etc.
Una vez que esté seguro de que el bus I2C está eléctricamente bien, puede usar un analizador lógico o equivalente (p. ej., MSO), o incluso un osciloscopio estándar nuevamente, para ver y descodificar el protocolo I2C para comprender mejor lo que está sucediendo en ese nivel . (Los analizadores lógicos baratos capaces de decodificar I2C, aunque tienen limitaciones, se pueden comprar por solo unos pocos dólares y se pueden usar con el software de código abierto Sigrok).
Compare la actividad que ve en el bus I2C con lo que debería suceder, como se muestra en la especificación I2C y en la documentación para ese esclavo I2C específico (algunos comportamientos pueden variar entre diferentes esclavos I2C y no están fijados en la especificación I2C solo).
De esa manera, puede encontrar donde el bus I2C primero se desvía del comportamiento esperado, y puede concentrarse en la h / w o s / w responsable de esa parte específica.