[Rozwiązano] STM32F411 - dioda nie świeci po ERASE CHIP, problem z .hex

Zdecydowałem się zacząć naukę programowania mikrokontrolerów, podążając kursem ze strony forbot.pl opierającym się na modelu STM32F411.
Niestety w połowie 4 rozdziału, w momencie w którym należało podpiąć diodę pod przycisk pojawił się problem, mianowicie program mimo że przepisany bez błędów, po wgraniu przez ST-LINKa na płytkę nie chciał działać, kontroler wciąż wykonywał poprzedni program.
Zdecydowałem się użyć opcji ERASE CHIP. Po jej użyciu jak przewidywałem poprzedni program przestał się wykonywać. Dodatkowo żaden nowy program też wykonywać się już nie chciał. Pole "Core state" pokazywało status "lockup".
Po stworzeniu nowego projektu, i napisaniu podstawowego polecenia zapalającego diodę udało się go wgrać na płytkę, status lockup zniknął, ale dioda się nie zapaliła, sytuacja powtórzyła się dla każdej z 4 diód na płytce.
Zauważyłem też że pliki .hex moich wcześniejszych projektów mają postać:

:04000000F8B500BF90
:04000400F8B500BF8C
:00000001FF

A chyba nie powinny tak wyglądać.
Próbowałem wymazywać pamięć przez bootloader, ale niestety nie pomogło. Nie mam już pomysłów co robić , czuje że popełniłem gdzieś jakąś głupote.
Byłbym bardzo wdzięczny za wszelką pomoc

Przede wszystkim udostępnij kod oraz napisz w jakim środowisku lub IDE to realizujesz. Bez konkretów nie będziemy mogli Tobie pomóc.

Działam w SW4STM32 oraz korzystam z STM32CubeMX w formie nakładki na eclipse. Wgrywanie programów oraz chip erase wykonałem za pomocą ST-LINK Utility. Przy późniejszej próbie wyczyszczenia pamięci przez bootloader korzystałem z STMFlashLoader Demo
Tak wyglądał program, który przerwałem za pomocą chip erase:



A to jest program, który nie wykonywał się pomimo wgrania za pomocą ST-LINKa:



Dodano po 13 [minuty]:

Prawdopodobnie drugi program nie chciał mi działać, ponieważ nie zauważyłem że plik .hex programu przyjął formę
:04000000F8B500BF90
:04000400F8B500BF8C
:00000001FF
W trakcie pisania programu dodałem w STM32CubeMX pozostałe 3 diody, przycisk oraz etykiety pinów, po wygenerowaniu kodu program skompilował się bez problemu, ale może wtedy .hex zmienił się w te pare marnych linijek, nie wiem.

piotx45 napisał:

Nie mam już pomysłów co robić

To może wgraj oryginalną zawartość z Nucleo F411 jaka jest w nówkach na dzień dobry, by przynajmniej sprawdzić Nucleo plus ST-link. On tam miga i reaguje na przycisk może pamiętasz:

piotx45 napisał:

Prawdopodobnie drugi program nie chciał mi działać, ponieważ nie zauważyłem że plik .hex programu przyjął formę...

A jaką formę miałby przyjąć i co z obecną formą jest nie tak?

piotx45 napisał:

A to jest program, który nie wykonywał się pomimo wgrania za pomocą ST-LINKa:

Nacisnąłeś przycisk na płytce, żeby sprawdzić czy diody zapalą się dopiero wtedy?

rb401 napisał:

piotx45 napisał:

Nie mam już pomysłów co robić

To może wgraj oryginalną zawartość z Nucleo F411 jaka jest w nówkach na dzień dobry, by przynajmniej sprawdzić Nucleo plus ST-link. On tam miga i reaguje na przycisk może pamiętasz:

Zaraz spróbuję

Dodano po 3 [minuty]:

Freddie Chopin napisał:

piotx45 napisał:

Prawdopodobnie drugi program nie chciał mi działać, ponieważ nie zauważyłem że plik .hex programu przyjął formę...

