Ein schönen Sonntag euch allen.
Ich versuche nun seit längerem mein Atmel Xplained Eval-Board mit dem
SAME70Q21 unter Linux ans laufen zu bringen. Erste Versuche mit den
GNU-ARM-Eclipse Plugins scheiterten gnadenlos. Deswegen Versuche ich es
im Moment manuell. Und habe nun mir unerklärliches Verhalten beobachten
können. Wenn ich über gdb den Wert einer Variable auslese ist es immer
der Initialisierungswert und ändert sich nie.
Rahmenbedingunen:
HW: JLink V8 (Alte EDU Version)
OpenOCD: 0.10.00 (aktuelles release)
GCC: gcc-arm-none-eabi-4.9 in der 2015 q3 Version
Ich habe ein Atmel Studio 7.0 Projekt genomment (CHIPID_EXAMPLE) und das
Makefile angepasst, dass es unter Linux kompiliert -- also nur Pfade
angepasst und es lief. Ich benutze also das Linker Script von Atmel und
auch die entsprechenden Startup und Syscall Routinen/Dateien.
Das ganze kompiliert ordentlich ohne Fehler durch. Ich starte OpenOCD
eine Telnet Sessiond und gdb.
Meine Main (chipid_example.c) sieht nun so aus: (habe viel gelöscht um
ein minimal-projekt zu haben):
>> Breakpoint 1 at 0x40129c: file ../src/chipid_example.c, line 403.
15
16
(gdb): continue
17
>> Breakpoint 1, main () at ../src/chipid_example.c:403
Der Breakpoint in Zeile 403 entspricht der ersten i = 0x2; Anweisung
nach board_init(); Von diesem Zeitpunkt an kann ich im single-step
Verfahren durch mein Programm gehen und mir die Werte von
1
i,cvarundfunky_variable
anschauen.
Dabei würde ich erwarten, dass sich die Werte ändern, aber sie bleiben
immer bei ihrer Initialisierung sprich:
i = 0,
cvar = 15,
funky_variable = 123
Die Zuweisungen scheinen nichts zu machen. Wenn ich im single-step bis
in die Funktion fn() gehe ich mir dort die lokale variable v ausgeben
lasse, hat diese den un-initialisierten Wert von 541075....
Hier noch ein Auszug:
1
│(gdb) s
2
│406 i = cvar;
3
│(gdb) p i
4
│$41 = 0
5
│(gdb) s
6
│408 i = fn(cvar);
7
│(gdb) s
8
│fn (v=541075696) at ../src/chipid_example.c:396
9
│396 return (v++);
10
│(gdb) p v
11
│$42 = 541075696 │(gdb)
Wenn ich nun über Telnet den Speicherbereich von i beschreibe und mir
dann über gdb i ausgeben lasse hat i den Wert den ich vorher zugewiesen
habe.
(
1
$43 = (volatile int *) 0x204008dc <i>
)
Telnet: mww 0x204008DC 0x09 1
Deswegen vermute ich, dass mein Debugger-Setup (OpenOCD config etc)
passt aber ich habe keine Ahnung was da sonst schief laufen könnte.
Kann mir jemand ein Tipp geben?
braucht ihr noch mehr Infos?
Ein schönen Sonntag an alle und schonmal danke fürs Lesen.
Hast du mal den Inhalt vom Flash zurückgelesen und verglichen?
Ich kann mir vorstellen, dass der Flashvorgang nicht korrekt ablief.
Dass der richtige Code angezeigt wird könnte daran liegen, dass der gdb
den Code zwischenspeichert.
Hast du dir mal das Disassembly angeschaut und den Registerinhalt?
Mache das mal und steppe dabei nicht durch den C-Code sondern durch die
Assembler Befehle.
Das ist aber alles nur geraten.
Dennis R. schrieb:> Hast du mal den Inhalt vom Flash zurückgelesen und verglichen?> Ich kann mir vorstellen, dass der Flashvorgang nicht korrekt ablief.
Wenn ich ein flash verify mache sagt er, dass alles korrekt ist:
Markus F. schrieb:> Das Ding hat einen Data-Cache (in den die CPU - hoffentlich - auch brav> reinschreibt).
Gelesen hatte ich das schon nur gedanklich völlig aussen vor gelassen,
in der dummen Annahme, dass die Daten die ich über SWD lese eben nicht
ge-cached werden.
mit
1
SCB_DisableDCache();
funktioniert es auch..
Jetzt habe ich wenigstens eine funktionierende Referenz und weiß dass es
ansich läuft und kann mit Eclipse weiter schauen.
Vielen Dank euch beiden!
Ich habe das gleiche unter Linux gemacht, allerdings mit Embedded
Studio:
https://www.segger.com/embedded-studio.html
Das hat sofort funktioniert. Wenn du eh schon einen SEGGER J-Link hast
wäre das vielleicht auch eine Alternative für dich.
Hey NoName,
daran hatte ich auch schon gedacht, aber ich befürchte das wird mit
meinem alten JLink nicht gehen.
Das Embedded Studio bietet zwar in der kostenfreien Version Support für
meinen M7 an, aber der JLink nicht. Beim Atmel Studio und den JLink
Tools unter Windows kommt dann die schöne Meldung
1
"Device not supported."
.
Daher glaube ich nicht, dass es damit klappt und möchte deswegen
generell vom Atmel Studio, Windows, und den Segger JTools weg.
Unter Linux setze ich für die meisten Sachen die IDE von QT (QTCreator)
ein, scheue mich aber noch vor dem Konfigurationsaufwand und hielt
bisher Eclipse für eine sinnvolle Alternative - mal schauen wie sich das
noch entwickelt.
Florian O. schrieb:> Das Embedded Studio bietet zwar in der kostenfreien Version Support für> meinen M7 an, aber der JLink nicht. Beim Atmel Studio und den JLink> Tools unter Windows kommt dann die schöne Meldung"Device not supported."
Die Meldung kommt aber dann von AtmelStudio und nicht vom J-Link. Der
J-Link EDU wird auch den Cortex-M7 unterstützen.
Daher gibt es keinen Grund die Segger Tools nicht einzusetzen.
Florian O. schrieb:> Unter Linux setze ich für die meisten Sachen die IDE von QT (QTCreator)> ein, scheue mich aber noch vor dem Konfigurationsaufwand und hielt> bisher Eclipse für eine sinnvolle Alternative - mal schauen wie sich das> noch entwickelt.
Aber ok, man kann sich das Leben auch schwer machen ;-).
Wenn ich mein Auto reparieren will baue ich auch erst mal Gießerei, um
meine Werkzeuge selber herzustellen.
NoName schrieb:> Die Meldung kommt aber dann von AtmelStudio und nicht vom J-Link. Der> J-Link EDU wird auch den Cortex-M7 unterstützen.> Daher gibt es keinen Grund die Segger Tools nicht einzusetzen.
Richtig.
Aber laut:
https://www.segger.com/admin/uploads/productDocs/UM08001_JLink.pdf
Seite 34, unterstützt der JLink EDU in der HW-Rev. 8.0 den Cortex-M7
nicht mehr. Das es doch geht, sehe ich ja mit OpenOCD - aber ich warum
sollte Seggers IDE das weiter unterstützen und Atmel nicht?
Florian O. schrieb:> *snip*> Rahmenbedingunen:> HW: JLink V8 (Alte EDU Version)> *snip*Florian O. schrieb:> snip unterstützt der JLink EDU in der HW-Rev. 8.0 den Cortex-M7> nicht mehr *snip*
Rev. 8 ;) mit der aktuellsten firmware die es für diese Version noch gab
- im kopf hab ich sie grad nicht. aber sollte auch keine rolle spielen