Das merkwürdige Verhalten des laufreifen Philips LPC932 zur

[Igor \"Knight\" Ivanov]

Hi, NG!

Ich bin in einem schlechten Film.

Man setze einen Philips P89LPC932 Controller, Rev. G, im PLCC28-Gehäuse,

(http://www.semiconductors.philips.com/acrobat/datasheets/P89LPC932-03.pdf)

in folgender Beschaltung ein:

1. Der Controller wird von einem 12MHz Quarz getaktet (per
Flash-Konfiguration). Der Generator läuft stabil.
2. Die Stromversorgung leistet ein LM2936-3.3 LDO von 10V auf 3V3. 22uF
Tantal + 0.22uF KerKo am Ausgang, nah am Controller. Ein 2K2 Widerstand ist
an die Stromversorgung angeschlossen, um diese nach dem Abschalten sicher
bis auf 0V fallen zu lassen. Der Grund: "Vdd Fall Time" lt. Datenblatt Table
8, Seite 45 und Punkt 8.15, Seite 25.
3. Nach dem Start werden per Software alle Port-Pins (mit wenigen Ausnahmen
wie P1.2, P1.3 und P1.5) als Quasi-Bidirectional definiert. Der Grund: nach
dem Reset sind alle Port-Pins lt. Datenblatt [Punkt 8.12, ab Seite 22] als
Eingänge ohne Pull-ups definiert, und damit sie im Betrieb nicht "floaten",
werden sie halt in Quasi-Bidirectional umgewandelt.
4. Der RESET-Pin (P1.5), bloß als Eingang definiert (Voreinstellung), ist
direkt an die Stromversorgung angeschlossen, um Missverständnisse zu
vermeiden, denn lt. Punkt 8.15, Seite 25, wird der Pin während "Power up"
trotzdem als Reset behandelt und darf zu dem Zeitpunkt nicht LOW sein.
5. Der Controller steuert über seine PWM-Ausgänge (Port-Pins P1.6, P1.7,
P2.1, P2.6) NMOS-Fets (Si9936DY). Diese Ausgänge werden als Push-Pull
definiert.

Mehr ist am Controller nichts dran.

Und jetzt kommt's:

Wenn man mit der Stromversorgung zwecks Zuverlässigkeitstests spielt, indem
diese aus- und nach zufälligen Pausen (zwischen unter einer Sekunde bis
einigen Sekunden) wieder eingeschaltet wird, kann man nach einigen Versuchen
die Situation reproduzieren, wo der Controller sich selber UMPROGRAMMIERT,
indem er zufällig die SICHERHEIT-BITS setzt (das Programm selber enthält
keinen Code für)!

Die Tatsache, dass die Sichetheit-Bits gesetzt worden sind, kann man
feststellen, indem diese mit FlashMagic (so ein Programmwerkzeug von Philips
für ISP-Programmierung) ausgelesen werden.

Der Speicherinhalt mit Code selber bleibt erhalten, denn das Programm läuft
weiterhin (man kann das mehr oder weniger zuverlässig feststellen, indem man
aus verschiedenen Programmabschnitten heraus die oder jene Port-Pins
ansteuert und diese beobachtet), und es sind keine unvorgesehenen Sprünge
festzustellen. Bloß werden im Programm einige Konstanten per MOVC A, @A+DPTR
aus dem Code geholt, und sobald die Sichetheit-Bits plötzlich programmiert
worden sind, tut der MOVC-Befehl nicht mehr richtig, die Konstanten sind
dann falsch, und das Programm rechnet falsch. Wenn man den Controller jedoch
neuprogrammiert und als Ergebnis auch die Sichetheit-Bits löscht,
funktioniert alles wieder richtig, u.s.w....

Ich weiss, die Frage ist sehr speziell...

TIA,
Igor.

 

[MaWin]

Igor "Knight" Ivanov <knightigor@hotmail.com> schrieb im Beitrag <bm8aib$jfih2$1@ID-91064.news.uni-berlin.de>...

Wenn man mit der Stromversorgung zwecks Zuverlässigkeitstests spielt, indem
diese aus- und nach zufälligen Pausen (zwischen unter einer Sekunde bis
einigen Sekunden) wieder eingeschaltet wird, kann man nach einigen Versuchen
die Situation reproduzieren, wo der Controller sich selber UMPROGRAMMIERT,
indem er zufällig die SICHERHEIT-BITS setzt (das Programm selber enthält
keinen Code für)!

Hat der uC eine eingebaute Brown-Out-Protection ? (Sorry, trotz URL

hol ich mal nicht das Datenblatt, das wird groesser sein) ?
Wenn nein: RESET-Controller an den RESET-Anschluss. Fuer 3V3 bei
active high RESET hat die
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
leider keinen brauchbaren auf Tasche (ICL7665, TL7702, na ja).
Wenn du also einen akzeptable findest (3-pin), sag die Typennummer.
(National, OnSemi, TI, Maxim)
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Tilmann Reh]

Hallo Igor,

ich habe auch gerade eine Entwicklung mit dem LPC932 hinter mir.

Es gibt da noch ein paar Bugs im Chip, die im Errata Sheet bislang
nicht genannt werden... Das von Dir beschriebene Verhalten habe
ich aber noch nicht beobachtet (auch nichts in dieser Richtung).
Wir können uns gerne über Details austauschen.

Was mir in Bezug auf die Stromversorgung aufgefallen ist: Bei sehr
kurzen Ausfällen, oder auch bei kurzen Pulsen auf der Reset-Leitung,
schaltet der Chip gelegentlich den CPU-Takt auf den internen
WD-Oszillator um. Dann läuft das Programm auf einmal gaaaanz langsam
weiter. Dieser Bug soll in der nächsten Revision behoben sein.

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Igor \"Knight\" Ivanov]

Wenn man mit der Stromversorgung zwecks Zuverlässigkeitstests spielt,
indem
diese aus- und nach zufälligen Pausen (zwischen unter einer Sekunde bis
einigen Sekunden) wieder eingeschaltet wird, kann man nach einigen
Versuchen
die Situation reproduzieren, wo der Controller sich selber
UMPROGRAMMIERT,
indem er zufällig die SICHERHEIT-BITS setzt (das Programm selber enthält
keinen Code für)!

Hat der uC eine eingebaute Brown-Out-Protection ?

Ja, wir haben alle Sicherheitsmechanismen, die der Controller bietet, auf
den Kreuzzug geschickt. Auch den Brown Out Detector im Reset Mode und den
Watchdog im Security Mode, was heisst, der startet sofort nach dem Power Up,
ohne von der Software explizit zum Laufen gebracht werden zu müssen. Nur
regelmässig bestätigen danach, natürlich.

Nix geholfen. Also, das hilft schon den Prozessor zu (re)starten, falls
dieser während der Vergewaltigung durch die Spannung "rein-raus" doch
stecken bleibt (das kann man manchmal tatsächlich beobachten, doch nach 2.66
Sekunden erweckt der Watchdog das Chipchen zum Leben wieder). Aber so ein
Hang beim Start bedeutete nicht automatisch, dass der Controller sich
programmierte. Der Controller startet immer aber dann ZACK! - Fehler, der
sich bei uns so zeigt, dass PWM nicht mehr tut, denn die Konstanten im
Speicher sind dafür notwendig.

Wenn nein: RESET-Controller an den RESET-Anschluss.

Gerne! Aber das Layout ist schon 1000-Fach fertig. Gut, ich habe eine
Revision gemacht, und die nächste Generation kriegt einen Reset-Chip
verpasst. Doch interessanterweise haben wir noch eine Schaltung, mit dem
Chip diesmal in einem TSSOP Gehäuse, wo RESET sogar in der Luft hängt, und
sie tut als ob nix wäre. Nirgendwo im Datenblatt oder ANs stand, dass der
Reset-Pin nicht frei gelassen werden dürfe! Da steht nur, während Start Up
bitte NICHT nach LOW ziehen.

active high RESET hat die

BTW, LPC932 braucht aktiv LOW.

Wenn du also einen akzeptable findest (3-pin), sag die Typennummer.
(National, OnSemi, TI, Maxim)

Ich hab' so einen von Maxim gefunden, irgendwie mit vierstelliger Nummer
MAXxxxx, SC70-Gehäuse. Das Datenblatt ist im Büro, habe nicht im Kopf...
Heutzutage gibt es diese Chips haufenweise, sogar bei AD! Mit
Schwellenspannungen im 0.1V Schritt.

Und noch eine Sache, die mir in den Sinn kam als ich jetzt diese Antwort
schrieb. Es kann sein, dass zum Startpunkt die noch floating Pins (die
Software ist noch nicht angelaufen) so eine Konstellation (Sternenbild? -
zum Thema Denglish und Latein ) darstellen, dass der Chip auf
PARALLEL-Programming Mode geht?! Ich habe sofort bei Philips nachgeschaut
und konnte überraschenderweise keinen Dokument finden, wo steht, wie man
diese Dinge parallel programmiert! Wer findet, bekommt von mir ein Bier
spendiert, jedoch virtuell ;-).

