Sterownik C.O. - Mój program-potrzebuje sprawdzenia.

Witam.
Ponad rok temu popełniłem sterownik do pieca co.
Od tamtego czasu staram się poprawiać program i wyłapywać wszystkie błędy jakie w nim są.
Dużo rzeczy zostało już poprawione ale mam dwa problemy których nie potrafię naprawić.
Program napisany w bascomie (tu proszę z góry nie komentować języka programowania i nie namawiać na przejście na inny), tylko ten język programowania znam i napisałem program tak jak umiałem.

Ale przejdźmy do problemu.
Otóż sterownik wysyła po bluetooth (BTM222) dane do Zdalnego panelu. Problem w tym że co jakiś czas dane są błędne. Ale tylko dwa parametry się nie zgadzają. A mianowicie temperatura zewnętrzna i stan pompy.
Tak jakby program sterownika wysyłał złe dane. Odbiornik nie sygnalizuje błędu (suma kontrolna).
I tylko te dwa parametry wszystko inne jest ok.
Dodam że kiedy źle wysyła to temp zewnętrzna zawsze jest 0 a pompa pomimo włączenia pokazuje że jest wyłączona.

Drugi problem jest znacznie poważniejszy i pojawił się niedawno.
Otóż sterownik potrafi umrzeć po jakimś czasie działania, zwykle po kilku godzinach.
Objawia się to tym że pomimo włączonego zasilania wyświetlacz nic nie pokazuje i w ogóle sterownik nie reaguje. Pomaga tylko wyłączenie i włączenie zasilania. Jakby procesor wchodził w powerdown .
Nie wiem dlaczego się tak dzieje skoro mam włączony watchdog. Mniemam że winowajcą tego stanu jest program ponieważ jeszcze dwa miesiące temu nie było takiego problemu.

Mam nadzieję na pomocne wskazówki.

Pozdrawiam.

Ostateczna wersja programu jest gdzieś zamieszczona?

Dodaje poprawnie listing programu.

Proszę niech ktoś zerknie na mój program.

Ja przeglądałem go tysiące razy i nie mogę wyłapać błędów.

Pozostaje nadal kwestia wyłączania się sterownika a w zasadzie nie wyłączania a jakiegoś zawieszania (nie wiem jak to nazwać) no i kwestia błędnie wysyłanych dwóch parametrów.

Po pierwsze takie numery to prawdziwy horror:



Po drugie podstawową sprawą jest porządne dobrze filtrowane napięcie zasilające.
Podejrzewam że "wykrzacza" się sam lcd. Proponuję zacząć sprawdzanie układu od tych dwóch rzeczy.

Zasilanie raczej nie stanowi problemu.

Ale skoro LCD się wykrzacza to dlaczego procek też nie reaguje? Nawet podświetlania LCD nie ma.
Jakby program poszedł w krzaki. Ale to też niemożliwe skoro watchdog go pilnuje.

No czary jakieś.

A mnie się wydaje że to jednak zasilanie. Mozliwe że dzieje się tak jak startuje przy piecu jakaś dmuchawa lub pompa. Sam się męczyłem z takimi objawami u siebie.
W Bascomie właśnie zdarzają się cuda które ciężko wyjaśnić...
Ale pomijając język programowania , to warto stworzyć nową wersję kodu i umieszczać kolejno nowe elementy (bloki funkcji) programu i testować w którym momencie zaczną się problemy. Może po prostu puścić jakiś prosty program wyświetlający jakiś testowy licznik czy nawet miganie ledem , przy okazji załączając pompę lub dmuchawę aby sprawdzić czy nie jest to wina zasilania lub uszkodzonego uC. Tak ja bym zrobił.

Opiszę jak to było dzisiaj jak byłem w pracy.

Pod moją nieobecność rozpalili w piecu, oczywiście na sterownik nikt nie zerknął a ten oczywiście włączony ale martwy.
Temperatura skoczyła prawie do stu zadzwonili do mnie kazałem wyłączyć na chwilę sterownik i włączyć z powrotem.
Po tym pompka wystartowała ale wyświetlacz razem z podświetlaniem martwy ale o dziwo procesor chyba normalnie pracował bo dane po bluetooth do panelu zdalnego szły normalnie no i pompka włączyła się wyłączyła prawidłowo.
Ja po pracy do kotłowni kilka resetów zasilania i nic wyświetlacz martwy. Rozebrałem sterownik odłączyłem płytę główną podłączyłem z powrotem poskładałem włączam i działa. Ale zdarzyło się coś co miało miejsce już wcześniej a o czym nie napisałem.
Mianowicie po takich akcjach już trzy razy zdarzyło się że z epromu wyleciał numer seryjny pierwszego czujnika (od kotła). Nie wiem czemu tak robi skoro nie zapisuję go nawet w pierwszej komórce pamięci.

