Problemas con la placa convertidora RS232 a TTL casera basada en MAX232 de TI

Diseñé una placa convertidora RS232 a TTL basada en el IC MAX232 de TI que planeo usar para programar algunas placas Arduino personalizadas que tengo. Sin embargo, tengo problemas con la placa y espero que alguien pueda ayudarme a solucionarlo.

Primero, déjame mostrarte mi configuración, a continuación.

mi configuración

Aquí hay una breve descripción de lo que hay en la imagen:

  • Tablero de destino (A) : es un tablero ATmega328P independiente personalizado (un reloj) que tengo la intención de programar usando la programación en serie y el IDE de Arduino. Se conecta a la Placa B a través de un cable tipo FTD a través del Conector (H) .

  • Placa convertidora de RS232 a TTL (B) : es la placa convertidora de RS232 a TTL basada en MAX232 que diseñé y estoy tratando de depurar. Es el tema principal de esta pregunta. Está conectado a la placa de destino (A) con el cable tipo FTDI a través del conector (G) y al cable USB a RS232 (C) a través de un conector hembra DB9 (F) .

  • Cable USB a RS232 (C) : no tengo un puerto COM adecuado en mi PC, así que eso es lo que uso para obtener un puerto serie. Se conecta a la PC a través de un conector USB (D) ya la Placa B a través de un Conector DB9 Macho (E) .

Los esquemas de la placa B están a continuación.

Tarjeta convertidora de RS232 a TTL (B)

El esquema del encabezado de programación en la placa de destino (A) se muestra a continuación.

Encabezado de programación en serie ATmega328P en la placa de destino (A)

Lo primero que me di cuenta es que el cable USB a RS232 (C) es del tipo económico . En lugar de entregar niveles de señal estándar RS232 en el rango de -12V/+12V, entrega 0V/5V. Supuse que usando la siguiente prueba: conecté el cable USB a RS232 (C) a la PC y desconecté el conector DB9 macho (E) de la placa convertidora (B) y probé el pin 3 del conector DB9 macho (E) mientras enviaba una serie de caracteres ASCII 'A'a través del monitor serial. A continuación se muestra la toma de alcance resultante de esta prueba.

Caracterización de la señal del cable USB a RS232

Por cierto, he notado que los diversos IC MAX232 fabricados por varios proveedores están diseñados para hacer frente a esta violación de los niveles de señal RS232 y también aceptan señales de 0V/5V. A continuación hay dos tomas de alcance que usé para probarlo. En la primera toma, apliqué una onda cuadrada de 0V/5V en el pin 13 del MAX232 (mientras estaba insertado y alimentado por mi placa convertidora) con mi generador de funciones casero (ruidoso, sí), ese es el rastro amarillo, y verifiqué la salida del pin 12 ( Nivel TTL RX - rastro verde). Para mi sorpresa, el MAX232 de TI responde con las señales TTL correctas. El segundo disparo es una señal RS232 -6V/+6V correcta simulada por una onda cuadrada que inserté en el mismo pin. Ambos dan los mismos resultados.

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

Hice algunas otras mediciones en mi placa convertidora (B) hasta el punto en que quedé satisfecho con ella. Por ejemplo, el pin 2 en MAX232 muestra +9.5V mientras que el pin 6 muestra -9.5V. El osciloscopio muestra que el duplicador de voltaje y el inversor también funcionan bien, con una onda cuadrada agradable y constante de 40 kHz en cada caso. También apliqué una onda cuadrada de 0/5 V de aproximadamente 68 kHz al pin 10 del MAX232 y al pin 7 del MAX232. Obtuve una buena y limpia señal invertida -6V/+6V RS232 (las imágenes no se muestran aquí).

Luego probé el eco del monitor en serie acortando los pines TX/RX en varios puntos. Los resultados donde:

  1. Sin MAX232 IC en su zócalo, acorté los pines 2 y 3 en DB9. eco bien.
  2. Coloqué MAX232 IC en el tablero y acorté sus pines 11 y 12. Echo ok.
  3. Con ATmega328P fuera de su zócalo, acorté los pines 2 y 3. Echo ok.

Luego conecté la configuración para programar mi placa de destino ATmega328P (A) . El resultado de avr-dude se muestra al final de esta publicación. A continuación se muestra un resumen con solo el mensaje de error:

...
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
...
avrdude: stk500_cmd(): protocol error

Durante este intento de programación, medí las señales a continuación. El rastro amarillo son los datos que se envían a la MCU, mientras que el rastro verde son los datos que recibe:

