I2C no funciona en mi primer diseño de PCB

Construí una placa de sensor simple que conecta un RFDUINO a dos componentes I2C. Un acelerómetro ADXL345 y un controlador táctil MPR121. La placa también incluye un LED RGB, un motor de vibración y un circuito cargador Li-Po.

El bus I2C parece no funcionar y no puedo leer el registro (usando la biblioteca de cables para Arduino) en los dos I2C. Si conecto un osciloscopio a las líneas I2C (usando algunas almohadillas expuestas en la PCB, vea la figura), puedo ver 3.3v pero no hay actividad en las líneas SCL y SDA.

En un prototipo de placa de prueba anterior, utilicé un escudo RFDUINO y placas de ruptura para ADXL345 y MPR121 y no presenté ningún problema.

Esquemático diseño de placa de circuito impreso

Esta no es la solución, pero no necesita dos conjuntos de resistencias pull-up si hay un conjunto que siempre estará conectado a VCC
¡Gracias! sí, lo descubrí después de enviarlo para la fabricación. Sin embargo, eso no debería interrumpir el bus I2C.
En realidad, puede afectar su bus I2C ya que esas resistencias no son arbitrarias. No estoy seguro de las especificaciones del bus I2C para RFduino, pero tener pull-ups demasiado fuertes o demasiado débiles puede hacer que su bus I2C sea inútil en cualquier sistema.
¿Qué tipo de batería estás usando?
La hoja de datos recomienda un pullup de 4.7k en SDA, y solo se requiere en SCL si hay varios maestros o si el maestro tiene una salida de drenaje abierto. Está utilizando pullups de 10k en SCL, SDA e INT
I2C es un protocolo irritantemente complejo. Realmente debería pensar en invertir en un analizador lógico si planea hacer tanto. Mi favorito personal. es Saleae Lógica.
¿Hiciste algún prototipo antes de imprimir la placa?
@SimoneMora ¿A qué velocidad de autobús está ejecutando el autobús I2C?
@Funkyguy El bus I2C funciona a 100 khz
@ScottSeidman Hice algunos prototipos de placas de prueba usando placas de ruptura para ADXL345 y MPR121 y eso no presentó ningún problema
@derstrom8 un LiPo de 100 Mha, pero también intenté encenderlo desde USB, el mismo problema ...
¿Error en la configuración? ¿Cortocircuitaste las resistencias? ¿Cuál es la resistencia SDA/SCL sin alimentación a VCC? Para un Atmel en modo I2C compatible con HW, debe tener más de 500 ohmios, o no podrá bajarlo lo suficientemente rápido. Menos de 50 ohmios (corto/casi corto) y ni siquiera verá un gran cambio en el voltaje. Y un dispositivo I2C que indica en la hoja de datos que solo necesita pull-up en SCL en ciertos casos no es un dispositivo I2C completamente calificado (y en mi opinión no debería usarse como tal, ya que el departamento de ingeniería estaba fuera de sus profundidades). )
Si yo fuera usted, escribiría un FW de prueba que escanea todas las direcciones I2C posibles y cambia un LED (o hace algo ) si tiene una coincidencia. Puede buscar qué direcciones hay en el bus muy fácilmente y hacerlas coincidir con la hoja de datos. Esto le ayudará a diferenciar entre un error de hardware (p. ej., una unión de soldadura en frío) y un error de FW (p. ej., no está utilizando las bibliotecas i2c correctamente). Creo que en arduino land puedes ver si Wire.endTransmission() devuelve 0 para una dirección. Si lo hace, entonces la dirección está en el autobús.
Pregunta realmente tonta, pero ¿tienes el cordón de soldadura en las almohadillas de puente?
Además, ¿no es necesario bajar !CS en el acelerómetro?
Si bien este probablemente no sea el problema en este caso, un pull-up excesivo puede evitar que el bus I2C funcione. Más en esta publicación .

Respuestas (2)

De la hoja de datos ADXL345:

El #CSpin siempre debe estar vinculado alto a VDDE/S o ser controlado por un controlador externo porque no hay un modo predeterminado si el #CSpin se deja desconectado.

Intente soldar VCC manualmente al IC si ha colocado una almohadilla que se pueda alcanzar. De lo contrario, probablemente necesitará encontrar una solución más creativa.

Gracias, esto es de hecho un defecto en mi diseño. Sin embargo, el segundo dispositivo I2C (controlador táctil) debería funcionar bien de todos modos o dejar el #CS desconectado podría interrumpir el bus I2C para todos los dispositivos.
@SimoneMora Hay otro problema entonces. Vuelva a verificar todas las conexiones y asegúrese de obtener una forma de onda que funcione con su osciloscopio.
@SimoneMora Un dispositivo esclavo I2C puede derribar todo el bus y evitar que otros dispositivos esclavos se comuniquen. Aquí hay una respuesta relacionada de forma remota que involucra ADXL345 . Una forma de probar esto es quitar el chip ADXL345 e intentar hablar con los otros esclavos I2C. Si puede hablar con ellos, entonces ADXL345 fue el culpable (de una forma u otra). En una nota relacionada, a juzgar por sus comentarios, aún no ha leído la especificación del bus I2C . Por favor, léalo (al menos hojearlo).
@NickAlexeev ¡Gracias! Leí las especificaciones de I2C y me di cuenta de que la amplitud de las señales (2,4 V) que recibo en SCL/SDA está bien. También descubrí que dejé la DIRECCIÓN CS y SDO/ALT desconectada. Traté de conectarlos a VDD (como en la hoja de datos, ¿debería agregar una resistencia también?) Y busqué la dirección I2C de RFDUINO pero aún no puedo ver el acelerómetro ni ningún otro dispositivo en el bus; pero no puedo confiar en mi trabajo de soldadura porque los pines son muy pequeños (paquete QFN). Desearía poder intentar quitar el acelerómetro, pero no tengo los equipos adecuados.

Si no hay actividad en el bus, los pines relevantes están altos y no están en cortocircuito a VCC, entonces el problema está en el firmware. (O está mirando los pines incorrectos, conectó los pines incorrectos, tiene el chip incorrecto, algo así).

Gracias, ahora leo algo de actividad en el autobús usando un alcance. Puedo ver el reloj, pero la amplitud de la señal es de aproximadamente 2.4v, probablemente no sea suficiente para que el RFDUINO sea captado, lo mismo para la línea de datos. Esto sucede tanto al alimentar el dispositivo a través de la batería como del USB. La frecuencia del reloj parece ser de 100 Hz, la resistencia de SDA/SCL a VCC sin alimentación es de 5K.
Te sugiero que lo cambies a 2.2k. 100 Hz es bastante lento. ¿Está seguro? ¿Y los datos que salen son correctos y lo que espera? Tienes que empezar con esto. Cuando intenta hacer una lectura I2C, ¿son correctos el reloj y los datos salientes? Hasta que lo esté, no te preocupes por nada más. Si es posible, desconectaría todo del bus, excepto los pullups, y probaría la señal saliente con un osciloscopio (y/o analizador) hasta que sea correcta. Hasta que se sepa que la señal de salida es correcta, no se espera una respuesta correcta.
I2C no funciona en mi primer diseño de PCB
RespuestasAquíPolítica de privacidad1y, 0v