Spartan 6 will einfach nicht

[Jens W. (jensw)]

Hallo zusammen,
ich bin am verzweifeln. Ich finde den Fehler nicht.
Ich habe ein Design gemacht mit Controller und FPGA. Hier kommt ein 
Atxmega und ein Spartan 6 XC6SLX9 zum Einsatz.
Ich habe die Leiterplatten bestellt, händisch aufgebaut und mit 
Mikroskop geprüft auf Brücken und so weiter. Alles gut. Nichts 
auffällig.
Die Spannungen sind alle gut. Der Mikrocontroller macht keine Probleme.
Das FPGA wird nicht warm. Über JTAG ist auch alles gut. Lesen, Schreiben 
kein Problem.
Aber die Pins bleiben stumm. Und ich habe keine Ahnung warum.
Der Takt wird vom Mikrocontroller erzeugt (internen Takt nach außen 
geführt). Ist auch gemessen mit ausreichen Bandbreite und Equipment. Der 
Takt ist auch da und passt.

Ich habe nun ein zweites Board aufgebaut, da ich dachte, dass das FPGA 
vielleicht einen weg hat.
Aber das zweite Board hat genau den selben Fehler und verhält sich 
identisch zum ersten.

Ich habe euch den Schaltplan und das Projekt für Xilinx ISE (ich 
verwende ISE 14.7) mit angehängt.

Ich bin so frustriert weil das billigste Programm nicht funktionieren 
will!
Und, noch dazu, da das Programm auf einem Spartan 3 läuft! Es soll doch 
nur eine LED blinken....

Irgendwie habe ich so den Verdacht, dass es mit der Entwicklungsumgebung 
zu tun haben muss. Und wahrscheinlich ist es auch ein Anfängerfehler. 
Das ist mein erster Versuch mit einem Spartan 6.

Ich hoffe ihr könnt mir weiter helfen.

Vielen Dank!

Grüße, Jens

[PingPong (Gast)]

