Ich benutze seit vielen, vielen Jahren verschiedene Mikrocontroller und Mikroprozessoren, aber die Kinetis KE-Serie (speziell die S9KEAZN64AMLC) scheint mich zu behindern.
17. Januar 2015 TL; DR:
Freescale bestätigt, dass Version 2.0.0 der Kinetis Design Studio-Software nicht mit diesem Gerät funktioniert (einschließlich der eigenen TRK-KEA64-Evaluierungskarte). Sie empfehlen vorerst die Verwendung von CodeWarrior MCU V10.6.
Segger hat v4.96a veröffentlicht (das "a" ist wichtig, ich habe v4.96 verwendet), das das Problem behebt und es Ihnen ermöglicht, ein Segger J-Link Lite CortexM-Debugger-Board mit KDS zu verwenden und über vollständige Programm- / Debug-Funktionen zu verfügen.
Bevor Segger v4.96a veröffentlichte, gelang es mir, den Chip zu flashen, indem ich den OpenSDA-Debugger auf Freescales kostengünstigem (15 US-Dollar) FRDM-KL25Z-Evaluierungsboard neu programmierte, indem ich die OpenSDA-Firmware, die mit USBDM geliefert wurde, erneut flashte (unter Verwendung von v4.10.6.240). Ich habe dann USBDMs eigenständige "ARM Programmer" Software verwendet. Ich habe nicht viel Zeit damit verbracht, das Debuggen zum Laufen zu bringen, da ich das Debuggen von "oldschool" so gut beherrsche, dass ich es nicht brauche. Stellen Sie sicher, dass Sie ein "harmloses" Programm in das On-Board-Target KL25 flashen, da die Reset-Leitung des On-Board-Targets KL25 auch mit J11-Cut noch mit dem OpenSDA-Debugger verbunden ist (siehe Keith Wakehams Blogpost) , weiter unten verlinkt).
Ein großes Dankeschön an Erich Styger für die freundliche Unterstützung bei der Ermittlung des Problems und der Bestätigung meiner Ergebnisse per E-Mail.
Nun zurück zu unserer regulären Frage:
Ich habe ein dumm-einfaches 3.3V Breakout Board gebaut. Es hat einige LEDs auf PTA, eine UART-Verbindung auf PTC und die SWD-Leitungen sind auf ihren Standleitungen. Es gibt buchstäblich nichts Besonderes oder Lustiges an diesem Board.
Ich verwende ein J-Link Lite für Cortex-M (J-Link LITE CortexM-9, siehe https://www.segger.com/jlink-lite-cortexm.html ) und unter OSX und Windows bekomme ich das Gleiches Ergebnis: Das Dienstprogramm J-Link Commander kann den Chip identifizieren, ich kann in SRAM lesen und schreiben und mit den Peripheriegeräten spielen, wobei manuelle Lese- und Schreibvorgänge an die richtige speicherabgebildete E / A-Adresse erfolgen. Wenn ich versuche, das Gerät zu flashen, schlägt dies jedoch fehl.
$ 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.
Das J-Link Lite ist vollkommen in Ordnung (ich kann mit dem nRF58122 SoC, einem anderen Cortex-M0-Prozessor, lesen und schreiben) und das Gerät scheint ansonsten zu funktionieren. Ich weiß, dass der Kinetis entsperrt ist, da er von DigiKey fabrikneu ist, aber selbst dann läuft der Befehl "kinetis unlock" in JLinkExe ohne Fehler oder nützliche Informationen ab.
Zu diesem Zeitpunkt bin ich sicher, dass ich etwas Dummes mache, aber ich bin ratlos, was es sein könnte.
Hat schon jemand mit diesen Geräten gearbeitet? Wie programmierst du sie?
Bearbeiten, um eine exemplarische Vorgehensweise hinzuzufügen:
Weitere Informationen:
Ich habe gelesen, dass der NMI # -Pin beim Zurücksetzen aktiviert ist (und dies durch Lesen von SIM_SOPT überprüft wurde), aber auch, dass er bei Aktivierung ein internes Pull-up aufweist. In diesem speziellen Teil befindet sich die PTB4 an Pin 10, der in meinem Design ein No-Connect ist. Das Deaktivieren des NMI-Pins macht keinen Unterschied. RST # ist ähnlich; Es ist mit einem Druckknopf verbunden, der den Stift erdet und auch an den J-Link Lite geht, aber es gibt kein externes Pullup. Dies sollte keine Rolle spielen, da der RST # -Pin wie NMI # über ein internes Pullup verfügt, das aktiviert wird, wenn PTA5 als Reset konfiguriert ist.
Mit Blick auf die Taktung jetzt ... Nach dem Zurücksetzen ist ICS die Taktquelle für die FLL und BDIV in ICS_C2 ist auf 001 eingestellt (die Standardeinstellung für das Zurücksetzen). Wenn ich das richtig verstehe, bedeutet dies, dass der interne 32-kHz-Oszillator mit 1024 multipliziert und dann durch 2 geteilt wird, was ICSOUTCLK zu 32 kHz * 1024/2 oder 16,8 MHz macht. Ich kann über die J-Link-CLI überprüfen, ob die FLL gesperrt ist, indem ich ICS_S lese:
J-Link>mem8 40064004 1
40064004 = 50
(LOCK und IREFST sind gesetzt, das ist richtig.)
Ich gehe dann weiter, um zu überprüfen, ob auf der SIM die Uhr für den Flash-Controller aktiviert ist, indem ich SIM_SCGC lese. Ich kann auch schnell überprüfen, ob BUSDIV in SIM_BUSDIV auf Null gesetzt ist, was bedeutet, dass BUSCLK dieselbe Frequenz hat wie ICSOUTCLK (dh es wird nicht heruntergeteilt):
J-Link>mem32 4004800c 1
4004800C = 00003000
J-Link>mem32 40048018 1
40048018 = 00000000
Bisher sieht alles gut aus. BUSCLK ist 16,8 MHz und der Takt des Flash-Controllers wird nicht gesteuert.
Gehen wir nun zum Flash-Controller über. Out of Reset FCLKDIV ist Null, und wir benötigen einen 1-MHz-Takt. Tabelle 18-2 in KEA64RM zeigt, dass FDIV auf 0x10 gesetzt werden sollte.
Out of Reset:
J-Link>mem8 40020000 1
40020000 = 00
Das Einrichten des Teilers und das Überprüfen von Dingen sind gut:
J-Link>w1 40020000 10
Writing 10 -> 40020000
J-Link>mem8 40020000 1
40020000 = 90
FDIVLD wird gesetzt und der korrekte Wert in FDIV angezeigt.
Bevor Sie zu weit gehen, stellen Sie sicher, dass der Blitz nicht geschützt ist:
J-Link>mem8 40020001 1
40020001 = FE
KEYEN = 11 (deaktiviert) und SEC = 10 (ungesichert). In Ordnung. Lassen Sie uns überprüfen, ob das Gerät leer ist:
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
Hier sehen wir, dass die MGSTAT-Bits in FSTAT anzeigen, dass die Leerprüfung fehlgeschlagen ist und dass auch nicht korrigierbare Fehler gefunden wurden. Seltsam. Versuchen wir es selbst zu löschen:
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
Der Befehl Alle löschen war erfolgreich. Versuchen wir jetzt einen Blankoscheck:
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
Jetzt ist der Blankoscheck in Ordnung?
An diesem Punkt bin ich bereit aufzugeben, den Verlust dieser Prototypen aufzuzehren und mit einem Prozessor von ST zu arbeiten, bei dem ich noch nie zuvor solche Probleme hatte. Die Kinetis-Dokumentation ist gründlich genug, aber sehr umfangreich und ich finde es sehr schwierig, damit anzufangen. Ich kann E / A durch Speicherlesevorgänge wackeln und auf andere Peripheriegeräte zugreifen, aber ich kann für mein ganzes Leben nicht herausfinden, was mit dem Flash-Controller nicht stimmt. Ich arbeite seit über 20 Jahren mit Mikros und diese Art von Schwierigkeiten habe ich noch nie erlebt.
20150102 bearbeiten:
Also immer noch nicht hingehen. Ich habe tatsächlich ein FRDM-KL25Z-Evaluierungsboard gekauft (15 USD von DigiKey) und es modifiziert, indem ich die generische CMSIS-DAP-Software in den OpenSDA-Debugger gestellt und J11 gemäß Keith Wakehams Blog geschnitten habe . Ich habe ein On-Board-Target (die KL25Z), das ein einfaches Programm ausführt, damit es die Reset-Leitung nicht stört, und ich kann mein SKEAZN64 mit OpenOCD sehen und damit spielen, aber leider kann es es auch nicht programmieren. Die Kinetis Design Studio (KDS) -Software lässt mein Kinetis nicht flashen, da sie als geschützt eingestuft wird und ich einen Massenlöschvorgang durchführen muss, aber OpenOCD (als Teil von KDS) scheint nicht zu wissen, wie das geht. Die Git-Master-Version von OpenOCD, die ich auf meinem Mac erstellt habe, versteht Kinetis, aber nicht die spezifische KEA-Serie.
Zurück zum J-Link ...
@AdamHaun hatte eine wirklich gute Ahnung, und wenn ich den J-Link-Reset-Typ (Befehl rsettype) auf '6' (Kinetis) setze, soll J-Link den Watchdog nach dem Zurücksetzen des Cores deaktivieren. Betrachtet man das WDOG_CS1-Register (0x40052000), so scheint dies der Fall zu sein, aber es gibt immer noch keine Würfel. Ein Löschvorgang scheint mit dem PC um 0xfffffffe und dem Fehlercode -5 nicht mehr möglich zu sein, und der Befehl "unlock kinetis" funktioniert nur, wenn ich den Reset-Pin mit SIM_SOPT deaktiviere (indem ich den 32-Bit-Wert 0x00000008 auf 0x40048004 schreibe). Wenn ich das tue, kann die CPU leider nie wieder angehalten werden, vermutlich weil die SWD-Schnittstelle die Rücksetzleitung nicht verwenden kann, um den SWD-DAP in einen bekannten Zustand zu zwingen.
20150103 bearbeiten:
Ich habe blinkende LED
WIEDERHOLEN
Ich habe blinkende LED
TL; DR-Version: Legen Sie das USBDM-Image auf die FRDM-KL25Z-Platine (eine Geschichte für sich), und senden Sie den Test mithilfe der eigenständigen ARM Programmer-App an die Platine. Power Cycle und Voilà.
Lange Version wird später kommen. Ich habe jetzt weniger als 48 Stunden Zeit, um Software für dieses KEAZN64-Board zu schreiben und zu debuggen, das Ändern / Testen anderer dazugehöriger Software abzuschließen und an einigen Dokumentationen für einen anderen Client zu arbeiten. Ich verspreche, dass ich diese Frage mit einer detaillierten Antwort aktualisieren werde . Ich wollte nur meinen Erfolg teilen. Vielen Dank für Ihre Hilfe. Möglicherweise muss ich mit den Mods sprechen, weil ich die Bounty besonders gerne einigen von euch geben würde.
Antworten:
Ich kann keine logischen Fehler in Ihrem Verfahren finden, aber hier sind einige Vorschläge:
Es gibt auch ein FTMRH_FERSTAT-Register (bei 4002_0007h). Es soll Ihnen sagen, was falsch gelaufen ist ... aber nur im Fall von Parität (oder Doppelparitätsfehlern). Ich bin nicht davon überzeugt, dass dies alles aufzeichnet, falls Fehler auftreten oder gelöscht werden, aber es lohnt sich wahrscheinlich, es zu überprüfen.
In der KEA-Dokumentation wird auch erwähnt, dass ein Interrupt durch Flash-Fehler ausgelöst werden kann (Abschnitt "18.3.5 Flash- und EEPROM-Interrupts"). Ich weiß nicht, ob dies der Fall ist, wenn der SEGGER ihn löscht, aber es ist eine plausible Erklärung, warum sich auch der PC ändert, da Sie Fehler im FSTAT-Register festgestellt haben. Leider zeigt der KEA-Dokumentationsabschnitt für den Interrupt-Controller ("3.3.2 NVIC-Konfiguration (Nested Vectored Interrupt Controller)") vage in Richtung der ARM-Website, um eine vollständige Dokumentation zu erhalten. Ich konnte nicht herausfinden, ob ein standardmäßiger Interrupt-Handler (beim Booten) für Flash-Fehler eingerichtet ist.
Sie haben nur Löschvorgänge auf Sektorebene manuell ausgeführt. Versuchen Sie daher, manuell (wie beim Schreiben des entsprechenden Registers) einen vollständigen Flash-Löschbefehl auszugeben. Die einzige Möglichkeit, dies in einem einzigen Befehl zu tun, scheint der in Abschnitt 18.3.9.10 (S. 246) des Handbuchs dokumentierte "Unsecure Flash" -Befehl zu sein. Dadurch wird sowohl das Gerät "entsichert" als auch ein vollständiger Flash- und EEPROM-Löschvorgang durchgeführt. Sie können ein FSTAT-Bit (CCIF) abfragen, um festzustellen, wann es voraussichtlich abgeschlossen ist, und anschließend die Fehlerflags erneut überprüfen. BEARBEITEN: Es gibt auch einen Abschnitt "18.3.9.7 Alle Blöcke löschen" im Handbuch, duh.
versuchen Sie es mit einer niedrigeren Bustaktfrequenz. Alles über 0,8 Mhz funktioniert gemäß der Dokumentation. Ich schlage dies vor, weil es einen Thread im Freescale-Forum gab, in dem ein externer Flash einwandfrei funktioniert hat, aber nicht über einer bestimmten Frequenz, die noch im ok-dokumentierten Bereich liegt. Es ist also möglich, dass der Flash-Controller im Chip ein Flakey ist und nicht mit dem gesamten angegebenen Frequenzbereich arbeiten kann.
Ebenso bist du ein anderer Chip. Es ist nicht unvorstellbar, dass Sie angesichts der Kosten (um die 3 US-Dollar) einen schlechten Preis haben. Ich erinnere mich, dass ich einen eingebetteten x86-Chip hatte, der in den meisten Fällen einwandfrei funktionierte, aber bei bestimmten Anweisungen im geschützten Modus seltsame Fehler aufwies. mein problem ging mit einem anderen gerät der gleichen marke weg. Mir ist nicht klar, ob Freescale (öffentlich bekannt gegebene) Steppings und Errata für diese Geräte hat oder nicht.
Dies ist alles, woran ich denken kann, wenn ich Vorschläge zum Debuggen mache, die von anderen auf dieser Seite nicht erwähnt wurden.
20150103 Bearbeitung (en):
(Verschobenes Material hier aus meinen Kommentaren & erweitert)
Es scheint, dass nicht alle Kinetis-Serien (zumindest offiziell) mit allen Blitzgeräten getestet wurden. Die relativ neue EA-Serie, die Sie tatsächlich verwenden, scheint offiziell nur vom Freescale-eigenen / OEM Cyclone MAX-Blinker unterstützt zu werden. Es ist das einzige, das auf Freescales Seite für die EA-Serien aufgeführt ist . Nun ist die Liste für ältere Kinetis wie KL0 viel länger, einschließlich eines SEGGER . Ich weiß nicht, ob dies einfach daran liegt, dass andere Blinker für die EA-Serie nicht getestet wurden, oder ob es sich tatsächlich um eine Programmiersprache handelt, die derzeit nur der Cyclone MAX kennt. Ich hatte gehofft, dass dies vielleicht nur darauf zurückzuführen ist, dass Freescale andere Blinker nur langsam auflistet, aber beim Überprüfen der J-Link-Handbuch gelesen habe (hoffentlich die richtige), es gibt dort auch keine getesteten Kinetis E- oder EA-Serien (S. 249), sondern nur Kinetis K10 bis K60-Geräte (und einige ältere MAC7).
Erwähnenswert ist, dass die PExDrv-Software / -Firmware für den Cyclone MAX ein Service Pack (Version 10.3) vom 20.03.2014 enthält, das "Unterstützung für MKE04Z64-, MKE04Z128-, MKE06Z64-, MKE06Z128-, SKEAZ64- und SKEAZ128-Derivate hinzufügt". Ein weiterer Hinweis ist die Open-Source- Bootloader / Flashloader-Software von Freescale für den KinetisObwohl es in letzter Zeit in 12/2014 noch aktualisiert wurde, werden keine Geräte der E- oder EA-Serie [sub] als unterstützt aufgeführt. Ich denke also, dass es einen Unterschied zwischen der E / EA-Serie und anderen Kinetis wie dem K10 gibt, obwohl ich keine Ahnung habe, was genau dieser Unterschied ist. Daher denke ich, dass die Erwartung, dass das EA-Flashen mit etwas anderem als dem Cyclone MAX automatisch funktioniert, an dieser Stelle wahrscheinlich unrealistisch ist. Möglicherweise können Sie anhand der Dokumentation der EA-Serie herausfinden, wie dies auf "Bare-Metal" -Ebene (Direktregisterbefehle) zu tun ist, aber ich stimme zu, dass die Dokumentation ziemlich stumpf ist. Es fehlt sicherlich jede Schritt-für-Schritt-Anleitung, die nur ein Referenzhandbuch ist. Hätte Freescales Open-Source-Bootloader / Flashloader die E / EA-Serie unterstützt, hätten Sie
Ihr Experiment mit dem FRDM-KL25Z (das mit einer Kinetis L-Serie geliefert wird) zeigt in die gleiche Richtung, dh Sie können eine L-Serie nicht mit einer EA-Serie tauschen und denselben Blinker verwenden (in diesem Fall OpenSDA).
Und wenn Sie wie Keith (der Blogger) sind, der "100 Dollar für einen Programmierer für lächerlich hält", werden Sie wahrscheinlich nicht mit der Perspektive zufrieden sein, über 900 Dollar für diesen Zyklon zu verlieren. Ich weiß nicht, ob Freescale dies absichtlich tut, um die Kunden in der Automobilbranche mit Vlies zu versorgen, oder was?
Beachten Sie auch, dass die Flashing-Funktion von OpenSDA anscheinend nur unter MS Windows funktioniert .
Wenn Sie mehr Boards ausprobieren (hacken) möchten, ist eines mit Kinetis der E-Serie möglicherweise eine bessere Idee, z. B. FRDM-KE02Z (13 US-Dollar bei Digi-Key). verwendet auch OpenSDA, so dass es möglicherweise hackbar ist. Sie machen / verkaufen keine Boards mit der EA-Serie, soweit ich das beurteilen kann. Es scheint jedoch, dass Sie nicht einen OpenSDA-Prozessor / eine OpenSDA-Karte verwenden können, um einen anderen Kinetis-Typ als den auf der eigenen Karte zu programmieren , selbst wenn beide Prozessoren der gleichen (z. B. L) Serie, aber mit unterschiedlichen Nummern sind.
Leider bedeutet "Open" in OpenSDA nur, dass die SDA-Spezifikation offen ist, nicht, dass sie den Quellcode als Open Source ausgibt. Daher kann ich nicht einmal den Quellcode finden, mit dem ein Flash der E-Serie programmiert werden kann.Anscheinend habe ich da nur halb recht. OpenSDA v1 ist nicht Open Source, aber v2 ist es .Also hier ist der Lowdown zu OpenSDAv2 . Es ist im Grunde nur ein CMSIS-DAP / mbed Bootloader & Flasher. Es kann also sein, dass es nicht die gleichen Funktionen hat oder die gleichen Chips wie v1 unterstützt ... und das stellt sich tatsächlich als der Fall heraus, da flash_features.h keine MKE (Kinetis E-Serie) auflistet, geschweige denn SKE (EA-Serie). Geräte. Zusammenfassend scheint Freescales Vorschlag für die EA-Serie zu lauten: Kaufen Sie unseren 900-Dollar-Cyclone-Flasher, oder wünschen Sie viel Glück beim Schreiben Ihrer eigenen, von uns veröffentlichten unvollständigen Open Source-Dateien.
Es stellt sich jedoch heraus, dass es ein Open-Source-Projekt gibt, das zumindest die Kinetis der E-Serie programmieren kann, nämlich USBDM . Das relevante Bit aus dem Changelog ist:
Und basierend auf diesem Protokolleintrag scheint es, dass die E-Serie skurril ist. Es gibt keine direkte Unterstützung für die EA-Serie (SKE), aber diese Codebasis ist wahrscheinlich die beste Wahl, wenn Sie Ihren eigenen Flasher hacken möchten. Oder Sie können den Autor von USBDM davon überzeugen, die EA-Serie (SKE) zu unterstützen. Als Hardware für USBDM hat sich herausgestellt, dass Sie den bereits erworbenen FRDM-KL25Z verwenden können. Sie müssen jedoch immer noch die USBDM-Software hacken, um die SKE-Chips zu unterstützen.
Die Master-Konfigurationsdatei für USBDM sieht ziemlich entmutigend aus. In USDBM werden verschiedene Blinker (Code-Basen) für verschiedene Geräte der MKE-Serie verwendet: "FTMRE" wird für MKE04 und MKE06 verwendet, "FTMRH" wird für MKE02 verwendet. Nach einem kurzen Blick auf die beiden Codebasen möchten Sie mit ziemlicher Sicherheit die FTRMH-Codebasis und nicht die FTRME-Codebasis. Letzteres hat eine andere FTMRH-Struktur als Ihr SKEA64-Gerät. Beispielsweise ist der Taktteiler nicht das erste, sondern das vierte Feld. FTRME setzt auch den Bus FIDV auf 0x17 = 24Mhz, was für Ihren Chip nicht in Reichweite zu sein scheint (S. 224 im KEA64-Handbuch schlägt max. 20Mhz vor). FTMRH setzt es auf 0x0F = 16Mhz (wie Sie), was in Ordnung zu sein scheint.
An diesem Punkt (es sei denn, Sie möchten den Cyclone MAX kaufen) wenden Sie sich am besten an Podonoghue, damit Ihr Chip mit seiner Codebasis funktioniert. Er scheint aktiv und sehr hilfsbereit zu sein (im Freescale-Forum) .
Auch aus diesem USDBM-Quellcode kann ich voraussagen, dass Ihr SEGGER Ihren SKEA auf keinen Fall selbst korrekt flashen kann, es sei denn, er erhält zuerst ein eigenes Firmware-Update. Warum sage ich das? Da die FTMRH-Codebasis von USDBM dort von genau einem Gerät verwendet wird, dem MKE02, von dem Ihr SEGGER scheinbar auch nichts weiß (basierend auf seinem Handbuch). Andere, gebräuchlichere Geräte wie die Kinetis L- und K-Serie verwenden einen anderen USDBM-Blinker, der auf einer FTFA-Codebasis basiert. Wenn Sie sich den FTFA-Code ansehen , unterscheidet sich die Flash-Controller-Register-Struktur (ebenfalls beginnend mit 0x40020000) für diese; Das erste Feld ist nicht einmal ein Taktteiler, sondern das Statistikregister usw. "Großartige" Möglichkeit für Freescale, inkompatible Geräte herzustellen ... aber zweifellos ein Segen für Blinkerhersteller.
quelle
Haben Sie Folgendes versucht: FLASH mit Segger J-Link entsperren und löschen
Angeblich musst du:
Was ich interessant fand, ist, dass Sie es entsperren und im nächsten Schritt löschen müssen, wenn das Entsperren dauerhaft sein soll:
EDIT1: falsche Daten hinzugefügt.
EDIT2: kannst du vielleicht das Flash Security (FSEC) Register lesen? Hast du versucht?
EDIT3: Aus der Verwendung der Kinetis-Sicherheits- und Flash-Schutzfunktionen, Rev. 1, 6/2012
Außerdem bin ich auf Beiträge gestoßen, in denen erwähnt wurde, dass verschiedene Kinetis-Familien unterschiedliche RESET-Signalmanipulationen erfordern, wenn versucht wird, das MDM-AP-Register zu lesen / schreiben.
EDIT4: Haben Sie versucht, SWD_DIO mit einem starken Pull-up zu versehen? Es ist ein Schuss im Dunkeln, aber Freescale empfiehlt es.
quelle
Sie müssen zuerst den Prozessor anhalten. Es ist offensichtlich, dass Sie ein Symptom für einen laufenden Prozessor bekommen. Ich benutze openocd; Vor dem Flashen des Geräts verwende ich den Befehl "Halt zurücksetzen". Dieses "Anhalten" ist ein Unterbefehl von "Zurücksetzen", um unmittelbar nach dem Zurücksetzen anzuhalten, während es auch einen eigenständigen Anhalten-Befehl gibt.
Suchen Sie also nach einem "reset halt" -Befehl. Nur ein Halt wird nicht ausreichen, da Sie den Zustand der Vorinitialisierung von Vektoren erreichen müssen, denke ich.
quelle
Ich habe es noch nicht erwähnt gesehen, also gehe ich voran und spekuliere, dass das Problem darin besteht, dass dieser Teil einen Cache hat, der beim Zurücksetzen aktiviert wird. Dies steht im Einklang mit dem "seltsamen" Verhalten, das Sie beim Blankoscheck beobachtet haben. Das zugrunde liegende Flash wurde aktualisiert, der Cache jedoch nicht. Um dies zu beheben, deaktivieren Sie sowohl den Daten- als auch den Anweisungscache, indem Sie in schreiben
MCM_PLACRatF000_300Chund leeren Sie dabei auch den Cache. Dasselbe seltsame Verhalten dürfte auch den Segger verwirrt haben.quelle
Da es sich bei der Fehlermeldung um den PC-Wert handelt, hört sich an, als würde die CPU irgendwo aus dem Ruder laufen. Dies ist ein langer Versuch, aber haben Sie versucht, den Watchdog-Timer zu deaktivieren?
quelle