Na a PHY-t sikerült feléleszteni, szerettem volna valami pinget, vagy bármit kipróbálni, da az Atollic beizzítja a kódméret korlátot és nem hajlandó lefordítani a projectemet. Próbáltam átgyötörni eclipse arm_gcc alá de nem sikerült LwIP-t. Ilyenkor mit tehetek? Azt hittem kicsit több az a 32k korlát, de a valóságban máris nem elég.
Mit tehetek ilyenkor?

Vagy eleve eclipse-be kezdjem a projektet és apránként építsem föl? (atollicban is ugy csináltam, a led villogtató projectemet építgettem tovább. )

Tedd az optimalizalast -Os re, lemegy a meret toredekre.

Kösz, kiprobalom, ez eszembe sem jutott, mert általában az optimalizációt is tiltani szokták.

Megjegyzem, lehet szelektíven is optimalizációt állítani. Pl csak a FreeRTOS és az lwip mappáját állítod be, hogy optimalizálja -Os módon. Azok jó eséllyel úgy is helyesen működnek. A saját kódodban meg lépegethetsz -O1 vagy -O0 optimalizációval.

Egyenlőre rtos nélkül nyomulok, tegnap az egyik demo program lwip binárisát beírtam a devboardba, de elkeseredtem, amikor megláttam a http server sebességét. Ettől még a pic is jobban hasított.

Ettől függetlenül én az atollic-ot azért használom, hogy megszokjam az eclipse környezetet, mert reményeim szerint később könnyebben át tudok térni a sima eclipse verziókhoz.

Ezért szeretném továbbra is tudni, hogy az atollicból lehet e átvinni valahogy projectet a sima eclipse verzióba. Ezt akarom majd használni.

Mivel a kérdésedre elégé összetett lenne a válassz, ezért ismét csak a már mások által leirt megoldást tudok ajánlani:
http://andybrown.me.uk/wk/2012/03/31/stm32f4discovery/

Ő az Atolicot csak Flashelésre és Debugra használja.

Na ez tetszik. Köszönöm! Bár gondolom ettől függetlenül az előző hozzászólásom végén linkelt módon is telepíthetem az eclipse környezetet.

Azonkívül még elég sok leírást lehet találni a neten.
Az eredmény kevés különbséggel mindig ugyanaz.
Még 1 Példa:
Bővebben: Setting up the GCC ARM Toolchain

Bővebben: Project Folder Structure and the makefile

Bővebben: GNU Make.pdf
Hosszú olvasni való (190 oldal).

Szerencsére az alapokat az Atolic megszerkeszti helyettünk!
Csak importálni kel a saját Projectünkbe.
Ezt viszont gyakorolni kel, az ingyenesség érdekében.

Hogyan tudok letakarítani mindent, amit eddig az eclipse-hez telepítettem?
Sokat próbálkoztam sokféle telepítéssel, de kezdenek összeveszni a dolgok.

Hiába konfigolok új eclipse-t a C/C++ Development Tooling - CDT már telepítve van benne.
Az a baj hogy az ld.exe -ben a windows hibát észlel és leáll fordítás közben.

Én csinálnék egy szűz mappát egy új eclipsenek, ami csak ARM ra van.

Igen ezt csináltam, sőt másik meghajtón van, de bármelyiket is próbálom, az ld.exe hibát észlel, és leáll, tegnap még jó volt. Nem értem.

Gcc toolchain reinstall?

Akkor döglik meg, ha berakom a projectbe a stm32f4_flash.ld linker scriptet és hozzáadom Az ARM Sourcery Windows GCC Linker/General/Scriptfile (-T) elérésiúthoz.

De ezt muszály hozzáadnom.

Esetleg ha érdekelne ez valakit EPS Debugger for STM32 a STM32F4DISCOVERY fut vele gond nélkül
Itt található GNU ARM Toolchain 4.6.3

Ezzel nem találkoztam, kipróbálom. Ez az eclipse tiszta kinlódás.

Ha már ennyi időt beleöltem az eclipse-be és ennyi segítséget kaptam mostmár befejezem az eclipse beállításomat.

