Freescale Kinetis KE: escritura en flash

En realidad, no puedo encontrar ningún error lógico en su procedimiento, pero aquí hay algunas sugerencias:

• también hay un registro FTMRH_FERSTAT (en 4002_0007h). Se supone que debe decirle qué salió mal... pero solo en el caso de paridad (o errores de doble paridad). No estoy convencido de que esto registre nada en caso de que borre errores, pero probablemente valga la pena echarle un vistazo.

• la documentación de KEA también menciona que una interrupción puede ser provocada por errores de flash (sección "18.3.5 Interrupciones de flash y EEPROM"). No sé si eso es lo que sucede cuando SEGGER lo borra, pero es una explicación plausible de por qué la PC también cambia, ya que vio errores marcados en el registro FSTAT. Desafortunadamente, la sección de documentación de KEA para el controlador de interrupción ("3.3.2 Configuración del controlador de interrupción vectorial anidado (NVIC)") apunta vagamente en la dirección del sitio web de ARM para obtener la documentación completa. No pude averiguar si hay un controlador de interrupción predeterminado configurado (en el arranque) para errores de flash.

• Solo ha realizado borrados a nivel de sector de forma manual, así que intente hacerlo manualmente (escribiendo usted mismo el registro correspondiente) emitiendo un comando de borrado de flash completo; la única forma de hacer esto en un solo comando parece ser el "Comando flash no seguro" documentado en la sección 18.3.9.10 (p. 246) del manual. Esto "desprotegirá" el dispositivo y hará un flash completo y un borrado de EEPROM. Puede sondear un bit FSTAT (CCIF) para ver cuándo supuestamente se completó y verificar los indicadores de error nuevamente después. EDITAR: también hay una sección "18.3.9.7 Comando Borrar todos los bloques" en el manual, duh.

• pruebe con una frecuencia de reloj de bus más baja. Cualquier cosa por encima de 0,8 Mhz funciona de acuerdo con la documentación. Sugiero esto porque hubo un hilo en el foro de Freescale donde un flash externo funcionó bien, pero no por encima de cierta frecuencia que todavía estaba en el rango bien documentado. Por lo tanto, es posible que el controlador de flash en el chip sea defectuoso y no pueda operar en el rango completo de frecuencias indicadas.

• Del mismo modo, tu chip es diferente. No es inconcebible que dado lo mucho que cuestan (alrededor de $3) tengas uno malo. Sí recuerdo tener un chip x86 incorporado que funcionaba bien en la mayoría de los casos, pero tenía errores extraños en ciertas instrucciones del modo protegido; mi problema desapareció con un dispositivo diferente de la misma marca. No me queda claro si Freescale tiene pasos y erratas (declarados públicamente) para estos dispositivos o no.

Esto es todo lo que puedo pensar en términos de sugerencias de depuración que otros no dijeron en esta página.

20150103 ediciones:

(Material movido aquí de mis comentarios y ampliado)

Parece que no todas las series Kinetis se prueban (oficialmente, al menos) con todas las luces intermitentes. La serie bastante nueva de EA que en realidad está utilizando parece ser compatible oficialmente solo con el propio flasher Cyclone MAX de Freescale/OEM; es el único que aparece en la página de Freescale para la serie EA . Ahora concedido, para Kinetis más antiguos como KL0, la lista es mucho más larga, incluido un SEGGER . No sé si eso se debe simplemente a la falta de pruebas de otros intermitentes para la serie EA o si en realidad hay alguna peculiaridad de programación involucrada que solo su Cyclone MAX conoce actualmente. Tenía la esperanza de que tal vez esto sea solo que Freescale está tardando en enumerar otros intermitentes, pero al consultar el manual de J-link(con suerte, el correcto), no hay ninguna serie Kinetis E o EA listada allí (p. 249) como probada, sino solo dispositivos Kinetis K10 a K60 (y algunos MAC7 más antiguos).

Vale la pena señalar que el software/firmware PExDrv para el Cyclone MAX tiene un paquete de servicio (v10.3) con fecha del 20/03/2014, que "agrega soporte para los derivados MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 y SKEAZ128". Otra pista es que el propio software de cargador de arranque/cargador flash de código abierto de Freescale para Kinetis, a pesar de haberse actualizado incluso más recientemente en 12/2014, no incluye ningún dispositivo de la [sub]serie E o EA como compatible. Así que creo que hay algo lo suficientemente diferente con respecto al parpadeo entre la serie E/EA y otros Kinetis como el K10, aunque no tengo idea de cuál es exactamente esa diferencia. Por lo tanto, creo que esperar que el parpadeo de EA funcione automáticamente con cualquier cosa que no sea Cyclone MAX es probablemente poco realista en este momento. Es posible que eventualmente pueda descubrir cómo hacerlo en el nivel "bare metal" (comandos de registro directo) de la documentación de la serie EA, pero estoy de acuerdo en que la documentación es bastante obtusa; ciertamente carece de instrucciones paso a paso siendo solo un manual de referencia. Si el cargador de arranque/cargador flash de código abierto de Freescale fuera compatible con la serie E/EA,

