Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

STM32F373 + SDCARD - Brak komunikacji z kartą

RADEKMTX80 16 Oct 2015 11:33 903 14
  • #1
    RADEKMTX80
    Level 10  
    Cześć.
    Siedze już 2 dni nad kodem, prześledziłem wszystkie rejestry i nie wiem już co jest źle. Mam problem z komunikacją z kartą SD już na samym początku kiedy wysyłamy komendę CMD0 - przejście w tryb sterowania po SPI.

    Oto dołączam mój kod:

    Biblioteka SPI:
    PLIK Spi.h
    Code: c
    Log in, to see the code



    plik spi.c
    Code: c
    Log in, to see the code




    Oraz kawałek kodu próbującego dostać się do karty:
    Code: c
    Log in, to see the code




    Po kazdym wyslaniu komendy CMD0 karta nie reaguje nie odpowiada.
    zmienna spi_res zawsze ma wartosc 0xff.

    Gdzie może być błąd?

    Chciałem dodac że taktowanie na porty i na SPI2 uruchamiam wcześniej w funkcji main i jest dobrze zrobione. Mierzyłem czestotliwosc na wyjsciu SCK spi i jest taka jaka zadałem. Wiec chyba spi chodzi.

    Uwaga! Dodam jeszcze że zintegrowałem obsługe karty SD z przykładowego projektu pod płytkę STM32F373C_EVAL (nawet te same piny wykorzystałem). Pobrałem z tamtąd całą inicjalizację robioną na podstawie standardowych bibliotek STMa i niestety nic nie pomogło. Nadal karta nie odpowiada (cały czas informacja zwrotna o wartości 0xff). Zakładam że jeżeli nie działa oryginalny kod z EVAL to coś msui być nie tak w połączeniach karty z uC.

    Same połączenie wygląda tak, że łącze się kablami bezpośrednio z goldpinów, a po drugiej stronie mam wlutowane kabelki (długość 15cm) bezpośrednio w adapter na karty microSD. Zadnej lini sygnałowej nie podciągam do zasilania przez zewnetrzny rezystor. Tylko podciągam 3 linie SCK, MIOS, MOSI po przez wewnetrze rezystory podciagające (40k) w kodzie przy inicjalizcji (tak było oryginalnie w kodzie EVAL)
    [28-30.06.2022, targi] PowerUP EXPO 2022 - zasilanie w elektronice. Zarejestruj się za darmo
  • #2
    KrukersRadek
    Level 10  
    Czy ktoś próbował się komunikować w ogóle po SPI2, SPI3 z karta SD programując procek STM32f373?
    Albo czy ktoś działał na kodzie z płytki eval z przykładu do komunikacji po spi z sd?
  • #3
    KrukersRadek
    Level 10  
    Jest ktoś tu co rzeczywiście dobrze się zna na temacie SPI i karty SD z prockiem STM32F373? Bo temat naprawde poważny, już wszystkiego spróbowałem.

    Mam jeszcze pytanie. Jak jest w końcu z sygnałami MISO, MOSI, SCK, CS? Jak je podłączać? Czy podciągać? Czy też nie podciągać do zasilania? Bo widziałem już tysiące róznych podłączeń i wszedzie inaczej.
  • #4
    RADEKMTX80
    Level 10  
    Tu wrzucam jeszcze analize stanów podczas kounikacji z karta SD. Według mnie SPI działa poprawnie, sami spójrzcie.

    Obraz przedstawiający wysłanie minimum 74 cykli zeby zrobić mieki reset karty SD. Ja wysyłam 80 cykli zegarowych.
    [img]
    STM32F373 + SDCARD - Brak komunikacji z kartą
    [/img]

    Oraz stany sygnałów podczas wysyłania komendy CMD0 i oczekiwania na odpowiedź.
    [img]
    STM32F373 + SDCARD - Brak komunikacji z kartą
    [/img]

    Poczytałem trche o kartach SD. Ponoć jak karta nie odpowiada na komende CMD0 to oznacza to ze nie potrafi być sterowana po SPI i tylko moze byc sterowana po SDIO.

    Więc czy mam takie sczęście że poprostu wybrałem 2 karty microSD które by sie nie dało programować? Czy jednak dalej szukać przyczyny?

    Pomoże ktoś?
    Pozdrawiam.
  • #5
    tantalos1
    Level 17  
    Patrząc na te obrazki to na moje oko SPI działa w trybie 16-bitowym zamiast w 8-bitowym.
  • #6
    KrukersRadek
    Level 10  
    Absolutnie nie. Czemu tak twierdzisz? Skąd takie podejrzenia?
  • #7
    tantalos1
    Level 17  
    KrukersRadek wrote:
    Absolutnie nie. Czemu tak twierdzisz? Skąd takie podejrzenia?

    Te przerwy pomiędzy bajtami to skąd są?
  • #8
    KrukersRadek
    Level 10  
    Wynikają z tego że procedura wysyłająca bajt przez SPI wysyła 8bitów po czym czeka az pojawi sie odpowiedz w buforze FIFO. Wiedzac że informacja przekazywana jest skewncyjnie szeregiem 8bitów jest to odpowiedni czas przesłania informacji zwrotnej do bufora FIFO oczytu (RxFiFO). Czyli prosciej mówiąc po wysłaniu czekamy na odpowiedź, a odpowiedź jest przesyłana i to musi potrwac 8cykli zegarowych 1 cykl na 1 bit.

    Jeżeli coś pomyliłem to prosze mnie poprawić.
  • #9
    tadzik85
    Level 38  
    Chłopie podczas initu max prędkość to zdaje się 400kHz, a ty plujesz tam MHz.
  • #10
    KrukersRadek
    Level 10  
    Chłopie zmieniłem dzielnik na 256 już dużo wcześniej bo próbowałem wszystkiego i to samo!
    36Mhz = 36000000/256 = 140625 = 140,625 kHz
  • #11
    tantalos1
    Level 17  
    KrukersRadek wrote:
    Wynikają z tego że procedura wysyłająca bajt przez SPI wysyła 8bitów po czym czeka az pojawi sie odpowiedz w buforze FIFO. Wiedzac że informacja przekazywana jest skewncyjnie szeregiem 8bitów jest to odpowiedni czas przesłania informacji zwrotnej do bufora FIFO oczytu (RxFiFO). Czyli prosciej mówiąc po wysłaniu czekamy na odpowiedź, a odpowiedź jest przesyłana i to musi potrwac 8cykli zegarowych 1 cykl na 1 bit.

    Jeżeli coś pomyliłem to prosze mnie poprawić.

    SPI nie działa sekwencyjnie, wysyłanie odbywa się równocześnie z odbiorem, tak więc po wysłaniu 8 bitów w FIFO odbiorczym już jest odebrany bajt. Nawet przy wysyłaniu komendy CMD0 na oko widać, że jest za dużo cylki zegarowych na SCK.
  • #12
    KrukersRadek
    Level 10  
    No dobra odbywa sie równoczesnie ale przy rozmowei z kartą SD już tak nie jest, bo jest bajt potem nalezy odczekac bajt odbiorczy, który możemy interpretowac lub możemy olać. A samo SPI oczywiścei ze podczas Fullduplex transmisja i odbiór jest równoległy tu sie zgodze.
  • #13
    tadzik85
    Level 38  
    KrukersRadek wrote:
    No dobra odbywa sie równoczesnie ale przy rozmowei z kartą SD już tak nie jest, bo jest bajt potem nalezy odczekac bajt odbiorczy, który możemy interpretowac lub możemy olać. A samo SPI oczywiścei ze podczas Fullduplex transmisja i odbiór jest równoległy tu sie zgodze.


    Jakieś bzdury wygadujesz. Jakie odczekiwanie na bajt odbiorczy chłopie.
    Obsługi Kart SD przez SPI w necie bez liku. I nigdzie takiej herezji nie widziałem.

    Reasumując procedury obsługa SPI do poprawki.
  • #14
    KrukersRadek
    Level 10  
    Chciał bym powiedziec, że kod na samym poczatku zachowuje sie identycznie jak oryginalny kod pod płytke eval dla uC stm32f373c. Pinieważ w tej chwili działam na oryginalnym kodzie z biliotek SPL.
    Więc wszystkie procedury inicjalizacji, zapisu i odczytu mam z SPL i tak to działa jak widać na przebiegach.

    Pozatym tu cytuję fragment książki Tomasza Jabłońskiego pt. "Karty SD/MMC w systemach mikroprocesorowych" o samy odczycie bajtów z karty sd, prosze przeczytać.

    Oto wycinek:
    [img]
    STM32F373 + SDCARD - Brak komunikacji z kartą
    [/img]

    W zasadzie róznie ten takst mozna interpretować. Aczkolwiek uważam że masz rację śa odczytywane w tym samym czasie co wysyałen są 1 na MOSI. Pytanie tylko w takim razie skąd te zwłoki czaasowe między poszczególnymi bajtami, skoro to oryginalny kod SPL.
  • #15
    RADEKMTX80
    Level 10  
    Tu załączam przebieg jaki udało mi się wygenerować. Ten już bardziej wygląda poprawnie ilosc impulsów sie zgadza.
    Problem był taki że wykonując komendę:

    SPI->DR = 0xff;

    Kompilator nadpisywał całe 16 bit i spi wysyłało 16 bit na MOSI, co jest bardzo dziwne bo miałem wybrany tryb 8bitowy. Kod zaieniałem na odpowiedni z użyciem dostepu do rejestru na poziomie 1 bajta:

    (*((uint8_t*)(&(SD_SPI->DR)))) = 0xff;

    I teraz zachowuje sie normalnie bo wystawia na MOSI tylko 8bitów te które wysyła.
    Myslę że winny jest mój kompilator który zle generuje kod.


    Jednak dalej nie rozwiązuje to problemu komunikacji z karta SD. Ponieważ karta naal nie odpowiada. A jak widać z przebiegu to wszystko po SPI jest wysyłane poprawnie. Więc oco chodzi.

    Oto przebieg, całej inicjalizacji + CMD0 i oczekiwanie na odpowiedz.
    (Oczekiwałem na odpowiedź 1000 razy i nie odpowiedziała).
    [img]
    STM32F373 + SDCARD - Brak komunikacji z kartą
    [/img]

    Dodano po 25 [minuty]:

    Dobra, temat zamykam problem rozwiązany.

    Podsumowując:

    1. Powodem był zle wygenerowany kod przez kompilator. Przyznam sie ze dawno nie zmieniałem toolchaina :D. Ale odpowiednio przerobiony zapis i odczyc z rejestru DR dał poprawny rezultat, komunikacji z SD.

    2. Później karta nie odbierała, w sumie nic dziwnego bo wczoraj ją wyciągnałem z adaptera i zapomniałem dzisiaj ją rano włożyć :D Troche śmiesznie, no ale ważne, że postanowiłem sprawdzić czy jest tam karta i problem sie rozwiązał.

    3. Napisane standardowe biblioteki w SPL są nie do końca napisane poprawnie. Mi po paru modyfikacjach udało sie znacznie zwiekszyc transfer do SD. Z SPL dużo niepotrzebnego czasu komunikacja oczekuje w petlach, co czasem jest nie potrzebne. Dlatego od zawsze jestem zwolennikiem pisania samemu bibliotek, przynajmniej na poziomie warstwy sterowniczej.

    Dziękuję za pomoc, troszeczkę pomogliście :)
    Pozdrawiam.