STM32F4 Discovery - STLink Utility nie wykrywa urządzenia po instalacji sterowników

Witam, zakupiłem właśnie moduł STM32F4 Discovery i postanowiłem założyć jeden wątek, w którym będę prosił o radę we wszystkich napotkanych problemach (a już wiem, że będzie ich co najmniej kilkanaście).
Problem 1 napotkałem na samym początku: zainstalowałem sterowniki do STlink oraz program STlink Utility. Wybieram opcję Target->connect i już nie widzi żadnego STlinka, więc dalej nawet nic nie próbuje. Jakieś porady?

Ok, odinstalowałem, zainstalowałem jeszcze raz i działa - magia. Widocznie samo napisanie tu na forum sprawia że coś zaczyna działać. Ale pojawił się
Problem nr2
Instaluje wszystko po kolei wg poradnika Frediego Chopina i utknąłem na instalacji OpenOcd
Ściągnąłem paczkę openocd-0.6.0 a w niej kilka tys plików i żadnego .exe z instalatorem. Wg Frediego

Cytat:

Proces instalacji OpenOCD jest w miarę oczywisty

ale ja poległem, więc chyba nie tak całkiem oczywisty.
a tak na marginesie to ten OpenOCD w ogóle jest mi potrzebny? On obsługuje STlink?

lukash90 napisał:

Instaluje wszystko po kolei wg poradnika Frediego Chopina i utknąłem na instalacji OpenOcd
Ściągnąłem paczkę openocd-0.6.0 a w niej kilka tys plików i żadnego .exe z instalatorem. Wg Frediego

Błagam! Może trochę własnej inwencji? O każdy najdrobniejszy szczegół będziesz pytał na forum?

lukash90 napisał:

a tak na marginesie to ten OpenOCD w ogóle jest mi potrzebny?

Skąd ktoś ma wiedzieć co Tobie jest potrzebne?

lukash90 napisał:

On obsługuje STlink?

Czy tylko pytając na forum elektrody można się tego dowiedzieć?

4\/3!!

Widzicie, kolego Freddie, dla początkujących chyba jednak lepszy jest Keil...

BlueDraco napisał:

Widzicie, kolego Freddie, dla początkujących chyba jednak lepszy jest Keil...

Eee tam. Trzeba tylko video tutorial zrobić jak rozpakować OpenOCD i będzie git

P.S. A czemu nie TrueSTUDIO tylko Keil ?

BlueDraco napisał:

Widzicie, kolego Freddie, dla początkujących chyba jednak lepszy jest Keil...