ingrese la descripción de la imagen aquí

Cuando recibo el error, hay una interrupción repentina en la comunicación. De un intento a otro, el problema ocurre en diferentes puntos durante la comunicación.

Finalmente, reemplacé mi placa MAX232 con una más antigua que tengo, que usa el truco del transistor en lugar del MAX232 IC, y todo comienza a funcionar correctamente. Con la placa anterior puedo programar la placa de destino. A continuación se muestra la captura de alcance que muestra la comunicación exitosa durante la programación de la placa de destino en este caso.

ingrese la descripción de la imagen aquí

Ciertamente estoy pasando por alto algo, pero no puedo decir qué es. Entonces mi pregunta es: ¿qué pasa con mi configuración? ¿Qué más puedo comprobar o medir para resolver el problema?

Aquí está el IDE de Arduino y la salida avr-dude:

Binary sketch size: 9.946 bytes (of a 32.256 byte maximum)
C:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CC:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P\\.\COM5 -b115200 -D -Uflash:w:C:\Users\Ricardo\AppData\Local\Temp\build2465731745810216807.tmp\DefusableClock_v2.cpp.hex:i 

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM5
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
avrdude: Send: A [41] . [80]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [83] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [84] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [04] 
avrdude: Recv: . [90] 

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
avrdude: Send: A [41] . [98]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [10] 
         Hardware Version: 131
         Firmware Version: 132.1077487570
avrdude: Send: A [41] . [84]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [85]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [86]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [90] 

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
avrdude: Send: A [41] . [87]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [03] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [89]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [83] 
avrdude: Recv: . [10] 
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 921.600 kHz
         SCK period      : 142.2 us

avrdude: Send: A [41] . [81]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [04] 
avrdude: Recv: . [10] 
avrdude: Send: A [41] . [82]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [04] 
avrdude: Recv: . [10] 
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: Send: P [50]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20] 
avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10] 
################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [10] 
avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [00] 
avrdude: Recv: . [90] 
avrdude: stk500_cmd(): protocol error
Bien documentado.
@tcrosley ¡Gracias! Hice lo mejor que pude, pero todavía había algunos puntos oscuros que traté de aclarar con mi última edición.
¿Hay alguna razón por la cual la línea de "reinicio" tiene voltajes RS232 y no pasa por el convertidor? ¿El Arduino necesita un voltaje más alto para programar o algo así?
@markrages: ese es un buen punto. No sé. Lo extrañé por completo. Trataré de desenterrar de dónde viene ese diseño, o si es mi propia creatividad .
Si bien el circuito de reinicio que tiene podría absorber el voltaje del controlador RS232 sin dañarlo, un problema quizás pasado por alto es que los controladores y receptores RS232 tradicionalmente invierten . Entonces, la lógica de la línea de reinicio puede estar al revés de lo que espera el software. Tiene un canal receptor sin usar, tal vez debería usarlo. También asegúrese de que el software esté impulsando una de las posibilidades de RTS o DTR para las que está conectado. Si puede preprogramar un boceto que interactuaría en la serie, puede realizar una validación adicional.
@ChrisStratton: de todas las cosas en mi tablero, el reinicio es el único que funciona (al menos aparentemente). El IDE de Arduino parece restablecer con éxito la placa antes y después de cargar el firmware. Pero sí, no he considerado el hecho de que el voltaje de reinicio RS232 puede haber dañado mis MCU. Voy a investigar eso. ¡Usar el segundo controlador es una buena idea para eso! ¡Gracias!
Con una señal invertida, esperaría que aún se reiniciara, pero en el momento equivocado (qué tan mal dependería de cuándo la señal se conduce en lo que normalmente es la dirección inactiva, que con la inversión se convertiría en la activa).
@ChrisStratton: según este artículo de Wikipedia sobre RS232 , las señales de control tienen una polaridad opuesta a las señales de datos, por lo que el reinicio (DTR) no está invertido. Pero los niveles aún pueden dañar la MCU.
@Ricardo: todavía están invertidos eléctricamente cuando pasan por el controlador de línea o el receptor, es solo que su sentido activo es opuesto a las líneas de datos. Avrdude ya sabe que tiene sentido opuesto, pero esperará que esté invertido en el traductor de niveles al igual que los demás.
@ChrisStratton - Punto tomado. Pero no he visto la línea de reinicio pasando por el inversor en los diversos diseños de MAX232 que he encontrado. Investigaré un poco más ya que me preocupa el voltaje de reinicio que estoy aplicando a mis MCU.
Consulte, por ejemplo , ftdichip.com/Support/Documents/DataSheets/Cables/DS_UC232R.pdf, donde las líneas de datos y estado pasan por canales idénticos del convertidor de nivel. Creo que cuando las personas usan ese chip serie USB con un Arduino y sin cambio de nivel, no invierten el reinicio, por lo que cuando pasa por un inversor en el cambiador de nivel de su cable, tendrá que pasar por otro en su circuito o de lo contrario terminará en sentido opuesto a su sentido habitual.

