Forum: Mikrocontroller und Digitale Elektronik [Interessant] Was macht ein Controller, wenn er nicht programmiert ist?


von Sebastian B. (mircobolle)


Lesenswert?

Hallo,

heute haben wir etwas interessantes im Labor untersucht (vielleicht ist 
das für den ein oder anderen interessant, oder er hat schon etwas 
ähnliches erlebt) Also folgendes:

Eigentlich eine ganz einfache Frage: Was macht ein Controller, wenn man 
ihn in Betrieb nimmt, er aber noch kein Programm in seinem Flash drin 
hat?

Aufgefallen ist das ganze anhand eines elektrischen Tests der Baugruppe, 
der VOR der Programmierung durchgeführt wird. Und hier wurde sich über 
das seltsame bzw. unterschiedliche Reset-Verhalten des Controllers 
gewundert.

Mögliche Verhalten waren:
- Controller erzeugt ein RESET alle 32 kHZ
- Der RESET Pin bleibt für eine "relativ" lange Zeit statisch HIGH
- Die Frequenz auf dem RESET Pin wechselt von 32 kHz auf 64 kHz

Diese möglichen Zustände traten bei ein und der selben Baugruppe auf, 
wenn man sie mehrmals von der Spannungsversorgung getrennt hat.

Die Frage ist nun, was macht der Controller da?

Also haben wir erstmal an die Start-Up Sequence des Controllers gedacht:
- Einschwingzeit des Oszillators
- Vdd Anstiegsgeschwindigkeit
- POR Circuit, POR Counter ...
- Brown Out (Unterspannungserkennung...)

Das einfachste aber ist natürlich, wenn wir einfach den Controller 
selbst fragen. Also haben wir mit WinIDEA den "leeren" Controller 
debugt.

Was haben wir gesehen?
Controller startet bei 0xFFFF, also richtig bei der Vektortabelle.
Dort wird der dort liegende Op-Code interpretiert.

Jetzt kommt das interessante worüber ich mir bisher keine Gedanken 
gemacht habe:
Die nächste Adresse ist nun 0x0000 dort liegen die Register des 
Controller, die in den Adressraum des Controllers gemapt sind. Die 
Registerwerte (also die Werte in den Ports) bestimmen nun was für ein 
Op-Code ausgeführt wird. Das ist alles aber noch einigermaßen 
"definiert", da man ja theoretisch weiß wie die Register (durch die 
Hardwarebeschaltung usw. initialisiert sind). Undefiniert wurde es erst 
an einer bestimmten Assemblerzeile:

RTI

Hier will er nun auf den STACK zugreifen und einen Rücksprung ins 
"Programm" vollführen. Ha, aber wo liegt diese Adresse? Im RAM... und 
der ist total undefiniert beim Reset! Wenn man also die Spannung weg 
nimmt und wieder anlegt ist das Verhalten NIE vorherzusagen..

In einem Fall z.B. ist er in einen undefinierten Adressbereich 
gesprungen was zu einem RESET (illegal address detected) geführt hat ein 
anderes mal ist er an den Anfang des Flashbereichs gesprungen und dann 
hat er sich dann "realtiv lange" aufgehalten, da der Flash ja mit 0xFF 
initialisiert ist.

Und das witzige an der Sache ist: der Fehler ist vorher nie so extrem 
aufgefallen, weil wir den MC9S08DZ60 im Einsatz hatten, bei diesem war 
der volle Adressbereich DEFINIERT.. nun haben wir den MC9S08DN32 
eingesetzt, dieser hat UNDEFINIERTE Speicherbereiche.

Natürlich besteht auch die Wahrscheinlichkeit, dass im Speicher ein 
illegal Op-Code liegt, aber die Wahrscheinlichkeit ist hier geringer, 
als auf eine illegale Adresse aus dem RAM heraus zu treffen.


Naja, wieder was dazu gelernt. ;-)

LG

von Klaus (Gast)


Lesenswert?

>[Interessant] Was macht ein Controller, wenn er nicht programmiert ist?

dumm tun?

von Sebastian B. (mircobolle)


Lesenswert?

