Va de Retro DRAM tester [v2.00]

[Popopo]

Voy a un poco a piñón hoy, no creo que me de para mucho el día.
He releído varias veces el post del nuevo firmware, pero no distingo que cambios hay respecto a la versión anterior, en un mensaje si indicas que la salida por serial ahora muestra un mensaje más detallado, ¿es ese el cambio o único cambio?

Ya estoy actualizando el nano para hacer algunas pruebas extra durante la tarde/noche, aunque ya con las 4116.

Lo de marcar el cátodo antes/después ... nah! que cada uno polimetro en mano detecte la polaridad XD a sufrir, sin dolor no hay gloria.

Lo de la pantalla y rellenos, intento fijarme, pero no veo un pijo. E igualmente no tenía claro si lo que reflejaba era ajustado a lo que hacía. OK, ahora lo tengo claro.

Llevas razón, no debo dar por sentado que lo trivial es directamente proporcional a los sencillo (que parece). El no tener acceso al código y esquema de funcionamiento (diagrama de flujo del programa) es lo que tiene, opinar y preguntar sin tener una base real de lo que ocurre. No compartas el código (entiendo lo que explicaste en su momento y muy respetable), pero si puedes (si te parece mejor) compartir el diagrama de trabajo del tester, de esa forma, podríamos dar ideas sobre el flujo y tu ya decides que ideas valgan para implementar en tu código o no.

Tampoco es importante.

No sabía que podía conectar el tester ... patino!, ahora recuerdo que comentabais ya hacía tiempo obtener las salidas de las pruebas por el puerto serie, pero no llegué a asimilar que fuera posible debido a lo que en su momento comentamos de que usábamos esos pines para las pruebas y por tanto no podían ser usados para la comunicación con un equipo externo. Claro, así me va por no comprobar los esquemas de asignación de pines actuales.

Esto me lleva a la conclusión @Gomas48K, ¿es a esto a lo que te refieres con decir que no hay pines para memorias de mayor patillaje? ... si es así, no hay problema. Se puede. Ya con el KiCAD creo que he llegado a lo que necesitaba llegar (aunque ahora toca ampliar y adquirir conocimientos sobre electrónica dedicada a los PCB).

Vamos, me puedo empezar a poner ya con la programación del Nano. De hecho tengo el sistema montado en un simulador de PC (aunque con otra pantalla) listo para empezar a darle caña. Debería poner las últimas modificaciones, pero como no son vitales que provoquen cambios en el funcionamiento... pues así me vale.


Así que pronto, espero poder aportar ya cositas más allá del manual. No a vuestro nivel de pruebas y control de electrónica, pero... en lo que mejor se me da... pues bueno, aportar.

[cacharreo]

He releído varias veces el post del nuevo firmware, pero no distingo que cambios hay respecto a la versión anterior, en un mensaje si indicas que la salida por serial ahora muestra un mensaje más detallado, ¿es ese el cambio o único cambio?

Si comparas con una utilidad los mensajes correspondientes a fw0.22 y fw0.23 sería lo que verías. En realidad hay bastantes cambios internos, se ha desacoplado el interface del resto del programa, más variables que antes eran locales ahora son globales (para ganar en velocidad y memoria RAM), deshabilita la salida serie y por el pin 12 con las 44256, con una directiva condicional se compila el código con el controlador SH1106 para las pantallas de 1.3", etc. pero a efectos de lo que se puede ver desde fuera el mayor cambio es el número de versión que se ve en el arranque y el mayor nivel de detalle en la salida serie cuando los tests fallan.

Como se dijo antes, mientras el firmware sea provisional no se va a mantener un registro de cambios, una vez pasemos a producción entonces sí que se detallará cada cambio (que presumible serán menos y más sutiles). Insisto en este punto para no frustrar ninguna expectativa.

Lo de marcar el cátodo antes/después ... nah! que cada uno polimetro en mano detecte la polaridad XD a sufrir, sin dolor no hay gloria.

Tienes razón, total son solo 20.

Lo de la pantalla y rellenos, intento fijarme, pero no veo un pijo.

