Hallo zusammen,

habe meine Hardware für ein SpartanII Board jetzt fertig und bin dabei
es in Betrieb zu nehmen. Ich benutze das etwas veraltete Xilinx
Parallel Cable III (DLC5) und versuche jetzt mit Xilnx Impact (neuste
Version) das FPGA zum leben zu erwecken.
Ich kommuniziere über die JTAG Schnittstelle (TDI,TDO,TMS,TCK), habe
meine IO Standard auf LVTTL (3,3V Vio) gesetzt.

Wenn ich das Cabel "aktiviere" erkennt es auch ein angeschlossenes
Device.
Lade ich das Bit File (innerhalb Impact) und starte "get device id"
bekomme ich folgende Fehlermeldung:
iMPACT:583 - '1': The idcode read from the device does not match the
idcode in the bsdl File.
INFO:iMPACT:1578 - '1':  Device IDCODE :
00001111111111111111111111111111
INFO:iMPACT:1579 - '1': Expected IDCODE:
00000000011000010000000010010011

Jetzt scheint mir diese Folge von Einsen doch sehr merkwürdig. Daher
habe ich nochmal die gesamte Hardware geprüft. TDI, TDO, TMS, TCK-alle
korrekt angebunden ohne Schluß oder ähnliches.

Zuletzt habe ich dann mal TDI, TD, TMS, TCK mit dem Scope
aufgezeichnet. Es läßt sich aber erkennen, daß alle 4 Signale sowohl
high wie auch low getrieben werden können und TDO auch Nullen
aufweist.

Kann mir bitte jmd. einen Tip geben? Ich habe alls geprüft. Vom
Datenblatt des FPGA über das des Cabels....

Ich kann das Scope-Bild noch nachträglich anhängen wenn jmd. mir dann
besser helfen kann.

Wäre euch wirklich dankbar wenn jemand mir helfen kann!!

Hallo

Ich hatte ähnliche Probleme bei einem selbstgebauten
Parallelprogrammierkabel. Eventuell sind deine Jtag Kabel zu lang oder
deine Spannungsversorgung ist nicht stabil genug. Bei mir waren es
fehlende Kondensatoren auf meinem CPLD Board (selbstbau). Beim
programmieren treten hohe Stromspitzen auf und wenn die Kabel zu lang
(Induktivitäten)sind oder die laut App.Note oder Datenblatt
vorgeschriebenen Kondensatoren fehlen bricht die Spannung ein und das
wars ...
Nach anbringen der Kondensatoren ging es übrigens fehlerfrei auch mit
1000fachem ID Code lesen (als Test gedachte Funktion im Impact).
Hoffe mal ich konnte dir irgendwie helfen.

Grüße Cpt

Moin...

Wie hast du Spartan, Prom und Kabel verbunden? Die Bezeichnungen am
Kabel sind irreführend, es wird nicht die übliche Chain weitergeführt.
Normalerweise ist ja immer TDO mit den nächsten TDI verbunden. Stimmt
nicht bei Stecker, da muss TDO auf TDO.

Ansonsten im Stecker des Kabels oder ganz nah am Stecke kleine
Blockkondensatoren anbringen.

--
 Sven Johannes

Danke erstmal für euer Tips!

Die Versorgung ist mit hohem Aufwand betrieben worden, um die Xilinx
Spezif. bezüglich C's und vor allem (bei Spartan2) bezüglich der
geforderten Power On Rampe einzuhalten. An jedem Vccint und Vccio sind
100nF Abblock C's direkt am Chip. Hinter den Längsreglern (2,5V u 3,3V
sind nochmal größerer C's. Des weiteren getrennte Ground Planes etc...

Die Sache mit TDO auf TDO oder TDI habe ich schon durch - das paßt
soweit.

Das Kabel vom Adapter zum Chip ist ca. 40cm lang - daran kanns meiner
Meinung nach nicht liegen. Die Signale sehen auf dem Scope auch gut
aus.

@Johnnes - wo soll ich denn deiner Meinung nach noch C's anbringen?
Doch nicht etwa an den TDI-TDO Signalen. Du meinst doch sicher die
Versorgungspins des FPGA?