Su experimento con el FRDM-KL25Z (que viene con una serie Kinetis L) apunta en la misma dirección, es decir, no puede intercambiar una serie L con una serie EA y usar el mismo flasher (OpenSDA en este caso).

Y si usted es como Keith (el bloguero) que "piensa que $100 dólares por un programador es ridículo", probablemente no estará satisfecho con la perspectiva de gastar más de $900 en ese Cyclone. No sé si Freescale hace esto a propósito para desplumar a sus clientes automotrices o qué... Seguramente parece extraño que las herramientas para la mayoría de la serie Kinetis no funcionen con el E/EA.

También tenga en cuenta que la función de flasheo de OpenSDA solo funciona bajo MS Windows , aparentemente.

Si está dispuesto a probar (hackear) más placas, una con Kinetis de la serie E podría ser una mejor idea, por ejemplo, FRDM-KE02Z ($13 en Digi-Key); también usa OpenSDA por lo que podría ser hackeable. No fabrican ni venden placas con la serie EA, por lo que sé. Sin embargo, parece que no puede usar un procesador/placa OpenSDA para programar un tipo de Kinetis diferente al de su propia placa , incluso si ambos procesadores están en la misma serie (por ejemplo, L), pero con números diferentes. Desafortunadamente, "Abrir" en OpenSDA solo significa que la especificación SDA está abierta, no que proporcionen el código fuente como fuente abierta; así que ni siquiera puedo encontrar el código fuente para programar un flash de la serie E. Aparentemente, solo tengo la mitad de razón en eso. OpenSDA v1 no es de código abierto, pero v2 es .

Así que aquí está la verdad sobre OpenSDAv2 . Básicamente es solo un cargador de arranque y flasher CMSIS-DAP/mbed. Por lo tanto, es posible que no tenga las mismas características ni admita los mismos chips que v1... y ese es el caso porque flash_features.h no incluye ningún MKE (Kinetis E-series) y mucho menos SKE (EA-series) dispositivos. En resumen, la propuesta de Freescale para la serie EA parece ser: compre nuestro Cyclone flasher de $900 o buena suerte escribiendo el suyo propio a partir de cualquier fragmento incompleto de código abierto que hayamos lanzado.

Sin embargo, resulta que hay un proyecto de código abierto que puede programar al menos el Kinetis de la serie E, a saber, USBDM . El bit relevante de su registro de cambios es:

V4.1.6.140 (abril de 2014)

Dispositivos Kinetis adicionales (MKE04, MKE06, MK64F)

• Correcciones para dispositivos MKE (no se pudo programar excepto después de Mass Erase)

Y según esa entrada de registro, seguramente parece que la serie E es peculiar. No hay soporte directo para la serie EA (SKE), pero esa base de código es probablemente su mejor opción si desea piratear su propio flasher; o tal vez pueda convencer al autor de USBDM para que agregue compatibilidad con la serie EA (SKE). Como hardware para USBDM resulta que puedes usar el FRDM-KL25Z que ya has adquirido; pero aún debe piratear el software USBDM para admitir los chips SKE.

El archivo de configuración maestro para USBDM parece bastante desalentador. En USDBM, se usan diferentes flashes (bases de código) para diferentes dispositivos de la serie MKE: se usa algo llamado "FTMRE" para MKE04 y MKE06, pero se usa "FTMRH" para MKE02. Después de mirarme brevemente las dos bases de código, es casi seguro que desee la base de código FTRMH, no la FTRME. Este último tiene una estructura FTMRH diferente a la de su dispositivo SKEA64, por ejemplo, el divisor de reloj no es el primero sino el cuarto campo. FTRME también configura el bus FIDV a 0x17 = 24Mhz, lo que parece estar fuera de rango para su chip (la página 224 en el manual de KEA64 sugiere un máximo de 20Mhz). FTMRH lo establece en 0x0F = 16Mhz (como lo haces tú), lo que parece estar bien.

En este punto, (a menos que quiera comprar el Cyclone MAX), lo mejor que puede hacer es ponerse en contacto con Podonoghue para que su chip funcione con su base de código. Parece activo y bastante dispuesto a ayudar con nuevos dispositivos (en el foro de freescale) .