Respuestas (2)

Su pregunta fue demasiado larga para leer, pero parece que tiene algunos problemas con un circuito convertidor de tipo MAX232. Hice lo que parece ser un circuito muy similar usando una de las variantes TI del chip e incluso lo vendo como un producto. Vaya a www.embedinc.com/products/rslink2 y podrá ver toda la documentación, desde una imagen hasta el diseño de la placa y el esquema. Tal vez puedas ver lo que estás haciendo de manera diferente.

Una cosa que noté mientras revisaba su pregunta es que está usando tapas electrolíticas. Vuelva a verificar que la polaridad de cada uno sea correcta. Otro problema es que algunos puertos COM, en particular los convertidores de USB a RS-232, no funcionarán sin RTS/CTS, ya sea que esté habilitado en el software o no. Observe cómo tengo los pines 7 y 8 conectados entre sí en el conector DB9-F.

No sabía cómo abreviar la pregunta porque no sé dónde está el problema. Así que decidí mostrar todo lo que tengo en detalle.
Además, mientras estudiaba el tema, encontré la página de su producto y los esquemas vinculados desde allí. ¡Muy agradable! Pero no lo estudié con más detalle porque el IC que usaste no parecía compatible con el mío. Pero voy a echar un vistazo más de cerca. ¡Gracias por tu ayuda! +1
Esto es lo más cercano a una respuesta que obtuve sobre esto, así que lo acepto. ¡¡Gracias!! He reducido el problema: se relaciona con un aumento de errores (debido al ruido o la sincronización de cristal) a 115200 bps, que no ocurren a 57600 bps. Vea mi otra pregunta para más detalles .

Dices que miraste el pin 3 del DB9 y viste 0-5V. El pin 3 recibe datos del mundo exterior y es impulsado por su cable serial USB a TTL.

El MAX232 recibe niveles RS-232 en los pines 8 y 13, convirtiéndolos a niveles TTL en los pines 9 y 12, respectivamente. El MAX232 recibe niveles TTL en los pines 10 y 11, impulsando niveles RS-232 en los pines 7 y 14, respectivamente.

Parafraseando al Dr. Indiana Jones, el destacado profesor de arqueología, estás mirando los pines equivocados.

Ejecute un generador de tren de pulsos 555 simple fuera de +5, aplíquelo al pin 10 del MAX232 (no conectado en su esquema), alcance el pin 7 del MAX232 y vea lo que obtiene.

