Witam Was,

Pisałem jakiś kod w C, który posiadał błąd. No i go namierzyłem. Zdumiał mnie skutek tegoż błędu, którego nie potrafię wytłumaczyć. Otóż pracowałem na wskaźnikach, które się rozjechały, więc siało śmieciami po pamięci. Działy się cuda. Procek restartował w kółko, ale z czasem dochodził do pewnego, sprawnego miejsca w kodzie i zamilkł. Zwracał mi na RS232 komunikaty debugingowe ale nie docierał do następnej linii kodu. Nie zdążył jeszcze dojść do miejsca, gdzie te wskaźniki zaczynały mieć wpływ. Korygowałem kod, wielokrotnie przesyłałem - i nic. Cały czas tak jakby wirtualnego breakpointa miał w pewnym miejscu ustawionego. Co ciekawe, wgrałem inny kod, który mam w pełni sprawny - też milkł w połowie działania. Odłączyłem więc zasilanie na chwilę - procek ruszył na sprawnym kodzie. Więc wróciłem do debugowania sypiącego się. I znów to samo - procek umierał "do połowy", żadne inne sprawne programy nie działały w 100%. Restarty nigdy nie pomagały - wyłącznie odcięcie zasilania zawsze zadziałało.

Co takiego mogło się wydarzyć, że procek resetował prawidłowo po użyciu "reset" z programatora, ale działał częściowo - niezależnie od wsadu i tylko zasilaniem można było reanimować go? Czy potrafilibyście napisać taki soft, który po uruchomieniu będzie uwieszał z opóźnieniem każdy inny później wgrany kod?

Szczerze? Jeśli to są jakieś warunki domowe i możesz najzwyczajniej w świecie podmienić procka to go podmień i do przodu. Nie wiem czy jest sens takich dywagacji, nawet w formie zajawki, zakładam, że wiele ludzi nawet za bardzo z takim czymś się nie spotkało, a dodatkowo nikt nie widział tego softu Twojego.
Najprościej możesz sprawdzić czy to błąd hardware czy firmware przez wgranie na nową kość i zobaczenie czy występuje to samo (o ile możesz sobie pozwolić na uziemienie kolejnego).

Skoro mówisz, że wszystko działa ale po pewnym czasie pada to możesz sobie wgrać jakiś najprostszy Hello World i złapać debugerem na jakiej instrukcji się wykłada, prawda?

Nie nie Wszystko jest sprawne. Zadałem pytanie tylko w kontekście zaspokojenia mojej ciekawości. Nie zrozumiałeś - zaraz wyjaśnię co się wydarzyło:

1. Wgrywam jakikolwiek swój działający soft - procek działa perfekcyjnie.
2. Wgrywam potem soft, który sp... i który zwyczajnie sieje po pamięci, co z oczywistych względów prowadzi do katastrofy.
3. Znów wgrywam soft z p.1 i działa tylko do pewnego momentu. Np. wypuszczam na UART "hello world" - przejdzie. Klonuję instrukcję N razy i po którejś jest koniec pracy. Procek zdycha. Mogę wgrywać co chcę - zawsze po zdechnie dość szybko.
4. Teraz zamieniam się w uzdrowiciela i wyłączam na chwilę zasilanie. Wszystkie wgrywane programy od tej pory będą poprawnie działać, aż do momentu opisanego w p.2.

Każdy jeden procek tak samo reaguje. To nie kwestia egzemplarza. Zastanawiam się wyłącznie cóż hipotetycznie może się w procku wydarzyć, czego reset podczas programowania nie zresetuje. Czy są jakieś obszary w procku, które nie podlegają resetowi? Nie mówię o pamięci EEPROM, bo ona nie może mieć na nic wpływu.

A skąd wiesz, że on "wisi" może wykonuje instrukcje, ale nie wiesz jakie.

W każdym razie inne pytanie, czy testowałeś to na 2 prockach?

Na 4-rech testowałem z identycznym wynikiem

To, co nazwałem "wisi" to oznacza "robi coś, czego ja nie życzę sobie". Wgrywam mu banalny kod, kilka tych samych instrukcji, a w pewnym momencie zaczyna się dziać coś spoza linii kodu. No chyba, że wgram soft na ten sam procek po wcześniejszym odłączeniu zasalania - wtedy będzie ok. Tego nie rozumiem.

