Freescale Kinetis KE - escrevendo para flash

Eu uso vários microcontroladores e microprocessadores há muitos e muitos anos, mas pareço estar frustrado pela série Kinetis KE (especificamente o S9KEAZN64AMLC).

17 de janeiro de 2015 TL; DR:

A Freescale confirma que a versão 2.0 do seu software Kinetis Design Studio não funciona com este dispositivo (incluindo sua própria placa de avaliação TRK-KEA64). Eles recomendam o uso do CodeWarrior MCU V10.6 por enquanto.

A Segger lançou a v4.96a (o "a" é importante, eu estava usando a v4.96), que corrige o problema e permite que você use uma placa de depurador Segger J-Link Lite CortexM com o KDS e tenha recursos completos de programa / depuração.

Antes de a Segger lançar a v4.96a, consegui atualizar o chip reprogramando o depurador OpenSDA na placa de avaliação barata FRDM-KL25Z da Freescale (US $ 15) ao atualizar o firmware do OpenSDA que acompanha o USBDM (usando a v4.10.6.240). Eu então usei o software "ARM Programmer" autônomo do USBDM. Não gastei muito tempo tentando fazer a depuração funcionar, pois sou proficiente o suficiente na depuração "oldschool" para não precisar dela. Certifique-se de exibir um programa "benigno" no alvo KL25 de bordo ou ele pode interferir na programação, pois a linha de redefinição do KL25 do alvo de bordo ainda está conectada ao depurador OpenSDA, mesmo com o corte J11 (consulte a publicação do blog de Keith Wakeham , link abaixo).

Um grande obrigado a Erich Styger por me ajudar muito graciosamente a determinar o problema e confirmar minhas descobertas por e-mail.

Agora, de volta à nossa pergunta programada regularmente:

Eu construí uma placa estúpida e simples de 3.3V. Possui alguns LEDs no PTA, uma conexão UART no PTC e as linhas SWD estão em suas linhas dedicadas. Não há literalmente nada extravagante ou engraçado neste fórum.

Estou usando um J-Link Lite para Cortex-M (J-Link LITE CortexM-9, consulte https://www.segger.com/jlink-lite-cortexm.html ) e, tanto no OSX quanto no Windows, recebo o mesmo resultado: o utilitário J-Link Commander pode identificar o chip, eu posso ler e gravar na SRAM e brincar com os periféricos com leituras e gravações manuais no endereço de E / S mapeado na memória correto. Porém, quando tento piscar o dispositivo, ele falha.

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

O J-Link Lite está perfeitamente bem (eu posso ler e gravar no nRF58122 SoC, outro processador Cortex-M0, com ele) e o dispositivo parece funcionar de outra maneira. Sei que o Kinetis está desbloqueado, pois são novos produtos de fábrica da DigiKey, mas mesmo assim o comando "kinetis unlock" no JLinkExe atinge o tempo limite sem nenhum erro ou informações úteis.

Neste momento, tenho certeza de que estou fazendo algo estúpido, mas estou perdido para o que poderia ser.

Alguém já trabalhou com esses dispositivos antes? Como você os está programando?

edite para adicionar explicação passo a passo:

Mais algumas informações:

Eu li que o pino NMI # está habilitado fora de redefinição (e verifiquei isso lendo SIM_SOPT), mas também que ele possui um pull-up interno quando ativado. Nesta parte em particular, o PTB4 está no pino 10, que não é de conexão no meu projeto. Desabilitar o pino da NMI não faz diferença. RST # é semelhante; Ele está conectado a um botão que aterra o pino e também vai ao J-Link Lite, mas não há pullup externo. Isso não deve importar, porque, como o NMI #, o pino do RST # possui um pullup interno que é ativado quando o PTA5 está configurado para ser redefinido.

Observando o relógio agora ... Fora da redefinição, o ICS é a fonte do relógio para o FLL e o BDIV no ICS_C2 está definido como 001 (o padrão de redefinição). Se bem entendi, isso significa que o oscilador interno de 32kHz é multiplicado por 1024 pela FLL e depois dividido por 2, tornando o ICSOUTCLK 32kHz * 1024/2 ou 16,8MHz. Posso verificar através da CLI do J-Link que a FLL está bloqueada lendo ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK e IREFST estão definidos, isso está correto.)

Em seguida, passo para verificar se o SIM tem o relógio ativado para o controlador flash, lendo SIM_SCGC. Também posso verificar rapidamente se o BUSDIV no SIM_BUSDIV está definido como zero, o que significa que o BUSCLK tem a mesma frequência do ICSOUTCLK (ou seja, não está sendo dividido):

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

