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.
Angehängte Dateien:
-
ISP.jpg
130 KB
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 LED LED ^= 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.
294 bytes zeigts mir an. Datei mit Editor erstellt und als *.hex abgespeichert.
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 ;)
stef schrieb: > Die von dir genannten sind, meines Wissens, ARM-Controller. Sind aber auch LPC also kompatible Peripherie. stef schrieb: > Mit einem anderen hätte ich wahrscheinlich weitaus weniger Probleme gehabt. Nachdem ich am Anfang Probleme mit meinem Programmer (diesen 1 Transistor und 4 NAND-Gates) hatte, geht der jetzt, und seitdem ist auch kein LPC900 mehr kaputt gegangen. Ich vermute bei Dir immer noch eher ein elektrisches Problem. Es gibt übrigens auch moderne 8051 z.B. hier komplett mit USB-Programmer für 8 EUR: http://www.silabs.com/products/mcu/smallmcu/pages/web-drawing-for-c8051f850-toolstick-starter-kit.aspx Dazu kommt dass die meisten SoC noch 8051 nutzen z.B. für Internet-of-Things die kann man dann auch nehmen (natürlich etwas überdimensioniert): http://www.ftdichip.com/MCU.html http://www.ti.com/product/cc1110f8
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.