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

Program na AT91SAM7 nie działa po ponownym uruchomieniu zasilania

andrzej_nied 12 Sie 2007 19:28 2065 3
REKLAMA
  • #1 4171428
    andrzej_nied
    Poziom 13  
    Posty: 134
    Ocena: 29
    Witam

    Od jakiegoś czasu używam kompilatora Crossworks for ARM (obecnie wersja 1.7), generalnie kompilator jest bardzo przyjazny i niczym nie ustępuje w stosunku do rozwiązań Keil-a czy IAR-a. Lecz niestety mam z nim pewien problem którego nie potrafię rozwiązać. Problem polega na tym że nie potrafię uruchomić programu z pamięci FLASH po załączeniu zasilania procesora. Gdy kompiluję program i wgrywam go do pamięci to wszystko jest OK natomiast po wyłączeniu i włączeniu zasilania programy wylatuje. Zaznaczam że kompiluję oprogramowanie w trybie ARM Flash Release. Używam firmowego programatora Wiggler zakupionego w firmie Propox. Wykonałem próbę weryfikacji programu po uprzednim wyłączeniu włączeniu zasilania i o dziwo programu tam nie było. Z reguły nie wierze w siły nadprzyrodzone ale coś w tym jest bo takiej sytuacji w całej mojej karierze zawodowej nie miałem.
    Za każdą sugestię i podpowiedz z góry dziękuję.

    Pozdrawiam

    Andrzej Niedworok
  • REKLAMA
  • #2 4172039
    shg
    Poziom 35  
    Posty: 2289
    Pomógł: 339
    Ocena: 135
    Nie znam za bardzo (praktycznie wcale tak właściwie) tego środowiska. Wszystko wskazuje jednak na to, że kod ładowany jest do pamięci RAM.
    Proponowałbym uważne przejrzenie wszystkich opcji.
    Może też to być wina linkera - sekcję z kodem umieszcza pod adresem mapowanym na RAM.
    Z tego co kojarzę, to Crossworks oparty jest na GCC, więc jeżeli na etapie kompilacji generowany jest plik .elf, to możesz podejrzeć, gdzie co ląduje.
    Polecenie objdump -h nazwa_pliku.elf, powinno wyświetlić adresy pod jakimi umieszczone są poszczególne sekcje (Ciebie interesuje .text). Z tym że to jeszcze może nic nie znaczyć, bo jeżeli z pliku .elf tworzony jest jakiś inny plik (np. .hex) za pomocą objcopy, który dopiero używany jest do programowania uC, to po drodze mogą zostać zmienione adresy sekcji (nowe adresy podaje się jako opcje dla objcopy).
  • REKLAMA
  • #3 4175640
    andrzej_nied
    Poziom 13  
    Posty: 134
    Ocena: 29
    Dziękuję za odpowiedz, już udało mi się rozwiązać ten problem. Okazało się że problem tkwił w konfiguracji preprocesora kompilatora Crossworks. Okazało się że należało w sekcji Preprocessor > Preprocessor Definitions wprowadzić dyrektywę STARTUP_FROM_RESET – i po sprawie. Tak się złożyło że wraz z rozwojem środowiska Crossworks ktoś zapomniał wprowadzić to ustawienie jako domyślne i stąd całe zamieszanie.

    PS Pozdrowienia dla kolegi SHG z Kędzierzyna Koźla, to miłe że ktoś z sąsiedniego miasta też zajmuje się tematyką ARM-ów, już myślałem że zostałem sam na tym polu.

    Andrzej Niedworok z Zalesia Śląskiego :-)
  • #4 4299460
    WWektor
    Poziom 12  
    Posty: 100
    Ocena: 57
    Mam podobny problem, ale niestety dopisanie STARTUP_FROM_RESET nic nie daje. Z ramu program uruchamia się bezbłędnie. Jak ustawię konfiguracje na ARM Flash Debug to program się kompiluje, wgrywa niby do flasha (takie są komunikaty) przyjmuje dyrektywę STARUP_FROM_RESET i się uruchamia bo procesor reaguje. Po wyłączeniu i włączeniu zasilania nic się nie dzieje - procek milczy i żadne resety itp mu nie pomagają :( Czy ktoś ma podobne problemy? Może jest na to jakieś proste rozwiązanie. Proszę o pomoc.
REKLAMA