Xilinx Multiprozessor - Reset Problem

HWILK schrieb:
> Reset Button auf dem Spartan3A-DSP Board drücke,
Wird der Taster entprellt? Und das Signal einsynchronisiert?

> wird immer nur der erste MicroBlaze neu gestartet. Der zweite bleibt
> stehen.
Hängen die wirklich an der selben Leitung?
Ist die Software die auf den Prozessoren läuft unabhängig voneinander?
Kommunizieren die Prozessoren miteinander?

> Wenn ich im SDK die Debug
> Perpektive öffne und dann den Reset drücke, haben beide Prozessoren den
> Status "Terminated"?
Das wird vermutlich über den xmd ausgelöst. Über den Weg könntest Du Dir 
ein tcl-Skript schrieben, welches beide Prozessoren startet.

Duke

Hallo

Ich nehme den Standard Reset Button von meinem Xtreme Spartan-3A DSP 
Board. Der dürfte eigentlich entprellt sein.
Das komische ist ja, wenn ich beide MicroBlazes parallel laufen lasse 
und die über FSL kommunizieren, dann funktioniert alles prima. Drücke 
ich aber den Reset Button, dann stirbt der zweite MicroBlaze. Der erste 
wird neugestartet, zumindest meistens :-)
Nur der MicroBlaze, der über den JTAG Uart kommunizieren sollte, bleibt 
hängen.
Das weitere komische ist, im Debug Modus funktoniert es. Dort wird der 
MicroBlaze ordnungsgemäß per Reset neugestartet. Warum?

Ich verwende EDK und SDK 13.1. Die MicroBlazes sind an getrennten PLBs 
und kommunizieren über den FSL. Beide sind an das MDM debug Modul 
angeschlossen. Der erste MB sendet per UART IP, der andere per JTAG UART 
(Dieser MB funktioniert nicht).
Der Reset wird über den proc_sys_reset IP verteilt. Dort kommt das 
Signal vom Button als externer Reset rein und dann sollte ein MB_Reset 
ausgeführt werdem. Dieser reset ist an beiden MicroBlazes.

Sorry für die schlechte Beschreibung. vielleicht hat trotzdem jemand 
eine Idee. vielen Dank

Der Taster ist sicherlich nicht entprellt!

Der arme Taster ijst nicht entprellt. Herrje. Nun löst er 100 mal einen 
Reset aus, der Böse.

Christian R. schrieb:
> Dann gibts die lustigsten Effekte beim Loslassen...
Hat er ja auch geschrieben:

HWILK schrieb:
> Der erste
> wird neugestartet, zumindest meistens :-)

Da muß offenbar jeder mal selber durch...

1

  -- generate synchronous reset

2

  reset_synchronizer : process(areset, clk)

3

  begin

4

    if areset = '1' then

5

      reset_shiftreg <= (others => '1');

6

    elsif rising_edge(clk) then

7

      reset_shiftreg <= reset_shiftreg(reset_shiftreg'high-1 downto 0) & '0';

8

    end if;

9

  end process;

10

11

  reset <= reset_shiftreg(reset_shiftreg'high);

Duke