Autor Tema: PIC32MZ - Estrenando micro y bugs en el silicio/compilador  (Leído 36405 veces)

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

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« en: 30 de Noviembre de 2014, 19:58:48 »
Hola  :mrgreen:

Trabajando en un proyecto con el amigo Akenafab estamos usando un PIC32MZ1024ECG100. Como es un micro nuevo de Microchip pues va a traer errores en el silicio y en su compilador y demás detalles incómodos.

Aquí la errata...
http://ww1.microchip.com/downloads/en/DeviceDoc/80000588E.pdf

El primero con el que me topo... el oscilador primario de 24MHz basado en cristal no funciona. El micro lleva un cristal de 24MHz que se divide internamente en 3, se multiplica por 50 y se divide en 2 para obtener los 200MHz del System Clock. Desafortunadamente a los de Microchip se les olvidó agregar una pull-up en OSC2 y el cristal jamás oscila... sólo tocando con los dedos a veces me funcionaba.

La solución sugerida es colocar una pull-up de 10k a 3V3, pero lo hice y funcionó una sóla vez. Medí con el osciloscopio OSC2 para ver cómo oscilaba el cristal y dejó de oscilar.

La sugerencia real... usar el FRC interno. Funciona a 8MHz y puede entrar al PLL y elevarse a 200MHz como el POSC. Un poco desafortunado ya que el cristal debería usarse para tener un USB clock preciso para High Speed, no sé si con el FRC también se pueda lograr.

Si llego a encontrar otro glitch tan incómodo como éste se los compartiré. Saludos.

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #1 en: 01 de Diciembre de 2014, 05:32:48 »
Yo no entiendo como con un error asi tan grande pueden liberar a la venta un IC. Por que me parece realmente grande el error :/

Digo.... no van a sacar una partida y ponerle un cristal para ver si oscila ?

Desconectado manwenwe

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 2211
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #2 en: 01 de Diciembre de 2014, 05:51:22 »
Y tanto....pedazo de cagada :shock:
Ojo por ojo y todo el mundo acabará ciego - Mahatma Gandhi -

Desconectado MerLiNz

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2463
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #3 en: 01 de Diciembre de 2014, 08:22:48 »
Lo han sacado en modo "prueba" o beta como algunos llaman, es logico ya que los usuarios son los que mas cuenta se dan de los bugs entonces les viene bien que los clientes les "echen una mano" es la moda ahora, los juegos tambien los sacan beta para que la gente lo vaya probando y vaya reportando los fallos, asi se ahorran bastante tiempo y dinero en probarlos ellos mismos...

De todas formas lo bueno que tiene microchip esq si dan problemas asi te cambian el MCU sin poner pegas, yo compre unos pics que segun microchip fallaban en el modulo ADC, sin saberlo recibi un mail de microchip comentandomelo y diciendome que si queria me los podian reemplazar/devolverme el dinero, pero como no usaba el ADC me dio igual...

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #4 en: 01 de Diciembre de 2014, 11:17:39 »
Sí, es muy desafortunado. Sin el cristal no puedo echar a volar el USB.

En la nueva versión de nuestra PCB tendremos que oscilar el cristal por fuera e inyectar los 24MHz en modo EC al PIC. Sólo así se puede proporcionar la señal de 24MHz al USB PLL.

