NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.

[planeta9999]

 
Ya está el tema en marcha, NXP ha puesto a la venta las placas de evaluación para los RT1020, un microcontrolador con encapsulado LQFP100 y LQFP144, Cortex M7 a 500Mhz.

Lo raro es que las placas de evaluación ya se pueden comprar, yo ya tengo pedida la mía a Mouser, pero el micro aún no está en stock, y tampoco han liberado el Datasheet, ni el Manual de la placa de evaluacion.

De documentación, han soltado fundamentalmente Notas Aplicativas, y el único documento interesante una "Guía de Desarrollo Hardware". Se supone que el día 26 del mes actual ya tendremos el Datasheet y se pondrán comprar los chips y pedir muestras gratuitas a NXP.

La documentación disponible, aquí:
https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series/i.mx-rt1020-crossover-processor-with-arm-cortex-m7-core:i.MX-RT1020?tab=Documentation_Tab

La placa de evaluación, vale poco más de 44€ en Mouser, raro también que no hayan puesto una foto del producto: https://www.mouser.es/ProductDetail/771-MIMXRT1020-EVK

De la documentación, le he echado un ojo a este documento para habilitar el arranque desde QSPI, y como generar el objeto, una vez compilado, para cargarlo. El ejemplo que ponen para cargar el programa, a mi no me vale, porque están usando un chip Kinetis que actúa de intermediario, y mi idea es cargarlo desde SD a QSPI.

https://www.nxp.com/docs/en/application-note/AN12108.pdf
 
La única peculiaridad de este micro, con respecto a otros, es que no tiene memoria flash interna. Para el arranque hay que conectar y habilitar una de las tres opciones posibles; tarjeta SD, memoria QSPI o Hyperflash paralelo.

Aprovechando el pedido a Mouser de la placa de evaluación, me he pedido unas memorias QSPI y una Hyperflash. También pedí a los polacos unos reguladores de 1.8 voltios, porque estas memorias, se alimentan ambas a ese voltaje.

Lo único complicado con la Hyperflash es que es encapsulado FBGA, pitch 1mm, en una matriz de 5x5 bolas, no se si esto lo podré hacer con un PCB de 2 capas, lo intentaré. Aparte de la placa de evaluación, en cuanto esté el Datasheet y los chips, mi idea es montar mi propia plaquita con el micro, su cuarzo (creo que es de 24Mhz), tarjetero micro SD, memoria QSPI y puede que la Hyperflash, también un regulador LD1117 de 3.3v para el micro y un MIC5504 para los 1.8v.

Esta es la hyperflash, bastante cara por cierto, si me funciona bien con la QSPI o incluso con el tarjetero SD, prescindiré de la hyperflash.

https://www.mouser.es/ProductDetail/727-S26KL128SDABHI02




En cuanto tenga la placa de evaluación, y el datasheet, mi idea es empezar las pruebas con MCUXpresso. Empezar con lo sencillo, probar el arranque desde las tres opciones posibles, y en cuanto lo tenga más o menos dominado, meterme con el DMA, que es lo que más me interesa. Y finalmente migrar todos mis desarrollos de Kinetis y STM32, al RT1020.

El precio del chip es una ganga, desde 6€ para una unidad, y bastante menos en cantidad.

Lo único en lo que cojea el RT1020 es que no tiene ningún controlador integrado para manejar pantallas TFT, una pena, para eso hay que usar el RT1050, pero ese ya es BGA, o echar mano de los STM32 que si tienen controladores TFT, bien paralelo o MIPI DSI.

[planeta9999]

 
Ya tenemos disponible el SDK del RT1020 para MCUXpresso. Lo he descargado, lo he importado a MCUXpresso y se ve muy bien, entre otras cosas, va bien cargado de fuentes de ejemplo (lo que siempre echo de menos en la mayoría de entornos de desarrollo, muchos fuentes de ejemplo, es como mejor se aprende), desde lo más sencillito para encender un Led, leer unos puladores, sacar variables por la Consola, hasta ejemplos para manejar toda la periferia del microcontrolador.

