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

[STM32][eclipse z CodeSourcery]błedna kompilacja programu do komunikacji USB HID

30 Cze 2012 14:08 7429 38
  • Poziom 10  
    Witam,
    Piszę o pomoc z nietypowym problemem dotyczącym mikrokontrolera stm32f103vct6.
    Ściągnełem demo ze strony stm do obsługi usb HID i teraz napisze kroki które wykonałem:
    1. odpaliłem demo w Keil i wszystko elegancko działa
    2. odchudziłem i wrzuciłem do eclipsa (projekt c i c++, gdzie c++ musiałem lekko zmodyfikować)i tu zaczyna się problem, wszystko ładnie się kompiluje ale po wgraniu i podłączeniu do komputera, komputer nie może rozpoznać urządzenia
    "stan urządzenia - System Windows zatrzymał to urządzenie z powodu zaraportowanych problemów. (Kod 43)"
    3. identyczne pliki wrzuciłem do Keil i wszystko działa.

    Zauważyłem, że plik z rozszerzeniem .hex który wgrywam wygenerowany z Keil ma 30KB, a z eclipsa 14KB, ciekawe.
    Eclipse :
    Version: Indigo Service Release 2
    Build id: 20120216-1857
    z CodeSourcery
    System Windows 7 sp1.

    Środowisko skonfigurowane ze strony:
    http://tutro.net/elektronika/integracja-eclipse-cdt-z-codesourcery-dla-arm-cortex-m3/

    Według mnie przyczyną jest plik startup i linker, również te pliki zamieniałem na startup z stm i linker z Atollic lecz problemu to nie rozwiązało.

    Załączam projekty z eclipse i keil.

    Z góry dzięki za pomoc.
  • Computer ControlsComputer Controls
  • Pomocny post
    Specjalista - Mikrokontrolery
    Problem to jest taki, że keil nie spełnia standardów języka C dotyczących kilku całkiem istotnych spraw. Jeśli kod o którym mówisz jest tym samym o którym myślę (nie chce mi się ściągać 14MB, bo pewnie wrzuciłeś tam pliki bin, elf i nie wiadomo jakie jeszcze zupełnie nie potrzebne do niczego) to w kodzie Keila jest mnóstwo operacji typu:

    Kod: C
    Zaloguj się, aby zobaczyć kod


    Przykłady rzeczywiste kodu z którym kompilator spełniający jakieś standardy niezbyt sobie poradzi:
    *((__packed DWORD *)pData) = RX_DATA;
    TX_DATA = *((__packed DWORD *)pData);
    (BYTE *)pD += ((USB_CONFIGURATION_DESCRIPTOR *)pD)->wTotalLength;

    Dwa pierwsze to dokładnie to o czym pisałem wcześniej, ten ostatni to też niezła ekwilibrystyka, którą kompilator GCC niezbyt trawi (required lvalue as left operand).

    Jeszcze kilka takich "smaczków" tam jest (sprawa zwykle rozbija się o wyrównanie zmiennych), kod trzeba dosyć solidnie zmodyfikować żeby działał w jakimś normalnym kompilatorze. Co prawda ja modyfikowałem kod przeznaczony dla ARM7, ale z dużym prawdopodobieństwem "rdzeń" stosu USB HID jest dokładnie taki sam.

    max7532 napisał:
    Według mnie przyczyną jest plik startup i linker, również te pliki zamieniałem na startup z stm i linker z Atollic lecz problemu to nie rozwiązało.

    Dobrze choć, że nie podejrzewasz błędu kompilatora... Nie wiem w jaki sposób skrypt linkera (dobry) mógłby stanowić JAKIKOLWIEK problem dla zwyczajnego kodu jakim jest stos usb hid? Tak samo startup - to że ten z Keila robi 1000 rzeczy, które musisz sobie teraz zrobić sam (ustawienie PLL i tym podobne sprawy) nie znaczy że problemem jest startup - problemem są założenia.

    max7532 napisał:
    Eclipse :
    Version: Indigo Service Release 2
    Build id: 20120216-1857
    z CodeSourcery
    System Windows 7 sp1.

    Spróbuj to skompilować z użyciem notatnika i Windows XP - wtedy na pewno działa... Sorry, ale co to ma do rzeczy jakiego używasz systemu operacyjnego i jakiego edytora? Może podaj jeszcze jaką masz wersję Adobe Flasha... Dobrze że napisałeś choć, jakiego kompilatora używasz... a nie czekaj - nie napisałeś, bo przecież CS wydawany jest co pół roku, więc przez ostatnie kilka lat było już z 10 wersji, w praktycznie każdej inna wersja GCC.

    4\/3!!
  • Poziom 10  
    Dzięki bardzo za pomoc, nie brałem tego pod uwagę ze względu na to że kompilator nie wyrzucał mi żadnych błędów, a nawet zastrzeżeń. Od dzisiaj zaczynam przerabiać cały kod.
    A jeżeli chodzi o informacje dotyczące systemu operacyjnego, to trochę źle to sformułowałem, bo miałem na myśli, że płytkę z stm testowałem na windows 7.
    Wolałem napisać więcej informacji, ze względu na to że dopiero co uczę się pracy w eclipse i nie wiedziałem jakiego typu to jest problem.
    Jeszcze raz dzięki za pomoc.
  • Computer ControlsComputer Controls
  • Specjalista - Mikrokontrolery
    Zacznij od tego, że z main() wywołujesz Set_System(), które w komentarzu ma napisane coś takiego:
    Cytat:
    /*!< At this stage the microcontroller clock setting is already configured,
    this is done through SystemInit() function which is called from startup
    file (startup_stm32f10x_xx.s) before to branch to application main.
    To reconfigure the default setting of SystemInit() function, refer to
    system_stm32f10x.c file
    */

    Co nie jest prawdą, bo startup który tam masz nie robi nic ponadto co robić musi... Wywołaj więc na początku maina tą funkcję SystemInit(), to już będziesz o krok bliżej.

    4\/3!!
  • Poziom 10  
    Sorry, że tak późno odpisuje, ale chciałem trochę poczytać zamiast coś bezsensu napisać.

    Rzeczywiście, już to zrobiłem, a mam takie pytanko mógłbyś mi powiedzieć z którymi częściami kodu z niżej wymienionych kompilator może mieć problem:

    1.
    Kod: c
    Zaloguj się, aby zobaczyć kod

    co przekierowuje do :
    Kod: c
    Zaloguj się, aby zobaczyć kod


    2.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    3.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    4.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    5.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    6.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    7.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    8.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    9.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    10.
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Starałem się wyszukać niespotykane za często dla mnie zapisy.

    A jeśli chodzi o te przykłady, które podałeś, niepoprawne dla kompilatora gcc to znalazłem tylko 9.
  • Pomocny post
    Specjalista - Mikrokontrolery
    Z tego co wymieniłeś wszystko jest OK (zakładam, że 3. to wskaźnik na funkcję, a nie jakieś dziwne rzutowanie).

    Ja bym się jednak początkowo skupił na zainicjalizowaniu w main() wszystkiego co inicjalizuje Keil w startupie, czyli po prostu wywołaniem SystemInit() - jeśli to zrobiłeś to następnym krokiem będzie zastanowienie się, czemu kod w Keilu generuje 30kB hexa, a w GCC 2x mniejszego - powinno być z grubsza tyle samo (tylko ustaw optymalizację na taki sam poziom, najlepiej początkowo na 0, w obydwóch kompilatorach ustaw tak samo kwestię kasowania nieużywanego kodu i danych).

    4\/3!!
  • Poziom 10  
    Dobra, zmieniłem optymalizację na None(-O0) (teraz jest taka sama jak w Keil) i mam już 29KB, pierwszy postęp.

    Z ciekawości podstawiłem startup od stm (żeby był ten sam co ma Keil)i linker od Atollic i hex ma 50KB, dziwne, jak oglądałem hexa to przez prawie cały kod były "-". Po wrzuceniu do procesora problem jest ten sam.

    Robiłem też taką kombinację że startup od stm oraz linker od Ciebie, lecz wtedy wyrzuca kompilator problem
    make: ***[nazwa.elf] Error 1

    Również robiłem że startup od Ciebie, oraz linker od Atollic i dostaje dużo błędów, lecz zrozumiałych. Ten przypadek zrobiłem z ciekawości, lecz wydaje mi się że nie ma sensu nad nim siedzieć i poprawiać te błędy, bo tak jak wcześniej mówiłeś problem może być w tym że czegoś brakuje w startup, a co jest w startup od stm, co również podzielam.
  • Specjalista - Mikrokontrolery
    startup jest sprzężony z linkerem poprzez nazwy początków i końców sekcji oraz parametry stosów - takie podmiany niezbyt są możliwe... Ale naprawdę nie szukaj problemu w tych dwóch plikach, bo tam go nie ma.

    4\/3!!
  • Poziom 10  
    tracę już pomysły, przed chwilą żeby się upewnić jeszcze raz zamieniłem wszystkie pliki z Eclipse na pliki z Keil. Sprawdziłem jeszcze raz w Keil (specjalnie wrzucałem program przez bootloader, czyli tak samo jak wrzucam z Eclipse) wszystko działa, a w eclipse nie, ciągle ten sam problem.
    Skoro nie jest to problem plików, oraz startup i linkera, to w czym może być problem? Masz może jeszcze jakiś pomysł?
  • Specjalista - Mikrokontrolery
    Mnie się średnio podobają takie rzeczy:

    USB_OTG_WRITE_REG32( fifo, *((__packed uint32_t *)src) );

    w GCC to może nie działać prawidłowo - trzeba by debuggerem sprawdzić czy wynik jest taki sam (ewentualnie zobaczyć czy wygenerowane rozkazy są takie same lub równoważne). Tyle że ta funkcja (OTGD_FS_WritePacket) niekoniecznie wchodzi do pliku wynikowego...

    Swoją drogą - kolejna rzecz - czy jesteś pewien, że masz ustawione w GCC te same definicje preprocesora co w Keilu? Pliki żródłowe najeżone są fragmentami kompilowanymi warunkowo... Na moje oko jest tak samo, ale mogę się mylić...

    4\/3!!
  • Poziom 10  
    Rozumiem, to co wtedy wrzuciłem to były projekty "ogólne", od tego czasu trochę uściśliłem je, takie rzeczy jak ta o której piszesz nie występują już w tych bibliotekach(a przynajmniej większość, lecz nawet jeżeli są to znajdują się w sektorach niekompilowanych.
    Sprawdzałem jeszcze raz definicje preprocesora, są takie same.
    W razie czego wrzucam aktualny projekt i pliki źródłowe do niego.
  • Poziom 10  
    Witam,
    Ostatnio miałem trochę mało czasu żeby się zająć tą sprawą, lecz teraz z powrotem wracam do tematu.
    Uruchomiłem debugowanie dzięki tutorialowi napisanemu przez Freediego (jeżeli chodzi o tutorial, to super, wszystko ruszyło za pierwszym razem :) )
    Będę omawiał przejścia tylko te które prowadziły do problemu.
    I debugowanie wygląda tak, zaczynamy w main (pomijając startup)
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Następnie wchodzimy w USB_Init();

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Następnie w pProperty->Init(); co prowadzi do CustomHID_init()
    Kod: c
    Zaloguj się, aby zobaczyć kod

    I w tym momencie dochodzimy do USB_SIL_Init(); po próbie wejścia program zaczyna coś wykonywać ( żeby mnie źle nie zrozumieć, opcję step into itp. znikają i jedyne co mogę zrobić to suspend lub terminate)
    Oczywiście wybieram suspend i w tym momencie przechodzę do __Default_Handler(void)
    Oraz w konsoli otrzymuję (załączę całą konsolę, według mnie nie trzeba jej całej, ale tak na wszelki wypadek)
    Kod: c
    Zaloguj się, aby zobaczyć kod

    [Kod z konsoli mam w C, żeby mi się ładnie zwinęło.]



    Przeszukując pliki znalazłem ciekawą sprawę, a mianowicie w pliku vectors.c napisanym przez Freediego jest (fragment)
    Kod: ASM
    Zaloguj się, aby zobaczyć kod

    oraz :
    Kod: ASM
    Zaloguj się, aby zobaczyć kod


    a w startupie od stm jest:
    Kod: ASM
    Zaloguj się, aby zobaczyć kod


    oraz :

    Kod: ASM
    Zaloguj się, aby zobaczyć kod


    Po zmianie tego tak jak od stm kod wynikowy w hex wynosi 45kB (bez tej zmiany 27kB).
    Urządzenie tak samo jest nierozpoznawalne, a przy debugowaniu program po wejściu do funkcji USB_SIL_Init(); (zaczyna pracować, tak jak wcześniej i po wciśnięciu suspend) trafia do HardFault_Handler(), oraz konsola nie wypisuje żadnego błedu(jest pusta).

    Próbowałem też zmienić w stm32f10x_it.c :
    Kod: c
    Zaloguj się, aby zobaczyć kod


    na

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Lecz oprócz tego że końcowy kod wynikowy ma 45kB, urządzenie dalej nie jest wykrywane przez komputer, a przy debugowaniu również trafia do HardFault_Handler().

    Ma ktoś może jakiś pomysł czym może to być spowodowane, lub co jeszcze mógłbym zrobić, żeby lepiej dowiedzieć się jaki to błąd?

    [EDIT]
    Zapomniałem jeszcze dodać co jest w funkcji USB_SIL_Init(); wygljąda ona następująco:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    i właśnie przy funkcji _SetISTR(0); przechodzi do __Default_Handler(void)

    oraz dodaję _SetISTR(0); w disassembly
    Kod: asm
    Zaloguj się, aby zobaczyć kod
  • Pomocny post
    Poziom 38  
    max7532 napisał:
    Ściągnełem demo ze strony stm do obsługi usb HID i teraz napisze kroki które wykonałem:


    Trochę mnie to dziwi, ponieważ ST udostępnia bibliotekę do USB nie mającą nic wspólnego z Keilem. Ja ją kiedyś ściągnąłem i przykłady jakie w niej były po przerobieniu na nieużywanie fwlib ruszały od kopyta w gcc. Czyżbyś ściągnął USB HID Demonstrator Release 1.0.2 ?
  • Specjalista - Mikrokontrolery
    Masz jakoś zdefiniowany rozmiar stosu dla przerwań? Jeśli korzystasz z mojego skryptu linkera, to w pliku tym musisz sobie zdefiniować jaki jest rozmiar stosu, bo bez tego przerwania się sypią.

    4\/3!!
  • Poziom 10  
    Rzeczywiście, wypisuje błąd związany z pamięcią stosu.

    Na początku zmieniam w linkerze :
    __main_stack_size = 4096; na __main_stack_size = 2048;
    błąd w konsoli w tym samym miejscu co wcześniej.
    Kod: c
    Zaloguj się, aby zobaczyć kod


    A później z powrotem na __main_stack_size = 4096; konsola ukazuje :
    Kod: c
    Zaloguj się, aby zobaczyć kod

    (trochę dziwne dla mnie bo wcześniej przy tych samych opcjach wyświetlały się inne błędy)


    Następnie (w linkerze) ustawiam __main_stack_size = 2048; oraz zamieniam :
    Kod: c
    Zaloguj się, aby zobaczyć kod


    na

    Kod: c
    Zaloguj się, aby zobaczyć kod


    oraz w vectors.c zamieniam :
    Kod: c
    Zaloguj się, aby zobaczyć kod


    na

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Dzięki temu przy debugowaniu w tym samym punkcie program przechodzi do __Default_Handler(void) lecz już konsola nie wypisuje błędów

    Możecie powiedzieć mi czy dobrze zabrałem się za to?

    Dodano po 21 [minuty]:

    gaskoin : tak ściągnąłem USB HID Demonstrator Release 1.0.2, ale wydaje mi się że raczej nie ma to znaczenia, bo przed włączeniem tego programu komputer nie wykrywa urządzenia.
  • Specjalista - Mikrokontrolery
    1. Błędy o których piszesz (sticky error) są nieistotne i nie należy się nimi przejmować)
    2. Jeżeli używasz mojego startupu, to tam układ przestawiany jest na używanie DWÓCH stosów - osobnego dla przerwań, osobnego dla reszty kodu. No i teraz masz ustawiony jeden z tych stosów na 0, więc w końcu się to sypnie. Jak ściągniesz nowszą wersję przykładu, to znajdziesz tam taki komentarz:

    Cytat:
    /* Handler mode (core exceptions / interrupts) can use only main stack */
    /* Thread mode can use main stack (default) or process stack - selected in CONTROL special register */

    __main_stack_size = 0;
    __process_stack_size = 1024;

    PROVIDE(__main_stack_size = __main_stack_size);
    PROVIDE(__process_stack_size = __process_stack_size);


    3. Naprawdę nie rób "soft_reset_halt" w OpenOCD, bo ta komenda to same problemy.

    4\/3!!
  • Poziom 38  
    Twoje zmiany są bez sensu i wprowadzą tylko dodatkowe komplikacje. 4kb stosu powinny wystarczyć.

    max7532 napisał:
    gaskoin : tak ściągnąłem USB HID Demonstrator Release 1.0.2, ale wydaje mi się że raczej nie ma to znaczenia, bo przed włączeniem tego programu komputer nie wykrywa urządzenia.


    Wielu już tak myślało :D Tak myślałem. Ściągnij więc http://www.st.com/internet/com/SOFTWARE_RESOU...OMPONENT/FIRMWARE/stm32_usb-fs-device_lib.zip to jest biblioteka USB od ST i nie ma tam cudów, które działają tylko w Keilu i są też przykłady użycia, między innymi jest HID który działa z coudesourcery. Ja nie używam fwlib więc było trochę zabawy żeby się tego pozbyć z przykładów.
  • Poziom 10  
    Freddie Chopin : uaktualniłem startup oraz linker (od Ciebie) ustawiłem :
    __main_stack_size = 1024;
    __process_stack_size = 1024;
    i dalej ten sam problem, przy uruchamianiu oraz przy debugowaniu.

    gaskoin : zaraz zabiorę się za wrzucenie projektu do Eclipse

    i wtedy pokombinuję ze stosami
  • Poziom 10  
    Udało mi się wrzucić do Eclipse po małych obróbkach.

    Problem nie zniknął,
    Przy debugowaniu mam bardzo dużo problemów, albo dostaję taki błąd:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    albo taki błąd:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Kod: c
    Zaloguj się, aby zobaczyć kod


    lub też : No source available for ""

    a czasami od razu przechodzi do __Default_Handler()

    Albo wskakuję na początek main() i stamtąd nie mogę dalej wyjść cokolwiek nie zrobię stoję jednej linijce(pierwszej).

    Raz na chyba 20 razy udało mi się przejść jak wcześniej i wystąpiła taka sama sytuacja.

    Najgorsze w tym wszystkim to, że we wcześniejszej wersji jest tak samo.

    Dodano po 35 [minuty]:

    Ok, udało mi się powrócić do "normalnego" debugowania, nie wiem już sam czy dobrze robię ale dodałem "soft_reset_halt" i z powrotem jest w porządku.
  • Specjalista - Mikrokontrolery
    Nie nie nie nie nie... Ludzie - skąd wy bierzecie ciągle tą komendę "soft_reset_halt"?

    Czemu nie można po prostu zrobić "reset halt" tylko ciągle soft_...? Jak Ci nie działa normalne reset halt, to dodaj może do wywołania OpenOCD coś takiego:
    -c "reset_config trst_and_srst"

    4\/3!!
  • Poziom 10  
    Ok, jest sukces !! Może nie ostateczny ale jakiś jest.W miejscu gdzie wcześniej wpadał do __Default_Handler() teraz przechodzi do USB_LP_CAN_RX0_IRQHandler(void)

    Podsumuję wszystko co zrobiłem:
    Nie wiem do końca co dokładnie powodowało ten problem, napisze wszystkie kroki które wykonałem, aby wpadał do danego przerwania:

    1. Aktualizacja vectors.c , startup.S , STM32F103xB_rom.ld oraz hdr_special_registers.h od kolegi Freddie Chopin

    2. wrzucenie biblioteki V3.4.0 do Eclipse, dzięki koledze gaskoin

    3. zmiana rozmiarów stosów ( ustawione na 1024)

    4. ustawienie nazw przerwań takich samych w vectors.c oraz stm32_it.c (wcześniej się różniły)

    5. ustawienie "reset halt" zamiast "soft_reset_halt" w debugowaniu

    Jednak dalej urządzenie nie jest wykrywane poprawnie.
  • Poziom 38  
    To już chyba wina złych deskryptorów lub ogólnie złej obsługi USB. Jak wchodzi w przerwanie od USB tzn, że program działa ok, ale coś w obsłudze/deskryptorach pokopałeś.
  • Poziom 10  
    Tylko, że nie zmieniałem ani jednego deskryptora, w keilu testowałem program na tych samych deskryptorach i było ok.
  • Poziom 38  
    Zaraz zaraz, dorzuciłeś bibliotekę, ale czy uruchamiasz przykład Custom HID czy dalej korzystasz z tego cudu, który ściągnąłeś wcześniej ?
  • Poziom 10  
    Trochę źle napisałem, wrzuciłem wszystkie pliki z Custom HID od Ciebie.
  • Poziom 10  
    Ok, więc sprawa wygląda tak: program wpada w przerwanie lecz urządzenie nie jest nadal rozpoznawane przez komputer.

    Wielkości stosów zostały ustawione na 4096.

    Podczas debugowania tego samego kodu przez keila i Eclipse znalazłem gdzie jest problem, wyglądał on dość łatwy, dopóki nie

    zacząłem go rozwiązywać, a dokładniej do teraz nie mogę go rozwiązać.

    Dotyczy zmiennej "wInterrupt_Mask". Wygląda on następująco.

    Przedstawię wszystkie funkcje prowadzące do niego:

    Zaczynamy od main() :

    Kod: c
    Zaloguj się, aby zobaczyć kod


    następnie idziemy do void USB_Init(void);

    Kod: c
    Zaloguj się, aby zobaczyć kod


    później pProperty->Init(); co prowadzi do void CustomHID_init(void);

    Kod: c
    Zaloguj się, aby zobaczyć kod


    oraz następnie do PowerOn();

    Kod: c
    Zaloguj się, aby zobaczyć kod


    I w tym miejscu jak widzimy pierwszy raz zmiennej wInterrupt_Mask przypisana jest wartość równa 0.
    Idąc dalej zmiennej wInterrupt_Mask zostaje przypisana zmienna 0x1C00 na podstawie stałych "CNTR_RESETM | CNTR_SUSPM |
    CNTR_WKUPM"

    po funkcji PowerOn(); następuje funkcja USB_SIL_Init(void) i wygląda ona następująco:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Rozpisuję to bardzo dokładnie dlatego że w USB_SIL_Init() znajduje się przypisanie wartości wInterrupt_Mask = IMR_MSK;

    które wynosi 0xBF00

    Wartość ta określa do jakich konkretnie if (poniżej w przerwaniu) będzie wpadał program :

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Gdzie USB_Istr(); wygląda następująco :

    Kod: c
    Zaloguj się, aby zobaczyć kod



    Program w Keilu trafia do tych if :
    if (wIstr & ISTR_RESET & wInterrupt_Mask)
    if (wIstr & ISTR_ERR & wInterrupt_Mask)
    if (wIstr & ISTR_SUSP & wInterrupt_Mask)
    if (wIstr & ISTR_SOF & wInterrupt_Mask)
    if (wIstr & ISTR_ESOF & wInterrupt_Mask)

    Natomiast program w Eclipse trafia tylko do
    if (wIstr & ISTR_RESET & wInterrupt_Mask)


    W Keilu i Eclipse :
    wIstr 0x0F00 0b0000 1111 0000 0000

    oraz

    ISTR_RESET 0x0400 0b0000 0100 0000 0000
    ISTR_ERR 0x2000 0b0010 0000 0000 0000
    ISTR_SUSP 0x0800 0b0000 1000 0000 0000
    ISTR_SOF 0x0200 0b0000 0010 0000 0000
    ISTR_ESOF 0x0100 0b0000 0001 0000 0000

    tylko w Keilu
    wInterrMask 0xBF00 0b1011 1111 0000 0000

    natomiast w Eclipse:
    wInterrMask 0x04A5 0b0000 0100 1010 0101

    (Dzięki temu rozpisaniu stałych i zmiennych widać do których if wpada program)

    Najciekawsze w tym wszystkim jest to, że "wInterrMask" zostaje przypisane 0 lub 0x1C00 w funkcji RESULT PowerOn(void)
    lub 0xBF00 w funkcji USB_SIL_Init()

    To skąd się bierze ta wartość 0x04A5 ?

    Próbowałem również zrobić przypisanie wInterrMask 0xBF00 na początku funkcji void USB_Istr(void) żeby wpadał w te ify w które wpada program w keilu, i tak się stało, program przeszedł w tym miejscu tak samo jak keil, lecz na końcu przerwania

    wysypał się wpadając do HardFault();


    Później debugowałem w ten sposób że ustawiłem sobie 3 breakpointy i 2 zmienne które mi się wyświtlają:

    Breakpointy:


    void USB_LP_CAN1_RX0_IRQHandler(void)
    {
    USB_Istr(); <----- 1 BREAKPOINT
    }

    void USB_Istr(void)
    {
    wIstr = _GetISTR(); <---- 2 BREAKPOINT

    if (wIstr & ISTR_CTR & wInterrupt_Mask) <---- 3 BREAKPOINT
    {
    /* servicing of the endpoint correct transfer interrupt */
    /* clear of the CTR flag into the sub */
    CTR_LP();
    }

    ...
    }

    1 BREAKPOINT:
    wIstr = 0; <- w tym miejscu jeszcze wIstr nie uaktualniło się, więc Ok
    wInterrupt_Mask = 0xBF00 <- wartość jak w Keilu

    2 BREAKPOINT
    wIstr = 0; <- dalej jeszcze wIstr nie uaktualniło się, więc Ok
    wInterrupt_Mask =0x04A5 <- Skąd to się bierze ?

    3 BREAKPOINT
    wIstr = 0x0F00; <- wartość aktualna, jak w Keilu, więc Ok
    wInterrupt_Mask =0x04A5 <- A tu zostaje już ta której nie znam


    Wie ktoś może czemu tak się dzieje i skąd ta wartość się bierze ?
    Może ma ktoś pomysł na to jakie testy mógłbym jeszcze wykonać ?
  • Poziom 38  
    Nie schodziłbym tak nisko.

    Pokaż plik hw_config.c i najlepiej schemat połączenia gniazda usb z prockiem.
  • Poziom 10  
    hw_config.c trochę przerobiony żeby usunąć zbędne define, dla pewności wrzuciłem go do Keil i wszystko działa.


    Kod: c
    Zaloguj się, aby zobaczyć kod
  • Specjalista - Mikrokontrolery
    Możesz sobie postawić watchpointa na zapis do tej zmiennej, to zobaczysz kiedy zmienia się jej zawartość.

    4\/3!!
  • Poziom 38  
    Ciężka sprawa, trudno grzebać w kodzie jak w jednym programie się kompiluje a w drugim coś nie chce :D

    Możesz jeszcze zerknąć w opcje kompilatora czy jest dobrze wywoływany (przykład jest najeżony ifdefami, może przez to się coś wysikało?)... Upewnij się też, że kody są na bank te same.

    Mogę Ci tylko poradzić tyle co Freddie - jedź linijka po linijce i sprawdź gdzie i dlaczego się wysypuje kod w Eclipsie.