Va de Retro DRAM tester [v2.00]

[cacharreo]

Autor: cacharreo
Fecha de publicación original: 23 Sep 2022, 14:21

---

Ni que decir tiene que esta PCB es más teórica que otra cosa y, al menos en principio, solo servirá de plataforma para los pequeños detalles que vayan surgiendo conforme se pule el diseño.

[cacharreo]

Autor: Gomas48K
Fecha de publicación original: 23 Sep 2022, 16:32

El voltaje correcto es +4.69V.

Son mejores números pero aún así la diferencia de consumo en mW es significativa (+20-70%).

También hay que tener en cuenta, que las memorias pueden tener diferentes consumos... y al estar puesta en el ZIF, puede alterar las lecturas.

Versión 1.05c

Muy trabajado!
Ya va teniendo un aspecto bastante interesante.

El conector ICSP en la placa, es todo un detalle.

Ni que decir tiene que esta PCB es más teórica que otra cosa y, al menos en principio, solo servirá de plataforma para los pequeños detalles que vayan surgiendo conforme se pule el diseño.

Me da, que la placa final no va a ser muy diferente a esta.

[cacharreo]

Autor: Popopo
Fecha de publicación original: 23 Sep 2022, 17:02

Hola
Estoy leyendo un poco suelto, ahora pensaba ponerme a seguir con la comprobación de la actualización en la que me quedé, con el firm 0.19.

Sobre compras, esperad antes de gastar más dinero. Os recuerdo que nos han donado unas cuantas memorias rotas y quizás ya tengamos de esas.

Por otra parte, no actualizaré ni firm ni placa hasta que no vea que pasa con la que tengo. A ver si hoy puedo entender la lectura de los pines que no me cuadran los datos y como se hacen dichas comprobaciones.

[cacharreo]

Autor: Popopo
Fecha de publicación original: 23 Sep 2022, 19:49

Bueno, adjunto imagen de resultados y describo.

Los valores vacíos indican que no hubo cambios en la tercera línea, es decir... se mantuvieron a 0. (excepción de la primera posición 01, que esta fijo a 1 haga lo que haga).
Para VCC (+5v) he indicado el pin de la pantalla que indica como activado. Los que han permanecido a 0, que ya había indicado anteriormente en un mensaje... permanecen a cero aunque conecte el VCC.
Por ejemplo, el J4/02 activa el dígito 08 de la pantalla.

En especial, he notado que algún dígito baila pero se queda estable y con el valor correcto cuando presiono la placa, luego algún corto o algo del estilo debe estar haciendo. Aunque lo he colocado sobre una superficie de cartón. Ya repasaré las soldaduras.

[cacharreo]

Autor: Popopo
Fecha de publicación original: 23 Sep 2022, 19:55

la primera columna representa los pines del ZIF, la segunda columna las pruebas con +5V (que deber dar un 1 como resultado) y la tercera las pruebas con GND (que deben dar un 0).

No se puede afirmar que funciona OK cuando está a 0 por defecto. Para hacerlo bien, pienso que debería estar a 1 primero, así al aplicar a GND se detecta si hay o no cambio.
Por eso mi sugerencia de separar en dos fases esta prueba. Para poder detectar los cambios de estado al usar GND o VCC.

[cacharreo]

Autor: Popopo
Fecha de publicación original: 23 Sep 2022, 20:05

En teoría no sería posible que coincidieran todos los resultados de tu test de pines con los de la tabla de referencia. Aunque en tu caso no cambien, los pines 8, 9 y 11 del zócalo ZIF deberían tener su valor por defecto (es decir, sin conectar nada desde J4) a 1 pero al conectarlos a tierra cambiarían a 0. Para el pin 10 el valor por defecto debería ser cercano a 0 (con una cierta tolerancia, <50).

Si no lo ves claro, publica en el tema un vídeo en el que se vea claramente el tester, su pantalla, J3 y J4 cuando realices las pruebas indicadas con el test de pines para todos y cada uno de los contactos del ZIF del 1 al 19.

Algo tendré mal, porque no están a 1.
Adjunto imagen.

[cacharreo]

Autor: Popopo
Fecha de publicación original: 23 Sep 2022, 20:12

tan claro está que si se prueban como 4164 pasan los tests. Necesitaríamos unas, TI u OKI que da igual, pero que de verdad tengan solo 32kb buenos; o eso, o va a tocar hacer algún cacharrete adicional para las pruebas que independientemente del tamaño real provoque un error cuando se acceda más allá del rango de direcciones supuestamente válido.

