ATTiny45 Lockbits setzen und gleichzeitig ISP deaktiveren

[Rush .. (rush)]

Ich fürchte dass ich mich mit meine ATTiny45 in eine Sackgasse geführt 
habe.

Undzwar messe ich über den INT0 (ja ich weiss.... ICP usw.; zu spät, 
Platinen sind schon gefertigt) Impulslängen. Blöderweise ist der INT0 
auch gleichzeitig der SCK für den ISP.

Nun möchte ich die Lockbits setzen sodas das Programm nicht ausgelesen 
werden kann.

Zum Setzen der Bits muss ja das ISP eingeschaltet sein. Schreibe ich nun 
die passenden Lockbits, kann ich aber die Fuse zum Deaktivieren der ISP 
Schnittstelle nicht ändern da sie ja durch die Lockbits geschützt sind. 
Ich brauche aber den SCK-Pin von der ISP da dieser, wie gesagt, mein 
INT0 ist.

Andersherum kann ich nicht die ISP Schnittstelle deaktivieren da ich 
dann nichts mehr an den Lockbits drehen kann.

DebugWire kann ich alternativ auch nicht benutzen da das Programm dann, 
trotz gesetzter Lockbits, trotzdem auslesbar bleibt.

Hat jemand eine Idee wie ich meinen INT0 bekomme und trotzdem das 
Auslesen des Programms verhindern kann?

Danke schonmal im Voraus.

Gruß, Rush

[spess53 (Gast)]

Hi

>Andersherum kann ich nicht die ISP Schnittstelle deaktivieren da ich
>dann nichts mehr an den Lockbits drehen kann.

Warum musst du die Lockbits setzen und ISP deaktivieren?

MfG spess

[Peter D. (peda)]

ISP kannst Du nur mit HV-Programming deaktivieren.
Setze Debugwire deaktiviert und die Lockbits.

Auf INT0 hat das alles keinen Einfluß.

[Rush .. (rush)]

Ich  muss den ISP deaktiveren weil dessen SCK-Pin auch der INT0 ist und 
ich diesen im Programm verwende.

@Peter
Meinst also:
1. DebugWire deaktivieren
dann 2. Lockbits passend setzen und
zum Schluss via HV den SPI deaktiveren

Richtig so?

[Peter D. (peda)]

Rush ... schrieb:
> Ich  muss den ISP deaktiveren weil dessen SCK-Pin auch der INT0 ist und
> ich diesen im Programm verwende.

Sagt wer?

Rush ... schrieb:
> zum Schluss via HV den SPI deaktiveren

Wozu?

[spess53 (Gast)]

Hi

>Ich  muss den ISP deaktiveren weil dessen SCK-Pin auch der INT0 ist und
>ich diesen im Programm verwende.

Na und? ISP ist nur aktiv, wenn das Resetpin Low ist. Und dann gibt es 
eh keinen INT0.

MfG spess

[Rush .. (rush)]

@Peter
Sagt das Datenblatt.
Ich will das ISP deaktivieren da das Signal was an dem INT0 ankommt 
Einfluss nimmt. Ist meine Signalquelle an dem INT0/SCK angeschlossen, 
bekomme ich den Tiny nicht programmiert da am SCK reingefunkt wird.
Ziehe ich die Signalquelle ab so lässt sich der uC problemlos 
programmieren.

[F. F. (foldi)]

Rush ... schrieb:
> Ich  muss den ISP deaktiveren weil dessen SCK-Pin auch der INT0 ist und
> ich diesen im Programm verwende.
>
> @Peter
> Meinst also:
> 1. DebugWire deaktivieren
> dann 2. Lockbits passend setzen und
> zum Schluss via HV den SPI deaktiveren
>
> Richtig so?

Eigentlich müsste es auch über ISP, als letzte Aktion, klappen ISP zu 
deaktivieren. Da gibt es zwar eine Fehlermeldung, aber danach kommst du 
nicht mehr über ISP rein.

[g457 (Gast)]

> Ich will das ISP deaktivieren da das Signal was an dem INT0 ankommt
> Einfluss nimmt.

Worauf? Und wer genau?