Gruss,
Igor.

 

[Igor \"Knight\" Ivanov]

Hallo Igor,

ich habe auch gerade eine Entwicklung mit dem LPC932 hinter mir.

Ah! Und was steht bevor? ;-)

Es gibt da noch ein paar Bugs im Chip, die im Errata Sheet bislang
nicht genannt werden... Das von Dir beschriebene Verhalten habe
ich aber noch nicht beobachtet (auch nichts in dieser Richtung).
Wir können uns gerne über Details austauschen.

Oh, ja! Anscheinend hat sich dieses Ungezieferpärchen ziemlich vermehrt! Ich
bin sicher, das Errata Sheet wird bald länger sein als der User Manual
selbst!

Was mir in Bezug auf die Stromversorgung aufgefallen ist: Bei sehr
kurzen Ausfällen, oder auch bei kurzen Pulsen auf der Reset-Leitung,
schaltet der Chip gelegentlich den CPU-Takt auf den internen
WD-Oszillator um. Dann läuft das Programm auf einmal gaaaanz langsam
weiter. Dieser Bug soll in der nächsten Revision behoben sein.

Wir haben jetzt die Revision G.
Aber das von dir beschriebene Verhalten konnten wir bisher nicht
feststellen. Bei uns läuft er immer mit 12MHz vom externen Quarz an, was man
(wie ich schon schrieb) anhang der Debug-(Kammerjäger-? Oh! Nach dem Thread
"OT: gutes Deutsch" hier, den ich ungewollt losgetreten hatte, komme ich
nicht mehr zu Ruhe!)Impulse, die wir aus dem Programm heraus senden, sieht.
(<- Kann man diesen Satz noch verstehen? Wenn nicht - läuft immer mit 12MHz.
Punkt.)