Den Plan kann man ja kaum lesen! :(

So auf dem ersten blick fällt mir DONE und der fehlende Basiswiederstand 
zur Transe auf.

Starten kann der FPGA nur wenn DONE auch 1 ist. Mein vorschlag wäre die 
Transe erst mal einen Basis R zu verpassen und DONE mit einem 330 Ohm 
PULLUP zu bestücken.

[. . (Gast)]

Hast Du das schon gelesen?
Das war ein ähnliches Problem.
https://forums.xilinx.com/t5/FPGA-Configuration/SPARTAN-6-CONFIGURATION-PROBLEM/td-p/429094

[Helmut S. (helmuts)]

Warum gibt es keinen (50MHz)-Clock in dem Schaltplan oder übersehe ich 
etwas?

[Jens W. (jensw)]

Ich bin ein Hirsch!
Genau das ist es!

Der Transistor hält die Spannung auf 0,6V wenn kein Basiswiderstand drin 
ist.
Ich habe nun einen 2,2k Basiswiderstand hingefädelt und habe den Pullup 
auf 330R erhöht.
Nun ist der Pegel zu Beginn schonmal richtig.

Einen 50MHz Quarz gibt es, aber der ist momentan nicht bestückt.
Der Clock kommt aus dem Mikrocontroller (32MHz interner Takt).

Jetzt habe ich aber noch ein Problem:
Wenn das FPGA über JTAG konfiguriert wurde, bricht das Signal an der 
Clock-Leitung (µC_PWM_15/EVENTOUT an Pin 22 am FPGA) bricht auf 0V 
zusammen.

Der clk_in wurde auf LVCMOS33 eingestellt. Was ergibt das denn für eine 
Eingangsimpedanz? Wo kann ich das denn nachlesen? Ich habe zu den 
Ausgangstreibern noch nicht das Richtige gefunden.

Grüße und Danke soweit!!!

[Helmut S. (helmuts)]

Helmut S. schrieb:
> Warum gibt es keinen (50MHz)-Clock in dem Schaltplan oder übersehe ich
> etwas?

Ich sehe gerade in der .ucf Datei ist P22 dein clk_in. An dem Pin 22 ist 
bei dir dieses Signal angeschlossen: 3C_PWM_15/EVENTOUT/4.5A
Liegen da, wie im Testprogramm erwartet, 32MHz an?

[Gustl B. (-gb-)]

Der Schaltplan ist sehr wahrscheinlich unvollständig.

In der .ucf steht:
NET "clk_in"  LOC = "P22" | IOSTANDARD = LVCMOS33 ;
NET "led_blink"  LOC = "P29" | IOSTANDARD = LVCMOS33;

Weder der Taktgeber noch die LED sind im Schaltplan zu sehen.

[Helmut S. (helmuts)]

Gustl B. schrieb:
> Der Schaltplan ist sehr wahrscheinlich unvollständig.
>
> In der .ucf steht:
> NET "clk_in"  LOC = "P22" | IOSTANDARD = LVCMOS33 ;
> NET "led_blink"  LOC = "P29" | IOSTANDARD = LVCMOS33;
>
> Weder der Taktgeber noch die LED sind im Schaltplan zu sehen.

Im Testprogramm sehe ich aber nur die Verwendung von clk_in.



architecture Behavioral of Spartan6_Test is

constant clk_freq : integer := 32000000;
constant blink_freq : integer := 10;
constant cnt_max : integer := clk_freq/blink_freq/2 - 1;
signal cnt : unsigned(20 downto 0);
signal blink : std_logic := '1';

begin

--Counter für die blinkende LED
led_counter: process (clk_in) begin
    if (clk_in='1' and clk_in'event) then
        if cnt = cnt_max then
            cnt <= (others => '0');
            blink <= not blink;
        else
            cnt <= cnt + 1;
        end if;
    end if;
   end process;

  led_blink <= blink;

end Behavioral;

[Gustl B. (-gb-)]

Helmut S. schrieb:
> led_blink <= blink;

Wird ebenfalls verwendet. Passt schon, sind aber nicht im Schaltplan zu 
sehen. Wenn jetzt aber alles wie gewünscht funktioniert ist das 
irrelefant.

[Jens W. (jensw)]

Hallo,

ja der Schaltplan ist nicht vollständig.
Aber ich schrieb ja, der Takt kommt vom µC.
Der Atxmega bietet die Möglichkeit den Systemtakt nach außen zu führen.
Und das geht direkt an den Pin vom FPGA (so wie oben angegeben an P22).
Andere Takte gibt es sonst nicht. Im Schaltplan nicht und bestückt ist 
auch nichts anderes.

Mich wundert nur, dass ich den Clock messen kann, solange das FPGA nicht 
konfiguriert ist.
Sobald es konfiguriert ist bricht das Signal zusammen.
Also muss es mit der Config zu tun haben.

Gruß, Jens

[Gustl B. (-gb-)]

Jens W. schrieb:
> Sobald es konfiguriert ist bricht das Signal zusammen.
> Also muss es mit der Config zu tun haben.

Da wäre jetzt eben der Schaltplan hilfreich. Wenn du den Takt z. B. an 
einen anderen Pin anlegst als du in der .ucf geschrieben hast, dann kann 
es sein, dass der per Pulldown nach Masse gezogen wird. Falls 
eingestellt ist, dass alle unbenutzten IOs nach Masse gezogen werden.

[Jens W. (jensw)]

Hmm, mir scheint wir reden aneinander vorbei oder ich habe was 
übersehen.

Der clk_in (VHDL) ist der Takt, der vom Controller kommt (heißt im 
Schalplan "µC_PWM_15/EVENTOUT/4.5A"). Das Signal ist auch da, solange 
das FPGA noch nicht konfiguriert ist.
Das ist vom FPGA der Pin P22 und das steht auch im .ucf File so drin.

led_blink ist am FPGA Pin P29 und geht nur auf ein Testpad. Da ist keine 
richtige LED angeschlossen. Da gehe ich nur mit dem Tastkopf auf das PAD 
zum Messen.

So, und nun gehe ich mit dem Programmer auf das FPGA und schreibe das 
bit-File. Die LED an DONE geht an, led_blink geht von '0' auf '1' und 
das Taktsignal bricht sofort auf 0V zusammen.
So als wenn der Pin am FPGA das Signal auf Masse zieht.
Und da kein Takt mehr, kommen auch die 10Hz an led_blink nicht. Klar 
ohne Takt.

Gruß, Jens

[Gustl B. (-gb-)]

Ja, genau. Im ISE das du vermutlich verwendest kann man einetsllen, dass 
alle unbenutzten IOs nach Masse gezogen werden. Wenn du da also einen 
Pin verwechselt hast dann wird vielleicht das Taktsignal nach Masse 
gezogen.

Um zu testen ob das FPGA überhaupt konfiguriert wurde und gestartet ist, 
könntest du intern einen schlechten Taktgeber aus einer Reihe von 
Gattern verbauen. Oder du könntest auf dem IO für die LED einfach nur 
das ausgeben was am Taktpin anliegt. Also:

led_blink <= clk_in;

Dann solltest du an dem Ausgang die Clock sehen/messen können. Wenn das 
aber nicht der Fall ist, dann trennst du mal vom clk_in Eingang den 
Mikrocontroller und legst da statich +3.3V an und guckst ob dann auch 
led_blink auf high geht. Mit einem Signalgenerator oder einem anderen 
uC-IO kannst du ja ja mal langsam zwischen 1 und 0 wechseln.

[Jens W. (jensw)]

Hallo,

ich habe nochmal an einem anderen Pin einen Takt eingespeist.
Gleiches Verhalten. Gut, der kommt auch vom µC, aber ich toggel in SW 
einfach einen Pin und erhalte etwa 2Mhz. Zum Messen sollte das reichen.

Wenn ich während dem Betrieb die unbenutzten Pins vom FPGA messen, dann 
erhalte ich an allen Pins 2,2kOhm gegen GND. Da würde ich etwas 
hochohmiges erwarten. Soll doch ein Eingang sein.

Mit einem stärkeren Taktsignal (Signalgenerator) traue ich mich noch 
nicht, nicht dass ich das FPGA grille.

Woher kann das kommen? Wie kann ich das global einstellen, dass die 
nicht genutzten Pin nicht gegen GND gezogen werden?
Und warum kann der Mikrocontroller keine 2,2kOhm treiben?
Oder ist das nur ein Messfehler?

Grüße, Jens

[Jens W. (jensw)]

Hallo,

also die PullDowns für die Default Pins waren es.
Ich habe das auf float umgestellt und nun geht es.

Alle Signale so, wie ich es erwarten würde.

Vielen Dank an alle!

Grüße und einen guten Rutsch ins neue Jahr!
:-)

[Gustl B. (-gb-)]

Jens W. schrieb:
> Zum Messen sollte das reichen.

Ja. Passt der Spannungspegel?

Jens W. schrieb:
> Wenn ich während dem Betrieb die unbenutzten Pins vom FPGA messen, dann
> erhalte ich an allen Pins 2,2kOhm gegen GND. Da würde ich etwas
> hochohmiges erwarten. Soll doch ein Eingang sein.

Ungenutzte Pins sind kein Eingang und kein Ausgang. Typischerweise 
werden die entweder über einen Pulldown nach Masse gezogen oder über 
einen Pullup zur Versorgungsspannung. Das passt also. Das wird gemacht 
damit kan keine floatenden Pins hat die dann hin und her wackeln.

Jens W. schrieb:
> Mit einem stärkeren Taktsignal (Signalgenerator) traue ich mich noch
> nicht, nicht dass ich das FPGA grille.

Ja, an einen ungenutzten Pin mit Pullup oder Pulldown solltest du das 
auch nicht. Aber an den clk_in Pin kannst du da schon rangehen. Der 
clk_in Pin ist ja als Eingang definiert. Wenn du da den uC trennst, 
solltest du den auch als hochohmig messen können. Du kannst auch beim 
Generator einen Widerstand in Reihe schalten zur Strombegrenzung. 1k Ohm 
sollte passen.

Jens W. schrieb:
> Und warum kann der Mikrocontroller keine 2,2kOhm treiben?

Naja, das muss er ja nicht. Sobald du einen IO vom FPGA als Eingang 
definierst ist der hochohmig.

Ich würde jetzt erstmal gucken ob das FPGA sich korrekt aus dem Flash 
konfiguriert. Und dazu könntest du im VHDL entweder einen internen Takt 
bauen (http://www.lothar-miller.de/s9y/categories/29-Ringoszillator ) 
und ausgeben oder du machst eine Logikverknüpfung zwischen einem Eingang 
und einem Ausgang. Letzteres hast du ja eigentlich gemacht, aber zum 
Testen würde ich zuerst etwas ohne Takt machen. Z. B.:

led_blink <= clk_in;

Und dann an clk_in mal 3.3V anlegen und mal mit Masse verbinden und 
gucken was an led_blink rauskommt.

Warte mal, ich schreibe dir eine VHDL zum testen.

Edit:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity Spartan6_Test is Port(
  led_blink: out  STD_LOGIC);
end Spartan6_Test;

architecture Behavioral of Spartan6_Test is

signal oscff   : std_logic := '0';
signal ring    : std_logic_vector(31 downto 0):=(others => '0');
attribute KEEP : string; 
attribute KEEP of ring : signal is "true"; 

begin
-- die Gatterkette
ring <= ring(30 downto 0) & not ring(7);
-- das Symmetrier-Flipflop
process begin
  wait until rising_edge(ring(31));
    oscff <= not oscff;
  end if;
end process;
-- die Ausgangszuweisung
led_blink <= oscff;
end Behavioral;

Das braucht keinen Eingang und hat nur led_blink als Ausgang. Da 
solltest du einen Takt sehen wenn alles passt. Die Frequenz kann ich 
leider nicht gut abschätzen, das Hängt vom IC selbst ab. Ich würde so 
zwischen 10 MHz und 50 MHz vermuten. Das kannst du mit dem Oszi 
angucken.

Edit:

Jens W. schrieb:
> Alle Signale so, wie ich es erwarten würde.

Glückwunsch!

Jens W. schrieb:
> Grüße und einen guten Rutsch ins neue Jahr!
> :-)

Vielen Dank! Den guten Rutsch wünsche ich dir auch.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jens W. schrieb:
> also die PullDowns für die Default Pins waren es
Kann dein uC keinen 10k-Pulldown treiben?

> Ich habe das auf float umgestellt und nun geht es.
> Alle Signale so, wie ich es erwarten würde.
Offene, floatende CMOS-Eingänge sind schlecht. Denn dann fließt gern mal 
nach ein paar Minuten, wenn sich ein "stabiler Pegel" auf Vcc/2 
eingestellt hat, ein satter Querstrom durch alle unbenutzen 
Eingansstufen. Auf diese Art kann man leicht das FPGA überhitzen. Du 
solltest also ab&zu mal den Finger drauf halten oder die Stromaufnahme 
kontrollieren...

[Weltbester FPGA-Pongo (Gast)]

Lothar M. schrieb:
> Offene, floatende CMOS-Eingänge sind schlecht. Denn dann fließt gern mal
> nach ein paar Minuten, wenn sich ein "stabiler Pegel" auf Vcc/2
> eingestellt hat, ein satter Querstrom durch alle unbenutzen
> Eingansstufen. Auf diese Art kann man leicht das FPGA überhitzen.

Hatte ich in 25 Jahren noch nie. Das müssten aber schon sehr viele 
Eingänge sein.

Was ich dem TE mal raten würde:

Geht das Erkennen des FPGA im JTAG und das Auslesen der User-ID?

[Andi (Gast)]

Lothar M. schrieb:
> Offene, floatende CMOS-Eingänge sind schlecht. Denn dann fließt gern mal
> nach ein paar Minuten, wenn sich ein "stabiler Pegel" auf Vcc/2
> eingestellt hat, ein satter Querstrom durch alle unbenutzen
> Eingansstufen. Auf diese Art kann man leicht das FPGA überhitzen.

Wieso sollte sich ein offener Eingang auf die halbe Spannung aufladen? 
Dazu bräuchte es eine hochohmige negative Rückkopplung. Auch wenn der 
Eingang mal zufällig auf die halbe Spannung floatet, ist da ja noch die 
Hysterese am Eingang, was einen Querstrom sicher verhindert.

[Helmut S. (helmuts)]

> Wieso sollte sich ein offener Eingang auf die halbe Spannung aufladen?

Wegen dem Gate-Leckstrom des NMOS- und des PMOS-Transistors am Eingang. 
Wenn sich da dann die Eingangsspannung auf die Hälfte der 
Betriebsspannung einpendelt, dann fließt ein hoher Drainstrom durch den 
NMOS und PMOS. Da hilft auch eine Hysterese des Eingangs nicht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Weltbester FPGA-Pongo schrieb im Beitrag #6090852:
> Hatte ich in 25 Jahren noch nie. Das müssten aber schon sehr viele
> Eingänge sein.
Ich schon. drum erwähne ich es. Und deshalb gibt es auch die Option, 
Pullwiderstände für definierte Pegel einzuschalten.

Andi schrieb:
> Wieso sollte sich ein offener Eingang auf die halbe Spannung aufladen?
Weil er es kann... ?
Und dann passiert das, was dort bei 2. beschrieben ist:
http://www.vias.org/mikroelektronik/dig_cmos.html

[Jens W. (jensw)]

Hallo zusammen,

@Weltbester FPGA-Pongo: Ja das Ansprechen über JTAG ist kein Problem. 
Auch die ID kann ich lesen.


Ich habe nun alle nicht benutzten Pins auf Pull Up gestellt. Damit geht 
es auch.

Den Fehler verstanden habe ich immer noch nicht.
Der Controller hat normalerweise genug Power um die Pins zu treiben, 
wenn da ein Pull Down dran ist. Laut Datenblatt soll der ja in der 
Größenordnung 25kOhm liegen. Keine Ahnung wo das her kommt.
Wenn ich der Einzige bin, der dieses Problem hat, dann wird es wohl an 
mir liegen. Das ist dann kein systematischer Fehler.

Trotzdem vielen Dank an alle!

Grüße, Jens

[Gustl B. (gustl_b)]

Ohne Layout ist das schwer zu  beurteilen.

[Christophz (Gast)]

Jens W. schrieb:
> also die PullDowns für die Default Pins waren es.
> Ich habe das auf float umgestellt und nun geht es.

Ich rate einfach mal mit:

- Geht ein FPGA I/O zum Reseteingang des Controllers?
- Kannst du mit dem Controller noch kommunizieren nach dem der FPGA mit 
einem problematischen Bitstream konfiguriert wurde?

[T. F. (sar)]

Mein Tip: teste Mal ob ein Kurzschluss (Lötnrücke) zu einem benachbarten 
Pin besteht?

[Jens W. (jensw)]

Hallo zusammen,

ich bin ein Stückchen weiter und gleichzeitig auch nicht... :-(

Ich fang nochmal an und hänge euch den gesamten Schaltplan an:
Ich habe ein ähnliches Design das funktioniert problemlos. Das Einzige 
was sich da geändert hat ist, dass das alte mit einem Spartan 3 war und 
das neue Design ein Spartan 6 hat.
Konfiguriert wird immer über JTAG. Entweder über den Programmierstecker 
und Plattform Kabel (funktioniert immer), oder über den µC (Xapp058- 
XSVF Player).

Die Probleme von oben sind gelöst. Wenn ich mit dem Plattform Kabel ran 
gehe funktioniert alles. Done geht auf High und die LED leuchtet.
Wenn ich das per µC mache, dann geht Done nicht auf High.

Ich habe eine serielle Ausgabe und kann die Ergebnisse des XSVF-Players 
aufs Terminal ausgeben. Hier ist alle in Ordnung. Der Player meldet 
keinen Fehler.
Spiele ich das XSVF File über das Kabel ab, dann auch, kein Fehler, aber 
Done bleibt Low.
Signale habe ich alle gemessen, die passen. Kein Ringing oder Klingeln 
auf den Signalen.
Die waitTime() Kalibrierung habe ich auch gemacht. Die Zeiten passen und 
während TMS low ist, toggelt TCK.

Ich habe so langsam die Entwicklungsumgebung in Verdacht, dass da was 
nicht passt.
Aber ich habe keine Idee mehr, wie ich das Problem der Reihe nach weiter 
eingrenzen kann.

Wie sollte ich jetzt Schritt für Schritt vor gehen?
Ich hoffe ihr könnt mir hier weiter helfen.

Grüße, Jens

[Christian R. (supachris)]

Hast du in den Settings für den Bitstream den Startup Clock korrekt auf 
JTAGCLK eingestellt? Default ist glaube ich CCLK.

[Jens W. (jensw)]

Hallo Christian,

danke für deine Antwort.
Ich bin schon ein Stückchen weiter. Es muss an der Implementierung auf 
dem µC liegen.
Wenn ich das XSVF File über das Plattform Kabel abspiele, dann 
funktioniert alles. Dann sind auch alle Settings schon richtig, vermute 
ich.
Wenn ich dann umschalte auf den µC, dann geht es nicht mehr.

Ich werde jetzt als erstes nochmal alle Verbindungen auf der 
Leiterplatte nachmessen. Eine Stelle sieht suspekt aus.

Grüße, Jens

[jens (Gast)]

Hallo,

kurzer Zwischenstand:
Also auf der Leiterplatte war kein Problem.
Es bleibt dabei, mit dem Programmer startet das FPGA, mit dem µC nicht.
Init_B bleibt Low, das heißt, dass es bei der Prüfung einen CRC Error 
gibt.

Da habe ich auch schon viel gelesen, dass es da einige gibt, die dieses 
Problem haben, jedoch die Lösung war noch nicht dabei.

Die Funktion wait_time() war oft diskutiert. Ich habe die 
Implementierung so, dass die Wartezeit ziemlich genau passt von der Zeit 
her und während der Wartezeit wird TCK getoggelt. Sollte also passen.

Wer hat noch eine Idee?

Grüße, Jens

[Gustl B. (-gb-)]

Guck dir mal die Signale mit dem Oszi an. Vielleicht sehen die ja 
unschön aus. Wenn möglich kannst du auch die Geschwindigkeit 
runtersetzen und gucken ob es dann funktioniert.

So wie ich JTAG verstanden habe ist das eine Registerkette. Also kommt 
aus TDO nach einigen vielen Takten wieder das raus was du mit TDI 
reingeschoben hast. Vielleicht kannst du das vergleichen und gucken ob 
das stimmt.

[Jens W. (jensw)]

Hallo Gustl,

das habe ich nun am Wochenende auch angefangen. Und siehe da, das sieht 
nicht so aus wie ich es erwarten würde.
Ich habe die Signale mit dem Plattform Kabel mal aufgenommen.
Da muss ich aber noch intensiver rein gehen.

Was ich auch nochmal machen möchte, ist, dass ich die Daten aus dem 
internen Flash nochmal als Kopie auf die SD Karte zurück schreibe, und 
mit dem Original vergleiche. Ich rechne zwar einen CRC über die Files 
und da gibt es keinen Fehler, aber doppelt hält besser.

Ich bin jetzt nochmal zwei Schritte zurück gegangen und steige nochmal 
ein, sonst finde ich den Fehler nie.

Ich halte euch auf dem Laufenden!

Danke schonmal an alle!

Grüße, Jens

[Jens W. (jensw)]

Hallo zusammen,

es hat bisher wirklich lange gedauert, aber ich glaube ich bin einen 
Schritt weiter.
Sehr tückisch!
Der Fehler wird von einem zweiten verdeckt.

Beim Kopieren des XSVF Files auf das SPI Flash auf der Leiterplatte 
passiert ein Fehler bei den letzten 46Bytes. Also 340000Bytes sind 
richtig und die letzten sind falsch.
Das führt dazu, dass der Player versucht mehr Werte aus dem Speicher zu 
lesen als eigentlich da sind. Und diese Werte sind dann falsch, was 
natürlich zu einem CRC Fehler im FPGA führt.

Warum habe ich das nicht früher gesehen?
Ich berechne beim Kopiervorgang eine CRC Prüfsummen, die ich auch mit 
den geschriebenen Werten vergleiche. Und da habe ich den Fehler gemacht, 
dass ich die Werte, die ich ins Flash schreibe für den CRC her nehmen. 
Aber da sind die Werte schon falsch. Dann lese ich das Flash und rechne 
den wieder und klar, sind die beiden Prüfsummen immer gleich. Also der 
Schreib- und Lesevorgang zum Flash ist richtig.
Wenn ich aber über das File, das auf der SD Karte liegt den CRC rechne 
und den mit dem gelesenen vom Flash vergleiche, dann stimmt es nicht 
mehr.

Ich vermute, dass bei der Adressbrechnung des letzten Frames was nicht 
stimmt, oder er greift für die Werte ins Leere. Da kommt er 
durcheinander (ich kopiere in kleinen 256Byte Frames und der letzte ist 
dann nicht mehr komplett).

Den Workaround habe ich noch nicht. Das ist erstmal nur das Ergebnis von 
gestern Abend, dass ich überhaupt mal sehe, dass was nicht passt.

Vielen Dank an euch alle soweit.
Ich meld mich nochmal wenn es dann funktioniert, oder ob noch ein 
weiteres Problem ist.

Grüße, Jens

[Jens W. (jensw)]

Hallo zusammen,

also das wars! Es war tatsächlich der falsche Speicherinhalt.
Da ist das beim Kopieren falsch gelaufen.

Das ist jetzt richtig, die CRC Prüfsummen passen und siehe da, das FPGA 
läuft!

Danke an alle!
Das war echt ne harte Nuss!

Grüße, Jens