La pantalla de 0.91" es muy reducida y me temo que con las que usa @Gomas48K de 0.96" no se gane mucho tamaño en los textos.

No compartas el código (entiendo lo que explicaste en su momento y muy respetable), pero si puedes (si te parece mejor) compartir el diagrama de trabajo del tester, de esa forma, podríamos dar ideas sobre el flujo y tu ya decides que ideas valgan para implementar en tu código o no.

El código se va a compartir pero como hablamos cuando esté completo que no quiere decir 100% depurado pero sí que al menos tenga todos los tipos de tests para todos los chips DRAM. Esto podía estar hecho hace muchos meses pero para que después no haya descoordinaciones entre lo que se hace y lo que hablamos prefiero ir aportando novedades al ritmo que se puedan probar las placas (lo cierto es que si no lo hicera así, pasados tres meses ni yo mismo sabría de qué hablamos )

Claro, así me va por no comprobar los esquemas de asignación de pines actuales.

No es necesario comprobar los esquemas ni tampoco las más accesibles tablas de asignación porque como se ha repetido tantas veces, y comentó @Gomas48K, actualmente estamos tomando ventaja de que esos pines solo los usan las 44256 que ahora mismo no tienen un test funcional.

[Gomas48K]

Feliz Navidad a todos!!!

Lo recuerdo. entonces no me habías mandado memorias de prueba, ¿o sí? me pareció que no, pero en un mensaje anterior me ha parecido entenderte que me las habías mandado para que hiciera pruebas una OK y una mala.

Estoy seguro que te mandé varias memorias "pochas" y una o dos buenas.

... las estoy haciendo en la habitación a oscuras y cuando dio fallo, tenía la lámpara encendida. XD Pues a ver... nada... hay que hacerlo tal cual. Si esta noche no peta otra vez con algún fallo, mañana repito la prueba con la lámparita encendida.

A no ser que uses una lampara de iluminación de fachadas... No creo que afecte mucho.

Lo de los colores, esta claro que por el material usado en los zener, la luz excita de alguna manera el material de que está compuesto y produce "interferencias" eléctricas. La onda (color) va asociada a la frecuencia, pero puede que también a la energía aplicada (no sé si usas diferentes punteros con diferente potencia de emisión).

Efectivamente uso varios punteros y como es de esperar de donde están comprados (Ali), no guardan ninguna similitud en sus potencias.
El morado al ser mas potente, afecta mas.

Sea como sea... habrá que aconsejar usar carcasas o pintar los zeners XD, justo como has dicho.
Veré de nuevo el video que has puesto de StarTrek para ver si entiendo mejor como falla. Unicamente me he fijado en como iluminas y saltan los errores, no en como afecta al patrón de test o la relación entre el tipo de patrón del test y la luz usada.

En principio, al hacer pasadas rápidas por encima de los zener mas conflictivos Z14 y Z18, en mi caso (creo que afecta dependiendo de su capacitancia), altera el resultado de los test.
Los test suelen fallar al hacer la lectura en "000" y menos frecuentemente en la lectura del test "111".
Cuando el test esta grabando los datos en la memoria, no afecta el láser... O eso me ha parecido.

Hace ya tiempo, averiguamos que los zener son fotoreceptivos y generaban una tensión al ser expuestos a una iluminación intensa, de por ejemplo una linterna LED.
En este caso, no es de extrañar, que la aplicación de un haz de láser sobre ellos, tengan este efecto.

Mas allá de ser una anécdota, no creo que nadie vaya a trabajar con estos tester en condiciones de iluminación tan extremos, como para que afecte significativamente... porque tendrían que usar gafas de soldador, para proteger los ojos!!!

Firmware fw0.23

Oído cocina!!!

Ni los sueñes!!! Los meto todos en un bote de pintura! A la vez, a dolor

Recuerda acortarles antes la patilla del cátodo para marcarlo de alguna forma.

En modo continuo la información de cada test la proporciona tanto por el puerto serie como por el pin 12 (en mensajes anteriores se explica el protocolo). Con el fw0.23 quedaría así:

