Freescale Kinetis KE - Schreiben in Flash

Ich kann eigentlich keine logischen Fehler in Ihrer Vorgehensweise finden, aber hier sind einige Vorschläge:

• es gibt auch ein FTMRH_FERSTAT-Register (bei 4002_0007h). Es soll Ihnen sagen, was schief gelaufen ist ... aber nur im Fall von Paritätsfehlern (oder doppelten Paritätsfehlern). Ich bin nicht davon überzeugt, dass dies im Falle von Fehlern etwas aufzeichnen oder löschen wird, aber es ist wahrscheinlich einen Besuch wert.

• die KEA-Dokumentation erwähnt auch, dass ein Interrupt durch Flash-Fehler ausgelöst werden kann (Abschnitt „18.3.5 Flash- und EEPROM-Interrupts“). Ich weiß nicht, ob das passiert, wenn der SEGGER es löscht, aber es ist eine plausible Erklärung dafür, warum sich der PC auch ändert, da Sie im FSTAT-Register Fehler angezeigt haben. Leider weist der KEA-Dokumentationsabschnitt für den Interrupt-Controller ("3.3.2 Nested Vectored Interrupt Controller (NVIC) configuration") ziemlich vage in die Richtung der ARM-Website für eine vollständige Dokumentation. Ich konnte nicht herausfinden, ob ein Standard-Interrupt-Handler (beim Booten) für Flash-Fehler eingerichtet ist.

• Sie haben Löschvorgänge nur manuell auf Sektorebene durchgeführt, versuchen Sie also, manuell (indem Sie das entsprechende Register selbst schreiben) einen vollständigen Flash-Löschbefehl auszugeben. Die einzige Möglichkeit, dies in einem einzigen Befehl zu tun, scheint der "Unsecure flash command" zu sein, der in Abschnitt 18.3.9.10 (S. 246) des Handbuchs dokumentiert ist. Dadurch wird sowohl das Gerät "ungesichert" als auch ein vollständiger Flash- und EEPROM-Löschvorgang durchgeführt. Sie können ein FSTAT-Bit (CCIF) abfragen, um zu sehen, wann es angeblich abgeschlossen ist, und die Fehlerflags danach erneut überprüfen. BEARBEITEN: Es gibt auch einen Abschnitt "18.3.9.7 Befehl "Alle Blöcke löschen"" im Handbuch, duh.

• Versuchen Sie es mit einer niedrigeren Bustaktfrequenz. Alles über 0,8 MHz funktioniert laut Dokumentation. Ich schlage dies vor, weil es einen Thread im Freescale-Forum gab, wo ein externer Blitz gut funktionierte, aber nicht über einer bestimmten Frequenz, die immer noch im ok-dokumentierten Bereich lag. Es ist also möglich, dass der Flash-Controller im Chip fehlerhaft ist und nicht im gesamten Bereich der angegebenen Frequenzen arbeiten kann.

• Ebenso hast du einen anderen Chip. Es ist nicht unvorstellbar, dass Sie angesichts dessen, wie viel diese kosten (ungefähr 3 US-Dollar), ein schlechtes haben. Ich erinnere mich, dass ich einen eingebetteten x86-Chip hatte, der in den meisten Fällen gut funktionierte, aber seltsame Fehler bei bestimmten Anweisungen im geschützten Modus aufwies. Mein Problem hat sich mit einem anderen Gerät des gleichen Herstellers erledigt. Es ist mir nicht klar, ob Freescale (öffentlich erklärte) Steppings und Errata für diese Geräte hat oder nicht.

Dies ist alles, was mir in Bezug auf Debugging-Vorschläge einfällt, die von anderen auf dieser Seite nicht gesagt wurden.

20150103 Bearbeitung(en):

(Material von meinen Kommentaren hierher verschoben & erweitert)

