Ultrascale+ Dokumentation/Information allgemein

[Jens Langecker (Gast)]

Hallo zusammen,

ich entwickle eine Firmware für einen R5-Kern auf einem Ultrascale+ und 
tu mir richtig schwer, die notwendigen Informationen zu finden.

Beispiel:
Gestern wollte ich einen Watchdog einbauen.

1. Ich schau in das system.mss des Boardsupportpackage und finde dort 
zwei Instanzen von "XWdtPs": psu_wdt_0 und psu_wdt_1.

2. Im Code-Beispiel für "XWdtPs" steht drinn, welche Schnittstellen es 
gibt, um die Register zu beschreiben, aber es steht nicht drinn, was man 
in diese Register reinschreiben muss, um z.B. ein Timeout von 5ms 
einzustellen.

3. Ich schau ins Datenblatt (UG1085) unter "System Watchdog Timers" und 
sehe dort, dass es drei Watchdogtimer gibt (LPD_SWDT, FPD_SWDT, 
CSU_SWDT).
Welcher dieser drei WDT ist denn nun psu_wdt_0 und welcher ist 
psu_wdt_1?

4. Im Datenblatt steht, dass jeder der WDT einen 24-Bit-Zähler hat. In 
der SW-Doku zu XWdtPs_SetControlValue() steht, dass man als Restartwert 
zwischen 0 und 0xFFF einstellen kann, also nur 12 Bit. Ich bin verwirrt.

5. Nach langem Suchen finde ich unter
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
die Beschreibung der "CONTROL (SWDT) Register" und sehe dort, dass man 
dort die 12 MSBs des 24-Bit-Restartwerts einstellt. Aha.

6. Nach noch längerem Suchen finde ich im "xparameters.h" das define 
"XPAR_PSU_WDT_0_WDT_CLK_FREQ_HZ" und kann mir jetzt endlich das Timing 
zusammenreimen.

7. Endlich kann ich meinen Watchdog richtig konfigurieren und ich sehe 
auch, dass er nach der erwarteten Zeit das "Watchdog reaches zero"-Flag 
im Statusregister setzt.
Aber: Der erwartete Reset wird nicht ausgelöst.

8. In irgendwelchen Foreneinträgen finde ich einen Hinweis, dass der 
gewünschte Reset nicht vom Watchdog direkt, sondern von der PMU 
(PlatformManagementUnit) ausgelöst wird, sofern diese richtig 
konfiguriert ist.

9. Nach stundenlangem Herumprobieren mit PMU_Registern klappt es 
endlich, dass der Watchdog einen Reset auslöst, allerdings bleibt der R5 
nach dem Reset im FirstStageBootloader hängen.
Und da häng ich im Moment.

Aber jetzt mein eigentliches Problem: Es kann doch nicht so schwer sein, 
die notwendigen Informationen für einen trivialen Watchdog zu finden?! 
Da mach ich doch irgendwas falsch.
Jede Hilfe ist willkommen.

[Duke Scarring (Gast)]

Jens Langecker schrieb:
> Aber jetzt mein eigentliches Problem: Es kann doch nicht so schwer sein,
> die notwendigen Informationen für einen trivialen Watchdog zu finden?!
> Da mach ich doch irgendwas falsch.
Nein, das glaube ich nicht.

Ich stecke momentan mehr oder weniger selbst in einer Entwicklung auf 
Zynq-Basis.
Der Fehler liegt m.E. im Marketing von Xilinx. Da wird ständig was von 
fast timt-to-markek gefaselt. Ist es aber nicht.
Da ist einfach nix schnell gemacht. Man muß Zeit mitbringen, selbst wenn 
diverse Erfahrungen vorhanden sind.

FPGA, ARM, Embedded-Software und Linux sind jeweils komplexe Themen. Im 
Zusammenspiel wird es definitiv nicht einfacher.

Zum eigentlich Problem: Du könntest bei Xilinx mal nach dem Technical 
Reference Manual (TRM) suchen (docnav). Möglicherweise gibt es da mehr 
Details zum Watchdog.

Duke

[Jens Langecker (Gast)]

Duke Scarring schrieb:
> Zum eigentlich Problem: Du könntest bei Xilinx mal nach dem Technical
> Reference Manual (TRM) suchen (docnav). Möglicherweise gibt es da mehr
> Details zum Watchdog.

Danke.
Das TRM ist das angesprochene UG1085.
Dann werd ich mich mal durch die PMU wühlen...

[A. Haak (Gast)]

Jens Langecker schrieb:
> 9. Nach stundenlangem Herumprobieren mit PMU_Registern klappt es
> endlich, dass der Watchdog einen Reset auslöst, allerdings bleibt der R5
> nach dem Reset im FirstStageBootloader hängen.
> Und da häng ich im Moment.

Wurde das Problem inzwischen gelöst? Ich habe lediglich das Bit 
PMU_GLOBAL_ERROR_POR_EN_1_LPD_SWDT_MASK aktiviert, bleibe allerdings im 
FirstStageBootloader hängen.