Przecież dokładnie takie same pytania mogę zadać o Keila, jakbym był Linuxiarzem to bym napisał "sed 's/OpenOCD/Keil/g'" (; Każdy sobie używa co chce, ja tylko nie zgadzam się z twierdzeniem, że Keil jest najlepszy, najcudowniejszy, bezproblemowy i w ogóle ideał.

4\/3!!

1. Utwórz na dysku C: katalog OpenOCD
2. Rozpakuj wszystkie pliki z paczki "openocd-0.6.1.zip" do katalogu c:\OpenOCD\
3. Zainstaluj STM32 ST-LINK Utility_v2.5.0 do pobrania na stronach STM
4. krok 3 zainstaluje ci też sterowniki do stlinka
5. odpal konsole (cmd.exe)
6. wpisz cd c:\openocd\bin
7. podłącz płytkę do kompa
8. wpisz openocd-0.6.1 -f scripts\board\stm32f4discovery.cfg
9. ciesz się podłączeniem OpenOCD do stlinka
10. pomyśl jak to zautomatyzować

1. Pobierz i zainstaluj Keil MDK-ARM.
2. Zainstaluj driver ST-Link z foldera, w którym zainstalował się Keil, klikając w niego myszą.
3. Odpal MDK-ARM i stwórz projekt.
4. W ustawieniach projektu wybierz ST-Link i typ układu.
5. Używaj. Nie trzeba nic automatyzować.

Wada: Open Source to to nie jest i ma ograniczenie do 32 KiB. Zacząć jednak z tym łatwiej niż z DIY, w dodatku praktycznie wszyscy producenci uC bardzo go lubią i dostarczają dużo programów przykładowych.

Naprawdę nie mam nic przeciwko innym środowiskom, widzę też parę wad Keila, ale początkującym zdecydowanie bym go polecił jako rozwiązanie najmniej kłopotliwe na start.

Z darmowych powiedziałbym że gcc+CooCox jak już ktoś musi mieć "spójne" IDE. Tyle tylko, że ma toto ładne babole w debugu [nie radzi sobie z odczytem rejestrów FSMC] + żeby zaprogramować procka muszę to robić dwa razy i nie diaboła nie wiem z czego to wynika...
No i nie radzi sobie np. z STM32F3, chyba, że przez "generic M4" (ale to raczej nie jest wyjście)

mrsajm0n napisał:

A tu nie zaczniesz się głowić jeszcze nad napisaniem programu, a zdążyłeś wyrwać wszystkie włosy próbując konfigurować openocd+eclipse+linaro. Dwa razy już podchodziłem do tego i nie udało mi się dopiąć działającego środowiska dla stm32f0.

Nie wiem naprawdę co może się tutaj nie udać, to jest mechaniczna zabawa typu "ściągnij, rozpakuj, uruchom, ściągnij, rozpakuj, uruchom" + 30s klikania w Eclipse... Ewentualnie 5s jeśli się zaimportuje projekt-szablon.

4\/3!!

mrsajm0n napisał:

Wiem, że nie wiesz. Tak jak bogaty nie wie co to bieda. Jakoś to się nie udaje wielu osobom.

Słabe porównanie... Nie udaje się np. takim osobom jak autor tematu w którym jesteśmy - zamiast instalatora w archiwum są pliki OpenOCD no i koniec... (teraz zacząłem podejrzewać, że autor tematu ściągnął paczkę ze źródłami...) Nie da się pójść dalej, może poszukać na stronie opisu, czy może google albo wyszukiwarka forum (w ostateczności pomyśleć)... Potem okazuje się, że po włączeniu Eclipse nie ma tam przycisku "automatycznie skonfiguruj mi taki projekt jak mi potrzebny" no i znów koniec, bo się nie da poszukać czy pomyśleć... Widząc jakie to straszne "problemy" ludzie napotykają z takim toolchainem można je wg. mnie podzielić na następujące kategorie, które obejmują 99% przypadków (z doświadczenia):
- najpopularniejsza - zaczynam z założeniem że to strasznie trudne, ewentualnie że Keil jest najlepszy, najgłupszy problem napotkany na drodze ogłaszam jako spektakularne fiasko, "gcc to dno" i kończę "przygodę" bez nawet 5s poświęconych na znalezienie rozwiązania
- zakładam że znajduje się w jaskini 1000m pod ziemią i przy pierwszym problemie od razu się poddaję, bez poszukania w google, w komentarzach lub na forum, zapytanie absolutnie nie wchodzi w grę (BTW - czy ja kiedyś komuś nie odpowiedziałem?)

Pozostały 1% przypadków to faktyczne problemy których rozwiązanie udaje się znaleźć na forum lub rozwiązać z pomocą choćby moją. W temacie o tym toolchainie czy w komentarzach pod artykułem jest opis rozwiązania 99% możliwych problemów. Nie pojawiają się w animowanych "balonikach" w Windowsie, trzeba poświęcić tą chwilę za pierwszym razem żeby to przeczytać (ewentualnie użyć google lub po prostu pomyśleć), niektórzy po prostu mają bardzo wygórowane oczekiwania i jeszcze uznają je za "podstawowe"...

No bo spójrzmy na sprawę realnie, biorąc za przykład ten wątek - jaki "kosmiczny" problem napotkał autor tego tematu? Jeśli dla kogoś samodzielna konfiguracja CZEGOKOLWIEK jest zbyt skomplikowana i musi być kreator (najlepiej z obrazkami), taki na max 5 kliknięć, to... ARM, elektronika, programowanie nie są dla każdego i tyle. Jeśli kogoś zadowala 32kB kodu albo ma zbędne 5000€ to proszę bardzo - można używać Keila. Jednak jeśli ktoś twierdzi, że używając Keila od razu jest cudownie to sorry - w tym programie jest tysiąc opcji i programy nie piszą się same, wiec...

4\/3!!

Ludzie co wy z tą konfiguracją eclipse ? Przecież to idzie "od kopa " że tak powiem, a tu co drugi temat o tym
Można ściągnąć przykład o Freddiego można z Yagarto można z przykładów od STM, można podejrzeć jak to jest zrobione w TrueSTUDIO (to jest przecież Eclipse i gcc).
Ja wziąłem gotowy projekt z przykładów od STM, makefile od Feddiego. W Eclipse zrobiłem nowy projekt z Makefile, wybrałem tollchain jako cross gcc. Skopiowałem przykład od STM i makefile od Freddiego do katalogu projektu. W makefile podałem ścieżki do źródeł, skryptu linkiera. I już wszystko po prostu działa.

mrsajm0n napisał:

F4 poszło mi spokojnie i twój przykład (Freddie) odpaliłem. Dziękuję Ci bardzo za cały wkład jaki dałeś od siebie dla nas. Ale problem miałem robiąc frankensteina dla F0, następnym razem postaram się przebić i pytać w razie czego.
imarszi - zauważ, że pliki z przykładów od ST (skrypty linkera) mają przezabawne obostrzenia licencyjne.

Wystarczy wejść do projektu dla RIDE tam nie ma żadnej licencji dla skryptu linkiera.

Akurat zmiana skryptu linkera jest najprostszą rzeczą [;

4\/3!!

http://www.coocox.org/
Na początek w sam raz, a i później wystarczy.

Bardzo dziekuje za wszystkie odpowiedzi, ostatecznie uruchomiłem coocox, zajęło to 5 min i wszystko działa. Nie bardzo jeszcze widzę czemu coocox nie jest tak polecane jak surowe eclipse ale to już dla mnie mniej istotne. Tylko jeśli mógłbym jeszcze prosić o wskazówkę gdzie znajdę informacje o szybkości zegara w coocox? Ustawił mi automatycznie maksymalną 168MHz? Dodało mi tam sporo plików i przyznam, że trochę sie zagubiłem co jest gdzie. Ewentualnie może któreś pliki mógłbym wyrzucić? Na razie wgrałem przykład LED_Blink i zajmuje on po optymalizacji 3kB, trochę sporo moim zdaniem

lukash90 napisał:

Nie bardzo jeszcze widzę czemu coocox nie jest tak polecane jak surowe eclipse ale to już dla mnie mniej istotne.

lukash90 napisał:

Ustawił mi automatycznie maksymalną 168MHz? Dodało mi tam sporo plików i przyznam, że trochę sie zagubiłem co jest gdzie.

Czyli jednak wiesz (;

4\/3!!

Jeśli napiszesz pusty SystemInit, to zegar zostanie taki, jak po Reset, czyli wolny z wewnętrznego oscylatora.
Z drugiej strony jeśli już się używa F4, to nie po to, żeby chodził na 8 MHz. Tak to ja robię często w mikrokontrolerach z Cortex-M0, kiedy nie zależy mi na wydajności.

Powiem tak Eclipse to cholerstwo mam go nieraz dość spać nie mogę użeram się już z nim trochę ALE.... jak narazię poradnik freediego plus forum plus freedi i jakoś problemy się rozwiązują. Odkrycie problemu i go rozwiązanie daje wiele frajdy naprawdę. A każdy rozwiązany problem to spora dawka wiedzy o eclipsie i procesorze. Wszystko jest przejrzyste widzę wszystkie pliki i cały kod jaki zostanie wgrany nic nie jest pochowane po kątach. I co najlepsze najbardziej skaszanione środowisko jak tak po rozrabiam w ustawieniach że nic nie da się zrobić stawiam on nowa w 5 minut (wywalam folder i rozpakowuje eclipse od nowa) plus kilka chwil na instalacje pluginów. A sama deinstalacja keila pewnie trwa z 10 min

Ja nie muszę deinstalować Keila, chyba że chcę wyrzucić starą wersję po wgraniu nowej. Potrzeba do tego ze trzech kliknięć i z pół minuty, ale niech Ci będzie.

Każda pliszka swój ogon chwali
Ja używam Geany i makefile'a i też mi dobrze
Swoją drogą ciekawe jak to jest przy pracy zespołowej - czy każdy może używać swojego ulubionego edytora/ide, czy też musi być unifikacja?
Bo jeśli dobrze rozumiem IDE generują swoje makefile'y automatycznie na podstawie wyklikanych ustawień?

To chyba zależy od licencji i samego miejsca zatrudniena. U mnie np. nie było z tym problemu, przy czym każdy używał raczej lekkich edytorów typu vi, ProgrammersNotepad czy inny Crimson Editor, do tego Makefile+CVS. A prototypowaniem w sprzęcie zajmowały się i tak pojedyncze osoby.

Pzdr.

Mam jeszcze (mam nadzieję) ostatnie pytanko odnośnie samego Coocox. Daje radę tworzyć projekty, kompilować i debugować ale zauważyłem, że gdy chcę wrócić do jakiegoś projektu np następnego dnia to często nie da się go już skompilować, mimo że nie wprowadziłem ani jednej zmiany. Dostaję error

Cytat:

C:\program files (x86)\codesourcery\sourcery_codebench_lite_for_arm_eabi\arm-none-eabi\lib\armv7e-m does not exist.

. Oczywiście cały toolchain dalej w tym miejscu jest, nic nie zmieniam. Jak założę nowy projekt to ten się da normalnie skompilować. Pytanko teraz czy to jest normalne i jest to jeden z powodów, dla którego Coocox jest niepolecany? Czy to może ja coś tylko namieszałem? Słabo tak zakładać codziennie nowy projekt i kopiować te same pliki

Proponuje nie instalować niczego w folderach z nawiasami i ewentualnie też spacjami - może przez to masz problem.

4\/3!!