🚀 go-pugleaf

2019-10-22 o 08:26 -0700, Maciek Godek napisał:
> piszę program na mikrokontroler STM32 (tzn. z ARMem).
> 
> W ostatnim czasie zauważyłem dość dziwne zachowanie: czasem (kiedy
> np. załączę do obrazu dużą tablicę z danymi) kontroler w ogóle nie
> wstaje.

Bez wczytywania się - brzmi jak problem za małego stack. Próbowałeś
może zaallokować twoją "dużą tablicę" via malloc() ? albo oflagować
ją jako static?

Mateusz

W dniu wtorek, 22 października 2019 17:33:56 UTC+2 użytkownik Mateusz Viste napisał:
> 2019-10-22 o 08:26 -0700, Maciek Godek napisał:
> > piszę program na mikrokontroler STM32 (tzn. z ARMem).
> > 
> > W ostatnim czasie zauważyłem dość dziwne zachowanie: czasem (kiedy
> > np. załączę do obrazu dużą tablicę z danymi) kontroler w ogóle nie
> > wstaje.
> 
> Bez wczytywania się - brzmi jak problem za małego stack. Próbowałeś
> może zaallokować twoją "dużą tablicę" via malloc() ? albo oflagować
> ją jako static?

Tablica jest globalna i oznaczona jako const, dlatego w całości powinna trafić do flasha (i to się zgadza z tym, co zwraca size).

To zresztą zgadza się z outputem size'a - rosną przede wszystkim sekcje rodata i text.

Stos raczej nie powinien być bardzo głęboki. W każdym razie różnica w samym kodzie występuje dopiero po inicjalizacji peryferiów, więc raczej bym się spodziewał że przynajmniej coś się gdzieś ruszy.

Zresztą na kontrolerze mam ponad pół megabajta ramu (z czego - jak widać - zmienne globalne zajmują mniej więcej połowę)

Zastanawiam się czy to może być błąd gcc - może gdzieś źle alignuje jakiś adres i dostaje jakiegoś hard faulta.

Malloc nie wchodzi tu jednak w grę. Mam co prawda swój alokator, ale korzystam z niego oszczędnie. Co się da muszę trzymać we flashu, i przenoszenie tych danych do ramu nie miałoby sensu, bo one i tak się nie zmieniają.

On 22/10/2019 17:26, Maciek Godek wrote:
> W ostatnim czasie zauważyłem dość dziwne zachowanie: czasem (kiedy np. załączę do obrazu dużą tablicę z danymi) kontroler w ogóle nie wstaje.

Czas podpiąc openocd i nawet w tak gołym środowisku, po wykonaniu halt 
powinieneś zobaczyć gdzie siedzi i co robi z poziomu konsoli openocd.

Natomiast *zdecydowanie* polecam podpięcie się do niego z gdb i razem z 
eclipse można wtedy mówić o debugu. To nie jest trudne.

http://ardupilot.org/dev/docs/debugging-with-gdb-on-stm32.html

U mnie na ten przykład podobna zagadka zakończyła się zamordowaniem w 
myślach idioty który w skrypcie linkera usunął sekcję odpowiedzialną za 
tablice wirtualne i wystawił to jako oficjalny i konsekrowany kawałek 
kodu. Bez debuggera walczyłbym z tym tygodniami.

W dniu środa, 23 października 2019 20:57:35 UTC+2 użytkownik heby napisał:
> On 22/10/2019 17:26, Maciek Godek wrote:
> > W ostatnim czasie zauważyłem dość dziwne zachowanie: czasem (kiedy np. załączę do obrazu dużą tablicę z danymi) kontroler w ogóle nie wstaje.
> 
> Czas podpiąc openocd i nawet w tak gołym środowisku, po wykonaniu halt 
> powinieneś zobaczyć gdzie siedzi i co robi z poziomu konsoli openocd.
> 
> Natomiast *zdecydowanie* polecam podpięcie się do niego z gdb i razem z 
> eclipse można wtedy mówić o debugu. To nie jest trudne.
> 
> http://ardupilot.org/dev/docs/debugging-with-gdb-on-stm32.html
> 
> U mnie na ten przykład podobna zagadka zakończyła się zamordowaniem w 
> myślach idioty który w skrypcie linkera usunął sekcję odpowiedzialną za 
> tablice wirtualne i wystawił to jako oficjalny i konsekrowany kawałek 
> kodu. Bez debuggera walczyłbym z tym tygodniami.

