Freescale Kinetis KE - escribiendo en flash

He estado utilizando varios microcontroladores y microprocesadores durante muchos, muchos años, pero parece que la serie Kinetis KE (específicamente el S9KEAZN64AMLC) me obstaculiza.

17 de enero de 2015 TL; DR:

Freescale confirma que la versión 2.0.0 de su software Kinetis Design Studio no funciona con este dispositivo (incluida su propia placa de evaluación TRK-KEA64). Recomiendan usar CodeWarrior MCU V10.6 por el momento.

Segger ha lanzado v4.96a (la "a" es importante, estaba usando v4.96) que corrige el problema y le permite utilizar una placa de depuración Segger J-Link Lite CortexM con KDS y tener la capacidad completa de depuración / programa.

Antes de que Segger lanzara v4.96a logré flashear el chip reprogramando el depurador OpenSDA en la económica placa de evaluación FRDM-KL25Z de Freescale ($ 15) al actualizar el firmware OpenSDA que viene con USBDM (usando v4.10.6.240). Luego utilicé el software independiente "ARM Programmer" de USBDM. No pasé mucho tiempo intentando que la depuración funcionara, ya que soy lo suficientemente competente en la depuración de la "vieja escuela" como para no necesitarla. Asegúrese de mostrar un programa "benigno" en el KL25 objetivo de a bordo o puede interferir con la programación ya que la línea de reinicio del KL25 objetivo de la placa todavía está conectada al depurador OpenSDA incluso con el corte J11 (vea la publicación del blog de Keith Wakeham , vinculado a continuación).

Muchas gracias a Erich Styger por ayudarme muy gentilmente a determinar el problema y confirmar mis hallazgos por correo electrónico.

Ahora volvamos a nuestra pregunta programada regularmente:

He construido una placa de conexión de 3.3V estúpidamente simple. Tiene algunos LED en PTA, una conexión UART en PTC y las líneas SWD están en sus líneas dedicadas. Literalmente, no hay nada lujoso o divertido en este tablero.

Estoy usando un J-Link Lite para Cortex-M (J-Link LITE CortexM-9, consulte https://www.segger.com/jlink-lite-cortexm.html ) y bajo OSX y Windows obtengo el mismo resultado: la utilidad J-Link Commander puede identificar el chip, puedo leer y escribir en SRAM y jugar con los periféricos con lecturas y escrituras manuales en la dirección de E / S correlacionada con la memoria correcta. Sin embargo, cuando intento flashear el dispositivo, falla.

$ JLinkExe
SEGGER J-Link Commander V4.94c ('?' for help)
Compiled Oct 31 2014 20:08:55
DLL version V4.94c, compiled Oct 31 2014 20:08:48
Firmware: J-Link Lite-Cortex-M V8 compiled Jul 17 2014 11:40:12
Hardware: V8.00
S/N: 518107921
Feature(s): GDB
VTarget = 3.332V
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots
Cortex-M0 identified.
Target interface speed: 100 kHz

J-Link>device skeazn64xxx2
Info: Device "SKEAZN64XXX2" selected (64 KB flash, 4 KB RAM).
Reconnecting to target...
Info: Found SWD-DP with ID 0x0BC11477
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>erase
Erasing device (SKEAZN64xxx2)...

(...several second pause while it communicates with the MCU...)



****** Error: PC of target system has unexpected value after erasing sector. (PC = 0xFFFFFFFE)!
---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
    PC   = FFFFFFFE
Current: R0   = 00F3E3BE, R1   = 00000001, R2   = 4004801C, R3   = 00000001
    R4   = 00000000, R5   = 00000000, R6   = 000000F4, R7   = 1FFFFD61
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Info: J-Link: Flash download: Total time needed: 2.174s (Prepare: 0.894s, Compare: 0.000s, Erase: 0.736s, Program: 0.000s, Verify: 0.000s, Restore: 0.542s)
ERROR: Erase returned with error code -5.

El J-Link Lite está perfectamente bien (puedo leer y escribir en el nRF58122 SoC, otro procesador Cortex-M0, con él) y el dispositivo parece funcionar de otra manera. Sé que el Kinetis está desbloqueado ya que son existencias frescas de fábrica de DigiKey, pero incluso entonces el comando "desbloqueo de kinetis" en JLinkExe agota el tiempo de espera sin ningún error o información útil.

En este momento estoy seguro de que estoy haciendo algo estúpido, pero no sé qué podría ser.

¿Alguien ha trabajado con estos dispositivos antes? ¿Cómo los estás programando?

editar para agregar tutorial:

Más información:

Leí que el pin NMI # está habilitado para restablecer (y verifiqué esto leyendo SIM_SOPT) pero también que tiene un pull-up interno cuando está habilitado. En esta parte en particular, PTB4 está en el pin 10, que es un no conectado en mi diseño. Deshabilitar el pin NMI no hace ninguna diferencia. RST # es similar; Está conectado a un botón que conecta el pin y también va al J-Link Lite, pero no hay pullup externo. Esto no debería importar porque, al igual que NMI #, el pin RST # tiene un pullup interno que se habilita cuando PTA5 se configura para reiniciarse.

Mirando el reloj ahora ... Sin reinicio, ICS es la fuente del reloj para el FLL y BDIV en ICS_C2 está configurado en 001 (el reinicio predeterminado). Si entiendo correctamente, esto significa que el oscilador interno de 32kHz se multiplica por 1024 por el FLL y luego se divide por 2, lo que hace que ICSOUTCLK sea de 32kHz * 1024/2 o 16.8MHz. Puedo verificar a través de la CLI de J-Link que el FLL está bloqueado leyendo ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK e IREFST están configurados, esto es correcto).