So what,
Igor.

P.S. Ich fahre mal in die NL, - gut, dass es hier um die Eck' ist, - und
sehe in die Augen dem jenigen, der das alt bewahrte Konzept mit
Quasi-Bidirectionalen Eingängen, die zum Startpunkt definiert sind, fallen
liess...

 

[Tilmann Reh]

Igor \"Knight\" Ivanov schrieb:

Ah! Und was steht bevor? ;-)

Wenn man die ganzen Bugs mal außen vor läßt, ist das doch ein
toller Chip
Und wenn man die meisten schon mal kennt, ist das Risiko bei
der nächsten Entwicklung schon kleiner... Ich denke jedenfalls,
daß die LPC900 Familie bei einigen Neuentwicklungen demnächst
auch wieder berücksichtigt wird.

Es gibt da noch ein paar Bugs im Chip, die im Errata Sheet bislang
nicht genannt werden... Das von Dir beschriebene Verhalten habe
ich aber noch nicht beobachtet (auch nichts in dieser Richtung).
Wir können uns gerne über Details austauschen.

Oh, ja! Anscheinend hat sich dieses Ungezieferpärchen ziemlich vermehrt! Ich
bin sicher, das Errata Sheet wird bald länger sein als der User Manual
selbst!

Du vergißt: auch das UM wird langsam länger )

