Autor Tema: NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.  (Leído 8006 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2980
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #15 en: 16 de Septiembre de 2018, 06:45:37 »
Ya que has usado estos micros te pregunto, has utilizado modo bajo consumo con bateria?? Que tal va, se que no es un ultralow power de los de texas pero que tal va de consumo?

Has encontrado algun error en algún periferico? Uart, rtc, can...?
Para guardar en memoria supongo que no habra muchos cambios por que sea externa.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #16 en: 16 de Septiembre de 2018, 08:29:15 »
 
No he probado temas de bajo consumo, estoy centrado principalmente en dominar el DMA, que es lo que más me interesa. Probando DMA con SPI y Periférico a Memoria para leer varios GPIO almacenando en un array.

Ya casi tengo dominado el DMA, luego me quiero poner a probar todo el tema del boot, desde QSPI, SD y con el RT1050 también con la hyperflash. Y lo último, bien con las placa de evaluación que tengo para el RT1020 y el RT1050, o creando mi propio prototipo con un LQFP144, es probar la SDRAM, la idea es que el firmware arranque desde QSPI, se copie a SDRAM y se ejecute desde allí, para conseguir el máximo rendimiento.

De periféricos solo he probado el SPI, y probaré el USB para grabar el firmwae con las MFG Tools, pero confío mucho en NXP, creo que hace un muy buen producto, y todo lo que proporciona es de calidad.

La memoria se gestiona igual que si fuera interna, solo que si quieres que el firmware se ejecute en SDRAM tienes que activarle un parámetro en la configuración de la compilación en MCUXpresso. Además, cuando creas la imagen del programa, tienes opción a configurarle que la encripte, esto es importante para la versión final de un producto comercial, para que no te lo copien, en la fase de desarrollo por comodidad puedes tenerlo desactivado. Con unos fuses internos, configuras el arranque, desde SD, QSPI o Hyperflash (en los LQFP144).


Configurando MXUxpresso, para que la aplicación se copie y ejecute en SDRAM externa, después de haber arrancado desde SD, QSPI o Hyperflash. Tengo por aquí chips SDRAM de 256Mbit y 512Mbit para las pruebas.

« Última modificación: 16 de Septiembre de 2018, 08:38:47 por planeta9999 »

Desconectado rusotech

  • PIC10
  • *
  • Mensajes: 8
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #17 en: 18 de Septiembre de 2018, 10:58:20 »
Citar
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.

Estoy usando 0402 en los capacitores de desacople finos (0.22u y 0.1u), resistencias en 0402 y el resto de los capacitores en 0603 o 0805 (salvo el de 33u del DCDC que es de 1206)

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.
Cuando elegí los componentes pensaba hacerlo todo en 0603 pero viendo las simulaciones de hyperlinx me convencieron de pasarme a lo recomendado por el fabricante que es 0402 en la mayoría de los capacitores de desacople. Posiblemente podriamos intentar una segunda versión volviendo a 0603 pero ya con los capacitores del otro lado de la placa (aquí el plus en el diseño era hacerlo montable en una sola pasada)

Te animo a que pruebes 0402 en tu P&P. Con un poco de maña sale bien.

Citar
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 ?.

El boot en si es simple. Hay tres modos seleccionables con BOOT0(A0) y BOOT1(A1) (si... no se a quien se le puede ocurrir poner pines de bootstrap en señales rápidas):

  • 0b00: Boot from fuses. Que lee los fuses internos y decide como bootear, por defecto los fuses están programados para bootear desde las interfaces QSPI usando una memoria que soporte el comando de lectura 0x0B
  • 0b01: Serial downloade. Independientemente del contenido de los boot device se inicia el bootloader y espera comandos por usb/spi/i2c/serial
  • 0b10: Internal boot. Que como su nombre NO indica, usa los pines externos y los eFUSES del modo 0b00 para determinar que dispositivo va a bootear.
  • 0b11: Reservado

El modo 10 es bastante dificil de entender pero en resumidas cuentas, lee los pines de A2 hasta A10 para determinar el boot. Esto es una molestia porque obliga a streappear todas las lineas con dipswitchs. Tambien es inutil porque esa misma configuracion puede hacere una vez en el startup de la placa grabando los eFUSEs correctamente. 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.

Citar
¿ 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.

Los 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]