Luego paso para verificar que la SIM tiene el reloj habilitado para el controlador de flash leyendo SIM_SCGC. También puedo verificar rápidamente para asegurarme de que BUSDIV en SIM_BUSDIV esté establecido en cero, lo que significa que BUSCLK tiene la misma frecuencia que ICSOUTCLK (es decir, no se divide):

J-Link>mem32 4004800c 1
4004800C = 00003000
J-Link>mem32 40048018 1
40048018 = 00000000

Hasta ahora, todo se ve bien. BUSCLK es 16.8MHz y el reloj del controlador de flash no está cerrado.

Ahora pasemos al controlador de flash. Sin restablecer FCLKDIV es cero, y necesitamos un reloj de 1MHz. La Tabla 18-2 en KEA64RM muestra que FDIV debe establecerse en 0x10.

Fuera de reinicio:

J-Link>mem8 40020000 1
40020000 = 00

Configurar el divisor y verificar las cosas es bueno:

J-Link>w1 40020000 10
Writing 10 -> 40020000
J-Link>mem8 40020000 1
40020000 = 90

Se establece FDIVLD y se muestra el valor correcto en FDIV.

Antes de avanzar demasiado, asegurémonos de que el flash no esté protegido:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (deshabilitado) y SEC = 10 (no seguro). Okay. Intentemos verificar que el dispositivo esté en blanco:

J-Link>mem8 40020006 1
40020006 = 80
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>mem8 40020006
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 83

Aquí vemos que los bits MGSTAT en FSTAT indican que la verificación en blanco ha fallado y también que se encontraron errores no corregibles. Impar. Intentemos borrarlo nosotros mismos:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 8
Writing 08 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

El comando borrar todo tuvo éxito. Ahora intentemos un cheque en blanco:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

¿Ahora el cheque en blanco está bien?

En este punto, estoy a punto de rendirme, comer la pérdida de estos prototipos e ir con un procesador de ST donde nunca he tenido este tipo de problemas antes. La documentación de Kinetis es lo suficientemente completa, pero es muy densa y me resulta muy difícil comenzar. Puedo mover las E / S a través de las lecturas de memoria y acceder a otros periféricos, pero no puedo entender por mi vida qué le pasa al controlador de flash. He estado trabajando con micros durante más de 20 años y este tipo de dificultad es algo que nunca antes había encontrado.

20150102 editar:

Así que todavía no vayas aquí. De hecho, compré una placa de evaluación FRDM-KL25Z ($ 15 de DigiKey) y la modifiqué colocando el software genérico CMSIS-DAP en el depurador OpenSDA y cortando J11 según el blog de Keith Wakeham . Tengo el objetivo a bordo (el KL25Z) ejecutando un programa simple para que no interfiera con la línea de reinicio y puedo ver mi SKEAZN64 con OpenOCD y jugar con él, pero desafortunadamente tampoco puede programarlo. El software Kinetis Design Studio (KDS) no mostrará mi Kinetis porque dice que está protegido y que necesito borrarlo en masa, pero OpenOCD (como parte de KDS) no parece saber cómo hacerlo. La versión maestra git de OpenOCD que construí en mi Mac comprende Kinetis, pero no la serie KEA específica, así que vuelvo al punto de partida.

Volviendo al J-Link ...

@AdamHaun tenía una muy buena pista, y si configuro el tipo de reinicio de J-Link (comando rsettype) para escribir '6' (Kinetis), se supone que J-Link deshabilitará el perro guardián después de reiniciar el núcleo. Mirando el registro WDOG_CS1 (0x40052000) parece que ese es el caso, pero aún no hay dados. Una operación de borrado parece salirse de los rieles con la PC en 0xfffffffe y el código de error -5, y un comando "desbloquear kinetis" solo funciona si desactivo el pin de restablecimiento usando SIM_SOPT (escribiendo el valor de 32 bits 0x00000008 a 0x40048004). Desafortunadamente, si hago eso, la CPU no puede detenerse nunca más, presumiblemente porque la interfaz SWD no puede usar la línea de reinicio para forzar el SWD DAP a un estado conocido.