Yo tengo OKIs. Esas si recuerdo que las tengo. Pero son funcionales 100% me parece...

En cuanto llegue a casa mido y posteo mis consumos y voltajes.
Lo que si esta claro es que los que se hagan para la tirada, se pidan los Nanos al mismo proveedor. También creo que una vez este la placa nueva se van a evitar estas placas con modificaciones , cortes y puentes y se minimizaran al máximo los errores propios de los prototipos que es lo que son , tenemos que pensar en que cuando estén funcionando tal como lo están haciendo , es de suponer que las nuevas generaciones o revisiones de placa , eliminaran de la ecuación los problemas derivados como interferencias , falsos contactos (propios de las tiras de pines hembra que algunos tenemos) así como errores propios de las modificaciones. Estamos en el buen camino, es cuestión de ir limando.

Amén!
También ando pensando que ya son demasiadas modificaciones y eso puede hacer bailar la cosa. Por mí esperaría una versión más de modificaciones como mucho para mandar hacer nuevas placas. Corre de mi cuenta esta vez.

Versión 1.05
Impresionante!

Y además el enlace ... menuda currada ¿cómo se puede hacer esas cosas en github? ¿Usas alguna herramienta?. No sé como lo haces... apenas tengo tiempo para poder avanzar en nada y tu estás a mil cosas, adelantas todo el trabajo, diseñas, presentaciones... mis respetos más profundos.

¿En este diseño la pantalla algo más gorda tendría cabida?
Por otra parte, si es una versión al que pocas modificaciones hay que hacerla... podría hacer un pedido de ellas para repartirnolas. Aunque me da un palazo estar desoldando... pero un gran palazo por la falta de tiempo, pero mucho mucho palazo... debo admitir que eso libraría de más de algún problema por falsa conexión.

Antes de que se me olvide. En caso de haber espacio de memoria, se podría dejar en las versiones Firm el test de pines como un menú a seleccionar inicial. Test pines // Test memorias. De esa manera se puede seguir haciendo supervisiones sobre adaptaciones de placa etc y comprobaciones.

[cacharreo]

Autor: geloalex
Fecha de publicación original: 23 Sep 2022, 22:03

Yo creo que el test de pines es algo implementado en su momento con fines de test y ajustes , no tienen cabida o sentido en una versión RC o final , lo mas lógico es que si quieres hacer ese test , hagas un downgrade de firm y cargues el v0.19 , hagas las comprobaciones y luego vuelvas al firm mas actualizado.

¿En este diseño la pantalla algo más gorda tendría cabida?

Lee la documentación de la nueva placa REV 1.05 , en ella tienes los detalles en la descripción de J1 y J1'.
Fue algo se propuso hace tiempo y en esta versión se contempla.

[cacharreo]

Autor: cacharreo
Fecha de publicación original: 24 Sep 2022, 08:42

---

También hay que tener en cuenta, que las memorias pueden tener diferentes consumos... y al estar puesta en el ZIF, puede alterar las lecturas.

Cierto pero las medidas que uso de referencia son en esas mismas condiciones y con una memoria de, probablemente, el mismo lote.

El conector ICSP en la placa, es todo un detalle.

Lo añadimos en la placa 1.05, se puede soldar o no según decida el interesado pero si se va a montar en caja y por problemas de espacio el Nano no lo lleva, para los que quieran cacharrear directamente con el Nano puede ser útil.

Me da, que la placa final no va a ser muy diferente a esta.

Para la versión 1.06 una vez todos los tests estén funcionando habrá que reorganizar las correspondencias entre los pines del Nano y los nodos entre los fusibles y los zeners para agruparlos de forma más ordenada y eficiente respecto a los registros (puertos). Eso equivaldría a hacer tantos cortes (2), puentes (2), etc. como intercambios hagamos pero esta vez todo irá en la placa.

[cacharreo]

Autor: cacharreo
Fecha de publicación original: 24 Sep 2022, 09:22

---

Estoy leyendo un poco suelto, ahora pensaba ponerme a seguir con la comprobación de la actualización en la que me quedé, con el firm 0.19.

Es lo suyo, pasar de la versión fw0.19 sin tener todo comprobado va a dar problemas.

Os recuerdo que nos han donado unas cuantas memorias rotas y quizás ya tengamos de esas.

Para las pruebas nos vendrían geniales algunas memorias que tengan errores en el decodificador de direcciones o en algún bit por la zona central o final del espacio de direcciones. Las memorias que están simplemente "fundidas" o que tienen errores muy al principio del espacio de direcciones son menos valiosas en ese sentido.