cuando un test falla en su línea se señala que falló (Test:0), en qué test falló ([000]), la dirección errónea (Address:22B2) y que aunque escribió un 0 (w00) acabó leyendo un 1 (r01).

Muy útil, cuando se deja en bucle una memoria que da algún fallo (como la de @Popopo), para poder saber si es siempre sobre una dirección de memoria concreta.
Gracias!!!

Esto me lleva a la conclusión @Gomas48K, ¿es a esto a lo que te refieres con decir que no hay pines para memorias de mayor patillaje? ... si es así, no hay problema. Se puede.

Correcto, a eso me refería.
Los pines del Nano RX y TX, se están usando ahora mismo para hacer monitoreo en un PC, como ha comentado @cacharreo.
En el momento que ampliemos a memorias con mas pines, tendremos que usar esos pines, con el problema que no se podrá hacer el monitoreo a la vez que se está testeando la memoria (porque como se ha comentado ya, vamos justos de velocidad como para implementar un monitoreo entrelazado con el testeo de la memoria).
Además creo recordar, que también era un problema si se usa Nanos con CH340X, que tienen los LED RX/TX en el mismo bus de datos (no son controlados independientemente como pasa en los FT232RL) y pueden afectar al flujo de datos en el testeo.

Lo de la pantalla y rellenos, intento fijarme, pero no veo un pijo.

La pantalla de 0.91" es muy reducida y me temo que con las que usa @Gomas48K de 0.96" no se gane mucho tamaño en los textos.

¿Quien me invoca?

También existe la posibilidad de conectar el prototipo a un ordenador por UART y a su vez, la salida de HDMI del ordenador a la televisión del salón de 55".
Va a parecer la pantalla de vuelos de un aeropuerto!.

[cacharreo]

Feliz Navidad a todos!!!

Igualmente.

... las estoy haciendo en la habitación a oscuras y cuando dio fallo, tenía la lámpara encendida. XD Pues a ver... nada... hay que hacerlo tal cual. Si esta noche no peta otra vez con algún fallo, mañana repito la prueba con la lámparita encendida.

A no ser que uses una lampara de iluminación de fachadas... No creo que afecte mucho.

Tiene que ser algo potente y local, aquí con el sol casi todo el día no ha habido problemas con los zeners pero, como ha dicho @Gomas48K, con una mini-linterna LED potente encontré algunos que sí que los afectaba.

En principio, al hacer pasadas rápidas por encima de los zener mas conflictivos Z14 y Z18, en mi caso (creo que afecta dependiendo de su capacitancia), altera el resultado de los test.
Los test suelen fallar al hacer la lectura en "000" y menos frecuentemente en la lectura del test "111".

Es normal porque -creo- el valor por defecto de las celdas de la memoria es 1.

Efectivamente uso varios punteros y como es de esperar de donde están comprados (Ali), no guardan ninguna similitud en sus potencias.
El morado al ser mas potente, afecta mas.

He encontrado las especificaciones de los que tienes y son todos de 5mW. Las longitudes de onda son 405nm (púrpura), 532 (verde) y 650nm (rojo) con una energía de 3.0614µeV, 2.3305µeV y 1.9075µeV por fotón de forma respectiva. Esto confirma nuestros resultados empíricos porque la energía del puntero laser púrpura por fotón es un 60% superior a la del rojo.

Oído cocina!!!

Esta versión comienza con el test [000] que, como hablamos, es más sensible a fallos.

Muy útil, cuando se deja en bucle una memoria que da algún fallo (como la de @Popopo), para poder saber si es siempre sobre una dirección de memoria concreta.
Gracias!!!

De nada. Lástima que solo las memorias muy fastidiadas dan error en una dirección de memoria fija, en la mayoría de las que presentan problemas solo tienen una zona favorita y el error llega a veces antes, a veces después. Está visto que el comportamiento durante el test depende mucho de las operaciones previas, como hemos comprobado puede darse el caso de que una memoria después de largas series de tests comience a dar fallos y unos días de descanso después vuelva a pasarlos todos.

