Freescale Kinetis KE - scrittura su flash

Uso molti microcontrollori e microprocessori da molti, molti anni ormai, ma mi sembra di essere ostacolato dalla serie Kinetis KE (in particolare S9KEAZN64AMLC).

17 gennaio 2015 TL; DR:

Freescale conferma che la versione 2.0 del software Kinetis Design Studio non funziona con questo dispositivo (inclusa la propria scheda di valutazione TRK-KEA64). Per il momento raccomandano di usare CodeWarrior MCU V10.6.

Segger ha rilasciato la v4.96a (la "a" è importante, stavo usando la v4.96) che risolve il problema e consente di utilizzare una scheda di debuger CortexM J-Link Lite Segger con KDS e dispone di funzionalità complete di programma / debug.

Prima che Segger rilasciasse la v4.96a, sono riuscito a far lampeggiare il chip riprogrammando il debugger OpenSDA sulla scheda di valutazione FRDM-KL25Z economica ($ 15) di Freescale riflettendo il firmware OpenSDA fornito con USBDM (usando v4.10.6.240). Ho quindi utilizzato il software standalone "ARM Programmer" di USBDM. Non ho trascorso molto tempo a cercare di far funzionare il debug, poiché sono abbastanza abile nel debug "oldschool" per non averne bisogno. Assicurati di eseguire il flashing di un programma "benigno" nel target di bordo KL25 o potrebbe interferire con la programmazione poiché la linea di reset del target di bordo KL25 è ancora collegata al debugger OpenSDA anche con taglio J11 (vedi il post sul blog di Keith Wakeham , collegato di seguito).

Un grande ringraziamento a Erich Styger per avermi aiutato molto gentilmente a determinare il problema e confermare le mie scoperte tramite e-mail.

Ora torniamo alla nostra domanda regolarmente programmata:

Ho creato una stupenda scheda breakout 3.3V. Ha alcuni LED su PTA, una connessione UART su PTC e le linee SWD sono sulle loro linee dedicate. Non c'è letteralmente niente di stravagante o divertente in questa tavola.

Sto usando un J-Link Lite per Cortex-M (J-Link LITE CortexM-9, vedi https://www.segger.com/jlink-lite-cortexm.html ) e sotto OSX e Windows ottengo il stesso risultato: l'utilità J-Link Commander può identificare il chip, posso leggere e scrivere su SRAM e giocare con le periferiche con letture e scritture manuali all'indirizzo I / O mappato in memoria corretto. Quando provo a far lampeggiare il dispositivo, tuttavia, non riesce.

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

Il J-Link Lite è perfettamente funzionante (posso leggere e scrivere sul SoC nRF58122, un altro processore Cortex-M0, con esso) e il dispositivo sembra funzionare diversamente. So che Kinetis è sbloccato poiché sono stock freschi di fabbrica da DigiKey, ma anche allora il comando "sblocco cinetis" in JLinkExe scade senza errori o informazioni utili.

A questo punto sono sicuro che sto facendo qualcosa di stupido, ma sono in perdita per quello che potrebbe essere.

Qualcuno ha già lavorato con questi dispositivi? Come li stai programmando?

modifica per aggiungere la procedura dettagliata:

Qualche informazione in più:

Ho letto che il pin NMI # è abilitato dal reset (e verificato questo leggendo SIM_SOPT) ma anche che ha un pull-up interno quando abilitato. In questa particolare parte PTB4 si trova sul pin 10, che è un no-connect nel mio design. La disabilitazione del pin NMI non fa differenza. RST # è simile; È collegato a un pulsante che mette a terra il pin e va anche a J-Link Lite ma non c'è pullup esterno. Questo non dovrebbe importare perché come NMI #, il pin RST # ha un pullup interno che è abilitato quando PTA5 è configurato per essere un reset.

Guardando il clock ora ... Fuori dal reset, ICS è la sorgente di clock per FLL e BDIV in ICS_C2 è impostato su 001 (il valore predefinito di reset). Se ho capito bene, questo significa che l'oscillatore interno a 32kHz viene moltiplicato per 1024 per il FLL e quindi diviso per 2, rendendo ICSOUTCLK 32kHz * 1024/2 o 16.8MHz. Posso verificare tramite l'interfaccia della riga di comando J-Link che il FLL è bloccato leggendo ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK e IREFST sono impostati, questo è corretto.)