A jaką formę miałby przyjąć i co z obecną formą jest nie tak?

Działające programy wyglądały mniej więcej tak:

Freddie Chopin napisał:

piotx45 napisał:

A to jest program, który nie wykonywał się pomimo wgrania za pomocą ST-LINKa:

Nacisnąłeś przycisk na płytce, żeby sprawdzić czy diody zapalą się dopiero wtedy?

Oczywiście, miały się dopiero wtedy zapalić, jednak to nie nastąpiło.

piotx45 napisał:

Działające programy wyglądały mniej więcej tak:...

Ale to co pokazałeś to jest CAŁY plik .hex czy jego fragment? Bo jak fragment, to ja naprawdę nie wiem co tam wygląda inaczej niż podobny fragment z "wcześniejszego" hexa.

Freddie Chopin napisał:

Ale to co pokazałeś to jest CAŁY plik .hex czy jego fragment? Bo jak fragment, to ja naprawdę nie wiem co tam wygląda inaczej niż podobny fragment z "wcześniejszego" hexa.

Różnicę pomiędzy hexami chyba najlepiej zobrazuje stan pamięci układu po wgraniu każdego z nich.

Pierwszy hex:


Drugi hex:

piotx45 napisał:

Różnicę pomiędzy hexami chyba najlepiej zobrazuje stan pamięci układu po wgraniu każdego z nich.

Akurat najlepiej tą różnicę by pokazało, jakbyś zamiast wrzucania obrazków odpowiadał precyzyjnie na pytania.

Jeśli to jest cały HEX, to znaczy że masz źle skonfigurowany projekt w swoim IDE.

rb401 napisał:

To może wgraj oryginalną zawartość z Nucleo F411 jaka jest w nówkach na dzień dobry, by przynajmniej sprawdzić Nucleo plus ST-link. On tam miga i reaguje na przycisk może pamiętasz:

No jest jakiś postęp chociaż nie wiem czy można to nazwać postępem.

Wgrałem ten program, wyrzucił mi jakiś błąd elf loadera ale ostatecznie znalazł się w pamięci:



Niestety żadne diody się nie zaświeciły.

Następnie wpadłem na pomysł żeby pobrać jakieś próbne programy od producenta, dedykowane dla płytki Discovery. Wgrałem program o nazwie Demonstration, którego kod (z którego niestety niewiele rozumiem) wygląda tak:



Przy wgrywaniu zostałem uraczony serią błędów:


Po czym rdzeń wszedł w stan lockup, po naciśnięciu przycisku reset na płytce zaświeciła się niespodziewanie zielona dioda a rdzeń zmienił stan na running, po ponownym wciśnięciu przycisku dioda zgasła i już się nie zaświeciła.

Potem z ciekawości wgrałem prosty program mający zaświecić niebieską diodę, znowu zostałem uraczony błędami a następnie na płytce zaświeciły się diody: czerwona i zielona.
Po chwili otrzymałem taki komunikat:



Na szczęście udało się połączyć z powrotem.
Czy to już moment aby dzwonić po egzorcystę?

Dodano po 6 [minuty]:

Freddie Chopin napisał:

Akurat najlepiej tą różnicę by pokazało, jakbyś zamiast wrzucania obrazków odpowiadał precyzyjnie na pytania.

Jeśli to jest cały HEX, to znaczy że masz źle skonfigurowany projekt w swoim IDE.

Wybacz w takim razie, nowo tworzone projekty mają pliki .hex takie jak w drugim przypadku. Nie chcą jednak działać.

Dodano po 40 [minuty]:

Jest jakaś możliwość przywrócenia mikroprocesora do czegoś w rodzaju ustawień fabrycznych?

piotx45 napisał:

No jest jakiś postęp chociaż nie wiem czy można to nazwać postępem.

Wgrałem ten program, wyrzucił mi jakiś błąd elf loadera ale ostatecznie znalazł się w pamięci:

piotx45 napisał:

