Jump to content

Firmware master-brick rekompiliert, hängt im Auslesen der uid


Recommended Posts

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

Link zu diesem Kommentar
Share on other sites

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)

 

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
Share on other sites

  • 3 months later...

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?

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...