Problema I2C en el procesador STM32F303, ¿qué sucede con SDA?

Navega tus respuestas
2

Estoy tratando de agregar una pantalla I2C a mi dron de control remoto. No consigo que la pantalla funcione. Tomé el mismo código y lo copié en un núcleo stm32f303k8 y conseguí que la pantalla funcionara. Moví el código de nuevo al drone y lo probé en el procesador STM32F303cc. No funciona Las señales a continuación forman exactamente la misma línea de código que pasa por I2c en ambos chips. Bueno, recompilado en el framework cubemx para los diferentes chips, por supuesto. La línea amarilla es scl. La línea azul del reloj. La línea amarilla con los garabatos es del drone que no funciona. Los otros 2 son del núcleo de trabajo. ¿Qué está mal con la señal en el avión no tripulado, el chip stm32f303cc? ¿Por qué es realmente ondulado? Ambos tienen resistencias de tracción 2.2k y 4.7k. Específicamente, ¿por qué la línea amarilla de abajo, la imagen superior, se divide 50/50 entre alta y baja en lo que parece ser el bit de confirmación? Gracias

    
pregunta Jeffrey Edward Messikian

1 respuesta

4
  

divide 50/50 entre alto y bajo en lo que parece ser el bit de confirmación
  [...]
  Parece un tirón de guerra entre alto y bajo en el ack

Correcto, y eso significa que el I 2 C Master no liberó realmente la línea SDA, para el I 2 C Slave para realizar el Ack.

A su vez, eso significa que los pines GPIO utilizados para I 2 C en el I 2 C Master (probablemente ambos pines, pero ciertamente SDA) eran < em> se configuró incorrectamente y se dejó en su valor predeterminado "push-pull", y no cambió a "open-drain", como se requiere para la operación I 2 C

.

Eso es lo que causa el "tira y afloja" como lo describiste, o como glen_geek dijo: "¿por qué la línea SDA no se arrastra hasta el suelo?" La respuesta es que SDA (y probablemente SCL también, pero la mayoría de los esclavos no intentan conducirlo) sigue siendo accionado (por un pin GPIO todavía configurado como "push-pull") y no se libera (solo con activación pasiva) como lo sería un pasador de "drenaje abierto".

Si está confiando en STM32CubeMX para escribir el código de inicialización, entonces acaba de descubrir un error en la versión que está usando (busque actualizaciones & errata) o bien, configúrelo incorrectamente (no lo uso) , así que no puedo decirle qué configuración puede estar equivocada).

  

En el Nucleo, el I2C está en I2C1. En el drone, está en I2C2.

Por lo tanto, los puertos I 2 C son diferentes entre las configuraciones de trabajo y las que no funcionan. Eso podría explicar fácilmente por qué su problema aparece solo en una configuración, si el marco STM32CubeMX no está inicializando correctamente I2C2 (y ha habido errores de inicialización de puerto que afectan solo a algunos puertos).

    
respondido por el SamGibson

Lea otras preguntas en las etiquetas

Oscilador disciplinado usando contador + micro Usar la transformada de Fourier para resolver la corriente en un circuito con condición inicial