Estoy usando la placa LIS331HH y FRDM-K22F .
Puedo escribir en el registro de alimentación y encender el LIS331HH, también puedo escribir en el registro de control de interrupción (23h) y leer el valor que he escrito.
Por alguna razón, no puedo leer desde el registro INT1_CFG (30), el registro INT1_SOURCE (31) o cualquiera de los otros registros relacionados con interrupciones.
Sin embargo, parece que puedo escribirles un valor.
STATUS_REG (0x27) también devuelve siempre 0.
Me preguntaba si alguien se ha encontrado con este problema con este dispositivo. ¿Cómo haría para verificar que el dispositivo no esté dañado a nivel de hardware?
No estoy seguro de si debo publicar el código aquí, pero necesito hacerlo, házmelo saber.
¿Cómo haría para verificar que el dispositivo no esté dañado a nivel de hardware?
Nunca podrá eliminar por completo la posibilidad de que un dispositivo tenga una falla de hardware, sin importar cuántas pruebas realice (por ejemplo, considere fallas intermitentes o sutiles).
Sin embargo, en el tipo de situación que describe, podría:
Verifique que los voltajes de la fuente de alimentación de su sensor, los capacitores de desacoplamiento y el diseño de PCB coincidan con los requisitos explicados en su hoja de datos ( especialmente si no está utilizando una placa de conexión comercial comprobada para el sensor).
Use un osciloscopio para ver los niveles de la señal de la interfaz, la forma de onda, etc. y confirme que no hay problemas allí. Entonces...
Use un osciloscopio (o, en esta etapa, sería mejor un analizador lógico o la funcionalidad de decodificación de protocolo integrada en algunos osciloscopios) para capturar las secuencias de comando (en cualquier interfaz que esté usando para ese sensor, I 2 C o SPI) que son enviado por su código FRDM-K22F actual.
Compare las secuencias de comandos enviadas por su programa actual con las que se muestran en la hoja de datos del sensor. Esta comparación puede requerir la asistencia de un experto, ya que puede resultarle difícil confirmar que su programa definitivamente está enviando los comandos correctos.
También compare las diferentes secuencias de comandos que mencionó entre sí , ya que informa que los accesos a algunos registros parecen comportarse como se esperaba, pero otros no.
O:
Como se indicó anteriormente, primero verifique la alimentación, el desacoplamiento, el diseño de PCB, etc.
Como se indicó anteriormente, use un osciloscopio para confirmar que no haya problemas con las formas de onda de la señal de la interfaz.
Conecte temporalmente su sensor a un Arduino que funcione.
Use una de las bibliotecas Arduino existentes para ese sensor (por ejemplo, esta de SparkFun que usa la interfaz SPI) para tener confianza en el hardware de su sensor.
Suponiendo que su sensor funcione con ese código Arduino, luego use un osciloscopio o un analizador lógico como se mencionó anteriormente, para capturar las secuencias de comando cuando use el Arduino "en funcionamiento" y su biblioteca.
Compare las secuencias de comandos "en funcionamiento" iniciadas por Arduino con aquellas que no "funcionan" en el código FRDM-K22F actual, encuentre las diferencias y luego use enfoques de depuración estándar para corregir ese código.
O, si no tiene un osciloscopio o un analizador lógico, no puede recopilar las secuencias de comandos reales que se envían en la interfaz del sensor:
Revise visualmente las secuencias de comandos, especialmente en la inicialización, utilizadas por el código existente de otras personas (por ejemplo, en esa biblioteca Arduino que mencioné).
Compare esas secuencias con las utilizadas en el código FRDM-K22F actual.
Concentre su investigación en las diferencias encontradas entre esos dos conjuntos.
Por supuesto, esto solo puede ayudar a encontrar problemas que son visibles en el código, y asume que el código escrito por otras personas es correcto. Este es un enfoque de solución de problemas relativamente débil en comparación con mirar lo que realmente sucede en la interfaz, como se describe en las sugerencias anteriores de la lista.
Esa no es una lista exhaustiva de posibles enfoques de resolución de problemas, pero es de esperar que den algunas ideas sobre lo que se podría hacer en esta situación.