Klaus wrote:
>>[Interessant] Was macht ein Controller, wenn er nicht programmiert ist?
>
> dumm tun?

Hintergrund:
Elektrische Vorprüfung eines System-Basis Chips:
LIN Transceiver + 5 V Festspannungsregler + Watchdog

Hier wird der Watchdog Trigger des SBC vor der Programmierung des uC 
getestet (prozesstechnisch bedingt). Die Resetleitungen des SBC und des 
uC sind miteinander verbunden. Wenn der uC nun dumm die Resetleitung 
runterzieht während der SBC getestet werden soll ist das natürlich dumm 
:-)

Da haben unsere Prozesstechniker nicht so richtig nachgedacht.

Workaround:
Background Debug Mode Pin des uC auf Masse legen (per Nadeladapter) dann 
hält der uC das Maul ;-)

von Peter D. (peda)


Lesenswert?

Sebastian B. wrote:
> Eigentlich eine ganz einfache Frage: Was macht ein Controller, wenn man
> ihn in Betrieb nimmt, er aber noch kein Programm in seinem Flash drin
> hat?

Dazu solltest Du erstmal sagen, um welche Architektur es sich handelt.


Ein AVR liest immer nur 0xFFFF bis zum Flash-Ende und fängt dann wieder 
bei 0x0000 an usw.
Das 0xFFFF wirkt als NOP, d.h. ein unprogrammierter AVR macht ganz genau 
garnichts.

Ein 8051 durchläuft auch den Flash, hier bedeutet 0xFF = MOV R7,A, d.h. 
nach außen hin macht er auch garnichts.
Ist es ein 8051 mit externem Bus, dann durchläuft er erst den internen 
Flash und danach versucht er auf den externen Programmspeicher 
zuzugreifen. Hier hat man dann Aktivität auf den Ports P0 und P2.
Wenn man z.B. LEDs an P0 oder P2 hat, sieht man also sehr schön, daß der 
Flash leer ist, weil sie flackern.


Bei unserer Produktion kommt es allerdings nie vor, daß ein MC leer ist, 
da der Bestücker die Chips immer vor dem Einlöten programmiert. Bei 
neueren Projekten ist das oft ein Bootloader, der dann über CAN die 
eigentliche Applikation lädt.



Peter

von Klaus (Gast)


Lesenswert?

Hi Peter,

auch ein Z80 läuft duch. Entweder alles 0    -> Nop
                                  oder  0xFF -> RST 38
Klaus

von Sebastian B. (mircobolle)


Lesenswert?

Peter Dannegger wrote:
> Sebastian B. wrote:
>> Eigentlich eine ganz einfache Frage: Was macht ein Controller, wenn man
>> ihn in Betrieb nimmt, er aber noch kein Programm in seinem Flash drin
>> hat?
>
> Dazu solltest Du erstmal sagen, um welche Architektur es sich handelt.

HC(S)08  Freescale  MC9S08 DN32 ... DZ60

>
> Ein AVR liest immer nur 0xFFFF bis zum Flash-Ende und fängt dann wieder
> bei 0x0000 an usw.
> Das 0xFFFF wirkt als NOP, d.h. ein unprogrammierter AVR macht ganz genau
> garnichts.

Bei mir sah die erste Disassemble Zeile in WinIDEA in etwa so aus:
Address: 0xFFFF Disassemble "STX ,X"

Die nächste Adresse ist dann hier 0x0000, und er macht dann alles andere 
als nichts.

Wie ist das beim AVR? Wenn dieser auch bei 0x0000 beginnt wird er 
wahrscheinlich ja auch den dort befindlichen Speicherbereich als OpCodes 
interpretieren? Oder bleibt er irgendwo definiert stehen?

> Ein 8051 durchläuft auch den Flash, hier bedeutet 0xFF = MOV R7,A, d.h.
> nach außen hin macht er auch garnichts.
Garnichts? Oder erzeugt er Resets? Hält er seinen Program Counter an, 
oder interpretiert er weiter?