Ich komme einfach nicht weiter - vielleicht ist das Cabel III einfach
nicht geeignet??

Wäre nett wenn ich noch einige Tips bekomme!

Danke, Daniel

Hi!

Das Kabel hängt aber am PC Parallelport, oder hast du etwa nen
usb->parallel wandler dran ?

Nee, schon klar!  Das Problem mit dem USB zu Parallel ist bekannt :-)

Habe hier auch noch ein CPLD XC.... liegen, das wird tadellos an der
JTAG Schnittstelle erkannt...

Bin noch immer am Suchen - habe die Versorgung nochmal geprüft-aber
alles klar - Spannungen sind sauber

Ich weiß jetzt einfach nicht mehr weiter und meine Motivation läßt
stark nach...

Habe das Kabel (vom Adapter zum Chip) jetzt nochmal verkürzt - nix,
immernoch die selbe Sch....

Grüße Daniel

Ah ok ;)

Also bei meinem gekauften digilent Kabel (war bei nem Spartan3 Evalkit
dabei) ist das Kabel PC<->Adapter gut 1.2m lang.
Die Buchse fürs Programmieren ist direkt auf der Platine mit dem
74xxx.
Hast du es evtl umgekehrt ?

Aber auch bei dem gekauften Kabel habe ich ab und an Programmierfehler
(bei vielen Hdd zugriffen zur gleichen Zeit zb)

Ist denn der gelesene ID Code immer der selbe oder nicht? Wenn die ID
ständig eine andere ist würde ich sagen, daß es ziemlich sicher ein
Kommunikationsproblem ist.
Andernfalls würde ich nochmal die bsdl Datei überprüfen und
sicherstellen, daß wirklich alles richtig ist (Typ,Speedgrade etc.)
Bin gespannt mehr zu hören.

Viel Erfolg
Cpt

@ssssssssssssssssssss

Klare Sache. Ich meinte auch das 74xxxx --> Target Kabel.

Ich hatte auch mal so ein ähnliches Problem, das als ID-Code nur Einsen
gelesen wurden. Das lag am CPLD, der nicht richtig verlötet war und ein
Pin ca 0.1mm über dem verzinnten Pad der Leiterplatte schwebte.
Bei Impact hat man die Möglichkleit, die Pins für Debugging einzeln zu
setzen. Einfach mal messen, ob die Logikzustände auch richtig
ankommen.

Henrik

>Klare Sache. Ich meinte auch das 74xxxx --> Target Kabel.
Also ich meinte folgendes:

PC <---- 1.2m ------->[platine mit 74xx]<-- 0cm ! ---> Stecker
<---direkt aufs board gesteckt.

Keine Ahnung ob das was ausmacht, ich kenn das aus der Uni von ti jtags
die sehr leicht streiken wenn man das kabel progadapter<->dsp nur gering
verlängert...

Hi

Ich hatte damit auch mal ewig rumgemacht. Schau dir bitte mal das TDO
Signal an, ob es sich beim Auslesen überhaupt bewegt. Sieht es nach
einem binären Signal aus oder bleibt es high (wie die ausgelesene ID)?

Meiner Erfahrung nach können C's auf den JTAG Datenleitungen sogar
stören. Hast schonmal die Answer Records nach "Spartan JTAG" etc.
durchsucht?

Grüße
Ralph

@ssssssssssssssss
Wir meinen genau das gleiche :-) . Ich kenne das Xilinx-Dev-Board da is
alles direkt auf der Platine, wenn mans aber selber baut ...

@alle
Also von Kondensatoren an den Datenleitungen kann ich nur abraten. Die
verfälschen das Signal doch erst recht!

Die ausgelesene ID sieht wirklich sehr merkwürdig aus. Eindeutig zu
viele Einsen.

Cpt

Ok, danke erstmal an Alle!

Aber

1. TDI,TDO,TCK,TMS habe ich mit dem Scope aufgezeichnet und alle
Signale können high und low annehmen und tun das auch. Das heißt es ist
kein Schluß oder ähnliches zwischen den Pins. Auch die Pullups/Downs
sind alle korrekt.