Además creo recordar, que también era un problema si se usa Nanos con CH340X, que tienen los LED RX/TX en el mismo bus de datos (no son controlados independientemente como pasa en los FT232RL) y pueden afectar al flujo de datos en el testeo.

Los Nanos con CH340x o con ATmega328PB están expresamente excluídos del soporte oficial.

También existe la posibilidad de conectar el prototipo a un ordenador por UART y a su vez, la salida de HDMI del ordenador a la televisión del salón de 55".
Va a parecer la pantalla de vuelos de un aeropuerto!

Así es, la comunicación con los dispositivos de salida (p.e. pantallas) se realiza a través de D18 (alias A4 alias SDA) y D19 (alias A5 alias SCL) utilizando el protocolo I2C y, aunque escape del ámbito de este proyecto, sería perfectamente viable prescindir de TX y RX, no usar pantalla en el tester, conectar los pines D18 y D19 al PC ⁽¹⁾ y representar los píxeles en una pantalla virtual en el monitor del ordenador teniendo en cuenta que la comunicación I2C es ridículamente lenta comparada con la velocidad de proceso de cualquier PC (quien dice el PC dice cualquier microcontrolador potente). Recuerdo además que la botonera puede ser controlada desde otro microcontrolador o PC.

El típico módulo USB-I2C (USB-Serial, USB-UART, USB-TTL,...) con FTDI FT232RL, FT232H, CH341x, CP2104, CP2112,... se puede conseguir en AliExpress por menos de 2 euros. A más bajo nivel podría diseñarse un sencillísimo interfaz (bit banging) para el puerto paralelo al estilo de los de hace 40 años aunque no siendo un problema hay que considerar que la mayoría de los ordenadores modernos necesitarían un (barato) adaptador USB-Paralelo. Otra opción es aprovechar que el SMB (SMBus alias System Management Bus) de los PC es un derivado compatible con I2C para comunicarse directamente con el dispositivo aunque la conexión física sería más delicada. Otra alternativa sería DDC (Display Data Channel) otro derivado (bastante) compatible con I2C que podría utilizarse tomando la conexión de una ñapa ad-hoc en el cable del monitor pero que tiene el inconveniente de que no está implementado en todos los PC.

Puesto que sería muy útil en su caso a ver si @Popopo se anima y lo intenta.

• SSD1306 (información sobre I2C en página 20)
• FT232R USB to I2C Communications Module (especificaciones técnicas de un interfaz USB-I2C con información interesante)
• MCP2221 USB 2.0 to I2C/UART Protocol Converter with GPIO (hoja de datos)
• USB-UART-I2C-Debugger (repositorio en github con ejemplos para MCP2221)

⁽¹⁾ Los pines de salida del bus I2C son de colector/drenaje abierto (open collector/open drain) por lo que son imprescindibles las resistencias elevadoras, de polarización,... (pull-up) entre 2kΩ y 10kΩ.

[Popopo]

Bueno...Lo que planteáis es algo que ya se planteo al comienzo. Es una de las primeras y más importantes directrices propuestas. Sigue vigente.

Yo me abstengo, principalmente porque no entiendo muy bien lo que decís. Al menos no hoy.

Habrá desarrollo de una aplicación para controlar el tester desde el ordenador. Así mismo, que el tester funcione incluso desde LEDs, con pantalla oLED y todo lo que propuse en un principio pero, que para poder avanzar y concretar lo antes posible una solución, dejamos a un lado. Retomarlo ahora, pues como veáis.

Una aplicación que controle el tester no necesita prácticamente ancho de banda ninguno. No es problema.
Mañana vuelvo a leer los mensajes a ver si me cosco mejor de lo que habláis.

[cacharreo]

Atención porque aunque en efecto al principio hubo varias disquisiciones sobre controlar el tester del ordenador por puerto serie y más adelante hablamos de pines alternativos, puertos serie por software, etc. todo esto quedó obsoleto cuando debido a los problemas de los clones de Nano con CH340x, CH551x, etc. vimos que no había forma de utilizar pines, ni TX, RX, ni ningún otro, para la comunicación puesto que la gestión simultánea en tiempo real de las señales del tester no dejaba pines libres. Si hubiera quedado un solo pin libre que no os quepa ninguna duda que se hubiera dedicado a la conmutación de JP5 ⁽¹⁾ para cortar la alimentación cuando no se estuvieran realizando tests.