Niestety żadne diody się nie zaświeciły.

Po kolei, nie za dużo rzeczy naraz, bo się trochę robi chaos.
Spróbuj ten plik .bin wgrać prosto z ST-link Utility albo po prostu kopiując go na ten wirtualny dysk od Nucleo. Ten plik teraz wgrałem u siebie do Nucleo dla pewności i jest ok, lampka miga itd. .
Czyli to musi działać skoro masz to samo Nucleo.

piotx45 napisał:

Różnicę pomiędzy hexami chyba najlepiej zobrazuje stan pamięci układu po wgraniu każdego z nich.

Tu akurat to co pokazałeś wygląda w miarę normalnie i tak właściwie nie ma różnicy w tych dwóch przypadkach.
Po prostu dwie pierwsze liczby 32bitowe (czyli osiem bajtów) w flashu (obojętnie czy patrzysz od 0x00000000 czy 0x08000000 bo to alias) muszą spełniać warunki takie, że pierwsza liczba musi pokazywać istniejący adres w RAM (zwykle gdzieś przy końcu) i druga istniejący adres we Flash (zwykle gdzieś blisko początku). Z tym że ta druga liczba koniecznie musi być nieparzysta.
Tu gdzie pokazujesz, te warunki są spełnione (choć np. jak na wielkość RAM F411 trochę nisko pierwsza liczba, ale to kwestia ustawień w projekcie), tak że w tej chwili trudno z tego coś wywnioskować w świetle Twoich problemów.

piotx45 napisał:

Jest jakaś możliwość przywrócenia mikroprocesora do czegoś w rodzaju ustawień fabrycznych?

Jeśli nie grzebałeś w Option Bytes, to stan fabryczny Nucleo masz dokładnie po wgraniu tego pliku co dałem.

W sumie zamiast pokazywać plik hex to mógłbyś pokazać plik listingu i/lub mapę. W tych plikach jest najwięcej użytecznych danych.

rb401 napisał:

Czyli to musi działać skoro masz to samo Nucleo.

Tyle że ja mam płytkę Discovery, a nie Nucleo :/

Dodano po 4 [minuty]:

_lazor_ napisał:

W sumie zamiast pokazywać plik hex to mógłbyś pokazać plik listingu i/lub mapę. W tych plikach jest najwięcej użytecznych danych.

Jestem nowy w temacie, proszę rozwiń pojęcie plik listingu/mapa.

piotx45 napisał:

Tyle że ja mam płytkę Discovery, a nie Nucleo :/

Aaaaaa.... No to inna rozmowa. Zasugerowałem się tym że widziałem kiedyś na Forbocie kurs robiony na Nucleo. Ale okazało się że jest tych kursów z STM32 jest więcej. Ale też trochę późno zareagowałeś na to że daję Ci plik na Nucleo.
No nie ważne. Faktycznie demo z Nucleo na Disco nie będzie działać, choć procesor bardzo zbliżony, bo pewnie co najmniej ma lampki na innych pinach portów.

Tu masz już właściwy (mam nadzieję) plik demonstracyjny do Twojego Discovery. Niestety nie mam możliwości samemu dla 100% pewności go u siebie sprawdzić bo nie mam teraz takiej płytki pod ręką.

piotx45 napisał:

Jestem nowy w temacie, proszę rozwiń pojęcie plik listingu/mapa.

Aby uzyskać mapę musisz dodać flagę do budowania:
-Wl,-Map,output.map

Nie wiem gdzie u Ciebie w IDE się to robi.

Aby uzyskać listing, musisz odpalić objdump z swojego toolchaina

arm-none-eabi-objdump -S twój_plik.elf > twój_plik.lst

To rozwiązanie z command line, może gdzieś u Ciebie w IDE jest jakiś check box który to zrobi auto magicznie.

rb401 napisał:

Tu masz już właściwy (mam nadzieję) plik demonstracyjny do Twojego Discovery. Niestety nie mam możliwości samemu dla 100% pewności go u siebie sprawdzić bo nie mam teraz takiej płytki pod ręką.