2. Die gemessenen Signale sehen immer gleich aus. (Triggerung auf TCK
und Aufzeichnung der gesamten Kommunikation). Auch der ausgelesene ID
Code ist immer der selbe.

3. C's an TDI und TDO verfälschen nur die Signale- sehe ich
genauso-das bringt einen Tiefpaß mit sich der nicht erwünscht ist

4. Das Kabel vom Adapter zur Platine habe ich um ca. 5cm verlängert, da
ich die JTAG Signale nicht auf einen Stecker sondern direkt an
vorgesehenen Lötpads neben dem Chip angelötet habe.

5. Answer Records habe ich alle gelesen-aber das ist bei Xilinx immer
so eine Sache mit ordentlichen Informationen.

6. Habe mit dem Impact Tool mal TDI, TCK, TMS vorgegeben und gemessen -
alles wie erwartet. es gibt einfach eine falsche Antwort seitens des
FPGA

@ Henrik: Ich habe die Pins TDI,TDO,TCK,TMS am FPGA nochmals geprüft.
Die sind alle kontaktiert. Das Gleiche gilt für Vccint und Vccio.
Kann es denn sein das noh irgendwelche anderen Signale, die eventuell
nicht richtig verlötet sind, die JTAG Kommunikation stören??

...würde mich über weitere Tips freuen.

Danke Daniel

Nochmal an CPT

bevor ich den BSDL File lade meldet Xilinx schon, das das erkannte
Device "UNKNOWN" ist, also der ausgelesene ID CODE nicht in der
Datenbank, die ich zudem aktualisiert habe, enthalten ist.
Der ausgelesene ID-Code, wie im ersten Beitrag zu sehen, ist

Device IDCODE :
00001111111111111111111111111111

und bleibt auch immer so, egal wie oft ich das ganze wiederhole.
Das heißt ich brauche den BSDL File meines Design gar nicht erst zu
laden.

Trotzdem läßt sich auf dem Scope sehen, das sich auf TDO was tut. Es
kann also nicht sein, das die Signale aufgrund von Hardwarefehlern auf
high oder low "festhängen".

Ich werde gleich mal bei der Xilinx Support Hotline anrufen, ob ers
vielleicht doch am Kabel liegt.

Habe gestern zudem noch ein CPLD Board in Betrieb genommen. Das
funktioniert mittels JTAG, auch mit meinen +5cm Kabel vom Adapter zum
Stecker.


Grüße Daniel

Hi!

Was macht dein Kabel wenn du kein Board dran hast ?
Bzw was meldet impact dann ?
Oder verbinde mal TDO und TDI mit nem 10K R (sicherheitshalber) und
lass impact nochmal scannen (STRG+I glaub ich)

Entweder spinnt dein Kabel irgendwie oder der Spartan2 spinnt irgendwie
?
Poste doch mal den ausschnitt aus dem Schaltplan wie der Spartan mit
dem jtag anschluss verdrahtet ist.

Gruss,
Simon

Hi Simon,

mit dem gleichen Kabel läßt sich ein CPLD, was hier rumliegt,
programmieren.

Wenn ich kein Board dran habe meldet Impact das nichts dran ist :-)

Was soll der 10K denn bringen? Ich werds mal testen, kann ich mir aber
nicht vorstellen. Wie gesagt, die Scope Bilder sehen gut aus.

Wie oben beschrieben geht ich mit dem Adapter direkt auf die Pads neben
den FPGA Pins. Das ist soweit alles korret. zig fach geprüft.


Vielleicht ist mein Spartan auch hin... Ich weiß im Moment nicht mehr
weiter.

Langsam wird es echt seltsam... Wenn sich auf TDO was tut, dann sollten
ja nicht nur Einsen ankommen. Wenn du damit nicht erfolgreich einen
CPLD programmieren könntest hätte ich jetzt noch auf den Modus der
paralleln Schnittstelle getippt (EPP,SPP ...). Da musste ich auch die
richtige Einstellung im Bios suchen. Aber wenn das mit dem CPLD
funktioniert??? Das wäre im Moment das letzte was mir noch einfällt.