Witam!
Taka moja propozycja, Byś skorzystał z mkAVRCalkulatora i wgrał wsad z opcją -e(kasowanie AVR).
Miałem przypadek, że na wyświetlaczu śiedmio segmentowym niespodziewanie pojawił się napis APAP - kasowanie AVR pomogło.

Tak czynię zawsze. Eksperymentowałem z flagami i w ramach tego wyłączyłem kasowanie. Zauważyłem, że pominięcie tejże opcji powoduje, że uda się 2-3x wgrać soft (w sensie kolejnych wersji), a potem już koniec zabawy. To również mnie zastanowiło, bo przyczyn nie potrafię sobie wyobrazić. Sądziłem, że kod jest zwyczajnie nadpisywany. No ale wyszło na to, że jest inaczej. Bardzo pokrewny temat.

Zanim zaczniesz wyciągać pochopne wnioski (typu błąd w kompilatorze, w rdzeniu procka itp. ) to wstaw
porządnie zdjęcia jak masz to wszystko połączone, załącz kody źródłowe, pokaż fusebity, wklej co Tobie
programator w konsoli wypluwa (może wydaje Ci się, że dobrze poszło programowanie a tak naprawdę wyłożyło
się na jakimś obszarze pamięci i program wgrywa się częściowo). Od tego zaczyna się konkretne przedstawianie problemu.
W zdecydowanej większości przypadków okazuje się bowiem, że problem wcale nie leży w kompilatorze lub rdzeniu

Dziwne, że w ogóle. EEPROM domyślnie jest kasowany automatycznie, ale FLASH trzeba skasować. Zprogramować poprawnie bez kasowania uda się wyłącznie w przypadku gdy w późniejszym wsadzie nie ma bitów 1 w miejsach gdzie we wcześniejszym były 0. Jeśli jesteś w bardzo eksperymentalnym nastroju możesz to sprawdzić na dwóch wsadach w formie binarnej - XOR dwóch plików potem AND wyniku i pliku późniejszego, jedynki w wyniku wskazują na niedozwoloną zmianę. Wyliczasz adresy gdzie to nastąpiło, plik lss z kompilacji w garsć i patrzysz który to obiekt. Jeśli to nie kod tylko jakaś dana to co najwyżej wyjdzie Ci APAP na wyświetlaczu. Jeśli to drugorzędny kod wykonywany rzadko, to może się wydawać ze program działa prawidłowo.

_________________
Think for yourself and question authority.

A to mnie zaciekawiło! Ja to robię sporadycznie i tylko wtedy gdy mam tylko pliki *.HEX, *.EEP. Jeśli mam projekt to wgrywam program prosto z Eclipse. W Eclipse już jest wstępnie sprawdzony i ewentualnie czyszczony(clean) projekt. Unikam zbędnych bibliotek, zbędnych danych, zbędnych funkcji - są jako komentarz w kodzie i czekają na ich użycie.

Włączyć garbage collection i można sobie darować. Kompilator sam pominie nieużywane funkcje i zmienne. Clean jest potrzebne gdy zmieni się definicję jakiegoś symbolu (typowy przykład: F_CPU). Powyższe nie ma nic wspólnego z opcją -e AVRDUDE

_________________
Think for yourself and question authority.

Ja to zauważyłem, podczas rozwoju jakiegoś kodu. Robiłem niewielkie zmiany, wgrywałem, testowałem i tak w kółko. Przy wyłączonej fladze automatycznego kasowania nie dało się pracować. Kod jest w 100% autorski. Zresztą raczej to nie ma znaczenia.

------------------------ [ Dodano po: 12 minutach ]



Wow Nie zamierzałem aż tak się angażować, by jedynie ciekawość zaspokoić. Jeśli efekt nie jest znany nikomu - to trudno. Nie ma po co aż tak mocno dociekać.
Nawet nie zachowałem wersji oprogramowania z błędem, w której to siało zapisami po całej przestrzeni adresowej, by móc eksperymentować. Zdjęcie procka... hmmm... płytka stykowa i przewody do programatora + kwarc. Nie ma czemu fot robić. A oprogramowanie - jakiekolwiek. Może być zwykła pętla while(1) a w niej wachlowanie pinem. Nie miało kompletnie żadnego znaczenia, co wgrywam. Wszystko się "uwieszało". Po poprawieniu błędu procek działa normalnie, również na każdym innym sofcie.