lpc1115 programmieren

[Hendrik]

Zum Flashen und Debuggen geht auch der LPC-Link2 (andere Suchbegriffe: OM13054, EA-XPR-200). Kostenpunkt rund 25 Euro. Gibt's z.B. bei Embedded Artists oder Conrad.

[mff]

Wenn ich richtig verstehe ist das ebay-Teil also nur für denjenigen sinnvoll, der fertige Projekte nachbaut und nur flashen will. Für die Entwicklung bräuchte es was "dickeres" wie von Hendrik bereits aufgeführt.

[klayman]

long time no see... Ich bin leider noch immer nicht weiter (keine Zeit). In der Hoffnung etwas Zeit zu sparen habe ich nun dieses Ding erstanden. Ich hoffe dieses mal ist es das richtige!? Jetzt steh ich wieder vor der Frage der Pinbelegung. Laut Anleitung des Proggers müssen folgende 4 Leitungen verbunden werden:

Code: Alles auswählen

Progger     LPC
-------     ---
TXD     --> UART0-RXD P0[2]
BOOT    --> P2[10]
RESET   --> RESET
RXD     --> UART0-TXD P0[3]

Bin mal wieder total aufgeschmissen. Hätte ja eigentlich gedacht, dass ich an der SMD-Löterei scheitere, aber nicht an der Programmierung

Danke für Eure Hilfe!!
Klayman

[mariosk8s]

Hallo miteinander,

ich hatte nach langem Mal wieder Zeit mich da rein zu arbeiten. Inzwischen bin ich zu dem Schluss gekommen, dass der OM13087 komplett unbrauchbar dafür ist, irgend etwas anderes als das mit gelieferte Chip zu programmieren.

Wie vorher schon erwähnt hatte ich Erfolg mit der Raspi/openocd bit banger variante.
Jetzt habe ich nur folgenedes Problem.
Mein FT1.2 Adapter ist mit dem arm chip ausgestattet. Ich hatte auch Erfolg das blinky Beispiel vom LPCxpresso auf zu spielen. Es scheint geklappt zu haben weil die rote LED blinkt. Leider habe ich keinen Erfolg mit der raspi firmware, und hoffe deshalb auf den Einen oder Anderen Tipp diesbezüglich.

Openocd liefert mit folgendes wenn ich zu flashen versuche:

Code: Alles auswählen

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO nums: swclk = 25, swdio = 24
BCM2835 GPIO config: srst = 18
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
BCM2835 GPIO nums: swclk = 3, swdio = 2
BCM2835 GPIO config: srst = 4
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter_nsrst_assert_width: 100
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : SWD only mode enabled (specify tck, tms, tdi and tdo gpios to add JTAG mode)
Info : clock speed 10 kHz
Info : SWD DPIDR 0x0bb11477
Info : lpc11xx.cpu: hardware has 4 breakpoints, 2 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* lpc11xx.cpu        cortex_m   little lpc11xx.cpu        halted
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x1fff0040 msp: 0x10000ffc
flash 'lpc2000' found at 0x00000000
auto erase enabled
Warn : Verification will fail since checksum in image (0x0000870a) to be written to flash is different from calculated vector checksum (0x97d4a8f4).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 4096 bytes from file ft1_2-1.11.bin in 18.655394s (0.214 KiB/s)
Error: lpc11xx.cpu -- clearing lockup after double fault
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xa0000003 pc: 0xfffffffe msp: 0x322affe0
Polling target lpc11xx.cpu failed, trying to reexamine
Info : lpc11xx.cpu: hardware has 4 breakpoints, 2 watchpoints
shutdown command invoked

Ich nehme an Error: lpc11xx.cpu -- clearing lockup after double fault ist das Problem.

Mein openocd.conf:

Code: Alles auswählen

source [find interface/raspberrypi2-native.cfg]
transport select swd
bcm2835gpio_swd_nums 3 2
bcm2835gpio_srst_num 4
source [find target/lpc11xx.cfg]
adapter_nsrst_assert_width 100
init 
targets
reset halt
flash probe 0
flash write_image erase ft1_2-1-12.bin 0x00000000
reset
shutdown

Die ist identisch zu der blinky Variante ausser des images.
Das geflashte image ist von git:software/ft1_2/Releases/ft1_2-1-12.hex convertiert mit

Code: Alles auswählen

arm-none-eabi-objcopy -I ihex -O binary ft1_2-1-12.hex ft1_2-1-12.bin

Dann wollte ich es Mal mit der eigentlichen Software versuchen, bin aber unklar, wo die relevanted Sources für diese Release leben. software/ft1_2 scheint nur LPC922 zu machen, was die Probleme erklären würden.

Also ist das so, und wenn wo finde ich die Sources für die ARM variante vom dem Teil?

Danke im voraus.

[Doumanix]

Hi mariosk8s,

ich versuch mal alles grob zu beantworten:

1. der OM13087UL taugt dazu sehr wohl. Siehe: geraete-dev-f6/om13087ul-arm-lpc1115-programmieren-t495.html
   Außerdem gehts von da auch noch weiter zum Wiki, wo schon vor langer Zeit das JTAG MApping dokumentiert wurde.