Até agora, tudo parece bem. O BUSCLK tem 16,8 MHz e o relógio do controlador de flash não está bloqueado.

Agora vamos para o controlador flash. O FCLKDIV fora da redefinição é zero e precisamos de um relógio de 1 MHz. A Tabela 18-2 no KEA64RM mostra que o FDIV deve ser definido como 0x10.

Fora de redefinição:

J-Link>mem8 40020000 1
40020000 = 00

Configurar o divisor e verificar se as coisas são boas:

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

FDIVLD está definido e o valor correto em FDIV é mostrado.

Antes de ir muito longe, vamos garantir que o flash não esteja protegido:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (desativado) e SEC = 10 (não garantido). Está bem. Vamos tentar verificar se o dispositivo está em branco:

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

Aqui vemos que os bits MGSTAT no FSTAT indicam que a verificação em branco falhou e também que erros não corrigíveis foram encontrados. Ímpar. Vamos tentar apagá-lo nós mesmos:

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

O comando apagar todos foi bem-sucedido. Agora vamos tentar um cheque em branco:

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

Agora o cheque em branco está bom?

Neste ponto, estou prestes a desistir, comer a perda desses protótipos e usar um processador da ST, onde nunca tive esse tipo de problema antes. A documentação do Kinetis é completa o suficiente, mas é muito densa e estou achando muito difícil começar. Posso alternar a E / S através de leituras de memória e acessar outros periféricos, mas não consigo descobrir o que há de errado com o controlador flash. Trabalho com micros há mais de 20 anos e esse tipo de dificuldade é algo que nunca encontrei antes.

20150102 editar:

Então ainda não vai aqui. Na verdade, comprei uma placa de avaliação FRDM-KL25Z (US $ 15 da DigiKey) e a modifiquei colocando o software CMSIS-DAP genérico no depurador OpenSDA e cortando o J11 conforme o blog de Keith Wakeham . Eu tenho o alvo on-board (o KL25Z) executando um programa simples, para que não interfira na linha de redefinição e posso ver meu SKEAZN64 com o OpenOCD e brincar com ele, mas, infelizmente, também não pode programá-lo. O software Kinetis Design Studio (KDS) não pisca meu Kinetis porque diz que está protegido e preciso fazer uma exclusão em massa, mas o OpenOCD (como parte do KDS) parece não saber como fazer isso. A versão mestra do git do OpenOCD que construí no meu Mac entende o Kinetis, mas não a série específica da KEA, então estou de volta à estaca zero.

Voltando ao J-Link ...

O @AdamHaun tinha uma pista realmente boa e, se eu definir o tipo de redefinição do J-Link (comando rsettype) para digitar '6' (Kinetis), o J-Link deve desativar o watchdog após a redefinição do núcleo. Olhando para o registro WDOG_CS1 (0x40052000), parece que é esse o caso, mas ainda não há dados. Uma operação de exclusão parece sair dos trilhos com o PC em 0xfffffffe e o código de erro -5, e um comando "unlock kinetis" funciona apenas se eu desativar o pino de redefinição usando SIM_SOPT (escrevendo o valor de 32 bits 0x00000008 para 0x40048004). Infelizmente, se eu fizer isso, a CPU não poderá mais ser interrompida novamente, provavelmente porque a interface SWD não pode usar a linha de redefinição para forçar o SWD DAP a um estado conhecido.

20150103 editar:

TENHO LED PISCANDO

REPETIR

TENHO LED PISCANDO

Versão TL; DR: coloque a imagem USBDM na placa FRDM-KL25Z (uma história por si só), use o aplicativo autônomo do ARM Programmer para enviar o teste automaticamente para a placa. Ciclo de poder e voilà.

A versão longa virá mais tarde. Agora tenho menos de 48 horas para escrever e depurar software para esta placa KEAZN64, concluir a modificação / teste de outro software que a acompanha e trabalhar em alguma documentação para outro cliente. Eu prometo que vai atualizar esta pergunta com uma resposta detalhada. Eu só queria compartilhar meu sucesso. Obrigado a todos por sua assistência. Talvez eu precise falar com os mods porque realmente gostaria de dar a recompensa a alguns de vocês em particular.

Na verdade, não consigo encontrar nenhum erro lógico no seu procedimento, mas aqui estão algumas sugestões:

• também há um registro FTMRH_FERSTAT (em 4002_0007h). Deveria dizer o que deu errado ... mas apenas no caso de paridade (ou erros de dupla paridade). Não estou convencido de que isso gravará algo em caso ou apague erros, mas provavelmente vale a pena conferir.