PD: Respondo las consultas sobre ruteo de planos de masa en el otro hilo

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #18 en: 19 de Septiembre de 2018, 08:20:05 »
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.

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í.

Citar
Te animo a que pruebes 0402 en tu P&P. Con un poco de maña sale bien.

En teoría la Neoden4, puede con los 0402, pero aún no lo he probado. Suelo usar para pasivos lo más grande que puedo, normalmente 1206, aunque si que he llegado a bajar hasta 0603 en algunos diseños montados a mano, y no hubo ningún problema posicionando a microscopio (cuando no tenía la Pick and Place).

Citar
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)

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.

Otra opción, es que la placa tenga un micro USB, y el cliente tenga que conectar al ordenador, y con el utilitario de NXP, grabe el firmware a la QSPI usando las MFG Tool, esta es la opción que menos me gusta, prefiero actualizaciones por SD, aunque al menos derjaría libre la SD para almacenamiento de archivos de trabajo con el aplicativo con FATFS.

Y la última opcion que se me ocurre, es tratar de hacer un bootloader, pero no tengo información de como podría hacerlo leyendo el nuevo firmare desde la SD y grabándolo en la QSPI. Tendría que crear un bootloader, que quedaría grabado de manera permanente en la QSPI, y al arrancar iría a buscar en la SD algún archivo de actualización, si lo encuentra lo lee y graba el firmware en la QSPI y luego arranca.

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.


Citar
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.

¿ 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.


Citar
¿ 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.
Citar
Los 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]

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.
« Última modificación: 19 de Septiembre de 2018, 08:42:10 por planeta9999 »

Desconectado rusotech

  • PIC10
  • *
  • Mensajes: 8
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #19 en: 21 de Septiembre de 2018, 21:10:22 »
Citar
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í.

Es bastante normal en china contar con maquinas "baratas" (para el mercado) que permiten incluso montar 01002 sin mucho esfuerzo. De todas formas son maquinas que requieren ajustes constantes y un personal especializado. Para uso comun tu Neoden4 deberia andar perfecto con 0402.

Citar
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 ?.

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.

Citar
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.

Yo las veces que lo he hecho para distintos lugares donde trabajé, usaba un bootloader propio desde la FLASH interna... solo una vez toco hacer algo en flash externa en la que usaba un zynq Z7010 que booteaba desde una QSPI. Por suerte, el micro soportaba grabar una clave AES en PROM para encriptar el bootloader QSPI que luego permitia cargar un u-boot encriptado desde SD (no habia forma de bootear desde SD con el romBOOT en ese pinout)

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.

Citar
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.

Estaria 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)

Citar
¿ 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.

Correcto, colocando el jumper el micro esperaria comandos del MFG Tool por usb y/o serial. Los dipswitch serian ignorados siempre que uses BOOT1 en 0.

Citar
¿ Sabes si los pines conectados con dip switches, una vez arrancado el firmware se pueden usar como puertos ?

Es correcto, como todos los pines de bootstrap, el rom boot lee los estados al arranque y luego los deja libres para operar. Esto es particularmente molesto porque estan en pines "rapidos" como A0 a A11 de la SDRAM, lo que obliga a ponerlos debajo del PCB (como en la placa de desarrollo de nxp) o usar los eFUSES (como en mi caso)

Citar
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.

Entiendo que los eFUSEs son PROM y no FLASH asi que no seria buena idea programarlos de forma despreocupada. Eso si, se puede enmascarar algunos de los pines de bootstrap. Es decir, poner solo los necesarios a pines y los otros desde eFUSEs. Tengo que estudiar mas el asunto... ni bien lo tenga claro lo posteo en este foro  ;-)