Bueno, adjunto imagen de resultados y describo.

Los valores de A6 (pin ZIF/J4#10) son ahora los esperados pero no es normal que +5V en J4#1 afecte en D01 y D10; D00, D01 y D07 deberían cambiar a 0 cuando se conecta GND a J4#11, J4#9 y J4#8 respectivamente. Es muy probable que haya errores en los puentes y/o cortes.

En especial, he notado que algún dígito baila pero se queda estable y con el valor correcto cuando presiono la placa, luego algún corto o algo del estilo debe estar haciendo. Aunque lo he colocado sobre una superficie de cartón. Ya repasaré las soldaduras.

Posiblemente no será tu caso pero vuelvo a advertir que si accidentalmente se tocan pines de los componentes es normal que bailen los dígitos en la tercera fila o los valores de A6 o A7. El típico ejemplo es cuando se pulsa el botón OK y se tocan los pines sin conectar de J2.

No se puede afirmar que funciona OK cuando está a 0 por defecto. Para hacerlo bien, pienso que debería estar a 1 primero, así al aplicar a GND se detecta si hay o no cambio.
Por eso mi sugerencia de separar en dos fases esta prueba. Para poder detectar los cambios de estado al usar GND o VCC.

Me temo que hay un malentendido porque no funciona así. Los valores que se muestran en el test de pines son el estado de los pines, es decir, la lectura directa del valor de un pin digital del Nano, y su valor "por defecto" siempre es determinado por el Nano porque nosotros leemos el valor de un puerto (un registro de lectura) que el procesador del Nano actualiza según la tensión que ve conectada a cierto pin digital, por lo que no es posible ponerlos a 0 o a 1 a voluntad (no tendría sentido).

Asunto diferente son los registros de escritura del procesador, esos sí podemos ponerlos a 0 o a 1 a voluntad lo que supone que el procesador del Nano fijará un cierto pin digital a +0V o +5V, pero estos registros son diferentes e independientes a los registros de lectura.

¿Es posible que resulte confuso que en esta familia de microprocesadores existan pines digitales de escritura y lectura que tengan los mismos nombres, D0, D1,...?

Algo tendré mal, porque no están a 1.
Adjunto imagen.

Con el ZIF vacío y con J4 sin cables D00, D01 y D07 deberían estar a 1.

Yo tengo OKIs. Esas si recuerdo que las tengo. Pero son funcionales 100% me parece...

Si pasan el test como 4164 no nos servirían.

Y Además el enlace ... menuda currada ¿cómo se puede hacer esas cosas en github? ¿Usas alguna herramienta?

Gracias. Por principios no me resulta agradable ni tranquilizador instalar o usar software de terceros, menos aún si es software propietario, así que todo lo hago subiendo ficheros con el navegador directamente en la cuenta de github con la opción "Add files".

No sé como lo haces...

No sé si será extrapolable a otros casos porque nuestra organización del tiempo variará de unos a otros, pero en mi caso solo hago una única tarea y no paro hasta que la termino, se tome el tiempo que se tome.

¿En este diseño la pantalla algo más gorda tendría cabida?

Sin problema, en ese sentido nada ha cambiado.

Por otra parte, si es una versión al que pocas modificaciones hay que hacerla... podría hacer un pedido de ellas para repartirnolas. Aunque me da un palazo estar desoldando... pero un gran palazo por la falta de tiempo, pero mucho mucho palazo... debo admitir que eso libraría de más de algún problema por falsa conexión.

De momento no es posible por el motivo de siempre, las pistas entre el Nano y el zócalo ZIF no reflejan las conexiones en el esquema. La placa es provisional y por eso ni nos molestamos en hacer los cambios hasta que tengamos una lista para enviar a fabricar.

Antes de que se me olvide. En caso de haber espacio de memoria, se podría dejar en las versiones Firm el test de pines como un menú a seleccionar inicial. Test pines // Test memorias.

Por ahora vamos holgados y quedan libres más de 5KB por lo que ahora mismo sí que cabe la demo, el test de pines, el de botonera, etc. pero en la versión final sería más que interesante utilizar ese espacio para una tabla grande de valores precalculados que acelerarían muchísimo la generación de números pseudoaleatorios para el último de los tests que, en las pruebas, ha demostrado ser el más lento de todos.

Como apunta @geloalex, al final tendremos dos versiones diferentes del firmware. Una "de desarrollo" exclusiva para el diagnóstico de problemas y otra "de producción" para las pruebas con DRAMs.