Poruszałem jeszcze porządnie wszystkimi złączkami elementami w środku by sprawdzić czy aby coś nie łączy i nic sterownik nie wyłączył się.

I teraz takie pytanie dlaczego sterownik najpierw w ogóle nie zareagował na temperaturę (był jakby całkowicie martwy) a później wyświetlacz był martwy a procesor działał normalnie.

Gdyby jakiś element programu źle działał to przecież Watchdog powinien załatwić sprawę czy tak? Czy jednak program może tak "pójść w krzaki" że nawet watchdog nie da rady?


A i jeszcze jedno. Nie bardzo powodem problemów może być włączająca się pompa ponieważ sterownik umiera tylko i włącznie podczas bezczynności.
Wentylator to na razie opcja i jest to nieużywane.

pier napisał:

Gdyby jakiś element programu źle działał to przecież Watchdog powinien załatwić sprawę czy tak? Czy jednak program może tak "pójść w krzaki" że nawet watchdog nie da rady?

Watchdog zawsze da radę inaczej nie miałby sensu istnienia.

Zrób sobie jakiś rejestr zdarzeń i po nim dojdziesz do tego co się dzieje. Piszesz o bluetooth i panelu zdalnym, więc może tam niech rejestr będzie założony.
W rejestrze tym zapisuj także z jakiej przyczyny został zresetowany mikrokontroler - rejestr MCUCSR.

Watchdog nie zawsze zadziała tak jak powinien. Dlatego są do tego celu specjalne zewnętrzne układy jak DS1813 (odnośnie zasilania) . Proponuję w fusebitach włączyć układ Brown-out Detection i ustawić na 4V.
Jeśli chodzi o lcd to może zawiesić się także sam wyświetlacz , dlatego u mnie mam możliwość odcięcia zasilania i ponownej inicjalizacji podczas pracy programu.
Kasowanie się eepromu także potwierdza możliwość problemów z zasilaniem.
Może dla testu odsunąć od pieca sterownik i podpiąć pod inny zasilacz (ja zasilam u mnie cały system ze zwykłego mocnego zasilacza ATX).

adambehnke napisał:

Watchdog nie zawsze zadziała tak jak powinien.

Dlaczego i w jakiej sytuacji?

pier napisał:

A i jeszcze jedno. Nie bardzo powodem problemów może być włączająca się pompa ponieważ sterownik umiera tylko i włącznie podczas bezczynności.

A może powodem jest komunikacja uart? Może program po prostu w którymś miejscu wchodzi w jakąś niekończącą się pętlę.

No ale Panowie jeśli Watchdog daje radę podnieść procesor po zawieszeniu to po co mam szukać buga w programie? Czy nie jest tak że po zawieszeniu się programu watchdog resetuje procesor i ma być on znów włączony od początku poprawnie?
Jeśli tak i jeśli mam nawet buga w programie to mimo wszystko sterownik nie powinien umierać jak ma to miejsce u mnie.

Nie powiem że nie sprawdzę programu tak że będę wyłączał jego części i sprawdzał po kolei czy pomogło ale chcę wiedzieć po prostu.

I jeszcze jedno czy powodem problemów może być sam lcd? Czy wyświetlacz może zablokować procesor?

Cytat:

A może powodem jest komunikacja uart? Może program po prostu w którymś miejscu wchodzi w jakąś niekończącą się pętlę.

No jeśli nawet tak jest to przecież Watchdog by zresetował kontroler.

Przypomniał mi się jeszcze jedno. Miałem duże problemy z programami kompilowanymi w nowych wersjach Bascom (zachowywały się dziwnie głównie obsługa 1Wire i uart) . Najstabilniejszą wersją jaką używałem była wersja 1.11.9.

No ja jak na razie kompilowałem wersją 1.11.9.5

To że procesor wystartuje za pomocą watchdoga, to nie znaczy, że będzie mógł poprawnie zainicjować wyświetlacz, który także mógł "dostać po łbie" jakimś przepięciem, wyładowaniem, itp., i w jego przypadku być może trzeba będzie wyłączyć mu zasilanie.

W okolicach 1991 r. miałem przypadek super fajnej centrali alarmowej firmy z Gdańska, opartej na Z80. Naprawdę świetnie oprogramowana z dużymi możliwościami - na Polskim rynku jedna z najlepszych w tamtym okresie. Ale wada projektowa polegała na nieprawidłowej filtracji zasilania, która ujawniała się przy byle przepięciach w sieci, o burzy już tylko wspomnę. Producent poniósł z tego tytułu spore koszty dodatkowe, a problemem był brak kilku kondensatorów, nieistotnych z punktu widzenia ekonomi (czytaj ceny) tej centrali.

