TL866ii Plus (ya) no me graba las 28C256...

[Rebobinando]

A mi me da que es una mala actualización , probaría a ver si se puede hacer un downgrade aun firm anterior

Si no lo he entendido mal esto se ha hecho.

Exacto. Es lo que hice al inicio. Puenteé en J1 según información que encontré de Xgecu y ejecuté el downgrade a v8.05, que es una versión de firm que me funcionaba perfectamente en su momento. Pero los resultados han sido los mismos. Ningún cambio.

o por lo menos trasladar la incidencia en la pagina del fabricante por que es rarísimo.

El fabricante ni sabe ni contesta, hasta ignora a los vendedores. Con suerte se puede obtener ayuda en el (lentísimo) foro pero, aunque me gustaría poder decir lo contrario, yo no tendría demasiadas expectativas al respecto.

Me lo planteé al inicio, pero viendo históricos en foro de Xgecu, no había ninguna solución salao insistirle al usuario en que todas sus EEPROMs podían estar rotas. El problema que se comentaba era el mismo de este hilo, pero con 28C64 en lugar de 28C256. Por este motivo, ya ni me planteé postear en Xgecu.

[cacharreo]

Probar con GAL, PAL u otro integrado puede servir, por lo menos, para saber que esas líneas de E/S del programador están funcionando bien. No es que aporte demasiada información pero al final sabiendo todo lo que no está mal, se puede dar con el problema.

[Rebobinando]

Probar con GAL´s no te va a clarificar o solucionar nada, ya que son chips diferentes y los procesos de lectura y grabacion tambien, lo mismo que probar con un pic o similar, que te lea un tipo de chips, no significa que funcione con otros tipos, para lo unico que te servira esa prueba es para saber si lee y graba GAL´s, pero eso no te va a aclarar nada del problema con las eproms o eeproms, lo suyo es que probaras esos chips que fallan en otro grabador y asi sales de dudas.

Tienen razón. No uses ni PAL ni GAL para comprobar porque no te van a aportar nada. Aunque puertas afuera parezcan todas iguales, puertas para adentro no existe un método genérico para grabarlas pues cada fabricante tiene el suyo y por lo que sé no los han publicado. Eso significa que si no se obtiene la licencia del fabricante de los componentes no se puede garantizar al 100% que una GAL pueda ser grabada.

Gracias compis, enitendo . Saco de la ecuación las GALs que tengo. No aportarán información.

Con las EEPROMs que tengo por aquí, he repetido las pruebas de nuevo:

CAT28C256
AT28C64B
W27E257
SST39F040

En todos los casos, el comportamiento es idéntico:

Lectura: 'lee' FF en todos los bytes.
Escritura: Da error al verificar, puesto que 'lee' FF en el primer byte, y no le cuadra con el contenido que aparentemente ha grabado o debería haber grabado.

Grabar, no graba realmente, ni FF, puesto que si, en el caso de la CAT28C256, pruebo en el CPC, sigue operativa y con el contenido anterior al intento de grabación.

Salvo que me esté perdiendo algo , ni graba, ni lee... Voy a ir mirando alternativas de grabadores por si acaso (un T48 o algo DIY con un arduino). La reparación del hard de este bicho se me hace muy cuesta arriba, por preparación y por herramientas.

[Rebobinando]

Probar con GAL, PAL u otro integrado puede servir, por lo menos, para saber que esas líneas de E/S del programador están funcionando bien. No es que aporte demasiada información pero al final sabiendo todo lo que no está mal, se puede dar con el problema.

Era la idea inicial , como información adicional.
Tendría que probarlas en el CPC después de grabarlas para confirmar que tienen lo que se espera (desde un punto de vista funcional). Sería la opción de confirmar de alguna manera la grabación correcta. De esta forma, se podría intentar acotar (si es posible) los pines potencialmente conflictivos.

Pero con la repetición sobre las EEPROMs, he podido ver que realmente, ni las lee, ni las escribe . Podría ser desde una señal de control, o el mismo bus de datos?...