Z debuggerem też się trochę próbowałem bawic, ale okazało się, że to fałszywy trop.
Zauważyliśmy, że problem pojawiał się wtedy, kiedy rozmiar wygenerowanego obrazu przekraczał pół megabajta.
Na procku jest 1MB flasza, więc teoretycznie nie powinno to stanowić problemu. Z drugiej strony, ta pamięć jest podzielona na 2 bloki po 512 kilo.

Wprawdzie cały czas nie wiem, co było przyczyną błędu, ale okazało się, że jeśli  przed wgraniem obrazu wyczyści się całego flasha, to problem znika.

Dlatego teraz skrypt ładujący rutynowo czyści flasha.

Ale 2 dni pracy stracone.

On 24/10/2019 20:02, Maciek Godek wrote:
> Wprawdzie cały czas nie wiem, co było przyczyną błędu, ale okazało się, że jeśli  przed wgraniem obrazu wyczyści się całego flasha, to problem znika.

Idę o zakład że ukryłeś buga.

> Dlatego teraz skrypt ładujący rutynowo czyści flasha.
> Ale 2 dni pracy stracone.

Teraz będzie ich znacznie więcej :D

Czyszczenie pamięci w celu usuwania bugów to bardzo, bardzo zły pomysł.

W dniu czwartek, 24 października 2019 20:15:46 UTC+2 użytkownik heby napisał:
> On 24/10/2019 20:02, Maciek Godek wrote:
> > Wprawdzie cały czas nie wiem, co było przyczyną błędu, ale okazało się, że jeśli  przed wgraniem obrazu wyczyści się całego flasha, to problem znika.
> 
> Idę o zakład że ukryłeś buga.

Skąd taki wniosek?
(No, i jakiego buga?)

> > Dlatego teraz skrypt ładujący rutynowo czyści flasha.
> > Ale 2 dni pracy stracone.
> 
> Teraz będzie ich znacznie więcej :D
> 
> Czyszczenie pamięci w celu usuwania bugów to bardzo, bardzo zły pomysł.

Jeżeli problem pojawiał się przez to, że obraz zajmuje więcej niż pół megabajta, to to jest raczej problem spowodowany infrastrukturą.

Jeżeli problem wynika stąd, że program nie chce się wgrać na mikrokontroler, to nie ma znaczenia, co to za program.

On 24/10/2019 20:41, Maciek Godek wrote:
>>> Wprawdzie cały czas nie wiem, co było przyczyną błędu, ale okazało się, że jeśli  przed wgraniem obrazu wyczyści się całego flasha, to problem znika.
>> Idę o zakład że ukryłeś buga.
> Skąd taki wniosek?

Z doświadczenia.

> (No, i jakiego buga?)

Prawdopodobnie niezainicjowana zmienna lub czytanie z uszkodzonego 
wskaźnika, jeśli to bug w software. Teraz czyta zera albo ff i 
przypadkiem działa.

>> Czyszczenie pamięci w celu usuwania bugów to bardzo, bardzo zły pomysł.
> Jeżeli problem pojawiał się przez to, że obraz zajmuje więcej niż pół megabajta, to to jest raczej problem spowodowany infrastrukturą.

Nie wiesz do czasu aż nie znajdziesz prawdziwej przyczyny.

Po prostu bym tego tak łatwo nie zostawiał. Za każdym razem kiedy ktoś 
mi mówi "wyczyściłem pamięci i bug zniknął" zapala mi się nie tyle 
czerwona lampka tylko wali tysiącem kogutów we wszystkich kolorach RGBT+.

W dniu czwartek, 24 października 2019 21:46:13 UTC+2 użytkownik heby napisał:
> On 24/10/2019 20:41, Maciek Godek wrote:
> >>> Wprawdzie cały czas nie wiem, co było przyczyną błędu, ale okazało się, że jeśli  przed wgraniem obrazu wyczyści się całego flasha, to problem znika.
> >> Idę o zakład że ukryłeś buga.
> > Skąd taki wniosek?
> 
> Z doświadczenia.
> 
> > (No, i jakiego buga?)
> 
> Prawdopodobnie niezainicjowana zmienna lub czytanie z uszkodzonego 
> wskaźnika, jeśli to bug w software. Teraz czyta zera albo ff i 
> przypadkiem działa.

Objawy są takie:
Przy wgrywaniu kodu wyświetla się błąd programatora, że jakiś adres jest źle zapisany. 

Podaj mi choć jedną hipotetyczną sytuację, w której taki błąd mógłby być spowodowany kodem programu.

Na ile rozumiem, podczas wgrywania obrazu program jest zatrzymany. W przeciwnym razie każde wgrywanie obrazu generowałoby całe zoo niezdefiniowanych zachowań.