Passo quindi a verificare che la SIM abbia l'orologio abilitato per il controller flash leggendo SIM_SCGC. Posso anche verificare rapidamente per assicurarmi che BUSDIV in SIM_BUSDIV sia impostato su zero, il che significa che BUSCLK ha la stessa frequenza di ICSOUTCLK (cioè non viene suddiviso):

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

Finora, tutto sembra a posto. BUSCLK è 16,8 MHz e l'orologio del controller flash non è chiuso.

Passiamo ora al controller flash. Fuori reset FCLKDIV è zero e abbiamo bisogno di un clock da 1MHz. La Tabella 18-2 in KEA64RM mostra che FDIV deve essere impostato su 0x10.

Non resettato:

J-Link>mem8 40020000 1
40020000 = 00

Configurare il divisore e verificare le cose vanno bene:

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

FDIVLD è impostato e viene visualizzato il valore corretto in FDIV.

Prima di andare troppo avanti, assicuriamoci che il flash non sia protetto:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (disabilitato) e SEC = 10 (non garantito). Ok. Proviamo a verificare che il dispositivo sia vuoto:

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

Qui vediamo che i bit MGSTAT in FSTAT indicano che il controllo del bianco è fallito e che sono stati trovati errori non correggibili. Dispari. Proviamo a cancellarlo da soli:

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

Il comando cancella tutto è riuscito. Ora proviamo un controllo vuoto:

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

Ora il controllo in bianco va bene?

A questo punto sono pronto per arrendermi, mangiare la perdita di questi prototipi e andare con un processore di ST dove non ho mai avuto questo tipo di problemi prima. La documentazione di Kinetis è abbastanza approfondita ma è molto densa e trovo molto difficile iniziare. Posso spostare l'I / O attraverso le letture della memoria e accedere ad altre periferiche, ma non riesco a capire cosa c'è che non va nel controller flash. Lavoro con i micro da oltre 20 anni e questo tipo di difficoltà è qualcosa che non avevo mai incontrato prima.

20150102 modifica:

Quindi ancora non andare qui. Ho effettivamente acquistato una scheda di valutazione FRDM-KL25Z ($ 15 da DigiKey) e l'ho modificata inserendo il software generico CMSIS-DAP sul debugger OpenSDA e tagliando J11 come nel blog di Keith Wakeham . Ho il target di bordo (il KL25Z) che esegue un semplice programma in modo che non interferisca con la linea di reset e posso vedere il mio SKEAZN64 con OpenOCD e giocare con esso, ma sfortunatamente non può nemmeno programmarlo. Il software Kinetis Design Studio (KDS) non farà lampeggiare il mio Kinetis perché dice che è protetto e che devo fare una cancellazione di massa, ma OpenOCD (come parte di KDS) non sembra sapere come farlo. La versione master git di OpenOCD che ho costruito sul mio Mac comprende Kinetis, ma non la specifica serie KEA, quindi sono tornato al punto di partenza.

Tornando al J-Link ...

@AdamHaun ha avuto un ottimo indizio, e se ho impostato il tipo di reset di J-Link (comando rsettype) sul tipo '6' (Kinetis) si suppone che J-Link disabiliti il ​​watchdog dopo aver resettato il core. Guardando il registro WDOG_CS1 (0x40052000) sembra che sia così, ma ancora nessun dado. Un'operazione di cancellazione sembra andare fuori dai binari con PC a 0xfffffffe e codice di errore -5, e un comando "sblocca cinetis" funziona solo se disabilito il pin di reset usando SIM_SOPT (scrivendo il valore a 32 bit da 0x00000008 a 0x40048004). Sfortunatamente, se lo faccio, la CPU non può mai essere arrestata di nuovo, presumibilmente perché l'interfaccia SWD non può usare la linea di reset per forzare il DAP SWD in uno stato noto.