Cpt

Du solltest die kurzen, bunten Verbindungskabel verwenden, welche mit
dem DCL5 mitkommen. Die CPLD's sind unkritischer.
Ich verwende auch den Parallel Cable III. Bei CPLD's XC95xxXL kann ich
zwischen dem grauen Kästchen und dem Board ein längeres, selbstbemachtes
Kabel werwenden und es funktioniert.
Bei den Spartan3's muß ich die kurzen Strippen verwenden.

Grüße
Klaus

"Kann es denn sein das noh irgendwelche anderen Signale, die eventuell
nicht richtig verlötet sind, die JTAG Kommunikation stören??"

Nicht, dass ich wüßte. Aber den Spartan 3 habe ich auch noch nicht
verwendet.

Henrik

Poste doch bitte mal den Schaltplan wie du was verkabelt hast.
Vielleicht ist dort irgendwas falsch/fehlt was...

Moin...

Die Kondensatoren an TDI bzw. TDO des Kabels sollen Schaltspitzen
wegfangen. also 100pf-1nf oder soetwas, keine "Filter". Hat
zuminestens bei einem Kollegen geklappt, das Signal war böse mit Spikes
durchsetzt, lag am PC.

Schon mal versucht im "compatible" Mode, also mit 200kHz zu
verbinden? Das hat bei mir ein CableV zum laufen gebracht, das
ansonsten auch nicht wiederzubeleben war. (Klingt vielleicht nicht so:
ja in der Abteilung gibts auch Kabel die funktionieren. Nur sind die
immer verliehen oder auf Reise.)

Ansonsten mal die Kette durchgehen, wo die Signale verschwinden. Leider
hat man ja auch mal ein faules Ei dazwischen.

--
 Sven Johannes

Ok, danke Leute.

Habe eure Beiträge studiert und nochmal alles versucht, bis ich den
Chip mutwillig zerstört habe :-)

Ich glaube und hoffe es lag an meiner Verlötung. Habe den 144pinner von
Hand eingelötet.... (zwar alles unter Lupe, mit ESD Schutz etc..)
könnte sein das ich da noch irgendwo ein Härchen übersehen habe.

Morgen bekomme ich ein neues, fertiges Muster von unserer Fertigung
(Wellen Lötung) - dann geht nochmal alles von vorne los.

Meld mich wenn ich Neuigkeiten habe.

Danke an alle
Daniel

Hallo Leute,

habe heute von unserer Fertigung 4 neue Platinen bekommen. Diese sind
bestückt mit 2 verschiedenen FPGA's (XC2S30 und XC2S50)

Habe beide in Betrieb genommen. Spannungen ok, Stromaufnahme ok....

JTAG angebunden und... der gleiche Fehler!! - bei beiden Typen wird der
gleiche besch.... ID Code ausgelesen.

Jetzt weiß ich wirklich nicht mehr weiter - ob ich mir einfach mal
testweise das Cabel IV bestellen sollte?

Obwohl Xilinx im Datenbaltt angibt, das die JTAG Configuration
unabhängig von den Pegeln der Configurtaion Pins M0..M2 bedienbar ist,
habe ich diese Pins mal auf die Pegel gelegt, die für JTAG angegeben
sind - immernoch der gleich Fehler.

Hat noch irgendwer einen Rat?
Übrigens: Die Schaltpläne darf ich leider nicht veröffentlichen, sorry
- ich hoffe ihr helft mir trotzdem weiter wenn ihr noch ne Idee habt

Die TDI,TDO;TMS Signale sehen übrigen sauber aus - als C's zum spikes
glätten ist nicht erforderlich

Danke Daniel

Ist die Stromversorgung am FPGA OK? Wird die richtige Spannung vom board
an das JTAG Kabel geliefert?

Hallo Daniel