La semana que viene me entregan la placa de evaluación, y empiezo las pruebas. Interesante ver que tiene un Debug que directamente permite usar el PRINTF para volcar cualquier variable, en tiempo real, a la salida de la Consola del MCUXpresso, para mi mucho mejor que tener que usar el Debug con Breakpoints, en este aspecto viene a ser como Arduino.




A partir de los fuentes de ejemplo del SDK, también veo que la placa usa un cuarzo de 24Mhz, así ya lo voy comprando para hacer mi placa, ya tengo la QSPI y la Hyperflash. He estado viendo varios fuentes más, y se ve todo muy familiar para cualquiera que sepa programar en C/C++ y más habiendo ya trabajado con otros micros NXP, como los Kinetis, no creo que me cueste mucho hacerme con esta maravilla de micro.

Incluso estoy pensando en probar a hacer una plaquita de 4 capas con el RT1050 en BGA, mi única duda es si los condensadores de desacoplo tendrán que ir por la cara de abajo (y el micro en la de arriba), porque eso me complicaría mucho el ensamblaje y soldadura para hacer un producto comercial. En el Teensy 3.6, que instala un Kinetis MK66 en BGA, no se ven componentes por la cara de abajo, me extraña un poco, a menos que las bolas con los pines de alimentación y GND, estén todas en el perímetro del encapsulado.

Uno de los tantos ejemplos que lleva cargado el SDK, uno sencillito, el típico para parpadear un led haciendo uso de una interrupción. En boards.h y boards.c, se define la frecuencia del cuarzo y la frecuencia de reloj, 24Mhz de cuarzo y 500Mhz de reloj para el RT1020.

Código: C++

1. /*
2.  * The Clear BSD License
3.  * Copyright 2017 NXP
4.  * All rights reserved.
5.  *
6.  */
7.  
8. #include "board.h"
9. #include "fsl_gpio.h"
10.  
11. #include "pin_mux.h"
12. #include "system_MIMXRT1052.h"
13. /*******************************************************************************
14.  * Definitions
15.  ******************************************************************************/
16. #define EXAMPLE_LED_GPIO BOARD_USER_LED_GPIO
17. #define EXAMPLE_LED_GPIO_PIN BOARD_USER_LED_GPIO_PIN
18.  
19.  
20. /*******************************************************************************
21.  * Prototypes
22.  ******************************************************************************/
23.  
24. /*******************************************************************************
25.  * Variables
26.  ******************************************************************************/
27. volatile uint32_t g_systickCounter;
28. /* The PIN status */
29. volatile bool g_pinSet = false;
30.  
31. /*******************************************************************************
32.  * Code
33.  ******************************************************************************/
34. void SysTick_Handler(void)
35. {
36.     if (g_systickCounter != 0U)
37.     {
38.         g_systickCounter--;
39.     }
40. }
41.  
42. void SysTick_DelayTicks(uint32_t n)
43. {
44.     g_systickCounter = n;
45.     while(g_systickCounter != 0U)
46.     {
47.     }
48. }
49.  
50. /*!
51.  * @brief Main function
52.  */
53. int main(void)
54. {
55.     /* Define the init structure for the output LED pin*/
56.     gpio_pin_config_t led_config = {kGPIO_DigitalOutput, 0, kGPIO_NoIntmode};
57.  
58.     /* Board pin init */
59.     BOARD_InitPins();
60.     /* Update the core clock */
61.     SystemCoreClockUpdate();
62.  
63.     /* Init output LED GPIO. */
64.     GPIO_PinInit(EXAMPLE_LED_GPIO, EXAMPLE_LED_GPIO_PIN, &led_config);
65.  
66.     /* Set systick reload value to generate 1ms interrupt */
67.     if(SysTick_Config(SystemCoreClock / 1000U))
68.     {
69.         while(1)
70.         {
71.         }
72.     }
73.  
74.     while (1)
75.     {
76.         /* Delay 1000 ms */
77.         SysTick_DelayTicks(1000U);
78.         if (g_pinSet)
79.         {
80.             GPIO_PinWrite(EXAMPLE_LED_GPIO, EXAMPLE_LED_GPIO_PIN, 0U);
81.             g_pinSet = false;
82.         }
83.         else
84.         {
85.             GPIO_PinWrite(EXAMPLE_LED_GPIO, EXAMPLE_LED_GPIO_PIN, 1U);
86.             g_pinSet = true;
87.         }
88.     }
89. }