• a documentação da KEA também menciona que uma interrupção pode ser acionada por erros do flash (seção "18.3.5 Interrupções do Flash e da EEPROM"). Não sei se é isso que acontece quando o SEGGER o apaga, mas é uma explicação plausível do motivo pelo qual o PC também muda, pois você viu erros sinalizados no registro FSTAT. Infelizmente, a seção de documentação da KEA para o controlador de interrupção ("3.3.2 Configuração do controlador de interrupção vetorial aninhada (NVIC)") está vagamente apontando na direção do site da ARM para obter a documentação completa. Não consegui descobrir se há um manipulador de interrupção padrão configurado (na inicialização) para erros de flash.

• Você só apagou manualmente no nível do setor, portanto, tente manualmente (como você mesmo registrando o registro apropriado) emitir um comando de apagamento total do flash; a única maneira de fazer isso em um único comando parece ser o "Comando inseguro do flash" documentado na seção 18.3.9.10 (p. 246) do manual. Isso "insegura" o dispositivo e faz um flash completo e a EEPROM será apagada. Você pode pesquisar um bit FSTAT (CCIF) para ver quando ele está supostamente concluído e verificar os sinalizadores de erro novamente posteriormente. EDIT: há também uma seção "18.3.9.7 Erase All Blocks command" no manual, duh.

• tente uma freqüência mais baixa do relógio do barramento. Qualquer coisa acima de 0,8 Mhz funciona de acordo com a documentação. Estou sugerindo isso porque havia um tópico no fórum Freescale em que um flash externo funcionou bem, mas não acima de uma certa frequência que ainda estava na faixa documentada. Portanto, é possível que o controlador flash no chip seja flakey e não possa operar em toda a faixa de frequências declaradas.

• Da mesma forma, teu chip é diferente. Não é inconcebível que, dado o custo desses (cerca de US $ 3), você tenha um custo ruim. Lembro-me de ter um chip x86 incorporado que funcionou bem na maioria das maneiras, mas com erros estranhos em determinadas instruções do modo protegido; meu problema foi embora com um dispositivo diferente da mesma marca. Não está claro para mim se a Freescale possui (publicamente) orientações e erratas para esses dispositivos ou não.

É tudo o que consigo pensar em termos de sugestões de depuração que não foram ditas por outras pessoas nesta página.

20150103 edição (s):

(Material movido aqui dos meus comentários e expandido)

Parece que nem todas as séries Kinetis são (oficialmente, pelo menos) testadas com todos os piscas. A relativamente nova série EA que você está realmente usando parece ser oficialmente suportada apenas pelo próprio pisca-pisca / OEM Cyclone MAX da Freescale; é o único listado na página da Freescale para os serires da EA . Agora concedido, para Kinetis mais antigos, como o KL0, a lista é muito mais longa, incluindo um SEGGER . Não sei se isso é simplesmente devido à falta de testes de outros flashes para a série EA ou se há realmente alguma peculiaridade de programação envolvida que apenas o Cyclone MAX atualmente conhece. Eu esperava que talvez o Freescale demorasse a listar outros piscas, mas ao verificar o manual do J-link (espero que seja o correto), não há séries Kinetis E ou EA listadas lá (p. 249) como testadas, mas apenas dispositivos Kinetis K10 a K60 (e alguns MAC7 mais antigos).

Vale ressaltar que o software / firmware PExDrv para o Cyclone MAX possui um service pack (v10.3) de 20/03/2014, que "Adiciona suporte aos derivados MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 e SKEAZ128". Outra pista é que o próprio software de bootloader / flashloader de código aberto da Freescale para o Kinetis, apesar de ter sido atualizado ainda mais recentemente em 12/2014, não lista nenhum dispositivo da série E ou EA [sub] como compatível. Então, acho que há algo suficientemente diferente em relação ao piscar entre a série E / EA e outros Kinetis como o K10, embora eu não tenha idéia do que exatamente é essa diferença. Portanto, acho que esperar que o EA piscando funcione automaticamente com qualquer coisa, menos o Cyclone MAX, provavelmente não é realista neste momento. Você pode eventualmente descobrir como fazê-lo no nível "bare metal" (comandos de registro direto) da documentação da série EA, mas eu concordo que a documentação é bastante obtusa; certamente falta instruções passo a passo, sendo apenas um manual de referência. Se o carregador de inicialização / flashloader de código aberto da Freescale suportasse a série E / EA, você