Lo siento, puede que no haya sido lo suficientemente claro. No tengo un cable serial USB-to_TTL. Estoy tratando de simular uno usando un cable USB a RS232 conectado a este convertidor de RS232 a TTL que hice.
En la verificación que mencionó en su primer párrafo, conecté el cable USB a RS232 a mi computadora y dejé el DB2 desconectado. Luego probé el pin 3 mientras enviaba datos a través de la terminal. Luego obtuve la señal de 0V/5V y llegué a la conclusión de que el cable no sigue los estándares RS232. Según esta imagen , el pin 3 es TXD en el conector macho DB9. ¿O simplemente estoy confundido?
Entonces, el pin 3 en DB9 macho transmite datos desde la computadora y conduce datos al convertidor RS232 a TTL, ¿verdad? Es lo contrario de lo que dijiste en tu primer párrafo.
Además, hice lo que sugirió en el último párrafo de su respuesta. Apliqué una onda cuadrada de 0/5 V de aproximadamente 68 kHz al pin 10 del MAX232 y al pin 7 del MAX232. Obtuve una buena y limpia señal invertida -6V/+6V RS232.
@Ricardo, OK, eso significa que el lado de transmisión está funcionando. Ahora, debe aplicar una onda cuadrada de +12 V/-12 V (nominal: +6 V/-6 V debería funcionar) al pin 3 del DB9 o al pin 13 del MAX232, y verificar la onda cuadrada TTL en el pin 12. La forma más fácil para hacer esto es dejar la onda cuadrada TTL en el pin 10 del MAX232, pines cortos 2 y 3 del conector DB9, y pin 12 del osciloscopio.
El pin 3 del conector DB9, tal como lo tiene conectado, espera recibir una señal +12/-12 RS-232 de algún otro lugar del universo, algo que NO SE MUESTRA en su esquema. Esto se mete en todo el asunto de DCE/DTE que hizo que la interfaz RS-232 fuera una pesadilla y creó el mercado para miles de millones de cajas de conexión RS-232, módems nulos y dobladores de género. Las cosas mejoraron cuando la PC de IBM estandarizó efectivamente los conectores para todos.
El problema con esa imagen es que no le dice lo más importante que debe entender sobre RS-232. Hay DOS (2) conectores involucrados en cualquier conexión RS-232, un macho y una hembra. En UNO de ellos (y no recuerdo cuál), el pin 2 conduce y el pin 3 recibe. En el otro, que está conectado al otro dispositivo, el pin 2 recibe y el pin 3 conduce. De esa manera, cuando conecta los dos dispositivos juntos, siempre está conectando un pin de controlador a un pin de receptor, y viceversa. Conectar un pin de controlador a un pin de controlador es una buena manera de quemar un controlador.
@ JohnR.Strohm Sin embargo, el OP dijo que pudo acortar los pines 11 y 12 en el MAX232 y conectar el MAX232 a un cable proveniente de una PC usando el DB9. Eso significa que el DB9 tiene que estar cableado correctamente, o el transmisor/receptor en el MAX232 no estaría conectado correctamente a los pines TX/RX en el DB9.
@ JohnR.Strohm Estoy de acuerdo con tcrosley en que mi conexión DB9 es correcta, pero parece que no presenté mi configuración con la mayor claridad posible. Así que traté de aclarar algunos puntos con mi última edición. Por favor, míralo.
¿Me estoy perdiendo de algo? El cable que tienes tiene protocolo RS232, pero con 0v/5v en lugar de +/-12v, ¿no? Eso es lo que llamamos 'TTL' y es exactamente lo que debería poder conectar directamente a ATMega. No se requiere MAX 232... El MAX 232 convierte de 0/5 a -12/+12, pero ATMega necesita 0/5 (a menos que sea un dispositivo de 3.3v, pero creo que incluso entonces 0/5v seguirá estando bien) . Así que comenzaría conectando RX a TX y TX a RX, directamente desde el DB9 al conector ATMega/FTDI (no olvide la conexión a tierra también) y volvería a intentarlo.
@RJR: se supone que el cable emite RS232 pero emite 0v / 5V en lugar de +/- 12V. No es TTL porque su salida está invertida. No sabía que existía tal cosa hasta que leí esta respuesta . Aparentemente, los cables baratos usan la fuente de alimentación USB de 5 V directamente para producir salida y el MAX232 y sus varios clones lo aceptan. Revisé el MAX232 de Maxim, así como los clones ICL232 y HIN232 y todos dicen que aceptan la entrada incorrecta de 0V/5V RS232. La hoja de datos de TI parece cumplir con los límites de +/- 3V, pero bajo mi alcance, también acepta 0V/5V.
@RJR - Entonces, no puedo usar ese cable para programar mi ATmega328P directamente (porque los 0V/5V están invertidos), a menos que invierta la señal de alguna otra manera, sin usar MAX232.
Ah, sí, eso sería un problema. Sin embargo, puede invertir el TTL con un par de transistores fácilmente (o usar un inversor IC). Simplemente busque en Google 'TTL transistor inverter' para el esquema.
Si su cable tiene un chip FTDI dentro, debería poder ejecutar el programa de configuración para él. Ahí puedes invertir cualquier línea, creo.
@Maple, a menos que su cable tenga un chip FTDI auténtico conocido en su interior, a diferencia de una falsificación barata, tendrá todo tipo de dolores de cabeza con los controladores para el cable. FTDI se cansó de que los falsificadores robaran su negocio y les enseñó a sus conductores a reconocer los chips genuinos y negarse a trabajar con falsificaciones. Esto causó un sinfín de problemas para los clientes chinos de handi-talkie, porque los fabricantes de cables de programación compraron los chips falsificados. (¡Soy uno de los chicos que tuvo problemas, al igual que mi hermano!)
Problemas con la placa convertidora RS232 a TTL casera basada en MAX232 de TI
RespuestasAquíPolítica de privacidad1y, 0v