(Ale mogę być w błędzie, bo nigdy nie analizowałem tego procesu)

> >> Czyszczenie pamięci w celu usuwania bugów to bardzo, bardzo zły pomysł.
> > Jeżeli problem pojawiał się przez to, że obraz zajmuje więcej niż pół megabajta, to to jest raczej problem spowodowany infrastrukturą.
> 
> Nie wiesz do czasu aż nie znajdziesz prawdziwej przyczyny.

To prawda.
Ale raczej nie znajdę, jeśli nie będę miał dobrej hipotezy.

> Po prostu bym tego tak łatwo nie zostawiał. Za każdym razem kiedy ktoś 
> mi mówi "wyczyściłem pamięci i bug zniknął" zapala mi się nie tyle 
> czerwona lampka tylko wali tysiącem kogutów we wszystkich kolorach RGBT+.

Tyle że 'bug' oznacza zazwyczaj zachowanie kodu. Tutaj oznacza raczej zachowanie infrastruktury.

Żeby nie było, temat drążę i kontaktuję się w tej sprawie z przedstawicielami ST.
Może się uda wyjaśnić.

On 24/10/2019 23:05, Maciek Godek wrote:
> Przy wgrywaniu kodu wyświetla się błąd programatora, że jakiś adres jest źle zapisany.

Nieprawda.

Napisałeś:

"Wszystko co prawda kompiluje się i linkuje bez problemu, ale po wgraniu 
obrazu nastaje cisza"

Do tego się odnoszę.

Jeśli teraz zeznana się inne to moje uwagi się do tego nie odnoszą.

W dniu sobota, 26 października 2019 11:59:15 UTC+2 użytkownik heby napisał:
> On 24/10/2019 23:05, Maciek Godek wrote:
> > Przy wgrywaniu kodu wyświetla się błąd programatora, że jakiś adres jest źle zapisany.
> 
> Nieprawda.

Jaka nieprawda?

> Napisałeś:
> 
> "Wszystko co prawda kompiluje się i linkuje bez problemu, ale po wgraniu 
> obrazu nastaje cisza"
> 
> Do tego się odnoszę.
> 
> Jeśli teraz zeznana się inne to moje uwagi się do tego nie odnoszą.

Zeznania są o tyle 'inne', że są pełniejsze.

Kompilacja i linkowanie przebiegały bez problemu. Obraz wgrywałem przy pomocy st-link_cli i nie zauważyłem błędu. (Co nie znaczy, że go nie było)

Pewnie wyniknęło to po części z tego, że program CLI nie zwraca kodu błędu do systemu (wywoływałem go przez makefile'a, który wypisuje komunikat błędu, gdy użyte narzędzie zwróci do systemu wartość niezerową)

Jak wgrałem przez narzędzie GUI, wyskoczył pop-up.
Jak wyczyściłem flasza i wgrałem, pop-up nie wyskoczył.

I tyle.

Nadal nie wiem, dlaczego programatorowi nie udaje się wgrać obrazu bez czyszczenia całego flesza

W dniu 2019-10-26 o 14:57, Maciek Godek pisze:

> Nadal nie wiem, dlaczego programatorowi nie udaje się wgrać obrazu bez czyszczenia całego flesza

Programy do urządzeń wrzucamy z programu produkcyjnego za pośrednictwem 
prowizorycznie zrobionego programatora (drutowana przeróbka jakiejś 
płytki), który, jak każda prowizorka, działa już lata (chyba ponad 10).

Mieliśmy taki problem, że czasem trzeba było programowanie przepuścić 2 
razy, aby było skuteczne (za pierwszym razem EEPROM się nie kasował). 
Problem występował tylko u nas (w biurze konstrukcyjnym) i tylko czasem 
a nigdy na produkcji więc nie było silnej determinacji aby go szukać.

OIDP się okazało, że Clear-All (mimo swojej nazwy) nie czyści 
wszystkiego gdy fuse bit zabezpieczający EEPROM przed modyfikacją jest 
ustawiony. Chyba nie wynikało to jasno z opisu.

Może w oprogramowaniu Twojego programatora jest błąd i np. kasuje tylko 
pierwszy bank flash. Może gdy procesory były mniejsze i miały tylko 
jeden bank to była jakaś funkcja clear-all i programator ją wywołuje, a 
jak dołożyli drugi to może autor oprogramowania programatora rozszerzył 
tylko adresy zakresu programowania a nie zauważył, że teraz już 
clear-all nie czyści wszystkiego a tylko pierwszy bank, a dla drugiego 
trzeba zawołać jakąś nową funkcję.
P.G.