Sua experiência com o FRDM-KL25Z (que vem com a série Kinetis L) aponta na mesma direção, ou seja, você não pode trocar uma série L por uma série EA e usar o mesmo pisca-pisca (neste caso, o OpenSDA).

E se você é como Keith (o blogueiro) que "acha ridículo US $ 100 para um programador", provavelmente não ficará satisfeito com a perspectiva de gastar US $ 900 ou mais nesse ciclone. Não sei se a Freescale faz isso de propósito para atrair seus clientes automotivos ou o que ... Certamente parece estranho que as ferramentas da maioria das séries Kinetis não funcionem com o E / EA.

Também tenha cuidado com o fato de que a função intermitente do OpenSDA só funciona no MS Windows , aparentemente.

Se você estiver disposto a tentar (hackear) mais placas, uma com o Kinetis da série E pode ter uma idéia melhor, por exemplo, FRDM-KE02Z (US $ 13 na Digi-Key); também usa o OpenSDA, por isso pode ser hackável. Eles não fabricam / vendem placas com a série EA, até onde eu sei. No entanto, parece que você não pode usar um processador / placa OpenSDA para programar um tipo Kinetis diferente daquele em sua própria placa , mesmo se os dois processadores estiverem na mesma série (por exemplo, L), mas com números diferentes. Infelizmente, "Abrir" no OpenSDA significa apenas que a especificação do SDA está aberta, não que eles forneçam o código fonte como código aberto; então nem consigo encontrar o código fonte para programar um flash da série E. Aparentemente, eu estou meio certo sobre isso. O OpenSDA v1 não é de código aberto, mas a v2 é .

Então, aqui está o resumo do OpenSDAv2 . É basicamente apenas um gerenciador de inicialização e pisca-pisca CMSIS-DAP / mbed. Portanto, ele pode não ter os mesmos recursos ou suportar os mesmos chips que a v1 ... e isso realmente acontece porque flash_features.h não lista nenhum MKE (série E da Kinetis) e muito menos a SKE (série da EA) dispositivos. Em resumo, a proposta da Freescale para a série EA parece ser: compre nosso pisca-pisca Cyclone de US $ 900 ou boa sorte escrevendo o seu com os bits incompletos de código aberto que lançamos.

Acontece, porém, que existe um projeto de código aberto que pode programar pelo menos o Kinetis da série E, chamado USBDM . O bit relevante do seu changelog é:

V4.1.6.140 (abril de 2014)

Dispositivos Kinetis adicionais (MKE04, MKE06, MK64F)

• Correções para dispositivos MKE (falha ao programar, exceto após a exclusão em massa)

E com base nessa entrada de log, certamente parece que a série E é peculiar. Não há suporte direto para a série EA (SKE), mas essa base de código é provavelmente a melhor opção se você deseja invadir seu próprio pisca-pisca; ou talvez você possa convencer o autor do USBDM a adicionar suporte à série EA (SKE). Como hardware do USBDM, você pode usar o FRDM-KL25Z que você já adquiriu; mas você ainda precisa hackear o software USBDM para suportar os chips SKE.

O arquivo de configuração principal do USBDM parece bastante assustador. No USDBM, diferentes flashes (bases de código) são usados ​​para diferentes dispositivos da série MKE: algo chamado "FTMRE" é usado para MKE04 e MKE06, mas "FTMRH" é usado para MKE02. Depois de me olhar brevemente para as duas bases de código, você quase certamente deseja a base de código FTRMH não a FTRME. O último possui uma estrutura FTMRH diferente do seu dispositivo SKEA64; por exemplo, o divisor de relógio não é o primeiro, mas o quarto campo. O FTRME também define o FIDV do barramento para 0x17 = 24Mhz, o que parece estar fora do alcance do seu chip (p. 224 no manual do KEA64 sugere no máximo 20Mhz). O FTMRH o define como 0x0F = 16Mhz (como você), o que parece bom.

Neste ponto, (a menos que você queira comprar o Cyclone MAX), sua melhor aposta é entrar em contato com Podonoghue para que seu chip funcione com sua base de códigos. Ele parece ativo e bastante disposto a ajudar com novos dispositivos (no fórum de freescale) .