20150103 modifica:

HO LED LAMPEGGIANTE

RIPETERE

HO LED LAMPEGGIANTE

Versione TL; DR: metti l'immagine USBDM sulla scheda FRDM-KL25Z (una storia tutta per sé), usa l'app autonoma del programmatore ARM per inviare il test stesso sulla scheda. Ciclo di accensione e voilà.

La versione lunga arriverà più tardi. Ora ho meno di 48 ore per scrivere ed eseguire il debug del software per questa scheda KEAZN64, finire di modificare / testare altri software che ne derivano e lavorare su alcuni documenti per un altro client. Prometto che farò aggiornare a questa domanda con una risposta dettagliata. Volevo solo condividere il mio successo. Grazie a tutti per il vostro aiuto. Potrei dover parlare con le mod perché mi piacerebbe davvero dare la grazia ad un paio di voi in particolare.

In realtà non riesco a trovare alcun errore logico nella tua procedura, ma ecco alcuni suggerimenti:

• c'è anche un registro FTMRH_FERSTAT (a 4002_0007h). Dovrebbe dirti cosa è andato storto ... ma solo in caso di parità (o errori di doppia parità). Non sono convinto che questo registrerà qualcosa nel caso o cancellerà errori, ma probabilmente vale la pena dare un'occhiata.

