STM32 System Workbench problem z wgraniem programu

[piotrdn]

Witam,

Ostatnio zauważyłem problem podczas wgrywania programu dla mikrokontrolera STM32F429. Problem objawia się następująco:

-Tworzę nowy projekt -> zapisuje, builduje, (nie ma błędów) -> wgrywam program poprzez Utility (wybierając plik z rozszerzeniem HEX) -> działa.

- Biorę ten sam projekt i wprowadzam pewne modyfikacje (np. zmieniam częstotliwość w CUBE, wybieram inny pin itp, generalnie drobne zmiany) -> zapisuje, builduje (nie ma błędów) -> wgrywam, i niestety bez powodzenia. Załączam screena z Utility po nieudanej próbie wgrania kodu.

Doszedłem do tego, że raczej wina leży po stronie Workbencha i niepoprawnie utworzonego pliku z rozszerzeniem HEX (plik ten jest praktycznie pusty, sprawdziałem go notatnikiem), ponieważ gdy chcę wgrać inny projekt wówczas wszystko działa poprawnie.

Próbowałem odinstalować oprogramowanie i zainstalować od nowa. Nie pomogło.

Czy ktoś spotkał się z czymś takim?

[Treker (Damian Szymański)]

@piotrdn podaj dla pewności wersja używanych programów. Zbadamy temat, bo ostatnio sporo takich zapytań się pojawiło.

[piotrdn]

[Zealota]

Zastanawiam się skąd bierzesz plik hex i po co go używasz.

W domyślnych ustawieniach System Workbench nie ma możliwości generowania pliku w tym formacie.

Używasz jakiegoś dodatkowego pluginu, czy jeszcze jakoś inaczej go generujesz?

W SW jest przecież przycisk "Run", który z poziomu Eclipse wgrywa plik elf do procesora, nie ma potrzeby używania ST link utility.

Na początku jest trudność z takim sposobem, ale w projekcie należy zmodyfikować opcje debuggera i bez problemu z każdego projektu można wgrywać  wsady do mikrokontrolera.

Wszystko wskazuje, że używamy tej samej wersji SW.

 

Edytowano Marzec 26, 2019 przez Zealota
jeszcze coś dopiszę

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[slon]

Widzę, że @piotdn miał takie same perypetie jak ja (też piotr :) ) ale udało mi się z tym poradzić. Tak na wstępie płytkę stm discovery F411 mam ok kilku dni. Więc na początek zacząłem od kursu stm. Zainstalowałem ST-link, sterowniki, CubeMX i System Workbench for Stm32 i wszytko ładnie poszło bez błędów. Więc kolejno robię to co w kursie a tam w końcu dochodzimy do etapu gdzie trzeba wgrać plik .bin a umnie takiego niema ale jest .hex więc chce wgrać .hex i mam taki sam problem jak @piotrdn (0s 0ms). To tak sobie myślę co można zrobić w 0s 0ms no tak na zdrowy rozum to nic. Więc borę w ST-LINK opcję ---> Program & Veryfi i odrazu pojawia się błąd. Robię od początku całą operację począwszy od CubeMX i System Workench wyberam ---> build All ,  przechodzę na zakładkę comments po kompilacji i wszystko jest Ok. Wchodzę w folder gdzie jest plik .hex ma on rozmiar 10KB więc wgrywam przez ST-LINK i jest OK. Następnie edytuję plik w System Workbench wybieram --->  Build All i teraz na zakładce comments mam komunikat:  nothing to build?? a plik .hex w docelowym folderze na rozmiar 1KB? no i teraz jak by chcieć to wgrać przez STM-LIK ---> Program,  to pojawia się to 0s 0ms. 

Rozwiązanie jest takie : tak od początku. CubeMX ---> import do System Workbench ---->Build All---->edytujemy kod ----->zapis-----> Build project(nie Build all) ----> STM-LINK ---->program. 

Po każdym wgrani przez ST-link zamykać zakładkę .hex (w ST-link). Cała metoda działa za każdym razem.

[Treker (Damian Szymański)]

@slon dzięki za podzielenie się Twoim rozwiązaniem 🙂 

Zrobiliśmy u siebie testy kilka dni temu i doszliśmy do wniosku, że to musi być jednak błąd w aktualizacjach CubeMX/SW, ponieważ takie same problemy pojawiały się nawet przy dokładnym odtwarzaniu instrukcji zamieszczonych na stronach ST. Zobaczymy czy u innych zadziała Twoje rozwiązanie 😉

[gregoor]

Aktualnie borykam się z takim samym problemem. Doszedłem do tego, że wina jest po stronie STM32CubeMx. Zrobiłem 2 kopie działających projektów, a następnie próbowałem "zepsuć" jeden z nich. Kod pozostawiłem ten sam, tylko generowałem projekt na różne sposoby w STM32CubeMx. Po uzyskaniu spodziewanego efektu, podmieniałem pliki z tego złego do tego dobrego i testowałem patrząc po zawartości pliku hex/elf. Wyniki jakie uzyskałem:

zepsuta wersja projektu wygenerowana w CubeMx zawsze miała pusty plik w lokalizacji: ....\<nazwa_projektu>\SW4STM32\<nazwa_projektu>\<plik_z_rozszerzeniem_ld> w moim przypadku było to "STM32F429ZITx_FLASH.ld". Po podmianie jedynie zawartości tego pliku z projektu działającego, do tego "złego" wszystko działało. Jest on odpowiedzialny, tak z grubsza, za organizację pamięci w uC. Plik zmienia się tylko wtedy, gdy generuje się nowy projekt w STM32CubeMx. Oczywiście po usunięciu tego pliku z projektu, kompilacja się zatrzymuje.

Macie jakieś pomysły jak to naprawić?

Załączam także ten plik - https://pastebin.com/6fHHZHp5

[Treker (Damian Szymański)]

@gregoor witam na forum 🙂

Tak, masz rację - to błąd w oprogramowaniu. Kontaktowałem się z ST i ten problem został potwierdzony. Ma być naprawiony w aktualizacji, a do tej pory najlepiej ręcznie kopiować wspomniany przez Ciebie plik.

[gregoor]

trzeba będzie jakiś skrypt napisać 😄