Spartan Slave Serial Programming

Gustav G. OP #7483268
Lesenswert?
• ▲
▼

Ich habe probleme beim programmieren eines Spartan 3 über den slave serial mode. Die Programmierung habe ich von einem Atmega328 auf einen STM32F1 portiert. Der einzige Unterschied ist, dass ich die CCLK und DIN nun nicht über SPI laufen lasse, sondern die Takte in Software generiere, da beide SPI Port belegt sind.

Ich bekomme immer an der gleichen Stelle im Bitstream einen CRC Fehler, den INIT_B während der Programmierung signalisiert. Das passiert reproduzierbar recht nahe am Ende des Bitstreams.

Weiß jemand ob CCLK sehr empfindlich gegen Jitter ist, der bei dieser Art der Taktgenerierung eher katastrophal ist, da Interrupts dazwischen sind? Das ist im Moment mein einziger Ansatz.

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Falk B. #7483279
Lesenswert?
• ▲
▼

Gustav G. schrieb:

Weiß jemand ob CCLK sehr empfindlich gegen Jitter ist,

Nein, aber gegen unsaubere Flanken! Der Konfigurationstakt ist aus der gleichen Technologie gebaut wie die schauschnelle Logik. Wenn die Flanken nicht ASTREIN sind, holst du dir Doppelpulse und damit Fehler an den Hals. Siehe Wellenwiderstand.

der bei dieser Art der Taktgenerierung eher katastrophal ist, da Interrupts dazwischen sind?

Das ist egal, das ist wie SPI echt synchron.

Das ist im Moment mein einziger Ansatz.

Aber der falsche ;-)

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gustav G. OP #7483283
Lesenswert?
• ▲
▼

Falk B. schrieb:

Nein, aber gegen unsaubere Flanken! Der Konfigurationstakt ist aus der gleichen Technologie gebaut wie die schauschnelle Logik. Wenn die Flanken nicht ASTREIN sind, holst du dir Doppelpulse und damit Fehler an den Hals. Siehe Wellenwiderstand.

Das wird mit aktuell unter 1MHz programmiert und ich habe mir die Flanke mal in Scope angesehen. Sieht sauber aus.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gustav G. OP #7483799
Lesenswert?
• ▲
▼

Ich bin nun dahinter gekommen was schief gelaufen ist. Der INIT_B Pin wird von mit im Design als Input definiert mit Pulldown. Das scheint so nicht zu funktionieren. Wenn ich allerdings bei INIT_B die Einstellung auf NONE setzte kommt am Ende kein CRC Error mehr und mittendrin auch nicht mehr.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #7483822
Lesenswert?
• ▲
▼

Gustav G. schrieb:

Ich bin nun dahinter gekommen was schief gelaufen ist. Der INIT_B Pin wird von mit im Design als Input definiert mit Pulldown.

Fail.

Das scheint so nicht zu funktionieren. Wenn ich allerdings bei INIT_B die Einstellung auf NONE setzte kommt am Ende kein CRC Error mehr und mittendrin auch nicht mehr.

Zufall. INIT_B ist im FPGA ein open drain, der braucht einen externen Pull-Up!

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.