"Ausgesperrt" trotz funktionierendem Takt

Vieleicht hast du dich mit der RSTDISBL Fuse ausgesperrt?

Dachte ich auch erst, aber der Reset funktioniert.

Sebi schrieb:
> aber seit ich die Fuses dafür
> gesetzt habe, kann ich den µC nicht mehr ansprechen
Solange Du uns nicht verrätst, auf was genau Du die Fuses gesetzt hast 
können wir nur raten.

Liegt der externe Takt an XTAL1 an oder an XTAL2? Letzteres wäre falsch.

An XTAL1. Am Takt liegts mMn auch nicht, denn das Programm auf dem µC 
läuft problemlos durch. Wenn der Takt nicht richtig anliegen würde, 
würde er wohl gar nichts machen.

Die Fuses müssten (kanns nicht nachprüfen) auf CLKSEL 0000 und SUT 10 
stehen. Bei CLKSEL bin ich mir recht sicher, denn wie gesagt, der 
Controller tut.

Sebi schrieb:
> An XTAL1. Am Takt liegts mMn auch nicht, denn das Programm auf dem µC
> läuft problemlos durch.
Dann wird es wohl tatsächlich nicht daran liegen.

Sebi schrieb:
> Die Fuses müssten (kanns nicht nachprüfen) auf CLKSEL 0000 und SUT 10
> stehen. Bei CLKSEL bin ich mir recht sicher, denn wie gesagt, der
> Controller tut.
Das klingt auch gut so. Zum Test könntest Du mal den externen Takt 
wegnehmen und schauen, ob der Controller dann nicht mehr läuft. Ist das 
der Fall, kannst Du dir sicher sein.

Zur Not einfach neuen AVR nehmen und das ganze nochmal sorgfältig 
probieren ;-)

Der RFM12 ist nicht in einem seiner vielen Stromsparzustände? 
Funktioniert der RFM12 direkt nach einem Reset als Taktquelle? Du 
sprichst das Modul wahrscheinlich über SPI an und nutzt letztendlich die 
gleichen Leitungen zur Programmierung. Vielleicht "hakt" da etwas.

Hast Du einen zweiten µC? Dann programmiere und "fuse" den doch "normal" 
mit internem Takt verbinde den "defekten" µC nur mit dem Takt-Ausgang 
des RFM12 und versuche diesen erneut zu programmieren.

Klingt zwar paradox, aber jemand hat mal geschrieben, dass er wieder 
programmieren konnte, indem er die Programmierfrequenz hochgesetzt hat. 
Das kannst du ja mal probieren, kostet ja nichts.

Dussel schrieb:
> Klingt zwar paradox, aber jemand hat mal geschrieben, dass er wieder
> programmieren konnte, indem er die Programmierfrequenz hochgesetzt hat.
> Das kannst du ja mal probieren, kostet ja nichts.

Ist gar nicht so paradox, hatte ich auch schon mal.

Wie ist der RFM angebunden? Hast Du ggf. Mechanismen drin dass dir der 
RFM nicht ins ISP reinquatscht? Wenn ja welche? (=> Schaltplan!)

War wohl echt das RFM, verwende jetzt einen externen Oszillator, 
funktioniert prima. Muss nur das Layout dann ein bisschen ändern.

Vielen Dank für die Tips, manchmal steht man einfach aufm Schlauch ^^

Meine Nutmaßung geht auch in die Richtung SPI-Crash - wenn Du den 
Controller programmierst, ist er ein Slave, wie auch das externe Modul, 
und auf dem SO-Draht können beide gegeneinander arbeiten.

Am Rande: Mit irgendeinem AVR hatte ich mal ein Problem mit einer zu 
geringen SPI-Rate. Ich weiß nicht mehr mit welchem AVR das war, aber ich 
hab mir davon gemerkt, es immer auch noch einmal mit SPI-Clocks zwischen 
1/16 und 1/4 des Systemclocks zu probieren.

Interessanterweise tritt das Problem aber nur auf, wenn ich auch den 
Takt vom RFM als Systemtakt verwende. Sonst hatte ich bisher nie 
Probleme mit dem RFM direkt am SPI.
Aber du hast recht, ich verwende das RFM normalerweise mit Software-SPI, 
daher ist mir das so noch nicht über den Weg gelaufen. Leider brauch ich 
in dem Fall jeden Port, deshalb HW.

Naja, wieder was gelernt ;)

Du hast nicht zufällig den AVR-Reset zum RFM durchverbunden? Falls doch, 
könnte genau das das Problem sein: Der AVR wird mit Reset = 0 
programmiert. Und dem RFM traue ich - wie jedem zusätzlichem Teil, ich 
bin da ein gebranntes Kind - zu, dass es sich bei Reset = 0 einfach tot 
stellt, und dann z.B. den Takt für den AVR beim ISP eben nicht liefert.