Du hattest oben mal geschrieben, dass die vier JTAG Datensignale auf
high und low gehen können, also folglich nicht kurzgeschlossen sind
oder leer laufen. Aber rührt sich am TDO Pin wirklich was, wenn du den
ID Code ausliest? Stell mal ein Oszi Bild davon rein. Am besten mit TCK
und TDO.

Ich hatte nämlich mal das Problem, das der TDO wirklich "gezappelt"
hat und iMPACT hat dann nur Nullen ausgelesen. ChipScope war dann
schlauer und hat wenigsten einen falschen ID Code angezeigt, der aber
nicht nur lauter gleiche Bits hatte sondern dem TDO entsprach. Mein
Problem war damals, dass ich keine R's in Serie drin hatte. Das wird
IMHO aber nur beim Spartan3E benötigt.

Gruß
Ralph

Hi Ralph,

hier ein scope-Bild. Getriggert auf die erste Flanke TCK nach Auslösung
der Anforderung "getDevicecId"

Kann dir auch noch ein "gezoomtes" Bild schicken.

grün: TCK
blau: TDO
gelb: TDI
rto: TMS


Danke, Daniel

Hi

Das ging ja schnell :-)

TDO bleibt bis auf den Anfang tatsächlich auf high, was bei mir damals
nicht der Fall war.

JTAG GND und FPGA GND hast du zusammen?

Es gibt doch im iMPACT die "Debug Chain". Ich habe damit fast noch
nie rumgespielt, aber funktioniert das wenigstens?

Hast du den Xilinx Support deswegen schonmal angeschrieben? Die sind
eigentlich recht fit.

Gruß
Ralph

Hallo Ralph,

klar geht das schnell-hab ja im Moment nur das eine Problem und komme
einfach nicht weiter..

ja, natürlich sind die GND's verbunden. Ist ja gerade meine IO Voltage
mit der ich den Adapter versorge.

Debug Chain geht auch. Kann TDI, TCK und TMS beliebig setzen.

Habe auch schon mit den Jungs von Xilinx telefoniert. Die sind auch
ratlos im Moment und auch da warte ich auf Antwort.

Ich frage mich was ich die letzten 5 Tage überhaupt geschafft habe??
Manchmal hasse ich den Job...

Hat denn noch irgendwer eine schlaue Idee? Hab ich irgendwas
übersehen?


Grüße
Daniel

Ok, wenn es hilft poste ich jetzt doch mal den Schaltplanauszug.
Zu sehen ist die Versorgung mit den benötigten Bauteilen zur
Realisierung der durch Xilinx Spezifikationen geforderten "Power on"
Rampe und das FPGA selber.

Bitte keine Fragen hierzu. Die Schaltung ist notwendig um alle
Spezifikationen bezüglich der Versorgung einzuhalten. Wer sich auskennt
und doch Fehler entdeckt meldet sich natürlich bitte :-)

Zu finden ist diese Schaltung in etwas anderer Form auch auf der TI
Hompage. Dort wird sie erklärt und ist unter dem Stichwort "powering
FPGA guide" zu finden.

TDI,TDO,TCK,TMS wurden nur auf testpads gelötet. Da ist aber alles
sauber bei der Verbindung mit dem Adapter.

Sieht jemand jetzt mehr??

Grüße Daniel

Hallo Daniel

Wie sehen denn die Signale auf der PC-Seite aus?
Gleicher Verlauf, wie auf der FPGA-Seite?

Welcher Chip wird denn im Xilinx Parallel Cable III für die
Pegelwandlung verwendet?

MfG
Holger

Hallo Holger

Die Signale auf der PC Seite habe ich noch nicht gemessen. Bin davon
ausgegangen, das wenn ich ein CPLD (XC9572) damit programmieren kann,
der Adapter dann ok sein sollte, oder? Habe auch schon im Bios alle
Möglichkeiten für den Parallel Port durch... hilft alles nix

Im Adapter sitzen 74HC125 Bausteine. Versorgt wird er mit 3,3V (meiner
IO Voltage)

Aber der ausgelesene ID Code "000011111111111111..." ist ja auch auf
dem scope zu sehen. Sprich TDO sendet einfach das Falsche, oder?
Kann ja am PC (hinter dem Adapter) nicht besser werden, oder?

