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

Estoy tratando de agregar una pantalla I2C a mi dron de control remoto. No puedo hacer que la pantalla funcione. Tomé el mismo código y lo copié en un núcleo stm32f303k8 y conseguí que la pantalla funcionara. Volví a mover el código al dron 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 marco 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 dron que no funciona. Los otros 2 son del núcleo de trabajo. ¿Qué pasa con la señal en el dron, el chip stm32f303cc? ¿Por qué es realmente ondulado? Ambos tienen resistencias de tracción de 2,2k y 4,7k. Específicamente, ¿por qué la línea amarilla debajo, imagen superior, dividir 50/50 entre alto y bajo en lo que parece ser el bit de reconocimiento? Gracias

mala comunicación

buena comunicación en stm32f303k8 nucleo

Más importante aún: ¿por qué la línea SDA no llega hasta el suelo?
Ojalá supiera. Originalmente, en ambos chips, utilicé un total de 4 resistencias de 4,7 k ohmios para aumentar el voltaje en las 2 líneas de los 2 chips. Luego cambié la resistencia a 2.2k ohmios en la línea sda en el gráfico superior. No hay cambios en la apariencia del gráfico del dron problemático. Incluso cuando configuré el bus a 10 khz, el gráfico del dron se veía igual. En el Nucleo, el I2C está en I2C1. En el dron, está en I2C2. También hay diferentes velocidades de autobús y configuraciones de reloj. No creo que eso deba marcar la diferencia. Parece un tira y afloja entre lo alto y lo bajo en el trasero.
"La línea amarilla es scl. La línea azul es el reloj". Pero "scl" es el reloj, así que no creo que te refieras a eso :-) Creo que te refieres a que la línea amarilla es SDA y la línea azul es SCL (el reloj), ¿sí?
sí, la línea amarilla es sda/non clock

Respuestas (1)

dividido 50/50 entre alto y bajo en lo que parece ser el bit de reconocimiento
[...]
Parece un tira y afloja entre alto y bajo en el reconocimiento

Correcto, y eso significa que el Maestro I 2 C en realidad no liberó la línea SDA, para que el Esclavo I 2 C realice el Ack.

A su vez, eso significa que los pines GPIO utilizados para el bus I 2 C en el I 2 C Master (probablemente ambos pines, pero ciertamente SDA) se configuraron incorrectamente y se dejaron en su valor predeterminado de "push-pull", y no se cambiaron a "drenaje abierto", como se requiere para la operación I 2 C.

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

Si confía 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 y erratas) o lo configuró incorrectamente (no lo uso, así que no puedo) No le diré qué configuración puede ser incorrecta).

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

Entonces, los puertos I 2 C son diferentes entre las configuraciones que funcionan 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 puertos que afectan solo a algunos puertos).

Wow, eso es extremadamente perspicaz. Muchas gracias. Compré un endoscopio solo para ver esto. Estuve investigando esto durante varias semanas aprendiendo todo tipo de cosas interesantes. Cuando el código fue creado por STM32CubeMX, era principalmente un proyecto predeterminado para el núcleo. El proyecto predeterminado de cubemx para la placa STM32F303cc tenía i2c2 en los pines pf0 anf pf1. Tuve que cambiarlos a PA9 y Pa10 para trabajar con los rastros de esos pines. esto está en drone entre la pantalla y la CPU.
Veré el código nuevamente, recuerdo que era básicamente el mismo. .. Etiquetado como drenaje abierto en ambos. Miraré esto más y veré qué es diferente. Tengo que aceptar que uno está en i2c1 y el otro en i2c2. Si logro que esto funcione, el código del dron original usaba la biblioteca periférica, no hal. En última instancia, tendré que averiguar cómo se configuró mal/aprender más sobre la configuración de configuración de gpio
@Jeffrey: me alegro de que la explicación haya ayudado. :-) ¡Conseguir ese alcance fue una buena idea! Re: "Etiquetado como drenaje abierto en ambos" Entonces, donde sea que haya visto eso, parece entender que debería usar drenaje abierto, pero el seguimiento del alcance confirma que SDA en realidad no estaba configurado para drenaje abierto. El propósito general de I2C que usa controladores de drenaje abierto es permitir que cualquier dispositivo I2C lleve completamente cualquier señal a la lógica baja, y su Esclavo no podría hacer eso, para Ack. Dado que tiene un ejemplo de un seguimiento I2C "bueno", sabrá cuándo se solucionó la configuración del "problema", ya que coincidirá con el seguimiento "bueno" (Ack completamente bajo).
Problema de I2C en el procesador STM32F303, ¿qué sucede con SDA?
RespuestasAquíPolítica de privacidad1y, 0v