Programador de PICs (Solo Enigma)

[golumx]

En un post anterior mencione los valores que obtenia en cada pin del micro y del ICSP. corriente le llega pero el micro parece muerto. ¿Hay mas puntos donde pueda tomar medidas con el polimetro que tengo? haber si puedo acotar el problema.
A mi tambien me parece raro lo de la bobina y mas raro que se deteriore y siga teniendo continuidad, aunque sin instrumental me parece que lo tengo dificil para conocer el valor real. La que tengo montada es de 220uH (rojo-rojo-marron) o eso creo.

 

[f_point]

A lo mejor la bobina no este deteriorada, simplemente podria pasar que el PIC no funciona bien y que por lo mismo la bobina no de indicios de funcionar bien. Si mi interpretacion del codigo de colores de la bobina es correcta, tu bobina tiene los colores correctos, a menos claro que la estes leyendo al reves ^_^

Pues... sinceramente se escapa de mis manos o de imaginacion que mas pudiera ser la causa de que no funcione. Lo que si puedo decir es que si no da señal de vida, posiblemente sea por alguna de las siguientes causas:

1- No llega alimentacion al PIC. Posiblemente porque haya un cortocircuito o simplemente hay una conexion abierta. O posiblemente no llegue suficiente voltaje como para que funcione adecuadamente.

2- Hay una conexion que por alguna causa desconocida esta mal, lo que probablemente fuerce al PIC a no operar bien (ej: un puerto de salida en cortocircuito).

3- El oscilador de reloj del PIC (cristal de 20MHz y sus capacitores de muy bajo valor en pF) no funciona. Puede ser un cortocircuito, una conexion abierta, o porque hay alguna capacitancia parasita que interfiere en su funcionamiento correcto. Una conexion muy larga podria ser causa de ruido tambien.

4- El PIC se mantiene en reset continuamente, posiblemete debido a un cortocircuito o conexion aberta en MCLR. Sin embargo el pin MCLR esta desactivado en el firmware, asi que podemos descartar esta causa.

5- El firmware no esta grabado correctamente en el PIC. Hay que programarlo y luego verificarlo unas 2 o 3 veces para asegurarse de que se lee bien todo el tiempo. Tambien seria bueno probar con mas de un programador y de ser posible, otra utilidad de software de programador (en la PC).

6- Hay problemas con la conexion USB, posiblemente un cable cortocircuitado o abierto.

7- Hay un ruido excesivo en la fuente, o en alguna otra parte del circuito y eso impide que el PIC siquiera arranque.

8- El PIC podria estar entrando en Latch-Up. Las causas de esto son muy diversas, aunque normalmente estan asociadas a que por un pin entra un voltaje superior a VDD. Cuando el MCU entra en ese estado, hay que apagarlo por varios segundos antes de que pueda volver a operar (si es que no se ha dañado).

9- El espiritu de Murphy hace de las suyas (si es que tal cosa existe) y eso impide a toda costa que funcione, hagas lo que hagas. Boooo!
Solo Bromeando

Causas para que no funcione las hay a granel, solo he mencionado las que se me vienen a la mente, pero te prometo que hay mas. Seguramente los demas amigos del foro puedan citar aun muchas mas. Alguna sugerencia?

Saludos.

 

[Guest]

Golumx creo que debes de checar la posicion del transistor (que transistor usas),para el 2n3904 tienes que ver que el pin 1 este conectado con la bobina y con el diodo y la terminal de enmedio a la pata 13 del pic atravez de la resistencia de 4.7k

luego la polaridad del diodo 1n4148 y la bobina; cuando arme mi bobina con el nucleo de ferrita debido a que el alambre era muy delgado al soldarla al pcb la parte a la que le habia quitado el esmalte no habia agarrado con la pista, por lo que aparentemente no habia conexion alguna del ransistor a vcc y esto lo asegure cuando medi la resistencia y la continuidad, sin embargo en la terminal vpp lograba medir 4.7vigual que tu, revise la bobina y me di cuenta del error, corregi la bobina y al medir me dio una tension de 12.8v, y es curioso por que al no haber conexion alguna con vcc pareceria que no podria haber una tension de 4.7v.