Wada ujawniła się w jednym ze sklepów z AGD - jedna z lodówek miała coś nie tak z układem filtrującym przy kompresorze i siała po sieci w momencie włączania (lub wyłączania nie pamiętam).

Bez analizy schematu i połączeń, położenia przewodów itp. źródła problemów zapewne łatwo nie znajdziesz.
Zrób rejestr i ... zaczekaj.

No dobrze wyświetlacz oberwie przepięciem i nie jest w stanie go zainicjować procesor bez wyłączenia mu zasilania. Ale sam procesor z programem musi wstać po resecie przez Watchdog? A nie wstaje.

Jak zrobić ten rejestr?

pier napisał:

Ale sam procesor z programem musi wstać po resecie przez Watchdog? A nie wstaje.

Na jakiej podstawie jesteś pewien, że nie wstaje?

pier napisał:

Jak zrobić ten rejestr?

Nie znam Twojego projektu, ale ja posługuję się tym co jest w danym projekcie wolne - UART, SPI, TWI, itp.

Gdy wolny jest UART dodaję Bluetooth (i dodatkowy mikrokontroler rejestrujący zdarzenia) umieszczony w drugim pomieszczeniu zasilany akumulatorem lub z innego zasilania.

Jeżeli wolny jest SPI lub TWI, to dodaję duży EEPROM lub FLASH.

Reszta to już tylko zapis danych według własnego uznania.

Cytat:

Na jakiej podstawie jesteś pewien, że nie wstaje?

Ponieważ po całym dniu bezczynności i rozpaleniu w piecu nie reaguje na wzrost temperatury i nie włącza pompy.

Mam w sterowniku opcję zapisu temperatur i czasu na karcie SD. Sprawdzałem tym sposobem do której godziny sterownik działał i było np tak że do godziny 24 były zapisy później nic i znów od 4 rano zapisywał.

a jak masz podłączone przekaźniki ? pokaż schemat /
Miałem to samo - raz wykrzaczał się LCD drugim razem atmega przestała działać mimo iż miałem na 101% porządnie zrobione zasilanie oraz układ gasikowy oraz zabezpieczenie przekaźników a raczej Uc przed przekaźnikami ! . Po wielu godzinach w kotłowni bo odziwo w warsztacie działało ok , doszedłem do 2 wniosków :
Atmega za blisko przekaźników " ekran z blachy troszkę pomógł .
zastosowanie triaków rozwiązało wszelkie problemy .

W życiu bym nie zastosował przekaźników.
Pompa i wentylator załączane są triakami.
Wiem że i triaki potrafią zakłócać ale nawet jeśli to i tak procesor powinien się podnieść po reszcie od Watchdoga.
Zresztą procesor się "zawiesza" tylko podczas bezczynności wtedy kiedy nic nie załącza.

Dlaczego przekaźniki nie - całe życie je stosuje czy to 8051 czy avr i jakoś nie miałem z nimi problemów ( i to przekaźniki z cewką na 5V ). Jak u Ciebie wygląda pin reset?, ile "ram-u" wykorzystuje program ( program z ram-em nie wchodzi na stos ), i najważniejsze jak masz rozwiązane zasilanie; jaki masz kwarc i kondensatory przy nim, i ostatnie pytanie jak idzie masa na pcb od tych kondensatorów przy kwarcu do masy up?.

Panowie prawdopodobnie znalazłem przyczynę dziwnych zachowań sterownika.
Nie chcę jeszcze zapeszać że to na 100% to ale Zerknijcie na tą linię kodu i powiedzcie czy może to być przyczyną:



To by potwierdzało moją teorię że przez poprzedni sezon sterownik działał poprawnie a w tym sezonie po "lekkich" moich poprawkach jest źle.

Tak jak myślałem. Po zmianie sterownik działa już kilka dni bez żadnych "zawiech".

Sterownik się już nie zawiesza ale nierozwiązana jest jeszcze kwestia błędnie wysyłanych danych.
Ktoś chętny pomóc?

pier napisał:

Sterownik się już nie zawiesza ale nierozwiązana jest jeszcze kwestia błędnie wysyłanych danych.
Ktoś chętny pomóc?

Ja, ale niestety język nie ten
Zastanów się nad zmianą na C, a wtedy będziesz miał znacznie lepsze wsparcie.

pier napisał:

(tu proszę z góry
nie komentować języka programowania i nie
namawiać na przejście na inny)

pier napisał:

pier napisał:

(tu proszę z góry
nie komentować języka programowania i nie
namawiać na przejście na inny)

Jak widzisz po braku odpowiedzi od 5 dni warto jednak się zastanowić nad jego zmianą, zamiast trwać przy wybranym języku.
Ale oczywiście Ty decydujesz ...