Was mir in Bezug auf die Stromversorgung aufgefallen ist: Bei sehr
kurzen Ausfällen, oder auch bei kurzen Pulsen auf der Reset-Leitung,
schaltet der Chip gelegentlich den CPU-Takt auf den internen
WD-Oszillator um. Dann läuft das Programm auf einmal gaaaanz langsam
weiter. Dieser Bug soll in der nächsten Revision behoben sein.

Wir haben jetzt die Revision G.

Wir auch, da ist der Fehler definitiv noch drin.

Aber das von dir beschriebene Verhalten konnten wir bisher nicht
feststellen. Bei uns läuft er immer mit 12MHz vom externen Quarz an, was man
(wie ich schon schrieb) anhang der Debug-(Kammerjäger-? Oh! Nach dem Thread
"OT: gutes Deutsch" hier, den ich ungewollt losgetreten hatte, komme ich
nicht mehr zu Ruhe!)Impulse, die wir aus dem Programm heraus senden, sieht.
(<- Kann man diesen Satz noch verstehen? Wenn nicht - läuft immer mit 12MHz.
Punkt.)

Wir haben bisher den internen Oszillator (7.4 MHz) verwendet. Das
Problem mit der ungewollten Taktumschaltung auf den 400 kHz Takt
ist sauber reproduzierbar und wurde auch von Philips bestätigt.
Daher weiß ich auch, daß der in der nächsten Release behoben sein
soll. Möglicherweise tritt er ja bei Betrieb am externen Quarz nicht
auf.

P.S. Ich fahre mal in die NL, - gut, dass es hier um die Eck' ist, - und
sehe in die Augen dem jenigen, der das alt bewahrte Konzept mit
Quasi-Bidirectionalen Eingängen, die zum Startpunkt definiert sind, fallen
liess...

Besser: Kontaktiere micro.support.europe@philips.com und kläre das
mit den Leuten dort. Man ist dort sehr hilfsbereit. (Du kannst in
deutsch oder englisch schreiben, was Dir lieber ist.)
Der Power-Up-Default als offene Eingänge hat manchmal auch Vorteile,
z.B. wenn man nachher high-aktive Ausgänge draus machen muß/will.
Man muß sich halt drauf einstellen (und das mußte man früher bei den
QBD-Ports auch). Ich finde es jedenfalls positiv, daß diese Chips
(endlich) vollwertige Ports haben.

Ach, da fällt mir noch was ein: hast Du DIVM verwendet, um den
CPU-Takt herunterzuteilen? Damit gibt es nämlich auch noch Probleme...

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Tilmann Reh]

Igor \"Knight\" Ivanov schrieb:

Und noch eine Sache, die mir in den Sinn kam als ich jetzt diese Antwort
schrieb. Es kann sein, dass zum Startpunkt die noch floating Pins (die
Software ist noch nicht angelaufen) so eine Konstellation (Sternenbild? -
zum Thema Denglish und Latein ) darstellen, dass der Chip auf
PARALLEL-Programming Mode geht?! Ich habe sofort bei Philips nachgeschaut
und konnte überraschenderweise keinen Dokument finden, wo steht, wie man
diese Dinge parallel programmiert! Wer findet, bekommt von mir ein Bier
spendiert, jedoch virtuell ;-).

Frage micro.support bei philips (siehe andere Nachricht), dort wird
man Dir die Zustände und Abläufe für Parallel-Programmieren nennen
können.

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Igor \"Knight\" Ivanov]

Hi!

Wir haben bisher den internen Oszillator (7.4 MHz) verwendet. Das
Problem mit der ungewollten Taktumschaltung auf den 400 kHz Takt
ist sauber reproduzierbar und wurde auch von Philips bestätigt.

