Author Topic: Firmware master-brick rekompiliert, hängt im Auslesen der uid  (Read 2722 times)

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
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

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Welchen Compiler, welche Version und welche Optimierungen verwendest du?
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
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)

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
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 :).
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
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

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Ich hab mal die Master Brick und Bricklib repos neu ausgecheckt und gebaut, bei mir werden die .bin und .elf im Anhang erzeugt.
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Arg, ich hab Firmwares aus dem falschen Ordner hochgeladen. Die aktuelle git Version ist im diesem Anhang ;D!
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
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

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
Übrigens, deine Firmwares laufen beide :-)

Thxs

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
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 :).
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: Firmware master-brick rekompiliert, hängt im Auslesen der uid
« Reply #10 on: October 01, 2012, 21:36:28 »
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

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Firmware master-brick rekompiliert, hängt im Auslesen der uid
« Reply #11 on: October 02, 2012, 09:09:03 »
Oh, was hast du denn genau getan um das Problem zu beheben? Gab es da eine spezifische Konfiguration?
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

wthie

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re: Firmware master-brick rekompiliert, hängt im Auslesen der uid
« Reply #12 on: October 02, 2012, 17:27:08 »
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?

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Firmware master-brick rekompiliert, hängt im Auslesen der uid
« Reply #13 on: October 02, 2012, 19:07:53 »
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 :o.
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!