Már majdnem jó, annyi baj van, hogy a fordítás végén a linker ezt a hibaüzenetet dobja:
Tehát valami _start cimkét keres rajtam, de nem tudom, hol kell megadni és milyen értékkel. Valaki találkozott már ezzel? A projekt egyébként mostmár lefordul, de ha be akarom írni a prociba, akkor azt írja az stlink, hogy Invalid Start Adress és nem kezdi el az írást.

Másik, nekem folyton hex file keletkezik, holott bin kellene.

Ezert erdemes minimalis kornyezetet hasznalni. Nekem pl. linux alatt gedit-bol fut az osszes make 'akarmi' es csodasan mukodik. Ezek a keretek csak plusz kin. Ha "elsore" megy jo, de ha nem akkor csak a mereg.
Nekem amugy a linker flags igy nez ki: Ebbol a legfontosabbat kiemeltem.

-nostartfiles

A bin igy keletkezik:


ahol :

es a CP pedig:

Köszönöm, mostmár jó, már csak egy működő debugger (ST-Link) beállításra lenne szükség és akkor összeáll a cucc.

Openocd fent van ? En a 0.6.1-et telepitettem fel. Patchelni kellett. A hagyomanyos patcheles nem jott ossze, ezert manualisan kellett megoldani, de mukodik. Szerencsere csak egy filet kell modositani. Openocd-nel fontos lehet, hogy ha ket config filera van szukseg (es igy volt) , es azok egymas alatt helyezkednek el a konytarstrukturaban, akkor mindegyik eleresi utat kulon meg kell adni -s kapcsoloval, kulonben nem talalja.

Ha fent van az arm-none-eabi-gdb akkor azt igy kell inditani:

Makefileban igy nez ki a bejegyzes:



Ez make gdb -re dolgozik.

Sziasztok!

A következő érdekes problémával szembesültem (Cortex-M3, LM3Sxx, Codesourcery - GCC).

Van egy deklarált változóm, ami 1024 byte méretű (DISP_RAM_LEN):


Van egy teljesen másik rutinban egy Timer0 timeout (overflow) interruptom.



És a teszt kedvéért ennyiből áll az interruptom:


A jelenség a következő, hogy az 1024 byte-os buffer végére (utolsó 20-60 byte - változó) folyamatosan random adatok kerülnek be. Ha letiltom a Timer0 interruptját, hibátlan a buffer. Ha engedélyezem akkor újra összeszemeteli a disp_ram-ot.

Gondoltam ezekre eddig:
- SRAM túl kicsi és ezért. De 96K SRAM-van, és a linker script-be is tudattam a linkerrel.
- Túl hosszú az interrupt. Nem lehet, mert flag törlés után egyből return (lásd fentebbi példa).
- Más interrupt nem zavar be, mert nincs.
- ResetISR, NMI és FaultISR kezelve van és végtelen ciklussal beragasztva (hogy észrevegyem ha van)
- Optimalizációval és anélkül is fennáll a hiba.

Valakinek van valami ötlete esetleg?
Már elkeseredésemben próbálkoztam: volatile, static, volatile static kulcsszavakkal is.
Most a következő ötletem, hogy hiába byte szervezésű a disp_ram ami kell, 32-bitesre alakítom át, hátha a sok byte kezelésével van a gond (de persze ha minden byte miatt lefoglalna egy 32bites blokkot, akkor sem lenne gond, mert az is csak 4K lenne).

Bármi ötletet, vagy tippet a további hibakeresésre elfogadok.

Köszönöm!