> Ist es ein 8051 mit externem Bus, dann durchläuft er erst den internen
> Flash und danach versucht er auf den externen Programmspeicher
> zuzugreifen. Hier hat man dann Aktivität auf den Ports P0 und P2.
> Wenn man z.B. LEDs an P0 oder P2 hat, sieht man also sehr schön, daß der
> Flash leer ist, weil sie flackern.
D.h. dass auch hier der "leere" / undefinierte Speicher als Op-Code 
interpretiert wird bis er auf einen illegal op-code bzw. auf eine 
illegal address trifft?

>
> Peter

Sebastian

von Sebastian B. (mircobolle)


Lesenswert?

Klaus wrote:
> Hi Peter,
>
> auch ein Z80 läuft duch. Entweder alles 0    -> Nop
>                                   oder  0xFF -> RST 38
> Klaus

Dachte ich auch, aber wie gesagt sind die Register ja in den Adressraum 
ab 0x0000 gemapt. D.h. dass der interpretierte Op-Code z.b. davon 
abhängig ist wie der PORT A beschaltet ist. Man könnte als, überspitzt 
ausgedrückt, einen korrekten Op-Code erzeugen, wenn man seine 
Pinbelegung entsprechend eines gültigen Op-Codes belegen würde.

Da hier bei mir z.B. ein "RTI" interpretiert wird greift er auf den 
STACK und damit auf den undefinierten RAM zu, was zu einem total 
undefinierten Verhalten führt. Hier kann z.B. einmal eine ungültige 
Adresse angesprungen werden -> Reset oder er springt in den Flash und 
führt 32k mal 0xFF aus... dieses spielt könnte er solange wiederholen 
bis die Spannungsversorgung entfernt wird -> RAM hat "neue" undefinierte 
Werte -> und aufeinmal springt er bei RTI nicht mehr in den Flash, 
sondern in einen ungültigen Speicherbereich -> Reset (illegal address)

Dieser Sachverhalt war mir halt nicht klar!

von Peter D. (peda)


Lesenswert?

Sebastian B. wrote:

> Wie ist das beim AVR? Wenn dieser auch bei 0x0000 beginnt wird er
> wahrscheinlich ja auch den dort befindlichen Speicherbereich als OpCodes
> interpretieren? Oder bleibt er irgendwo definiert stehen?

Wie gesagt, der Adreßzähler läuft immer rum, da NOPs ausgeführt werden.
Nach dem Reset startet er bei 0x0000 und läuft bis Flashende und dann 
wieder 0x0000.

8051 und AVR sind Harward, d.h die können nie in den Datenbereich 
laufen.


> Garnichts? Oder erzeugt er Resets? Hält er seinen Program Counter an,
> oder interpretiert er weiter?

Resets kann er garnicht erzeugen, bei AVR und 8051 ist der Resetpin nur 
ein Eingang.
Er läuft dann irgendwann auch wieder in den internen Flash rein.


> D.h. dass auch hier der "leere" / undefinierte Speicher als Op-Code
> interpretiert wird bis er auf einen illegal op-code bzw. auf eine
> illegal address trifft?

Illegal gibts beim 8051 nicht, nur 0xA5 ist nicht benutzt und wird wie 
NOP ausgeführt.


Peter

von holger (Gast)


Lesenswert?

Zieh bei deinem PC das Bios ROM mal halb raus.
Da kommen gar wundersame Dinge zustande.
Ist es sinnvoll diese zu untersuchen
oder vieleicht besser es wieder rein zu stecken?

von Sebastian B. (mircobolle)


Lesenswert?

holger wrote:
> Zieh bei deinem PC das Bios ROM mal halb raus.
> Da kommen gar wundersame Dinge zustande.
> Ist es sinnvoll diese zu untersuchen
> oder vieleicht besser es wieder rein zu stecken?

Eigentlich würde ich sowas auch nie untersuchen, aber wie gesagt war das 
ein Fehler der aus unserem Prüfstand stammt. Hier wurden viele 
Baugruppen als fehlerhaft deklariert, weil eben dieser unscheinbare, 
unprogrammierte Controller bei der elektrischen Prüfung eines anderen 
Chips dazwischen gepfuscht hat.

