Hallo Leute, ich will ein Prüfadapter für eine Platine erstellen. Das Konzept für den Testablauf steht auch schon. Jetzt habe ich gesehen das es möglich ist, mit dem verwendeten Mikrocontroller (NXP LPC1769) auch einen Boundary-Scan-Test durchzuführen. Ich habe mich bereits in das Thema gut eingelesen und auch ungefähr verstanden wie das ganze ablaufen soll. Die gekauften Boundary-Scan-Controller sind allerdings sehr teuer, weshalb ich mal nachfragen wollte ob jemand hier sich damit auskennt und ob es möglich wäre so etwas selbst du bauen. Bzw. ob sich der Aufwand lohnt? Soweit ich das verstehe ist es ja "nur" ein Bindeglied zwischen der Jtag-Schnittstelle mit einer weiteren Schnittstellen wie z.B USB? und dadurch kann ich Kommandos lesen/schreiben? Grüße Torben
Torben Veit schrieb: > Jetzt habe ich gesehen das es möglich ist, > mit dem verwendeten Mikrocontroller (NXP LPC1769) auch einen > Boundary-Scan-Test durchzuführen. Ich habe mich bereits in das Thema gut > eingelesen und auch ungefähr verstanden wie das ganze ablaufen soll. Der LPC176x hat zwar JTAG, aber nur den ARM-Debug Tap und keinen extra Boundary Scan Tap. Ob der nicht näher beschriebene Boundary Scan Controller damit umgehen kann, müsste man sich genaustens anschauen. Wenn für den Test nur Pins getoggelt/eingelesen werden sollen - das bekommt man auch mit OpenOCD und z.B. einem FTDI USB Chip als JTAG Adapter hin.
Es gibt keinen extra Boundary Scan Controller die HW Schnittstelle ist JTAG aber du brauchst die passende Software, von NXP das passende BSDL File und du schreibst dir dann ein Script für deine Prüfsoftware. Open OSD kann das nicht. Natürlich muss deine Hardware ein Boundary Scan Register haben.
:
Bearbeitet durch User
Jim Meba schrieb: > Der LPC176x hat zwar JTAG, aber nur den ARM-Debug Tap und keinen extra > Boundary Scan Tap. Ob der nicht näher beschriebene Boundary Scan > Controller damit umgehen kann, müsste man sich genaustens anschauen. Laut Datenblatt hat der Controller eine JTAG mit den benötigten Pins: TCK,TMS,TDI,TDO.. . Kann man also daraus nicht schließen, das ein Boundary-Scan möglich wäre? Hans-Georg Lehnard schrieb: > du brauchst die passende Software, von NXP das passende BSDL File > und du schreibst dir dann ein Script für deine Prüfsoftware. Open OSD > kann das nicht. Natürlich muss deine Hardware ein Boundary Scan Register > haben. es gibt leider kein BDSL File von NXP: http://www.nxp.com/knowledge-base/article/kbkA0D0000000CgkbKAC Damit stirbt die Idee den Prozessor über BS zu testen?
> Damit stirbt die Idee den Prozessor über BS zu testen? Boundary Scan ist etwas fuer Hersteller. Man muss den inneren Aufbau der betreffenden Hardware kennen, genau kennen. Dafuer kann man sowas selbst immplementieren, sofern die Hardware das zulaesst. zB in einem FPGA. Bei einem Controller schreibt man ein Testprogramm, das die noetigen Funktionen umd die umgebenden Hardware zu testen enthaelt. Den Controller selbst muss man nicht testen. Der laeuft schon richtig.
Torben Veit schrieb: > es gibt leider kein BDSL File von NXP Warum sollte es ein BSDL-File geben, wenn, wie vorher schon geschrieben wurde, der Controller nicht mit BoundaryScan getestet werden kann? Wenn Du einen günstigen BoundaryScan-Controller willst, schau Dir mal den PicoTap von Goepel an. Schaltplan gibt es irgendwo im Internet. Der Controller baut auf dem FTDI-Chip FT4232H auf. Software dafür mußt Du natürlich selbst erstellen, die Goepel-Software wirst Du nicht bezahlen können.
Jetzt Nicht schrieb: > Boundary Scan ist etwas fuer Hersteller. Man muss den inneren Aufbau der > betreffenden Hardware kennen, genau kennen. Beides falsch. Der Hersteller braucht kein Boundary Scan. Der innere Aufbau der Hardware ist für den normalen Boundary Scan Test völlig unerheblich. Es werden nur die Ein- und Ausgänge getestet, die Core Logic wird abgeschaltet. An den meisten Pins liegt intern eine Boundary Scan Zelle. Diese Zellen sind seriell miteinander verbunden und liegen über den TAP-Controller zwischen TDI und TDO, vereinfacht ausgedrückt. Über die JTAG-Schnittstelle und den TAP-Controller können die Boundary Scan Zellen in bestimmte Zustände versetzt werden und auch gemessen werden. Um diese Tests aufzusetzen, braucht man schon eine leistungsfaähige Software.Grundvoraussetzung ist ein BSDL-File des Herstellers, weil dieses ein Beschreibung der Boundary Scan Zellen enthält.
BoundaryScan schrieb: > An den meisten Pins liegt intern eine Boundary Scan Zelle. Der OP hat einen NXP LPC176x, und der hat sowas eben nicht. Die nächstbeste Lösung wäre IMHO mittels Script und JTAG Debugger (z.B. via OpenOCD) die Pins für einen Test zu toggeln. Mit Boundary Scan hat das dann allerdings nix mehr wirklich zu tun.
Jim Meba schrieb: > BoundaryScan schrieb: >> An den meisten Pins liegt intern eine Boundary Scan Zelle. > > Der OP hat einen NXP LPC176x, und der hat sowas eben nicht. Das war mir schon klar. Mein Post bezog sich allgemein auf Boundary Scan.
BoundaryScan schrieb: > Es werden nur die Ein- und Ausgänge getestet, die Core > Logic wird abgeschaltet. JTAG und Core arbeiten völlig unabhängig voneinender ! Wie willst du sonst zur Laufzeit beim Arm die Debug Register ändern und auch die internen Logic analyzer würden bei den FPGA nicht funktionieren. Dafür ist der Prozessor Reset Eingang auf die Schnittstelle herausgeführt. Deshalb ist es auch wichtig JTAG Eingänge bei nicht Benutzung mit den entspechenden Widerständen zu versehen sonst kann der TAP Controller durch Störimpulse schon mal los laufen .. alles schon passiert !
Hans-Georg Lehnard schrieb: > JTAG und Core arbeiten völlig unabhängig voneinender ! > Wie willst du sonst zur Laufzeit beim Arm die Debug Register ändern und > auch die internen Logic analyzer würden bei den FPGA nicht > funktionieren. Ich habe auch nur den allgemeinen Boundary Scan Test gemeint und nicht das Debuggen über die JTAG-Schnittstelle. Beim Boundary Scan Test interessiert der Core nicht.
Göpel bietet fü Controller, dienur ein JTAG als Debug/Emulationsschnittstelle haben auch eine VarioTap Funktion (Ist im Grunde sehr ähnlich wie das beschriebene Verfahren über OpenOCD), kostet aber gut Geld das ganze... Am einfachsten wird wohl sein eine UART zu nutzen und ein paar Befehle zum Steuern der Controller-Funktionen in der Firmware zu implementieren (oder eine Debug-Firmware einschreiben). Bbeim BoundaryScan steckt das Know-How zu 99% in der Software, die Hardware ist fast schon trivial...
Nachdem der LPC1769 des TO wohl kein Boundary Scan unterstützt - wie sähe es denn aus wenn der Controller es würde und ein BSDL-File vorhanden wäre? Die STM32 unterstützen z.B. Boundary Scan und ST hat für einige STM32 auch BSDL-Dateien veröffentlicht. Doch wie sieht es mit Open Source Software für den Boundary Scan Test aus? Ich hab da z.B. das hier gefunden: http://www.gojtag.com/ Hat damit jemand Erfahrung? Ist das brauchbar? Was fehlt im Vergleich zu kommerziellen Programmen wie denen von Göpel?
Das was Göpel sich bezahlen lässt sind halt so Saxhen wie automatische Generierungen von Testschritten, programmieren externer Flashes, Auswertung der Ergebnisse, Einlesen der Netzliste aus dem Cad Programm usw. außerdem pflegen die eine riesige Datenbank mit BSDL Files und sonstigen Beschreibungen von Chips um die Testprogramme möglichst komfortabel für den Nutzer erstellen zu lassen. Wir nutzen Cascon schon seit Jahren für unsere FPGA Platinen, macht sich schnell bezahlt.
:
Bearbeitet durch User
Was mir bisher auf diesem Gebiet als freie Software begegnet ist kann zwar die Boundary Register irgendwie lesen und schreiben aber viel mehr nicht. Rentiert sich ja auch nicht, dafür eigene Leute zu bezahlen da liefert man einfach das Flash Image an den Bestücker und der kümmert sich darum wie das auf die Platine kommt und wie die geprüft wird. Bei Multilayer BGA Platinen kommt er ja mit Nagelbett nicht sehr weit ...
Hans-Georg Lehnard schrieb: > Rentiert sich ja auch nicht, dafür eigene Leute zu bezahlen da liefert > man einfach das Flash Image an den Bestücker und der kümmert sich darum > wie das auf die Platine kommt und wie die geprüft wird. Bei Multilayer > BGA Platinen kommt er ja mit Nagelbett nicht sehr weit ... Hmm. Du lässt also den Bestücker auch die Tests für Deine Baugruppen entwerfen? Woher weiß der denn wie das alles funktionieren soll und wo er wann welche Pins auf High/Low legen darf ohne daß was abraucht? Ich habe dem Bestücker bisher immer fertige Test-Jigs geliefert mit denen die Baugruppen geflashed und getestet wurden.
Moin, > > Doch wie sieht es mit Open Source Software für den Boundary Scan Test > aus? > Ich hab da z.B. das hier gefunden: http://www.gojtag.com/ > > Hat damit jemand Erfahrung? Ist das brauchbar? Was fehlt im Vergleich zu > kommerziellen Programmen wie denen von Göpel? Ich habe das Teil recht ausgiebig getestet und auch ein paar Anpassungen daran vorgenommen. Fazit, in Kürze: + Für manuelle langsame Tests oder individuelles Board-Debugging ganz ok - Trotz GUI nicht sonderlich intuitiv. Sollte zum Verständnis von JTAG dienen, aber die Bedienung ist teils unlogisch und umständlich - BSDL-Parser fehlerhaft - Nicht weiter gewartete Software Ein kurzes Anwendungsbeispiel findet sich auch im ICEbear-Manual ab Seite 30: http://www.section5.ch/dsp/icebear/ICEbear-manual.pdf Die Lösung biete ich allerdings nicht mehr an, falls jemand denken sollte, ich wolle damit Werbung machen. Rechnet sich vom Aufwand her nicht. Das Problem bei vielen "Billig-"Bscan-Tools auf Basis der einfachen FTDI-Lösungen ist, dass die Bandbreite des USB nicht richtig genutzt wird. D.h. es wird teils a la Parallelport (mein Gott ist das lange her) eine Sequenz geschickt, und auf die Antwort gewartet, bevor die nächste Sequenz losgeht. Deswegen sind die ganzen Sachen kaum für komplette HW-Testpatterns per BScan zu brauchen. 30 Sekunden Testdauer geht in einer richtigen Taktstrasse so gar nicht... Die Goepel-Sachen sind teils auch nicht unbedingt ihr Geld wert, aber sie sind nun mal der Platzhirsch am Markt. Für Massenproduktion und generell Leute, die mal eben 50k für einen ICT ausgeben können, sind die Tools gerade richtig, wie supachris schon beschrieben hat. Zwischen dem teuren Zeug und der Gratisschiene gibt es leider nicht viel. Dennoch/deswegen hat es sich für mich gelohnt, mit einigen Queueing-Tricks auf dem guten alten FT2232H eine relativ flotte BSCAN-Lösung zu implementieren. Mit einer einfachen Library und einem Python-Wrapper kann man ne Menge schöner Sachen machen. Man muss sich nur etwas mit dem FT2232 beschäftigen, die Investition ins Knowhow ist allerdings gut angelegt, der Chip ist nach vielen Jahren immmer noch ein Renner. Wer was schnelleres zur Generierung von synchronen Testpatterns braucht, dem sei ein MachXO2 Breakout-Board empfohlen. Allerdings muss er sich in VHDL eine vernünftige JTAG-Engine hacken.. Viele Grüsse, - Strubi
Strubi schrieb: > Ich habe das Teil recht ausgiebig getestet und auch ein paar Anpassungen > daran vorgenommen. Fazit, in Kürze: Vielen Dank für Deinen Erfahrungsbericht. Liest sich leider nicht so, als ob ich mir damit Arbeit sparen würde. Bisher schreibe ich Testprogramme, die ich dann in den Controller lade, oder, falls das normale Programm noch genug Flash freilässt, Teil der regulären Firmware sind und über einen Befehl aktiviert werden können. Bei einer solchen Lösung habe ich natürlich keine Probleme mit USB-Latenzen oder ähnlichem, da sich die Kommunikation zwischen Steuerungsrechner und dem µC auf ein Minimum beschränkt. > Das Problem bei vielen "Billig-"Bscan-Tools auf Basis der einfachen > FTDI-Lösungen ist, dass die Bandbreite des USB nicht richtig genutzt > wird. Klar, der FTDI kann die Daten ja (trotz MPSSE) nicht wirklich interpretieren und direkt darauf antworten, sondern muss warten bis das Programm auf dem PC ihm sagt wie es weitergeht. Würde bei solchen Problemen nicht einer der intelligenteren JTAG-Adapter helfen? Ich meine hier sowas wie J-Link, ST-Link, CMSIS-DAP,... Oder fehlen denen spezielle Befehle für den Boundary Scan? > 30 Sekunden Testdauer geht in einer richtigen > Taktstrasse so gar nicht... Auch bei manuellen Tests willst Du das vermeiden, die Arbeitszeit dafür haut Dir der Bestücker ja auf die Stückkosten drauf.
Hi Gerd, > > Liest sich leider nicht so, als ob ich mir damit Arbeit sparen würde. > > Bisher schreibe ich Testprogramme, die ich dann in den Controller lade, > oder, falls das normale Programm noch genug Flash freilässt, Teil der > regulären Firmware sind und über einen Befehl aktiviert werden können. > Ich denke mal, das ist für gewisse uC-Anwendungen eleganter und schneller, d.h. wenn du die In-Circuit-Emulations-Möglichkeiten für die Tests nutzt anstatt BScan. Ist dann halt sehr plattformspezifisch und die Gefahr ist, dass man gewisse HW-Probleme nicht sieht. > Bei einer solchen Lösung habe ich natürlich keine Probleme mit > USB-Latenzen oder ähnlichem, da sich die Kommunikation zwischen > Steuerungsrechner und dem µC auf ein Minimum beschränkt. > >> Das Problem bei vielen "Billig-"Bscan-Tools auf Basis der einfachen >> FTDI-Lösungen ist, dass die Bandbreite des USB nicht richtig genutzt >> wird. > > Klar, der FTDI kann die Daten ja (trotz MPSSE) nicht wirklich > interpretieren und direkt darauf antworten, sondern muss warten bis das > Programm auf dem PC ihm sagt wie es weitergeht. > Du kannst halt erst mal den FTDI mit einer dicken Sequenz an Bscan-Register-Writes/Reads zumüllen, und die auf dem Chip gepufferte Antwort später einlesen. Also ein einigermassen intelligentes Queueing verwenden und schauen, dass der Bus immer voll ausgelastet ist. Das macht die Sache deutlich schneller, und das hat man auch in 1-2 Tagen ausgelotet. > Würde bei solchen Problemen nicht einer der intelligenteren JTAG-Adapter > helfen? Ich meine hier sowas wie J-Link, ST-Link, CMSIS-DAP,... > Ehrlich gesagt bin ich mir nicht so sicher, ob die *-Links viel intelligenter sind. Man müsste sie eben auch per Firmware auf seinen Zweck anpassen können. Da ist der FTDI halt einfach schön simpel. > Oder fehlen denen spezielle Befehle für den Boundary Scan? > Mir ist dazu nix bekannt. Vermute mal eher, dass nicht. Das vollgenerisch-programmierbare BScan-Segment gehört halt immer noch den "Grossen" im Spiel. Ich habe mal für eine spezielle Anwendung auf diesen Digilent X-Boards was gebastelt. Um schnelle BScan-Sequenzen abzunudeln und die Ergebnisse abzufragen habe ich im Prinzip sowas wie ne MPSSE stricken müssen, nur auf dem Cypress FX2 bzw. dem CPLD. War allerdings bis Faktor 20 schneller als die FTDI-Lösung. Die Boards gibts allerdings lange nimmer, und heute würde ich den MPSSE-Ansatz nich mehr verfolgen, wo man eine menge gut getesteter SoCs bekommt und so einiges in einen MachXO2 reingeht. So läuft es momentan, eine vereinfachte Hardware-Queue wird einfach von der SoC-Firmware direkt auf dem FPGA getrieben, Kommunikation geht zwar noch über den FTDI, aber nur UART. Aber 1-2 Wochen Arbeit muss man da schon reinstecken. >> 30 Sekunden Testdauer geht in einer richtigen >> Taktstrasse so gar nicht... > > Auch bei manuellen Tests willst Du das vermeiden, die Arbeitszeit dafür > haut Dir der Bestücker ja auf die Stückkosten drauf. Claro, am Schluss muss einer rechnen, wo der Aufwand hin soll.. Und da rechnet sich u.U. auch ein Goepel-Tool, weil es auch einfach seine 10 Jahre supportet wird. Am Schluss kommt auch das subjektive Wohlfühlding dazu (selbermachen/investieren, oder kaufen/vertrauen). Grüsse, - Strubi
Strubi schrieb: > Claro, am Schluss muss einer rechnen, wo der Aufwand hin soll.. > Und da rechnet sich u.U. auch ein Goepel-Tool, weil es auch einfach > seine 10 Jahre supportet wird. Am Schluss kommt auch das subjektive > Wohlfühlding dazu (selbermachen/investieren, oder kaufen/vertrauen). So ist es. Göpel kostet zwar einiges, aber dafür kriegt man das Rundumsorglospaket. Unbekannte Bateile werden meist am gleichen Tag noch von denen in die Datenbank eingearbeitet. Aber die jährlichen Kosten sind schon nicht ohne...
Wenn Du einen günstigen und trotzdem professionelles Boundary-Scan Tool anschaffen willst, schaue Dir auch ABI Electronics an: http://www.abielectronics.co.uk/ Wenn ich mich nicht irre, hat es mich mal GBP2.500 gekostet. Früher hat RS Online das Produkt auch geführt aber scheint nicht mehr der Fall zu sein. Die Firma ist keine Klitsche. Sie treten bei den meisten deutschen Messen auf, Electronica, Embedded World
Strubi schrieb: > Ich denke mal, das ist für gewisse uC-Anwendungen eleganter und > schneller, d.h. wenn du die In-Circuit-Emulations-Möglichkeiten für die > Tests nutzt anstatt BScan. Ist dann halt sehr plattformspezifisch klar. > und > die Gefahr ist, dass man gewisse HW-Probleme nicht sieht. An was denkst Du da? Ich kann im Controller über die Alternate Functions ja alle Spezialhardware wie I2C, UART,... abschalten, (fast) alle Pins als GPIOs ansteuern und dann systematisch durchprüfen. Sehr gerne kombiniere ich das dann mit einem über den Testrechner gesteuerten, etwas besseren Multimeter (z.B. Keithley 2000) mit dem ich die Stromaufnahme messe. So kann ich z.B. ganz einfach feststellen, ob eine LED den erwarteten Strom aufnimmt oder nicht. Was könnte ich dabei im Vergleich zum BScan übersehen?
> > An was denkst Du da? > > Ich kann im Controller über die Alternate Functions ja alle > Spezialhardware wie I2C, UART,... abschalten, (fast) alle Pins als GPIOs > ansteuern und dann systematisch durchprüfen. > Ok, wenn das so geht, dann taugt der Controller was. In dem Fall an den ich da dachte, war's ein kniffliger Kurzschluss auf dem BGA, der aber interessanterweise nur unter gewissen Bedingungen und zudem indirekt auftrat, also die Pins die den Effekt zeigten, waren gar nicht kurzgeschlossen, sondern es ging über einen dritten Pin und vermutlich die Schutzdioden. Konnte erst per BScan so richtig rekonstruiert werden, dummerweise wurde die HW schon produziert und ausgeliefert, das ist bei den Jungs einfach durch den ICT gerutscht. > Sehr gerne kombiniere ich das dann mit einem über den Testrechner > gesteuerten, etwas besseren Multimeter (z.B. Keithley 2000) mit dem ich > die Stromaufnahme messe. So kann ich z.B. ganz einfach feststellen, ob > eine LED den erwarteten Strom aufnimmt oder nicht. > > Was könnte ich dabei im Vergleich zum BScan übersehen? Ich hau mal wieder ne Platitüde raus: Wenn du deinen Debugger nicht debuggen musst, ist alles gut :-) Wenn du alle Szenarien abdecken kannst, und deiner HW vertraust, muss der built in self test nich schlechter sein als ne externe BSCAN-Probe. Auch beim BSCAN kann man so einige wichtige Testmuster im Prinzip vergessen haben, andersrum ist BSCAN auch wieder so intrusiv oder im Timing beschränkt, so dass man z.b. den memory-check auch wieder dem BIST überlassen muss. Gruss, - Strubi
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.