Atmel SAME70 (Cortex-M7) unter linux ans Laufen bringen..

[Florian O. (simuru)]

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):

volatile int i=0;
volatile int cvar=15;
volatile int funky_variable = 123;

int fn(int v)
{
   return (v++);
}
int main(void)
{
   /* Initialize the system */
   sysclk_init();
   board_init();
   i = 0x2;
   i = 0x2;

   i = cvar;

   i = fn(cvar);

   funky_variable = fn(i);

   while (1) 
   {
   }
}

geflasht wird über gdb:

(gdb): mon flash write_bank 0 CHIPID_EXAMPLE1.bin 0
>> wrote 9352 bytes from file CHIPID_EXAMPLE1.bin to flash bank 0 at offset 0x00000000 in 0.349893s (26.102 KiB/s)

(gdb): mon reset halt
>> target halted due to debug-request, current mode: Thread                                                            >> xPSR: 0x01000000 pc: 0x00400f5c msp: 0x20402918

(gdb): load
>> Loading section .text, size 0x1c3c lma 0x400000
>> Loading section .relocate, size 0x84c lma 0x401c3c
>> Start address 0x400f5c, load size 9352
>> Transfer rate: 5 KB/sec, 4676 bytes/write.

(gdb): break chipid_example.c:403
>> Breakpoint 1 at 0x40129c: file ../src/chipid_example.c, line 403.

(gdb): continue
>> 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

i, cvar und funky_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:

│(gdb) s
│406        i = cvar;
│(gdb) p i
│$41 = 0
│(gdb) s
│408        i = fn(cvar);
│(gdb) s
│fn (v=541075696) at ../src/chipid_example.c:396
│396        return (v++);
│(gdb) p v
│$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.

(

$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.

[Dennis R. (dennis_r93)]

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.

[Florian O. (simuru)]

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:

(gdb) mon flash verify_bank 0 CHIPID_EXAMPLE1.bin 0
read 9352 bytes from file CHIPID_EXAMPLE1.bin and flash bank 0 at offset 0x00000000 in 0.140940s (64.799 KiB/s)
contents match

Im Listing steht (CHIPD_EXAMPLE1.lss):

   i = 0x2;
  40129c:  4b0f        ldr  r3, [pc, #60]  ; (4012dc <main+0x4c>)
  40129e:  2202        movs  r2, #2
  4012a0:  601a        str  r2, [r3, #0]
   i = 0x2;
  4012a2:  4b0e        ldr  r3, [pc, #56]  ; (4012dc <main+0x4c>)
  4012a4:  2202        movs  r2, #2
  4012a6:  601a        str  r2, [r3, #0]

   i = cvar;
  4012a8:  4b0d        ldr  r3, [pc, #52]  ; (4012e0 <main+0x50>)
  4012aa:  681b        ldr  r3, [r3, #0]
  4012ac:  4a0b        ldr  r2, [pc, #44]  ; (4012dc <main+0x4c>)
  4012ae:  6013        str  r3, [r2, #0]

   i = fn(cvar);
  4012b0:  4b0b        ldr  r3, [pc, #44]  ; (4012e0 <main+0x50>)
  4012b2:  681b        ldr  r3, [r3, #0]
  4012b4:  4618        mov  r0, r3
  4012b6:  4b0b        ldr  r3, [pc, #44]  ; (4012e4 <main+0x54>)
  4012b8:  4798        blx  r3
  4012ba:  4602        mov  r2, r0
  4012bc:  4b07        ldr  r3, [pc, #28]  ; (4012dc <main+0x4c>)
  4012be:  601a        str  r2, [r3, #0]

Als Assembler unwissender muss ich gleich kurz ein wenig lesen um zu 
verifizieren, dass das passt ;)

[Markus F. (mfro)]

Das Ding hat einen Data-Cache (in den die CPU - hoffentlich - auch brav 
reinschreibt).

Probier' mal mit "Cache aus".

[Florian O. (simuru)]

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

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!

[NoName (Gast)]

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.

[Florian O. (Gast)]

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

"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.

[NoName (Gast)]

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.

[Florian O. (Gast)]

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?

[NoName (Gast)]

Das hängt nicht von EDU oder nicht EDU ab sondern von der Hardware 
Revision. Ab V9 wird Cortex-M7 unterstützt. Welche HW-Rev. hast du denn?

[Florian O. (Gast)]

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