Hallo,
ich habe ein Evaluation Board von NXP (es ist das OM13056) mit einem
LPC1549 darauf. Um damit mal einzusteigen, habe ich in LPCXpresso ein
Beispielprojekt geöffent und compiliert. Bis dahin funktioniert alles
soweit. Beim Flashen erhalte ich allerdings folgenden Fehler:
Nt: Writing 4608 bytes to address 0x00000000 in Flash
33
Pb: 1 of 1 ( 0) Writing pages 0-1 at 0x00000000 with 4608 bytes
34
Ps: ( 0) at 00000000: 0 bytes - 0/4608
35
Nc: After error Nn(05). ACK Fault -
36
Nc: Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
37
Nc: After error Nn(05). ACK Fault -
38
Nc: Failed to read address register in DAP - Ee(FF). Redlink interface error 255.
39
Wc: failed to send op Terminate message - rc Em(16). Debug port inaccessible after access at location 0x02002458 - verify population of memory and peripherals
40
41
Pb: (100) Writing Flash ended with an error.
42
Ed:05: File 'LCD_LPC6.axf' load failure: Em(16). Debug port inaccessible after access at location 0x02002458 - verify population of memory and peripherals
43
Pc: (100) Target Connection Failed
Ich bin nun etwas ratlos, woran das liegen könnte? Ich verwende Ubuntu
14.04 und habe die udev rules von NXP übernommen.
Hat jemand eine Idee?
Viele Grüße,
Doran
Danke für den Tipp, der Mass-Erase funktioniert ohne Probleme, habe ich
gerade durchgeführt. Nur leider funktioniert das flashen des Programms
immer noch nicht, die Fehlermeldung ist weiterhin wie oben gepostet.
Woran könnte es noch liegen?
unter Linux habe ich das nie benutzt, da fällt mir nicht mehr so viel
ein. Die Debug Probe wird ja erkannt, die USB Treiber Seite sollte damit
ok sein.
Ist ein Test unter Windows möglich? Und die akutelle Version ist
MCUXpresso, allerdings hat das LPCXpresso bei mir seit Version 3.6 auch
immer gut funktioniert.
da kann man bei dem Board eigentlich nichts falsch machen, der Debugger
ist da mit drauf. Es gibt einen Jumper JP2, der muss auf 'Loc'al stehen,
bei 'Ext' kann man ein externes Target über den SWD Connector
anschliessen. Aber wenn das löschen geht muss ja schon eine Verbindung
da sein.
Dann gibt es noch den DFU-Link Jumper. Wenn der gesteckt ist wird das
Board als DFU Device erkannt. Wenn LPC/MCUXpresso einen Download machen
möchte erkennt es das Board und programmiert erstmal per dfu_util die
Firmware für die Debug Probe, also mal mit gestecktem Jumper USB Kabel
raus/rein probieren.
Gerade eben habe ich den Rechner hochgefahren und das Board an einen
anderen USB-Port gesteckt. Jetzt kann ich auf einmal ohne Fehler den LPC
programmieren!
(Jumper war die ganze Zeit auf Loc(al) und der DFU-Jumper nicht
gesetzt).
Keine Ahnung, warum es jetzt auf einmal geht (auch an dem anderen
USB-Port geht es jetzt), aber Danke für die Tipps.
Viele Grüße,
Doran
Jetzt funktioniert zwar das Flashen über LPCXpresso, aber ich würde
gerne auch über die Kommandozeile flashen. LPCXpresso zeigt mir an, dass
es folgenden Befehl verwendet:
Das würde ich dann mit openOCD machen, das ist besser dokumentiert als
der proprietäre redlink server. Das interface wäre cmsis-dap, das kann
openOCD auch bedienen.
Für die Software kann ich noch mbed-os empfehlen, das unterstützt den
LPC1549 auch. Über das mbed-cli kannst du dir ein Projekt mit dem OS und
allen Einstellungen als makefile oder MCUXpresso Projekt exportieren
lassen.
ohja, das mit openOCD sieht ja gut aus, aber unterstützt das auch den
LPC1549? Es ist bei mir zumindest keine conif file dabei....!? Wie muss
ich da vorgehen?
Meldet lsusb denn den Debugger Adapter?
Lpcxpresso lädt die Firmware beim Start, dann also erstmal den Debugger
mit lpcxpresso starten und dann den dfu_link Jumper umstecken damit der
erhalten bleibt. Danach müsste es mit dem Openocd gehen.
Hallo,
achso!! Ja, jetzt habe ich gerade eben zuerst mit LPCXpresso einmal
geflasht, danach das LPCXpresso beendet und dann geht es mit openOCD!
Allerdings nur solange, bis ich das Board einmal entferne. Wenn ich es
dann wieder anschließe leuchtet die LED D2 und es geht nicht mehr mit
openOCD. Erst wenn ich wieder einmal mit LPCXpresso flashe blinkt LED D2
und ich kann LPCXpresso beenden und mit openOCD loslegen. Wie kann ich
die Firmware ohne LPCXpresso laden? (Ich würde gerne auf LPCXpresso
verzichten und alles über die Kommandozeile machen).
Wie muss ich den Jumper "DFU" stecken, damit die Firmware erhalten
bleibt?
Danke für die Tipps!
Also mit dem LPC-Link2 habe ich das jetzt nicht hinbekommen :-(
Gäbe es eine andere Möglichkeit, vielleicht über den
"Target"-USB-Anschluss oder über UART zu programmieren?
From LPCXpresso IDE version 7.3x and later, we now supply a boot script
for all supported platforms. To make use of this script:
cd <install_dir>\lpcxpresso\bin and run
boot_link2
For version of LPCXpresso IDE earlier than version 7.3 - you will need
to locate the dfu-util utility and pass the parameters for the device
and code etc. as below:
cd <install_dir>\lpcxpresso\bin and run
dfu-util -d 1FC9:000C -c 0 -t 2048 -R -D LPC432x_Redlink_V4_30.bin.hdr
LPC432x_Redlink_V4_30.bin.hdr is the file name for the firmware supplied
in LPCXpresso IDE V 7.2.0
Note: The exact name of the .hdr file may change between different tools
releases, please ensure you use the name of the correct name
Doran S. schrieb:> Danke für die Tipps!
You're welcome. Schön das sich hier mal wieder jemand mit den LPC
beschäftigt, bei den Cortex-M haben die STM32 ja mittlerweile den
Hobbybereich erobert.
Aber gerade beim Thema flashen sind die LPC sehr unkompliziert.
Doran S. schrieb:> Gäbe es eine andere Möglichkeit,
ja, mehrere. Der LPC15xx hat einen eingebauten Bootloader im ROM der per
UART, CAN oder USB anzusprechen ist. Siehe dazu das user manual
(UM10736.pdf solltest du haben), Kapitel 5.
Um per USART zu programmieren brauchst du folgendes:
- FlashMagic software, gibts wohl nur als Windows Vesion, aber die läuft
auch unter Wine. Vermutlich gibt es da mittlerweile auch native Linux
Möglichkeiten, kennt hier jemand welche?
- Am Arduino Header D0/D1 sind ISP_RX/ISP_TX, hier den seriellen Adapter
anschliessen
- das Board über den USB Programmer Anschluss J5 versorgen. Das ist
wichtig weil die serielle Schnittstelle auch mit dem onboard programmer
verbunden ist und der dann per Multiplexer die Pins in Ruhe lässt. Der
Hinweis ist im Schaltplan zu finden.
- beide Buttons ISP_0 und ISP_1 gedrückt halten und Reset auslösen.
Damit startet der LPC im USART Bootloader und kann jetzt programmiert
werden.
Es geht aber noch viel einfacher über den USB Bootloader. Dazu ein USB
Kabel an J3 anschliessen, ISP_0 Button gedrückt halten und reset
auslösen. Damit startet der USB Bootloader und meldet ein MSD device an.
Das OS sollte also ein USB Laufwerk erkennen mit einer Datei
'firmware.bin'. Diese löschen und das neue bin file draufkopieren -
damit wird die automagisch in den Flash geschrieben und nach Reset
sollte das neue Programm starten.
den Schaltplan von dem Board kann man bei EA runterladen:
http://www.embeddedartists.com/products/lpcxpresso/lpc1549_xpr.php
Hallo,
das ist ja cool und sehr einfach über USB die bin Datei rüber zu ziehen.
Habe es so versucht: Beim Reset des Boards habe ich den Button "ISP0"
gedrückt und am PC erscheint das Device. Darin ist eine Datei
"firmware.bin", welche ich gelöscht habe und mit meiner neuen bin Datei
ersetzt habe. Auch der Kopiervorgang funktioniert. Leider scheint die
Datei aber nicht im Flash gelandet zu sein, denn nach einem Reset des
Boards (ohne den Button "ISP0" zu drücken), startet mein Programm leider
nicht :-( Was muss ich da beachten oder ändern?
Danke für Deine Unterstützung, darf ich fragen, wie Du Dich in diese
Materie eingearbeitet hast?
Viele Grüße,
Doran
wie hast du das bin erzeugt, mit der IDE? Dann sollte das laufen.
Wichtig ist nur das .bin zu kopieren, nicht hex oder elf oder sonstiges.
Und bei den LPC muss eine Prüfsumme eingebaut werden, das macht das tool
'checksum' das bei LPCXpresso dabei ist. Die IDE ruft das im build
Vorgang auf, ein damit erzeugtes .bin sollte also ok sein. Wenn es nicht
läuft kann eigentlich nur was im Programm faul sein. Wenn das Programm
in der IDE oder im Debug Build läuft mal auf nicht initialisierte
Variablen überprüfen. Oder den Release Buld als .bin flashen.
Bei den µCs habe ich mit AVR angefangen, dann kamen die ARM-TDMI mit
mehr Takt und Speicher, da war die Programmierung und das Flashen aber
noch viel unbequemer. Dann habe ich die erstmal beseite gelegt und dann
mit dem LPCXpresso und dem LPC1769 Board lief fast alles Plug 'n Play.
Habe viele der mitgelieferten Beispiele durchprobiert, incl. Ethernet
und FreeRTOS hat das gut funktioniert. Sehr wertvoll dabei war für mich
die Möglichkeit einfach und gut debuggen zu können. Die Eclipse IDE ist
zwar sehr gewöhnungsbedürftig, aber dafür kann damit alles Mögliche
machen.
Dann habe ich weitere LPC Boards gekauft und baue mir auch selber
(kleinere) Boards für die Heimautomatisierung und andere Projekte. Als
Softwarebasis nehme ich mbed weil ich damit schnell Projekte starten
kann, egal ob kleinen LPC812 oder fetten STM32F407.
Hallo,
ja, genau, ich habe das .bin mit der IDE erzeugt (und die IDE erzeugt
auch ein .axf, welches ich per LPC-Link2 über die IDE auch erfolgreich
flashen kann und dann funktioniert das Programm auch korrekt, aber nur
mit dem .axf, nicht mit dem .bin....).
Auch habe ich (bzw. das macht die IDE) mit dem Programm "checksum" eine
Prüfsumme in das .bin geschrieben.
Der LPC1549 meldet sich auch als "Laufwerk" am Rechner und ich kann das
.bin rüberziehen. Nur wird dann das Programm nicht ausgeführt.
Hast Du da vielleicht noch eine Idee, woran es liegen könnte?
Cool, mit den AVRs habe ich auch angefangen und bin dann zu STM32
übergegangen. Nur tue ich mir jetzt mit dem Umstieg auf LPC schwer...
Viele Grüße und Danke für die Hilfe,
Doran
Doran S. schrieb:> Umstieg auf LPC
Die ganzen LPC Tools sind nur unter Windows fehlerfrei. Wenn im
MCUxpresso unter Windows das Debuggen geht, muss das unter Linux nicht
so sein. Auch der USB Bootloader funktioniert unter Windows einwandfrei,
und macht unter Linux oft Probleme.
das scheint so zu sein wie Lothar schrieb, ich hatte dazu auch was
gelesen. Vielleicht ist hier eine Abhilfe bei:
https://community.nxp.com/thread/421354
Und in dieser AppNote am Ende vom 3.Kapitel steht ein mögliche Ursache:
https://www.nxp.com/docs/en/application-note/AN10986.pdf
Dann empfehle ich nochmal MCUXpresso zu benutzen, ist im Prinzip gleich
aber aktueller. Wurde unter neuem Namen fortgeführt weil NXP ja die
Kinetis gekauft hat und die ebenfalls in diese IDE übernommen wurden.
Doran S. schrieb:> Hast Du da vielleicht noch eine Idee, woran es liegen könnte?
Linux schrieb IIRC die firmware.bin nicht an die erwartete Stelle im
virtuellen Filesystem. Abhilfe war IIRC Firmware.bin überschreiben (z.B.
"dd of=firmware.bin") und nicht vorher löschen.
Habe nun viel ausprobiert und auch mit dd funktioniert es nicht über die
USB die Firmware zu flashen. Da ich das ganze als Hobby-Projekt mache um
Erfahrungen zu sammeln, würde ich jetzt gerne mal über UART flashen.
Dazu habe ich einen USB-to-UART Adapter. Dieser liefert allerdings doch
Signale mit 5V-Pegel? (Werde ich gleich mal messen). Wie soll ich diesen
UART-Adapter nun anschließen? Habe schon Schaltungen mit Zener-Dioden
gesehen, ist so etwas erforderlich?
Doran S. schrieb:> Dieser liefert allerdings doch> Signale mit 5V-Pegel?
kommt drauf an, ich habe billige China Dinger die per Jumper auf 3V3
umgestellt werden können.
Und diese MTools aus dem Link den ich genannt hatte funktionieren auch
nicht?
Doran S. schrieb:> Habe nun viel ausprobiert und auch mit dd funktioniert es nicht über die> USB die Firmware zu flashen.
Dann ist praktisch immer die Checksumme falsch. Probier mal das "lpcfix"
von der CCC R0ket:
https://github.com/r0ket/r0ket/tree/master/tools/bootloader
Das ist zwar für den LPC1343, aber IIRC war die Checksumme derselbe
Algorithmus.
Ach ja: Viele Debugger Tools, die über JTAG/SWD flashen, korrigieren die
Vector Table Checksumme automatisch. Dann bekommt man nicht gleich mit
dass die flasch ist.
hartnäckiger Fall, die checksum hat Doran ja schon über die IDE
bekommen. Ich habe es auch mal in Ubuntu probiert und bekomme die
gleichen Effekte.
Alternativ geht das mit dem mbed bootloader, der enthält CMSIS-DAP und
ein MSD. Dieses MSD ist aber nicht das aus dem ROM vom LPC1549 sondern
eben das vom zusätzlichen µC für den Debugger. Der Vorteil ist das der
solange da ist wie das USB Kabel steckt, die Fummelei mit den Buttons
zum Starten des Bootloaders entfällt damit.
Den Bootloader bekommt man hier als bin file:
https://os.mbed.com/teams/NXP/wiki/Updating-LPCXpresso-firmware
Da ist NXP Tool beschrieben, ich würde das aber per dfu_util probieren.
Das sollte beim LPCXpresso dabei sein oder extra installieren. Debuggen
geht damit auch noch, den CMSIS-DAP erkennt die IDE normalerweise auch.
Das Problem war mein Rechner! Wahrscheinlich habe ich mir durch
Basteleien den USB-Port irgendwie zerstört. Habe jetzt einen neuen
Recher und auch wieder Kubuntu installiert und mit den oben
vorgeschlagenen MTools funktioniert das Flashen über USB hervorragend!
Am alten Rechner hatte ich am Ende auch Probleme mit Maus und Tastatur
(hängen ja auch am USB) und bin so dem Problem auf die Schliche
gekommen. Merkwürdig nur, dass es mit der IDE noch funktioniert hat den
Mikrocontroller zu flashen.....
Danke für die Unterstützung und die vielen Vorschläge, das hat sehr
geholfen!
Viele Grüße,
Doran
Thread beobachten
Seitenaufteilung abschalten