Freescale Kinetis KE - pisanie do flasha

Używam różnych mikrokontrolerów i mikroprocesorów od wielu, wielu lat, ale wydaje mi się, że przeszkadza mi seria Kinetis KE (w szczególności S9KEAZN64AMLC).

17 stycznia 2015 TL; DR:

Freescale potwierdza, że wersja 2.0.0 ich oprogramowania Kinetis Design Studio nie działa z tym urządzeniem (w tym z własną płytą ewaluacyjną TRK-KEA64). Na razie zalecają używanie CodeWarrior MCU V10.6.

Segger wypuścił wersję 4.96a („a” jest ważne, korzystałem z wersji 4.96), która rozwiązuje problem i pozwala używać płyty debugera Segger J-Link Lite CortexM z KDS i mieć pełną możliwość programowania / debugowania.

Zanim Segger wypuścił wersję 4.96a, udało mi się sflashować układ, przeprogramowując debugger OpenSDA na niedrogiej (15 USD) płycie ewaluacyjnej FRDM-KL25Z Freescale, zmieniając oprogramowanie wbudowane OpenSDA z USBDM (przy użyciu wersji v.10.10.6.240). Następnie użyłem samodzielnego oprogramowania „ARM Programmer” USBDM. Nie spędzałem dużo czasu próbując uruchomić debugowanie, ponieważ jestem wystarczająco biegły w debugowaniu „oldschool”, aby go nie potrzebować. Upewnij się, że flashujesz „łagodny” program na pokładzie KL25 lub może to zakłócać programowanie, ponieważ linia resetu na pokładzie KL25 jest nadal podłączona do debuggera OpenSDA, nawet z cięciem J11 (patrz post na blogu Keitha Wakehama , link poniżej).

Ogromne podziękowania dla Ericha Stygera za bardzo, bardzo łaskawą pomoc w ustaleniu problemu i potwierdzeniu moich ustaleń przez e-mail.

Wróćmy do naszego regularnie zaplanowanego pytania:

Zbudowałem głupio prostą płytkę z wyłącznikiem 3,3 V. Ma kilka diod LED na PTA, połączenie UART na PTC, a linie SWD są na dedykowanych liniach. W tej desce nie ma dosłownie nic wyszukanego ani zabawnego.