También ayer me di varios topes con Harmony. El echar a andar la SD Card con SPI y DMA no es cosa fácil... al menos como principiante.  :(

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #5 en: 01 de Diciembre de 2014, 13:24:24 »
Lo han sacado en modo "prueba" o beta como algunos llaman, es logico ya que los usuarios son los que mas cuenta se dan de los bugs entonces les viene bien que los clientes les "echen una mano" es la moda ahora, los juegos tambien los sacan beta para que la gente lo vaya probando y vaya reportando los fallos, asi se ahorran bastante tiempo y dinero en probarlos ellos mismos...

De todas formas lo bueno que tiene microchip esq si dan problemas asi te cambian el MCU sin poner pegas, yo compre unos pics que segun microchip fallaban en el modulo ADC, sin saberlo recibi un mail de microchip comentandomelo y diciendome que si queria me los podian reemplazar/devolverme el dinero, pero como no usaba el ADC me dio igual...

Lo entiendo perfectamente. Si uno quiere probar rigurosamente las cosas no te queda otra que liberarlo a las masas y de tantas pruebas ver que no funciona, el software siempre ah sido asi.
Hasta la placa que compre de TI que deberia tener un TM4C1294NCPT , es XM4C1294NCPT, cuando mire decia que era experimental. pero hasta ahora no encontre ningun error, es decir no tuve ningun problema.

Y el tema pasa por que... es el oscilador, no es ni siquiera un perifierico como vos decis que fue el AD en tu caso. Si pones un micro y no arranca algo anda mal, creo que es lo MINIMO a probar. Pongan un programita que asigne salida y ponga a 1 todas las salidas asi como tambien leerlas, ADC tmb. SPI UART: al menos un envio/recepcion y luego liberarlo. En el tiempo de desarrollo de ese micro seguro que tuvieron tiempo en hacer el codigo.
Hay una fase de pruebas inicial para sacar los errores mas grandes y asi liberarlo para asi detectar los errores minisculos o que sucedan aleatoriamente y que no se discriminaron al comienzo. Sino el costo del envio de los integrados los asesina a Microchip o la compañia que sea si tuvieran que cambiar todos. Por que el oscilador es yo lo categorizaria como "Principal" para el funcionamiento de un integrado.


Igual mig
Con esa frecuencia, SPI DMA SD , un hermosos datalogger de USB High Speed :3

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #6 en: 01 de Diciembre de 2014, 13:58:12 »
Igual mig
Con esa frecuencia, SPI DMA SD , un hermosos datalogger de USB High Speed :3

¡Ojalá! Ahorita el rendimiento que tengo del micro es bajo, puedo hacer toggle de GPIOs a 1MHz. Ya tiene la caché ROM habilitada, pero faltan las optimizaciones PRO.

Quise instalar el modo de evaluación de XC32, desde web, desde consola y ningún método me funciona. Sin optimizaciones el micro es tan lento como sus hermanos menores PIC16/18.  :5]

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #7 en: 01 de Diciembre de 2014, 14:58:54 »
Igual yo dije eso pero no se mig, los perifericos trabajan tambien a esa frecuencia ?
O trabajan con Fosc / 4 como las versiones PIC16/18
O es solo el nucleo el que va a 200Mhz y los perifericos a mucha menor frecuencia ?

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #8 en: 01 de Diciembre de 2014, 15:51:07 »
Los periféricos se alimentan de unos relojes llamados Peripheral Bus Clock. Esos relojes pueden sacarse de varias fuentes, pero su máxima frecuencia tolerada es de 100MHz, o sea, la mitad de la frecuencia máxima del reloj del CPU.

El rendimiento de los PIC32 no es directo, no puedo decirte si 200MHz equivalen a 200MIPS. La equivalencia correcta son los Dhrystone MIPS.

https://en.wikipedia.org/wiki/Dhrystone

El micro corre a 200MHz, pero equivalen a 330DMIPS de acuerdo a Microchip... haciendo necesaria la optimización del compilador en PRO para llegar a tal rendimiento.

http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MZ1024ECG100

Dato curioso... los GPIOs necesitan reloj. El máximo que aceptan también es de 100MHz. No sé aún si es posible hacerlos oscilar tan rápido, sólo he visto en el foro de Microchip que lo han logrado a 20MHz... muy lejanos de mi 1MHz con la versión gratuita del compilador FREE.

Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.

http://ww1.microchip.com/downloads/en/DeviceDoc/60001183B.pdf
« Última modificación: 01 de Diciembre de 2014, 15:54:44 por migsantiago »

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #9 en: 01 de Diciembre de 2014, 16:33:35 »


¿ Alguien sabe porque al conectar un PIC32MZ2048ECH100 con MPLABX y Pickit3, me sale el estado del Pickit3 con 2 puntos amarillos ?, cuando uso un PIC32MX me salen los dos puntos verdes, me da la sensación de que el Pickit3 necesita una actualización de firmware para soportar los PIC32MZ, pero tampoco encuentro en MPLABX como actualizarlo.





He estado mirando en la configuración del proyecto, a ver la revisión del chip, por si está en la lista negra de PIC32MZ chapuceros, y no lo tengo claro. Cuando le doy para que pickit3 lea y recargue, me aparece el ID de dispositivo 5113053 correspondiente al PIC32MZ2048ECH100, pero en Device ID Revisión me pone 30000000 (como se ve en esta captura de pantalla), no tengo claro si es alguna de las revisiones A3, A4 o A5 de chips malos del PDF que ha colgado migsantiago.

Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.





Edito: en la ventana Output, pestaña Pickit3, si que me pone que es una revisión A3, pues vaya chufa, dinero tirado a la basura.


« Última modificación: 01 de Diciembre de 2014, 16:56:01 por planeta9999 »

Desconectado manwenwe

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 2211
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #10 en: 01 de Diciembre de 2014, 17:05:08 »
Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.
http://ww1.microchip.com/downloads/en/DeviceDoc/60001183B.pdf