20150103 editar:

HE PARPADEADO LED

REPETIR

HE PARPADEADO LED

Versión TL; DR: coloque la imagen USBDM en la placa FRDM-KL25Z (una historia por sí sola), use la aplicación independiente ARM Programmer para enviar la prueba .elf a la placa. Ciclo de potencia y voilà.

La versión larga vendrá más tarde. Ahora tengo menos de 48h para escribir y depurar software para esta placa KEAZN64, terminar de modificar / probar otro software que lo acompaña y trabajar en alguna documentación para otro cliente. Prometo que voy a actualizar esta pregunta con una respuesta detallada. Solo quería compartir mi éxito. Gracias a TODOS por su ayuda. Puede que tenga que hablar con los mods porque realmente me gustaría dar la recompensa a un par de ustedes en particular.

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

• También hay un registro FTMRH_FERSTAT (a 4002_0007h). Se supone que te dirá 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 el 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 de vector 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 borrado manualmente a nivel de sector, así que intente manualmente (como al escribir el registro apropiado usted mismo) emitir 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 "desprotegerá" el dispositivo y hará un flash completo y borrará EEPROM. Puede sondear un bit FSTAT (CCIF) para ver cuándo supuestamente se ha completado 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. Estoy sugiriendo esto porque había un hilo en el foro de Freescale donde un flash externo funcionaba bien, pero no por encima de una frecuencia determinada que todavía estaba en el rango bien documentado. Por lo tanto, es posible que el controlador de flash en el chip sea inestable y no pueda funcionar en el rango completo de frecuencias establecidas.

• Del mismo modo, eres un chip diferente. No es inconcebible que, dado el costo de estos (alrededor de $ 3), tenga uno malo. Recuerdo tener un chip x86 incrustado que funcionó bien en la mayoría de los casos, pero tenía errores extraños en ciertas instrucciones de modo protegido; mi problema desapareció con un dispositivo diferente de la misma marca. No está claro para mí si Freescale tiene (públicamente) pasos y erratas 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 edición (s):

(Material movido aquí de mis comentarios y expandido)

Parece que no todas las series Kinetis se prueban (oficialmente, al menos) con todas las luces intermitentes. La serie EA bastante nueva que está utilizando realmente parece ser oficialmente compatible solo con el flasheador Cyclone MAX de Freescale / OEM; Es el único listado en la página de Freescale para los servidores EA . Ahora concedido, para Kinetis mayores 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 flashes para la serie EA o si hay alguna peculiaridad de programación involucrada que solo su Cyclone MAX conoce actualmente. Esperaba que tal vez esto sea solo que Freescale tarda en enumerar otros flashes, pero al consultar el manual de J-link (ojalá sea el correcto), no hay ninguna serie Kinetis E o EA listadas allí (p. 249) como las probadas tampoco, 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 20/3/2014, que "agrega soporte para MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 y SKEAZ128 derivados". Otra pista es que el propio software de cargador de arranque / flashloader de código abierto de Freescale para Kinetis, a pesar de haberse actualizado aún más recientemente en 12/2014, no enumera ningún dispositivo de la serie [sub] E o EA como compatible. Así que creo que hay algo suficientemente diferente con respecto al flasheo 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 flasheo de EA funcione automáticamente con cualquier cosa que no sea el Cyclone MAX probablemente no sea realista en este momento. Es posible que eventualmente pueda descubrir cómo hacerlo a nivel "básico" (comandos de registro directo) a partir 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, ya que es solo un manual de referencia. Si el cargador de arranque / flashloader de código abierto de Freescale admitiera la serie E / EA, usted '

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 flash (OpenSDA en este caso).

Y si usted es como Keith (el blogger) que "piensa que $ 100 dólares para un programador es ridículo", probablemente no estará satisfecho con la perspectiva de dejar caer más de $ 900 en ese Ciclón. No sé si Freescale hace esto a propósito para engañar 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 (piratear) más placas, una con un 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 pirateable. Por lo que puedo decir, no fabrican / venden tableros con la serie EA. 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 es que den el código fuente como código abierto; así que ni siquiera puedo encontrar el código fuente para programar un flash de la serie E. Aparentemente, solo estoy medio en lo cierto al respecto. OpenSDA v1 no es de código abierto, pero v2 sí .

Así que aquí está la información sobre OpenSDAv2 . Básicamente es solo un gestor de arranque y flasheador CMSIS-DAP / mbed. Por lo tanto, es posible que no tenga las mismas características o que no sea compatible con los mismos chips que v1 ... y ese es el caso porque flash_features.h no enumera 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 flasheo Cyclone de $ 900 o buena suerte escribiendo el suyo de cualquier parte incompleta de código abierto que hayamos lanzado.