[planeta9999]

 
Hoy recibí la placa de evaluación para el RT1020, con un día de antelación. Esta placa instala un LQFP144 a 500Mhz. Parece que no hay Hyperflash, solo QSPI y SDRAM. Supongo que solo podrá arrancar desde SD o QSPI, a diferencia de la placa de evaluación del RT1050 que además añade Hyperflash.

El SDK del RT1020 ya está disponible para MCUXpresso. Lo descargué e instalé, en general bien aunque las Peripheral Tools y la configuración gráfica del Reloj no están disponibles aún. Lleva muchos ejemplos de código fuente y documentación, eso está muy bien, lo que siempre le he pedido a un entorno de desarrollo, fuentes de ejemplo a cascoporro, que es como mejor se aprende en vez de Manuales de Referencia con miles de páginas que no hay quien se las trague.

Con la placa solo dan un cable micro USB, eso es todo, un poco rácanos. No hay ningún software, CD o DVD, solo un documento impreso del Packing List, donde lleva impresa la dirección web nxp.com/MIMXRT1020EVKQSG, para en teoría descargar la Guía de Usuario de la placa, pero esa dirección no funciona. Espero que el día 26 estén disponibles el Datasheet, el Manual de Referencia del micro y el Manual de usuario de la Placa de Evaluación.

La primera impresión es buena, tanto el hardware, como el SDK prometen mucho, ya estoy preparado para migrar todos mis desarrollos de Kinetis y STM32, a esta maravilla que es la serie RT de NXP.

Por cierto, en la última foto, hay un chip de la placa que no consigo identificar, con la referencia que lleva impresa no me sale nada por Google, solo se ve que lo fabrica NXP.

[planeta9999]

 
Ya tenemos el chip en el mercado (el LQFP100 a 500Mhz), por ahora solo en Digikey, yo me pedí 10 unidades hace unos días a 5,37 Euros la unidad, gastos de envío gratuitos para pedidos que superen los 50 euros, como en Mouser. Una auténtica ganga para un Cortex M7 a 500Mhz, me los han entregado hoy por UPS.  Samples gratuitos, por ahora NXP no da.

Para mi sorpresa no me han hecho pagar IVA. Según la web de Digikey, ellos pagan los aranceles de Aduanas, pero el IVA lo tiene que pagar el cliente cuando te lo entrega el repartidor. Mouser funciona parecido, pero el IVA te lo cargan en la tarjeta de crédito.

En cuanto tenga un hueco libre, que es básicamente cuando eche a andar la Pick and Place, me pongo a diseñar el PCB para esta maravilla, algo sencillo con tarjetero micro SD, QSPI de 64 Mb, cuarzo de 24Mhz, algunos leds para tareas de debug y unos conectores IDC para mi aplicación de pantallas led. Pondré en práctica por primera vez lo del "Length Tuning" para rutear la QSPI y el SDIO.

Lo único en lo que flojea el RT1020 es en el SDK para MCUXpresso, todavía no soporta las Peripheral Tools, que es el asistente para configurar toda la periferia, me interesa sobre todo para el DMA y las interrupciones, si no hay que hacerlo todo a mano, o tirar de alguno de los ejemplos de código fuente y ver como está montado.

