problema de SDRAM - LPC1788

3

He estado usando un placa de desarrollo LPC1788 de NXP en la que he desarrollado mi aplicación en (.NET) Microframework Cortex-M3 Puerto).   Todo estaba bien en este tablero, no tuve problemas con la memoria RAM ni de ningún otro modo, así que estaba listo para comenzar a desarrollar mi tablero de producción.

Creé una nueva placa con la misma RAM y procesador, tomé el binario de la placa dev y lo puse en la nueva placa y tengo problemas al ejecutar SDRAM. No es lo habitual cuando no hay conexión, ni hay un fallo intermitente ... Puedo ejecutar una prueba de memoria (escribir en todo el bloque SDRAM en 32 bits, 16 bits, 8 bits y leer los datos correctos varias veces).

Sin embargo, cuando intento ejecutar mi aplicación, tengo problemas realmente extraños con la RAM que se sobrescribe o no se escribe en absoluto. Esto es solo cuando se ejecuta la aplicación que es perfecta en la placa de desarrollo. No es intermitente, hace lo mismo cada vez. Debido a esto, asumo que no es mi enrutamiento lo que me está causando problemas (porque mi comprobación de memoria pasa).

¿Hay alguna característica extraña del LPC1788 EMC (controlador de memoria ARM PrimeCell ™ MultiPort) que no conozco y que podría estar causando problemas de almacenamiento en búfer o problemas de lectura anticipada? Si alguien con experiencia en esto podría orientarme en la dirección correcta, o ayudarme a escribir una mejor prueba de memoria para probar estas extrañas condiciones, sería muy útil ...

He adjuntado una imagen del enrutamiento, que aunque no es óptima (solo tengo 4 capas, 2 señales, 2 planos de potencia) permite que la RAM funcione y puedo leer desde el dispositivo.

    
pregunta James

3 respuestas

3

Trazos largos y paralelos. Sin terminación de señal. No hay tapas de desacoplamiento en la memoria RAM. Señale los rastros que van de la capa superior a la inferior sin una tapa cerca. Rastros con largos, sin terminar, talones. Algunas señales pasando por 5 vías. Y posiblemente no haya suficientes vías en los pines power / gnd del BGA (pero es difícil decirlo de su imagen).

Cualquiera de estos podría causar problemas de memoria, y algunos a cualquier velocidad. Pruebe cuidadosamente sus relojes en el destino con un alcance de alta velocidad (350 MHz o más) y muéstrele lo que ve. Lo más probable es que tenga un problema con la integridad de la señal.

    
respondido por el user3624
3

Huele como un problema dependiente de los datos. Es posible que tenga un acoplamiento desafortunado entre algunos de los datos y / o líneas de dirección, de manera que el patrón correcto cause un fallo en algún lugar.

Intenta reducir la velocidad del reloj. Cómo el síntoma cambia o no puede dar algunas pistas. Si hay interferencia entre algunas de las direcciones y las líneas de datos, esto debería hacer que el problema desaparezca porque las transferencias se realizan después de que todo se resuelva. Si el problema es que el ruido llega a la línea del reloj, es probable que esto no cambie nada.

Observe algunas de las señales con un alcance y vea qué tan limpias se ven. ¿Puso resistencias en serie con las líneas para igualar mejor la impedancia de la traza y reducir el timbre? Asegúrese de verificar la línea del reloj también, no solo unas pocas líneas de datos. También verifique que realmente tenga la configuración y los tiempos de espera que necesita el chip.

Recuerde que el funcionamiento correcto aparente no es una prueba del funcionamiento correcto, solo de tener suerte.

    
respondido por el Olin Lathrop
2

¿Qué pruebas de memoria estás ejecutando? Además de los clásicos, rellénelo con 0's y F's y A's and 5's and walking y todo eso, y la dirección para hacer una prueba de bits de dirección. Mi favorito es una prueba pseudoaleatoria. tome un lfsr (muy fácil de codificar, determinístico y repetible y es "lo suficientemente aleatorio"), inicialícelo, llene la memoria con números aleatorios (no omita ninguno ni se detenga en corto, de principio a fin, pase una semilla al inicio, asegúrese el lfsr no se repite en el espacio que lo está utilizando), déjelo y vuelva a leer. Colóquelo, llene la memoria con los valores invertidos del aleatorizador, coloque el cheque. Cambia la semilla y repite. Tiendo a dejar correr una prueba como esta por un tiempo. Encuentra rápidamente problemas de bitios y problemas de línea de datos y muchos de los problemas normales más rápido que las pruebas tradicionales.

¿Qué sucede si retrasas el reloj y corres más lento, cambia?

Si no es hardware, entonces céntrese en el software, ¿qué diferencia hay entre la placa de desarrollo y su placa? divida la aplicación en partes y vea si alguna de ellas se ejecuta o si falla, sin importar cuánto la recorte.

    
respondido por el old_timer

Lea otras preguntas en las etiquetas