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
>[Interessant] Was macht ein Controller, wenn er nicht programmiert ist?
dumm tun?
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 ;-)
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
Hi Peter, auch ein Z80 läuft duch. Entweder alles 0 -> Nop oder 0xFF -> RST 38 Klaus
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
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!
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
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?
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.
Die Frage mag dumm sein aber wer nutzt schon einen µC, der nicht programmiert ist?
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.
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
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.
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
> 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.
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
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ß? ;-)
>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.
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.
Wie Holger vorschlägt würde ich ein Programm, eventuell ein eigenes Testprogramm, auf den µC bringen und erst dann die Baugruppe testen.
@Sebastian B. (mircobolle) der Hinweis ist nicht schlecht, das werde ich im Hinterkopf behalten. Danke außerdem ist es echt nicht uninteresant :)
> 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.