[C][PIC32] - Komunikacja z kartą SD/MMC ("fatfs") pod PIC32MX695F512H

Staram się od jakiegoś czasu uruchomić komunikację z kartą pamięci SD przy pomocy biblioteki "fatfs" na układzie PIC32MX695F512H, bezskutecznie, funkcja disk_initialize(0), zwraca mi ciągle wartość "1" (STA_NOINIT).
Karta jest podłączona w podstawce pod napięcie 3,3V, takie samo jak cały układ. Piny MOSI => SDO3, MISO => SDI3, SCK => SCK3, oraz CS => PD4, połączenie elektryczne jest sprawdzone i wydaje się być prawidłowe, używam portu SPI3. Przy karcie zastosowałem kondensatory filtrujące, zgodnie z dokumentacją. Karta jest formatowana przy użyciu systemu FAT, z domyślnymi ustawieniami i ma 4GB pojemności.

Bity konfiguracyjne są następujące:


Mój plik zapewniający komunikację niskiego poziomu, wygląda następująco:


Siedzę nad tym od kilku dni, bardzo proszę o pomoc, gdzie jeszcze mogę szukać błędu? Program oczywiście kompiluje się bez błędów, po wykonaniu funkcji disk_initialize(0) która zwraca błąd program wykonuje się dalej poprawnie (obsługa USB, I2C, etc).