El valor de la bobina es critico si estas muy por debajo de los 220uh pero en la simulacion que hice con una inductancia desde 180uh hasta 500uh el elevador de tension funciona sin problemas (obviamente al estar debajo de 220uh tarda un poco mas en elevarse la tension por que tarda un poco mas en saturarse la bobina).

Pienso que tu problema es la conexion de la bobina con el transistor y vcc ya que si estuviera bien conectada , aunque el valor estuviera algo fuera de rengo deberias de observar un incremento en la tension y no los 4.7v derivados en parte de la caida de tension del 1n4148, y en mayor medida creo que tiene que ver la posicion, conexion y tipo de transistor que usas.

 

[golumx]

He chequeado las conexiones del elevador de tension midiendo la reisencia entre los terminales de cada componente, pongo una foto para mas detalle:

Los puntos 1,2,3 se corresponden con las patillas del 2N3904, entre los puntos 1 y 4 hay una resistencia de 0.4 ohm, entre el punto 4 y el 6 (anodo del 1n4148) la sresistencia que me indica el polimetro es de 0.4 ohm y entre los puntos 5 y 6 es de 3.5ohm. Si mido la resistencia entre el punto 2 y el pin 13 es de 4.61Kohm. Hay que decir que el polimetro mide en cortocircuito 0.4ohm, teniendo en cuenta que estos resultados han sido medidos sobre las patillas de los componentes por la cara que no tiene pistas me atreveria a decir que las conexiones estan bien hechas. Ahora pongo los voltajes obtenidos con el programador conectado al PC, la masa la situo en el pin Gnd del ICSP.
Pin 13 -> 0.0v
punto 1->5.08v
punto 2 ->0.12v
punto 3 ->0.00v
punto 4 y 5 ->5.08v (medidos en continua, en alterna 10.5v)
punto 6 ->5.08v
punto 7 ->4.72v
punto 8 -> 0.13v
punto 9 ->0.00v
parece que las conexiones estan bien lo que me da mala espina es que la tension en el pin 13 sea de 0v que va a la base del 2N3904 con lo cual nunca va a funcionar este transistor ¿sera que esta dañado el PIC? no me lo expilico por que le he cargado el firmware varias veces y siempre me lo verifica si error.....

 

[golumx]

Una pregunta de igorante, jejeje.... ¿podria valernos este esquema para el zocalo ZIF de 40 pin? Hay que decir que perenece a un programador comercial, el GTP-USB + pero tiene el ICSP, a mi este programador no me vale por que no es capaz de programar 16F876.

Solo añadir que tengo el fotolito de la placa y la distribucion de los componentes......

 

[Residente]

golumx he echo las mismas pruebas que tu, recpeto a las resistencias que has medido tengo los mismos valores en todos los puntos, en las tensiones si tengo algunas diferencias, mi programador se enciende pero no lo detecta el SO, espero que asi lo mismo puedes hacer que se enciendan los leds.
Pin 13 -> 3.6v
punto 1->4.7v
punto 2 ->0.6v
punto 3 ->0.00v
punto 4 ->4.7v
punto 5 ->4.9v
punto 6 ->4.7v
punto 7 ->8.2v
punto 8 -> 0.6v
punto 9 ->3.6v
las mayores diferencias entre el programador de golumx y el mio son los 3.6v del pin 13, aver si alguien que lo tenga funcionando bien puede hacer las mismas pruebas y asi detectar los fallos

 

[golumx]

pues va a ser que el micro esta dañado, otros 11€.....

 

[elmasvital]

Chicos de donde sois? igual podeis darnos la placa a alguno para que le echemos un vistazo...

de todas formas yo diria que si no os detecta windows el programador... el pic estará muerto... cualquier corto se los come y con las puntas del polimetro es muy facil hacer cortos en una placa.

yo soy de sevilla.

 

[golumx]

