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

Atmega32 i karta SD 16MB - błędne dane przy odczycie sektorów

szakamason 08 Gru 2006 21:52 2613 4
REKLAMA
  • #1 3310205
    szakamason
    Poziom 13  
    Posty: 123
    Pomógł: 3
    Ocena: 4
    Witam, mam problem z obsługą karty SD 16MB przez atmega32. Do uC mam wgrany program, który jest dołączony do biblioteki procyon pod AVR'y jako example. W PROTEUS'ie wszystko mi pięknie śmiga, z tym że program jest napisany pod kartę MMC, która jest akurat jako VSM.DLL w PROTEUS'ie. Gdy podłączyłem na żywo do atmegi, pojawiały mi się w hyper terminalu jakies bajty, z tym że jak zmieniałem sektory do odczyty, te dane były ciągle takie same, no i doszedłem do wniosku, że te dane to smieci w RAM'ie mikrokontrolera, gdy dodałem funkcję zerującą bufor na początku programu, faktycznie smieci się już nie pojawiały. W PROTEUS'ie układ dalej smigał tak jak powinien, czyli od strony programowej już jest wszystko dobrze. No i nastepnie dopisałem w funkcji inicjalizującej kartę SD wysyłanie komendy CMD55, która mi umożliwi wpisanie komendy ACMD41 która jest wymagana w kartach SD, z tym że wpisywałem to według specyfikacji 1.9v, czy karta 16MB SD jest zgodna z tą specyfikacją. Gdy wysyłam do karty jakies polecenie to ona mi coś odpowiada, mogę to zaobserwować na migającej diodzie podłączonej do wyjścia. Czyli niby O.K., dla pewności na wyjściu karty zastosowałem bufor 74hc244n, żeby poziomy napięć się zgadzały. Ale niestety mikrokontroler wysyła mi na RS'a tylko zera, czyli bufor 512B pusty. Już ni e mam pomysłów:(
  • REKLAMA
  • #2 3328185
    szakamason
    Poziom 13  
    Posty: 123
    Pomógł: 3
    Ocena: 4
    Nikt nie potrafił mi pomóc, więc pomogłem sobie sam. A więc, po rozmontowaniu układu, odstawieniu na półkę znowu mnie natchnęło po kilku dniach do SD/MMC. Zmontowałem układ na nowo. Zrobiłem sobie mały debugger w programie. Po wysłaniu każdej komendy, wysyłam po RS'ie daną która jest zwrócona w buforze odbiorczym SPI. O dziwo po podłączeniu karty wszystko śmiga aż miło. Czyli co ma do tego moja zmiana w programie?? - nic. Poprostu coś z kabelkami było nie tak. Działa to na Atmega32( bez L) bez dopasowywania poziomów napięć poprzez bramkę(z bramką zresztą też). Testowane na kartach MMC+, SD128MB. Nie zaświeciła mi jedynie karta SD16MB, po wysłaniu komendy CMD1 odpowiedź dostaje 5, a powinno być 0 po kilku kolejnych jedynkach (1). Może uwaliłem kartę podczas tysięcy prób odpalenia:) Ale co tam, ważne że na reszcie działa.
  • REKLAMA
  • #3 3328277
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    Spróbuj innej sekwencji w przypadku SD (mogłem się pomylić, przeklejam z "kodu", w którym inicjuję także SDIO):
    CMD0, CMD58, CMD55, ACMD41, CMD16


    W przypadku MMC wystarcza:
    CMD0, CMD1, CMD16


    I oczywiście rozbiegówka 0xFF przynajmniej x10 na samym początku.
  • REKLAMA
  • #4 3328395
    szakamason
    Poziom 13  
    Posty: 123
    Pomógł: 3
    Ocena: 4
    Dzięki. Ja używam sekwencji:

     
    
    CMD0  CMD1  CMD55  ACMD41  CMD59  CMD16
    
    


    No i w tej sekwencji działa mi SD 128MB oraz MMC+ 512 MB, a nie działa jedynie SD 16MB. MMC zwykłe też działaja w tej sekwencji, w symulatorze przynajmniej mi chodzą.
  • Pomocny post
    #5 3328610
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    Dziwne, może ta 16MB jest wolniejsza/starsza, chociaż ErrCode 05 = ILLEGAL_CMD + IDLE_STATE. Swój kod testowałem z SD 16MB Cannon (nie było mi szkoda upalić) i nie miałem problemów. Oczywiście z większymi również, ale tylko SD i SD/IO, bez MMC.

    A wysyłasz 0xFF przed każdą komendą zanim zrobisz CARD_SELECT? W sumie to u mnie działa i bez tego, ale..
REKLAMA