Hallo, ich habe hier ein lpcxpresso1769 board, das ich mit der mitgelieferten Code Red IDE programmiere. Jedenfalls in einigen Fällen. Leider kommt es häufig zu Fehlern beim Programmieren, so was wie "Flash write error", "Target board not ready" oder ähnlich. Manchmal hilft nochmal probieren, teilweise muss man den lpc in den ISP Modus setzen und oft probieren, irgendwann gehts dann. Hat jmd. hier sowas auch beobachtet? Ich habe verschiedene, kurze und hochwertige USB-Kabel probiert, externe Spannungsversorgung, Linux, Windows, 2 verschiedene Rechner, 2 verschiedene Lpcxpresso boards (beide 2010 Rev. B). Woran könnte das noch liegen? Mir gehen die Ideen aus. Wenn ich ihn dann programmiert bekomme, tut er was er soll. Danke und Viele Grüße nicolas
Hmmmm ... ich habe so den Eindruck, gewisse Komponenten sind etwas zu früh in Fertigung und Verkauf gegangen. Ich habe jetzt 2 h Fehler auf dem AVR-IO gesucht. Symptom: RESET liegt bei 3 V aktiv, bei 4 V inaktiv. Erwartet hätte ich etwas anderes. Anscheinend hat die RESET-Leitung des Programmers versucht die Spannungsversorgung der Platine zu übernehmen. USB-Kabel raus und wieder rein, auf einmal geht's. Abgestürzt ? (AVR-IO, Attiny2313, Diamex-Programmer) Mitfühlende Grüße, Joe
Ja, eben, das riecht schon sehr nach irgendetwas halbgarem. Ich habe einfach noch ein Exemplar bestellt (die anderen habe ich vor längerer Zeit bestellt), in der Hoffnung dass die neuer sind und vl weniger Fehler haben. :/ Nerv Um soetwas zu vermeiden, kauft man doch "professionelle" Hardware. VG nicolas
Ich kaufe nichts wo "Profi" draufsteht ;) Irgendwie hat die ganze Geschichte so ihre Tücken. Fast immer Kleinigkeiten die man irgendwann einmal kennt und sich keine Gedanken mehr darum macht. Fängt man damit an, klemmt's halt. Wenn Du ein Scope hast miß mal die Leitungen von vorne bis hinten durch, angefangen habe ich mit den ISP-Signalen.
Ja, aber - was mich wundert, ich bin doch wohl kaum der einzige, der das Ding nutzt. Und getestet ist das auch - da liegt der Fehler ziemlich sicher bei mir. Aber wo? Ich meine, ich kaufe einen Prototypen, stecke den USB-Stecker an, und schreibe die mitgelieferten Beispiele mit der mitgelieferten IDE auf das Ding. Und das klappt schon nicht. Das kann ja wohl nicht sein! Na ja, mal sehen.
Ich tippe auf irgendeine Kleinigkeit. Check alles noch mal durch. Pingeleig und mit gnadenloser Sturheit. Prinzipiell scheint es ja zu gehen, ist also nicht "richtig" kaputt.
ich nutze den LPC xpressoDebugger mit einem eigenem Board Anfangs lief es garnicht .. dann mit deinen obiogen Fehlern und nun tritt es extrem selten auf. schuld war der reset C bei meiner schaltung die LPCXpresso variante der IDE enthielt mal einen FIX um diese fehler zu verringern. schuld sind hier scheinbar die timings nach einem reset. schlimm wirds erst wenn was mit "non debugable" dasteht .. aber ansonst is die IDE + Debugger schon recht .. empfindlich
nicolas schrieb: > Na ja, mal sehen. Mit diesem Code Red konnte ich nichts anfangen und habe mir von Keil eine Demoversion von µVision4 geladen. Damit konnte ich dann erfolgreich LEDs blinken lassen ;-) Was bei Keil nervt, ist der Hinweis auf 32k Limit bei jedem Compileraufruf. Dann gibt es noch von IAR eine Kickstart-Version; die nervt nicht und rechnet nicht nur float sondern auch double. Für mich die angenehmste Software, vielleicht auch für Dich.
Ja, es sieht ganz so aus. Mir ist nur schleierhaft, wie man soetwas in dem Zustand verkauft - immerhin ist das ja keine Wald-und-Wiesen Firma. Da sollte man erwarten, die machen das richtig.
Aber im Grunde ist das doch Eclipse mit den entsprechenden Kommandozeilentools. Das ist doch auch kein Zauberwerk, und der Fehler hier riecht doch eher nach Hardware, finde ich.
nicolas schrieb: > und der Fehler hier riecht doch eher nach Hardware, finde ich. Das weiß man aber immer erst nachher! Bei Keil und IAR kosten die IDEs richtiges Geld; die können sich keine Schnitzer bei Demoversionen erlauben, anderfalls werden sie nichts verkaufen. Wenn mit deren Software der Fehler ebenfalls vorhanden ist, dann ist es die Hardware!
Als ich das lpc1769 lpcxpresso bekommen hatte, habe ich mich 3x geärgert: Man musste sich registrieren, die IDE hat ein Limit auf 128k, und die Installation würde einem das Linux versauen, weil libusb einfach überschrieben wird (Installation geht nur als "root"). Und es war extra mit "Linux-Support" beworben. Im Gegensatz zu den STM32 discoveries: Dort steht nichts von Linux, aber der Debugger geht trotzdem ;-) Ziemlich angesäuert habe ich den lpc-Part abgesäbelt - chop-chop - und mir eine UART boot loader - Beschaltung gebaut. D. h. seit Anfang an wird via UART programmiert. Kein Code-Limit. Kein Ärger. Für mich war das OK, da ich weder IDE noch Debugger benötige. Den Debugger brauche ich eh extrem selten, und wenn doch, dann halt auf einem STM32 discovery. Wenn ich jetzt noch lese, welche Problem noch gewartet hätten ... gut dass der Appendix weg ist ;-)
alternative ist zB CooCox IDE einen JTAG gibts dort zu kaufen .. ( oder auch DIY möglich ) einmal FTDI version udn einen mit kontroller damit gehen dann zumindest in der IDE STM , NXP , usw alles mit GCC ohne codelimit
Also ich kann mich nicht beschweren, ich habe sowohl den 1343, als auch den 1769 auf einem LPCXpresso Board, und alles hat von Anfang an funktioniert. Bei mir gabs zwischendrin mal kurz Schwierigkeiten, (Target nicht gefunden) komischerweise hat da plötzlich mein Firewall reingepfuscht, lag wohl am Windows-Update. Das Code Limit von 128k reicht mir noch etwas aus. Auch die oben genannte "Empfinglichkeit" habe ich bisher nicht beobachten können.
Ich verwende ebenfalls LPCXpresso Board mit der Code Red Umgebung und soweit funktioniert diese tadelos. Die hier genannte CooCox IDE habe ich ebenfalls getestet und diese führt bei mir sofort zum Absturz. So unterschiedlich sind also die Erfahrungen.
Also zum LPC-Link selbst kann ich sagen, das das ganze sehr empfindlich einmal gegen ESD ist und vor allem gegen Störungen die durch EMV also Störquellen um dich rum entstehen können. Ich muss wenn ich sinnvoll debuggen will mit dem Ding immer eine ESD Matte und ESD Armband anlegen, da es sonst zu ungewollten Abstürzen kommen kann. Liegt aber bei mir an der unpassenden Kombination mit dem Teppichboden und meinem Stuhl, diese laden sich gegeneinander auf und die Entladungen die dann passieren (über mich) führen schon mal zu ungewollten Ergebnissen. Auch in der Firma wo der LPC-Link nur für kleine Dinge verwendet wird, ist immer eine komplette ESD Ausrüstung vorhanden. Auch hier gibt es keine Probleme. Aber sobald man das ganze wegläst hat man nur Ärger! Ach ja noch mal so am Rande mit den FTDI basierenden Debuggern (hier JTAG und nicht SWD) hab ich das Problem nicht, ebenso wie mit professionellen Tools von einschlägig bekannten Firmen.
Danke für Eure Erfahrungen - interessant wie unterschiedlich die sind. @Roland: "Ziemlich angesäuert habe ich den lpc-Part abgesäbelt - chop-chop - und mir eine UART boot loader - Beschaltung gebaut." Das hört sich gut an. Wie genau sieht denn die Beschaltung aus? Und womit programmierst du dann, Kommandazeile? Und gcc, oder wie? Danke und Viele Grüße nicolas
nicolas schrieb: > @Roland: "Ziemlich angesäuert habe ich den lpc-Part abgesäbelt - > chop-chop - und mir eine UART boot loader - Beschaltung gebaut." > > Das hört sich gut an. > > Wie genau sieht denn die Beschaltung aus? Chop-chop: http://www.ucapps.de/mbhp_core_lpc17.html Beschaltung: Sieht man schön bei den Keil-Eval-Boards, z. B. http://www.keil.com/mcb1700/mcb1700-schematics.pdf lpc21isp steuert dann mittels DTR + RTS Reset und "boot loader select". nicolas schrieb: > Und womit programmierst du > dann, Kommandazeile? Und gcc, oder wie? Ja, was sonst? ;-) summon-arm-toolchain, GNU make, Emacs etwas aufgebohrt. Eclipse 2x versucht, ist jedes Mal gescheitert, da es mit den "Makefile projects" nicht wirklich funktionierte.
super, danke. Das werde ich probieren. lpc21isp: das geht trotz des Namens auch für den 17xx ? Ah ja, seh ich gerade.
nicolas schrieb: > super, danke. Das werde ich probieren. > > lpc21isp: das geht trotz des Namens auch für den 17xx ? Ah ja, seh ich > gerade. Ja, der Name verwirrt. Das passt schon, die lpc2xxx waren halt früher "da" :-)
Reicht denn für die Lösung mit lpc21isp der vorinstallierte bootloader? Also reicht es den lpc in den ISP Modus zu versetzen ? Oder brauchts ein einmaliges Flashen der bootloader Sektion? Hat vl jmd schon mal einen bootloader über ethernet probiert? Da gibts ja ein paar auf den einschlägigen Seiten. Nur interessehalber. Viele Grüße Nicolas
nicolas schrieb: > Reicht denn für die Lösung mit lpc21isp der vorinstallierte bootloader? > Also reicht es den lpc in den ISP Modus zu versetzen ? Oder brauchts ein > einmaliges Flashen der bootloader Sektion? Ja. Ja. Nein. Lies Dir mal im ref manual alles zum Thema "boot loader" durch. Das ist anders, als man es z. B. von den atmegas her gewohnt ist. nicolas schrieb: > Hat vl jmd schon mal einen bootloader über ethernet probiert? Da gibts > ja ein paar auf den einschlägigen Seiten. Nur interessehalber. Beim Ethernut wird das so gemacht (Nut/OS). Vielleicht wirst Du dort fündig.
Nicht gleich aufgeben... die Dinger gehen weg wie warme Semmeln, und bei den meisten hats funktioniert. Coocox werde ich mich aber auch mal ansehen
Ok, ich habe ein weiteres LPCXpresso board bekommen, das gleiche wie oben beschrieben. Nur Murx, kein Arbeiten möglich. Dann also per bootloader, an UART0 und mit lpc21isp -> Alles funktioniert absolut zuverlässig. Nach wie vor stellt sich mir die Frage, wie man einen "Debugger" verkaufen kann, der selbst so unzuverlässig ist. Aber so läufts ja! Vielen Dank nochmal für die Unterstützung hier! Viele Grüße Nicolas
Also ich habe bisher 4 davon im Einsatz. Alle gehen. Sowohl unter w7 x64 als auch unter xp. Wenn sich das Programm im Startup verrennt oder die pll falsch programmiert, hilft wirklich nur noch den Bootloader-Pin auf Masse zu legen. Sonst habe ich aber keinerlei Probleme. Irgendwie scheint das Problem vorm Monitor zu sitzen.
Habe zwei LPCxprssos mit 1769 im Einsatz. Eines original und eines getrennt und mit Gehäuse zum Debuggen / Flashen eigener Hardware. Läuft mit der CodeRed IDE und ist nicht wirklich sehr viel anders als jetzt ein uLink etc. Leichte ESD Empfindlihkeit kann ich bestätigen, was aber max. Ab- und Anstecken bedeutet hat und sehr selten passierte. Ich sehe da kein prinzipielle Problem und tippe eher auch den PC. Mit bin\crt_emu_cm3_nxp.exe kann man auch ohne den Debugmode der IDE per JTAG flashen. Gruß Mirko
Ja, ich glaube ja auch nicht das die Dinger grundsätzlich schlecht sind, aber: An drei unabhängigen PC das gleiche, wie oben beschrieben. Win und Linux: Das selbe Problem. Und zu "Problem vor dem Monitor": Ich nehme die originale IDE, original Beispielprojekt, ein kurzes USB Kabel, und versuche es zu programmieren. Was kann ich da falsch machen?! Keinerlei eigene Hard- oder Software! Und völlig unerfahren bin ich in solchen Sachen auch nicht. Und der bootloader funktioniert einwandfrei. Das Problem liegt also beim LPC-Link. Ich bleibe dabei: Nach wie vor stellt sich mir die Frage, wie man einen "Debugger" verkaufen kann, der selbst so unzuverlässig ist. Welche Revision des LPCxpresso habt Ihr denn? Bei mir ist es Rev. B. Viele Grüße Nicolas
"Wenn sich das Programm im Startup verrennt" was genau meinst Du damit?
Leider Nein, diverse verschiedene probiert (neu, USB 2.0 und kurz). Und: beim Bootloader gehts (na gut, ist auch langsamer).
Ich arbeite nur mit makefiles und übersetze die Programme wahlweise mit CodeRed, codesourcery, oder yagarto. Für den gesamten printf-Part aus der newlib verwende ich eigene Funktionen. Die LpcXpresso IDE benutze ich im Moment nur zum Flashen und Debuggen. Bis ich das am Laufen hatte, habe ich auch viel Mist gemacht und dabei beobachtet: Sobald das Programm so buggy ist, dass es auf einen HardFault-Handler läuft, ist das Neuflashen ohne den Bootloader-Pin auf Masse zu legen kaum möglich. Wenn mit den Linkerscripts was nicht passt oder der Initialisierung der PLL, kann auch der Zustand auftreten, dass über JTAG nichts mehr geht. Unschön ist auch, dass das Starten einer Debug-Session in Eclipse möglich ist, wenn noch eine läuft und damit den lpc-link belegt. Die Fehlermeldungen sind da ähnlich wie oben beschrieben. Es ist mir auch schon untergekommen, dass sich das makefile-Projekt in Eclipse (nur zum Debuggen angelegt) die CPU nicht gemerkt hat und davon ausging, dass ich eine LPC13xx flaschen wollte, was natürlich nicht gehen kann. Das sieht man auch nicht sofort.
Jürgen Liegner schrieb: > makefile-Projekt Soso .. ein "makefile-Projekt" ;) Was soll denn das sein ?
Funktioniert gut, aber NUR wen das Teil direkt am PC angesteckt werd... NICHT über einen Hub
war direkt am USB Port ohne Hub, und kurzes Kabel. Vl habe einfach Pech mit meinen 2 -3 Rechnern? Auch eher unwahrscheinlich.
Es gibt in der RedSuite einen Schalter namens Vector Catch, der schafft immerhin ein wenig Abhilfe: Beitrag "LPC1768 mit Red Suite und eigenem Linker Script"
Den habe ich mit Hilfe der Foren bei nxp auch schon entdeckt, daas hilft auch tatsächlich etwas. Also in einigen Fällen. Aber lange nicht in allen. Ich kann nach einigen Versuchen immer Prgogrammieren, aber so kann man doch nicht arbeiten. Aber das muss doch auch ohne solche "Tricks" gehen?
Schade, ich ärgere mich nämlich auch schon seit ein paar Tagen mit dem LPC-Link herum. Neben dem Vector-Catch gibt es noch die Möglichkeit, den Debugger bei laufender RedSuite vom USB abzuziehen und neu anzustecken. Das hilft bei mir bisher immer, auch wenn es eine unschöne Lösung ist.
Hallo, ich habe auch gerade das LPCXpresso LPC1769 und dazu das Base Board gekauft, um den Prozessor erst einmal ohne sonstige Bauaktivitäten ausprobieren zu können. Erster Frust: Prozessor auf das Base Board gesteckt und versucht, mir Code-Red ein Beispielprogramm zu laden, es gabb immer die Fehlermeldung "device not debuggable" oder so ähnlich. Der LPCXpresso alleine ohne Base Board ließ sich aber im Debugger ansprechen. Erst nach längerem Suchen fand ich heraus, daß man die beiden Jumper von J54 entfernen muß, die ziehen sonst den Reset dauerhaft herunter. In der Doku des Base Boards steht das nur ziemlich versteckt und eher indirekt formuliert, defaultmäßig sind die Jumper gesetzt, scheint mit anderen Prozessoren wohl zu gehen. Danach funktionierte das Downloaden endlich und ich konnte einige Beispielprogramme ausprobieren. Ich habe hier gelesen, daß in einigen hartnäckigen Fällen es nötig sein kann, den "Bootloader-Pin" auf Masse zu ziehen. Auch woanders habe ich das schon gelesen, aber leider nirgendwo erfahren, was der Bootloader-Pin denn ist. Irgendwo stand was von Pin59 des LPCXpresso, aber der Adapteranschluß hat nur 54... Pin 59 des Prozessors selber ist es wohl eher nicht. Alle herausgeführten Pins haben abgesehen von VCC, GND und Reset nur allgemeine Portnummern, welcher muß denn dann nach Masse gezogen werden? Programmiert wird mit der Code Red IDE über den Teil von LPCXpresso, der später abgesägt werden kann, später will ich den LPCXpresso mit abgesägtem Teil in Eigenbauprojekten verwenden, zum Programmieren, wird der über Steckerleisten angesteckt. Ach, ja, das Beispielprogramm mit der RGB-LED auf dem Base Board funktionierte auch erst einmal nicht, die RGB-LED wird über "VIN" versorgt, VIN wird aber über Dioden von den beiden USB-Buchsen auf dem Base Board "geodert" und versorgt dann einen 3.3V-Regler. Die RGB-LED braucht wohl mehr als 3.3V. Allerdings gibt es gar kein VIN, wenn man über die USB-Buchse des LPCXpresso angeschlossen ist und auch darüber versorgt... Ein zweites USB-Kabel vom PC zu einer der anderen USB-Buchsen löst das Problem, das lieferte nur über die 5V und eine Diode die Spannung "VIN". Weitere Fragen kommen wahrscheinlich später noch. Gruß
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.