Der Controller als Übeltäter war schnell ausgemacht, aber nur warum er 
eben dieses sporadische, nicht gleichbleibende Verhalten gezeigt hat, 
waren eben diese Untersuchen nötig. Und nun haben wir halt Gewissheit, 
dass unser Controller (HCS08) quer durch den Speicher läuft und eben 
unvorhersehbar Resets erzeugt.

von Michael (Gast)


Lesenswert?

Die Frage mag dumm sein aber wer nutzt schon einen µC, der nicht 
programmiert ist?

von Sebastian B. (mircobolle)


Lesenswert?

Michael wrote:
> Die Frage mag dumm sein aber wer nutzt schon einen µC, der nicht
> programmiert ist?

Nochmal:
Das war ein Fehler aus der Produktion / Fertigung

Zuerst werden die Nutzen mit den Leiterplatten im Ofen gelötet und mit 
Bauteilen bestückt.

Dann wird optisch (automatisiert) geprüft ob die Bauteile richtig 
sitzen, dann kommt ein elektrischer Test mit einem Nadeladapter 
(automatisiert) und da wird eben nun dieser ATA6624 (System Basis Chip) 
geprüft, aber hier hängt eben auch der bis dato noch unprogrammierte uC 
dran.

Und hier entsteht das Problem.

Controller stört die Resetleitung des SBC -> Messsung schlägt fehl -> 
Baugruppe wird als schlecht aussortiert.

Dann ist eben eine dieser Baugruppen bei uns im Labor gelandet und wir 
haben untersucht ab was es lag.

von Sebastian B. (mircobolle)


Lesenswert?

Peter Dannegger wrote:

> Wie gesagt, der Adreßzähler läuft immer rum, da NOPs ausgeführt werden.
> Nach dem Reset startet er bei 0x0000 und läuft bis Flashende und dann
> wieder 0x0000.
>
> 8051 und AVR sind Harward, d.h die können nie in den Datenbereich
> laufen.

Harvard Architektur, stimmt. Das hatte ich nicht bedacht. Hier ist das 
Verhalten natürlich definiert.

>> Garnichts? Oder erzeugt er Resets? Hält er seinen Program Counter an,
>> oder interpretiert er weiter?
>
> Resets kann er garnicht erzeugen, bei AVR und 8051 ist der Resetpin nur
> ein Eingang.
> Er läuft dann irgendwann auch wieder in den internen Flash rein.

Eigentlich eine gute Sache so eine Harvard Architektur :-D
Warum hat unser HCS08 diese Architektur nicht ??? :)
Eigentlich eignet sich diese Architektur doch besonders gut für uC, oder 
liege ich da falsch? Das ganze gewährt ja auch eine gewisse Sicherheit.

Warum sind aber dann gerade Freescale Prozessoren so verbreitet bei 
Automotive Anwendungen... finde ich gerade etwas seltsam. Alleine nur 
wegen den "besseren" elektrischen Eigenschaften?

Sebastian

von Uhu U. (uhu)


Lesenswert?

Sebastian B. wrote:
> Eigentlich eine gute Sache so eine Harvard Architektur :-D

Finde ich nicht. Sie bringt letztlich außer zusätzlichen Komplikationen 
gegenüber der von-Neumann-Architektur garnichts.

von spess53 (Gast)


Lesenswert?

Hi

Verbuche das unter der Rubrik 'Wieder etwas dazugelernt'. Da das Problem 
sehr Controller- und Schaltungsspezifisch ist, kann ich aus meiner 
Sicht keine tiefergreifende Konsequenzen erkennen.

MfG Spess

von Znuh (Gast)


Lesenswert?

> Die Frage mag dumm sein aber wer nutzt schon einen µC, der nicht
> programmiert ist?

Jeder der ISP nutzt. Ich schaffs jedenfalls nichtmal bei 32kHz Takt 
innerhalb eines cycle auf den Program-Button zu klicken ;-)

Daher ist die Frage durchaus berechtigt.

von Peter D. (peda)


Lesenswert?

Sebastian B. wrote:

> Eigentlich eine gute Sache so eine Harvard Architektur :-D

Aber bei der Programmierung in C ergeben sich bei manchen Compilern 
(GCC) einige Klimmzüge, um konstante Daten im Flash zu plazieren.


