problema muy extraño con USART

[pollastre]

Hola,

llevo varias horas dandome de cabeza contra esto, a ver si soy capaz de explicar bien el problema y a alguien le suena alguna posible solución...

el tema es que tengo un PIC que se comunica con un dispositivo a 115200 bauds, tanto en recepción como en transmisión. Hace ya tiempo que terminé el programa de comunicaciones en ensamblador, y con un cristal HS @16Mhz todo funciona a las mil maravillas.

Por diversas razones ahora necesito usar un cristal XT <=4Mhz, y aquí viene la sorpresa. El mismo, exactamente el mismo programa que antes funcionaba perfectamente a 16Mhz, se "cuelga" en el primer intento de transmisión cuando está funcionando a 4Mhz.  Es algo muy extraño, nunca lo había visto antes. El procedimiento que sigo es muy sencillo :


para empezar inicializo  la usart ,

- establecer SBPRG y SPBRGH (valores distintos según vayamos a probar con XT=4Mhz o HS=16Mhz)
- SPEN = 1, SYNC= 0, BRGH = 1, BRG16 = 1
- TXEN = 1, CREN = 1

y luego según tengo que recibir o transmitir, voy activando TXIE o RCIE, para que me vaya pidiendo o entregando caracteres respectivamente. Cuando termino mi transmisión desactivo TXIE, y así sucesivamente.

Pues bien, a 4Mhz, cuando llego a mi primera transmisión y activo TXIE, el pic se queda como "esperando" algo,  algo que por supuesto sea lo que sea no llega, y me resetea el pic por watchdog (???). Mientras que a 16Mhz, funciona perfectamente. Sinceramente, no lo entiendo.

La única diferencia que yo vea, es que, para 115k2 bauds, a 16Mhz  la tasa de error del generador de baudios alcanzada con el par SPBRG:SPBRGH es muy baja, casi cero (0,2% si mal no recuerdo). A 4 Mhz, la tasa de error sube a 3,6%.
A menos que una tasa del 3,6% sea demasiado alta para hacer funcionar correctamente la usart a 115k2, francamente, no puedo ver por qué un código transmite perfectamente a 16Mhz, y se queda colgado a 4Mhz.

Lamento no ser demasiado claro en mi explicación, ahora mismo llevo un día y medio intentando resolver esto y estoy un poco "espeso". Si tuvierais alguna pista o dirección en la que investigar, os lo agradecería enormemente.

un saludo,

[xocas]

una pregunta amigo pollastre... ¿has probado a reducir la tasa de transmision y ver que sucede?

un saludo

[pollastre]

pues sí, probé con otro dispositivo que iba a 4k8 bauds, y ... sorpresa, funcionaba correctamente a 4Mhz. Hay que decir que la tasa de error para 4k8bauds a 4Mhz es muy baja tambien , así que para mí que el tema reside en que 115k2 con 4Mhz da una tasa de error que, sencillamente, no es tolerable por el dispositivo contra el que se conecta el pic.

Por ello me hice con unos cristales de 3,58mhz, que para 115k2 dan una tasa de error tambien muy baja . En cuanto pueda haré la prueba definitiva, que es intentar 115k2 a 3,58mhz. Si funciona, tenemos ya la respuesta de lo que pasa....

[maunix]

Revisa que no se estén activando los bits de error OERR o FERR.

[xocas]

hola Mauricio, tanto tiempo sin coincidir...

todos los ejemplos que he visto del tema usando un xtal de 4Mhz ponian como frontera los 9600 bauds y crei que por algun motivo no se podia o no era recomendable una tasa mayor. como se que tu tienes experiencia y conocimiento del tema queria preguntarte si esto es asi o no.

un saludo

[pollastre]

en teoria la datasheet (en este caso del 16F689 que estoy usando), en la seccion del generador de baudrate, muestra en las tablas con valores precalculados que con 4Mhz es posible 115k2.... con una tasa de error algo alta, pero parece posible...

un saludo,

[maunix]

hola Mauricio, tanto tiempo sin coincidir...

todos los ejemplos que he visto del tema usando un xtal de 4Mhz ponian como frontera los 9600 bauds y crei que por algun motivo no se podia o no era recomendable una tasa mayor. como se que tu tienes experiencia y conocimiento del tema queria preguntarte si esto es asi o no.

un saludo

