Hola planeta9999, pudistes armar una placa con el imxrt1021 en LQFP100?
Yo estoy apuntando al LQFP144 para cuando salga.
Soy el diseñador de esta placa:
https://github.com/martinribelotta/imxrt1020-module
La cual ya hemos discutido previamente en el post correspondiente del blog mcuoneclipse.
También puse un conector USB para probar la carga de firmware encriptado usando la herramienta MFG. Todavía no sé si JTAG puede cargar una imagen de firmware encriptada o solo puede ser por USB/UART utilizando la herramienta MFG. He puesto tanto el conector JTAG como el SWD para probar ambos, y finalmente decidiré cuál prefiero.
Aún me queda bastante por rutear (aunque no es complicado), y creo que tendré que cambiar todos los condensadores de desacoplo, por unos de tamaño 0603, ahora son 0805, me parecen demasiado grandes y dejan poco espacio para el ruteo. Me sorprende la cantidad de condensadores de desacoplo que necesita este microcontrolador, acostumbrado a poner, en los STM32 o Kinetis, uno de 100nF por cada pin positivo, en el RT1020 hay montones, algunos en paralelo de varios valores.
Sigo los consejos de la "Guía de desarrollo de hardware" de NXP. Me llama la atención el comentario sobre el ajuste de la longitud de las pistas en el tarjetero SD, " For the SD module interfaces: o Match the data, clock, and CMD trace lengths (length delta depends on the bus rates). "
Otro problema que se te puede presentar en altas velocidades (que no justo en este diseño con solo QSPI) es el tema de no tener matcheadas las impedancias de las lineas. O mejor dicho, tener des adaptados los 50ohm de las single ended. Matchear a 50ohm con un tickness de PCB mayor a 0.2 es imposible así que ni lo intentes. Actualmente el rebote es soportable según la gente de NXP (ellos recomiendan resistencias en serie pero eso solo evita que no se cargen mucho los GPIO en el rebote... la señal sigue siendo horrible jajajajaja) así que me dijeron en el foro de ellos mismos que las R que usan son de 0ohm y les anda a 133MHz la flash. Entiendo que tu QSPI tiene que andar perfecto a 50MHz.
Contanos tu experiencia cuando tengas el micro montado... en especial con el firmware de NXP que según vi esta un poco verde para estos micros (va lo verde es el MCUExpresso porque las librerías son las imx-6/7/8 revampeadas para tener los IPCore en su configuración correcta)
Está muy bien.
¿ Que tamaño de pasivos estás usando ?, se ven muy pequeños, 0402 o incluso 0201. Yo lo más pequeño que uso es 0603, aunque mi máquina de Pick and Place creo que puede montar hasta 0402, pero contra más pequeños sean menos precisión tiene. Me gustaría dejarlo todo como mucho a 0603, y lo que sea posible incluso más grande.
Lo del boot no lo he mirado todavía, en mi prototipo de momento he puesto los mismos DIP switches que en la placa de evaluación de NXP, aunque creo que todo eso se puede eliminar programando los fuses internos para que el boot sea fijo, por ejemplo siempre desde QSPI.
¿ Que funciones tiene el jumper de tu boot ?.
¿ Sobre el conector de programación, no has pensado en cambiarlo por uno tipo TC2050?, este no necesita conector en el PCB, solo la huella para que enganche el conector TC2050. Yo ya no pongo conector de programación en ninguno de mis nuevos diseños, solo la huella para el conector TC2050, que compré en Digikey junto al adaptador JTAG para el Jlink de SEGGER.
En si, uno nunca debe bajar de 0402 para producción que no sea de alta presición. He hecho algunas cosas con 0201 e incluso con 01002 pero no es fácil conseguir quien los monte.
Te animo a que pruebes 0402 en tu P&P. Con un poco de maña sale bien.
Entre otras opciones lo que controla es el boot device que, la unica cosa interesante que tiene es poder bootear desde SD (en modo RAW... nada de fatFS ni cosas raras)
Desestime por completo toda la funcionalidad de poder elegir esas cosas y me quede con el boot por QSPI y el rom bootloader, que es lo que elige el jumper. Cuando esta puesto fuerza a 1 el pin A0 (BOOT0) mientras que A1 (boot1) esta streapeado con una resistencia de 10K a masa bien cerca de la terminación de la SDRAM para que no moleste.
¿ Sobre el conector de programación, no has pensado en cambiarlo por uno tipo TC2050?, este no necesita conector en el PCB, solo la huella para que enganche el conector TC2050. Yo ya no pongo conector de programación en ninguno de mis nuevos diseños, solo la huella para el conector TC2050, que compré en Digikey junto al adaptador JTAG para el Jlink de SEGGER.CitarLos he mirado con ganas durante mucho tiempo pero esta totalmente afuera de mi presupuesto... considera que mi hora laborable esta en los 3usd en este momento en mi país :5] :5] :5] :5] :5]
Yo terminé hace poco un diseño con 0201 para un cliente, pero él se lo monta, yo solo les hago el diseño. Les pregunté si la empresa que les monta las placas podían con los 0201, y me confirmaron que sí.
No tengo claro todavía, si usaré la SD como arranque, creo que me decantaré por la QSPI. De todas formas, hablas de arranque con la SD en RAW, sin ningún formato tipo FAT32 o similar, en ese caso, si luego en la aplicación quisieramos usar la SD con FATFS, ¿ no se podría ?.
Una de las cosas que aún no se como hacer es el sistema de actualizaciones de firmware para el cliente, en un producto comercial. Con los Kinetis, tengo un bootloader encriptado, que va de fábula. Para los RT, si el arranque fuera desde SD, entiendo que podría dar un archivo imagen para que el cliente lo grabe en su SD con algún programa como los que se usan para crear imágenes para la SD en las Raspberry. El problema es que perdería la funcionalidad de la SD como almacenamiento de archivos de configuración para mis aplicativos, usado FATFS y tarjetas en FAT32.
Lo que si que tengo claro, es que quiero usar la SDRAM, para que mis programas se ejecuten desde ahí. Ya ví en MCUXpresso como se compila para que arranque desde QSPI o SD, y automáticamente el objeto se copie a la SDRAM y se ejecute. Pero para eso necesito el LQFP144, que aún no está comercializado, estoy por sacar uno de las placas de evaluación de NXP que tengo, y montar mi propio prototipo con SDRAM, y ya puestos con el mismo sistema de boot con un solo jumper que tú has puesto.
¿ El modo rom bootloader, es el Serial Downloader para cargar firmware con las MFG Tool por USB ?.
Yo en la placa de evaluación para pruebas, he puesto dip switches a todos las lineas, como en la placa de evaluación, pero en mis diseños finales no habrá nada de eso, estará todo programado con los fuses.
¿ Sabes si los pines conectados con dip switches, una vez arrancado el firmware se pueden usar como puertos ?
El tema fuses aún no lo he mirado. ¿ Se pueden reprogramar todas las veces que se quieran, o una vez programados ya no hay manera de cambiarlos ?. Leí en los foros de Teensy, sobre el nuevo 4.0, que montará el RT1050, y algo de los fuses comentaban, sobre que una vez programado, ya era irreversible.
Juer, pues si que está mal la cosa por ahí. A mi en general me va bastante bien, no me puedo quejar, además buena parte de lo que fabrico se va fuera de España, principalmente a Francia, Alemania, Italia, Reino Unido y Estados Unidos. Aparte recibo encargos de productos a medida, también de fuera de España, acabo de terminar un encargo para una empresa americana, y todo sin problemas.
Segun entiendo del datasheet, la imagen dentro de la FLASH tiene un offset especifico que no entra dentro de los 512 bytes del MBR (que define la tabla de particiones) asi que no habria problema en en dejar una porcion de la SD en RAW y montar el resto de la/las particiones mas arriba.
Lo que yo haria (y de hecho si tengo tiempo haré) para este micro, es armar un bootloader secundario (fuera del serial bootloader que se accede con las MFG Tools) que este encriptado (requiere grabar clave AES en eFUSEs) que pueda leer archivos en FAT (o exFAT que para eso Elm Chan le dio soporte!)
En si, es un lindo proyecto que seria interesante encarar. Si te resulta util, podemos armar algo en github y avanzar desde ahi.
Lo que si que tengo claro, es que quiero usar la SDRAM, para que mis programas se ejecuten desde ahí. Ya ví en MCUXpresso como se compila para que arranque desde QSPI o SD, y automáticamente el objeto se copie a la SDRAM y se ejecute. Pero para eso necesito el LQFP144, que aún no está comercializado, estoy por sacar uno de las placas de evaluación de NXP que tengo, y montar mi propio prototipo con SDRAM, y ya puestos con el mismo sistema de boot con un solo jumper que tú has puesto.CitarEstaria de lujo que nos cuentes como va con eso... aunque de digikey me dijeron que, aunque no tienen fechas de entrega, estiman que el fabricante va a cumplir los plazos esperados para octubre (que era la fecha estimada desde hace casi medio año)