Yo soy de Madrid, gracias por el ofrecimiento, ya lo habia pensado, pero antes de pedir el favor y andar liando prefiero agotar todas las posibilidades. Lo de los cortos con el polimetro puede ser pero solo cuando no ha funcionado he metido el polimetro con el circuito conectado y lo he hecho por la cara de los componentes y con mucho cuidado, no creo que se a esa la causa.
El esquema que he colgado antes solo es para PIC, pero no se si funcionaria.

 

[Eclip-se]

Hola a todos.

Y deseándoles un Feliz Año.

Esta lista..! La nueva versión de programador Eclipse, la cual incorpora la familia de los AVRs. Solo lo he probado con el ATmega16 (Es el único que tengo), me falta por probar los demás AVRs pero podrían funcionar.

En este caso ya esta definida la versión del Software y Firmware, empezamos con:
Eclipse V1.0.
Firmware V1.0.

Para comprobar que el Firmware esta programado bien, al momento de conectar el programador al puerto USB se genera un encendido y apagado de los Leds, 5 veces luego se pone en su estado normal, también permite hacer las pruebas del hardware de todas las líneas que maneja el programador.

Para verificar que el programa esta haciendo su trabajo. He implementado la opción de “Llenar Buffer”, esto nos permite poner el valor deseado y verificar su correcta programacion.

Para comprobar, que localidad de memoria puede generar errores en el momento de programar. Existe la posibilidad de utilizar una “Programacion o Lectura selectiva”, que permite programar o leer la localidad escogida:

Memoria FlashROM
Meroria EEPROM
CONFIG.

Antes de programar un micro utilicen la opción de auto detectar, para verificar que el dispositivo sea identificado, que el programador lo soporta y esta funcionando correctamente. Luego de eso pueden abrir el archivo a programar.

Recuerden para programar AVRs debe estar seleccionado 5V y para PIC 13 V. Aunque por error he escogido 13V para AVRs, y al ser un instante de tiempo que esta sometido a ese voltaje. No se ha dañado, pero se debe tener mucha precaución y escoger el voltaje adecuado.

Cuando quieran cambiar la configuración de los AVRS asegurarse de saber lo que están haciendo. Ya que si escogen la opción de utilizar un cristal externo se debe utilizar la señal XTAL1 para generar los pulsos que permitan que el micro funcione.

La señal XTAL1 se puede varia de 100Hz a 15KHz (Si alguien dispone de un frecuencimetro podría medir la señal y comentar en que valores se encuentra y si la variación es lineal), esto nos permite escoger el valor adecuado ya que no existe información exacta de cual es el valor de dicha señal.

También trae la opción de cambiar la velocidad de CLK, como estamos en la etapa de pruebas hay que tener esa opción, esta seleccionada por defecto en velocidad media, pero también funciona en las demás velocidades. Prueben primero en la velocidad Alta si todo esta bien utilicen solo esa velocidad, si ocurre un error bajen la velocidad.

Recuerden dejar apagando la señal XTAL1, para que no se este generando la señal cundo estemos utilizando PICs. Ya que podría generar ruido que causara problemas en la programacion.

Con respecto a los reportes de errores comentados por f point. Empecé a corregir el generado por el PIC 12F675. Y no dispongo de esos PIC, pero el algoritmo de programacion es similar a los PICs de otras familiar y es pos eso que los programa. El problema es la lectura de OSCCAL. La hoja técnica de programacion dice que el valor esta en la localidad 0x3FF. Pero no se si es la localidad de menoría o que?. Por que en el grafico esa localidad aparece en la parte inferior donde recién empieza la memoria de datos.
No se si esa localidad es la ultima localidad de memoria o como hago para leer?. Ya que al inicio de la programacion la dirección en la que se inicia es la 0x400, en la memoria del PIC, pero nosotros le podemos considerar como la dirección 0x000. Y si en el inicio la primera dirección es 0x400 y OSCCAL esta en 0x3FF esta el dilema de cual es la dirección.

En otros PIC ahí si se inicia en 0x000 y para leer OSCCAL hay que seguir incrementando la dirección hasta llegar a ese valor. Ahí si es entendible el proceso de lectura incluso hay que seguir incrementando la dirección para llegar al inicio de la memoria de datos y empezar a programar el PIC.