Ahora hablamos de controlar el tester por otros medios, la botonera mediante un DAC conectado al PC y a J2 lo que no es un concepto nuevo, pero dejando el tester sin pantalla y conectando a los pines SCL y SDA del I2C desde J11 ó J12 al PC, lo que sí que es nuevo.

A propósito y para que nadie se lleve a engaños, para estos propósitos podéis ir descartando ideas como multiplexores, expansores de pines y similares que aunque puedan sonar atractivas no se soportan más que sobre el papel.

Habrá desarrollo de una aplicación para controlar el tester desde el ordenador.

Una aplicación que debería realizarse en Python 3 -el candidato ideal- o, su defecto, en algún lenguaje con un importante soporte multiplataforma.

Así mismo, que el tester funcione incluso desde LEDs, con pantalla oLED y todo lo que propuse en un principio pero, que para poder avanzar y concretar lo antes posible una solución, dejamos a un lado. Retomarlo ahora, pues como veáis.

En el estado actual en el que en la práctica casi solo realizamos pruebas, si hay ganas y tiempo se puede comenzar ahora mismo para no retrasar más aún la fecha de lanzamiento oficial.

⁽¹⁾ Las referencias de componentes son de la placa 1.06.

[Popopo]

En el estado actual en el que en la práctica casi solo realizamos pruebas, si hay ganas y tiempo se puede comenzar ahora mismo para no retrasar más aún la fecha de lanzamiento oficial.

Lo dicho, lo que decidáis vosotros está genial. Me decís como puedo ayudar o probar cosas y lo trataré.
Python es una gran elección. Lamentablemente no podré aportar mi grano de arena en ello, no lo domino suficiente. Solo a nivel supervisión y corrección, no para implementar soluciones.

[Gomas48K]

Efectivamente uso varios punteros y como es de esperar de donde están comprados (Ali), no guardan ninguna similitud en sus potencias.
El morado al ser mas potente, afecta mas.

He encontrado las especificaciones de los que tienes y son todos de 5mW. Las longitudes de onda son 405nm (púrpura), 532 (verde) y 650nm (rojo) con una energía de 3.0614µeV, 2.3305µeV y 1.9075µeV por fotón de forma respectiva. Esto confirma nuestros resultados empíricos porque la energía del puntero laser púrpura por fotón es un 60% superior a la del rojo.

Yo me volví loco a buscar y no encontré ninguna información en las tiendas de Ali.

Los Nanos con CH340x o con ATmega328PB están expresamente excluídos del soporte oficial.

Así es, la comunicación con los dispositivos de salida (p.e. pantallas) se realiza a través de D18 (alias A4 alias SDA) y D19 (alias A5 alias SCL) utilizando el protocolo I2C y, aunque escape del ámbito de este proyecto, sería perfectamente viable prescindir de TX y RX, no usar pantalla en el tester, conectar los pines D18 y D19 al PC ⁽¹⁾...

Exposición perfecta!

Gracias!

[cacharreo]

Yo me volví loco a buscar y no encontré ninguna información en las tiendas de Ali.

En Ali no encontré nada, tube que buscarlo en AliBaba (¡qué buen nombre!) y GearBest. La energía por fotón no estaba especificada, es calculada.

Exposición perfecta!
Gracias!

De nada, no se me ocurren muchas más formas de controlar el tester completamente, de forma externa y sin alterar su funcionamiento de forma significativa, o al menos para poder usarlo con todas las memorias incluida la 44256.

[Popopo]

Buenas
Pasando de nuevo a la memoria "que de vez en cuando falla", ha vuelto a arrojar otro error en otro ciclo (antes de los 200 tests)... sigue en marcha. Esta... la voy a poner en cuarentena...


@Gomas48K ¿Tendrá alguna foto de las memorias que me pasaste o alguna indicación que me ayude a localizarlas? Es muy posible que las pusiera junto a otras y ahora no sea capaz de discernir.