mikrocontroller.net

Forum: FPGA, VHDL & Co. USB Blaster Defekt nach'm Programmieren


Autor: J. O. (einjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab so'n "China Böller C" (USB Blaster Rev.C) im Nachbau mit einem 
STM32F101CB (an 3.3V) und einem 74HC244 Buffer (rote Platine).

Damit habe ich einen Altera MAX 7032 S (an 5V) programmiert. Es ist nur 
ein CPLD in der Kette und es ist ein einfaches Stück Lochrasterplatine 
mit 'nem PLCC44 Sockel an dem die ca. 30cm Flachbandkabel vom USB 
Blaster gehen. 5V für den MAX7032S kommen von einem USB "Power Pack".

Da ich nur ein Projekt habe und der CPLD von mir danach vorerst nicht 
neu programmiert wurde, fiel mir erst viele Monate später - also neulich 
- auf, dass Quartus II 13.0 SP1 zwar den Chip noch erkannte aber nicht 
mehr beschreiben wollte.

Es stellte sich heraus, dass im HC244 der Treiber für TDI defekt ist. 
Hatte so'n lustig schwebenden Pegel. 
http://joogn.de/a/def-HC244-Treiber.PNG
Da noch ein Gatter im 244 frei war, hab ich das einfach umverdrahtet und 
siehe da, ich konnte den CPLD wieder programmieren... einmal o_0;

TDI, TCK und TMS haben bei erneuten Versuchen zu beschreiben, laut Oszi, 
eigentlich akzeptable Pegel und Flanken. Was auffällt sind jedoch 
"Überschüsse" von fast 1V und ein deutliches Übersprechen der High/Low 
Wechsel auf +5V und GND. (auf meiner Platine hat der CPLD direkt an 3 
von 4 Vcc Pins einen 100nF SMD Kondensator.)

Auf TDO tut sich nichts - außer Übersprechen. Ich kenn mich aber auch 
nicht mit dem ISP Protokoll genügend aus, um zu wissen, ob der CPLD 
antworten sollte. Bei einem "Device Check" gehts nie auf Low. Ich habe 
noch ersatz 7032S, aber auch ein erster Austausch brachte keine 
Änderung.

Ich werde den HC244 austauschen, aber wenn es den so leicht beschädigt 
hat, liegt nahe, dass es einem neuen schnell ähnlich ergehen wird. Darum 
bin ich für Tipps und Hinweise dankbar, wie es dazu kommen konnte? Da 
laut Netz-Suche niemand sonst in der Welt dieses Problem zu haben 
scheint, könnte ich wohl irgendwas 'falsch' machen...

: Bearbeitet durch User
Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J. O. schrieb:
> könnte ich wohl irgendwas 'falsch' machen...
1. Unter Spannung gesteckt.
2. Versorgung der Zielplattform aus einer anderen Steckdose mit 
entsprechender Potentialverschiebung.

Verbinde GND der Zielplattform mit dem USB Gehäuse/Masse vor dem 
Einstecken des Programmers.

Autor: J. O. (einjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> 1. Unter Spannung gesteckt.

Welche Spannung? Vom Ziel (5V), vom USB Blaster (intern 3.3V wenn am 
laufenden PC gesteckt) oder beide?

D.h. HC244 Austauschen und dann genau drauf achten.

Lässt sich das durch ein paar Bauteile "idiotensicherer" gestalten? In 
meinem ByteBlaster Selbstbau waren noch zusätzlich 100 Ohm Widerstände 
in Reihe von TDI, TDO, TCK und TMS oder dämpfen die lediglich 
Signal-Reflexionen?

> 2. Versorgung der Zielplattform aus einer anderen Steckdose mit
> entsprechender Potentialverschiebung.

Die Sache mit der Masseschleife?
Wie gesagt, ich versorge den CPLD mit einem Akkupack.

> Verbinde GND der Zielplattform mit dem USB Gehäuse/Masse vor dem
> Einstecken des Programmers.

Dieses USB-Gehäuse wäre dann der PC? Der USB Blaster hat ein 
Plastikgehäuse. Das äußere Metall der USB-Mini-B Buchse am Programmierer 
ist mit seinem GND verbunden.

: Bearbeitet durch User
Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Orginal USB-Blaster gibt's im Manual folgenden Hinweis:

To avoid damaging the USB-Blaster cable, first unplug the
cable from the 10-pin header on the target board before
unplugging the cable from the USB port on your PC.

was sicherlich dem Buffer geschuldet ist (bei dir 74HC244).
Das gleiche wird wohl auch für die Clone gelten, d.h.
wenn bei dir mal USB wegfällt (PC aus etc.) kann's für
die Buffer/Treiber evtl. gefährlich werden (hier TDI,
der wird doch vom CPLD getrieben?).

Ein zweiter Punkt, der aber bei dir ausgeschlossen ist
aber trotzdem nicht vergessen werden sollte:
Dein CPLD lässt sich ca. nur 100x programmieren, danach
ist das Flash "verbraucht". (bei mir war's bei einem
Xilinx XC9572xl so, da wurden nach einem Programmieren
nur noch die IO-Pins entsprechend gesetzt)

Autor: J. O. (einjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten

Sigi schrieb:
> Beim Orginal USB-Blaster gibt's im Manual folgenden Hinweis:
>
> To avoid damaging the USB-Blaster cable, first unplug the cable from
>  the 10-pin header on the target board before unplugging the cable
> from the USB port on your PC.

Das hab ich schon ein paar mal gemacht. Mal rasch das USB Kabel am 
Blaster abzuziehen ist verlockend. Aber da waren CPLD und HC244 jedoch 
nie an 5V...

> was sicherlich dem Buffer geschuldet ist (bei dir 74HC244). Das
> gleiche wird wohl auch für die Clone gelten, d.h. wenn bei dir mal
> USB wegfällt (PC aus etc.) kann's für die Buffer/Treiber evtl.
> gefährlich werden (hier TDI, der wird doch vom CPLD getrieben?).

(TDO kommt vom PLD)
.. deshalb verstehe ich noch nicht, warum das den HC244 beschädigt?
Der HC244 "hängt" im Programmierer ohne Versorgungsspannung und kriegt
vom Controller darin bereits 3.3V Signale (wenn USB vom laufenden PC 
angesteckt ist). Tristate wird im HC244 nicht genutzt, die -OE sind fest 
auf GND. Wenn mein CPLD ohne Spannung ist, wäre das nicht einfach 'nur' 
eine "Verlängerung" des USB Blasters - am gleichen GND Potential?

> Ein zweiter Punkt, der aber bei dir ausgeschlossen ist aber trotzdem
>  nicht vergessen werden sollte: Dein CPLD lässt sich ca. nur 100x programmieren

Ja, ist eine kleiner beiläufiger Satz versteckt im Datenblatt /-:
Wie war das bei Deinem Xilinx? Gab es dann eine Fehlermeldung?
Das "Verify" sollte dann nicht klappen, oder?

Ist das mit dem 3,3V Controller im USB-Programmierer und zum CPLD mit 
einem "schwebenden" HC-Buffer für ggf. 2-6V überhaupt so eine wirklich 
saubere Lösung?

Also, ich tausche den HC244 aus und halte mich brav an die Reihenfolgen.
Mal sehn, ob er dann länger hält.

Macht es Sinn, zusätzlich noch den Pull-Down an TCK und den Pull-Up an 
TMS eizubauen, wenn nur ein CPLD in der Kette programmiert wird? Bzw. 
100 Ohm Serien-Widerstände (wie beim ByteBlaster)?

: Bearbeitet durch User
Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J. O. schrieb:
>> gefährlich werden (hier TDI, der wird doch vom CPLD getrieben?).
>
> (TDO kommt vom PLD)
stimmt, mein Fehler! Aber was kaputt gehen kann, wenn
man obige Regel nicht beachtet weiss ich jetzt auch nicht.
(btw: bei einigen Xilinx-Clonen ist der treibende Chip ein
XC9500xl, und bei dem ist die Reihenfolge bein Einschalten
bzgl. Spannungen "sehr" egal, d.h. nicht so empfindlich
wie der Altera Blaster)

Schau mal ins Sheet des 244, vlt. findet man das was(?).

J. O. schrieb:
> Wie war das bei Deinem Xilinx? Gab es dann eine Fehlermeldung?
> Das "Verify" sollte dann nicht klappen, oder?
An das Verifiing kann ich mich nicht mehr erinnern, nur
noch daran, dass die Reset/Init-Pegel an den Ausgängen
korrekt waren (hm, seltsam, funktioniert vlt. jetzt noch).

J. O. schrieb:
> Ist das mit dem 3,3V Controller im USB-Programmierer und zum CPLD mit
> einem "schwebenden" HC-Buffer für ggf. 2-6V überhaupt so eine wirklich
> saubere Lösung?

Wie man's wirklich narrensicher machen kann weiss ich
auch nicht. Wie oben schon gesagt, gibt es XC9500XL-Lösungen
(oder CoolrunnerII) basierend auf 2 IO-Bänken, je eine für
den USB-Chip (3V3) und eine für das CPLD/FPGA (3V3,2V5, 1Vx ...).
Damit fährt man schonmal recht sicher (glaube, dass der
orginal-Xilinx-Programmer so aufgebaut ist).

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J. O. schrieb:
> Lothar M. schrieb:
>> 1. Unter Spannung gesteckt.
>
> Welche Spannung? Vom Ziel (5V), vom USB Blaster (intern 3.3V wenn am
> laufenden PC gesteckt) oder beide?

Eventuell solltest du einmal die Spannung zwischen PC (mit Erde 
verbunden) und dem USB Netzteil messen. Das wird sicherlich nicht 
geerdet sein und hat deswegen zur Entstörung einen Kondensator eingebaut 
(Stichwort: Y-Kondensator).

Allerdings wird damit die Masse des USB Netzteils auf 120V angehoben. 
Die möglichen Ströme sind zwar relativ klein, aber vielleicht reicht das 
ja schon aus um den 244 beim Einstecken des 10 poligen Kabels zu 
beschädigen. Einfachste Abhilfe wäre das USB-Netzteil immer zuletzt 
einzustecken.

Autor: J. O. (einjo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mike schrieb:
> Eventuell solltest du einmal die Spannung zwischen PC (mit Erde
> verbunden) und dem USB Netzteil messen. Das wird sicherlich nicht
> geerdet sein und hat deswegen zur Entstörung einen Kondensator eingebaut
> (Stichwort: Y-Kondensator).

Was meinst Du mit USB-Netzteil?
Der USB-Blaster kriegt seine 5V vom PC. Intern arbeitet der mit 3,3V.
Der HC244 (im Blaster) bekommt seine 5V via dem 10-pol. Kabel. Gleiche 
Spannung wie der MAX7032S braucht und das ist einfach nur ein 5V Akku 
(nicht geerdet ;).

: Bearbeitet durch User
Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigi schrieb:
> To avoid damaging the USB-Blaster cable, first unplug the
> cable from the 10-pin header on the target board before
> unplugging the cable from the USB port on your PC.
Das ist aber irgendwie logisch oder?
Wenn Du das Teil von hinten her treibst, ohne dass es Spannung hat, 
überfährst Du seine Ausgänge. Das geht mit keiner Schaltung lange gut.

> Dein CPLD lässt sich ca. nur 100x programmieren, danach
> ist das Flash "verbraucht".
"Verbraucht"?

Sagen wir "kaputtprogrammiert"?

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5208367:
> Das ist aber irgendwie logisch oder?

Im konkreten Fall, d.h. bezogen auf die konkrete
Schaltung des Programmiergeräts schon, iA aber
nicht: ich habe ja Oben von einer Schaltung mit
einem XC9500XLer geschrieben, bei dem ist die
Reihenfolge beim Einschalten (IntVCC, IO-VCC und
Pin-Signal) egal, d.h. da sollte eigentlich nichts
kaputtgehen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.