Guten Abend, ich hab eine Raspberry Pi kompatiblen HAT, auf dem ein FPGA-Modul ist. Das JTAG ist an den GPIOs des Pis angeschlossen (TCK GPIO12, TMS GPIO16, TDI GPIO20, TDO GPIO21). Auf einem Pi3 funktioniert OpenOCD mit BCM2835-Interface wunderbarst. FPGA wird in sowas 8s konfiguriert und es funktioniert quasi immer. Für den Pi4 hab ich herausgefunden, dass die Basisadresse eine andere ist (0xfe000000) und ich hab für OpenOCD Koeffizienten für das BCM2835-Interface gefunden, mit dem das Timing an den Pi4 angepasst wird. Funktionierte erstmal überhaupt nicht - wenn ich die Koeffizienten so anpasse, dass der Clock ca. 300kHz langsam ist, klappt es - aber nicht immer (und dauert fast 30 Sekunden). Über sysfs klappte es, aber ist noch langsamer. Ich frag mich, wieso reproduzierbar der HAT nicht auf einem Pi4 geht (drei Pi4 getestet mit 5 HATs und insgesamt 15 Modulen^^), aber ohne Probleme und mit wunderbarer Geschwindigkeit auf einem Pi3. Ich weiß, dass der Pi4 andere Register für die GPIO Pull-Ups und -Downs hat, aber die werden nicht benutzt. Mittlerweile vermute ich, dass die GPIOs nicht sauber auf Ausgang geschaltet werden, konnte aber noch nicht mit einem Oszi draufschauen. Alternativ dachte ich auch daran, dass die GPIOs vlt von einer Peripherie benutzt werden, aber im Device-Tree des Raspian Busters findet man nicht disbezügliches. Etliches Googeln hat mich leider nicht schlauer gemacht und solche Probleme hab ich sonst keine gefunden (außer das bereits Bekannt mit Basisadresse und PUPs/PUDs). Hat jemand ähnliche Beobachtungen gemacht? Viele Grüße, Mampf *edit*: Ich hab auch ein anderes Program zum Konfigurieren des FPGAs ausprobiert. Ich glaube es hieß irgendwas mit xvcpi oder so - ein Xilinx Virtual Cable driver für einen Pi, mit dem man sich vom Vivado hardware-manager hinconnecten und die GPIOs als Virtual JTAG Cable benutzen kann. Funktioniert auf einem Pi3 super, auf einem Pi4 wieder gar nicht.
:
Bearbeitet durch User
Hallo Mampf, leider kann ich dir nicht helfen. Ich wollte allerdings fragen ob du mittlerweile herausgefunden hast woran es liegt. Ich wollte einen STM32 programmieren, was mit dem alten Raspberry super funktioniert (per SWD über OpenOCD) mit dem neuen (auch mit angepasster Baseaddress) allerdings gar nicht :(
Gerald M. schrieb: > Hallo Mampf, > > leider kann ich dir nicht helfen. Ich wollte allerdings fragen ob du > mittlerweile herausgefunden hast woran es liegt. > Ich wollte einen STM32 programmieren, was mit dem alten Raspberry super > funktioniert (per SWD über OpenOCD) mit dem neuen (auch mit angepasster > Baseaddress) allerdings gar nicht :( Hallo Gerald, ja mittlerweile funktioniert alles. Die Probleme waren weg, als ich in der /boot/config.txt die Pull-Ups/Downs deaktivierte, die wohl standardmäßig an sind. Sah bei mir (für JTAG) dann in etwa so aus:
1 | # risc-v reset to pull-up |
2 | gpio=19=pu |
3 | |
4 | # fpga jtag |
5 | # tck |
6 | gpio=12=pn |
7 | # tms |
8 | gpio=16=pn |
9 | # tdi |
10 | gpio=20=pn |
11 | # tdo |
12 | gpio=21=pu |
Vlt ist es bei dir auch soetwas - die Pullup/down werden von der Software für Pi3 nicht konfiguriert, weil die Adressen andere sind. So nebenbei ... Gestern erst gesehen: https://medium.com/@ly.lee/openocd-on-raspberry-pi-better-with-swd-on-spi-7dea9caeb590 Dort wird SWD über SPI gemacht, was wesentlich schneller ist :) Vielleicht funktioniert das auch auf dem Pi4 :) Viele Grüße, Mampf
Hallo und schon mal vielen Dank! Das SWD über SPI habe ich bei der Suche nach der Lösung meines Problems auch schon entdeckt, nur brauche ich auch die SPI-Schnittstelle zur Übertragung von Daten zum Mikrocontroller. Ich komme von der Mikrocontroller Seite und den Charm den der Raspberry für mich ausmacht ist der, dass das meiste ohne viel zutun funktioniert (wenn es nicht funktioniert bin ich meist aufgeschmissen und muss viel googlen). Aktuell habe ich den Mikrocontroller wie angehängt an den Raspberry angebunden um: - debuggen und programmieren zu können - Via UART Befehle senden zu können - Via SPI live-Daten auszutauschen Ich glaube wenn man beispielsweise eine weitere SPI-Schnittstelle über die Alternativen GPIO Funktionen hinzufügt und diese dann für z.B. die live-Daten benutzt funktioniert eventuell etwas anderes nicht mehr, was sich bei einem Raspberry deutlich schlechter herausfinden lässt als bei einem normalen Mikrocontroller... Oder sind meine "Ängste" unbegründet? Danke und liebe Grüße Gerald
Gerald M. schrieb: > Ich glaube wenn man beispielsweise eine weitere SPI-Schnittstelle über > die Alternativen GPIO Funktionen hinzufügt und diese dann für z.B. die > live-Daten benutzt funktioniert eventuell etwas anderes nicht mehr, was > sich bei einem Raspberry deutlich schlechter herausfinden lässt als bei > einem normalen Mikrocontroller... > > Oder sind meine "Ängste" unbegründet? Hmm schwer zu sagen ... Ängste können zerstreut werden, indem man es einfach ausprobiert und feststellt, dass es geht - oder nicht :)
Ja, das stimmt schon. Ich werde vermutlich SWDIO und SWD_CLK auf GPIO20 und GPIO21 legen, so kann ich zunächst das Bitbanging nutzen. Falls mich die Geschwindigkeit zu sehr stört habe ich wenigstens so die Möglichkeit durch Zeiteinsatz das SWD Interface über den SPI1 Kanal laufen zu lassen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.