Citar
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.

Pessss... Argentina es un mundo aparte... entiendo que en España no son Alemania ni Suecia pero no llegan al nivel de mi pais (las cosas basicas funcionan y la moneda es estable)
El unico lugar que esta peor que argentina es Venezuela y allí el problema ya no es trabajar sino directamente comer...

Una buena cosa que tiene estar en España es que existen en el radar mundial... Fui a china en 2016 y la mitad de la gente con la que me tope no podia ubicar en el mapa mi pais... creian que estaba cerca de italia o algo asi...  :lol: :lol: :lol: :lol:

Supongo que si las cosas se complican mas, tendre que emprender el camino inverso a mis bisabuelos de hace 100 años  :(

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #20 en: 21 de Septiembre de 2018, 22:30:23 »
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.

Eso estaría bien, así podría arrancar desde SD y usar desde mi firmware la tarjeta para almacenar archivos de datos y configuración.

El caso es poderle dar al usuario las actualizaciones de firmware para carga desde SD, es lo que uso con los Kinetis por medio de un bootloader encriptado, lo prefiero a usar USB y tener que conectar a un PC.


Citar
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.

Si, sería muy interesante, para mi lo primordial es disponer de un bootloader encriptado, imprescindible para poder dar actualizaciones a los clientes. Es lo primero que miro y desarrollo cuando empiezo a trabajar con una nueva familia de microcontroladores.

Supongo que lo único a estudiar, es como grabar en la QSPI, si la usamos como sistema de arranque, metiendo ahí un pequeño bootloader encriptado que lea desde la SD y grabe a partir de cierta página (si es que la QSPI también va por páginas, y se graba como la flash).

Mi duda, de todas formas, es como se puede combinar eso con el arranque desde QSPI, con copia automática a SDRAM para que se ejecute todo desde la SDRAM. Porque si se compila para arranque desde QSPI con copia a SDRAM, lo que se transfiere a la SDRAM es solo el bootloader, no la aplicacion de usuario.


Citar
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.
Citar
Estaria 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)

El sistema de actualizaciones y esto de ejecutar desde la SDRAM es lo que más me interesa, porque necesito mucha velocidad y cargar tablas bastante gordas en la SDRAM para un acceso muy rápido. Compré varias SDRAM de 256Mbit y 512Mbit, para montar un prototipo con un LQFP144, sacando el micro de una de las placas de evaluación que tengo, o también se puede probar en la propia placa de evaluación de NXP.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #21 en: 22 de Septiembre de 2018, 17:24:19 »
 
He abierto un proyecto en mi cuenta de Gitlab, si quieres podemos ir colgando ahí lo que vayamos creando para los RT, empezando por un sistema de bootloader encriptado.

Hay muchas más cosas interesantes que se pueden ir colgando, yo en cuanto profundice con el DMA, puedo colgar proyectos para MCUXpresso totalmente funcionales, y cualquier otra cosa que vaya surgiendo.

Este es el enlace a mi cuenta de Gitlab para colgar y ver cosas, en el apartado que he creado para los RT. Desde que Microsoft compró Github, prefiero usar Gitlab, como muchos otros usuarios.

https://gitlab.com/pinballsp/proyectos-nxp-i.mx-rt-series

Ahora mismo, precisamente, tengo unas cuantas placas que montar de varios prototipos que he diseñado, tengo dos con el RT1020.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:NXP RT1020, LQFP100/144, Cortex M7, 500Mhz, ya disponible.
« Respuesta #22 en: 03 de Octubre de 2018, 16:12:23 »
 
Ya monté mis placas. Una con un RT1020 LQFP100, y la otra es una placa de expansión para pincharla en la placa de evaluación de NXP, con un conector tipo Arduino.

La ventaja de la placa de expansión, es que puedo usar el LQFP144 con la SDRAM que instala NXP, porque de momento los LQFP144 no están disponibles, aunque queda ya muy poco, según NXP para Diciembre los tenemos.










 

anything