También a partir de ese código fuente de USDBM puedo profetizar que no hay forma de que su SEGGER pueda actualizar correctamente su SKEA por sí mismo a menos que obtenga su propia actualización de firmware primero. ¿Por qué digo eso? Porque la base de código FTMRH de USDBM es utilizada exactamente por un dispositivo allí, el MKE02, del cual su SEGGER tampoco parece saber nada (según su manual). Otros dispositivos más comunes, como las series Kinetis L y K, utilizan un flasher USDBM diferente basado en una base de código "FTFA". Si observa el código de FTFA , la estructura de registro del controlador flash (que también comienza en 0x40020000) es diferente para estos; el primer campo ni siquiera es un divisor de reloj, sino el registro de estadísticas, etc. "Excelente" manera para que Freescale haga dispositivos incompatibles... pero una gran ayuda para los fabricantes de luces intermitentes, sin duda.

Probaste esto: Desbloqueo y borrado de FLASH con Segger J-Link

Supuestamente tienes que:

Para reprogramar los sectores FLASH protegidos con Segger J-Link, primero necesito desbloquear y borrar en masa el dispositivo. Para ello, existe la utilidad J-Link Commander que cuenta con una interfaz de línea de comandos para desproteger y borrar el dispositivo. Solo para borrar, J-Flash (y Lite) es una herramienta muy útil, especialmente para obtener una memoria 'limpia' del dispositivo.

Lo que me pareció interesante es que tienes que desbloquearlo y borrarlo en el siguiente paso si quieres que el desbloqueo sea permanente:

Pero parece que necesito hacer un desbloqueo, seguido de un borrado para que sea permanente. Para borrar el dispositivo, puedo usar la misma utilidad de línea de comando. Pero primero necesito especificar el nombre del dispositivo y luego puedo borrarlo (ejemplo para el KL25Z):

EDIT1: se agregaron datos incorrectos.

EDIT2: ¿puede leer el registro de Flash Security (FSEC)? ¿Has probado?

EDIT3: de Uso de las funciones de seguridad y protección flash de Kinetis, Rev. 1, 6/2012

Borrado masivo a través de Debugger/JTAG Los depuradores y las herramientas JTAG tienen un acceso muy limitado al dispositivo cuando un procesador está protegido. Los únicos registros a los que se puede acceder a través de JTAG son los registros de estado y control de MDM-AP. Para permitir que las herramientas de depuración desprotejan partes, el bit 0 del registro de control de MDM-AP se puede configurar para solicitar un borrado masivo del procesador. Para usar este método para deshabilitar la seguridad, FSEC[MEEN] debe establecerse en un valor distinto de 10 para permitir la capacidad de borrado masivo. Si el borrado masivo está deshabilitado, FSEC[MEEN] = 10, la memoria flash ignorará la solicitud de borrado masivo y el dispositivo no se podrá desproteger con este método. Muchos depuradores utilizarán automáticamente el bit 2 del registro de estado de MDM-AP para determinar si un dispositivo está protegido al intentar establecer una conexión. Se puede utilizar una ventana emergente del depurador para alertar de que el dispositivo está protegido y preguntar si se desea un borrado masivo para desproteger el dispositivo. Una vez que se complete y verifique el borrado masivo, se desactivará la seguridad. Algunos depuradores pueden programar automáticamente el campo de configuración flash para poner el flash en un estado no seguro después de que se complete el borrado masivo, FSEC = 0xFE.

También me topé con publicaciones que mencionan que diferentes familias de kinetis requieren diferentes manipulaciones de señal RESET al intentar leer/escribir el registro MDM-AP.

EDIT4: ¿intentaste agregar un pull-up fuerte en SWD_DIO? Es un tiro en la oscuridad, pero Freescale lo recomienda.

Primero debe detener el procesador. Es obvio que obtiene un síntoma de un procesador en ejecución. Yo uso openocd; antes de flashear el dispositivo, uso el comando "restablecer detener". Ese "detener" es un subcomando de "restablecer", para detenerse inmediatamente después del reinicio, mientras que también hay un comando de detención independiente.

Así que busque un comando de "restablecer detención", solo una detención no será suficiente porque supongo que debe llegar al estado de preinicialización de vectores.

Todavía no lo he visto mencionado, así que seguiré adelante y especularé que el problema es que esta parte tiene un caché que se habilita al reiniciar. Esto es consistente con el comportamiento "extraño" que observaste con el cheque en blanco. El Flash subyacente se actualizó pero la memoria caché no. Para arreglar esto, apague tanto el caché de datos como el de instrucciones escribiendo MCM_PLACRen F000_300Chy también borre el caché mientras lo hace. Es probable que este mismo comportamiento extraño haya confundido al Segger también.

Dado que el mensaje de error es sobre el valor de la PC, parece que la CPU se está descarrilando en alguna parte. Esta es una posibilidad remota, pero ¿ha intentado desactivar el temporizador de vigilancia?