Es scheint, dass nicht alle Kinetis-Serien (zumindest offiziell) mit allen Flashern getestet wurden. Die ziemlich neue EA-Serie, die Sie tatsächlich verwenden, scheint offiziell nur von Freescales eigenem/OEM Cyclone MAX-Flasher unterstützt zu werden; Es ist das einzige, das auf der Seite von Freescale für die EA-Serien aufgeführt ist . Nun zugegeben, für ältere Kinetis wie KL0 ist die Liste viel länger, einschließlich eines SEGGER . Ich weiß nicht, ob das einfach daran liegt, dass andere Flasher für die EA-Serie nicht getestet wurden, oder ob es tatsächlich eine Programmiermasche gibt, von der derzeit nur ihr Cyclone MAX weiß. Ich hatte gehofft, dass dies vielleicht nur daran liegt, dass Freescale andere Flasher nur langsam auflistet, aber nachdem ich das J-Link-Handbuch überprüft habe(hoffentlich die richtige), dort ist auch keine Kinetis E oder EA Serie als getestet aufgeführt (S. 249), sondern nur Kinetis K10 bis K60 Geräte (und einige ältere MAC7's).

Erwähnenswert ist, dass die PExDrv-Software/Firmware für den Cyclone MAX ein Service Pack (v10.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 Kinetis, obwohl es in 12/2014 noch vor kurzem aktualisiert wurde, listet keine Geräte der E- oder EA-[Unter-]Serien als unterstützt auf. Ich denke also, dass es beim Flashen zwischen der E/EA-Serie und anderen Kinetis wie dem K10 einen ausreichenden Unterschied gibt, obwohl ich keine Ahnung habe, was genau dieser Unterschied ist. Daher denke ich, dass es zu diesem Zeitpunkt wahrscheinlich unrealistisch ist, zu erwarten, dass EA-Flashing automatisch mit irgendetwas anderem als dem Cyclone MAX funktioniert. Möglicherweise können Sie anhand der Dokumentation der EA-Serie herausfinden, wie dies auf "Bare-Metal" -Ebene (direkte Registerbefehle) geht, aber ich stimme zu, dass die Dokumentation ziemlich stumpf ist. Es fehlen sicherlich Schritt-für-Schritt-Anleitungen, da es sich nur um ein Referenzhandbuch handelt. Hätte der Open-Source-Bootloader/Flashloader von Freescale die E/EA-Serie unterstützt, hätten Sie

Ihr Experiment mit dem FRDM-KL25Z (das mit einer Kinetis L-Serie geliefert wird) weist in die gleiche Richtung, dh Sie können eine L-Serie nicht gegen eine EA-Serie tauschen und denselben Flasher (in diesem Fall OpenSDA) verwenden.

Und wenn Sie wie Keith (der Blogger) sind, der „100 Dollar für einen Programmierer für lächerlich hält“, wird Ihnen die Aussicht, mehr als 900 Dollar für diesen Cyclone zu verlieren, wahrscheinlich nicht gefallen. Ich weiß nicht, ob Freescale dies absichtlich tut, um seine Kunden aus der Automobilbranche zu trösten oder was... Es sieht sicherlich seltsam aus, dass die Werkzeuge für die meisten Kinetis-Serien nicht mit dem E/EA funktionieren.

Beachten Sie auch, dass die Flash-Funktion von OpenSDA anscheinend nur unter MS Windows funktioniert .

Wenn Sie bereit sind, mehr Boards auszuprobieren (zu hacken), ist eines mit einem Kinetis der E-Serie möglicherweise eine bessere Idee, z. B. FRDM-KE02Z ($ 13 bei Digi-Key); verwendet auch OpenSDA, so dass es möglicherweise gehackt werden kann. 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 seiner eigenen Karte zu programmieren , selbst wenn beide Prozessoren zur gleichen (z. B. L) Serie gehören, aber unterschiedliche Nummern haben. Leider bedeutet "Offen" in OpenSDA nur, dass die SDA-Spezifikation offen ist, nicht, dass sie den Quellcode als Open Source herausgeben; Daher kann ich nicht einmal den Quellcode finden, um einen Blitz der E-Serie zu programmieren. Anscheinend liege ich damit nur halb richtig. OpenSDA v1 ist nicht Open Source, aber v2 ist .

Hier also die Fakten zu OpenSDAv2 . Es ist im Grunde nur ein CMSIS-DAP/mbed Bootloader & Flasher. Es hat also möglicherweise nicht die gleichen Funktionen oder unterstützt nicht die gleichen Chips wie v1 ... und das stellt sich tatsächlich heraus, weil flash_features.h kein MKE (Kinetis E-Serie) auflistet, geschweige denn SKE (EA-Serie) Geräte. Zusammenfassend scheint Freescales Vorschlag für die EA-Serie zu sein: Kaufen Sie unseren 900-Dollar-Cyclone-Flasher oder viel Glück beim Schreiben Ihres eigenen aus allen unvollständigen Teilen von Open Source, die wir veröffentlicht haben.

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 seinem Changelog ist:

V4.1.6.140 (April 2014)

Zusätzliche Kinetis-Geräte (MKE04, MKE06, MK64F)

• Fehlerbehebungen für MKE-Geräte (Programmierung fehlgeschlagen, außer nach Mass Erase)

Und basierend auf diesem Protokolleintrag scheint es sicherlich, dass die E-Serie schrullig 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 vielleicht können Sie den Autor von USBDM davon überzeugen, Unterstützung für die EA-Serie (SKE) hinzuzufügen. Als Hardware für USBDM stellt sich heraus , dass Sie das bereits erworbene FRDM-KL25Z verwenden können; aber Sie müssen immer noch die USBDM-Software hacken, um die SKE-Chips zu unterstützen.

Die Master-Konfigurationsdatei für USBDM sieht ziemlich abschreckend aus. In USDBM werden verschiedene Flasher (Codebasen) für verschiedene Geräte der MKE-Serie verwendet: etwas namens "FTMRE" wird für MKE04 und MKE06 verwendet, aber "FTMRH" wird für MKE02 verwendet. Nachdem ich mir kurz die beiden Codebasen angesehen habe, 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, zum Beispiel ist der Taktteiler nicht das erste, sondern das 4. Feld. FTRME setzt auch den Bus-FIDV auf 0x17 = 24 MHz, was für Ihren Chip außerhalb des Bereichs zu liegen scheint (S. 224 im KEA64-Handbuch schlägt maximal 20 MHz vor). FTMRH setzt es auf 0x0F = 16 MHz (wie Sie es tun), 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 bereit zu sein, bei neuen Geräten zu helfen (im Freescale-Forum) .

Auch aus diesem USDBM-Quellcode kann ich prophezeien, dass Ihr SEGGER Ihren SKEA auf keinen Fall selbst korrekt flashen kann, es sei denn, es 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 anscheinend auch nichts weiß (basierend auf seinem Handbuch). Andere, gängigere Geräte wie die Kinetis L- und K-Serie verwenden einen anderen USDBM-Flasher, der auf einer „FTFA“-Codebasis basiert. Wenn Sie sich den Code von FTFA ansehen , ist die Registerstruktur des Flash-Controllers (ebenfalls beginnend bei 0x40020000) für diese unterschiedlich; Das erste Feld ist nicht einmal ein Taktteiler, sondern das Statistikregister usw. Eine "großartige" Möglichkeit für Freescale, inkompatible Geräte herzustellen ... aber ohne Zweifel ein Segen für Flasher-Hersteller.

Haben Sie dies versucht: Entsperren und Löschen von FLASH mit Segger J-Link

Angeblich muss man:

Um die geschützten FLASH-Sektoren mit Segger J-Link neu zu programmieren, muss ich das Gerät zuerst entsperren und massenweise löschen. Dafür gibt es das Dienstprogramm J-Link Commander, das über eine Befehlszeilenschnittstelle verfügt, um den Schutz aufzuheben und das Gerät zu löschen. Nur zum Löschen ist J-Flash (und Lite) ein sehr nützliches Werkzeug, insbesondere um einen "sauberen" Gerätespeicher zu erhalten.

Was ich interessant fand, ist, dass Sie es entsperren und im nächsten Schritt löschen müssen, wenn Sie möchten, dass die Entsperrung dauerhaft ist:

Aber es scheint, dass ich ein Unlock machen muss, gefolgt von einem Löschen, um es dauerhaft zu machen. Um das Gerät zu löschen, kann ich dasselbe Befehlszeilenprogramm verwenden. Aber ich muss zuerst den Gerätenamen angeben, und dann kann ich ihn löschen (Beispiel für die KL25Z):

EDIT1: falsche Daten hinzugefügt.

EDIT2: Kannst du vielleicht das Flash Security (FSEC) Register lesen? Hast du versucht?

EDIT3: aus Using the Kinetis Security and Flash Protection Features, Rev. 1, 6/2012

Massenlöschung über Debugger/JTAG Debugger und JTAG-Tools haben nur sehr eingeschränkten Zugriff auf das Gerät, wenn ein Prozessor gesichert ist. Die einzigen Register, auf die über den JTAG zugegriffen werden kann, sind die MDM-AP-Status- und Steuerregister. Damit Debug-Tools Teile unsicher machen können, kann Bit 0 des MDM-AP-Steuerregisters gesetzt werden, um eine Massenlöschung des Prozessors anzufordern. Um diese Methode zum Deaktivieren der Sicherheit zu verwenden, muss FSEC[MEEN] auf einen anderen Wert als 10 gesetzt werden, um die Fähigkeit zum Massenlöschen zu ermöglichen. Wenn die Massenlöschung deaktiviert ist, FSEC[MEEN] = 10, wird die Massenlöschanforderung vom Flash ignoriert und das Gerät kann mit dieser Methode nicht entsichert werden. Viele Debugger verwenden automatisch Bit 2 des MDM-AP-Statusregisters, um festzustellen, ob ein Gerät gesichert ist, wenn sie versuchen, eine Verbindung herzustellen. Ein Debugger-Popup-Fenster kann verwendet werden, um darauf hinzuweisen, dass das Gerät gesichert ist, und zu fragen, ob eine Massenlöschung erwünscht ist, um das Gerät zu entsichern. Sobald die Massenlöschung abgeschlossen und verifiziert ist, wird die Sicherheit deaktiviert. Einige Debugger programmieren möglicherweise automatisch das Flash-Konfigurationsfeld, um den Flash nach Abschluss der Massenlöschung in einen ungesicherten Zustand zu versetzen, FSEC = 0xFE.

Außerdem bin ich über einen Beitrag gestolpert, in dem erwähnt wird, dass verschiedene Kinetis-Familien unterschiedliche RESET-Signalmanipulationen erfordern, wenn versucht wird, das MDM-AP-Register zu lesen/schreiben.

EDIT4: Haben Sie versucht, SWD_DIO einen starken Pull-up hinzuzufügen? Es ist ein Schuss ins Blaue, aber Freescale empfiehlt es.

Sie müssen den Prozessor zuerst anhalten. Es ist offensichtlich, dass Sie ein Symptom eines laufenden Prozessors erhalten. Ich verwende openocd; Vor dem Flashen des Geräts verwende ich den Befehl "reset halt". Dieses "halt" ist ein Unterbefehl von "reset", um unmittelbar nach dem Zurücksetzen anzuhalten, während es auch einen eigenständigen Halt-Befehl gibt.

Suchen Sie also nach einem Befehl zum Zurücksetzen des Halts. Nur ein Halt reicht nicht aus, da Sie den Zustand der Vorinitialisierung von Vektoren erreichen müssen, denke ich.

Ich habe es noch nicht erwähnt gesehen, also gehe ich weiter und spekuliere, dass das Problem darin besteht, dass dieser Teil einen Cache hat, der beim Zurücksetzen aktiviert ist. Dies stimmt mit dem "seltsamen" Verhalten überein, das Sie beim Blankoscheck beobachtet haben. Der zugrunde liegende Flash wurde aktualisiert, der Cache jedoch nicht. Um dies zu beheben, schalten Sie sowohl den Daten- als auch den Anweisungscache aus, indem Sie in MCM_PLACRat schreiben, F000_300Chund leeren Sie dabei auch den Cache. Dieses seltsame Verhalten dürfte auch den Segger verwirrt haben.

Da es in der Fehlermeldung um den PC-Wert geht, hört es sich so an, als würde die CPU irgendwo aus den Fugen geraten. Das ist ein langer Schuss, aber haben Sie versucht, den Watchdog-Timer zu deaktivieren?