Servus,
ich bin momentan an einem kleinen Projekt für die Technikerschule.
Vorgabe war es, einen 8051er zu nutzen. Die Wahl fiel auf den 89LPC922.
So weit, so gut.
Nach Aufbau der Schaltung wollte ich jetzt nur ein kleines Testprogramm
in Assembler schreiben, um die ganze Sache zu testen (Taster, LEDs).
Parallel dazu habe ich noch einen Programmer aufgebaut, auf Basis des
Keil MCB900.
Als IDE nutze ich Ride7, zum Flashen Flash Magic. Da Autobaud von FM
nicht funktionieren wollte, habe ich den Controller über das senden
eines "u" über Putty auf 9600Baud stellen lassen.
Codestart ist im Programm bei 0000h angegeben, ISP-Protection in FM ist
an, in der DeviceConfig wurde auf High Frequency Crystal umgestellt,
unter Communications das Quarz mit 12.000MHz angegeben.
Der Controller ließ sich jetzt genau einmal flashen.
Da ich dachte, es läge an meinem Programm (habe den Port1 komplett auf
Input gestellt - P1M1; nach weiterem Nachdenken, sollte das nicht
stören, da das ja erst nach dem Booten ausgeführt wird), habe ich den
Part aus dem Programm entfernt und versucht einen zweiten Controller zu
flashen.
Das gleiche wieder. Jetzt ist nur noch ein weiterer 922er über und
Montag ist Projektabgabe.
Bevor ich die Spannung weggenommen hatte, war der LPC nach dem Flashen
noch über die serielle Schnittstelle ansprechbar. Jetzt aber nicht mehr.
Weiß wer weiter? Woran könnte das liegen? Fehler meinerseits? Irgendwas
nicht beachtet?
Danke,
Stefan
stef schrieb:> auf Basis des Keil MCB900
Du hast also den LPC935-PLCC aus dem MCB900 rausgezogen und einen
LPC922-DIP in den DIP-Sockel gesteckt? Dann RESET-Jumper und mit FM
flashen. Dann RUN-Jumper und Dein Programm läuft?
Übrigens, dafür ist es natürlich jetzt zu spät, aber ein LPC-Programmer
besteht genau aus 1 Transistor und 4 NAND-Gates, sollte man also selber
machen.
stef schrieb:> Da Autobaud von FM> nicht funktionieren wollte, habe ich den Controller über das senden> eines "u" über Putty auf 9600Baud stellen lassen.
FM müsste eigentlich anzeigen dass der LPC922 nur 7200 Baud kann.
Was sagt denn "ISP->ReadDeviceSignature"?
stef schrieb:> Der Controller ließ sich jetzt genau einmal flashen.
Du wirst doch nicht den Bootloader überschreiben (ist ganz hinten im
Flash). FM wie folgt eingestellt?
Erase all Flash+Code Rd Prot : AUS
Erase all blocks used by Hex File : AN
Fill unused Flash : AUS
Hallo Lothar,
nein, ich habs so gelöst, wie von Dir vorgeschlagen.
Hab' den MAX232, einen Transistor und ein 4xNAND plus deren "drumrum".
Die Lösung habe ich aus einem Schaltplan vom MCB900.
FM hat 7200 als empfohlene Baudrate angegeben. Aber über Putty hab' ich
nach dem Senden des "U" alle Zeichen zurückbekommen. Von daher gehe ich
davon aus, dass das mit der Baudrate dann gepasst hat.
"ISP->ReadDeviceSignature" gab vorher das aus, was es sollte.
Nach dem Flashen kommt nun nur noch "Unable to connect at the specified
baud rate (...) failed to autobaud". Egal, welche Baudrate, gleiches
Spiel.
Der Bootloader sollte eigentlich nicht überschrieben sein. Hab' zwar den
Haken bei "Erase all Flash" gesetzt, zusätzlich aber auch den Haken
unter "Options->Advanced Options->Security->Protect ISP-Code".
Vor dem Flashen hat FM gefragt, ob ich mir sicher bin, dass ich den
ISP-Code schützen möchte, was ich bejaht hatte.
Sollte also so passen...
Kann das irgendwie mit dem Boot Status Bit zusammenhängen? Ich meine mal
irgendwo vor Wochen was davon gelesen zu haben, dass das bei manchen zu
Problemen geführt haben soll. Finde aber die Seite nicht mehr, da ich
mich nicht mehr an den genauen Zusammenhang erinnere.
stef schrieb:> ich habs so gelöst, wie von Dir vorgeschlagen.
Das sollte der Lehrer ja schon mal honorieren. Also den letzten LPC922
aufheben und am Mo live flashen :-)
Läuft das Programm nach dem Flashen oder nicht? Wenn ja sollte es ja
trotzdem passen.
stef schrieb:> Der Bootloader sollte eigentlich nicht überschrieben sein.
Kenne das Ride7 nicht, und das sollte eigentlich ausgeschlossen sein,
aber wenn Ride7 in einem LPC-Projekt als Default im generierten HEX-File
die Security Bits setzt, wird der Bootloader abgeschaltet
(CodeReadProtection).
Aber auch dann sollte das noch funktionieren: "ISP->ReadSecurity"
Oder als Default ein externer Quarz eingestellt ist.
Ich würde mal den Compiler und das Blinky für das MCB900 versuchen:
http://www.keil.com/c51/ca51kit.asp
Ich frag' mich nur, obs was an der Sache geändert hätte, hätte ich nicht
"Erase all Flash" gewählt. Kann ich mir aber echt nicht vorstellen,
zumal die ISP-Protection ja aktiv ist.
Und am Bootloader sollte es jetzt eigentlich echt nicht liegen. Die
serielle Verbindung gibt ja nichts mehr her.
Wenn ich vorher noch übers Terminal ein Echo bekommen hab, ist da jetzt
nichts mehr.
Kann auch am Oszi die Pegeländerung sehen, aber kein Echo auf der
anderen Leitung.
Das Programm läuft leider nicht, Ausgänge kommen nicht. Wollte erst mal
testen, ob alles anspricht und mich dann an die eigentliche Sache
machen. Das Projekt sollte ein POV-Display werden.
In der Schule nutzen wir ein Board, das einer mal als Technikerarbeit
erstellt hatte...leider ist das etwas zu wuchtig für mein Projekt.
Darauf nutzen wir allerdings auch einen andern µC.
Denke nicht, dass Ride die Security Bits setzt, da haben wir bei unserem
Board mit Atmel 8051er jedenfalls noch nie Probleme gehabt.
Bei Flash Magic lassen sich für einzelne Speicherbänke Security Bits
setzen, aber da steig ich ehrlich gesagt nicht so recht durch.
An Keil hab' ich mich schon vergebens versucht. Als ich testweise
kompilieren wollte, wurde ich mit Fehlermeldungen "attempt to define an
already defined symbol" überhäuft. Hatte daraufhin alles "doppelte" in
der include-Datei auskommentiert, brachte aber auch keine Lösung.
Außerdem versteh ich nicht, wie die Startup900.a51 ins Projekt
integriert wird.
Im Netz bin ich jetzt auf "NoTouch" gestoßen, was die Prozedur um in den
Bootloader zu kommen, erleichtern soll.
Wird mir aber auch nicht viel bringen, da ich ja eher ein Problem mit
der seriellen Kommunikation habe. Wüsste nicht, was ich da noch setzen
oder nullen müsste, um das zu verhindern.
Bin langsam echt am Verzweifeln, was die Geschichte angeht. Hätte nicht
gedacht, dass es daran scheitern wird.
Mal anbei die ISP-Schaltung die ich verwende.
Beim Keil ist ein fertiges Blinky-Projekt dabei, da musst Du nur das
C-Programm entsprechend ändern.
Wenn Du den letzten LPC922 noch flashen willst, hier ein HEX-File das
bei mir funktioniert:
:10080000EF1F70011E144E70F7EF1F70011E144E83
:1008100070F7EF1F70011E144E70F7EF1F70011E6E
:05082000144E70F722E8
:100825007584FF7585FFA280B392807FFF7E0011DE
:030835000080F34D
:04FFF00043001F00AB
:08FFF800000000000000000001
:03000000020838BB
:0C08380078FFE4F6D8FD75810702082562
:00000001FF
Hier das C-Programm:
#include <REG922.H>
// long delay
void delay(unsigned int cnt)
{
while (--cnt);
while (--cnt);
while (--cnt);
while (--cnt);
}
// LED on P0.0
sbit LED = P0^0;
void main(void)
{
// P0 open drain mode (= external pull)
P0M1 = 0xFF;
P0M2 = 0xFF;
for(;;)
{
// toggle LEDLED ^= 1;
delay(0xFF);
}
}
stef schrieb:> MAX232
Das könnte auch noch sein: bleibt Dein MAX232 wirklich <= 5V ?
Der LPC ist nämlich ein 3.3V Core und hat nur 5V tolerante Pins. Wenn Du
also an RX 5.5V anlegst könnte der Pin erledigt sein. Dann kann der
Bootloader natürlich nicht mehr angesprochen werden.
Im MCB900 ist ein MAX3221 mit 3.3V
Lothar schrieb:> Der LPC ist nämlich ein 3.3V Core
Woher kommt eigentlich bei Dir die Versorgungsspanung VCC 3.3V für den
LPC ? Hier verträgt der LPC nämlich sogar nur max. 3.6V Wenn Du VCC vom
MAX232 ziehst (auch über Spannungsteiler) ist der LPC wohl hinüber. Es
ist ein 3.3V Spannungsregler erforderlich.
Muss jetzt mal kurz einkaufen, danach probier ich das ganze gleich mal
aus. Danke Dir!
Den MAX232 hatte ich schon am Oszi hängen, über 5V ist der nie hoch.
Meine Schaltung entspricht in etwa der deinen. Die passt auch, da bin
ich mir sicher.
Hatte ja manuell schon übers Terminal Zeichen gesendet. Wenn da
spannungstechnisch was schief gelaufen wäre, wäre ich schon gar nicht
mehr zum Flashen gekommen.
Ich wollte zuerst die 3,3V-Variante bestellen, war aber nicht lieferbar.
Da die Pins 5V ab können, hab ich den 5V MAX232-CPE bestellt.
Der LPC hängt an einem 3,3V-Regler. Die 3,3V gehen über einen Pin raus
auf den Programmer über den Transistor und zurück. Hab auf meiner
Steuerplatine einen Schalter, um zwischen den eigenen 3,3V VDD und denen
vom Programmer umzuschalten.
stef schrieb:> danach probier ich das ganze gleich mal aus
Dann aber auch mal direkt vor und nach dem Flashen mit
"ISP->DisplayMemory" nach dem Bootloader sehen.
stef schrieb:> Ist ausgegraut
Mein Fehler, der LPC900 Bootloader kann das nicht, kann erst der
Nachfolger LPC800. Aber schau mal unter "File->Information" sollten bei
meinem HEX-File 296 bytes sein.
Sorry, habs noch nicht probiert. Suche gerade noch weiter im Netz nach
Möglichkeiten einen erneuten Fehler zu vermeiden. Will alles versuchen,
um mir noch 'ne kleine Chance zu verschaffen, dass das doch noch klappt.
Da gibts u.a. mehrere Backdoors. Einmal NoTouch und dann noch den UART
Break Detect. Mit beiden lässt sich über bestimmte "Reize" an den Pins
der Bootloader des LPC starten.
//UART Break Detect
SCON = 0x50; // select the BRG as UART baud rate source, pg. 60
SSTAT = 0x00; //Timer1
BRGR0 = 0xF0; // 9600 BAUD at @ 7.373MHz internal RC oscillator
BRGR1 = 0x02; //timer increments every .0271 microsec.
BRGCON = 0x03; // enable BRG, pg. 59
AUXR1 |= 0xC0; // enable reset on break detect, pg. 102
Das ist jetzt für einen 932er, werde wohl versuchen die Methode in ein
neues File zu integrieren - natürlich angepasst auf den 922er.
Eventuell auch alternativ die NoTouch-Methode.
Was mir aber noch viel lieber wäre, wenn ich den verbliebenen LPC nutzen
könnte, um die anderen beiden per ICP zu retten. Leider habe ich keine
Ahnung, wie ich das anstellen soll.
stef schrieb:> 294 bytes zeigts mir an
Das sollte passen, ich habe hier noch eine Leerzeile drin dann sind es
296 bytes, das ist FM aber bestimmt egal.
stef schrieb:> wenn ich den verbliebenen LPC nutzen> könnte, um die anderen beiden per ICP zu retten
Das habe ich noch nie versucht und dürfte deutlich komplexer sein als
Dein eigentliches Projekt. Prinzipiell kann man einen LPC schon nutzen
um einen anderen zu programmieren. Die Doku findest Du mit Google:
AN10258: How to use the LPC900 In-circuit programming
Wenn es nicht zu spät wäre hätte ich Dir noch zu anderer Hardware raten
können:
Statt LPC900 die Nachfolger LPC800 oder LPC1100 nehmen:
- Bootloader-ROM, habe noch nie einen kaputt bekommen
- braucht keinen Programmer mehr (diesen 1 Transistor und 4 NAND-Gates)
- billiger
Statt RS232/MAX einen USB-seriell-Wandler:
- von dem kann man gleich die 3.3V ziehen
http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-Neu-/251454579542?pt=Bauteile&hash=item3a8bdc6356
Außerdem können die LPC800 oder LPC1100 notfalls mit LPC-LINK 2
preisgünstig debuggt werden.
Naja, das Problem ist, dass wir einen 8051er nutzen müssen.
Die von dir genannten sind, meines Wissens, ARM-Controller.
Mir wäre mehr Freiheit, was die Controller angeht, lieber gewesen. Mit
einem anderen hätte ich wahrscheinlich weitaus weniger Probleme gehabt.
Ich danke Dir auf alle Fälle mal für deine Hilfe. Ich werde jetzt mal
versuchen eine der Backdoor-Lösungen umzuschreiben und dann den letzten
Controller zu flashen. Wenns schiefgeht, hats wenigstens Erfahrung
gebracht.
Falls es funktioniert, werd ichs hier reinstellen...falls nicht, dann
kann man das Projekt als gescheitert ansehen ;)
Danke für die Tipps!
Ich hab das ganze jetzt endlich gelöst bekommen.
Kein Grund mehr für den Programmer, jedenfalls insofern man einen
jungfräulichen LPC hat oder einen alten mit dem Programmer umflasht.
Bin gestern auf "NoTouch" und "backdoor" gestoßen. Zwei Fetzen Code, die
man leicht in das Projekt integrieren kann.
Da ich mit der ganzen Geschichte noch nicht wirklich viel Erfahrung
habe, hab' ich jetzt Datenblatt nach Datenblatt gewälzt und das ganze
minimal auf meine Bedürfnisse abgeändert, da das Ursprungsfile für den
LPC932A1 war.
Hatte nur Bedenken, dass ich ausversehen die falschen Entrypoints für
den Bootloader, bzw. Boot Vector nutze.
Nachdem ich gesehen hatte, dass die beiden LPC den gleichen ISP-Source
nutzen, war alles kein Problem mehr.
Das Projekt bekomm' ich zwar bis morgen definitiv nicht mehr fertig, an
Erfahrungen bin ich jetzt aber um einiges reicher. Immerhin.
Ab jetzt geht das Flashen jedenfalls easy und nur noch mit dem MAX232,
kein NAND-Gatter und Transistor mehr nötig.
Danke für die Hilfe!
Stefan
stef schrieb:> Ich hab das ganze jetzt endlich gelöst bekommen.
Gratulation. Nur zu meinem Verständnis: dann hat das erste Flashen des
Backdoor-Codes mit dem Programmer funktioniert (und danach geht es ohne
Programmer). Dann überschreibt das erste Flashen wohl irgendwie den
Bootvector, oder?
Danke.
Geht auch schon beim ersten Flashen ohne Programmer. Ein fabrikneuer LPC
hat das Boot Status Bit auf 1 stehen, ist also direkt im Bootloader,
wenn er Spannung bekommt.
Woher die ganze Problematik jetzt kam, weiß ich leider immer noch nicht,
dem will ich aber noch nachgehen, sobald ich wieder mehr Zeit zur
Verfügung hab.
In diversen Foren war die Rede davon, dass Flash Magic bei "Erase all
Flash" wirklich den Boot Vector löscht. Kanns mir aber kaum vorstellen,
da anderswo empfohlen wurde, hier den Haken zu setzen. Da gabs ja dann
auch keine Probleme.
Dass es an meinem Programmer liegt, schließ ich eigentlich auch fast
aus. Hab mehrmals alles kontrolliert. Werd mir das aber bei Zeiten noch
mal am Oszi ansehen, ob die Reset-Sequenz wirklich passt.
Die ganze Geschichte ist für mich leider noch ein Buch mit sieben
Siegeln. Werde wohl meine Sommerferien dazu nutzen, um mich intensiv mit
der Materie auseinanderzusetzen, zumal dann auch gleich die
Technikerarbeit ansteht.
