Jump to content
Sign in to follow this  
wthie

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

Share this post


Link to post
Share on other sites

Welchen Compiler, welche Version und welche Optimierungen verwendest du?

Share this post


Link to post
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)

 

Share this post


Link to post
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 :).

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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 :).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...