Hi all

 

letzter Stand Source Code master-brick aus git, Firmware rekompiliert, Länge des binaries divergiert ganz leicht (40 Bytes), Neue Firmware läuft an, bleibt aber in der Funktion uid_get_uid64() in uid.c auf Zeile 15:

 

EFC->EEFC_FCR = (0x5A << 24) | EFC_FCMD_STUI;

 

hängen. Getestet mit Code, welcher die rote LED (bei Start gesetzt) nach/vor dieser Zeile wieder löscht.

 

brick_master_firmware_latest.bin flasht und läuft ohne Probleme.

 

Übersehe ich da etwas Offensichtliches?

 

TIA, Werner

Welchen Compiler, welche Version und welche Optimierungen verwendest du?

Diverse Toolchains ausprobiert, generell dasselbe Problem. Mich erstaunt, dass der Code so empfindlich reagiert :-(

 

master-brick frisch von der Presse aus git, keine Änderungen an den gcc Optionen

 

CodeSourcery Toolchain macht dieselben Probleme momentan wie

 

TIA, Werner

 

binutils-2.22

gcc version 4.7.0

newlib-1.20

 

arm-none-eabi-gcc -v

Using built-in specs.

COLLECT_GCC=arm-none-eabi-gcc

COLLECT_LTO_WRAPPER=/usr/local/arm-none-eabi/libexec/gcc/arm-none-eabi/4.7.0/lto-wrapper

Target: arm-none-eabi

Configured with:

../configure

--target=arm-none-eabi

--prefix=/usr/local/arm-none-eabi

--build=i686-apple-darwin11

--host=i686-apple-darwin11

--with-gnu-as

--with-gnu-ld

--with-newlib

--enable-extra-sgxxlite-multilibs

--enable-lto

--enable-poison-system-directories

--enable-threads=single

--enable-languages=c,c++

--disable-decimal-float

--disable-libffi

--disable-libquadmath

--disable-libssp

--disable-libgomp

--disable-shared

--disable-libmudflap

--disable-libstdcxx-pch

--disable-nls

--disable-libitm

--disable-libatomic

--with-gmp=/usr/local

--with-mpfr=/usr/local

--with-mpc=/usr/local

--without-headers

Thread model: single

gcc version 4.7.0 (GCC)

 

Ich benutze hier im Moment arm-none-eabi-gcc version 4.6.3.

 

Dein Problem kann ich mir um ehrlich zu sein nicht erklären, die Stelle dort tut ja nichts böses, warum sollte da der Mikrocontroller stecken bleiben?

 

Das erste was ich probieren würde ist an den Optimierungen rumzuspielen. Wenn du eine Optimierungsoption findest die funktioniert wäre es natürlich toll wenn wir herausfinden könnten wo sich der generierte Assembler Code unterscheidet an der Stelle um evtl einen GCC Bugreport zu machen und fürs erste einen Workaround zu finden damit nicht der kaputte Code erzeugt wird.

 

Alternativ liegt die Problematik an etwas ganz anderem .

Hmm, habe mit den Compiler Optimierungen rumgespielt, binaries zwischen

55k bis 83k, alle zeigen denselben Effekt, scheint etwas systematisches und nicht Compiler-technisches zu sein. Das disassembly des .elf zeigt relativ vieles aus dem Code sauber strukturiert und dargestellt. Mir fehlt jedoch ein .elf der brick_master_firmware_latest.bin.

 

Ich wäre froh um ein laufendes Paar (.bin & .elf) der brick_master_firmware_latest, dann wäre ein Codevergleich wesentlich einfacher.

 

TIA, Werner

Ich hab mal die Master Brick und Bricklib repos neu ausgecheckt und gebaut, bei mir werden die .bin und .elf im Anhang erzeugt.

Edit: Veraltete Firmware entfernt.

 

 

Arg, ich hab Firmwares aus dem falschen Ordner hochgeladen. Die aktuelle git Version ist im diesem Anhang !

Edit: Veraltete Firmware entfernt.

 

 

Hah, da haben wir doch mit Sicherheit ein 16 <-> 32bit Problem. Wie habe ich das in die Toolchain eingeschleppt?

 

borg-master-brick.dis:

 

20000924 <__malloc_trim_threshold>:

20000924: 0000 0002                                  ....

 

20000928 <lc_ctype_charset>:

20000928: 5341 4943 0049 0000 0000 0000 0000 0000

 

 

my-master-brick.dis

 

20000c6c <__malloc_trim_threshold>:

20000c6c: 00020000                                ....

 

20000c70 <lc_ctype_charset>:

20000c70: 49435341 00000049 00000000 00000000

 

Immerhin eine Erklärung für das Hängen, damit geht der 'unverdächtige' Zugriff wohl daneben.

 

Thxs, Werner

Übrigens, deine Firmwares laufen beide :-)

 

Thxs

Also innerhalb eines 32 bit blocks sind bei dir jeweils 16 bit vertauscht?

 

Wenn dein Compiler aus aus irgendwelchen Gründen das ganze als Big Endian kompilieren würde, wären ja eigentlich jeweils 8 bit Blöcke vertauscht.

 

Wenn man jetzt wüsste wie man diese Art von Endian nennt könnte man bestimmt einen Compilerparameter dafür finden um es abzuändern .

Problem gelöst, ich habe mittlerweilen mit crosstool-ng-1.16.0 die Toolchain auf dem Mac (OSX 10.7.5) hin bekommen, der generierte Code läuft nun auf den Bricks. Ich hänge die .config hier an, vielleicht kann sie jemand verwenden.

 

Enjoy, Werner

tinkerforgeM3.config

Oh, was hast du denn genau getan um das Problem zu beheben? Gab es da eine spezifische Konfiguration?

Zentral ist die Wahl für den CORTEX_M3, dazu ist zu sagen, dass ich die Toolchain nur mit gcc 4.7.1 und newlib 1.19 hingekriegt habe. gcc 4.6 und newlib 1.17 produziert zwar Code, der auf dem Brick soweit anläuft, dass er die Blinkerei mit den LED's noch hinkriegt, die Kommunikation über RS-485 ist dann aber tot. Ich habe das nicht weiter untersucht weil ich keine schlaue Debug Möglichkeit habe. So nebenbei, debuggt ihr mit dem Debug Brick mit dem JTAG Interface wenn neuer Code entwickelt wird?

So nebenbei, debuggt ihr mit dem Debug Brick mit dem JTAG Interface wenn neuer Code entwickelt wird?

 

Klar, ich musste dafür sogar damals Support für den sam3s erst zu openocd hinzufügen: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg13361.html

 

Da kann man auch sehen wie lange wir schon an dem Kram gearbeitet haben bevor wir online gegangen sind .