Con todo f point podrías leer el PIC12F675 y supuestamente en la ultima localidad de memoria 0x3FF, estaría almacenado el valor de OSCCAL, También podrías poner algún valor la ultima localidad de memoria y proceder a grabar. Y ver si se graba OSCCAL con ese valor.

Te agradecería mucho f point.

 

[Residente]

Genial eclip-se, cada vez esto tiene mejor pinta¡¡
He programado el firmware nuevo, y si me hace el parpadeo de los leds, aunque con el mismo error de winxp que no detecta el dispositivo. ¿el valor de la bobina podria estar dando este problema?
Muchas gracias elmasvital aunque yo tambien estoi lejos como para que le eches un ojo.

 

[f_point]

En efecto, la localidad 0x3FF del PIC12F675 pertenece a la memoria de programa (es la ultima localidad de la memoria FLASH para codigo), y contiene una instruccion ejecutable como todas las localidades de programa comunes y corrientes.

La instruccion contenida en 0x3FF es un "retlw XX", donde XX es el valor de calibracion para el oscilador interno del PIC. Segun entendi de la hoja tecnica, el PIC al iniciar deberia de saltar a la localidad 0x3FF y ejecutar esar instruccion, para leer el valor de calibracion que luego debera ser guardado en OSCCAL.

Tengo entendido que eso es responsabilidad del usuario, pues hay un ejemplo de como transferir el valor de calibracion en la hoja tecnica. Dicho ejemplo esta en la seccion 9.2.5.1.

Lo unico que hace realmente especial a la localidad 0x3FF es que ya viene programada de fabrica (ya lo he comprobado). De ahi en demas, la localidad 0x3FF no es diferente de ninguna otra, incluso puede ser destruida o reutilizada para algo mas (naturalmente, no lo queremos hacer).

Tienes problemas para accesar la localidad 0x3FF? Hmmm... realmente no se bien como esta el rollo de como programar un PIC, pero mi logica indica que deberia haber una instruccion al estilo de "address set" o "select address". Dices que al arrancar el modo programacion el puntero de lectura/escritura apunta a 0x400, y que es necesario ir leyendo o grabando para hacer que el puntero de lectura/escritura se mueva (y que lo hace solo para adelante si no capte mal)... No habra una forma de establecer la direccion inicial a 0x000 con un comando?

Bueno, segun el mapa que adjuntaste, la direccion 0x400 esta inmediatamente despues de la palabra de calibracion, de manera que estamos pasados de la palabra de configuracion justo por 1 :-/. Entiendo por la misma grafica que accesar desde 0x400 equivale a accesar desde 0x000. Que tal si lees todo hasta la direccion 0x7FF? Mi logica exige que deberia equivaler a leer 0x377, ya que 0x7FF - 0x400 = 0x3FF.

Hagamos la prueba, podria funcionar ;-)

En unos momentos procedere a hacer la prueba que me dices con la nueva version. Les mantendre informaciónrmado en cuanto termine.

 

[f_point]

Muy bien, prueba con el 12F675 terminada.

Basicamente las cosas siguen bastante igual que con la version anterior, pero puedo confirmar que, en efecto, la ultima localidad de programa se lee correctamente junto con el resto del programa (aparece al fondo de la ventana de Flash ROM, tal como aparece seleccionada en el screenshot) y contiene el valor de calibracion, que como la vez pasada la perdi, la reemplace por 0x3480 (retlw 0x80).

Asimismo, la palabra de calibracion tambien es grabada junto con el resto del programa, pues probe borrando el 12F675, luego grabandolo, y luego volviendolo a leer; La palabra se lee de regreso perfectamente bien.

Debo agregar que hay un bug que persiste. Este se da cuando la palabra de configuracion que viene en el .hex tiene algun bit en 1 pero el PIC no la implementa (siempre se lee como 0). En esta nueva version sin embargo, ahora me dice que el programador no esta conectado justo antes de terminar de programar el PIC (la version anterior decia que hubo un error programando el PIC). Una vez mas, al igual que la vez pasada, el PIC se graba correctamente a pesar del error (va una imagen adjunta con la descripcion).

