Ich habe am FPGA (virtex2) einen Atmega angeschlossen, von dem eine
Leitung(reset) zum FPGA geht. Diese setze ich beim power ab, kurzzeitig
auf high und dann wieder low. Die Input-Leitung am FPGA ist LVTTL und
hat im ucf file noch einen Pulldown Widerstand bekommen. Komischerweise
wird mein FPGA trotzdem noch in unregelmäßigen Abständen resettet. Ich
habe leider keinen Scope da, der mir einmalig auf das Signal triggert
und das Bild behält (um herauszukriegen kann, was das für ein h-Pegel
ist und wie das Signal aussieht0). Das Signal kommt auf jeden Fall vom
Atmega, habe es überprüft, der wird 100% nicht neugestartet, also kann
das Reset-Signal nicht durch Fkt-Aufruf zum Anfang des Programms
ausgelöst.
Vielleicht mache ich aber doch noch was falsch und das sieht jemand
sofort.
MC Code:
#define CONTROL_REG DDRC
#define CONTROL_PORT PORTC
#define RESET PC3
...
CONTROL_REG |= (1<<RESET);
....
CONTROL_PORT |= (1<<RESET);
LONGDELAY;
CONTROL_PORT &= ~(1<<RESET);
...
----------------------------------
FPGA:
(ucf)
NET "RESET" LOC = "U12";
NET "RESET" PULLDOWN;
(vhd)
rstinbuf_mc : bufg port map(i => RESET, o => RESET_INT);
-----------------------------------------------------------------------
2 Sachen noch. (a) Reset vom MC klappt nach dem Einschalten, (b) wenn
ich die Leitung danach fest auf Masse lege, passieren diese ungewollten
Resets nicht.
Kann es sein, dass du irgendwo sonst im Code noch auf den CONTROL_PORT
schreibst und dabei versehentlich etwas an RESET änderst? Oder
alternativ auch am entsprechenden DDR? Könnte es sein, dass du
versehentlich Atmega-Peripherie auf dem betroffenen Port aktivierst?
Eventuell kommt das Signal auch nicht von Atmega, sondern eine unsaubere
oder unterdimensionierte Spannungsversorgung des FPGAs löst dessen Reset
aus. Würde ich zumidnest nicht ausschließen, aber um das zu überprüfen
bräuchte man auch wieder ein Scope.
@ Frager: verstehe nicht was du damit meinst
@ David: hilft bei meinem Problem wahrscheinlich auch nicht weiter
@ mr.chip: Ja, die anderen Pins des Ports haben auch ihren Einsatz,
jedoch wird RESET Pin dabei nicht angefasst.
@ Matthias: Nein, wenn ich die Resetleitung fest auf GND Pin anklemme,
wird auch kein RESET ausgelöst und das FPGA Board läuft fröhlich weiter.
Ich werde heute testweise eine andere Leitung am MC nehmen und darauf
RESET legen.
@ Gast (Gast)
>@ mr.chip: Ja, die anderen Pins des Ports haben auch ihren Einsatz,>jedoch wird RESET Pin dabei nicht angefasst.
Glaubst du das oder WEISST du das? Wenn es schliesslich mit einer auf
Masse gelegten Leitung geht, dann scheint ja doch was faul zu sein. Nur
ein kleiner Schreibzugriff auf den Port , und schwups!
>@ Matthias: Nein, wenn ich die Resetleitung fest auf GND Pin anklemme,>wird auch kein RESET ausgelöst und das FPGA Board läuft fröhlich weiter.
Eben!
MFG
Falk
>>Glaubst du das oder WEISST du das?
Ich weiß es, hab mir alle C Dateien genau angeguckt, Reset kommt dabei
nicht vor und anderen PINS auf dem PortC werden per Oder-Verknüpfung
geändert, dass RESET dabei so bleibt, wie nach dem Aufruf der
Reset-Funktion.
@ Gast (Gast)
>Ich weiß es, hab mir alle C Dateien genau angeguckt, Reset kommt dabei
Dann glaubst du immer noch. WISSEN tust du es erst, wenn du mit nem Oszi
das Pin anschaust und WIRKLICH keine Spikes siehst.
>nicht vor und anderen PINS auf dem PortC werden per Oder-Verknüpfung>geändert, dass RESET dabei so bleibt, wie nach dem Aufruf der>Reset-Funktion.
Und du hast sicher keinen einzigen Befehl übersehen .. . ?
MfG
Falk
>> Und du hast sicher keinen einzigen Befehl übersehen .. . ?
Ja 100%, ich habe es auch alles selbst programmiert.
>> WISSEN tust du es erst, wenn du mit nem Oszi das Pin.......
Ich meinte doch oben, dass kein Oszi da ist, der einmalig auf das Signal
triggern kann.
Und mich hinsetzen und die Leitung 4h beobachten (manchmal kommt sowas
erst nach 4h), kann ich mir nicht leisten, da macht mein Chef nicht mit
und meine Augen erst Recht nicht :)
Ich glaube jetzt jedoch das Problem gefunden zu haben.
>> #define RESET PC3>> ...>> CONTROL_REG |= (1<<RESET);
sollte eigentlich heißen:
#define RESET DDC3
CONTROL_REG |= (1<<RESET);
wobei im Endeffekt hinter jedem #DEFINE ob PC3, oder DDC3 immer eine 3
steht oder?
>>Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) >>identisch: (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke >>(1<<PC7),... zu (1<<7))>
@ Gast (Gast)
>> Und du hast sicher keinen einzigen Befehl übersehen .. . ?>Ja 100%, ich habe es auch alles selbst programmiert.
Mag sein, aber sowas übersieht man schon mal.
>Und mich hinsetzen und die Leitung 4h beobachten (manchmal kommt sowas>erst nach 4h), kann ich mir nicht leisten, da macht mein Chef nicht mit>und meine Augen erst Recht nicht :)
Dann bau dir einen Low-Cost-Oszi. Nimm ein 74HC74 und leg dein Reset an
den Takteingang. D auf VCC. mit CLR löschst du den Ausgang. Wenn nun ein
böser Puls kommt, lädt das FlipFlop eine 1, die am Ausgang per LED
angezeigt weren kann. Läuft alles automatisch.
>wobei im Endeffekt hinter jedem #DEFINE ob PC3, oder DDC3 immer eine 3>steht oder?
Sicher.
MfG
Falk
>>wobei im Endeffekt hinter jedem #DEFINE ob PC3, oder DDC3 immer eine 3>>steht oder?>Sicher
@ Falk:
(sicher = ja, das ist egal) || (sicher = sicher macht das ein
Unterschied)
????
>> Dann bau dir einen Low-Cost-Oszi.
Gibt aber keine Aussage über die Impulsbreite und den Spannungspegel.
@ Gast (Gast)
>(sicher = ja, das ist egal) || (sicher = sicher macht das ein>Unterschied)
Es ist sicher das gleiche.
>> Dann bau dir einen Low-Cost-Oszi.>Gibt aber keine Aussage über die Impulsbreite und den Spannungspegel.
Aber es gibt eine chance, einen Puls durch einen Programmierfehler zu
finden. Der ist nämlich mind. 1 Takt breit. Glitches oder EMV wird man
nicht zuverlässig finden, aber ggf. eine Ahnung entwickeln.
MFG
Falk