Én két valószínű problémakört tudok elképzelni (ami végülis ugyanaz a probléma):
- az interrupt handler meghívásakor nem mentődik el minden, aminek el kéne,
- a főprogram olyan erőforrásokat használ, aminél nem garantált, hogy interrupt esetén nem rondít bele valami.
Az interrupt rutint mi hívja meg? Gondolom van valami standard könyvtár, abban van az igazi interrupt handler, és az hívja meg a felhasználó rutinját. Ha nem ez a helyzet (a fenti rutin maga az interrupt handler), akkor viszont tuti, hogy valami spéci kulcsszóval meg kell mondani a fordítónak, hogy generálja bele a rutinba a mentéseket/visszatöltéseket. Ha gcc a fordító, akkor erre külön flag van: Bővebben: Link, azt kell használni. Érdemes megnézni az adott fordítóhoz/az adott standard könyvtárhoz készített móricka-példákban mit használnak.

Erre tudtam én is gondolni, azért tiltottam le gyakorlatilag mindent. Semmi nem fut, csak egy időnkénti SSI használat, amiből kiderül, hogy tönkrement a disp_ram buffer.
Próbaként letiltottam a globális interruptokat SSI használat előtt, majd utána vissza. De gyakorlatilag kiküldés előtt már rossz a disp_ram.

Ezen kívül üres a főciklus, nincs más engedélyezve sem a próba miatt és a SSI használat is másodlagos, nagyon ritkán hívódik meg.

Debugolod a futást a procin? Sokmindent elárulna.
Stack és heap mérete megfelelő?
Probáld ki, hogy a stack méretét duplájára állítod.

Lenne kérdésem, megjegyezem mellesleg hogy nem használom CMSIS-t mert szerintem orbitális szívás. Működik az ISR rutinod? Odaugrik egyáltalán? A végén mindig törli a bitet rendesen?

Az IRQ rutinod után kellene egy __irq jelzés a fordítónak. Nálam legalábbis kéri sőt követeli

Írd meg bare-metal-ba úgy látni és tudni fogod hogy mi történik. CMSIS-t is emberek csinálták, és van benne hiba dögivel. A random adat hardver felöli hiba lehet, szerintem nem tölődik mindig és rendesen a Timer0 Interrup Flag. Törlés hiányában pedig az első adandó alkalommal vissza is ugrik a rutinba, de mivel az ugrásnak nincs alapja - mert nem áll fenn az esemény, pl nincs korrekt adat - így el tudom képzelni hogy a véletlen szerű adat az a Timer-el kapcsolatban álló hardvered egy pillanatnyi állapota.

Az NVIC-ben az interruptok törlése a CLEAR ENABLE bittel történik.
Példa:
USART1 Interrupt engedélyezése: SET ENABLE


Interrupt Handler végén a Flag törlése: CLEAR ENABLE


Szóval én nem bízom abban a CMSIS-es megszakítás törölve részben.

Stack méretével is próbálkoztam, semmi változás.

ARM7 és M0 alatt én sem, de most a (fejlesztési) sebesség miatt fordultam hozzá elsősorban az ethernet miatt.

A megszakítás meghívása teljesen jó, GPIO-t villogtatva meggyőződtem róla. ICDI-vel programoztam, nem debugoltam (nem szoktam, én a ledvillogtatós, nyomógombos debugolás híve vagyok, nagyon sok idő-kritikus applikációt fejlesztettem már, és a debugger az használhatatlan amikor tényleg jól jönne...)

Az IRQ flag törlést elvégeztem regiszter szinten is kézzel, a helyzet változatlan, de maga az IRQ megy rendesen.

Helyesbítek!

Lefordítottam IAR-al is a kérdéses részt, és ott rendesen bele tudtam mászni debuggerrel a stack kérdéskörbe. Megnéztem, az interrupt közben miket akar stack-elni és megnéztem az IAR és a GCC kód különbséget. Az IAR ugyan azt, egyharmaddal kisebb kódra fordítja és ott a jelenség nem jött elő.

IAR-al ment 64 byte stack-el is, GCC esetén csak 192 byte esetén nem jött elő a hiba. De ugyan azon kód viszont gyorsabban fut GCC-vel fordítva, mint IAR-al.

Köszönöm szépen, úgy néz ki egyenlőre ez a kérdés megoldódott. Azért nem is nyomoztam tovább, mert megkétszereztem a stack méretét és a hiba akkor is fennált... De úgy néz ki a kétszerezés kevés volt.