Hello, Guest the thread was called1.3k times and contains 6 replays

last post from Natas at the

Elektronik: SPI-Flash ISP-tauglich auf Platine packen

  • Hallo,


    das ist eigentlich eine Frage für ein Elektronikforum - aber hier scheinen ja genügend Kundige antreffbar zu sein und ich empfinde die Community hier einfach als angenehmer als das, was ich in dem einen oder anderen deutschen Elektronikforum schonmal mitlesen musste... insofern mich bitte sanft und liebevoll darauf hinweisen, wenn das Thema hier gar nicht reinpasst.


    Ich bastel ja gerne an FPGA-Zeugs (siehe https://github.com/maikmerten/riscv-tomthumb) und habe für diese billigen ~20 Euro FPGA Boards ("ep2c5 mini board", z.B. Ebay) eine Platine entworfen, die 512Kx8 SRAM, SPI-ROM (nun, eigentlich ist es ja Flash) und ein paar Pins für eine UART-Schnittstelle vorsieht:


    pcb.png


    Die Idee ist, beim Poweron/Reset den SRAM mit den Daten aus dem SPI-ROM zu initialisieren, damit anschließend der Softcore im FPGA mit vernünftigen (Programm-)Daten loslegen kann. Platine habe ich fertigen lassen und zusammengelötet - und funktioniert.


    Ich habe vorgesehen, den SPI-ROM entweder in einen Sockel zu packen (U2) oder auf die Platine selbst zu löten (U3). Im ersteren Falle würde man dann den SPI-ROM zum Programmieren von der Platine ziehen, im zweiten Fall würde man über den Sockel die Programmierung vornehmen - dann müsste ich aber die ganze Platine vom FPGA-Board herunternehmen, da die Leitungen direkt durchverbunden sind und ich die Signale des Programmers nicht einfach so auf den FPGA loslassen will (es ist i.d.R. keine gute Idee, an ICs, die nicht mit Versorgungsspannung versorgt werden, über die Signalleitungen was reindonnern zu lassen) und der Programmer auch nicht die 3,3 Volt-Schiene des FPGA-Boards befeuern soll.


    (Eine dritte Möglichkeit wäre natürlich, einen Programmer in den FPGA zu laden und dem dann z.B. über UART die Daten reinzureichen, dazu hatte ich aber bisher keine Lust.)


    Für eine eventuelle Weiterentwicklung möchte ich aber eigentlich das Teil über In System Programming (ISP) beschreiben - also SPI-ROM drauflöten, rauf auf das FPGA-Board und dann über eine Programmierpinleiste die Daten draufpumpen. Hier muss man natürlich aufpassen, dass nicht versehentlich sowohl Programmierer wie auch FPGA mit voller Kraft in entgegengesetzter Richtung an derselben Leitung ziehen - da verliert u.U. der weniger robuste und hat anschließend einen GPIO weniger.


    Ist es prinzipiell vertretbar, das wie folgt zu lösen?


    spi-isp.png


    Für R würde ich sowas wie 1K vorsehen - dann fließen im schlimmsten Fall 3,3 Milliampere zwischen Programmer und FPGA, was sowohl Programmer wie auch FPGA locker verkraften dürften. Ein Tauziehen müsste der Programmer im Zweifel immer gewinnen.


    Das Ganze soll insbesondere auch dann funktionieren, wenn der FPGA läuft, damit ich den nicht dauernd von der Spannungsquelle abstöpseln muss - deshalb kann auch weiterhin das Board den SPI-ROM mit Energie versorgen. Soll auch der Programmer Energie liefern dürfen, dann müsste ich eine Schottky-Diode für VCC vorsehen, um zu verhindern, dass das FPGA-Board über den Programmer gespeist wird. Dann habe ich da aber im Normalbetrieb einen Spannungsabfall auf der Versorgungsleitung des SPI-ROM und die Datensignale vom FPGA hätten auf einmal ein höheres Spannungsniveau als VCC am SPI-ROM. Das Datenblatt des SPI-ROM erlaubt "nur" VCC+0,4 Volt als "Absolute Maximum Rating", was mit einer einer gut gewählten Schottky-Diode einzuhalten sein müsste - aber ich kann gut damit leben, wenn ich nur bei betriebsbereitem FPGA-Board den SPI-ROM beschreiben kann.


    Habe ich da irgendwo einen fatalen Fehler in meinen Überlegungen, oder passt das vermutlich soweit? Danke!

  • Altera+Flash-Programmer ist jetzt nicht so meine Spezialität,
    da wird es aber sicherlich auch eine SPI-Lösung geben (kostet
    aber bei den Sdt.IPs schnell ein paar Hundert LEs). Leider ist
    bei deinem Board auch noch das Config-ROM schon dabei,
    ausserdem ist die der Pin DATA0 nach der Konfiguration nicht
    frei als IO, sonst hättest du dieses ROM als Ausgangpunkt
    verwenden können.


    Bleiben wir also mal bei deinem Ansatz. Ich würde CS vom
    Programmerpin evtl. in einen neuen FPGA-Pin einspeisen und
    mit diesem dann in der Flashphase die restlichen SPI-Pins
    Hi-Z setzen. Nachteil: Du verlierst einen FPGA-Pin und darfst
    um Gottes Willen nicht Flashen, wenn ein fremdes Design
    geladen ist.

  • Danke euch für den Input!



    Bleiben wir also mal bei deinem Ansatz. Ich würde CS vomProgrammerpin evtl. in einen neuen FPGA-Pin einspeisen und
    mit diesem dann in der Flashphase die restlichen SPI-Pins
    Hi-Z setzen. Nachteil: Du verlierst einen FPGA-Pin und darfst
    um Gottes Willen nicht Flashen, wenn ein fremdes Design
    geladen ist.


    Eine interessante Idee mit dem Extra-Pin, um dem FPGA mitzuteilen, er soll sich mal abklemmen.


    Sofern ich die Widerstände wie in der Skizze habe, dann sollte doch eigentlich auch bei Fremd-Designs nichts wirklich Schlimmes passieren: Der Programmer übernimmt de-facto den Bus und der FPGA liest Blödsinn und ggf. landen seine Schreibzugriffe im Nirvana - aber zumindest dürfte keine Hardware bei drauf gehen. Das ist zumindest das, was ich hoffe ;)

  • Hätte mir auch Gestern Abend schon einfallen können:
    Statt den CS-Pin in einen "neuen" FPGA-Pin einzuspeisen
    und entsprechend mit der Flash-Logik zu verknüpfen
    wäre es evtl. besser, einen Bustreiberchip (z.B. LS245 oÄ)
    dazwischen zu schalten und CS als EN# verwenden
    (=> kein extra Pin, keine Widerstände aber extra IC).

    aber zumindest dürfte keine Hardware bei drauf gehen. Das ist zumindest das, was ich hoffe

    Naja, das einzige Problem ist immer noch der MISO-Pin. Ein
    "fremdes" Design muss diesen ja nicht notwendigerweise
    als Eingang behandeln, da würde ich mir wenigstens noch
    Gedanken zu machen.

  • Ui, klar, ein Bustreiber wäre natürlich eine saubere Lösung - einen Widerstand bräuchte man aber doch, um !OE schwach gegen Masse zu ziehen, damit der nicht rumfloatet, wenn kein Programmer angestöpselt ist. ;-)


    Ansonsten habe ich endlich das gemacht, was ich längst hätte tun sollen: Einfach mal ein bisschen simuliert, was bei meiner Skizze oben denn so passiert, auch wenn es eigentlich trivial ist:


    buskollision.png


    Wer hätte es gedacht: Im Falle einer Buskollision gewinnt der stärkere Treiber... Captain Obvious und so :whistling: