µController am Reset-Pin resetten

[bizkwie (Gast)]

Hi!

Wenn ich einen Microcontroller per Signal Hardware-Mässig an seinem 
reset-Eingang resette, springt er dann intern wieder an seine 
Ausgangssituation im Bootloader, oder ist dann das ganze Programm 
futsch?

grüßle

[bizkwie (Gast)]

Exakt einen AT90CAN128

[Bastler (Gast)]

Kommt auf die Spannung drauf an... Reset > 100V bewirkt meistens eine 
dauerhafte Löschung aller internen Speicher, inklusive der 
Prozessorregister. Auch die Struktur der CPU wird "zurückgesetzt". 
Gegebenenfalls stellt sich auch ein anderer Aggregatzustand ein, aber 
das ist nicht genau spezifiziert.

[spess53 (Gast)]

Hi

>springt er dann intern wieder an seine Ausgangssituation im Bootloader,

Er springt je nach BOOTRST-Fuse an die Adresse $0000 oder den durch 
BOOTSZ1:0 festgelegten Anfang des Bootsektors.

>oder ist dann das ganze Programm futsch?

Warum sollte etwas 'fusch' sein?

MfG Spess

[bizkwie (Gast)]

first: thx 4 reply!

> Er springt je nach BOOTRST-Fuse an die Adresse $0000 oder den durch
BOOTSZ1:0 festgelegten Anfang des Bootsektors.

Und dann ist's aber programmiere-abhängig, was er dann tut, oder?
Hab den Code hier leider nicht vor mir. Ist halt ein verbautes Gerät, 
das nicht mehr kommunizieren mag. Mehr als so zu resetten, fällt mir 
nicht ein. Da ich für den Controller direkt keine 
programmiermöglichkeiten habe.

> Wieso futsch?

Weil ich nicht weis, was er danach macht. Gut, der Code ist noch im 
Controller vorhanden, aber wenn er nicht weiter zum Progranmmstart 
springt ist das eher nebensächlich.

[Guru (Gast)]

Naja, wenn Du keinen Quelltext und keine Beschreibung des Programmes 
hast, nicht mal irgendeine mündliche Äusserung, was von dem uC zu 
erwarten ist, dann wird es schwer, eigentlich unmöglich, zu beurteilen 
ob er nun korrekt arbeitet oder nicht.

>Und dann ist's aber programmiere-abhängig, was er dann tut, oder?

Ich nehme mal an die Frage ist so gemeint: "Und dann hängt es von dem 
Programm ab, was er dann tut, oder?"

Das ist genau richtig.

>aber wenn er nicht weiter zum Progranmmstart springt ist das eher >nebensächlich.

Es gibt eigentlich nur einen Grund warum der uC, nachdem er, wenn ich 
das recht verstehe, eine Weile lang seinen Dienst getan hat, auf einmal 
nicht mehr zum Programmstart springen sollte: Er ist defekt.

Normalerweise, bei guter Behandlung, kann man aber davon ausgehen, das 
keine Defekte auftreten, nach denen der uC nicht an den Programmanfang 
springt.

Du schreibst, das der uC nicht mehr kommuniziert. Da oft, aber nicht 
immer, an den eigentlichen I/O Pins noch Pegelwandler oder irgendwelche 
Logik oder auch nur ein Widerstand kommt, lohnt es sich vielleicht mal 
zu kontrollieren ob direkt an den I/O-Pins etwas geschieht und ob der 
Takt noch funktioniert. Letzteres geht aber nur entweder falls der uC 
intern getaktet wird, falls der Takt herausgeführt ist (siehe 
Datenblatt) oder falls der Takt ausserhalb des uC erzeugt wird.

Viel Erfolg.