Aber wenn Du in irgendeine Richtung einen Tip hast wäre ich sehr sehr
dankbar.

Danke Daniel

nochmal ein Schaltplan des Adapters (Xilinx Parallel Cable III)

Hm, an einem Spartan 3 Design seh ich PullUps an den JTAG Leitungen,
im spartan2 datanblatt hab ich nichts dazu gefunden.

TDO ist innerhalb des Adapters über 5K1 an Vcc angebunden.

TDI, TMS, TCK sind nicht angebunden. Hab da auch keine Infos zu
gefunden. Aber die Signale auf dem scope sehen doch sauber aus

OK, machen wir mal einen Schlachtplan! Die fronten sind

1. Stromversorgung
2. Verdrahtung JTAG-Kabel -FPGA
3. andere Verdrahtung
4. das JTAG Kabel
5. JTAG-Signal
6. JTAG-Software

1. scheint mir messtechnisch noch nicht geprüft, aber beim design hat
mal wohl schon drauf geachtet. Dennoch Einschaltreihenfolge und Rampe
überprüfen. Und wenn möglich während JTAG läuft auf Spannungseinbrüche
triggern. Spartan2
insbesondere 2E als Industrial hat enorme Anforderungen an Power on -
Surge.
Ich sehe noch 50% chance das der fehler hier hockt.

2. vielleicht 5% Fehlerwahrscheinlichkeit. Die Pinnummern im schematic
sind für JTAG ok (wenn tq144), aber das layoutprogramm kann Fehler
haben. Die FPGA Typbezeichnung hast Du sicherlich gecheckt. 100 %
sicher sind wir, wenn Du die betreffenden pins auszählst (jeweils
zweimal, von rechts und links) und dann auf Durchgang zum
entsprechenden JTAG TP durchklingelst. Sicht von oben und Sicht von
unten verwechseln ist immer wieder beliebt.

3. Lt. Xilinx sollen die ModePins bei JTAG egal sein, Glauben wir das
mal. Wie
ist es mit ProGRAMM,CS  und INIT? Sind die wirklich so beschaltet, das
nix falsches passieren kann?!

4. wenn das Kabel an dem CPLD funzt, sollten wir auf der richtigen
Seite sein. Vorsichtshalber checken ob das TDOetc  vom Kabel auch auf
das TDOetc vom CPLD geht und somit auch auf das vom FPGA.

5. lt. scope bild sind die Pegel und Flanken OK. Setup, hold und max.
TCLK-f kann ich auf dem JPEG nicht bestimmen. Hänge vor der Messung
alle Testköpfe an das selbe Signal. ich hatte schon mal zwei Köpfe ,
wovon einer 2 ns nachging. Böse Falle. Mich verwundert der leichte
höhere Pegel beim Ausschieben des Wortes, aber er versetzt mich nicht
in Unruhe. 2% das hier der Bug liegt.

6. Also bitgen und impact. Bitgen kommt wohl noch nicht zum Zuge,
bleibt impact.
Ist das gesendete Signal auch das für get_device_id ?! In der XAP503
ist ein schema für diesen Befehl für ein CPLD angegeben. Flüchtig
geprüft ist es ein anderes Schema als auf Deinem Scope Bild. Kannst du
auf einen funktionierenden Board den JTAG Stream aufzeichnen?
Vielleicht hat Xilinx Bildchen wie get_device_id auszusehen hat. 30%
das der fehler hier lauert.
Hast Du einen anderen PC mit andere impact version, der bisher tadellos
lief?
Check mit diesem.

Rückfallvariante:
Nicht über JTAG sondern bit-seriel laden (DI,CCLK,PROGRAMM,Init,CS).
Geht zumindest mit PC 4. Geht aber auch schief wenn der bug in der
stromversorgung sitzt.


Vielleicht kann ein anderer hier, mal ein JTAG get_device_id auf
spartan2 aufzeichnen.


Nicht unterkriegen lassen.

Guten Morgen Küchle :-)