2. Das was du geflasht hast, war ein HEX für den LPC922 (liegt unterm Repo "software"). Das kann auf dem ARM natürlich nicht tun. Aktueller FT1.2 ARM-Entwicklungszweig, welcher unter "software-arm-incubation" liegt: https://github.com/selfbus/software-arm ... /misc/ft12
3. So ganz selbsterklärend ist die Struktur im Git nicht, ok, aber man findet (wenige) fertige Releases unter software-releases. Unter anderem auch eine FT1.2 Version, die bei mir erfolgreich läuft (gut mit EIBD, weniger gut mit KNXD, siehe http://selfbus.myxwiki.org/xwiki/bin/vi ... 1.2%20HAT/
4. Selbst kompillieren: Kennst du das VBox Image, das ich im Wiki beschrieben habe? Wenn du das runter lädtst und zum laufen bekommst, hast du alles schon fertig in der Entwicklungsumgebung. Alle (Stand heute glaube ich immer noch alle, obwohl das Image ein Jahr fast alt ist ) Repositorys sind drin, müssten natürlich mal mit der aktuellen Version vom Git synchronisiert werden.

5. Leider habe ich keinen Erfolg mit der raspi firmware

   Das verstehe ich nicht. FT1.2 Firmware meinst du, oder? Dass es da seltsame Meldungen gibt, ist klar, siehe Punkt 2.

Grüße
Christian

[Marinux]

Hallo miteinander,

ich hatte nach langem Mal wieder Zeit mich da rein zu arbeiten. Inzwischen bin ich zu dem Schluss gekommen, dass der OM13087 komplett unbrauchbar dafür ist, irgend etwas anderes als das mit gelieferte Chip zu programmieren.

Wie Christian schon erwähnt und verlinkt hat, ist der OM13087 bestens dafür geeignet. Wie hast Du denn die Verbindung zwischen Selfbus-Platine und dem OM13087 versucht herzustellen?

Gruß

Marinux

[mariosk8s]

Vielen Dank, Christian

der OM13087UL taugt dazu sehr wohl. Siehe: geraete-dev-f6/om13087ul-arm-lpc1115-programmieren-t495.html
Außerdem gehts von da auch noch weiter zum Wiki, wo schon vor langer Zeit das JTAG MApping dokumentiert wurde.

Die Seite kannte ich noch nicht. Ich habe mich dabei nicht soll toll angestellt. Bord getrennt

Das was du geflasht hast, war ein HEX für den LPC922 (liegt unterm Repo "software"). Das kann auf dem ARM natürlich nicht tun. Aktueller FT1.2 ARM-Entwicklungszweig, welcher unter "software-arm-incubation" liegt: https://github.com/selfbus/software-arm ... /misc/ft12

Hab ich's mir doch gedacht.

So ganz selbsterklärend ist die Struktur im Git nicht, ok, aber man findet (wenige) fertige Releases unter software-releases.

software-releases hatte ich noch nicht ausgecheckt. Guter Punkt. Hab's gerade aufgespielt und openocd hat nicht gemault.

Unter anderem auch eine FT1.2 Version, die bei mir erfolgreich läuft (gut mit EIBD, weniger gut mit KNXD, siehe http://selfbus.myxwiki.org/xwiki/bin/vi ... 1.2%20HAT/

Ja, da wär ich jetzt als nächstes an die Wand gefahren, hatte nämlich knxd installiert.

Selbst kompillieren: Kennst du das VBox Image, das ich im Wiki beschrieben habe? Wenn du das runter lädtst und zum laufen bekommst, hast du alles schon fertig in der Entwicklungsumgebung. Alle (Stand heute glaube ich immer noch alle, obwohl das Image ein Jahr fast alt ist ) Repositorys sind drin, müssten natürlich mal mit der aktuellen Version vom Git synchronisiert werden.

Ah, die kannte ich auch noch nicht. Lädt gerade.

> Leider habe ich keinen Erfolg mit der raspi firmware
Das verstehe ich nicht. FT1.2 Firmware meinst du, oder?

Ja genau das.

[mariosk8s]

Wie hast Du denn die Verbindung zwischen Selfbus-Platine und dem OM13087 versucht herzustellen?

Erst löten, dann Schaltpläne anschauen

[Marinux]

Hi Mario,

dein OM13087 sieht ein bisschen vom Design her anders aus als mein OM13087UL. Vielleicht eine andere Revision?

Ist auf der Rückseite Deines Boards J3 zu sehen? Dann wirst Du direkt von dort SWD abgreifen können. Außerdem musst Du CMSIS-DAP aktivieren, bei meinem Board durch öffnen von JP3.

Gruß

Marinux

[mariosk8s]

Ne, J3 ist da um das Chip auf dem kleinen Board zu flashen.
Bei dem fing bei mir die Löterei an.
Das Problem ist das die 3.3V Stromversorgung für das kleine Bord auf dem großen ist.

Ich hab mir jetzt'n LPC Link2 bestellt.