Lo suyo sería poder ejecutar código desde RAM y no sé si se puede (creo que los cortex M4 sí lo hacen). A 330mips y con una memoria flash por PMP (aunque fuese lenta) y una sram o nor por QSPI sería ideal: no habría forma de "acabarse" el micro. De hecho no sé porque no se implementa ya QSPI en todos los micros: la lógica no es muy compleja y hasta cierta frecuencia no hay mucho problema con las señales single-ended a 3.3V (a 50Mhz se puede leer a 25MB/s que no está nada mal).

Saludos.  
Ojo por ojo y todo el mundo acabará ciego - Mahatma Gandhi -

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #11 en: 01 de Diciembre de 2014, 20:51:52 »
Dato curioso... los GPIOs necesitan reloj. El máximo que aceptan también es de 100MHz. No sé aún si es posible hacerlos oscilar tan rápido, sólo he visto en el foro de Microchip que lo han logrado a 20MHz... muy lejanos de mi 1MHz con la versión gratuita del compilador FREE.

Una de las razones por las que los 200MHz no son reales es que la Flash es más lenta que el reloj del CPU. Por eso hay que habilitar la caché de la ROM, que va pre-leyendo la Flash para tenerla lista para cuando el CPU la necesite.

Si los DMIPS para mi son una mentira. por que todo depende de la aplicacion. Estos tiene cache y gracias a eso algunos codigos son super rapido pero otros no e.e. Dependeria de tu compilador como mete las instrucciones a la cache.
Y con respecto a cambiar los valores de los puertos, no quedaria otra que ASM ? Si no se tiene mucha idea se podria debuggear y que muestre el ASM asociado al mismo, lo que si no se como lo tomara el compilador que le metas ASM.

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #12 en: 01 de Diciembre de 2014, 21:51:50 »
Lo suyo sería poder ejecutar código desde RAM y no sé si se puede (creo que los cortex M4 sí lo hacen). A 330mips y con una memoria flash por PMP (aunque fuese lenta) y una sram o nor por QSPI sería ideal: no habría forma de "acabarse" el micro. De hecho no sé porque no se implementa ya QSPI en todos los micros: la lógica no es muy compleja y hasta cierta frecuencia no hay mucho problema con las señales single-ended a 3.3V (a 50Mhz se puede leer a 25MB/s que no está nada mal).

Saludos.  

Una buena idea, hay micros de 16 bits con apenas 64kB en ROM que son capaces de correr desde RAM, no veo por qué éste no pueda. Es cosa de investigar.

Si los DMIPS para mi son una mentira. por que todo depende de la aplicacion. Estos tiene cache y gracias a eso algunos codigos son super rapido pero otros no e.e. Dependeria de tu compilador como mete las instrucciones a la cache.
Y con respecto a cambiar los valores de los puertos, no quedaria otra que ASM ? Si no se tiene mucha idea se podria debuggear y que muestre el ASM asociado al mismo, lo que si no se como lo tomara el compilador que le metas ASM.

Sí, sería bueno probar, pero prefiero conseguir la licencia de evaluación para agilizar el trabajo. Imagínate terminar todo el proyecto en ASM... jejej

Desconectado migsantiago

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8257
    • Sitio de MigSantiago
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #13 en: 01 de Diciembre de 2014, 21:53:38 »
Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.

Hola, yo pienso inyectar la salida dividida de 200MHz, siendo de 24MHz, del FRCPLL hacia el POSC, configurado como EC. No me importa mucho la precisión de la señal... por el momento es una prueba y así sí podría usar el USBPLL. Hay que ver qué pasa. :S

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re: PIC32MZ - Estrenando micro y bugs en el silicio/compilador
« Respuesta #14 en: 02 de Diciembre de 2014, 11:18:24 »
Si es de los malos lo usaré para chapucear, y ya compraré otro cuando este en condiciones, que no se si a fecha de hoy ya están disponibles con todas esas cagadas arregladas (¿ alguien lo sabe ?), lo que si necesito seguro es que pueda funcionar con el cuarzo.

Hola, yo pienso inyectar la salida dividida de 200MHz, siendo de 24MHz, del FRCPLL hacia el POSC, configurado como EC. No me importa mucho la precisión de la señal... por el momento es una prueba y así sí podría usar el USBPLL. Hay que ver qué pasa. :S


En los datasheet de los PIC32MX, Microchip recomienda usar el cuarzo para USB, yo nunca lo he probado con el oscilador interno y USB, no se si funcionará. En este caso el A3 que tengo lo usaré para experimentos, pero no lo voy a instalar en un producto final, menudo castaña nos han vendido.

Lo que no se es como está ahora la cosa, ¿ ya podemos comprar un PIC32MZ en condiciones, o siguen sirviendo los, A3, A4 y A5, plagados de problemas ?, ya no se puede uno fiar, porque los proveedores pueden tener en stock todas estas versiones malas hasta que agoten el producto, no hay manera de saberlo hasta que lo conectamos y leemos la versión, es como jugar a la lotería.