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

Dziwne zachowanie atmega32

flapo213 29 Lis 2008 19:55 1714 9
  • #1 5798404
    flapo213
    Poziom 21  
    Witajcie.

    Mam do napisanie w sumie prosty sofcik do atmegi 32 ale napotkałem problem nie do przeskoczenia. Otóż mam do procka podpięty na nóżkach PINA.6 i PINA.7 i2c z zewnętrznym podwieszeniem 3.3k do 5V. Problem polega na tym że jak próbuję coś odczytać to soft się wysypuje przy próbie zapisu adresu to znaczy wywala go poza adres flasha. Problemu nie ma na atmedze16. Nie kapuję co jest nie tak. Korzystam z gcc 4.2.2 ale i na 4.3.0 to samo się dzieje pod windowsem i pod linuxem identyczny efekt. Drugi problem jest taki że procesor ten ma jakieś dziwne strzały z resetem podciągnąłem nóżkę reset poprzez rezystor 10k do plusa zasilania i dalej guzik mruga mi diodkami masakra jednym słowem. Dziwne jest to że jak wezmę podstawię atmegę 16 wszystko śmiga super nie rozumiem czym różnią się te 2 procesorki poza ramem i flashem. Proszę pomóżcie

    Kod napisany w c jest raczej dobry bo i2c na atmedze 16 odczytuje zapisuje do zewnętrznego zegarka po i2c.


    W atmel avr studio dostaję podczas debugowania taką informację
    JTAG ICE: Warning: Reading the program counter, an invalid value (0xFFFE) was received from the device.
    JTAG ICE: Warning: A problem occured while executing this debug command! Please check the connections, the voltage, and the clock system of the target application!
  • #3 5799251
    flapo213
    Poziom 21  
    W tej chwili jest tak że jak przekompiluję z optymalizacją -2 wszystko działa, jeśli ustawie na -0 mam restart za restartem. Projekt jest ustawiony na atmega32 tu wszystko jest ok. Makefile jest ok wzięty z eclipsa stworzony działający. Problem się pojawia jak podejrzewam przy przejściu programu przez magiczne 16k kodu. Ponieważ po wyłączeniu optymalizacji jest ponad 18 k kodu. Spróbuję w jakimś komercyjnym środowisku dla testów. Wydaje mi się że to może być trochę wina gcc. Macie jakieś koncepcje. Fuse też dobrze mam kwarc 11.0592MHz i ustawione na high speed w atmel avr studio.
  • #5 5801734
    flapo213
    Poziom 21  
    Kolego co rozumiesz przez pojęcie "zapomniałem volatile" ma to jakieś znaczenie. Owszem stosuję volatile ale do instrukcji pętli np for-ów aby optymalizacja nie wycieła. Zaciekawiło mnie możesz rozwinąć temat. Bo w tej chwili z optymalizacją wszystko śmiga pięknei zero zawieszeń.
  • #7 5803110
    flapo213
    Poziom 21  
    Nie to nie volatile. Usunąłem wszystkie wystąpienia volatile pozostawiłem jedynie w pętlach for taką składnie for(i=0;i<25;i++)asm volatile("nop");

    Ok jestem już pewnien te funkcje które pisałe na początku nie są powodem restartół mikrokontrolera. Wiem teraz już na 100% że coś złego się dzieje po przekroczeniu 16kb kodu programu podejrzewam że to chyba nie wina gcc tylko coś ze sprzętem znaczy z atmega32 nie halo choć bardzo bym się chciał mylić. Pozdrawiam
  • #8 5803848
    markosik20
    Poziom 33  
    A jakim programatorem wgrywasz soft? Programowanie przechodzi weryfikację poprawnie?
  • #9 5804881
    flapo213
    Poziom 21  
    Sofcik wgrywam avrdude a programator to popularny jtag ice mk chyba 1 ten zbudowany w oparciu o atmege16. Weryfikację przechodzi pomyślnie. Nie umiem tego zrozumieć zazwyczaj po włączeniu optymalizacji coś nie chodzi a tu jest odwrotnie stąd moje przypuszczenia z kodem że po przekroczeniu 16k kodu coś zaczyna się dziać. Acha próbowałem też avarice to samo. Kurcza nie za bardzo wiem gdzie już szukać usterki. Jak debugowałem to robi się tak np jest instrukcja PORTA |= 1<<6; np za 40 razem i po prostu robi zwisa komunikat dziwny i restart procka. Próbowałem różnych kombinacji wyłączałem przerawania i włączałem bez skutku to samo.
  • #10 5872272
    flapo213
    Poziom 21  
    Witam wszystkich. Rozwiązałem problem. Okazało się że 1 problem polegał na tym iż jak sie włączyło przerwania i była obsługa i2c softwarowa to Atmega i układ pcf poprostu w pewnych miejscach miały sprzeczne stany - pcf 0 a atemaga 1 i zwarcie, oczywiście port nie padł ponieważ układ pcf ma zabezpieczenia. Problem rozwiązano poprzez sterowanie wyprowadzeniami przy pomocy rejestru DDRD a PORT na sztywno na 1 w wymaganych bitach. Po tym zabiegu odczyt i zapis po I2C idzie bez problemu. Drugi problem polegał na tym iż kompilator 4.3.0 jest coś nie za bardzo, chwilami to ciężko diodką było zamrugać o reszcie nie wspomnę. Wszystko działa poprawnie na 4.2.3 oraz na wersji 4.3.2 przetestowałem na windowsie i na linuxie. Temat uważam za zamknięty. Dzięki pozdrawiam
REKLAMA