Também a partir desse código-fonte do USDBM, posso profetizar que seu SEGGER não pode fazer o flash correto do seu SKEA sozinho, a menos que ele receba sua própria atualização de firmware primeiro. Por que eu digo isso? Como a base de código FTMRH da USDBM é usada por exatamente um dispositivo, o MKE02, sobre o qual o SEGGER parece não saber nada (com base no manual). Outros dispositivos mais comuns, como as séries Kinetis L e K, usam um pisca-pisca USDBM diferente, com base em um código "FTFA". Se você observar o código do FTFA , a estrutura de registro do controlador flash (também começando em 0x40020000) é diferente para eles; o primeiro campo não é nem um divisor de relógio, mas o registro de estatísticas, etc. "Ótima" maneira para a Freescale criar dispositivos incompatíveis ... mas uma vantagem para os fabricantes de pisca-pisca, sem dúvida.

Você tentou o seguinte: Desbloqueando e apagando o FLASH com Segger J-Link

Alegadamente, você deve:

Para reprogramar os setores FLASH protegidos com o Segger J-Link, preciso primeiro desbloquear e apagar em massa o dispositivo. Para isso, existe o utilitário J-Link Commander, que possui uma interface de linha de comando para desproteger e apagar o dispositivo. Apenas para apagar, o J-Flash (e Lite) é uma ferramenta muito útil, especialmente para obter uma memória 'limpa' do dispositivo.

O que eu achei interessante é que você precisa desbloqueá-lo e apagá-lo na próxima etapa se quiser que o desbloqueio seja permanente:

Mas parece que eu preciso fazer um desbloqueio, seguido de uma exclusão para torná-lo permanente. Para apagar o dispositivo, posso usar o mesmo utilitário de linha de comando. Mas preciso especificar primeiro o nome do dispositivo e depois apagá-lo (exemplo para o KL25Z):

EDIT1: adicionado dados incorretos.

EDIT2: você pode ler o registro do Flash Security (FSEC)? Você tentou?

EDIT3: do uso dos recursos de segurança e proteção contra flash Kinetis, Rev. 1, 6/2012

A exclusão em massa via Debugger / JTAG Debuggers e ferramentas JTAG tem acesso muito limitado ao dispositivo quando um processador está protegido. Os únicos registros que podem ser acessados ​​por meio do JTAG são os registros de status e controle do MDM-AP. Para permitir que as ferramentas de depuração não tenham segurança, o bit 0 do registro de controle do MDM-AP pode ser configurado para solicitar uma exclusão em massa do processador. Para usar esse método para desativar a segurança, o FSEC [MEEN] deve ser definido como um valor diferente de 10 para permitir a capacidade de exclusão em massa. Se a exclusão em massa estiver desativada, FSEC [MEEN] = 10, a solicitação de exclusão em massa será ignorada pelo flash e o dispositivo não poderá ser desprotegido usando esse método. Muitos depuradores usarão automaticamente o bit 2 do registro de status do MDM-AP para determinar se um dispositivo está protegido ao tentar estabelecer uma conexão. Uma janela pop-up do depurador pode ser usada para alertar que o dispositivo está protegido e perguntar se uma exclusão em massa é desejada para garantir a segurança do dispositivo. Depois que a exclusão em massa for concluída e verificada, a segurança será desativada. Alguns depuradores podem programar automaticamente o campo de configuração do flash para colocar o flash em um estado não seguro após a exclusão em massa, FSEC = 0xFE.

Também me deparei com posts que mencionam diferentes famílias de cinética requerem diferentes manipulações de sinal RESET ao tentar ler / gravar o registro MDM-AP.

EDIT4: você tentou adicionar um pull-up forte no SWD_DIO? É um tiro no escuro, mas a Freescale o recomenda.

Você precisa parar o processador primeiro. É óbvio que você recebe um sintoma de um processador em execução. Eu uso o openocd; antes de piscar o dispositivo, uso o comando "reset halt". Essa "parada" é um subcomando de "redefinição", para interromper imediatamente após a redefinição, enquanto também existe um comando de interrupção independente.

Portanto, procure um comando "reset halt", apenas uma parada não será suficiente porque você precisa chegar ao estado de pré-inicialização de vetores, eu acho.

Ainda não o vi mencionado, então irei adiante e especularemos que o problema é que esta parte possui um cache ativado na redefinição. Isso é consistente com o comportamento "estranho" que você observou com o cheque em branco. O Flash subjacente foi atualizado, mas o cache não. Para corrigir isso, desative o cache de dados e instruções escrevendo para MCM_PLACRat F000_300Che também limpe o cache ao fazê-lo. Esse mesmo comportamento estranho provavelmente confundiu o Segger também.

Como a mensagem de erro é sobre o valor do PC, parece que a CPU está saindo dos trilhos em algum lugar. Este é um tiro no escuro, mas você já tentou desativar o cronômetro do watchdog?