LPC2138 führt Programm nicht aus - ratlos.

[Tobias S. (Firma: none) (tobimc)]

Hi,

ich doktere jetzt schon eine ganze Weile an meinem LPC2138-Design herum.
Ich habe es nach längerem Hin und Her geschafft, eine JTAG-Verbindung 
mittels openOCD (0.5.0-dev cygwin-compile aus den git-sourcen) und dem 
BusPirate herzustellen.
Das funktioniert auch ganz wunderbar, openOCD hat weder an der scan 
chain noch am target / tap etwas zu meckern. Das (Hardware-) Design ist 
sehr an ein Olimex-board (Schaltplan: 
http://www.olimex.com/dev/pdf/ARM/LPC/LPC-MT-2138%20-%20schematic.pdf ) 
angelehnt, ich verwende allerdings einen 20MHz Quarz; der auch mit 20MHz 
schwingt, wie ich gemessen habe. RTCK ist mit 4,7k auf GND gezogen, um 
den Chip in den Debug-Mode zu verfrachten, wie das im Manual empfohlen 
wird. P0.14 liegt per 4,7k gegen VCC. Wie gesagt; Jtag scheint soweit zu 
funktionieren.

Ich habe ein einfaches Programm geschrieben, dass 2 Pins (P0.31 und 
P1.24) als Output konfigurieren, und toggeln soll (Zählschleife als 
Pause).
Ich verwende Startupcode und Linkerscript aus einem Beispiel von Martin 
Thomas, beides ist in der angehängten ZIP enthalten. Dass es daran 
liegt, glaube ich allerdings nicht, da der Compile einerseits ohne 
Fehler ausgeht, und andererseits das mapfile (map.txt) - so wie sich das 
mir erschließt - ganz OK aussieht...
(Ich habe sämtliche Files (auch das openOCD-cfg-file) als zip angehängt)
Ich verwende die GNUARM-Commpiler von YAGARTO; vom 18.3. eine 
arm-none-eabi Version (schluckt aber alle Files ohne Mucken). (Ich 
verwende als Build-Umgebung Code::Blocks; daher kein Makefile.

Build output:

-------------- Clean: default in test1 ---------------

Cleaned "test1 - default"

-------------- Build: default in test1 ---------------

Compiling: src\Startup.S
ROM_MODE enabled
remapping enabled
Vectors at start of RAM
Vectors in section .vectmapped -> .data
MEMMAP to 2 on init
Handlers in section .vectmapped -> .data
Compiling: src\swi_handler.S
SWI-Handler in section .vectmapped -> .data
Compiling: src\main.c
Linking console executable: default\test1.elf
Output size is 75.89 KB
Running project post-build steps
arm-elf-size -A default\test1.elf
default\test1.elf  :
section            size         addr
.text               540            0
.data               360   1073741824
.stack            11408   1073742192
.ARM.attributes      44            0
.comment             17            0
Total             12369
arm-elf-objcopy -j .text -j .data -O ihex default\test1.elf test1.hex
arm-elf-size -A test1.hex
test1.hex  :
section   size   addr
.sec1    900      0
Total    900
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

Wie gesagt; ich denke nicht, dass es daran liegt. Ausser es ist ein 
Problem mit dem Remapping...?

Was mir mehr Gedanken macht ist folgendes: Wenn ich per openOCD flashen 
will passiert folgendes:

Open On-Chip Debugger
> reset halt
JTAG tap: lpc2138.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
> flash write_image erase d:\\test1.hex 0x0
auto erase enabled
Verification will fail since checksum in image (0xe1a00000) to be written to flash is different from calculated vector checksum (0xcc3ffffa).
To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 4096 bytes from file d:\test1.hex in 2.502000s (1.599 KiB/s)
>

Soweit so gut. Ich habe im Netz gelesen, dass openOCD die richtige 
Checksumme einsetzt. (Wenn ich ohne erase nur das Image schreibe; 
schreibt openOCD nur die auch in der size-ausgabe besagten 900 Byte.)

Wenn ich das Image verifizieren möchte passiert das:

> verify_image d:\\test1.hex
checksum mismatch - attempting binary compare
diff 0 address 0x00000000. Was 0x34 instead of 0x06
diff 1 address 0x00000001. Was 0x40 instead of 0x00
diff 2 address 0x00000002. Was 0x9f instead of 0x00
diff 3 address 0x00000003. Was 0xe5 instead of 0xea
diff 4 address 0x00000004. Was 0x02 instead of 0x00
diff 5 address 0x00000005. Was 0x50 instead of 0x00
diff 6 address 0x00000007. Was 0xe3 instead of 0xe1
diff 7 address 0x00000009. Was 0x50 instead of 0x00
diff 8 address 0x0000000a. Was 0x84 instead of 0xa0
diff 9 address 0x0000000b. Was 0xe5 instead of 0xe1
diff 10 address 0x0000000c. Was 0x03 instead of 0x00
diff 11 address 0x0000000d. Was 0x50 instead of 0x00
diff 12 address 0x0000000f. Was 0xe3 instead of 0xe1
diff 13 address 0x00000010. Was 0x04 instead of 0x00
diff 14 address 0x00000011. Was 0x50 instead of 0x00
diff 15 address 0x00000012. Was 0x84 instead of 0xa0
diff 16 address 0x00000013. Was 0xe5 instead of 0xe1
diff 17 address 0x00000014. Was 0x1c instead of 0x00
diff 18 address 0x00000015. Was 0x20 instead of 0x00
diff 19 address 0x00000016. Was 0x9f instead of 0xa0
diff 20 address 0x00000017. Was 0xe5 instead of 0xe1
diff 21 address 0x00000019. Was 0x30 instead of 0x00
diff 22 address 0x0000001b. Was 0xe3 instead of 0xe1
diff 23 address 0x0000001c. Was 0x93 instead of 0x00
diff 24 address 0x0000001e. Was 0x02 instead of 0xa0
diff 25 address 0x00000020. Was 0x28 instead of 0x34
diff 26 address 0x00000021. Was 0x20 instead of 0x01
diff 27 address 0x00000022. Was 0x82 instead of 0x9f
diff 28 address 0x00000023. Was 0xe2 instead of 0xe5
diff 29 address 0x00000024. Was 0x93 instead of 0x00
diff 30 address 0x00000026. Was 0x02 instead of 0xa0
diff 31 address 0x00000027. Was 0xe1 instead of 0xe3
diff 32 address 0x00000028. Was 0x07 instead of 0x00
diff 33 address 0x00000029. Was 0x30 instead of 0x10
diff 34 address 0x0000002a. Was 0xc0 instead of 0x80
diff 35 address 0x0000002b. Was 0xe3 instead of 0xe5
diff 36 address 0x0000002c. Was 0x28 instead of 0x2c
diff 37 address 0x0000002d. Was 0x30 instead of 0x01
diff 38 address 0x0000002e. Was 0x02 instead of 0x9f
diff 39 address 0x00000030. Was 0x04 instead of 0xaa
diff 40 address 0x00000031. Was 0xf0 instead of 0x10
diff 41 address 0x00000032. Was 0x1f instead of 0xa0
diff 42 address 0x00000033. Was 0xe5 instead of 0xe3
diff 43 address 0x00000034. Was 0xc4 instead of 0x55
diff 44 address 0x00000035. Was 0xd1 instead of 0x20
diff 45 address 0x00000036. Was 0xff instead of 0xa0
diff 46 address 0x00000037. Was 0x7f instead of 0xe3
diff 47 address 0x00000038. Was 0x14 instead of 0x24
diff 48 address 0x00000039. Was 0xc0 instead of 0x30
diff 49 address 0x0000003a. Was 0x02 instead of 0xa0
diff 50 address 0x0000003b. Was 0xe0 instead of 0xe3
diff 51 address 0x0000003c. Was 0x00 instead of 0x04
diff 52 address 0x0000003d. Was 0xc0 instead of 0x30
diff 53 address 0x0000003e. Was 0x1f instead of 0x80
diff 54 address 0x0000003f. Was 0xe0 instead of 0xe5
No more differences found.
in procedure 'verify_image'
>

Es sind übrigens immer genau 54 Diffs.
(Das verify_ image fehlschlägt kann evtl. doch am Remapping liegen?)

Sage ich jetzt 'resume' passiert garnichts; es ändern sich keine Pegel, 
an beiden Pins liegen nur 2V an (was im halt-state auch so war).

Ich bin sicher ich hab irgendwas übersehen, nur leider bin ich etwas mit 
meinem Latein am Ende.
Jemand eine Idee, woran das liegen könnte?

Danke schonmal vorweg,
Tobi

[Tobias S. (Firma: none) (tobimc)]

Hi,

um Fehler in openOCD / GNUARM auszuschließen, habe ich die aktuelle 
Version des Keil ARM development kits heruntergeladen, und in µVision 
ein Projekt mit dem LPC2138 begonnen, und eine main.c erstellt und zum 
Projekt hinzugefügt.

(Siehe Anhang)

Alles compiliert ohne Errors und Warnings.

Dann habe ich zum einen per FlashMagic und zum anderen per 
LPC210x_ISP.exe (mit denen ich im Übrigen die Device-ID und 
Bootloader-Version problemlos auslesen kann) versucht das hexfile zu 
flashen, was problemlos funktioniert (und auch verifiziert; 
Vector-Checksum habe ich mit LPC210x_ISP generiert).

Problem: Nichts tut sich; alle GPIOs sind High-Z bei etwa 2V.

Frage:
- Bin ich vollkommen verrückt?
- Ist der Chip defekt?
- Sind böse Mächte am Werk?
- Mag mich mein Chip nicht?

Sonstiges:
- Oszillator schwingt mit 20MHz, Flashen mit ISP beweist dass Chip 
Spannung und Takt hat
- P0.14 liegt mit 4k7 nach VCC
- RST mit 10k nach VCC

Bin jetzt echt ratlos. Keiner eine Idee?

[Kai F. (k-ozz)]

Du willst die Pins P0.31 und P1.24 toggeln. Hast du da noch etwas 
angeschlossen? LEDs? Wie sieht die Schaltung speziell an P0.31 aus?

[Tobias S. (Firma: none) (tobimc)]

Hi,

Habe das Problem gerade mit Hilfe der LPC2000-Mailinglist gelöst:
http://www.embeddedrelated.com/groups/lpc2000/show/52173.php
und
http://tech.groups.yahoo.com/group/lpc2000/message/53467?var=1&l=1

Letztenendes lag es an einer kalten Lötstelle (!) an P0.14.
Da muss man erstmal draufkommen.

Danke für deine Hilfe!