Nibo2: ISP scheitert wg. SPI-SCK-Überlagerung

[geekalert]

Hallo allerseits,

ich scheitere gerade daran meinen Nibo2 mittels ISP über mein STK600 zu programmieren, wundere mich allerdings weniger darüber warum es nicht geht, sondern wie es prinzipiell funktionieren soll:
Nibo2 verfügt über zwei Controller, den Hauptcontroller und den Cocontroller. Die Controller kommunizieren über SPI, wobei der Cocontroller als Master fungiert. ISP und SPI teilen sich am Hauptcontroller den SCK-Pin. Da ein ISP-Reset nur den Hauptcontroller zurücksetzt und der Cocontroller fröhlich die SCK-Leitung treibt, überlagern sich die Clock-Signale von ISP und SPI.
Sehe ich den Wald vor lauter Bäumen nicht, oder wie zum Teufel haben sich das die Leute von nicai-systems vorgestellt?
Wie bereits erwähnt verwende ich mein STK600 zum Programmieren, das mit avrdude von meinem Gentoo-Linux-PC angesprochen wird. Symptomatisch äußert sich oben geschilderte Überlagerung dadurch, das avrdude beim Auslesen der Device-Signatur scheitert. Diese ergibt sich meiner Meinung nach zufällig daraus, wie die beiden Clocks gerade zusammenfallen.
Zur Kontrolle habe ich erfolgreich den Attiny84 der NDS3-Erweiterung (das Distanzscanner-Modul von Nibo2) programmieren können.
Nebenbei sei noch erwähnt, dass ich den VTarget-Jumper am STK abgezogen habe (gemäß der Anweisung im STK600-User-Guide) und Nibos eigene Spannungsversorgung verwende. Die Akkus sind frisch und liefern mehr als genug Spannung (10.4V = 1.3V * 8 Zellen).
Ich bin sehr gespannt auf Eure Antworten.

Viele Grüße
Flo

P.S.: Nibo2 Schaltplan: http://download.nicai-systems.com/nibo/nibo2_schematic_2_04.pdf

[geekalert]

Tja, nun habe ich den letzten Zweifel ausgeräumt. Zieht man die Resetleitung des Cocontrollers händisch aktiv und unterdrückt damit das Clock-Signal der SPI-Verbindung zum Hauptcontroller, lässt sich der Hauptcontroller einwandfrei programmieren.
Bleibt die Frage, was sich der Hersteller dabei gedacht hat? Irgendetwas übersehe ich hier doch? Aber Nibo hat nun mal keinen Jumper o.ä. um entweder SCK abzuklemmen, oder die Resetleitungen zusammenzulegen. :confused:

[Achim S.]

Hallo
verstehe da was nicht so richtig. Wozu willst du das machen. Ich bin bei der programmierung noch nicht auf dieses Problem gestossen. Verwende das AVR MKII. Macht der andere Typ so viel Unterschied?
achim

[geekalert]

Der Programmierer sollte keinen Unterschied machen. Ich finde leider gerade das ISP-Adapterkabel nicht um mal mein JTAGICE MKII zu probieren.
Ein weiterer Blick auf den Schaltplan hat mich nun weiter verwirrt. Der tiefere Sinn der Beschaltung der RESET_IC2-Leitung, die dem Hauptcontroller ermöglicht, den Cocontroller zurückzusetzen, entzieht sich mir. Ich habe überlegt, ob dadurch der Cocontroller zurückgesetzt werden sollte, wenn der Pin schwebt (also der Hauptcontroller gerade im Reset ist), sehe aber nicht wie.
Ansonsten kann ich nur wiederholen, dass mir manuelles auf GND ziehen der Cocontroller-Resetleitung, erlaubt, den Roboter wunderbar zu programmieren.
Flo

[geekalert]

Herr Springob von nicai-systems konnte die Sache klären. Ich verwende mein eigenes Display, dessen Resetleitung, die mit dem Reseteingang des Cocontrollers verknüpft ist, verhindert, dass Haupt- und Cocontroller gemeinsam den Resetzustand einnehmen.
Flo