De las cuatro referencias de RT1020, dos LQFP100 y dos LQFP144, a 400 y 500Mhz, por ahora solo está disponible el LQFP100 a 500Mhz. La placa de evaluación monta un LQFP144 a 500Mhz.

[rusotech]

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.

[planeta9999]

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.

Hola Martin.

Estoy preparando el diseño, el esquema ya lo tengo prácticamente completo para el LQFP100, con el conector para programar y hacer Debug por JTAG y un mini USB para cargar la imagen encriptada del firmware con la MFG Tool, aunque tengo dudas sobre donde se conecta la QSPI. En los esquemas de la placa de evaluación con el LQFP144, la SD va conectada al puerto GPIO_SD_B0, que no existe en el LQFP100.

He conectado en mi esquema la tarjeta SD al puerto GPIO_SD_B1. El problema es que si conecto la QSPI tambien a GPIO_SD_B1, el pin  GPIO_SD_B1_06 quedaría compartido entre la SD y la QSPI. En la SD, ese puerto va a la señal SD_CD_SW (creo que es la detección de tarjeta SD), y en la QSPI ese es el pin 3 de datos, sospecho que no funcionaría.

La alternativa es llevarme la QSPI al puerto GPIO_AD_B1, por lo que vi en el Manual de Referencia (FlexSPI 2nd option). Lo pregunté a NXP en su foro y también como una consulta privada, y de poco me sirvió la respuesta, porque prácticamente me remitieron al Manual de Referencia, que yo ya me había visto. 

https://community.nxp.com/message/1038958

Estoy por arriesgarme, pongo la QSPI en GPIO_AD_B1, ruteo y mando a fabricar a JLCPCB. Creo que es lo correcto, considerando todo esto del IOMUX para configurar las funciones alternativas de cada puerto, pero como estoy empezando con el RT1020 no estoy seguro al 100%.

[planeta9999]

 
La cosa se complica, porque ahora resulta en que el puerto GPIO_AD_B1 también esta JTAG y SWD. Si ahí se conecta la QSPI, no se podrá hacer Debug, eso seguro, tal vez si se deje programar.

Lo único que se me ocurre para tenerlo todo es poner la QSPI en GPIO_SD_B1, siempre que el pin SD_CD_SW de detección de la SD, en el puerto GPIO_SD_B1_06, sea algo opcional que se pueda desactivar.

Si a cada pin, se le puede configurar individualmente su función alternativa, entonces supongo que se puede conectar GPIO_SD_B1_06 solo para la QSPIk sin que interfiera con la SD. Es lo que tiene cuando empiezas con algo, todo son dudas, y los manulaes como son tan crípticos, no ayudan demasiado, tampoco puedes esperar mucho del soporte oficial de NXP que ante estos pasteles te remiten al Manual de Referencia o al Datasheet, y búscate la vida Serafín.

Consultando el Manual de Referencia, apartado del Mutiplexado de pines, me encuentro que FlexSPI (A), permite elegir entre dos puertos para cada señal. Falta saber si se pueden mezclar o todas tienen que ser del mismo puerto. Tampoco tengo claro que no es lo mismo el Multiplexado de los pines y  la configuración del Boot de arranque.

Salir, saldrá, pero a base de echarle horas a cascoporro, pruebas y prototipos que terminarán en el cubo de la basura, me lo veo venir.

[planeta9999]

 
Creo que me voy a arriesgar a poner la QSPI en GPIO_SD_B1. Por lo que voy entendiendo del multiplexado de pines, hay pines que pueden tener varias funciones configurables por el usuario, solo UNA, por lo que en teoría no puede haber un pin compartiendo varias funciones, en este caso entre la SD y la QSPI.

Según la tabla adjunta, el puerto GPIO_SD_B1_06 puede configurarse con 7 funciones alternativas (en el manual pone 8, pero yo cuento 7), la ALT0 sería para que funcionase como el Card Detect de la tarjeta SD, y el ALT1 para que funcione como la linea 3 de Datos de la QSPI, que es lo que me interesa.

De esta manera me quedan libres los pines 0 a 6 del puerto GPIO_AD_B1 para el JTAG o el SWD, ambos para poder programar y hacer Debug. Aunque sigo teniendo dudas de si el modo Boot para la SD exige que GPIO_SD_B1_06 esté asignado a la SD, de ser así tampoco creo que haya problema, puedo configurar el Boot desde QSPI, y el acceso al tarjetero SD solo para modo de trabajo, lectura y almacenamiento de archivos de configuración.

Bueno Martín, si lo lees, ya comentarás que te parece, mi idea es mandar a fabricar el PCB esta próxima semana, recibo la placa una semana despues, y lo monto todo a ver que sale. Para el LQFP144, que para mi sería el ideal, todavía hay que esperar bastantes meses, hasta finales de año, y a mi me interesaría tener en marcha este bicho lo antes posible, para poder migrar mis diseños de Kinetis MK66 a RT1020.

Ya empecé a leer el apartado del DMA en el Manual de Referencia, y con la ayuda de otros textos lo voy entendiendo, quiero empezar probando el DMA por SPI y luego en paralelo de varios puertos GPIO a varios arrays.

[planeta9999]

 
Ya empecé a crear mi placa personalizada con el microcontrolador RT1020 en LQFP100 (el único disponible). Finalmente decidí poner la QSPI en el puerto GPIO_SD_B1, dejando el puerto GPIO_AD_B1 libre para JTAG o SWD.

He puesto puentes para configurar todo el sistema de arranque, ya que es una placa experimental para migrar uno de mis productos con Kinetis MK66. En la versión final, los fusibles se programarán internamente para el modo de arranque y todos estos puentes desaparecerán, dejando a su vez más puertos libres. No sé si reemplazar los jumpers con interruptores DIP, en general los jumpers parecen más prácticos en las placas de desarrollo.

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). "

Creo que para la próxima semana puedo tener el diseño listo para enviarlo a JLCPCB, y en unos días tengo la placa para ensamblarlo aquí, y empiezo con las pruebas.

[planeta9999]

 
PCB terminado y enviado a JLCPCB. En una semana espero recibirla y empiezo el ensamblaje y pruebas. Finalmente he puesto todos los condensadores de desacoplo de tamaño 0603, y el cuarzo SMD de 5x3mm. También he puesto interruptores DIL, en vez de los jumpers, supongo que si se eligen de calidad no darán problemas, porque me experiencia con este tipo de interruptores de los chinos, fue bastante mala, fallaban muchisimo.

[rusotech]

Hola planeta9999, perdón el retardo en responder pero he tenido un par de semanas so-fucking-hot-of-work.

Voy respondiendo por partes (lo que me acuerdo y puede serte util):

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.

JTAG puede hacer todo... básicamente tenes acceso al bus del CPU con ello. Yo he probado openocd con los imx6/7 (que tienen una arquitectura muy similar a los imx-rt pero con cortex-a7/a9) y se puede acceder al bus interno como si fueras un CPU mas. De ahí, el truco es bajarles un firmware a RAM y usar las interrupciones y algunos buffer en RAM para transmitir información entre el debugger y el MCU. Con esto, grabar la flash externa es pan comido... Entiendo que con el jlink comprado los micros están soportados al 100% (ya que NXP paga a segger para ello) y que en breve estará el script para usarlos desde openocd.

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.

Incluso los 0604 son "grandes" para este micro, pero creo que va a ir bien... Cuando mas alta es la frecuencia de operación esto se vuelve común, incluso teniendo que echar mano de capacitores en array como estos:
https://www.digikey.com/product-detail/en/samsung-electro-mechanics/CL21B104MOCNBNC/1276-2452-1-ND/3890538

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). "