[WhatIsAMan]

Probar con GAL, PAL u otro integrado puede servir, por lo menos, para saber que esas líneas de E/S del programador están funcionando bien. No es que aporte demasiada información pero al final sabiendo todo lo que no está mal, se puede dar con el problema.

Era la idea inicial , como información adicional.
Tendría que probarlas en el CPC después de grabarlas para confirmar que tienen lo que se espera (desde un punto de vista funcional). Sería la opción de confirmar de alguna manera la grabación correcta. De esta forma, se podría intentar acotar (si es posible) los pines potencialmente conflictivos.

Pero con la repetición sobre las EEPROMs, he podido ver que realmente, ni las lee, ni las escribe . Podría ser desde una señal de control, o el mismo bus de datos?...

¿Tienes osciloscopio?
Una prueba sencilla puede ser introduciendo un alambre suficientemente gordo pero suficientemente estrecho para que no estropee el ZIF. En ese alambre puedes pinchar una sonda.
Si no recuerdo mal la serie 28 de memorias graba con 12V, nada que un osciloscopio normalillo no pueda asumir. Primero verifica que al pin de alimentación del integrado a probar le llega chicha en el modo de lectura. Si es correcto, entonces puedes probar de ejecutar el programa de escritura de EEPROM mientras monitorizas VPP, #WR, #CS. Creo que a lo mejor te puedes encontrar con algo interesante. Al fin y al cabo, por lo general el valor 0xFF es devuelto en tres casos: el primero es que la ROM esté preparada para ser grabada (vacía), el segundo que esté estropeada pero en el tercer caso puede ocurrir si el lector no tuviera nada conectado (tri-state) y los pull-ups del lector/grabador asignen el valor.

[cacharreo]

Tendría que probarlas en el CPC después de grabarlas para confirmar

Desactivando "Encrypt chip" antes de grabarlas permitiría además poder verificarlas con el programador antes de en el CPC:

De esta forma, se podría intentar acotar (si es posible) los pines potencialmente conflictivos.

Si hay pines conflictivos independientes del integrado que se programe es una forma de acotarlos.

Podría ser desde una señal de control, o el mismo bus de datos?...

Puede ser.

[cacharreo]

Si no recuerdo mal la serie 28 de memorias graba con 12V, nada que un osciloscopio normalillo no pueda asumir....

El osciloscopio no puede conectarse directamente a señales de control o buses porque provocaría un fallo en la comprobación/detección de los pines. Para hacerlo con garantías hace falta utilizar un buffer/driver entre el programador y el osciloscopio.

[WhatIsAMan]

Si no recuerdo mal la serie 28 de memorias graba con 12V, nada que un osciloscopio normalillo no pueda asumir....

El osciloscopio no puede conectarse directamente a señales de control o buses porque provocaría un fallo en la comprobación/detección de los pines. Para hacerlo con garantías hace falta utilizar un buffer/driver entre el programador y el osciloscopio.

Tienes razón. Sé que no es muy elegante, sin embargo quizás con una breadboard puedas poner el búfer/driver/op-amp y pinchar en el ZIF con unos du-pont.

No sé cuán efectivo sería pero es la primera idea que me viene a la cabeza...

[cacharreo]

Tienes razón. Sé que no es muy elegante, sin embargo quizás con una breadboard puedas poner el búfer/driver/op-amp y pinchar en el ZIF con unos du-pont.

No sé cuán efectivo sería pero es la primera idea que me viene a la cabeza...

Es lo que hicimos unos días atrás (prueba con osciloscopio/analizador lógico).

[WhatIsAMan]

Tienes razón. Sé que no es muy elegante, sin embargo quizás con una breadboard puedas poner el búfer/driver/op-amp y pinchar en el ZIF con unos du-pont.

No sé cuán efectivo sería pero es la primera idea que me viene a la cabeza...

Es lo que hicimos unos días atrás (prueba con osciloscopio/analizador lógico).

Disculpa. Es que voy con RENFE...