Debugowanie wykazało, że funkcja kończy działanie na lini if (send_cmd(CMD0, 0) == 1) { /* Enter Idle state */ (linia 348). Ciężko mi stwierdzić czy jest w ogóle jakaś komunikacja z kartą czy karta zwraca błąd, w każdym razie po wysłaniu tej komendy "send_smd" zwraca nie-jeden, co w zasadzie kończy wykonywanie całej funkcji.


----------------------------------------------------------------
Biblioteka "fatfs" - http://elm-chan.org/fsw/ff/00index_e.html
PIC32MX695F512H - http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en545654

W dalszym ciągu nie mogę zmusić żadnej karty do współpracy, kupiłem juz nawet z tej okazji analizator stanów logicznych, poniżej wynik analizy:



Karta jest inicjalizowana książkowo, zgodnie z dokumentacją, CS i DO logiczne 1, potem ponad 80 cykli zegara, CS = 0, wysyłam CMD0 z odpowiednim CRC i karta milczy. Zgodnie z dokumentacja powinna potwierdzić odebranie polecenia zwracając R1. Karta w ogóle nic nie zwraca, jak by jej nie było w slocie. Sprawdzałem z trzema karta, sprawdzałem karty microsd i zwykłe sd.

Ktoś mi pomoże? Naprawdę przekopałem już internet od góry do dołu i nie mogę uruchomić tej karty pamięci.

wywołujesz disk_timerproc() co 1 ms?

Tak, dokładnie co 1ms, ale nie wydaje mi się, żeby to było przyczyną, procedura inicjalizacyjna jest przeprowadzona dobrze, tylko karta z jakiegoś powodu nie odpowiada. Powinna odesłać 0x01 lub coś innego w przypadku błędu. Zasilanie jest poprawne, 3,3V, kondensatory 100n na zasilaniu są, PIC32 "transmituje" dobrze, częstotliwość wynosi 400kHz.
I mimo to karta nie odpowiada.

Dodano po 16 [minuty]:

Próbowałem również wykonać procedurę ze strony http://pwc.theclarkwebsite.com, polegającą na:

Quote:

Step 1 - "Wake up" the SD Card Before we can start clocking in instructions, we must clock in at least 74 "warm up" pulses to the card. As a practical matter, most people clock in 0xFF through the SDI module 10 times which results in 80 clock pulses. The chip select pin should not be asserted during this process (should be in the high state)

Step 2 - Assert the Chip Select pin Bring RB7 low to assert the chip select pin.

Step 3 - Clock in CMD0 into the SD Card Clock in the following bytes: 0x40 0x00 0x00 0x00 0x00 0x95. Clock in two dummy bytes to get the response from the SDI Card, which should be 0x00.

Step 4 - Clock in CMD8 into the SD Card Clock in the following bytes: 0x48 0x00 0x00 0x00 0b10101010 0x87. Clock in two dummy bytes to get the response from the SDI Card, which will be 0b10101010 if you are using a new card. The card I use is an older card, which doesn't recognize this command and returns 0x01, which is an error message but does not impact the initialization sequence.

W dalszym ciągu żadnej reakcji ze strony karty. Sprawdziłem ponownie połączenia elektryczne, działają.

Co jest na RD0? na tym pinie według kodu sprawdzana jest jednocześnie obecność karty SD i blokowanie zapisu.

solarstone, właśnie nie, te funkcje są nadpisane, mój slot nie posiada tych wyprowadzeń, zresztą kod na którym się wzorowałem miał już tak ustawione te wartości (wartość 0 oznacza odpowiednio, brak blokady zapisu i niepusty slot).

Ale nawet gdyby te wartości miały znaczenie, to uC nie wysylał by komendy przejścia do trybu SPI, natomiast takie polecenia idą, karta powinna coś odpowiedzieć.



Zastanawiam się, czy nie posiadam jakiś kart, które nie wspierają trybu SPI, ale czytałem gdzieś, że podobno mimo iż dokumentacja dopuszcza brak takiego wsparcia, to wszystkie karty działają w trybie SPI.

U mnie transmisja z karty w tym samym momencie wygląda tak:

Karta powinna odpowiedzieć, ale miałem już karty które nie chciały się poprawnie inicjalizować.
Może coś nie tak z elektrycznym układem zasilania karty?

Ja nie korzystam z Fatfs, ale to nie ma w tym momencie znaczenia.

Edit: Po jakim czasie od włączenia zasilania zaczynasz transmisję do karty?
Ja u siebie mam ok. 0,1s zwłoki.

W końcu mi się udało! Chyba w życiu się tak nie cieszyłem na jeden pusty plik tekstowy na karcie pamięci! Gdyby nie ten analizator stanów logicznych to nigdy by mi się nie udało!

Dwie rzeczy miałem źle ...

Po pierwsze, rezystory podciągające są wg. dokumentacji OBOWIĄZKOWE, nawet na liniach których nie używamy w dokumentacji. Bez tego karta milczała w ogóle.



Po drugie, brakowało mi parametru SPI_OPEN_CKE_REV w funkcji inicjującej port SPI. Powinno być: SpiChnOpen(SPI_CHANNEL3,SPI_OPEN_MSTEN|SPI_OPEN_SMP_END|SPI_OPEN_CKE_REV|SPI_OPEN_MODE8,2);
Bez tego uC źle odczytywał przychodzące dane z karty.

Dzięki chłopaki za pomoc, na razie nie zamykam wątku, postaram się wstawić kod i schemat jak skończę, dla potomonych

No to gratulacje
Ja u siebie nie mam zdaje się tych nieużywanych linii podciągniętych - może dlatego niektóre karty (dwie) nie chciały się zainicjować.
Będę musiał sprawdzić przy okazji.

Własnie przed chwilą tez walczyłem z programatorem i PICem32.
Zachciało mi się wypróbować czy czasem nowe OpenOcd nie zaprogramuje PICa32.
Oczywiście znowu nic, ale przy okazji ta operacja kasuje coś w pamięci procka i po tym on już nie wstaje. Trzeba przeprogramowywać PICkitem.
No i nie chciało coś zadziałać - już myślałem, że procek się jakoś trwale przeprogramował, ale okazało się ze linux ma jakieś kłopoty z obsługą pickita poprzez port USB3.0.
Po przełaczeniu na USB2.0 wszystko wróciło do normy.
Ale co się naszukałem, to moje

Widzisz, chyba gdybyśmy nie byli tacy ciekawscy i uparci, nic by z tego nie wyszło, wygląda na to, że to jednak zaleta

Tak jak obiecałem, wstawiam część swojego kodu, w pliku mmcPIC32.c jest najważniejsza część, czyli realizacja zapisu, odczytu przez SPI, biblioteki nie zamieszczam, bo można ja pobrać. Zapis i odczyt działają aż miło

Tutaj mam również taką funkcję inicjalizującą, która również tworzy foldery i otwiera plik logu do zapisu.


Pozdrawiam