logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

AVR231 - Bootloader wpływa 'niechcący' na funkcje IO aplikacji

Karol966 16 Sie 2016 09:48 1158 14
REKLAMA
  • #1 15871531
    Karol966
    Poziom 31  
    Witam

    Od jakiegoś czasu używam bootloadera AVR231. Po pierwszych uruchomieniach zakończonych sukcesem programowałem układ klasycznie programatorem aby przyspieszyć fazę pisania programu. Niestety okazało się niedawno, że zaszyfrowany kod aplikacji po wgraniu przez bootloader nie obsługuje termometru DS18b20, który jest podłączony na tej samej linii IO, którą bootloader sprawdza w celu ewentualnego uruchomienia procesu uaktualnienia aplikacji. Co może być tego przyczyną? Aplikację z poziomu bootloadera uruchamiam chyba klasycznie:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Wszystko inne działa poprawnie tylko ta jedna linia PINB4 ma ciągle stan wysoki (tak jak od podciągniętego do zasilania wejścia). Na oscyloskopie widać w zasadzie stałą wartość z bardzo delikatnymi zakłóceniami. Zapewne zakłócenia, które widzę to transmisja 1-wire od czujników na sąsiednich liniach (4 czujniki ds18b20 - każdy na osobnej linii IO).

    Myślałem nad jakimś dodatkowym sposobem zerowania procesora jednak niezależnie czy coś dołożę do programu, pytanie brzmi dlaczego moja właściwa aplikacja sama nie panuje już nad tą jedną linią IO?
  • REKLAMA
  • #2 15871534
    excray
    Poziom 41  
    Pokaż swój kod.
  • REKLAMA
  • #3 15871540
    Karol966
    Poziom 31  
    Kod czego? aplikacji (obecnie kilka tysięcy linii) czy bootloadera (klasyczna nota avr231 z minimalnymi zmianami), napisz proszę co dokładnie Ci jest potrzebne bo chyba nie pytasz o samą konfigurację linii IO w obu programach - to było by zbyt proste ;)
  • #4 15871545
    excray
    Poziom 41  
    Karol966 napisał:
    napisz proszę co dokładnie Ci jest potrzebne bo chyba nie pytasz o samą konfigurację linii IO w obu programach - to było by zbyt proste ;)

    Dokładnie o to pytam. Chciałbym zobaczyć jak inicjujesz porty w swoim programie. Podaj też model procesora.
  • #5 15871563
    Karol966
    Poziom 31  
    Używam ATmega128
    // bootloader
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    No a sama aplikacja po nigdzie nie ustawia rejestrów tej linii gdyż robi to sama obsługa 1W.
  • REKLAMA
  • #6 15871573
    excray
    Poziom 41  
    Ale prawidłowa obsługa 1W polega zazwyczaj na sterowaniu linią DDRx przy założeniu, że linia PORTx jest wyzerowana. A u Ciebie nie jest.
  • #7 15871592
    Karol966
    Poziom 31  
    A skąd taki wniosek? Pozostałe linie działają bez zmian.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • Pomocny post
    #8 15871653
    excray
    Poziom 41  
    Zróbmy tak, żeby nie marnować mojego cennego czasu. Daj sobie pomóc i do funkcji RESET_PULSE() dopisz na samiuteńkim początku PORTB &= ~(1<<4);
  • #9 15871679
    Karol966
    Poziom 31  
    Wiesz co, po pierwsze dziękuję bo pomogłeś mi - jednak sprawa błaha się okazała.
    Wstawiłem tą linię na samym początku funkcji main. Teraz tylko pytanie dlaczego tak się dzieje, że mimo wszystko bootloader wpływa mi na aplikacje? Czy to jest tak, że skod do 0 licznika rozkazów nie kasuje ustawień rejestrów (wydaje mi sie,ze właśnie tak jest). No i dlaczego sama klasyczna obsług 1W nie poradziła sobie z konfiguracją tej linii? Czyżby zakładany jest zerowy/ domyślny stan początkowy?
  • REKLAMA
  • #10 15871687
    excray
    Poziom 41  
    Karol966 napisał:
    Czy to jest tak, że skod do 0 licznika rozkazów nie kasuje ustawień rejestrów

    Nie kasuje. To tylko skos pod adres. Kasuje tylko reset sprzętowy.
    Karol966 napisał:
    No i dlaczego sama klasyczna obsług 1W nie poradziła sobie z konfiguracją tej linii?

    Obsługa 1W nie poradziła sobie ponieważ w ogóle nie ingeruje w PORT. Zwróć uwagę, że co prawda wysyłasz do funkcji PORTB, ale sama funkcja RESET_PULSE i inne podstawiają to już pod DDR. Inne porty działały bo były wyzerowane przez reset. Ten akurat sam ustawiłeś na 1 włączając podciąganie. Dlatego trzeba uważać na takie kwiatki i zawsze mimo wszystko inicjować rejestry.
  • #11 15871695
    Karol966
    Poziom 31  
    Dzięki wielkie za pomoc, generalnie wyczułem gdzie leży problem ale jakoś potrzebowałem kogoś, kto za rączkę mnie poprowadzi dalej - za co raz jeszcze dzięki. Wszystko co piszesz się oczywiście zgadza.
    Dobrze myślę, że w zasadzie nie ma innego rozwiązania tego problemu? Mam na myśli to, że jeżeli bym zrobił twardy reset to i tak ponownie wystartuje pierwszy bootloader a nie aplikacja więc będzie błędne koło. Jest jakiś fajny sposób na przywrócenie stanów początkowych wszystkich rejestrów?
  • #12 15871714
    excray
    Poziom 41  
    Poza resetem, chyba tylko ręczne wklepywanie wartości początkowych. Generalnie jednak RESET jest najlepszą opcją.
  • #13 15871727
    Karol966
    Poziom 31  
    Pisząc RESET masz na myśli sprzętowy reset czy programowy poprzez zerowanie licznika rozkazów? Strzelam, że to 1 a wtedy przecież ponownie wystartuje sekcja bootloadera chyba, że po zostaną w niej zmienione fusebity a w aplikacji ponownie ustawione na start z obszaru bootsektora a nie aplikacji - zamotane ma maksa o ile w ogóle możliwe.
  • #14 15871768
    excray
    Poziom 41  
    Pisząc reset mam na myśli sprzętowy reset. Wywołujesz reset wykorzystując WDT po czym sprawdzasz po uruchomieniu programu w sekcji bootloadera co wywołało reset. Jeśli WDT to ignorujesz sprawdzanie czy wgrywanie programu tylko od razu skaczesz pod adres 0.
REKLAMA