mußte gestern auch mal Feierabend machen :-)
Habe gerade mal deinen Beitrag komplett gelesen.  Danke erstmal -
scheinst dich ja auszukennen.
Die meisten Punkte habe ich so berücksichtigt wie von dir beschrieben.
Ich schaue jetzt nochmal alles von oben bis unten ganz genau durch und
schreibe dir dann in ein paar Stunden was zu den einzelnen Punkten.

Danke, Daniel

FPGA-KÜCHLE - ich danke Dir! Du hattest Recht mit der 50% Chance. Punkt
eins war richtig!

Es läuft jetzt! Schuld war der Feedback Kondensator am Längsregler.
(Dieser dient der Rauschunterdrückung)

Dieser hat dazu geführt, das die letzten 200mV der Ausgangsspg. nach
einer langsamen e-Fkt. angestiegen sind und somit meine Rampe schon am
Ende war als der Längsregler noch gar nicht fertig war.

Von 0-2,3V hat die Rampe eine wunderbare Steigung aufgewiesen, danach
änderte sich dies jedoch drastisch. Obwohl die Steigung von 2,3-2,5V
noch in den Spez. liegt dauerte der Gesamtanstieg von 0-2,5V mehr als
50ms.

C927  (100nF) durch 10nF ersetzen und alles eird gut :-))))

fazit: Die Power On Geschichte ist bei Xilinx wirklich ernst und Wort
für Wort aus dem Datenblatt zu nehmen.

Ich danke euch allen nochmal vielmals. Vielleicht hilft diese
Diskussion ja noch dem einen oder anderen

Danke,
Daniel

Was, so empfindlich sind die ?!

Das glaub ihc irgendwie nicht...
Also ich hab bei meinem selbstentwickelten Spartan3 Board
100nF und 22uF hinter allen Reglern.
Dazu auch nochmal überall 10,47,100nF an jedem Versorgungspin...

War dein 100nF evtl defekt ? oder fehlte einfach nur ein 10nF (vonwegen
irgendwelcher Störungen)

Gruss,
Simon

Nein, so empfindlich sind die. Steht alles im Datenblatt.

Spezifikationen bezüglich minimum Power-On Current, Rampe,
Sequenzielles einschalten etc..

Guck dir den Schaltplan an den ich gepostet habe. Da siehst du den
Konni C927 um den es geht. Wenn Du dir dann noch das Datenblatt zu dem
eingesetzten LDO TPS79625 ansiehst, siehst du, das der Konni einen
internen Tiefpaß für die Regelung bildet, wodurch Noise unterdrückt
werden kann. Dieser Konni darf max. 100nF betragen.

Bei 100nF wir jedoch die Einschaltdauer enorm verzögert, so das die
Spezifikationen für die Rampe nicht mehr eingehalten werden.

10nF macht das Ding schneller und die Rampe läuft wie erwartet.

Gruß Daniel

Spartan2 und noch stärker Spartan2E sind sehr wählerisch während des
PoerUps. Lt. Xilinx treiben Slices gegeneinander vor der Konfiguration.
Deshalb werden über 1A PowerOn Surge gezogen.
Lt. Xilinx und diversen FAE's äusserts sich eine Missachtung durch
Misslingen der Konfiguration. Offenbar funzt auch JTAG nicht richtig.
Spartan3 ist da entspannder.

Siehe Xilinx AppNote XAP450.

MfG

Hi!

Ah sorry hab in dem riesenschaltplan vorhin nicht nachgeguckt welchen C
du meintest ...
Ok, dort wo er sitzt vergiss einfach meine aussagen gg

Aber interessant zu wissen dass die spartan2 da so empfindlich sind.
;)

Gruss, Simon

Hi

Freut mich für dich, dass es jetzt geklappt hat! Die Aufgabe eines
Inscheniörs besteht halt leider zu 80% solche Fehler zu entdecken und
nur ein kleiner Teil ist wirklich kreativ...

Im Nachhinein sieht man das eventuell sogar an dem Osziausdruck von
dir, da das TDO-Signal nicht ganz auf high ist sondern mal ganz leicht
schwankt.

Grüße
Ralph