Sobre eso hay mucho mito y miedos varios dando vuelta por internet. En general, la diferencia entre pistas NO debe ser mayor al 10% de la longitud de onda del 5to armónico de tu señal cuadrada (recordar que una cuadrada esta formada por la sumatoria de armónicos sinusoidales impares) con lo que, si tu frecuencia es de 100MHz (cosa que pocas QSPI soportan) debes tener en cuenta una freq. sinusoidal de máximo 500MHz en tus lineas, y tunear su largo para que el frente de ondas no llegue desfasado las del 10% de esos 500M.

Luego el tamaño de esa onda hay variaciones de como calcularla, la mas simple (y la mas alejada de la realidad) es:

Ldiff_max=c/f

donde c es velocidad de la luz (299792458 m/s) que para 500MHz da: 0.0599584916 m. Esto es, casi 6cm de offset entre una y otra linea. Si nos ponemos exquisitos, podemos hablar de en vez del 10% un 5% lo que nos da algo así de 3.5cm.

Por supuesto, en el cobre c es distinta a la velocidad en en el vacío y esta afectada por un factor que depende de tantísimos parámetros que siempre se aproxima. Yo uso para FR4 el valor de 0.45*c lo que, a efectos prácticos nunca me ha dado peor que en las mediciones (esto con un network analyzer). Entonces de nuestros 3.5cm quedarían algo así de 2.7cm (0.1*299792458*0.45/500e6) lo cual sigue siendo un mundo respecto a las diferencias que tenes en tu placa.

Lo mismo aplica para la FlexRAM/FlexFLASH y los distintos grupos de la SDRAM (Grupo de direcciones y control: { A0...12, BA[1:0], nCAS, nRAS, nWE, nCE } y grupo de datos: D0..7, D8..15, DQML-DQMH, CKE, CLK).... Ok, con la sdram estoy haciendo una super simplificación porque hay mas reglas entre ellas pero en si, es fácil de ver.

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)

PD: Perdón si algún argentinismo no se entiende bien... escribo algo apurado jejeje

[planeta9999]

 

Pues ya recibí la placa, ahora ando un poco liado con varios temas, intentaré montarla este fin de semana. Adjunto foto.

También me pedí un cable TC2050 de Tag Connect, este es un tipo de conector especial para programar y hacer debug por JTAG, que no necesita poner conector en el PCB, solo la huella para que los pines del conector toquen los pads, te ahorra tiempo y dinero en el ensamblaje. http://www.tag-connect.com/TC2050-IDC

En el diseño del PCB, cometí un error, porque desconocía como funciona el DMA. Necesito volcar datos de un array a varios pines de un puerto, y pensé que se podían elegir cualquier puerto y pin, luego me enteré que todos los pines deben de ser del mismo puerto y contiguos formando 1 o varios bytes. He diseñado una pequeña placa adaptadora con un conector IDC que reordena los pines, así podré probar mi aplicativo, que es una pantalla led con módulos HUB75.

La QSPI y el tarjetero SD, practicamente los tengo pegados al microcontrolador, con pistas muy cortas y directas, por eso no perdí el tiempo ajustando el largo para que todas coincidan.

Sobre el tamaño de los pasivos, aunque mi máquina de Pick and Place (una Neoden4) en teoría puede montar hasta 0402, prefiero siempre poner los componentes lo más grandes posible para evitar la imprecisión del posicionamiento de componentes muy pequeños. Si puede ir con 0603, para mi perfecto.

[planeta9999]

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.

Este es un tema que se me escapa, porque nunca he trabajado con dispositivos tan rápidos, lo máximo los Kinetis MK66 a 180 Mhz, y estos lo llevan todo dentro del microcontrolador.

De QSPI, pedí estos dos modelos, ambas a 133 Mhz, de 64 Mbit y 128Mbit.
https://www.mouser.es/ProductDetail/870-25LP064A-JBLE
https://www.mouser.es/ProductDetail/870-IS25LP128-JBLE