Używam J-Link Lite dla Cortex-M (J-Link LITE CortexM-9, patrz https://www.segger.com/jlink-lite-cortexm.html ) i zarówno w OSX, jak i Windows otrzymuję ten sam wynik: narzędzie J-Link Commander może zidentyfikować układ, mogę czytać i zapisywać w pamięci SRAM oraz bawić się urządzeniami peryferyjnymi z ręcznymi odczytami i zapisami na poprawny adres we / wy odwzorowany w pamięci. Jednak gdy próbuję sflashować urządzenie, to się nie udaje.

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

J-Link Lite jest całkowicie w porządku (mogę czytać i pisać na nRF58122 SoC, innym procesorze Cortex-M0, z nim), a urządzenie wydaje się działać inaczej. Wiem, że Kinetis jest odblokowany, ponieważ są fabrycznie nowe od DigiKey, ale nawet wtedy polecenie „odblokowanie kinetis” w JLinkExe przekroczy limit czasu bez żadnego błędu lub użytecznych informacji.

W tej chwili jestem pewien, że robię coś głupiego, ale brakuje mi tego, co to może być.

Czy ktoś wcześniej pracował z tymi urządzeniami? Jak je programujesz?

edytuj, aby dodać instrukcję:

Więcej informacji:

Przeczytałem, że pin NMI # jest włączony po zresetowaniu (i zweryfikowałem to, czytając SIM_SOPT), ale także, że ma wewnętrzny pull-up, gdy jest włączony. W tej konkretnej części PTB4 znajduje się na pinie 10, co w moim projekcie nie ma połączenia. Wyłączenie pinu NMI nie ma znaczenia. RST # jest podobny; Jest podłączony do przycisku, który uziemia pin, a także przechodzi do J-Link Lite, ale nie ma zewnętrznego pullupu. Nie powinno to mieć znaczenia, ponieważ podobnie jak NMI #, pin RST # ma wewnętrzne pullup, który jest włączony, gdy PTA5 jest skonfigurowany do resetowania.

Patrząc na taktowanie teraz ... Po zresetowaniu ICS jest źródłem zegara dla FLL, a BDIV w ICS_C2 jest ustawiony na 001 (domyślne resetowanie). Jeśli dobrze rozumiem, oznacza to, że wewnętrzny oscylator 32kHz jest mnożony przez 1024 przez FLL, a następnie dzielony przez 2, co daje ICSOUTCLK 32kHz * 1024/2 lub 16,8 MHz. Mogę sprawdzić za pomocą interfejsu CLI J-Link, czy plik FLL jest zablokowany, czytając ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(LOCK i IREFST są ustawione, jest to poprawne.)

Następnie przechodzę do sprawdzenia, czy karta SIM ma włączony zegar kontrolera flash, czytając SIM_SCGC. Mogę również szybko sprawdzić, aby upewnić się, że BUSDIV w SIM_BUSDIV jest ustawiony na zero, co oznacza, że ​​BUSCLK ma tę samą częstotliwość co ICSOUTCLK (tj. Nie jest dzielony):

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

Jak dotąd wszystko wygląda dobrze. BUSCLK ma 16,8 MHz, a zegar kontrolera flash nie jest bramkowany.

Przejdźmy teraz do kontrolera flash. Po zresetowaniu FCLKDIV wynosi zero i potrzebujemy zegara 1MHz. Tabela 18-2 w KEA64RM pokazuje, że FDIV powinien być ustawiony na 0x10.

Po zresetowaniu:

J-Link>mem8 40020000 1
40020000 = 00

Konfigurowanie dzielnika i sprawdzanie rzeczy jest dobre:

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

FDIVLD jest ustawiony i wyświetlana jest poprawna wartość w FDIV.

Zanim przejdziemy za daleko, upewnijmy się, że lampa błyskowa nie jest chroniona:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (wyłączony) i SEC = 10 (niezabezpieczony). Dobrze. Spróbujmy sprawdzić, czy urządzenie jest puste:

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

Widzimy tutaj, że bity MGSTAT w FSTAT wskazują, że sprawdzenie próby ślepej nie powiodło się, a także znaleziono błędy, których nie można poprawić. Dziwny. Spróbujmy to usunąć sami:

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

Komenda wymazania wszystkich powiodła się. Teraz wypróbujmy czek in 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

Teraz czek in blanco jest w porządku?

W tym momencie jestem już gotowy się poddać, zjeść stratę na tych prototypach i przejść z procesorem z ST, w którym nigdy wcześniej nie miałem takich problemów. Dokumentacja Kinetis jest dość dokładna, ale jest bardzo gęsta i trudno mi zacząć. Mogę przełączać wejścia / wyjścia poprzez odczyty pamięci i uzyskiwać dostęp do innych urządzeń peryferyjnych, ale przez całe życie nie mogę zrozumieć, co jest nie tak z kontrolerem flash. Pracuję z micros od ponad 20 lat i tego rodzaju trudności nigdy wcześniej nie spotkałem.

20150102 edycja:

Więc nadal nie idź tutaj. Właściwie kupiłem płytę ewaluacyjną FRDM-KL25Z (15 USD od DigiKey) i zmodyfikowałem ją, umieszczając ogólne oprogramowanie CMSIS-DAP w debuggerze OpenSDA i wycinając J11 zgodnie z blogiem Keitha Wakehama . Mam na pokładzie docelowy (KL25Z) działający prosty program, więc nie koliduje on z linią zerowania i widzę mój SKEAZN64 z OpenOCD i bawię się nim, ale niestety nie może go również zaprogramować. Oprogramowanie Kinetis Design Studio (KDS) nie flashuje mojego Kinetisa, ponieważ mówi, że jest chroniony i muszę wykonać masowe wymazywanie, ale OpenOCD (jako część KDS) nie wie, jak to zrobić. Wersja git master OpenOCD, którą zbudowałem na moim Macu, rozumie Kinetis, ale nie konkretną serię KEA, więc wracam do sedna.

Wracając do J-Link ...

@AdamHaun miał naprawdę dobrą wskazówkę i jeśli ustawię typ resetowania J-Link (polecenie rsettype) na typ „6” (Kinetis), J-Link powinien wyłączyć watchdoga po zresetowaniu rdzenia. Patrząc na rejestr WDOG_CS1 (0x40052000) wydaje się, że tak jest, ale nadal nie ma kości. Wydaje się, że operacja kasowania znika z komputera z 0xfffffffe i kodem błędu -5, a polecenie „odblokuj kinetis” działa tylko wtedy, gdy wyłączę pin resetowania za pomocą SIM_SOPT (zapisując 32-bitową wartość 0x00000008 na 0x40048004). Niestety, jeśli to zrobię, procesora nie można już nigdy zatrzymać, prawdopodobnie dlatego, że interfejs SWD nie może użyć linii resetowania do wymuszenia znanego stanu SWD DAP.

20150103 edycja:

MAMY DIODĘ LED

POWTARZAĆ

MAMY DIODĘ LED

Wersja TL; DR: umieść obraz USBDM na płycie FRDM-KL25Z (historia sama w sobie), użyj samodzielnej aplikacji ARM Programmer, aby wysłać testową .elf na płytkę. Cykl zasilania i voilà.

Długa wersja pojawi się później. Mam teraz mniej niż 48 godzin na napisanie i debugowanie oprogramowania dla tej płyty KEAZN64, dokończyć modyfikowanie / testowanie innego oprogramowania, które się z nią wiąże, i pracować nad dokumentacją dla innego klienta. Obiecuję, że będzie aktualizować to pytanie ze szczegółową odpowiedź. Chciałem tylko podzielić się moim sukcesem. Dziękuję KAŻDEMU za pomoc. Być może będę musiał porozmawiać z modami, ponieważ naprawdę chciałbym dać nagrodę szczególnie niektórym z was.

Nie mogę znaleźć żadnych błędów logicznych w twojej procedurze, ale oto kilka sugestii:

• jest też rejestr FTMRH_FERSTAT (o 4002_0007h). Ma powiedzieć ci, co poszło nie tak ... ale tylko w przypadku parzystości (lub błędów podwójnej parzystości). Nie jestem przekonany, że to coś zarejestruje na wypadek lub skasuje błędy, ale prawdopodobnie warto to sprawdzić.

• w dokumentacji KEA wspomniano również, że przerwanie może zostać wywołane przez błędy flash (sekcja „18.3.5 Przerwania Flash i EEPROM”). Nie wiem, czy tak się dzieje, gdy SEGGER usuwa go, ale jest to prawdopodobne wytłumaczenie, dlaczego komputer się zmienia, ponieważ widziałeś błędy oznaczone w rejestrze FSTAT. Niestety, sekcja dokumentacji KEA dla kontrolera przerwań („Konfiguracja zagnieżdżonego Vectored Interrupt Controller (NVIC)”) raczej niejasno wskazuje na stronę ARM w celu uzyskania pełnej dokumentacji. Nie byłem w stanie ustalić, czy istnieje domyślna procedura obsługi przerwań (podczas rozruchu) dla błędów flash.

• Usuwasz tylko ręcznie na poziomie sektora, więc spróbuj ręcznie (np. Samodzielnie pisząc odpowiedni rejestr) wydać polecenie pełnego wymazywania; jedynym sposobem na zrobienie tego w jednym poleceniu wydaje się być „Niezabezpieczone polecenie flash” udokumentowane w sekcji 18.3.9.10 (s. 246) podręcznika. Spowoduje to zarówno „niezabezpieczenie” urządzenia, jak i pełne flashowanie i wymazywanie pamięci EEPROM. Możesz sondować bit FSTAT (CCIF), aby zobaczyć, kiedy jest rzekomo ukończony, i później ponownie sprawdzić flagi błędów. EDYCJA: w podręczniku znajduje się również sekcja „Polecenie wymaż wszystkie bloki” 18.3.9.7.

• wypróbuj niższą częstotliwość zegara magistrali. Wszystko powyżej 0,8 MHz działa zgodnie z dokumentacją. Sugeruję to, ponieważ na forum Freescale był jeden wątek, w którym zewnętrzny flash działał dobrze, ale nie powyżej określonej częstotliwości, która wciąż była w dobrze udokumentowanym zakresie. Możliwe więc, że kontroler pamięci flash w układzie jest płatkowy i nie może działać na pełnym zakresie podanych częstotliwości.

• podobnie twój inny układ. Nie jest wykluczone, że biorąc pod uwagę, ile kosztują (około 3 USD), masz zły. Pamiętam, że miałem wbudowany układ x86, który działał dobrze pod wieloma względami, ale miał dziwne błędy w niektórych instrukcjach trybu chronionego; mój problem zniknął z innym urządzeniem tej samej marki. Nie jest dla mnie jasne, czy Freescale ma (publicznie podane) kroki i erratę dla tych urządzeń, czy nie.

To wszystko, o czym myślę, jeśli chodzi o sugestie debugowania, których inni nie powiedzieli na tej stronie.

20150103 edycja:

(Przeniesiłem materiał tutaj z moich komentarzy i rozwinął się)

Wygląda na to, że nie wszystkie serie Kinetis są (przynajmniej oficjalnie) testowane ze wszystkimi flasherami. Dość nowa seria EA, której faktycznie używasz, wydaje się oficjalnie wspierana tylko przez własny flasher Freescale / OEM Cyclone MAX; jest to jedyny wymieniony na stronie Freescale dla seriali EA . Teraz przyznane, dla starszych Kinetis, takich jak KL0, lista jest znacznie dłuższa, w tym SEGGER . Nie wiem, czy to po prostu z powodu braku testowania innych flasherów dla serii EA, czy też jest jakieś dziwactwo programistyczne, o którym wie tylko ich Cyclone MAX. Miałem nadzieję, że to może być po prostu Freescale powolny na liście innych flasherów, ale po sprawdzeniu instrukcji J-link (miejmy nadzieję, że właściwy), nie ma tam testowanej serii Kinetis E lub EA (s. 249), ale tylko urządzenia Kinetis K10 do K60 (i niektóre starsze MAC7).

Warto zauważyć, że oprogramowanie / oprogramowanie PExDrv dla Cyclone MAX ma pakiet serwisowy (wersja 10.3) z dnia 3/20/2014, który „dodaje obsługę MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 i pochodnych SKEAZ128”. Kolejną wskazówką jest to, że własne oprogramowanie ładujące / flashloader Freescale dla Kinetis, mimo że zaktualizowano go jeszcze niedawno w 12/2014, nie wymieniono żadnych obsługiwanych urządzeń z serii E lub EA [pod]. Myślę więc, że istnieje coś wystarczająco odmiennego w flashowaniu między seriami E / EA a innymi Kinetis, takimi jak K10, chociaż nie mam pojęcia, czym dokładnie jest ta różnica. Dlatego myślę, że oczekiwanie, że flashowanie EA będzie działało automatycznie z czymkolwiek poza Cyclone MAX, jest prawdopodobnie nierealne w tym momencie. Być może będziesz w stanie dowiedzieć się, jak to zrobić na poziomie „gołego metalu” (polecenia rejestru bezpośredniego) z dokumentacji serii EA, ale zgadzam się, że dokumentacja jest dość tępa; z pewnością brakuje w nim instrukcji krok po kroku, które są jedynie instrukcją. Gdyby program ładujący / flashloader Freescale typu open source wspierał serię E / EA, „

Twój eksperyment z FRDM-KL25Z (który jest dostarczany z serią Kinetis L) wskazuje w tym samym kierunku, tzn. Nie możesz zamienić serii L na serię EA i użyć tego samego flashera (w tym przypadku OpenSDA).

A jeśli jesteś podobny do Keitha (blogera), który „uważa, że ​​programista 100 dolarów za programistę jest niedorzeczny”, prawdopodobnie nie będziesz zadowolony z perspektywy upuszczenia 900 $ na tym Cyklonie. Nie wiem, czy Freescale robi to specjalnie, by zamaskować swoich klientów z branży motoryzacyjnej, czy co ... Z pewnością wygląda dziwnie, że oprzyrządowanie dla większości serii Kinetis nie działa z E / EA.

Uważaj również, że funkcja flashowania OpenSDA działa najwyraźniej tylko w MS Windows .

Jeśli chcesz spróbować (zhakować) więcej kart, jedna z Kinetisami z serii E może być lepszym pomysłem, np. FRDM-KE02Z (13 USD w Digi-Key); używa również OpenSDA, więc może być hakerskie. O ile wiem, nie produkują / nie sprzedają desek z serii EA. Wydaje się jednak, że nie można użyć jednego procesora / płytki OpenSDA do zaprogramowania innego typu Kinetis niż ten na własnej płytce , nawet jeśli oba procesory należą do tej samej serii (np. L), ale mają różne numery. Niestety „Open” w OpenSDA oznacza tylko, że specyfikacja SDA jest otwarta, a nie to, że podają kod źródłowy jako open-source; więc nie mogę nawet znaleźć kodu źródłowego do zaprogramowania pamięci flash z serii E. Najwyraźniej mam rację tylko w połowie. OpenSDA v1 nie jest oprogramowaniem typu open source, ale v2 jest .

Oto lista zalet OpenSDAv2 . Jest to po prostu bootloader i flasher CMSIS-DAP / mbed. Więc może nie mieć tych samych funkcji lub obsługiwać tych samych układów co v1 ... i tak się dzieje, ponieważ flash_features.h nie wymienia żadnych MKE (seria E Kinetis), a tym bardziej SKE (seria EA) urządzenia. Podsumowując, propozycja Freescale dla serii EA wygląda następująco: kup nasz flasher Cyclone za 900 $ lub powodzenia w pisaniu własnych z dowolnych niekompletnych części open source, które wypuściliśmy.

Okazuje się jednak, że istnieje projekt open source, który może zaprogramować przynajmniej Kinetis z serii E, a mianowicie USBDM . Odpowiedni bit z jego dziennika zmian to:

V4.1.6.140 (kwiecień 2014 r.)

Dodatkowe urządzenia Kinetis (MKE04, MKE06, MK64F)

• Poprawki dla urządzeń MKE (programowanie nie powiodło się z wyjątkiem Mass Erase)

Na podstawie tego wpisu w dzienniku z pewnością wydaje się, że seria E jest dziwaczna. Nie ma bezpośredniego wsparcia dla serii EA (SKE), ale ta baza kodu jest prawdopodobnie najlepszym rozwiązaniem, jeśli chcesz zhakować własny flasher; a może uda Ci się przekonać autora USBDM do dodania obsługi serii EA (SKE). Okazuje się, że jako sprzęt dla USBDM można użyć już nabytego FRDM-KL25Z; ale nadal musisz włamać się do oprogramowania USBDM, aby obsługiwać układy SKE.

Plik konfiguracyjny zagospodarowania USBDM wygląda raczej trudne. W USDBM używane są różne flashery (podstawy kodu) dla różnych urządzeń z serii MKE: coś o nazwie „FTMRE” jest używane w MKE04 i MKE06, ale „FTMRH” jest używane w MKE02. Po krótkim spojrzeniu na dwie podstawy kodu prawie na pewno chcesz bazy kodu FTRMH, a nie FTRME. Ten ostatni ma inną strukturę FTMRH niż twoje urządzenie SKEA64, na przykład dzielnik zegara nie jest pierwszym, ale czwartym polem. FTRME ustawia również FIDV magistrali na 0x17 = 24 MHz, co wydaje się poza zakresem dla twojego układu (s. 224 w podręczniku KEA64 sugeruje maks. 20 MHz). FTMRH ustawia go na 0x0F = 16 MHz (tak jak ty), co wydaje się w porządku.

W tym momencie (chyba że chcesz kupić Cyclone MAX), najlepszym rozwiązaniem jest skontaktowanie się z Podonoghue, aby twój chip działał z jego bazą kodu. Wydaje się być aktywny i chętny do pomocy przy nowych urządzeniach (na forum Freescale) .

Również z tego kodu źródłowego USDBM mogę przepowiedzieć, że nie ma sposobu, aby Twój SEGGER mógł poprawnie flashować SKEA samodzielnie, chyba że najpierw otrzyma własną aktualizację oprogramowania układowego. Dlaczego to mówię? Ponieważ baza kodu FTMRH USDBM jest używana przez dokładnie jedno urządzenie, MKE02, o którym zdaje się, że Twój SEGGER nic nie wie (na podstawie instrukcji). Inne, bardziej powszechne urządzenia, takie jak seria Kinetis L i K, używają innego flashera USDBM opartego na bazie kodu „FTFA”. Jeśli spojrzysz na kod FTFA , struktura rejestru kontrolera flash (również zaczynająca się od 0x40020000) jest dla nich inna; pierwsze pole nie jest nawet dzielnikiem zegara, ale rejestrem statystyk itp. „Świetny” sposób Freescale na tworzenie niekompatybilnych urządzeń… ale bez wątpienia dobrodziejstwem dla twórców flasherów.

Czy próbowałeś tego: Odblokowanie i kasowanie FLASH za pomocą Segger J-Link

Podobno musisz:

Aby ponownie zaprogramować chronione sektory FLASH za pomocą Segger J-Link, najpierw muszę odblokować i masowo wymazać urządzenie. Do tego celu służy narzędzie J-Link Commander, które ma interfejs wiersza poleceń do odblokowania i usunięcia urządzenia. Tylko do usuwania, J-Flash (i Lite) jest bardzo przydatnym narzędziem, szczególnie do uzyskania „czystej” pamięci urządzenia.

Interesujące dla mnie jest to, że musisz je odblokować i usunąć w następnym kroku, jeśli chcesz, aby odblokowanie było trwałe:

Wygląda jednak na to, że muszę odblokować, a następnie usunąć, aby było trwałe. Aby usunąć urządzenie, mogę użyć tego samego narzędzia wiersza poleceń. Ale najpierw muszę podać nazwę urządzenia, a następnie mogę ją usunąć (przykład dla KL25Z):

EDYCJA 1: dodano nieprawidłowe dane.

EDIT2: czy możesz przeczytać rejestr Flash Security (FSEC)? Próbowałeś?

EDYCJA 3: Korzystanie z funkcji zabezpieczeń i ochrony pamięci flash Kinetis, Rev. 1, 6/2012

Kasowanie masowe poprzez Debugger / JTAG Debuggery i narzędzia JTAG mają bardzo ograniczony dostęp do urządzenia, gdy procesor jest zabezpieczony. Jedynymi rejestrami, do których można uzyskać dostęp za pośrednictwem JTAG, są rejestry stanu i kontroli MDM-AP. Aby umożliwić narzędziom debugującym niezabezpieczone części, bit 0 rejestru sterującego MDM-AP można ustawić tak, aby żądał masowego wymazania procesora. Aby użyć tej metody do wyłączenia zabezpieczeń, FSEC [MEEN] musi być ustawiony na wartość inną niż 10, aby umożliwić funkcję masowego wymazywania. Jeśli wymazywanie masowe jest wyłączone, FSEC [MEEN] = 10, wówczas żądanie wymazywania masowego zostanie zignorowane przez lampę błyskową i urządzenie nie będzie mogło zostać niezabezpieczone przy użyciu tej metody. Wiele debuggerów automatycznie używa bitu 2 rejestru stanu MDM-AP, aby ustalić, czy urządzenie jest zabezpieczone podczas próby nawiązania połączenia. Wyskakujące okienko debugera może być wykorzystane do ostrzeżenia, że ​​urządzenie jest zabezpieczone i zapytania, czy konieczne jest masowe wymazanie w celu niezabezpieczenia urządzenia. Po zakończeniu i weryfikacji masowego wymazywania zabezpieczenia zostaną wyłączone. Niektóre debugery mogą automatycznie zaprogramować pole konfiguracji pamięci flash, aby przełączyć pamięć flash w stan niezabezpieczony po zakończeniu kasowania masowego, FSEC = 0xFE.

Natknąłem się również na posty, w których wspominałem, że różne rodziny kinetis wymagają różnych manipulacji sygnałem RESET podczas próby odczytu / zapisu rejestru MDM-AP.

EDIT4: Czy próbowałeś dodać silne podciągnięcie na SWD_DIO? To strzał w ciemność, ale Freescale poleca to.

Najpierw musisz zatrzymać procesor. Oczywistym jest, że pojawia się objaw działania procesora. Używam openocd; przed flashowaniem urządzenia używam polecenia „reset halt”. To „zatrzymanie” jest podkomendą „reset”, do zatrzymania natychmiast po resecie, podczas gdy istnieje również samodzielne polecenie zatrzymania.

Poszukaj więc polecenia „resetuj zatrzymanie”, po prostu zatrzymanie nie wystarczy, ponieważ musisz przejść do stanu wstępnej inicjalizacji wektorów.

Nie widziałem jeszcze o tym wspomnianego, więc spekuluję, że problem polega na tym, że ta część ma pamięć podręczną, która jest włączona po zresetowaniu. Jest to zgodne z „dziwnym” zachowaniem zaobserwowanym podczas czeku in blanco. Podstawowa pamięć Flash została zaktualizowana, ale pamięć podręczna nie została zaktualizowana. Aby to naprawić, wyłącz pamięć podręczną danych i instrukcji, pisząc na adres MCM_PLACRat, F000_300Cha także wyczyść pamięć podręczną. To samo dziwne zachowanie prawdopodobnie również zdezorientowało Segger.

Ponieważ komunikat o błędzie dotyczy wartości komputera, wygląda na to, że procesor gdzieś zjeżdża z torów. To jest długa szansa, ale czy próbowałeś wyłączyć zegar kontrolny?