> Ist meine Signalquelle an dem INT0/SCK angeschlossen,
> bekomme ich den Tiny nicht programmiert da am SCK reingefunkt wird.

Dann hast Du das Datenplatt und die diversen AppNotes, z.B. die 042, 
nicht beachtet.

> Ziehe ich die Signalquelle ab so lässt sich der uC problemlos
> programmieren.

Sehr schön, Du kannst den µC also Programmieren. Und was genau hat das 
jetzt mit INT0 zur Laufzeit zu tun?

Nimms uns nicht krumm, aber das was Du schreibst, lässt nicht gerade 
drauf schließen, dass Du die Funktionsweise des µC im Allgemeinen und 
des ISP im Speziellen hinreichend verstanden hast.

[holger (Gast)]

>Eigentlich müsste es auch über ISP, als letzte Aktion, klappen ISP zu
>deaktivieren.

Nein, das geht nicht. Schau ins Datenblatt.

[Deeepdischarge (Gast)]

Deaktiviere einfach den Resetpin, dann keiner mehr ISP benutzen.

[F. F. (foldi)]

holger schrieb:
>>Eigentlich müsste es auch über ISP, als letzte Aktion, klappen ISP zu
>>deaktivieren.
>
> Nein, das geht nicht. Schau ins Datenblatt.

Dann war es sicher nur ein Zufall, dass das bei mir schon mindestens 
zweimal geklappt hat.

[Rush .. (rush)]

Also nochmal:
am INT0 hängt ein Servoausgang eines RC-Empfängers dran. Und über INT0 
messen ich die High-Periode des Empfängerkanals.

INT0 und der ISP-SCK ist der Selbe Pin.

Und doch ich verstehe den uC im Allgemeinen. Ich verstehe nur nicht 
warum ihr nicht versteht dass Signal an INT0 (das was ich in der 
Software auswerte) für den ISP ein Fremdsignal ist und der ISP somit 
"verwirrt" ist und mein Programm scheinbar nicht das macht was es soll.

Peter du meintest ich soll das Debugwire ausschalten und die Lockbits 
setzen und gut ist. Genau das habe ich ja auch getan und gesehen, dass 
es eben nicht so funzt wie erwartet. Deswegen schreibe ich ja diesen 
Beitrag.

[holger (Gast)]

>>>Eigentlich müsste es auch über ISP, als letzte Aktion, klappen ISP zu
>>>deaktivieren.
>>
>> Nein, das geht nicht. Schau ins Datenblatt.
>
>Dann war es sicher nur ein Zufall, dass das bei mir schon mindestens
>zweimal geklappt hat.

Vieleicht hast du dir die Reset Fuse weggeblasen.
So geht das natürlich auch.

Laut Datenblatt kann man im ISP Mode die SPIEN Fuse
nicht ändern.

[F. F. (foldi)]

holger schrieb:
>
> Laut Datenblatt kann man im ISP Mode die SPIEN Fuse
> nicht ändern.

Ist schon länger her, dass ich das (seinerzeit zuerst versehentlich) 
ausgeschaltet hatte, daher auch das "Eigentlich" in meinem Text.

[g457 (Gast)]

> Ich verstehe nur nicht warum ihr nicht versteht dass Signal an INT0
> (das was ich in der Software auswerte) für den ISP ein Fremdsignal
> ist und der ISP somit "verwirrt" ist und mein Programm scheinbar nicht
                                      ^
> das macht was es soll.

Doch, die erste Hälfte davon (bis zum zur Markierung bei 'ISP ist 
verwirrt') glauben wir Dir. Und das liegt wie schon geschrubt am 
Nichtbefolgen der AVR042. Macht hier aber nix, weil programmieren kannst 
Du ja (mit Empfänger abgesteckt).

Das danach hat damit aber reingarnix zu tun. Es mag sein, dass Dein 
Programm nicht das tut, was es soll, das liegt aber nicht am ISP, weil 
der ist zur Laufzeit gar nicht aktiv.

[Rush .. (rush)]

Ja, so hatte ich mir das auch gedacht. Die AppNote habe ich tatsächlich 
nicht beachtet :(

Ich werde morgen einfach mal eine andere dieser Platinen ausprobieren 
wobei ich weniger glaube dass es dann funktioniert. Bei 13 Bauteilen ist 
die Fehlerwahrscheinlichkeit doch ein wenig gering ;-)

Danke euch für die Bemühungen und einen schönen Abend.

[g457 (Gast)]

> Die AppNote habe ich tatsächlich nicht beachtet :(

Ich hoffe ich hab Dich jetzt nicht versehentlich auf den falschen 
Dampfer geleitet. Das von Dir gesuchte Problem liegt ∗nicht∗ im ISP 
begraben - der ist NUR während des Programmierens aktiv. Mit Problemen 
zur Laufzeit hat das nichts zu tun, insbesondere nicht wenn der 
Programmieradapter gar nicht angesteckt ist.

[Rush .. (rush)]

Nene, das ist schon vollkommen ok von dir :-)

Somit ist diese Fehlerquelle schonmal ausgeschlossen.


Nur wirds jetzt noch seltsamer:
Ich programmiere den uC auf einer Adapterplatine. Da ist sonst nichts 
anderes drauf außer dieser selbst. Es hängt also an den ISP-Leitungen 
also entweder NUR der Programm oder NUR die eigentliche Signalquelle für 
den INT0.

Und den programmiere ich über ISP und löte ihn anschließend in die 
Schaltung. Es scheint als würde das Programm dann irgendwo hängenbleiben 
weswegen ich vermutete dass er sich im Programmiermodus befindet und auf 
Daten vom Programmer wartet.
Den letzten Beiträgen zu Folge würde er sich nur im Programmiermodus 
befinden wenn der Rest-Pin auf GND liegen würde. Tut er aber nicht.


Seltsamerweise funzt das identische Programm  auf der gleichen Platine 
(nicht die selbe; habe 10 Stück) problemlos wenn ich es über DebugWire 
flashe...

[g457 (Gast)]

Ins Target einlöten ohne Debugschnittstelle ist ein eher hinderlicher 
Ansatz wenns ums Fehlersuchen geht. Zeig doch mal Schaltplan und 
Quellcode, vielleicht kann man da ja was erkennen. Wenns nicht anders 
geht dann bau zumindest einen Sockel in ein Target um Dir das Löten zu 
ersparen.

Ansonsten hilft nur das übliche: Debuggen. Vorzugsweise über einen 
Debugadapter und im Target. Wenn das nicht geht dann über eine adäquat 
zurechtgebogene (unidirektionale) Schnittstelle wie tracen über UART. 
Wenn nicht mal das geht hilft nur noch LED oder ähnliches. Danach wirds 
dann eng mit den Optionen..

[F. F. (foldi)]

Rush ... schrieb:
> Und den programmiere ich über ISP und löte ihn anschließend in die
> Schaltung.

Rush ... schrieb:
> Seltsamerweise funzt das identische Programm  auf der gleichen Platine
> (nicht die selbe; habe 10 Stück) problemlos wenn ich es über DebugWire
> flashe...

Irgendwie verstehe ich das nicht.
Also grundsätzlich programmierst du den µC extern, aber auf einer der 10 
Platinen kannst du ihn mit dW programmieren?

Wenn das so ist, dann hast du ja vorher dW eingeschaltet, denn das ist 
standardmäßig abgeschaltet.

Was ist denn mit normalem ISP auf der anderen Platine, geht das denn 
auch?
Und überhaupt, mit dW flashen? Da bist du im Debug Modus und das hat mit 
dem eigentlichem flashen doch gar nichts zu tun.

???

[Rush .. (rush)]

Ich habe ja eine Zielplatine wo ich die ISP-Leitungen direkt an den 
Controller gelötet habe, falls noch was an der Firmware verändert werden 
müsste etc.

Die funktioniert ja ohne Probleme.

Nur wenn ich eine andere Zielplatine (habe ja mehrere identische davon) 
nehme, und einen über ISP (auf dem Programmieradapter) geflashten 
Controller darauf löte, funktioniert er nicht.

[F. F. (foldi)]

Rush ... schrieb:
> Ich habe ja eine Zielplatine wo ich die ISP-Leitungen direkt an den
> Controller gelötet habe, falls noch was an der Firmware verändert werden
> müsste etc.
>
> Die funktioniert ja ohne Probleme.
>
> Nur wenn ich eine andere Zielplatine (habe ja mehrere identische davon)
> nehme, und einen über ISP (auf dem Programmieradapter) geflashten
> Controller darauf löte, funktioniert er nicht.

Vielleicht hilft dir das weiter:

• dW: When the debugWIRE Enable (DWEN) Fuse is programmed and Lock bits are unprogrammed, the 
debugWIRE system within the target device is activated. The RESET port pin is configured as a wire-AND 
(open-drain) bi-directional I/O pin with pull-up enabled and becomes the communication gateway between 
target and emulator

Da scheint unter Umständen etwas mit deiner Reset Leitung nicht zu 
stimmen.

[F. F. (foldi)]

Ist denn dein DWEN on?

[F. F. (foldi)]

Schon mal gelesen?

Connection of RESET pin on AVRs 
The RESET pin on the AVR is active LOW, and setting the pin LOW externally will thus result in a reset of the AVR. The 
RESET has two purposes: 
1. To release all lines by tri-stating all pins (except XTAL pins), initialize all I/O registers and set program counter 
to zero. 
2. To enter programming mode (for some parts also the PEN line is used to enter programming mode). 
Furthermore it is possible to enter high-voltage/parallel programming mode by drawing the RESET pin “very” 
high, where very high means 11.5V – 12.5V (refer to the datasheet of the device for more information). 
The reset line has an internal pull-up resistor, but if the environment is noisy it can be insufficient and reset can 
therefore occur sporadically. Refer to datasheet for value of pull-up resistor on specific devices. 
Connecting the RESET so that it is possible to enter both high-voltage programming and ordinary low level reset can be 
achieved by applying a pull-up resistor to the RESET line. This pull-up resistor makes sure that reset does not go low 
unintended. The pull-up resistor can in theory be of any size, but if the Atmel AVR should be programmed from e.g. 
STK®
500/AVRISP the pull-up should not be so strong that the programmer cannot activate RESET by draw the RESET 
line low. The recommended pull-up resistor is 4.7kΩ or larger when using STK500 for programming. For DebugWIRE to 
function properly, the pull-up must not be smaller than 10kΩ. 
To protect the RESET line further from noise, it is an advantage to connect a capacitor from the RESET pin to ground. 
This is not directly required since the AVR internally have a low-pass filter to eliminate spikes and noise that could 
cause reset. Applying an extra capacitor is thus an additional protection. However, note that this capacitor cannot be 
present if DebugWIRE or PDI is used. 
If not using High Voltage Programming it is recommended to add an ESD protecting diode from RESET to Vcc, since 
this is not internally provided due to High Voltage Programming. Alternatively, or in addition, a Zener diode can be used 
to limit the RESET voltage relative to GND. The Zener diode is highly recommended in noisy environments. The 
components should be located physically close to the RESET pin of the AVR. Figure 2-2 shows the recommended 
circuit on the RESET line.

[Rush .. (rush)]

DebugWire ist ausgeschaltet. Der Rest-Pin liegt mit 10kOhm an VCC.
Und VCC ist 5V was auch die einzige vorhandene Spannung ist.
Kurzschluss von Reset zu GND habe ich auch ausschließen können.

[F. F. (foldi)]

Rush ... schrieb:
> DebugWire ist ausgeschaltet. Der Rest-Pin liegt mit 10kOhm an VCC.
> Und VCC ist 5V was auch die einzige vorhandene Spannung ist.
> Kurzschluss von Reset zu GND habe ich auch ausschließen können.

Dann weiß ich auch nicht weiter.

[Rush .. (rush)]

Ich auch nicht mehr...

Aber trotzdem danke.

[g457 (Gast)]

Du hast immernoch die Option..

> Zeig doch mal Schaltplan und Quellcode, vielleicht kann man da ja was
> erkennen.

..von oben.