Wow! Danke fuer den Tipp! Wir haben naemlich eine Schaltung, die mit dem
internen Oszi laufen tun macht . Bisher konnten wir jedoch den Effekt
nicht beobachten. Aber. Ich glaube, man kann aus der Situation herauskommen:
man startet den Watchdog und stellt ihn so ein, dass das Programm mit 7.xxx
MHz es schafft, diesen rechtzeitig und regelmaessig zu bestaetigen, aber das
selbe Programm, getaktet mit 400kHz, - nicht mehr. Kommt reset, und... Was
dann? Schaltet der Prozessor wieder auf 7.xxx Mhz um? Weisst du, ich rede am
Montag mit dem Kollegen, der das Programm schreibt...

Besser: Kontaktiere micro.support.europe@philips.com und kläre das
mit den Leuten dort. Man ist dort sehr hilfsbereit. (Du kannst in
deutsch oder englisch schreiben, was Dir lieber ist.)

(Mir iss egal, man spricht beim Thema sowieso Denglish ;-)).
Ich habe unseren Distributor (von dem wir die Chips beziehen) so erschreckt,
dass die Leutz mir eine e-mail Adresse von irgendeinem Supportingenieur
persoenlich rausgerueckt hatten. Den habe ich heute schon angeschrie(b)en
. Der schlief bestimmt noch zu dem Zeitpunkt, aber am Montag werden wir
sehen...

Der Power-Up-Default als offene Eingänge hat manchmal auch Vorteile,
z.B. wenn man nachher high-aktive Ausgänge draus machen muß/will.
Man muß sich halt drauf einstellen (und das mußte man früher bei den
QBD-Ports auch). Ich finde es jedenfalls positiv, daß diese Chips
(endlich) vollwertige Ports haben.

Die duerfen vollwertige Ports haben, meinetwegen, aber warum muss ich mich
um irgendwelche externen Widerstaende kuemmern, um z.B. MOS-Eingaenge in
einem definierten Zustand zu halten, solange die Ports, die die Eingaenge
ansteuern sollen, noch nicht als Ausgaenge von der Software geschaltet
sind?! Wozu baut man so einen feinen klitzekleinen Chip, wenn drum herum
haufenweise Resis stehen muessen?

Ach, da fällt mir noch was ein: hast Du DIVM verwendet, um den
CPU-Takt herunterzuteilen? Damit gibt es nämlich auch noch Probleme...

Ob wir DIVM verwenden... Denke nicht, muss 1:1 laufen... Muss den Kollegen
am Montag Fragen, das ist sein Kramm.

Danke!
Igor.

 

[Tilmann Reh]

Hallo Igor,

Wir haben bisher den internen Oszillator (7.4 MHz) verwendet. Das
Problem mit der ungewollten Taktumschaltung auf den 400 kHz Takt
ist sauber reproduzierbar und wurde auch von Philips bestätigt.

Wow! Danke fuer den Tipp! Wir haben naemlich eine Schaltung, die mit dem
internen Oszi laufen tun macht . Bisher konnten wir jedoch den Effekt
nicht beobachten. Aber. Ich glaube, man kann aus der Situation herauskommen:
man startet den Watchdog und stellt ihn so ein, dass das Programm mit 7.xxx
MHz es schafft, diesen rechtzeitig und regelmaessig zu bestaetigen, aber das
selbe Programm, getaktet mit 400kHz, - nicht mehr. Kommt reset, und... Was
dann? Schaltet der Prozessor wieder auf 7.xxx Mhz um? Weisst du, ich rede am
Montag mit dem Kollegen, der das Programm schreibt...

genau so ist es jetzt bei unserem Gerät.

Allerdings braucht es schon heftige Störungen (oder eben bestimmte
kurze Pulse direkt an der Reset-Leitung), damit diese ungewollte
Taktumschaltung passiert. Aber wenn es doch mal vorkommt, ist es
gut, wenigstens einen WD-Reset auszulösen...