Plik wgrał się prawidłowo, na płytce zaczęły sekwencyjnie zapalać i gasić się wszystkie 4 programowalne diody tak jak przy pierwszym podłączeniu płytki do komputera. Widzę jednak że zielona dioda działa "na odwrót" tzn cały czas świeci i gaśnie wtedy kiedy jest jej kolej by zaświecić.
Spróbowałem następnie na próbę wgrać program zapalający niebieską diodę, który nie chciał wcześniej działać. Niestety wciąż nie chciał zadziałać.

Oto kod niedziałającego programu:



Dodano po 2 [minuty]:

Tutaj jest plik output.map tego programu, tyle że jako txt żeby zaakceptowało załącznik

Kombinuje jeszcze nad wygenerowaniem pliku .lst

Jest i plik .lst

piotx45 napisał:

Plik wgrał się prawidłowo, na płytce zaczęły sekwencyjnie zapalać i gasić się wszystkie 4 programowalne diody tak jak przy pierwszym podłączeniu płytki do komputera. Widzę jednak że zielona dioda działa "na odwrót" tzn cały czas świeci i gaśnie wtedy kiedy jest jej kolej by zaświecić.

O, i tu się robi ciekawie.
Przeglądam źródła tego programu demonstracyjnego od STM i jak widzę, to w pierwszej części demo (do naciśnięcia przycisku), te lampki powinny migać całkowicie symetrycznie. Są wstępnie zgaszone a później toglowane (czyli zmieniany na stan przeciwny) dokładnie tyle samo razy każda z diod. Od strony programu żadna nie jest inaczej traktowana.
Jeśli jednak zielona zachowuje się diametralnie różnie od pozostałych, to jest jakiś punkt zaczepienia, nie wdając się na razie w inne Twoje problemy. Moim zdaniem to trzeba wyjaśnić jakoś racjonalnie.

Ale jest sprawa, którą dobrze by było byś sprawdził najpierw. Spójrz na płytkę od tyłu, w rejonie gniazdka słuchawkowego, na piny złącz, czy przypadkiem nie masz zgiętych któryś pinów, albo czy coś metalowego (np. śrubka) utknęło pomiędzy pinami:


Tam właśnie są wyjścia portów, które też idą na ledy. Zwarcie między nimi mogło by faktycznie powodować dziwne anomalie w świeceniu tych czterech diod led.

dodaj jeszcze flagę -g aby były symbole debugowe i będzie łatwiej czytać mapę i listing...

rb401 napisał:

Ale jest sprawa, którą dobrze by było byś sprawdził najpierw. Spójrz na płytkę od tyłu, w rejonie gniazdka słuchawkowego, na piny złącz, czy przypadkiem nie masz zgiętych któryś pinów, albo czy coś metalowego (np. śrubka) utknęło pomiędzy pinami:

Sprawdziłem i żadne piny na płytce nie są zwarte. Ciekawe, bo po wciśnięciu przycisku na płytce nic się nie zmienia, a z tego co napisałeś wynika że program demonstracyjny powinien jakoś zareagować. Wyrzuciłem go przed chwilą z pamięci za pomocą full chip erase z poziomu ST-LINKa i po skończonej operacji na płytce wciąż świeciła się zielona dioda. Przestała świecić po wciśnięciu przycisku reset.

Dodano po 24 [minuty]:

_lazor_ napisał:

dodaj jeszcze flagę -g aby były symbole debugowe i będzie łatwiej czytać mapę i listing...

Z tego co widzę flaga -g była domyślnie ustawiona, tyle że w bardziej szczegółowej opcji:


Zauważyłem jednak że wygenerowałem plik .lst z flagą -D, a ty chciałeś z flagą -S. Nowy plik w załączniku.

piotx45 napisał:

Oto kod niedziałającego programu:

Tu w w Twoim poście #16, w tym prostym zaświeceniu niebieskiej lampki masz z jakiegoś powodu prosty błąd, np. tutaj:


Odwołujesz się do portu B (GPIOB) a te cztery kolorowe lampki są na porcie D(GPIOD).
Popraw ten port we wszystkich miejscach gdzie występuje i zobacz czy teraz świeci. Przynajmniej coś by było do przodu.

piotx45 napisał:

i po skończonej operacji na płytce wciąż świeciła się zielona dioda. Przestała świecić po wciśnięciu przycisku reset.

W tym fabrycznie wgrywanym programie, którego źródła masz u siebie na dysku bo pisałeś już nim wcześniej w #10 (Demonstrations), dioda D4 (zielona) ma też inną funkcję. Sygnalizuje jakiś błąd w np. inicjalizacji jakiegoś sprzętu, w ten sposób że po jej zaświeceniu program utyka w martwej pętli i już więcej nic nie robi (i to chyba u Ciebie się dzieje):



Co prawda we fragmencie samego migania ta funkcja nie jest wywoływana i powinna zielona migać jak pozostałe, ale tak wstępnie widzę że w dalszej części demo, już po naciśnięciu przycisku user, w kilku miejscach może pojawić się przyczyna wywołania tej funkcji, np. przy braku kontaktu z akcelerometrem, czy jakiś problemach inicjalizacji USB itd. . Tyle że w tej chwili trudno wyczuć z którego miejsca program u Ciebie wskakuje w Error_Handler.

rb401 napisał:

Tu w w Twoim poście #16, w tym prostym zaświeceniu niebieskiej lampki masz z jakiegoś powodu prosty błąd, np. tutaj:

Kod: C / C++

Zaloguj się, aby zobaczyć kod

Odwołujesz się do portu B (GPIOB) a te cztery kolorowe lampki są na porcie D(GPIOD).
Popraw ten port we wszystkich miejscach gdzie występuje i zobacz czy teraz świeci. Przynajmniej coś by było do przodu.

Faktycznie, a to ciekawa sprawa, bo te fragmenty kodu są wygenerowane automatycznie przez STM32CubeMX.
Spróbowałem zmienić wszędzie zarówno na GPIOD jak i na GPIOB, w żadnym wypadku dioda się niestety nie zaświeciła.

piotx45 napisał:

Faktycznie, a to ciekawa sprawa, bo te fragmenty kodu są wygenerowane automatycznie przez STM32CubeMX.

Automatycznie owszem, ale ja bym tu jednak rozważył "czynnik ludzki" w błędnym wskazaniu portu w CubeMx. Ale może przemilczmy to.

piotx45 napisał:

Spróbowałem zmienić wszędzie zarówno na GPIOD jak i na GPIOB, w żadnym wypadku dioda się niestety nie zaświeciła.

Diody są tylko na GPIOD. Ruszanie pinem 15 na GPIOB jest bezproduktywne bo ten pin idzie donikąd.

Jeśli korygujesz ręcznie ten projekt to oprócz tych trzech miejsc gdzie zmieniasz błędny GPIOB na GPIOD musisz też zmienić tą instrukcję:



na:


Bez tej zmiany sterowanie portem D nie będzie działać a tym samym nie zaświecisz lampki.

A jeśli coś jeszcze nie tak, to może zrób ten testowy projekt jeszcze raz, na czysto, zwracając uwagę by ten port się nie pokręcił.

piotx45 napisał:

czuje że popełniłem gdzieś jakąś głupote.

No czyli dobrze czułem XD
Nie zauważyłem że jest więcej niż jeden pin z numerem 15 i w CubeMX sugerując się jedynie numerem wybierałem niechcący pin PB15 zamiast PD15. Głupota straszna, ale przynajmniej trochę się nauczyłem próbując to naprawić. Dzięki wielkie za poświęcony czas i wszelkie podpowiedzi!

Moderowany przez Marek_Skalski:

2020.03.26: Temat odblokowałem na prośbę Autora.

Temat można uznać za zamknięty.