Im HQ befinden sich zur Zeit für verschiedene Bastelprojekte und Experimente fünf STM32F4 Discovery Boards.


== Doku ==
* Produktseite und Doku: http://www.st.com/internet/evalboard/product/252419.jsp
* Projekte auf Github: https://github.com/sebseb7/pentstm32f4
* Deutsche Doku zu STM32-Controllern allgemein: http://www.mikrocontroller.net/articles/STM32
* Prozessor: STM32F407 VG [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00037051.pdf Datasheet]
* [http://pentapad.hq.c3d2.de/p/TA_Hack_Your_Arm Etherpad zum Themenabend] am 11.07.2012


=== eLua ===
für das board gibt es auch einen noch nicht upstream geflossenen elua support

http://wiki.eluaproject.net/STM32F4DISCOVERY

dieser findet sich auch github

https://github.com/jsnyder/elua/tree/bikeNomad-master

_john  bastelt wohl da mit mal etwas rum. 
Bereits gestestete erste Schritte:

<pre>
	git clone git@github.com:tuxcodejohn/elua.git 
…
	cd elua
	git checkout -b origin/bikeNomad-master
…
	export PATH=$PATH:/<hier toolchain bin pfad>
	scons board=STM32F4DSCY prog 
…
</pre>
jetzt solltest man elua_lua_stm32f407vg.bin im aktuellen verzeichnis finden... sonst war wohl noch irgendeine vorraussetzung nicht erfüllt... siehe auch toolchain.
Um diese auf eines dieser boards zu programmieren brauchst du ein Programmiertool. Zum Beispiel das <tt>dfu-util</tt> (mindestens in der Version 0.5)
<br>
<tt> 2 b continued...</tt>


=== Exemplare in Benutzung ===
Boards sind gegenwärtig verliehen an bzw. in Benutzung durch:
* koeart
* john
* lachmoewe
(ein defektes Board liegt im HQ, auf der Platinenunterseite steht grün auf grün DEFEKT)


=== Toolchain ===
Um lustige Software für das Board zu bauen ohne irgendwie eine Entwicklungsumgebung zu kaufen musst Du Dir Deien eigene CrossToolchain bauen.

Für MacOS und Linux:<br>
jsnyder arm-eabi-toolchain: https://github.com/jsnyder/arm-eabi-toolchain<br>
ACHTUNG! BAUT EWIG!

Zum Testen dann sebseb7's pentstm32f4 clonen und 
<pre>
make 
make flash 
</pre>machen. Bei mir hats mit arm-eabi nicht auf Anhieb geklappt, da kein Hardware float support mitkompiliert wurde. In den makefiles 
<pre>
./Makefile 
./STM32_DSP_Lib/build/Makefile 
./STM32F4xx_StdPeriph_Driver/build/Makefile
</pre>
muss dann jeweils
<tt>-mfloat-abi=softfp</tt>
gesetzt sein, dann sollte es gehen.

=== Troubleshooting ===
==== Couldn't find any ST-Link/V2 devices ====
<tt>-make flash</tt> liefert den Fehler <tt>WARN src/stlink-usb.c: Couldn't find any ST-Link/V2 devices</tt>. 

===== add this to your /etc/udev/rules.d/ dir 

--------------------49-stlinkv2.rules:

         SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", \
    	 OWNER:="john",MODE:="0660", \
    	 SYMLINK+="stlinkv2_%n"
replace john with your username ...

==== gdb ====
Wenn Deine Software nicht will, kannst Du wie auf dem Ta vorgestellt zu drastischen Mitteln wie dem gdb greifen. Den nötigen gdb-server gibt es auf 
https://github.com/texane/stlink



==== Hard Fault Handler ====
Der Tip mit dem hfh kam auf dem ta etwas kurz. hier ein link, der doch ganz gut erklärt, wie man einen sinnvollen hfh bekommt:
http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/

==== Disassembler ====
Wenn dem Code auch im gdb nicht beizukommen ist, oder Dein HFH (siehe oben) Dir eine Adresse ausspuckt und Du nun wisses willst, was an dieser adresse geschiet, ist es es häufig nützlich einen Disassembler auf das elf binary abzufeuern und nachzusehen, was dem chip da grade Sorgen bereitet. Das geht zum Beispiel mit dem aus den binutils stammenden Tool objdump so:
         
        arm-none-eabi-objdump -dsl foo.elf > foodis.txt




[[Kategorie:Projekt]]