Besser: Kontaktiere micro.support.europe@philips.com und kläre das
mit den Leuten dort. Man ist dort sehr hilfsbereit. (Du kannst in
deutsch oder englisch schreiben, was Dir lieber ist.)

(Mir iss egal, man spricht beim Thema sowieso Denglish ;-)).
Ich habe unseren Distributor (von dem wir die Chips beziehen) so erschreckt,
dass die Leutz mir eine e-mail Adresse von irgendeinem Supportingenieur
persoenlich rausgerueckt hatten. Den habe ich heute schon angeschrie(b)en
. Der schlief bestimmt noch zu dem Zeitpunkt, aber am Montag werden wir
sehen...

Die genannte Support-email geht auch direkt an das technische Team
im Halbleiterwerk in Hamburg. Sehr kompetente und hilfsbereite
Leute.
Laß uns bitte auf jeden Fall wissen, was dabei herauskommt!

Der Power-Up-Default als offene Eingänge hat manchmal auch Vorteile,
z.B. wenn man nachher high-aktive Ausgänge draus machen muß/will.
Man muß sich halt drauf einstellen (und das mußte man früher bei den
QBD-Ports auch). Ich finde es jedenfalls positiv, daß diese Chips
(endlich) vollwertige Ports haben.

Die duerfen vollwertige Ports haben, meinetwegen, aber warum muss ich mich
um irgendwelche externen Widerstaende kuemmern, um z.B. MOS-Eingaenge in
einem definierten Zustand zu halten, solange die Ports, die die Eingaenge
ansteuern sollen, noch nicht als Ausgaenge von der Software geschaltet
sind?! Wozu baut man so einen feinen klitzekleinen Chip, wenn drum herum
haufenweise Resis stehen muessen?

Nimm SIL-Arrays.
(... alles hat *mindestens* zwei Seiten

Viel Erfolg!

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Erik Hermann]

Igor "Knight" Ivanov wrote:

die Situation reproduzieren, wo der Controller sich selber UMPROGRAMMIERT,
indem er zufällig die SICHERHEIT-BITS setzt (das Programm selber enthält

Naja, diese Probleme gibt es schon, seit EEPROM und Flash auf dem
markt sind. Manche Contrroller machen die lustigsten (haha) Sachen
mit ihrem Flash und vor allem mit dem EEPROM, wenn sie beim Ein-
oder Ausschalten der Versorgung eine definierten Zustände haben.
Aus leidvoller Erfahrung benutze ich z.B. niemals die Zelle 0 in
einem EEPROM.
Woran Dein Problem nun liegt, ist aus der Ferne schwer zu beurteilen.
Ich kenne solche Sachen, die Temic/Atmel 8051 mit Flash machen
sowas auch gerne. Meistens eine Kombination aus Stromversorgung und
Layout. Wenn es geht versuche ich de Stromversorgung so auszulegen,
dass sie Netzausfälle von bis zu 500ms problemlos überbrückt, das
hält schonmal viele potenzielle Probleme vom uC ab. Ansonsten hilft
neben sauberem Hochstarten auch eine Power-fail Logik, z.B. mit
einem Low Drop Spannungsregler mit Enable Anschluss. In diesem Falle
sollte man allerdings nach dem Spannungsregler nur frugale Kapazitäten
einsetzen. Übrigens könnte der Spannungsregler auch schon das Problem
sein. Hast Du Dir mal die Spannung beim Einschalten angeschaut?
22uF Tantal geben beim Einschalten einen sauberen Kurzschluss,
möglicherweise schleicht sich dadurch die Spannung hinter dem LDO
zu langsam ein, oder bricht nach kurzem Hochschiessen wieder ein.

 

[Igor \"Knight\" Ivanov]

Hi!

Woran Dein Problem nun liegt, ist aus der Ferne schwer zu beurteilen.
Ich kenne solche Sachen, die Temic/Atmel 8051 mit Flash machen
sowas auch gerne.

Muss sagen, mit den Typen hatten wir bisher keine Probleme dieser Sorte...

sein. Hast Du Dir mal die Spannung beim Einschalten angeschaut?
22uF Tantal geben beim Einschalten einen sauberen Kurzschluss,
möglicherweise schleicht sich dadurch die Spannung hinter dem LDO
zu langsam ein, oder bricht nach kurzem Hochschiessen wieder ein.

Die Spannung hatte ich auch beobachtet. Die Anstiegzeiten sind OK, es gibt
keine Knicke oder kurzfristige Zusammebrueche.

Wie ich schon schrieb, bedarf man einige Versuche und Spielereien mit dem
Stromschalter, um den Prozessor aus dem Takt zu bringen (im übertragenen
Sinne ). Das heiss, man kann die Situation zwar hervorrufen, dass der Chip
die Bits programmiert, aber diese ist nicht so leicht zu erreichen. Von
daher schliesse ich auf, dass mit der Spannung alles OK ist. Ich vermute
immer stärker, dass eben eine gewisse Konstellation an den frei liegenden
Pins entsteht (nochmals, die haben zur Anfangszeit keine Pullups!), wodurch
der Chip in den parallelen Programmiermodus hineingehe und Blödsinn
anstelle. Deswegen benoetige ich schleunigst die Infos zu diesem Modus, um
das zu analysieren und die oder jene Pins in einen definirten Zustand zu
versetzen: ich will jetzt nicht anfangen, wild und blind zu experimentieren.
Ich habe heute schon mit dem Supportingenieur telefoniert und ihm auf meine
e-mail an ihn aufmerksam gemacht. Er hat versprochen, sich damit so schnell
wie moeglich auseinanderzusetzen. Mir bleibt nur Hoffnung, dass er es tut.

Ich werde euch hier informieren (wie ich es schon Tilmann zusagte), wie es
mit der Sache vorangeht. Der Chip ist ja relativ neu, Philips gibt auch zu,
dass es damit gewisse Probleme gibt (Kinderkrankheiten halt). Der Chip sieht
aus meiner Sicht vielversprechend aus (auch vom Preis her), und ich moechte
in Zukunft auf seine Features zurueckgreifen. Ich habe eben nicht erwartet,
dass ich mit SOLCHEN Schwierigkeiten konfrontiert werde. Ich kenne MSC-51
in- und auswendig und sah die 8051-Architektur als voll ausgereift an.
Bisher hatte ich Probleme dieser Sorte nie gehabt (wo es nicht mehr an mir
sondern offensichtich am Chip liegt, und man erlebt Überraschungen da, wo
man es nicht mal vermuten kann).

Danke fuer die Antworten,
weiter so,

Igor.

 

[Igor \"Knight\" Ivanov]

Hi nochmals!

Ach, da fällt mir noch was ein: hast Du DIVM verwendet, um den
CPU-Takt herunterzuteilen? Damit gibt es nämlich auch noch Probleme...

Nachgefragt: DIVM wird bei uns nicht angefasst. Alles DEFAULT.

Igor.

Don't let them take your rights!
http://www.againsttcpa.com

 

[Igor \"Knight\" Ivanov]

Frage micro.support bei philips (siehe andere Nachricht), dort wird
man Dir die Zustände und Abläufe für Parallel-Programmieren nennen
können.

Hi, Tilmann,
Hi, NG!

Ich habe gefragt. Die haben sehr freundlich und hilfsbereit reagiert und mir
auch die Abläufe zum Parallel-Programmieren genannt. Ich habe das analysiert
und festgestellt - ausgeschlossen, dass der Prozessor sich selber auf diesem
Wege programmiert.

Inzwischen haben wir jedoch etwas gefunden. Das ist aber kein grundliegender
Fehler unsererseits: wie man weiter sehen wird, haben wir eigentlich alles
richtig gemacht, nur funktioniert der Prozessor unter Umständen
unvorhersehbar. Das Missverständnis ist nur, wofür ich mich entschuldige,
dass wir etwas behauptet haben, was nicht ganz stimmte.

Zur Erinnerung: durch mehrmaliges Ein- und Ausschalten der Versorgung konnte
man erreichen, dass der Prozessor die Sicherheitbits so programmierte, dass
die konstanten im Speicher nicht mehr mit MOVC erreichbar wurden, obwohl das
Programmcode selbst nicht darunter litt und weiterhin richtig ausgeführt
wurde. Man bekam eben falsche Ergebnisse.

Ich habe behauptet, dass unser Programm keinen Code enthalte, der die
Programmierung anstellen konnte. Und das war falsch. Wir haben anfangs das
Programm eben so gestaltet, dass es nach jedem Hochfahren einige spezielle
Konfigurationbits, die man während der Programmierung des Prozessors mit
FlashMagic auch setzen kann (und muss), überprüft und ggf. selber setzt. Das
Ziel war, dass falls diese speziellen Bits (wie externer Quarz, Watchdog
Modi, darunter Sicherheitbit für Bank 0, wo sich das Programm befindet,
etc...) aus Versehen doch nicht gesetzt wurden, das "nachzuholen".
Sozusagen, der Schutz gegen eigene Unaufmerksamkeit.

Wir haben diesen Programmabschnitt in einen "Conditional Translation"
Abschnitt platziert. Das heisst, man müsse erst ein Symbol im Programmtext
definieren, damit dieser Abschnitt umgesetzt wird. Und wir waren der
Überzeugung, dass dieses Symbol nirgendwo definiert worden ist. Und das war
unser Fehler, denn der Code:

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
// ATTENTION !
//
#define DO_LOCK_CODE_READ // activates segments lock code
//
// Check the generated asm-code below
// to compatibility with Flash-programming firmware interface
// (activate "#pragma src..." above and explore asm-file)
//
// Check allocation of ALL ?CO?... segments;
// they must NOT be located in the locked segments!!!
//
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

#define MAX_SEG_TO_LOCK (0) // segments to lock:
0..MAX_SEG_TO_LOCK

#define SEG0_INDEX (8) // index of security byte for
Segment #0
#define FLASH_OP_MISC_READ (0x03)
#define FLASH_OP_MISC_WRITE (0x02)
#define FLASH_SECURITY_SEG_BITS (0x01)
#define FlashFirmware (0x0FF00)

#ifdef DO_LOCK_CODE_READ
{
unsigned char ireg;
for (ireg=MAX_SEG_TO_LOCK+SEG0_INDEX; ireg != SEG0_INDEX-1; ireg--)
{
unsigned char regv;
FeedWDog();
ACC = FLASH_OP_MISC_READ;
regv = (*(TPGM_FLASH_MISC_READ)FlashFirmware)(ireg); // CY after
return: 1 - error, 0 - ok
if (CY || regv & FLASH_SECURITY_SEG_BITS)
continue; // error OR already set
ACC = FLASH_OP_MISC_WRITE;
(*(TPGM_FLASH_MISC_WRITE)FlashFirmware)(ireg,
FLASH_SECURITY_SEG_BITS);
}
}
#endif //DO_LOCK_CODE_READ


wurde doch umgesetzt.

Wie man sieht, FLASH_SECURITY_SEG_BITS == 1. Und dieses einzige Bit wurde
tatsächlich gesetzt, was eigentlich auch anfangs gewünscht und korrekt war.
Hier haben wir alles richtig gemacht. Doch durch die Spielereien mit der
Versorgung gab's anscheinend Situationen, wo WÄHREND des Programmiervorgangs
innerhalb der Firmware nicht nur dieses eine sondern auch weiter
Sicherheitbits MITEINPROGRAMMIERT wurden.

Fazit: man solle mit grosser Vorsicht die Konfigurationbits genießen und
diese aus dem Programm heraus lieber links liegen lassen.

Euer Igor.

--
Don't let them take your rights!
http://www.againsttcpa.com