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

[Rozwiązano] ATMEGA64 - uP resetuje się podczas wychodzenia z funkcji.

narasta 10 Sty 2013 22:52 2280 18
  • #1 11771582
    narasta
    Poziom 21  
    Cześć, spotkałem się z dość dziwnym zachowanie (kompilatora bądź uP) mianowicie.

    Mając nawet jeden plik (np main.c) gdy wywołam przykładową funkcję q() to uP się resetuje podczas wychodzenia z niej - wykonuje to co jest w niej zawarte, ale podczas powrotu się wywala. Testowane z i bez optymalizacji. Zegar 11.0592.
    Projekt założony od nowa.

    AVRStudio5

    #define F_CPU 16000000
    
    #include <avr/io.h>
    
    #include "macros.h"
    
    void q(void)
    {
    	_0(PORTE,2);
    }
    
    int main(void)
    {
    	DDRE = 255;
    	PORTE = 255;
    	
    	q();
    	
    	_0(PORTE,3);
    	
    	while(1)
    	{
    	}
    
    	return 0;
    }


    #include "avr/io.h"
    
    #define _1(x,y) x |= (1<<y)
    #define _0(x,y) x &= ~(1<<y)
    #define _T(x,y) x ^= (1<<y)
    
    typedef unsigned char uchar;
    typedef unsigned int uint;
    
    #define false 0
    #define true 1


    Przyznam, że zgłupiałem. O co może chodzić?
  • #2 11771642
    BlueDraco
    Specjalista - Mikrokontrolery
    Np. o brak stosu - sprawdź rozmiar.
  • #3 11771778
    narasta
    Poziom 21  
    W jakim sensie sprawdzić. Gdyby ten sam kod a w zasadzie o wiele więcej wpisze się w maina to tam normalnie się kod wykonuje, ale wiadomo - nie o to chodzi.
  • #4 11771797
    BlueDraco
    Specjalista - Mikrokontrolery
    Sprawdź w ustawieniach projektu / linkera. Wygląda to na źle zainicjowany wskaźnik stosu albo stos o rozmiarze 0 (nie zaalokowany).

    Sprawdź też ustawienie typu procesora - od tego zależy lokalizacja stosu.
  • #5 11771801
    szulat
    Poziom 23  
    ciekawa sytuacja, bo chociaż objaw jest typowy dla przepełnienia stosu to jednak pokazany program przecież stosu nie przepełni :P

    ale kiedyś udało mi się zepsuć makefile tak że kompilowało się dla jednego procesora a dołączało startup code z parametrami innego i wtedy jakiekolwiek użycie stosu też powodowało katastrofę. pewnie jednak w AVRStudio nie da się tak zepsuć? na wszelki wypadek jednak sprawdź jakie polecenia są wykonywane w całym procesie kompilacji (jakiś log albo co).
  • #6 11771807
    mickpr
    Poziom 39  
    narasta napisał:
    Zegar 11.0592

    narasta napisał:
    #define F_CPU 16000000

    Ponadto - pokaż log z kompilacji (chodzi mi o #define - jaki to CPU?).

    Czasem IDE wykonuje za nas naprawdę "czarną robotę" - w sensie knoci wszystko, co możliwe.

    szulat napisał:
    pewnie jednak w AVRStudio nie da się tak zepsuć?

    Są na świecie rzeczy, o których się filozofom nie śniło.
  • #7 11771816
    narasta
    Poziom 21  
    Z zegarem to pomyka oczywiście. ma być 11.0592

    Procesor to mega64A - kompiluje pod m64, ale one się przecież nie różnią niczym.

    W proteusie się nie wywala.


    ------ Build started: Project: TAUm64, Configuration: Debug AVR ------
    Build started.
    Project "TAUm64.avrgccproj" (default targets):
    Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
    Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\AVR Studio 5.0\Vs\AvrGCC.targets" from project "c:\TAUm64\TAUm64.avrgccproj" (target "Build" depends on it):
    	Using "RunAvrGCC" task from assembly "C:\Program Files (x86)\Atmel\AVR Studio 5.0\Vs\AvrGCCLib.dll".
    	Task "RunAvrGCC"
    		C:\Program Files (x86)\Atmel\AVR Studio 5.0\AVR ToolChain\bin\make.exe all 
    		AVR Memory Usage
    		----------------
    		Device: atmega64
    		Program:     226 bytes (0.3% Full)
    		(.text + .data + .bootloader)
    		Data:          0 bytes (0.0% Full)
    		(.data + .bss + .noinit)
    	Done executing task "RunAvrGCC".
    Done building target "CoreBuild" in project "TAUm64.avrgccproj".
    Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
    Target "Build" in file "C:\Program Files (x86)\Atmel\AVR Studio 5.0\Vs\Avr.common.targets" from project "c:\TAUm64\TAUm64.avrgccproj" (entry point):
    Done building target "Build" in project "TAUm64.avrgccproj".
    Done building project "TAUm64.avrgccproj".
    
    Build succeeded.
    ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
  • #8 11771824
    mickpr
    Poziom 39  
    narasta napisał:
    ma być 11.0592
    czy może 11059200? Bądźmy szczegółowi :)
    A co jeśli skompilujesz z palca - i skąd wiesz, że się wywala przy powrocie? Masz jakiś debugger?
  • #9 11771829
    narasta
    Poziom 21  
    Debbugera nie mam.

    We wcześniejszym poście wrzuciłem loga
  • #10 11771870
    BlueDraco
    Specjalista - Mikrokontrolery
    całkowita zajętość pamięci RAM wynosi 0! A stos gdzie?
  • #11 11771875
    mickpr
    Poziom 39  
    BlueDraco napisał:
    całkowita zajętość pamięci RAM wynosi 0! A stos gdzie?

    Kolega dobrze zauważył - w opcjach projektu (patrzę w Atmel Studio 6.0, więc może się różnić) - masz zakładkę (w ustawieniach linkera) Memory Settings... Pewnie niewypełnioną.
  • #12 11771879
    narasta
    Poziom 21  
    Hm, no rzeczywiście - nie zwróciłem uwagi.

    U mnie zakładka ta wygląda tak:

    ATMEGA64 - uP resetuje się podczas wychodzenia z funkcji.



    Kiedyś kompilowałem już w AVRstudio5 z resztą pod m128. Było sporo kodu. Headerów i sourceów masa i chodziło. W sumie robiłem to na innym komputerze - cholera wie co się podziało podczas instalacji tutaj...

    Edit.

    ATMEGA64 - uP resetuje się podczas wychodzenia z funkcji.

    Hm... COś tu jest chyba nie tak z tym AVS5.0... Chyba czas wrócić do poczciwego i sprawdzonego 4.0
  • #13 11771904
    mickpr
    Poziom 39  
    Jednak nie znam się na tym dziwnym środowisku. Domyślne wartości powinny być wystarczające.
    W Eclipse i i AVR Studio 4 nigdy nie miałem z tym problemu.
  • #14 11771909
    narasta
    Poziom 21  
    Zgadnijcie co - oczywiście wszytko działa tak jak trzeba pod 4.0...

    Nie dość, że AVS5.0 ładuje się długo, kompiluje większy kod niż WINAVR (w przypadku 4.0) i do tego jeszcze nie działa wygenerowany kod. To przechodzi ludzkie pojęcie
  • #15 11771914
    mickpr
    Poziom 39  
    Ciekawostką jest fakt - że ten AVR simulator się po prostu sypie. Właśnie zarządał mi biblioteki
    C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\gcc\gcc\config\avr\libgcc.S
    jakby rodem z linux'a....
    Oczywiście takiego katalogu u mnie brak.

    Wygląda, że przeszkadza mu drugi toolchain :)

    Ja wiem - kiepskiej baletnicy rąbek u spódnicy przeszkadza.... ale nie lubię jak mi coś na dzień dobry się wykrzacza.
    A miało być tak pięknie (AS 6.0).


    W ogóle - skoro jest IDE, to po kiego grzyba pakować coś do przeciążonej zmiennej PATH. Wszak IDE ma to załatwiać, aby wybierany był domyślnie odpowiedni toolchain, prawda?
    W przeciwnym bądź razie - po co to IDE - jako "koloryzator kodu"?

    Jakoś w przypadku ARM-ów każde (z moich pozostałych IDE) sobie rzepkę skrobie.
    I się nie gryzą.
  • #16 11771952
    narasta
    Poziom 21  
    No wiesz - mi przeszkadza niedziałający kod jednak...

    W każdym bądź razie - w 4.0 nie wywala się, ale jeśli przeniesie się funkcje do zewnętrznego pliku source to znowu się wywala...

    Po dalszych próbach...

    Wpisuje komendę USART_Tx('a') - pojawia się 'a' w konsoli
    Wpisuje komendę USART_Tx('a' + 2) - zamiast 'c' pojawiają się krzaki... Już nic nei rozumiem... Nic dziwnego, że uP ma problem z wyjściem z subrutyny skoro nawet nie może dodać.

    Co się dzieje w tym maleńkim rdzeniu?! :P

    Czas stestować inny egzemplarz uP, albo przejść na m128, bo tam wszytko działało- nawet XRAM.
  • #17 11774694
    narasta
    Poziom 21  
    Ostatecznie wlutowałem inny egzemplarz i zaczęło to w końcu działać.

    Dziwne, że ten pierwszy uP się wysypał...
  • #18 11774847
    tmf
    VIP Zasłużony dla elektroda
    Po pierwsze sprawdź fusebity - szczególnie fusebit kompatybilności z M103. Tu pewnie leży pies pogrzebany - M103 (domyślnie tak M64 jest sprzedawany) ma inną wielkość przestrzeni IO i w związku z tym inny początek i koniec SRAM. W efekcie jeśli w projekcie wybierasz M64 bez skasowania tego fusebitu to objawy będą takie jak opisujesz.
    Poza tym AVR Studio 5 to wersja beta, dlaczego jej używasz? Wersją finalną jest AVR Studio 5.1 lub Atmel Studio 6. Różnice są istotne, bo jest tam zupełnie inny toolchain.

    Do mickpr: Ta ścieżka (C:\home\tools\hudson\workspace\avr8-gnu-toolchain\src\gcc\gcc\config\avr\libgcc.S) to ścieżka do pliku źródłowego liblioteki. Nie jest to wina IDE - kompilator umieszcza w czasie kompilacji informacje dla debuggera, a IDE tylko z nich korzysta. Jeśli ktoś nie wystripował biblioteki to takie odnośniki będą. W ogóle nie jest to żaden błąd, po prostu przerwałeś kod w chwili wywoływania funkcji bibliotecznej i tyle. A że nie ma dla niej dostępnych źródeł, to pewnie przeniósł cię do okna disasemblacji, bo co miał innego zrobić?
    Co do PATH - niestety toolchain wymaga, aby pewne definicje były w path, dzięki temu niektóre komponenty toolchaina mogą znajdować inne. Tak jest pod Windows, podobnie jest po linuxem, tyle, że nie korzysta z path, tylko zmiennycvh o innych nazwach, ale wychodzi na jedno. To znowu nie wina IDE.
  • #19 20563693
    Szycha082
    Poziom 11  
    Witam, po latach lecz problem dalej aktywny. Trzy dni szukałem przyczyny resetowania się procka, dopiero tu znalazłem odpowiedz :) faktycznie ten tryb kompatybilności M103C wszystko psuje... nie wiem po co to wprowadzali.
REKLAMA