• la documentazione di KEA menziona anche che un interrupt può essere innescato da errori flash (sezione "18.3.5 Interrupt Flash ed EEPROM"). Non so se questo è ciò che accade quando SEGGER lo cancella, ma è una spiegazione plausibile del perché anche il PC cambia poiché hai visto errori contrassegnati nel registro FSTAT. Sfortunatamente la sezione della documentazione di KEA per il controller di interrupt ("3.3.2 Configurazione del controller di interrupt vettoriale annidato") punta piuttosto vagamente nella direzione del sito Web ARM per la documentazione completa. Non sono riuscito a capire se esiste un gestore di interrupt predefinito impostato (all'avvio) per errori flash.

• Hai effettuato solo cancellazioni a livello di settore manualmente, quindi prova a emettere manualmente (come nel caso scrivendo il registro appropriato) un comando di cancellazione completamente flash; l'unico modo per farlo in un singolo comando sembra essere il "Comando flash non sicuro" documentato nella sezione 18.3.9.10 (p. 246) del manuale. Ciò "non è sicuro" del dispositivo e cancella completamente il flash e la EEPROM. È possibile eseguire il polling di un bit FSTAT (CCIF) per vedere quando è presumibilmente completato e controllare nuovamente i flag di errore in seguito. EDIT: c'è anche una sezione "Comando Cancella tutti i blocchi" nel manuale, duh.

• provare una frequenza di clock bus inferiore. Qualsiasi cosa sopra 0,8 Mhz funziona secondo la documentazione. Lo sto suggerendo perché c'era un thread sul forum di Freescale in cui un flash esterno funzionava bene, ma non al di sopra di una certa frequenza che era ancora nell'intervallo ben documentato. Quindi è possibile che il controller flash nel chip sia flakey e non possa funzionare sull'intera gamma di frequenze indicate.

• allo stesso modo, sei un chip diverso. Non è inconcepibile che dato quanto costano (circa $ 3) ne hai una cattiva. Ricordo di avere un chip x86 incorporato che funzionava bene nella maggior parte dei modi ma aveva strani errori su alcune istruzioni in modalità protetta; il mio problema è andato via con un dispositivo diverso della stessa marca. Non mi è chiaro se Freescale abbia o meno dichiarato (pubblicamente) steppings ed errata per questi dispositivi.

Questo è tutto ciò a cui riesco a pensare in termini di suggerimenti di debug che non sono stati detti da altri in questa pagina.

20150103 modifica (s):

(Spostato materiale qui dai miei commenti ed espanso)

Sembra che non tutte le serie Kinetis siano (almeno ufficialmente) testate con tutti i flashers. La nuova serie EA che stai effettivamente usando sembra essere ufficialmente supportata solo dal lampeggiatore Cyclone MAX di Freescale / OEM; è l'unico elencato sulla pagina di Freescale per i server EA . Ora concesso, per i Kinetis più vecchi come KL0 l'elenco è molto più lungo, incluso un SEGGER . Non so se questo sia semplicemente a causa della mancanza di test di altri flasher per la serie EA o se in realtà ci sono alcune stranezze di programmazione che solo il loro Cyclone MAX attualmente conosce. Speravo che forse Freescale fosse lento nell'elencare altri flasher, ma dopo aver controllato il manuale di J-link (si spera quello giusto), non c'è nessuna serie Kinetis E o EA elencata lì (p. 249) come testata, ma solo i dispositivi Kinetis da K10 a K60 (e alcuni vecchi MAC7).

Da notare che il software / firmware PExDrv per Cyclone MAX ha un service pack (v10.3) datato 20/03/2014, che "aggiunge il supporto per MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 e SKEAZ128 derivati". Un altro indizio è che il software bootloader / flashloader open source di Freescale per Kinetis, nonostante sia stato aggiornato ancora più recentemente nel 12/2014, non elenca alcun dispositivo E o EA [sub] series come supportato. Quindi penso che ci sia qualcosa di sufficientemente diverso per quanto riguarda il flashing tra la serie E / EA e altri Kinetis come il K10, anche se non ho idea di quale sia esattamente la differenza. Pertanto, penso che aspettarsi che il flashing di EA funzioni automaticamente con qualsiasi cosa tranne il Cyclone MAX a questo punto probabilmente non è realistico. Potresti eventualmente riuscire a capire come farlo a livello "bare metal" (comandi di registro diretto) dalla documentazione della serie EA, ma sono d'accordo che la documentazione è piuttosto ottusa; manca certamente di istruzioni passo-passo essendo solo un manuale di riferimento. Se il bootloader / flashloader open source di Freescale avesse supportato la serie E / EA, tu '

Il tuo esperimento con FRDM-KL25Z (che viene fornito con una serie Kinetis L) punta nella stessa direzione, cioè non puoi scambiare una serie L con una serie EA e utilizzare lo stesso lampeggiatore (in questo caso OpenSDA).

E se sei come Keith (il blogger) che "pensa [s] $ 100 dollari per un programmatore è ridicolo", probabilmente non sarai soddisfatto della prospettiva di far cadere $ 900 + su quel Ciclone. Non so se Freescale lo faccia apposta per viziare i loro clienti automobilistici o cosa ... Sicuramente sembra strano che gli strumenti per la maggior parte delle serie Kinetis non funzionino con l'E / EA.

Nota anche che la funzione di OpenSDA lampeggiante funziona solo con MS Windows , a quanto pare.

Se sei disposto a provare (hackerare) più schede, una con un Kinetis serie E potrebbe essere un'idea migliore, ad esempio FRDM-KE02Z ($ 13 su Digi-Key); usa anche OpenSDA quindi potrebbe essere hackerabile. Per quanto ne so, non producono / vendono schede con la serie EA. Tuttavia, sembra che non sia possibile utilizzare un processore / scheda OpenSDA per programmare un tipo di Kinetis diverso da quello sulla propria scheda , anche se entrambi i processori sono nella stessa serie (ad es. L), ma numeri diversi. Sfortunatamente "Open" in OpenSDA significa solo che le specifiche SDA sono aperte, non che forniscono il codice sorgente come open-source; quindi non riesco nemmeno a trovare il codice sorgente per programmare un flash della serie E. Apparentemente, ho solo ragione a metà. OpenSDA v1 non è open-source, ma lo è v2 .

Quindi ecco il lowdown su OpenSDAv2 . Fondamentalmente è solo un bootloader e un lampeggiatore CMSIS-DAP / mbed. Quindi potrebbe non avere le stesse funzionalità o supportare gli stessi chip di v1 ... e questo in realtà risulta essere il caso perché flash_features.h non elenca alcun MKE (Kinetis serie E) e tanto meno SKE (serie EA) dispositivi. In sintesi, la proposta di Freescale per la serie EA sembra essere: acquista il nostro lampeggiatore Cyclone da $ 900 o buona fortuna scrivendo il tuo da qualsiasi frammento incompleto di open source che abbiamo rilasciato.

Si scopre tuttavia che esiste un progetto open source in grado di programmare almeno il Kinetis serie E, ovvero USBDM . Il bit rilevante dal suo log delle modifiche è:

V4.1.6.140 (aprile 2014)

Dispositivi Kinetis aggiuntivi (MKE04, MKE06, MK64F)

• Correzioni per i dispositivi MKE (impossibile programmare tranne dopo la cancellazione di massa)

E sulla base di quella voce di registro, sembra sicuramente che le serie E siano eccentriche. Non esiste un supporto diretto per la serie EA (SKE), ma quella base di codice è probabilmente la soluzione migliore se si desidera hackerare il proprio lampeggiatore; o forse puoi convincere l'autore di USBDM ad aggiungere il supporto della serie EA (SKE). Come hardware per USBDM si scopre che puoi usare il FRDM-KL25Z che hai già acquisito; ma devi ancora hackerare il software USBDM per supportare i chip SKE.

Il file di configurazione principale per USBDM sembra piuttosto scoraggiante. In USDBM sono usati diversi lampeggiatori (basi di codice) per diversi dispositivi della serie MKE: qualcosa chiamato "FTMRE" è usato per MKE04 e MKE06, ma "FTMRH" è usato per MKE02. Dopo aver esaminato brevemente le due basi di codici, quasi sicuramente vuoi la base di codici FTRMH e non quella FTRME. Quest'ultimo ha una struttura FTMRH diversa rispetto al tuo dispositivo SKEA64, ad esempio il divisore di clock non è il primo ma il 4o campo. FTRME imposta anche il bus FIDV su 0x17 = 24Mhz, che sembra fuori portata per il chip (p. 224 nel manuale KEA64 suggerisce un massimo di 20Mhz). FTMRH lo imposta su 0x0F = 16Mhz (come fai tu), il che sembra a posto.

A questo punto, (a meno che tu non voglia acquistare il Cyclone MAX) la soluzione migliore è contattare Podonoghue per far funzionare il tuo chip con la sua base di codice. Sembra attivo e abbastanza disposto ad aiutare con i nuovi dispositivi (sul forum di Freescale) .

Anche da quel codice sorgente di USDBM posso profetizzare che SEGGER non può in alcun modo far lampeggiare correttamente SKEA da solo se non ottiene prima il proprio aggiornamento del firmware. Perché lo dico io? Poiché la base di codice FTMRH di USDBM viene utilizzata esattamente da un dispositivo lì, l'MKE02, di cui il tuo SEGGER sembra non sapere nulla (basato sul suo manuale). Altri dispositivi più comuni come le serie Kinetis L e K utilizzano un diverso lampeggiatore USDBM basato su una base di codice "FTFA". Se si osserva il codice FTFA , la struttura del registro del controller flash (anche a partire da 0x40020000) è diversa per questi; il primo campo non è nemmeno un divisore di clock, ma il registro stat, ecc. "Ottimo" modo per Freescale di creare dispositivi incompatibili ... ma un vantaggio per i produttori di lampeggiatori, senza dubbio.

Hai provato questo: sbloccare e cancellare FLASH con Segger J-Link

Presumibilmente devi:

Per riprogrammare i settori FLASH protetti con Segger J-Link, devo prima sbloccare e cancellare in massa il dispositivo. Per questo, c'è l'utilità J-Link Commander che ha un'interfaccia a riga di comando per rimuovere la protezione e cancellare il dispositivo. Solo per la cancellazione, J-Flash (e Lite) è uno strumento molto utile, soprattutto per ottenere una memoria del dispositivo "pulita".

Quello che ho trovato interessante è che devi sbloccarlo e cancellarlo nel passaggio successivo se vuoi che lo sblocco sia permanente:

Ma sembra che devo fare uno sblocco, seguito da una cancellazione per renderlo permanente. Per cancellare il dispositivo, posso usare la stessa utility da riga di comando. Ma prima devo specificare il nome del dispositivo, quindi posso cancellarlo (esempio per il KL25Z):

EDIT1: aggiunti dati errati.

EDIT2: puoi forse leggere il registro di sicurezza Flash (FSEC)? Hai provato?

EDIT3: da Utilizzo delle funzionalità Kinetis Security e Flash Protection, Rev. 1, 6/2012

Cancellazione di massa tramite Debugger / JTAG I debugger e gli strumenti JTAG hanno un accesso molto limitato al dispositivo quando un processore è protetto. Gli unici registri a cui è possibile accedere tramite JTAG sono i registri di stato e controllo MDM-AP. Per consentire agli strumenti di debug di parti non sicure, il bit 0 del registro di controllo MDM-AP può essere impostato per richiedere una cancellazione di massa del processore. Per utilizzare questo metodo per disabilitare la sicurezza, FSEC [MEEN] deve essere impostato su un valore diverso da 10 per consentire la funzionalità di cancellazione di massa. Se la cancellazione di massa è disabilitata, FSEC [MEEN] = 10, la richiesta di cancellazione di massa verrà ignorata dal flash e il dispositivo non può essere non protetto con questo metodo. Molti debugger utilizzeranno automaticamente il bit 2 del registro di stato MDM-AP per determinare se un dispositivo è protetto quando si tenta di stabilire una connessione. Una finestra pop-up di debugger potrebbe essere utilizzata per avvisare che il dispositivo è protetto e chiedere se si desidera una cancellazione di massa per rendere non sicuro il dispositivo. Una volta completata e verificata la cancellazione di massa, la sicurezza verrà disabilitata. Alcuni debugger potrebbero programmare automaticamente il campo di configurazione del flash per mettere il flash in uno stato non protetto dopo il completamento della cancellazione di massa, FSEC = 0xFE.

Inoltre mi sono imbattuto in un post che menziona diverse famiglie di cinetis richiedono diverse manipolazioni del segnale RESET quando si tenta di leggere / scrivere il registro MDM-AP.

EDIT4: hai provato ad aggiungere un forte pull-up su SWD_DIO? È uno scatto nel buio, ma Freescale lo consiglia.

Devi prima arrestare il processore. È ovvio che si ottiene un sintomo di un processore in esecuzione. Uso openocd; prima di far lampeggiare il dispositivo uso il comando "reset halt". Tale "arresto" è un sottocomando di "ripristino", per l'arresto immediato dopo il ripristino, mentre esiste anche un comando di arresto autonomo.

Quindi cerca un comando "reset halt", solo una sosta non sarà sufficiente perché devi arrivare allo stato di pre-inizializzazione dei vettori immagino.

Non l'ho ancora visto menzionato, quindi andrò avanti e ipotizzerò che il problema è che questa parte ha una cache abilitata al ripristino. Ciò è coerente con il comportamento "strano" osservato con il segno di spunta. Il Flash sottostante è stato aggiornato ma la cache no. Per risolvere questo problema, disattiva sia la cache dei dati che quella delle istruzioni scrivendo su MCM_PLACRat F000_300Che cancella anche la cache mentre lo fai. È probabile che questo stesso strano comportamento abbia confuso anche il Segger.

Poiché il messaggio di errore riguarda il valore del PC, sembra che la CPU stia andando fuori dai binari da qualche parte. Questo è un colpo lungo, ma hai provato a disabilitare il timer del watchdog?