Hallo mikocontroller community, wollte mal nachfragen ob einer von euch genauere Informationen zu den drei oben genannten debug/Programmierschnittstellen hat. Genauer gesagt würde es mir um einen Vergleich der drei gehen was Programmiergeschwindigkeit usw angeht. Ich weiß das SWD 2 pins benötigt und JTAG dagegen 4 oder optional 5 sowie VDD und GND. Boundary scan benötigt nur 4 bzw 5. Aber was ist mit Programmiergeschwindkeit bzw. Protokoll? Ich konnte z.b nirgendwo Infos finden worin sich JTAG und boundary scan eigentlich unterscheiden. Weiterhin nirgendwo Infos bzgl. den Protokollen und Programmierzeiten gefunden. Danke!
Schau mal hier: http://www.fpga4fun.com/JTAG.html Vielleicht beantwortet das zumindest ein Teil deiner Fragen.
>Aber was ist mit Programmiergeschwindkeit bzw. Protokoll?
Das hängt natürlich vom Programmer und vom zu programmierenden
Device ab.
Hast Du schon mal beim Segger geschaut?
Hi, danke für die Infos. Mir ist klar das dies vom genutzten Programmer abhängt, aber mir ist irgendwie noch nicht der Unterschied klar zwischen Boundary Scan und JTAG was die Programmierung angeht. beide arbeiten mit derselben state machine, beide benötigen die selben Signale..
Manuel Reisser schrieb: > Hi, > danke für die Infos. > Mir ist klar das dies vom genutzten Programmer abhängt, aber mir ist > irgendwie noch nicht der Unterschied klar zwischen Boundary Scan und > JTAG was die Programmierung angeht. > beide arbeiten mit derselben state machine, beide benötigen die selben > Signale.. Boundary Scan ist ein Teil von JTAG. Man kann mehrere JTAG-Teilnehmer ansprechen (aber immer nur einen) und so mehrere Teilnehmer (hintereinander) programmieren. Lies dir meinen oben genannten Link durch...
Hi Daniel, hab ich durchgelesen, explizit der Unterschied ist mir trotzdem nicht klar. Ich kann Prozessoren per boundary scan programmieren (also der Flash) oder per JTAG. Wo ist da jetzt der große Unterschied? Das BS und JTAG zu 1149.1 gehören ist mir auch klar..
So noch mal zum Mitschreiben. JTAG ist das allgemeine. Der Boundery scann verwendet JTAG. damit kanst du an allen pins wakeln und dadurch, auch wenns langsam ist einen extern angeschlossenen flasch programmieren. Und um MCUs zu debugen verwendet man auch JTAG. nur ist da der "Boundery" direct um die MCU gelegt. das heist du kanst an den internen eigentlich von der MCU kontrolliereten signalen wackeln. Register beschreiben / auslesen, ... dadurch kannst du z.B. kleine programm rotinen ins sram schreiben und einen kleinen datablock von deinem Programm und damit das flaschen auslösen. Das geht vermutlich um einiges schneller als über das signal gewackele. nur ist JTAG nicht wirklich besonders schnell. Schau dier was Protokolle angeht z.B. die ARM documentation an. Da ist sowol die anbindung von JTAG an die MCU dokumentiert als auch die von SWD an die Cortex MCU. und SWD ist z.B. um einiges schneller, da du nicht über die MCU gehen must um auf speicher zuzugreifen sondern den direkt ansprechen kanst. (wenn der hersteller das auch implementiert hat in seinem baustein)
Mir gehts vorallem um das programmieren eines internen Flash Speichers, also nen embedded Flash von nem Mikrocontroller. Sollte ja mit allen 3 Methoden machbar sein, aber der Unterschied zwischen Boundary scan und JTAG Programmierung wurde noch nicht deutlich. Für Programmierung über JTAG reicht es wenn der Baustein eine JTAG Schnittstelle hat, für Programmierung über BS benötigt er aber zusätzlich boundary scan Zellen an seinen Pins. Dadurch muss es doch auch nen grundlegenden Unterschied geben.. JTAG verwendet ja nicht das boundary scan register zum programmieren!
Hallo Manuel, der Boundary scan dient nicht zum Programmieren, sondern wird zum Testen der Anschlusspinne verwendet. Wie bereits im ersten Link von Daniel V. sehr gut dargestellt. Dazu wurde eine Standardisiertes Interface namens JTAG geschaffen. Wobei JTAG eigentlich der Name des Normierungsteams ist das das JTAG Interface normiert hat ... Findige Ingenieure, die kostbare Anschlusspinne sparen wollten, haben sich dann gefragt, ob man die ansonsten nutzlosen JTAG Pinne nicht auch zum Programmieren und Debuggen von Mikrocontroller verwenden kann. Dafür haben Sie dann das JTAG Interface mit nicht standardisierten Erweiterungen zum Programmieren und Debuggen erweitert. Deshalb funktioniert ein AVR-JTAG Debugger auch in der Regel nicht mit einem STM32 Cortex M3. Die Firma ARM hat dann für ihre Kerne diese nicht standardisierten Erweiterungen etwas vereinheitlicht. Außerdem haben Sie (ARM) sich fürs Debuggen und Programmieren eine weitere Schnittstelle namens SWD ausgedacht, die gegenüber JTAG noch weniger Pinne braucht. Also: Programmieren/Debuggen macht man über die nicht standardisierten JTAG Erweiterungen oder SWD. Zum Testen der gefertigten Platine könnte man den Boundary scan verwenden. Alle deine Fragen und auch deine früheren Posts hier und im STM32 Forum scheinen mir recht theoretisch zu sein. So als ob du noch nie einen Mikrocontroller mal in der Praxis programmiert hättest. Am besten bekommt man nämlich ein Gefühl dafür was JTAG, SWD ist, indem man einfach mal ein paar Programme für Mikrocontroller schreibt und dann JTAG/SWD und alternativ einen Bootloader benutzt um diesen dann zu programmieren und zu Debuggen. Dann werden sich auch alle deine Fragen/Unsicherheiten bezüglich JTAG (fast) ganz von alleine klären.
Hallo SF, mir ist mitlerweile schon klar was ich mit den einzelnen Dingen machen kann :) Nur kann man definitiv auch per boundary scan programmieren http://boundaryscan.blogspot.de/2010/11/flash-programming-speed.html JTAG benötigt keine boundary scan Zellen, bei der Programmierung über boundary scan spielen diese jedoch eine größere Rolle. Mikrocontroller wurden bei uns an der Hochschule nur über RS232 programmiert, wir haben leider nie mit bootloadern usw gearbeitet. Selbst hab ich mal nen Atmega32 über JTAG programmiert. Der obige Link zeigt z.b. wie man die Programmierzeit theoretisch berechnet wenn man boundary scan chains verwendet. Wie die ganze Sache bei JTAG aussieht konnte mir noch keiner sagen (Muss anders aussehen, da die BS Zellen dort keine Rolle spielen) Danke!
Manuel Reisser schrieb: > Wie die ganze Sache bei JTAG aussieht konnte mir noch keiner sagen (Muss > anders aussehen, da die BS Zellen dort keine Rolle spielen) > Danke! Was meinst du mit Boundary Scan "Zelle"? Fazit im oben verlinkten Artikel ist: "Now that we have an intuitive understanding of how chain length and TCK rate affect programming rate, we can put our knowledge into practice." Es wird beschrieben, wie die Programmierzeit von der Kettenlänge abhängt. Falls du weißt, was mit Kette gemeint ist, ist gut. Ansonsten solltest du nochmal meinen obigne Link lesen, und zwar alle Kapitel. Wenn du nur ein Bauteil am JTAG hängen hast, dann brauchst du keinen Boundary Scan. Andernfalls natürlich schon. Warum wohl?
Boundary Scan Zellen nennen sich die einzelnen Glieder der Kette.. Also wenn die BS chain aus 900 bits besteht sind dies 900 BS Zellen die miteinander verbunden sind. Also berechne ich die theoretische Programmierzeit für EIN device bei JTAG genauso wie bei BS? Spielt bei Programmierung über JTAG die Kettenlänge, welche im BSDL file angegeben ist, also eien Rolle? Spielt bei Programmierung die im BSDL file angegebene maximale TCK Frequenz ne Rolle? Kann ich mir kaum vorstellen, denn es gibt Bausteine die über eine JTAG Schnittstelle verfügen aber eben nicht BS fähig sind..
"Boundary Scan" war ursprünglich dazu gedacht, den Zustand der physikalischen Pins eines Bausteins einzulesen, so daß man nicht mit dem Osci-Tastkopf an die Platine muß. Daher der Name: Boundary = Grenze des Bausteins = seine Pins Scan = Lesen Nun kann man mit Boundary Scan die Pinne nicht nur lesen, sondern auch setzen. D.h. Du kannst die Pins vom PC aus "fernsteuern". Dies sollte das Testen erleichern (siehe "T" in "JTAG"). Wenn man Pinne fernsteuern kann, kann man dies dazu "mißbrauchen", um mit einem anderen Baustein wie z.B. einem externen Flash zu kommunizieren, bzw. diese Flash zu programmieren. Das Protokoll dieses Flashes ist aber natürlich nicht Teil des JTAG-Protokolls (das JTAG-Protokoll kann ja unmöglich alle Flashe und alle erdenkbaren Verdrahtungen abdecken). Unabhängig vom "Boundary Scan" kann jeder Chip-Hersteller das JTAG-Protokoll mit prorietärem Kram erweitern, z.B. mit Debugger-Protokoll oder Flash-Programmier-Protokoll. Das ist aber dann ein Hersteller-spezifischer Kram.
Manuel Reisser schrieb: > Boundary Scan Zellen nennen sich die einzelnen Glieder der Kette.. Nein. Die Glieder der Kette sind die einzelnen Bauteile, also FPGA, Controller, Flash, etc. Für jedes Bauteil gibt es ein BSDL-File, das dieses Bauteil beschreibt. Über die JTAG-Schnittstelle kann man die Device-ID des Bauteils auslesen und so erfahren, was denn überhaupt an der Kette dran hängt und im entsprechenden BSDL-File die Eigenschaften lesen. > Also wenn die BS chain aus 900 bits besteht sind dies 900 BS Zellen die > miteinander verbunden sind. Aus dem BSDL-File erfährst du wieviele Bits das entsprechende Bauteil hat. Das hat nix mit der Kette zu tun. Das BSDL-File weiß nix von der Kette. > Also berechne ich die theoretische Programmierzeit für EIN device bei > JTAG genauso wie bei BS? Ja. > Spielt bei Programmierung über JTAG die > Kettenlänge, welche im BSDL file angegeben ist, also eien Rolle? Es ist nicht die Kettenlänge angegeben, sondern die zu beschreibenden/lesenden Bits des Bauteils. > Spielt bei Programmierung die im BSDL file angegebene maximale TCK > Frequenz ne Rolle? Ja, die sollte nicht überschritten werden. D.h. das langsamste Bauteil in der Kette bestimmt die maximale Frequenz. > Kann ich mir kaum vorstellen, denn es gibt Bausteine die über eine JTAG > Schnittstelle verfügen aber eben nicht BS fähig sind.. Alle JTAG-Bauteile sind BS fähig. Die ganze Bauteil-Kette verhält sich wie ein riesiges Schieberegister. Das erste Bauteil hat 900Bits, das zweite 58. Wenn du also das zweite Bauteil ansprechen willst, musst du deine Daten erstmal 900 Bits durchschieben (takten), damit sie dort ankommen, wo sie hin sollen. Je mehr Bauteile du in der Kette hast, desto länger dauert es (weil mehr Bits), bis du die Daten geschrieben hast. Soviel in aller Kürze. JTAG ist eigentlich recht einfach, die Fülle an Bauteilen und Möglichkeiten macht es aber sehr komplex.
Daniel V. schrieb: > Wenn du also das zweite > Bauteil ansprechen willst, musst du deine Daten erstmal 900 Bits > durchschieben (takten), damit sie dort ankommen, wo sie hin sollen. Das kann man umgehen, indem man den Baustein in den BYPASS Mode setzt. Eigentlich muss man nur die Länge des Instruction Registers wissen, damit man den BYPASS Befehl reinschreiben kann. Der BYPASS Befehl ist einer der wenigen festgelegten Befehle, der geht an jedem 1149.1 fähigem Baustein. Dann hat man für diesen Baustein nur noch genau 1 TCK Verzögerung. Siehe hier: http://www.corelis.com/education/Boundary-Scan_Tutorial.htm#requiredinstructions
Morgen, Mit kette meine ich in diesem Fall nicht die die externe Verkettung einzelner Bauelemente sondern das Boundary scan register, das wiederrum aus einzelnen Boundary Scan Zellen besteht. Das is Fakt! (Sorry, vielleicht schelcht ausgedrückt) Mit 900 Bits meine ich also die Länge des internen BS Registers. @ Christian : Da hast du recht, so wird das gemacht @ Daniel nochmal : Mit boundary scan kenn ich mich eig recht gut aus, ich weiß also wozu ein BSDL File da ist usw. Zu deinem letzten Absatz : http://www.corelis.com/blog/index.php/blog/2011/01/10/jtag-for-functional-test-without-boundary-scan "There’s a JTAG port, but this processor does not support boundary-scan test. This is something that often comes up when talking to our customers—aren’t JTAG and boundary-scan synonymous? Not necessarily. A particular processor might have a JTAG port for programming and debug without including any boundary-scan capability." Ganz klar wird hier gesagt das ein JTAG fähiger Baustein nicht gleichzeitig BS fähig ist, dass ist ja genau das was mich verwirrt!! Wenn ein JTAG fähiger Baustein nicht BS fähig ist heißt das das diesem das BS Register fehlt. Wie funktioniert die Programmierung dann bei JTAG? @Bronco : Um die Pins via JTAG fernsteuern zu können benötige ich doch auch an jedem Pin eine Zelle (wie die BS Zelle) die dies übernimmt, oder nicht? Das ist genau der Knackpunkt bei dem es bei mir hängt! JTAG-fähiger Baustein welcher nicht BS fähig ist wird wie programmiert? Er hat ja dann kein BS Register, also kein Register um die bits zu den einzelnen Pins zu shiften um diese zu kontrollieren! Danke
Manuel Reisser schrieb: > Das ist genau der Knackpunkt bei dem es bei mir hängt! JTAG-fähiger > Baustein welcher nicht BS fähig ist wird wie programmiert? Ganz einfach über hersteller-spezifische Algorithmen, die lediglich JTAG als elektrische Schnittstelle nehmen. Ist schon so, JTAG muss nicht BS heißen, der MSP430 hat zum Beispiel auch JTAG als Programmierinterface und kann kein BS, der kann nichtmal in den BYPASS Modus geschalten werden, kann also nicht mit anderen JTAG Bausteinen in einer Kette eingesetzt werden. Die programmierung kann bei verschiedenen Bausteinen(z.B. Xilinx) wahlweise über JTAG und herstellerspezische Algorithmen erfolgen, oder auch über IEEE1532, was auf IEEE1149 aufsetzt. Damit wollte man eine Art standardisiertes programmierverfahren entwickeln, eventuell ist es das, was du meinst. Aber meines Wissens unterstützen das nicht allzu viele Hersteller.
Grunsätzlich gehts mir darum : Bei boundary scan wird das boundary scan Register verwendet um die Pins zu kontrollieren und damit den embedded Flash zu programmieren. Nun hat ein Bauteil, wie der MSP430, welcher JTAG fähig ist aber nicht BS-fähig kein boundary scan Register, kann somit auch nicht von der Programmierung her analog zu boundary scan funktionieren. Für die Programmierung mit boundary scan gibt es theoretische Berechnungen, wie man die Programmierzeit ausrechnen kann (Siehe 1. Link) Wie siehts bei JTAG aus? Da ich hier keine Kette hab muss die theoretische Berechnung anders aussehen. Danke
Manuel Reisser schrieb: > Für die Programmierung mit boundary scan gibt es theoretische > Berechnungen, wie man die Programmierzeit ausrechnen kann (Siehe 1. > Link) Das dürfte ziemlicht theoretischer Natur sein. In der Praxis wird wohl die Schreibzeit im Flash/EEPROM der limitierende Faktor sein. Das sind nämlich in der Regel einige 10 ms pro Block (oder Page).
Deshalb hab ich ja theoretische Berechnung geschrieben ;) edit : wird aber denk ich mal relativ eng, da die Programmierung über BS relativ langsam ist..
Wieso sollte das über BS zu langsam sein? Kommt eben drauf an, wieviele BS-Zellen in dem Chip sind. Einen BS-fähigen Chip "normal" über JTAG zu programmieren dauert dann genauso lange, da das BYPASS nur für den gesamten Chip gilt. Wozu soll diese Betrachtung gut sein? Das ist doch komplett aus der Realität gerissen. Wird das eine Doktorarbeit?
Manuel Reisser schrieb: > Bei boundary scan wird das boundary scan Register verwendet um die Pins > zu kontrollieren und damit den embedded Flash zu programmieren. Woher stammt diese Erkenntnis? Der viel weiter oben verlinkte Blog sprach von der Programmierung eines externen Flash! Ich glaube kaum, das internes Flash über die BSC programmiert wird, denn der Boundary Scan Test definiert die Kommunikation mit der Außenwelt, die chipinterne Funktionalität wird während des BST normalerweise abgetrennt. Jörg Wunsch schrieb: > Das dürfte ziemlicht theoretischer Natur sein. In der Praxis wird > wohl die Schreibzeit im Flash/EEPROM der limitierende Faktor sein. > Das sind nämlich in der Regel einige 10 ms pro Block (oder Page). Das ist -leider- Wunschdenken. Nehmen wir z.B. ein PC28F256P30TF von Numonyx: Erreichbare Schreibrate bei Verwendung der maximalen Buffergröße: 1,14 MB/s. Nutzbare Rate bei Programmierung über die BSC eines FPGA mit einer BSC Länge von 1164 Bits und einer TCK Frequenz von 10MHz: 4,6 kB/s Dies gilt natürlich nur für die Programmierung eines externen Flash über die BSC. Und die BSC kann bei FPGAs schon mal sehr lang werden. Und dann bestimmt diese Länge die Programmierzeit. (Über Tricks kann man die Geschwindigkeit wieder erhöhen, aber das ist ein anderes Kapitel.)
Florian V. schrieb: > Woher stammt diese Erkenntnis? Der viel weiter oben verlinkte Blog > > sprach von der Programmierung eines externen Flash! Ich glaube kaum, das > > internes Flash über die BSC programmiert wird, denn der Boundary Scan > > Test definiert die Kommunikation mit der Außenwelt, die chipinterne > > Funktionalität wird während des BST normalerweise abgetrennt. Diese Kenntnis kommt aus unterschiedlichen Betrachtungen: Wenn ich in einer Kette aus 2 Bausteinen den letzen Programmieren will, addiere ich die BS Zellen beider Bausteine um die effektive Länge des BS registers herauszubekommen. Wenn die Programmierung nicht über die Kette laufen würde bräuchte ich dies ja nicht zu tun, alsio die Zellen des letzten Bausteins dazu addieren.. Der boundary scan test beinhaltet ja unterschiedliche Operationen, nicht nur die Kommunikation mit der Außenwelt. @Christian R. : Ich bin mir eigentlich ziemlich sicher das die Programmierung über boundary scan langsamer ist, da die bits welche zur Programmierung "nötig" sind durch das kompleete scan register geshifted werden müssen, und zwar für jeden Schreibvorgang. Nö, keine Doktorarbeit, soll aber für eine relativ theoretische Arbeit verwendet werden.
Es wurde schon viel Richtiges geschrieben. Daher möchte ich nur einen Link beisteuern, unter dem viel um die Entstehung und Verwendung von JTAG (das ist eigentlich der Name der Erfindergruppe "Joint Test Access Group") zu lesen ist: http://corelis.eu/education/JTAG_Tutorial.htm Interne Flashes werden übrigens oft aus der Entwicklungsumgebung programmiert, indem über das JTAG-Interface ein Stück Code in das interne RAM geladen und dort ausgeführt wird (Emulationsmodus). Der Code empfängt dann den Flash-Inhalt über das JTAG-Interface und programmiert das on-chip Flash. Für den Entwickler ist diese Methode meist nicht zugänglich. Ähnliche Methoden gibt es auch für extern angeschlossene programmierbare Bauteile, die aber jeweils spezifisch für einen bestimmten Controller realisiert werden. Boundary Scan kann dass natürlich auch, sogar unabhängig vom Prozessor/FPGA, ist aber i.d.R. deutlich langsamer.
Hallo Andreas, Dies wird aber vermutlich nicht so gemacht wenn der Bootloader beim Bestücker in den interne Flash des Mikrocontrollers geschrieben wird nehm ich mal an..? Unsere Prüfvorschrift belegt das der Bestücker den bootloader über JTAG ins interne Flash schreibt. Der wird das wohl nicht über die Entwicklungsumgebung machen? (So macht mans wahrscheinlich während der Prototypenphase in der Entwicklung nehm ich mal an..?) Danke dir
Hi Manuel, ich hab den Eindruck, Du bringst zwei Sachen durcheinander. Stell Dir vor, Du hast eine Garage (Dein µC mit internem Flash) von Daimler-Benz. In der Garage ist ein genormtes Fenster (JTAG Boundary Scan) und ein 6m breites proprietäres Tor von Daimler-Benz (proprietäres Flash-Programmier-Protokoll über JTAG). Frage: Wer würde freiwillig seinen Benz in Einzelteilen durch's Fenster in die Garage reichen, nur weil dieses in den meisten Garagen auch vorhanden ist?
Manuel R. schrieb: > Ich bin mir eigentlich ziemlich sicher das die Programmierung über > boundary scan langsamer ist, da die bits welche zur Programmierung > "nötig" sind durch das kompleete scan register geshifted werden müssen, > und zwar für jeden Schreibvorgang. Welches Scan-Register meinst du denn? Klar müssen die durch alle BS-Zellen durch, wenn der Chip BS kann, und das auch, wenn über spezielle Befehle ins Instruction Register und die USER Register programmiert wird, wie das bei den Herstellern üblich ist. Dazu muss man trotzdem alles durchschieben, BYPASS betrifft den gesamten Chip. JTAG Programmierung nutzt ja auch nur die selbe Infrastruktur im Chip wie die IEEE1532 Programmierung, nur halt nicht so abstrahiert.
Christian R. schrieb: > Welches Scan-Register meinst du denn? Klar müssen die durch alle > BS-Zellen durch, wenn der Chip BS kann, und das auch, wenn über > spezielle Befehle ins Instruction Register und die USER Register > programmiert wird, wie das bei den Herstellern üblich ist. Dazu muss man > trotzdem alles durchschieben, BYPASS betrifft den gesamten Chip. Die BSC befindet nicht bei allen JTAG-Instructions in der Chain, nur bei SAMPLE/PRELOAD und EXTEST wird sie in die Kette eingeschaltet. Bei anderen Kommandos ist sie schlicht nicht da. Da werden dann, wenn benötigt, andere Register in die Chain eingeblendet, z.B. die für die interne Programmierung.
Manuel R. schrieb: > Der boundary scan test beinhaltet ja > unterschiedliche Operationen, nicht nur die Kommunikation mit der > Außenwelt. Hast Du dafür ein konkretes Beispiel, wo mit den Mitteln der BSC etwas anderes gemacht wird, als Verbindungen mit der Außenwelt abzufragen oder zu stimulieren? Im BSDL-File kann man da viel rauslesen. Das wäre mir nämlich neu. Interne Programmierung wird üblicherweise über spezielle JTAG-Instructions gemacht, die dann gerade nicht über die BSC laufen.
Florian V. schrieb: > Die BSC befindet nicht bei allen JTAG-Instructions in der Chain, nur bei > SAMPLE/PRELOAD und EXTEST wird sie in die Kette eingeschaltet. Achso? Das wusste ich auch noch nicht. Wieder was gelernt.
Moin, sehr verwirrender Thread, aber dafür können die Mitwirkenden nix. Liegt vor allem daran, dass JTAG die Bezeichnung "Standard" eigentlich gar nicht verdient hat. Deswegen findet man auch eine Menge Bugs in den Implementationen, teilweise verstümmeln die Hersteller mit oder ohne Absicht die Funktionalität, von Dokumentation gar zu schweigen. So geschehen auch ursprünglich beim MSP430, Verkettung funktioniert nicht, und BSCAN fehlt bekanntlich. Inzwischen ist aber einiges reverse-engineerte publiziert worden: Siehe dazu source code zum "mspdebug" tool. Beim MSP430 gabs aber noch eine andere proprietäre Methode (allerdings dokumentiert), das interne Flash zu beschreiben. Wenn man ein BSDL-File in die Finger kriegt, hat man schon mal Glück, dass man im Prinzip mit den geeigneten Tools einen Flash-Chip programmiert bekommt (dadurch dass man per BScan an den Pins wackeln kann). Für die zeiteffektive Produktion ist das aber nicht wirklich praktikabel. Der Emulations-Modus der schon genannt wurde, ist da die schnellere Variante, ist aber auch bei wenigen CPUs vernünftig dokumentiert: Dabei werden einfach die Instruction-Opcodes per JTAG in die CPU geladen, somit der Chip wie von aussen ferngesteuert. Wie das im Prinzip geht, kann man hier (leider nur auf englisch) nachlesen: http://www.section5.ch/doc/jtag/jtag-impl-ew2012.pdf Gibt auch noch ein nettes grafisches Tool zum herumspielen, wenn man ein BSDL-File hat: goJTAG (www.gojtag.com). Wurde auch mal aktiv beworben, das Projekt scheint mir nur recht verwaist, alte Bugs werden wohl in der freien Version nicht mehr behoben.. Grüsse, - Strubi
Bronco schrieb: > Hi Manuel,ich hab den Eindruck, Du bringst zwei Sachen durcheinander.Stell Dir vor, Du hast eine Garage (Dein µC mit internem Flash) von Daimler-Benz. In der Garage ist ein genormtes Fenster (JTAG Boundary Scan) und ein 6m breites proprietäres Tor von Daimler-Benz (proprietäres Flash-Programmier-Protokoll über JTAG).Frage: Wer würde freiwillig seinen Benz in Einzelteilen durch's Fenster in die Garage reichen, nur weil dieses in den meisten Garagen auch vorhanden ist? Guten Morgen alle zusammen, Hi Bronco, Ich weiß selber das die Programmierung über boundary scan nicht wirklich Sinn macht wenn man ein einziges, dazu auch noch embedded Flash programmieren will. @Florian V. : bin mir nicht mehr sicher, war RUNBIST nicht eine Operation bei der die BS chain verwendet wird aber nicht mit der Außenwelt "direkt" kommuniziert wird? @Strubi : Danke, schau ich mir mal an. Aber ich denke ich habe meine Antwort auf die Fragé. Und zwar ist es so: BS ist eine Methode der in-system Programmierung über JTAG. JTAG is das übergeordnete Kommunikations&Kontroll Protokoll und kann für mehrere Methoden verwendet werden, nicht nur für Boundary scan. Da gibts dann z.B noch die Methode die Strubi beschrieben hat und noch einige Andere. Wenn ein Baustein über JTAG programmiert werden kann heißt das noch lange nicht, dass dieser über BS programmiert werden kann, denn dazu benötigt er die BS Zellen welche der bei den anderen Methoden über JTAG nicht benötigt. Diese Antwort hätte mir eigentlich ausgereicht :P Danke trotzdem!!
Manuel R. schrieb: > bin mir nicht mehr sicher, war RUNBIST nicht eine > Operation bei der die BS chain verwendet wird aber nicht mit der > Außenwelt "direkt" kommuniziert wird? Nach der Spec (siehe z.B. http://www.scribd.com/doc/63310993/33/The-RUNBIST-instruction ) wird für RUNBIST das "Test data register" eingeblendet. Und dies darf, wieder was gelernt, identisch mit dem Boundary Scan Register sein.
Manuel R. schrieb: > BS ist eine Methode der in-system Programmierung über JTAG. Naja, das nun eben gerade nicht. Eher so: Boundary Scan (IEEE1149.1) ist eine Methode zum statischen digitalen Verbindungstest. Boundary Scan benutzt JTAG als elektrisches Interface. Einige Baisteine können über die Boundary Scan Register auch interne oder externe Flash-Speicher programmieren. Dazu gibt es auch herstellerunabhängige Protokolle wie z.B. IEEE1532. Da dies durch die Länge der Schiebekette ineffizient sein kann, wird die Programmierung meist über herstellerspezifische Protokolle durchgeführt, die ebenfalls JTAG als Interface benutzen. Nicht jeder Baistein, der einen JTAG Anschluss hat, ist boundary scan fähig, aber jeder boundary scan fähige Baustein hat einen JTAG Anschluss.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.