Forum: Mikrocontroller und Digitale Elektronik Fehlerhaftes debuggen in Eclipse für LPC2378


von Steffen H. (mcst)


Lesenswert?

Hallo
Ich habe ein Problem mit dem Debugger bei Eclipse und hoffe ihr könnt 
mir helfen!

Der Reihe nach: Ich will mein Programm auf dem Entwicklungsboard 
LPC-2378-STK-A von Olimex debuggen und nutze hierfür einen 
USB-JTAG-Adapter (ARM-USB-TINY; ebenfalls Olimex). Dieser ist über 
OpenOCD im Eclipse eingebunden. Unter Debuge-Configurations nutze ich 
„Zylin Embedded Debuger (Native)“ mit GUNRAM arm-elf-gdb.exe
Bei den Run-Commands habe ich
1
target remote localhost:3333
2
monitor reset
3
monitor sleep 500
4
monitor poll
5
monitor soft_reset_halt
6
monitor arm7_9 force_hw_bkpts enable
7
monitor flash erase_sector 0 0 0
8
monitor flash write_image Debug\\test1.hex 0x0
9
break main
10
load
11
continue
eingetragen, Initialize Commands habe ich keine.

Nun zum eigentlichen Problem:
Nur jeder zweite Start des Debuggers funktioniert. Läuft der Debugger 
mal, so kann ich schön sehen wie Variablen verändert werden aber wenn 
ich Registerinhalte ändere um z.B. einen digitalen Eingang zu aktivieren 
um eine LED zum Blinken zu bringen passiert nix. Ich sehe zwar wie sich 
die angezeigten Registerplätze ändern aber am Board tut sich nichts.

Hier mal das Listung für einen positiven Start des Debugers:
1
mi_cmd_break_watch: Missing <expression>
2
No registers.
3
target remote localhost:3333
4
0x7fffe154 in ?? ()
5
monitor reset
6
JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
7
monitor sleep 500
8
monitor poll
9
target state: halted
10
target halted in Thumb state due to debug request, current mode: Supervisor
11
cpsr: 0xa00000f3 pc: 0x7fffe156
12
monitor soft_reset_halt
13
requesting target halt and executing a soft reset
14
monitor arm7_9 force_hw_bkpts enable
15
force hardware breakpoints enabled
16
monitor flash erase_sector 0 0 0
17
erased sectors 0 through 0 on flash bank 0 in 0.578125s
18
monitor flash write_image Debug\\test1.hex 0x0
19
wrote 2568 byte from file Debug\\test1.hex in 1.718750s (1.459091 kb/s)
20
Breakpoint 10 at 0x41c: file ../main.c, line 30.
21
break main
22
load
23
Loading section .text, size 0xa08 lma 0x0
24
Start address 0x0, load size 2568
25
Transfer rate: 1 KB/sec, 2568 bytes/write.
26
continue
27
Note: automatically using hardware breakpoints for read-only addresses.
28
29
Breakpoint 1, main () at ../main.c:30
30
30    long    j = 0;
Wo liegt mein Fehler und was muss ich ändern damit ich das Problem 
beseitige?
Über jede Hilfe freu ich mich, mir sind mittlerweile die Ideen 
ausgegangen.

Steffen

von Philipp (Gast)


Lesenswert?

Lieber Steffan,

hast du schon eine Lösung für das Problem gefunden??

Wenn ich den chip debuggen will, funktioniert es bei mir nur ca. jedes 
zweite mal. Wenn es funktioniert, kann ich alle variablen werte sehen, 
auch die Pins am µC toggeln.
wenn ich das ganze jetzt nochmal debuggen will, steht der program 
counter bei einer Adresse um ca. 0x7FFF E152. So wie auch bei dir:

>target remote localhost:3333
>0x7fffe154 in ?? ()
>monitor reset

Bei 0x7FFF E008 liegt der Bootloader...

Nun gibt es den Pin P2.10. Ist dieser Pin auf Lo, so sollte der Chip in 
den ISP mode gehen. Ist der Pin Hi, sollt der Chip nur in den ISP mode 
gehen, wenn die checksumme nicht übereinstimmt (der user Code nicht 
valid ist).

Wenn ich den Pin P2.10 auf 0V ziehe, funktioniert es jedesmal.
Allerdings ist dann der ISP mode aktiv. Folglich sollte das debuggen ja 
eigentlich nicht funktionieren...

wenn ich den µC flashe muss der Pin P2.10 auf Hi sein. In diesem Fall 
funktioniert es ca. bei jedem 2. mal flashen.
wenn es nicht funktioniert, hängt der program counter bei ca. 0x7FFF 
E156.

Hat jemand einen möglichen Lösungsvorschlag?
Hatte noch jemand außer uns das selbe Problem?

LG,
Philipp

von Steffen H. (mcst)


Lesenswert?

Hi Philipp,

das Problem was ich hatte war:
Beim ersten Durchlauf war es nich möglich den µC aus Eclipse heraus zu 
flashen, da dieser in einem Modus sich befand in dem er keinen Zugriff 
auf den Speicher erlaubte. ->Fehlermeldung danach wechselt der µC 
komischerweise den Modus...
Debuggen war möglich aber der Code ja nich auf dem Controller
Beim zweiten Durchlauf ging dann immer das flashen aber debuggen war 
nich mehr drin :-C

vll. trifft die Beschreibung auch bei dir zu und hilft dir weiter.

Da ich nicht unendlich Zeit hatte, hab ich das Problem (meiner Meinung 
nach sehr unelegant) umgangen:
Ich übersetze meinen Code wie gewohnt im Eclipse in ein .hex und brenn 
diesen über FlashMagic in den LPC2378

Beim Debuggen ruf ich Zylin mit folgender Ini. auf:
1
target remote localhost:3333
2
monitor reset
3
monitor sleep 500
4
monitor poll
5
monitor soft_reset_halt
6
monitor arm7_9 sw_bkpts disable
7
monitor arm7_9 force_hw_bkpts enable
8
monitor mww 0xE01FC040 0x01
9
monitor mdw 0xE01FC040
10
break main.c:97
11
load
12
continue
PC steht durch Reset an stelle Null im Speicher;
Das "breake" Kommando setzt dabei einen Hardware-Breakpoint an der 
Stelle:
 File:Zeile
load und continue bewerkstelligen das der Controller los läuft und du 
was siehst.

Das funktioniert bei mir super und es sind auch keine Probleme wieder 
aufgetreten. Ich kann alles im Speicher beobachten :-)

Das mit dem Pin hat bei mir nich viel gebracht und mich eigentlich sogar 
noch mehr verwirrt.

Hoff echt das hilft dir weiter! Ich selbst hab ewig gebraucht um das 
hinzubekomm.

LG Steffen

Bitte 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
Noch kein Account? Hier anmelden.