Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

Karol966 16 Sie 2016 09:48 852 14
  • #1 16 Sie 2016 09:48
    Karol966
    Poziom 30  

    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
    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?

    0 14
  • #3 16 Sie 2016 09:54
    Karol966
    Poziom 30  

    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 ;)

    0
  • #4 16 Sie 2016 09:56
    excray
    Poziom 39  

    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.

    0
  • #5 16 Sie 2016 10:07
    Karol966
    Poziom 30  

    Używam ATmega128
    // bootloader

    Kod: 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.

    0
  • #6 16 Sie 2016 10:16
    excray
    Poziom 39  

    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.

    0
  • #7 16 Sie 2016 10:26
    Karol966
    Poziom 30  

    A skąd taki wniosek? Pozostałe linie działają bez zmian.

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • Pomocny post
    #8 16 Sie 2016 11:03
    excray
    Poziom 39  

    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);

    0
  • #9 16 Sie 2016 11:22
    Karol966
    Poziom 30  

    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?

    0
  • #10 16 Sie 2016 11:27
    excray
    Poziom 39  

    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.

    0
  • #11 16 Sie 2016 11:31
    Karol966
    Poziom 30  

    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?

    0
  • #12 16 Sie 2016 11:40
    excray
    Poziom 39  

    Poza resetem, chyba tylko ręczne wklepywanie wartości początkowych. Generalnie jednak RESET jest najlepszą opcją.

    0
  • #13 16 Sie 2016 11:48
    Karol966
    Poziom 30  

    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.

    0
  • #14 16 Sie 2016 12:17
    excray
    Poziom 39  

    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.

    0
  • #15 16 Sie 2016 12:20
    Karol966
    Poziom 30  

    Aaa, zapomniałem, że akurat można sprawdzić co wywołało reset. Dzięki - pobawię się tym tematem dalej.

    0