Los avances y algunas dudas que me van surgiendo, por ejemplo con el DMA, las voy planteando en los foros de EEVBlog, allí hay bastante movimiendo y participación. Lo curioso es que en los foros de NXP, apenas contesta nadie a los posts, solo de vez en cuando y casi siempre técnicos de NXP (aunque las respuestas que dan no suelen aportar mucho).

http://www.eevblog.com/forum/microcontrollers/nxp-rt1020-programdebug-by-swd/
http://www.eevblog.com/forum/microcontrollers/dma-memory-to-peripheral/

Ahora me estoy planteando si comprar esta nueva placa de evaluación para el RT1050, fabricada por Embedded Artists.

https://www.mouser.es/ProductDetail/924-EAK00296

Lo bueno que tiene con respecto a la de NXP, es que te da acceso a todos los puertos del microcontrolador, mientras que la de NXP solo te pone unos conectores tipo Arduino con unos pocos puertos. Con respecto al RT1020, como no está todavía disponible el LQFP144, no puedo hacer mi placa con SDRAM, que me interesa mucho para cargar datos y programa para una aplicación que necesita un acceso muy rápido y mucha capacidad en RAM.

Ahora lo tengo todo en fase de pruebas, pero mi intención es usar el RT1020 LQFP144 para casi todos mis diseños, con QSPI y SDRAM. Solo en algunos casos en que no necesite la SDRAM, para proyectos sencillos, usaré el LQFP100 con QSPI nada más.

Incluso he pensado en atreverme con el RT1050 en BGA, ahora que tengo la Pick and Place, pero haciendo un sistema modular, con el micro en una pequeña plaquita a 4 capas, algo tipo SODIM o con otro tipo de conectores de menos pines según la aplicación. En principio la única ventaja que le veo al RT1050, es que incorpora controladores para displays TFT.

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)

En MCUXpresso, lo único que echo en falta para los RT, es las Peripheral Tools, me dijeron en los foros de NXP, que estarán disponibles en el último trimestre de este año. Creo que coincidirá todo, disponibilidad del RT1020 LQFP144, y liberación del SDK con soporte para las Peripheral Tools.

A mi lo que más me gusta de MCUXpresso, tanto para Kinetis como para los RT, es la cantidad de fuentes de ejemplo que lleva el SDK, es genial. Tienes una opción directa crear tu proyecto a partir de los ejemplos que trae el SDK. Por contra, no creo haber visto nada parecido en ST, con sus STM32, allí puedes echar mano del Cubemx, pero no te dan ningún fuente de ejemplo de programas modelo. Para mi es algo bastante importante, lo ví por primera vez en el entorno de Arduino, es una de las pocas cosas que me parecieron geniales, igual que su sistema de Debug usando printf  para enviar cualquier variable a una ventana de puerto serie.

[rusotech]

Bueno... va tomando forma lentamente:


Algunos cambios:

• Ruteo enteramente en 6mil/6mil con 0.3mm de drill
• Agregado usb to uart usando CP2102 en USART1
• regulador achicado a uno mas barato de 500mA (nadie va a consumir en 3v3 1.5A!!!)
• esquema de ROM boot cambiado de dipswitchs a jumper simple
• cambiadas las dimenciones para entrar en un din-enclosure estandar

En estos dias estoy haciendo la compra en digikey ni bien me respondan cuanto van a tardar en mandarmelo desde la fabrica de NXP (ellos no lo tienen en stock, tienen que pedir a fabrica)

[planeta9999]

 
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.

Te dejo unas fotos del TC2050, en una de mis placas, es un conector de 2x5 muy pequeño (JTAG/SWD), con pestañas para fijarlo al PCB. Lo hay incluso más pequeño (TC2030) de 2x3 para usar solo SWD, y aún más pequeños sin pestañas, pero esos los tienes que sujetar con la mano porque no se enganchan a la placa, solo se quedan presionando los pines sobre los pads de la placa.