STM32F373 + SDCARD - Brak komunikacji z kartą

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



plik spi.c




Oraz kawałek kodu próbującego dostać się do karty:




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)

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?

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.

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]

[/img]

Oraz stany sygnałów podczas wysyłania komendy CMD0 i oczekiwania na odpowiedź.
[img]

[/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.

Patrząc na te obrazki to na moje oko SPI działa w trybie 16-bitowym zamiast w 8-bitowym.

Absolutnie nie. Czemu tak twierdzisz? Skąd takie podejrzenia?

KrukersRadek wrote:

Absolutnie nie. Czemu tak twierdzisz? Skąd takie podejrzenia?

Te przerwy pomiędzy bajtami to skąd są?

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ć.

Chłopie podczas initu max prędkość to zdaje się 400kHz, a ty plujesz tam MHz.

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

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.

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.

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.

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]

[/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.

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]

[/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 . 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ć 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.