Poder se puede, sobre todo si conectarás 2 pics entre sí. 

Ahora si el otro hardware es una pc, depende de que tan versátil sea a la pequeña diferencia de baudeaje que haya.  Un 3% no me parece mucho de diferencia.  En mis comunicaciones siempre utilizo algún tipo de control extra (checksum por ejemplo) que me de mayor precisión a la hora de saber si lo recibido es correcto o no.


El problema que muestra pollastre es que le deja de funcionar la usart lo cual me parece q el problema no viene por el tema del baudeaje sino por otro lado porque 'algo' debiera salir del pic.

Ahora que me pongo a pensar más claramente, pollastre tienes un osciloscopio para ver si realmente el pic se clava o si salen datos pero no son legibles por la pc?

[pollastre]

Maunix,

es muy raro, porque parece como que se "clava" en transmisión. Si se clavara en recepción, podría ser un problema de FERR u OERR, pero esas dos condiciones se dan en recepción, nunca en transmisión.

Estoy metiendo breakpoints a modo de leds que se van encendiendo en diversos puntos de la interrupción de servicio para TXIF, a ver a dónde llego. De momento ya he visto que no es capaz de transmitir todo el mensaje completo, se clava antes. Al mismo tiempo he podido constatar que sí es capaz de transmitir, al menos, el primer caracter del mensaje antes de clavarse.

Ahora sigo haciendo pruebas a ver cuantos caracteres es capaz de transmitir antes de colgarse...

un saludo,

[pollastre]

El problema que muestra pollastre es que le deja de funcionar la usart lo cual me parece q el problema no viene por el tema del baudeaje sino por otro lado porque 'algo' debiera salir del pic.

estoy de acuerdo con tu valoración: si fuera un problema de baudrate erróneo o muy desviado de 115k2, el dispositivo remoto podría entenderme o no, pero la transmisión debería realizarse, nunca quedarse el pic como colgado a mitad de la transmisión (acabo de comprobar que también llega a transmitir el segundo caracter) de tal forma que me llegue a producir un reset por WDT.

[pollastre]

maldita sea mi estampa.... ya descubrí qué pasaba.

envío las cadenas TX , algunas con direccionamiento indirecto (FSR), y otras usando tablas. Desesperado ya como estaba por el comportamiento trucho del PIC, puse un breakpoint en forma de led a la salida de la rutina de servicio de interrupcion TXIE... quería ver cuantos caracteres era capaz de enviar antes de colgarse.

Empiezo a subir el numero de caracteres de tope... joder si parece que los envía todos... espera... entonces por qué se cuelga .... aumento el breakpoint en un caracter más... y el led tambien se enciende (?????). Pero cómo diablos, de una cadena de N caracteres, está enviando N+1 ?

Aquello me dió la pista definitiva. Resulta que mi código, no es en la propia rutina de servicio de TXIE donde desactivaba TXIE al recibir el ultimo caracter de la cadena, sino que TXIE se desactivaba al volver de la interrupcion, tres o cuatro de byteops más adelante.

Con un reloj de 16Mhz, el pic era capaz de salir de la interrupcion y llegar a la orden de desactivacion de txie ANTES de que la usart se "tragara" el caracter en TXREG hacia TSR.

Pero con un reloj de 4Mhz, antes de llegar a la desactivación, la USART ya se habia quedado con TXREG vacio, con lo cual habia hecho set de TXIF. En cuanto se abandonaba la rutina de servicio de int, al restablecerse GIE, inmediatamente volvia a entrar otra vez en la interupcion de envio. Y claro, volvia a entrar con un indice de caracter N+1 ... que al intentar saltar a esa posicion de la tabla, entraba en una zona de código "sucia"... cuelgue al canto.... y todo explicado.

Qué maravilla los pic... cada vez que piensas que pueden funcionar mal o de forma no determinista, siempre acaban poniendote en tu sitio y demostrandote que los que cumplen 100% la datasheet son ellos, y no tu código trucho 

un saludo,

[maunix]

Me alegro que hayas encontrado tu problema.

y yo hago lo mismo que te acabas de dar cuenta, el TXIE lo deshabilito durante la interrupción, no al salir de ella   , ya que el riesgo es grande

[xocas]

me alegro igualmente que lo hayas solucionado y te doy las gracias por la detallada explicacion, que tendre muy en cuenta a la hora de trabajar a esas velocidades.

un saludo