> Warum sind aber dann gerade Freescale Prozessoren so verbreitet bei
> Automotive Anwendungen...

Ich weiß jetzt nicht, wie welche MCs in welchen KFZ verbreitet sind.
Ich denke, daß da hauptsächlich Lobbyarbeit bestimmt, welcher 
MC-Hersteller zum Einsatz kommt und wohl auch der Preis. Die technischen 
Eigenschaften sind weitgehend nebensächlich.

In den Anfängen des MC im KFZ waren ja sehr viele 8051 im Einsatz.
Siemens hatte aber nicht erkannt, daß OTP out ist und Flash-MCs 
gewünscht werden, daher hat dann der 8051 verloren. Und Atmel hatte noch 
nicht so den Fuß drin im Markt.


Peter

von Sebastian B. (mircobolle)


Lesenswert?

spess53 wrote:
> Hi
>
> Verbuche das unter der Rubrik 'Wieder etwas dazugelernt'. Da das Problem
> sehr Controller- und Schaltungsspezifisch ist, kann ich aus meiner
> Sicht keine tiefergreifende Konsequenzen erkennen.
>
> MfG Spess

So sehe ich das auch.

Ich habe einfach daraus mitgenommen, einen unprogrammierten uC nicht als 
"passives" Bauelement in einer Schaltung zu verstehen, sondern als einen 
aktiven Teil, der sehr wohl Einfluss auf die umgebende Schaltung haben 
kann.

Evtl. hat man ja mal eine nicht programmierte Baugruppe, mit einem 
seltsamen Freescale Controller drauf, in den Händen ... ;-)

Wer weiß? ;-)

von holger (Gast)


Lesenswert?

>Dann wird optisch (automatisiert) geprüft ob die Bauteile richtig
>sitzen, dann kommt ein elektrischer Test mit einem Nadeladapter
>(automatisiert) und da wird eben nun dieser ATA6624 (System Basis Chip)
>geprüft, aber hier hängt eben auch der bis dato noch unprogrammierte uC
>dran.

>Und hier entsteht das Problem.

Da würde ich erstmal den uC programmieren und dann
testen.

von Karl H. (kbuchegg)


Lesenswert?

Der springende Punkt, an den du dich gewöhnen musst:

Sowas wie einen unprogrammierten µC gibt es nicht.
Es ist immer ein 'Programm' vorhanden. Nur mag dieses Programm aus 
irgendwelchen Werten bestehen, die sich mehr oder weniger zufällig in 
irgendwelchen Speicherzellen ergeben haben.

Für den Prozessor spielt das alles aber keine Rolle. Der holt sich seine 
Op-Codes und führt sie aus. Ob diese Op-Codes jetzt entstanden sind, 
weil du sie in den Speicher platziert hast, oder ob sich diese Werte 
zufällig ergeben haben oder ob diese Werte alle 0 oder 0xFF sind, weil 
der Speicher gelöscht wurde oder weil vielleicht gar kein Speicherchip 
am Bus hängt, interessiert den Controller nicht. Der liest stur vom Bus 
seinen OpCode und führt aus was da daher kommt.

von Michael (Gast)


Lesenswert?

Wie Holger vorschlägt würde ich ein Programm, eventuell ein eigenes 
Testprogramm, auf den µC bringen und erst dann die Baugruppe testen.

von Andreas W. (Gast)


Lesenswert?

@Sebastian B. (mircobolle)

der Hinweis ist nicht schlecht, das werde ich im Hinterkopf behalten. 
Danke

außerdem ist es echt nicht uninteresant :)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Mögliche Verhalten waren:
> - Controller erzeugt ein RESET alle 32 kHZ
> - Der RESET Pin bleibt für eine "relativ" lange Zeit statisch HIGH
> - Die Frequenz auf dem RESET Pin wechselt von 32 kHz auf 64 kHz
wie wäre es, während des ICT den uC ganz einfach über einen aktiven 
Pegel am Reset-Eingang im Reset-Zustand zu halten?
Wie sich ein Controller im Reset verhält ist wesentlich besser 
definiert.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.