Wie würde JTAG eine MCU mit Flash-Speicher programmieren? Mir ist klar, dass dies wahrscheinlich von Chip zu Chip unterschiedlich ist, aber ich gehe davon aus, dass es einen Prozess gibt, den sie alle gemeinsam haben. Insbesondere frage ich in Bezug auf den LPC1768, der im Datenblatt nicht angibt, wie Sie dies tun würden.
Wie würde JTAG eine MCU mit Flash-Speicher programmieren?
In den meisten MCUs ist JTAG nicht direkt mit Flash verbunden. Es gibt tatsächlich einen Stapel von Zugriffsmethoden, jede mit ihrem Protokoll. Ein Debugger / systeminterner Programmierer muss mit allen "sprechen", um tatsächlich den Flash zu erreichen.
Insbesondere frage ich in Bezug auf den LPC1768
LPCs basieren auf ARM Cortex-M. Sie nutzen die Debug-Infrastruktur von ARM . Der Weg von JTAG zu Flash ist:
JTAG -> JTAG-DP -> AHB-AP -> Haupt-AHB-Bus -> Flash
Aber diesen direkten Weg werden wir eigentlich nicht gehen. LPCs stellen die Blinkfunktion über IAP bereit.
Lassen Sie uns die Schritte im Detail beschreiben:
JTAG ist der übliche Name für ein Drahtprotokoll, das eine Kette von TAPs (Test Access Ports) über 4 Drähte (TCK TMS TDI TDO) verfügbar macht. Eine JTAG-Kette ist eine große Kette von Schieberegistern mit einer standardisierten Methode zum Auswählen der Register jedes TAP und zum Zugreifen auf den Registerwert. TAPs können einen beliebigen Satz von Registern beliebiger Größe verfügbar machen.
JTAG-DP (JTAG Debug Port) ist ein von ARM spezifizierter TAP, der hauptsächlich zwei 32-Bit-Register namens DPACC und APACC (tatsächlich 35 Bit, wegen der Verkettung mit 3 Operationsbits) verwendet, die den Zugriff auf AP und DP ermöglichen. Dies ist der Einstiegspunkt für das ARM-Debug-Modell.
Der Debug-Port von ARM ist ein Gateway zu Zugriffsports. Zugriffsports legen die Schnittstelle für etwas anderes offen. DP kann Zugriffe auf 256 APs multiplexen. Die meisten MCUs im LPC-Bereich enthalten nur einen AP, der Zugriff auf die interne AHB (Amba Host Bridge) gewährt, dh die interne Schaltmatrix, die die CPU und alle anderen IPs miteinander verbindet. (Nun, eigentlich ist AHB-AP nicht direkt mit dem Hauptbus verbunden, sondern geht zu einem Debug-Bus, der eng mit der CPU gekoppelt ist, siehe Cortex-Designdokumente für blutige Details).
Das Design von ARM für das Cortex-M-Debugging ist speicherbasiert: Die Debugger-Schnittstelle ermöglicht den Zugriff auf den Speicher (Adresse + Daten, Lesen/Schreiben usw.), und die CPU-Debug-Verwaltung (Anhalten, Überprüfen von Registern usw.) erfolgt über Speicherzuordnung Register, auf die über die Speicherschnittstelle zugegriffen werden kann (siehe Kapitel 10 in Cortex-M3 TRM ).
Wenn wir dort ankommen, haben wir Zugriff auf den Hauptspeicherbus und können die CPU steuern. Über den Speicherbus haben wir Zugriff auf alle internen IPs, als ob wir Code von der CPU ausführen würden.
Heutzutage verfügen die meisten MCUs über eine ordnungsgemäße Energieverwaltung. Dies beinhaltet im Allgemeinen zwei Hauptaspekte: Power-Gating (Entfernen von Strom von Teilen des Chips) und Clock-Management (Oszillator-Aktivierung und Clock-Routing).
Die meisten Chips aktivieren Power Gates und Clocks nicht auf magische Weise, wenn ein Debugger angeschlossen ist, daher muss der Debugger auch die Plattformverwaltung übernehmen und die ordnungsgemäße Initialisierung verschiedener MCU-IPs durchführen, bevor er tatsächlich den internen Flash erreicht.
Können wir dann mit Flash IP sprechen?
Ja, aber nicht effizient.
Wenn wir alle Speicherzugriffe vom externen Debugger nach Vorschrift machen, wird das funktionieren, aber extrem langsam sein. Das Problem, das wir beim JTAG-Zugriff haben, besteht darin, dass im Allgemeinen eine USB-basierte Sonde mit einer großen (~ Millisekunden) Umlaufzeit durchlaufen wird. Flash-IP-Zugriffe beinhalten normalerweise einen Algorithmus wie:
Es gibt zu viele Abfragen, wenn wir ein paar Millisekunden für jede Iteration dieser Schleife verlieren, wird das Programmieren unserer paar Dutzend KiB Code ewig dauern. Wir werden versuchen, dies zu beseitigen.
Der allgemeine Fall besteht darin, ein kleines Programm in den RAM der MCU hochzuladen, das Datenblöcke aus dem RAM in den Flash kopieren kann. Die Idee besteht darin, USB-Roundtrips zu vermeiden, indem große bedingungslose Uploads von Daten vom Debugger in den RAM durchgeführt werden (sie können in einer USB-Transaktion gestapelt werden) und die CPU die Kopie zum Flashen ausführen lässt (was im Allgemeinen Wort für Wort erfolgt).
Einige Hersteller (entweder weil sie Implementierungsdetails ihrer Flash-IP verbergen möchten oder weil sie das Leben ihrer Kunden erleichtern möchten) implementieren eine Reihe von ROM-basierten Routinen, die Sie direkt vom Debugger-Port aufrufen können, um verschiedene Arten von Aufgaben auszuführen, einschließlich Chip identifizieren, programmieren, löschen. NXP implementiert eine solche Art von ROM in der LPC-Reihe, sie nennen es IAP.
JTAG-Alternativen existieren. ARM hat eine solche Option namens SWD. SWD legt das gleiche Registermodell für DP (Debug Port) und AP (Access Port) offen. Es gibt SWD/JTAG-Varianten (als SWJ-DP bezeichnet), die dynamisch von JTAG auf SWD und umgekehrt umschalten können.
ARM DP/AP-Modellalternativen existieren. Frühere ARMs haben ein anderes Modell, und jeder andere CPU-Anbieter hat seine eigene Art, JTAG (oder ein anderes Debug-Wire-Protokoll) mit Interna zu verbinden.
Die Überbrückung des Debug-Zugriffsports zum Speicher ist eine Option, aber andere Anbieter sorgen dafür, dass der Debug-Port direkt auf die CPU-Register zugreift. Dann kann der Debugger auf den Speicher zugreifen, indem er entweder tatsächliche CPU-Anweisungen in die CPU einfügt (wie Laden und Speichern) oder über spezielle Pseudoregister verfügt, die Speicherzugriffe auslösen. Ti CC2xxx und Mips sind Beispiele für solche Architekturen.
Einige Anbieter haben sich auch für einen direkten Pfad vom Debug-Port zur Flash-IP entschieden, aber das ist ziemlich ungewöhnlich für heutige MCUs, bei denen wir sowieso eine Debug-Fähigkeit haben (weil es indirekten Zugriff auf Flash gibt). Dies war früher üblich für Teile, bei denen die interne CPU keinen Schreibzugriff auf den internen Flash hatte.
Ich frage in Bezug auf den LPC1768, der im Datenblatt nicht angibt, wie Sie dies tun würden.
Tatsächlich steht es im Referenzhandbuch (UM10360.pdf). Sie legen einfach Daten in den RAM und führen die IAP- CopyRamToFlash()Funktion aus. Ja, auch bei Verwendung eines Debuggers.
Die Debug-Schnittstelle selbst wird vom Core IP-Anbieter (ARM) unter http://infocenter.arm.com dokumentiert (kann jedoch eine Registrierung für das vollständige Dokument erfordern).
Es gibt Unterstützung im Open Source OpenOCD-Projekt - man könnte hier in den Quellcode schauen.
Ich gehe davon aus, dass es einen Prozess gibt, den sie alle gemeinsam haben.
Im Großen und Ganzen gibt es drei gängige Muster für die Programmierung von Flash über JTAG:
Schreiben Sie Daten direkt in die Flash-Steuerregister, um sie zum Programmieren des Flash-Speichers zu befehlen. Dies ist oft langsam, stellt aber minimale Anforderungen an den Mikrocontroller.
Schreiben Sie ein kleines temporäres Programm in den RAM (oder verwenden Sie den bereits im ROM vorhandenen Code), der die im RAM abgelegten Daten in den Flash kopiert.
Verwenden Sie Mikrocontroller-spezifische JTAG-Operationen, um direkt in Flash zu schreiben.
Von diesen drei Mustern ist das zweite das häufigste. Und wie in der Antwort von Turbo J erläutert, ist dies diejenige, die der LPC1768 verwendet.
Als Cortex-m3-basiertes JTAG ist nicht unbedingt der richtige Begriff, SWD wäre eher so.
Es variiert von Chip zu Chip, Design zu Design. Dies ist eine sehr weit gefasste Frage.
Eine kürzere Antwort und vielleicht im Einklang mit etwas, das manchmal gemeinsam ist. Wenn ein Chip in der Anwendungsprogrammierung anbietet, was bedeutet, dass ein Programm, das auf diesem Prozessor ausgeführt wird, den Flash, den dieser Prozessor verwendet, und hoffentlich den Flash-Block, von dem er bootet, löschen/schreiben kann, dann können Sie mit einem On-Chip-Debugger, den der Cortex-m3 hat, zugreifen über eine Schnittstelle SWD/JTAG, was auch immer sie anbieten, um mit diesem Debugger zu kommunizieren. Sie teilen dem On-Chip-Debugger mit, dass er den Prozessor stoppen soll, obwohl dies prozessor- und debuggerspezifisch ist. In diesem Fall hat der On-Chip-Debugger vollen Zugriff auf die amba/axi/apb/etc-Busse am Rand des Cortex-m3, sodass Sie alles tun können, was Sie von einem Programm auf dem Cortex-m3 aus tun können, das Bustransaktionen für Sie generiert kann durch den Debugger über den Prozessorbus in den Herstellerbereich des Chips gelangen, einschließlich des Gesprächs mit dem Flash-Peripheriegerät.
Einige MCUs verfügen über eine spezielle Logikschnittstelle zum Zweck der In-Circuit-Programmierung, die nicht unbedingt (wahrscheinlich nicht) durch den Prozessorkern geht, sondern zum Flash selbst oder zu einem Teil der Peripherie umgeht. Schauen Sie sich die ISP-Schnittstelle für den AVR an (es gibt mehr als eine verschiedene AVR-Schnittstelle, übrigens die Xmegas gegenüber den Nicht-Xmegas), diese sind wahrscheinlich logikbasiert und kein Bootloader und kein JTAG.
Nicht ungewöhnlich, einen werkseitig gebrannten Bootloader im Chip zu haben, wie die NXP-Chips typischerweise, wie der, den Sie haben, der ST Cortex-ms auch, Atmel ARM7, aber sieht nicht wie der Cortex-ms aus und so weiter. Manchmal kann man den werkseitig installierten Bootloader ersetzen, manchmal nicht. Diese können jede Schnittstelle verwenden, in der sie entwerfen, manchmal uart, basierend, spi, i2c, usb, benutzerdefiniert.
Und dann gibt es reines JTAG, bei dem ich mich frage, ob diese Chips überhaupt haben, da viele MCUs nicht viele Pins haben und nur wenige/keine übrig haben. JTAG ist eine Zugriffsmethode, wenn Sie über JTAG-Debugger sprechen, JTAG ist der Weg, wie Sie zum Debugger gelangen, es ist nicht JTAG, das ist der Schlüssel, es ist, dass es einen Debugger gibt, der eine Schnittstelle hat und zufällig mit einem verbunden ist JTAG-Schnittstelle, sozusagen, ich habe einen Debugger, den ich mit einer SPI-abhängigen Schnittstelle verbunden habe. Es ist nur die Zugriffsmethode. JTAG wird im Allgemeinen für eine Reihe anderer Dinge verwendet und war für etwas anderes als das On-Chip-Debugging gedacht und wird immer noch sehr häufig für das Non-On-Chip-Debugging verwendet. Es ist also technisch möglich, dass eine JTAG-Kette an eine Flash-Schnittstelle angeschlossen werden könnte, Sie verbinden sich oft mit SRAM für On-Wafer und / oder nach Verpackungstests des SRAM (oder Starten und Überprüfen von mbist), sodass sie möglicherweise auch Zugriff auf einen Flash haben, wenn das Design so ist, und damit könnten Sie mit den richtigen Scan-Ketten Manipulieren Sie die Flash-Schnittstelle so, dass Sie sie programmieren können. Wenn es einen guten Anwendungsfall gäbe, um diesen Flash in der Schaltung zu programmieren, würden sie dort etwas Einfacheres einbauen, was sie für MCUs tun.
Jedes Prozessordesign kann einen On-Chip-Debugger haben oder auch nicht, und das Design dieses Debuggers ist das, was sie wählen, kein Grund anzunehmen, dass die Prozessordesigns zweier Anbieter entfernt gleich sind. Die FUNKTIONALITÄT ist oft dieselbe, Sie können oft durch den On-Chip-Debugger gehen, um auf den Prozessorbus zuzugreifen, um dann auf den Rest des Chips zuzugreifen, es sind nur der Kommunikationspfad und das Protokoll und die Funktionen, die sich unterscheiden. Einige Prozessoren verfügen möglicherweise nicht über einen On-Chip-Debugger. Man könnte sich ein Design vorstellen, bei dem ein Chipentwickler etwas auf dem Hauptbus des Prozessors platziert hat, das den Zugriff ermöglicht, diesen Bus als Hintertür um den Prozessor herum zu überschreiben und zu übernehmen.
Die ARM-Cortex-m-Debug-Schnittstelle ist bei ARM dokumentiert. Die Informationen des Chipherstellers werden vom Chiphersteller dokumentiert, oft können Sie sich durch den Prozessorbus zu den Peripheriegeräten durch die Vordertür einführen, sodass Zugriffe über die Hinter- / Seitentür, die ein Peripheriegerät nicht über die Prozessorbusse übernehmen, oft nicht benötigt werden, aber wenn Vorhanden wäre dann zu hoffen, dass der Chiphersteller dokumentiert, dass in Form der externen Schnittstelle / des Protokolls, das für diesen Zugriff benötigt wird, die tatsächliche Funktionsweise der Interna ihre IP ist und kein Grund, warum sie sie teilen müssen.
Jede „JTAG“-Schnittstelle verwendet eine modellspezifische Zugriffskontrolle, die auf ein bestimmtes Gerät ausgerichtet ist. Das Erstellen eines JTAG-Debuggers aus Rohspezifikationen übersteigt die Fähigkeiten eines Heimwerkerbenutzers und kann einige Sicherheitsmethoden verwenden, die eine gewisse Lizenzierung erfordern.
Gemäß Ihren anderen Fragen haben Sie das Board von einem No-Name-Hersteller auf einer faulen Internetseite gekauft. Als solches wird das Board anscheinend ohne Dokumentation oder Toolchain-Unterstützung geliefert.
Stattdessen sollten Sie sich an den Originalhersteller NXP/Freescale/Motorola wenden und dessen Entwicklungskit mit allen erforderlichen Tutorials und Tools und Unterstützung von Mouser oder ähnlich erhalten
Spehro Pefhany
19172281
Benutzer103380
wie heißt es
19172281