La meta con este PIC, seria de leer la palabra de calibracion primero, antes de borrarlo o reprogramarlo. Luego, como parte posterior al proceso, hay que volver a grabar la palabra de calibracion. Lo mismo deberia hacerse con los bits <BG1:BG0> de la palabra de configuracion, ya que tambien forman parte de la calibracion del PIC.

Adicionalmente, seria bueno darle una opcion al usuario para reemplazar la calibracion si asi lo desea (pero esta opcion deberia estar apagada por defecto).

Eso seria todo, saludos.

 

[golumx]

Bueno, pues he cambiado la bobina por una con nucleo de ferrita de 220uH, y nada de nada, ademas he cargado el nuevo firmware sin ningun problema y lo he verificado dos veces, todo ok, pero cuando lo enchufo al PC..... nada de nada. Por ultimo he vuelto ha hacer el programadoe entero, placa y componentes nuevos y pic nuevo, pero nada de nada.... ¿Que es lo que hago mal.....?

 

[Eclip-se]

Hola. Gracias f point por la información.

Con esto comprobamos que en efecto OSCCAL esta en la direccion 0x3FF y que el procedimiento de leer y grabar es el mismo que para grabar toda la memoria de datos. Y tal como comental al poner un valor en la ultimalocalidad ese valor se graba es OSCCAL. Todo esta clato.
Solodebo hacer una lectura de toda la memoria antes de programar y almacenar la ultima localidad. Luego al momento de programar pongo el valor que lei en la memoria de dato y listo.

Tambien ya le voy adicionar la opcion que tu dices. Y a corregir ese problema que sale al final de programar.

Tambien ya modifique el Firmware para que pueda ser utilizado con distintos critales. Solo deben cambiar la configuracion para que simpre la frecuencia del CPU sea de 24MHz, en la pagina 29 y 30 del Data Sheet esta la informaciónmacion de las distintas configuraciones.

Se puede utilizar cristales de 4, 8, 12, 14, 16, 18 y 20.

El Firmware solo esta en aqui, por que se necesita comprobar si funciona.

 

[Guest]

golumx prueba quitando el capacitor de 100nf

 

[f_point]

Gracias a ti eclipse, por escuchar nuestras sugerencias. Me alegra saber que mis pruebas y comentarios aportan algo util a la comunidad.

Con gusto probare el nuevo firmware. Solo que debo comentar que mi tablero ya esta terminado, y que desoldarle el cristal de 20MHz le afectaria un poco la estetica al acabado, asi que no le echare mas mano a esa unidad.

En vez armare otro programador, esta vez en protoboard con el unico fin de probar. Pero eso no podra ocurrir hasta que me consiga mas piezas para duplicarlo , particularmente el inductor, que me podria tomar quiza hasta un mes para conseguir otro (pues el primero me lo regalaron y quedaba solo esa unidad).

Mas sin embargo vere si puedo adaptar el firmware via fuses de configuracion a mi tablero con XTAL de 20MHz por el momento, asi al menos hare unas pruebas preliminares.

Saludos.

 

[golumx]

Quite el condensador de 100nF y no se aprecia ningun resultado, no hace falta puentearlo ¿no? ahora estoy montando otro en placa perforada como el de las fotografias de eclip-se.....
¿Alguien que tenga montado y funcionando el programador puede colgar unas fotos haber si encuentro que error cometo?

 

[f_point]

Con gusto publicaria el mio, pero me temo que es una version modificada y podria no servirte. Por que no miras el que esta publicado en la pagina de eclipse? El lo hizo en placa perforada.

 

[golumx]

En eso estoy, pero me parece una version de prueba, no se que tal funcionara por que le faltan algunos componentes, tambien me estoy bajando un PROTEL 2004 para ver las pistas y repasar el esquema, ¿No hay nadie que haya hecho la PCB de la version actual y que le funcione?