Sin embargo, resulta que hay un proyecto de código abierto que puede programar al menos la serie E Kinetis, 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 (error al programar excepto después de borrado en masa)

Y en base a 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 quiere hackear su propio flasheador; o quizás 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 utilizan diferentes luces intermitentes (bases de código) para diferentes dispositivos de la serie MKE: se usa algo llamado "FTMRE" para MKE04 y MKE06, pero "FTMRH" se usa para MKE02. Después de mirarme brevemente a las dos bases de código, seguramente querrá la base de código FTRMH, no la FTRME. Este último tiene una estructura FTMRH diferente que su dispositivo SKEA64, por ejemplo, el divisor de reloj no es el primero sino el cuarto campo. FTRME también establece el FIDV del bus en 0x17 = 24Mhz, que parece estar fuera del rango de su chip (p. 224 en el manual de KEA64 sugiere un máximo de 20Mhz). FTMRH lo establece en 0x0F = 16Mhz (como usted), lo que parece estar bien.

En este punto, (a menos que quiera comprar el Cyclone MAX) su mejor opción es contactar a Podonoghue para que su chip funcione con su código base. Parece activo y bastante dispuesto a ayudar con nuevos dispositivos (en el foro de escala libre) .

También a partir de ese código fuente de USDBM, puedo profetizar que no hay forma de que su SEGGER pueda flashear correctamente su SKEA por sí mismo a menos que primero obtenga su propia actualización de firmware. ¿Por qué digo eso? Debido a que la base de código FTMRH de USDBM es utilizada exactamente por un dispositivo allí, el MKE02, del cual su SEGGER parece no saber nada tampoco (según su manual). Otros dispositivos más comunes, como las series Kinetis L y K, usan 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" forma para que Freescale haga dispositivos incompatibles ... pero una bendición para los fabricantes de flashes, sin duda.

¿Intentó 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 esto, existe la utilidad J-Link Commander que tiene una interfaz de línea de comandos para desproteger y borrar el dispositivo. Solo para borrar, el J-Flash (y Lite) es una herramienta muy útil, especialmente para obtener una memoria de dispositivo 'limpia'.

Lo que me pareció interesante es que debes 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 hacerlo permanente. Para borrar el dispositivo, puedo usar la misma utilidad de línea de comandos. Pero primero necesito especificar el nombre del dispositivo, y luego puedo borrarlo (ejemplo para el KL25Z):

EDITAR1: se agregaron datos incorrectos.

EDIT2: ¿tal vez puedas leer el registro de Flash Security (FSEC)? ¿Has probado?

EDIT3: del uso de las características de seguridad y protección contra flash de Kinetis, Rev. 1, 6/2012

El borrado masivo a través de Debugger / JTAG Debuggers y las herramientas JTAG tienen un acceso muy limitado al dispositivo cuando un procesador está asegurado. 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 no aseguren partes, el bit 0 del registro de control MDM-AP se puede configurar para solicitar un borrado masivo del procesador. Para utilizar este método para desactivar la seguridad, FSEC [MEEN] debe establecerse en un valor distinto de 10 para permitir la capacidad de borrado en masa. Si el borrado en masa está desactivado, FSEC [MEEN] = 10, entonces la solicitud de borrado en masa será ignorada por el flash y el dispositivo no puede ser desprotegido usando este método. Muchos depuradores usarán automáticamente el bit 2 del registro de estado de MDM-AP para determinar si un dispositivo está protegido cuando intenta establecer una conexión. Se puede usar una ventana emergente del depurador para alertar que el dispositivo está asegurado y preguntar si se desea un borrado en masa para desproteger el dispositivo. Una vez que se haya completado y verificado el borrado masivo, se deshabilitará la seguridad. Algunos depuradores pueden programar automáticamente el campo de configuración de flash para poner el flash en un estado no seguro después de que se complete el borrado en masa, FSEC = 0xFE.

También me topé con una publicación que menciona que diferentes familias de kinetis requieren diferentes manipulaciones de señal RESET cuando intento leer / escribir el registro MDM-AP.

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

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

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

Todavía no lo he visto mencionado, así que seguiré adelante y especularé que el problema es que esta parte tiene un caché que está habilitado en el reinicio. Esto es consistente con el comportamiento "extraño" que observó con el cheque en blanco. Se actualizó el Flash subyacente pero no la memoria caché. Para solucionar esto, apague la memoria caché de datos e instrucciones escribiendo en MCM_PLACRat F000_300Chy también borre la memoria caché mientras lo hace. Es probable que este mismo comportamiento extraño también haya confundido al Segger.

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 deshabilitar el temporizador de vigilancia?