karta SD na SPI zawiesza AtXmega128A3U

Wróciłem ostatnio do jednego ze swoich projektów na Xmega128A3U. Postanowiłem dodać do niego funkcję związaną z zapisem danych na karcie microSD. Hardware był już do tego przygotowany - na płytce znajduje się gniazdko, podłączone do SPI na PORTE.

Przekopiowałem pliki związane z biblioteką FatFS z mojego innego projektu (na PIC24), modyfikując jedynie niskopoziomowe funkcje, odpowiedzialne za komunikację z kartą i konfigurując odpowiednie linie sygnałowe. W pętli głównej dodałem funkcję odpowiedzialną za zapisywanie danych na karcie. Wszystko się skompilowało i uruchomiło, aż nagle pojawił się problem, którego nie potrafię zdiagnozować...

Za każdym razem, gdy FatFS próbuje rozmawiać z kartą, urządzenie się zawiesza (jakby wpadło w nieskończoną pętlę) i po chwili zostaje zresetowane przez WDT. W moim przypadku problem pojawia się w momencie wykonania f_open().

Problem musi występować raczej gdzieś blisko sprzętu, bo:

- Dokładnie te same pliki źródłowe FatFS działały prawidłowo po skompilowaniu na PIC24, jedyną różnicą były niskopoziomowe funkcje I/O.

- Problem nie występuje, jeśli w slocie nie ma karty i biblioteka nie podejmuje próby komunikacji przez SPI.

Pomyślałem, że pewnie popełniłem jakiś błąd podczas pisania funkcji odpowiedzialnych za komunikację po SPI. Obejrzałem je jeden raz, drugi i trzeci, nie widząc żadnego problemu. Uprzedzając możliwe komentarze - nie, to nie jest wina pętli while, w której sprawdzana jest flaga zajętości po transferze SPI. Sprawdziłem ją wielokrotnie, poza tym po jej zakomentowaniu zawieszenie ciągle występowało.

W akcie desperacji postanowiłem sprawdzić inny sterownik SD, pożyczony z przykładów dołączonych do jednej z książek Tomasza Francuza, podpinając go do FatFS. Projekt się skompilował, a po jego ponownym uruchomieniu... Problem wystąpił ponownie.

Na chwilę obecną nie mam już pomysłów odnośnie tego, co mogło pójść nie tak. Pomyłka w montażu albo konfiguracji mogłaby powodować nieudaną transmisję, ale tutaj mam do czynienia z zawieszeniem układu. Nie jest to też problem ze stosem, bo wolnej pamięci mam pod dostatkiem, a po wyłączeniu WDT restarty ustają, choć oczywiście układ pozostaje zawieszony.

Reply to
Atlantis
Loading thread data ...

Przepraszam ze pytam o oczywistosc, ale czy sprawdziles zasilanie? Karta do pracy swoje potrzebuje...

Reply to
antispam

Tak, to już sprawdziłem. Cały układ jest zasilany z przyzwoitego zasilacza impulsowego, a przy karcie jest obecny kondensator filtrujący. Ścieżka zasilająca w miarę gruba i niezbyt długa.

Okazuje się, że winę za to zachowanie ponoszą najprawdopodobniej dwa błędy. Pierwszy wynikał z zastosowania zmiennych o niezdefiniowanej długości, zależnej od kompilatora. Na PIC24 zmienna miała właściwy rozmiar, ale na AVR przepełniła się przed osiągnięciem wartości mającej zakończyć pętlę.

Samo to jednak nie usunęło problemu. Zacząłem wywoływać niskopoziomowe funkcje I/O bezpośrednio w pętli głównej programu. I faktycznie, writeSPI() zawiesza program, na pętli oczekiwania na zakończenie transmisji. Jeśli zakomentuję pętlę, zawias znika.

Funkcja wygląda następująco:

#define SD_SPI SPIE

// send one byte of data and receive one back at the same time unsigned char writeSPI( unsigned char b) { SD_SPI.DATA = b; while(!(SD_SPI.STATUS & SPI_IF_bm)); return SD_SPI.DATA; }// writeSPI

Jakiś pomysł co do tego, co może powodować problem z tą flagą?

W tym samym układzie mam już uruchomione inne urządzenie na SPIC - tam żadne problemy ne występują.

Reply to
Atlantis

Sprawdź wyrównywanie pół w strukturach. Miałem podobny problem aczkolwiek portowalem z czego innego na STM32 (tez fakt na SD). Po wpisaniu czegoś w rodzaju #pragma pack(1) zadziałało. Problem brał się z tego ze oba kompilatory inaczej budowały struktury. jp

Reply to
jacek

Ok, cofam ostatnie. Problem z nieustawioną flagą w funkcji wysyłajacej/odbierającej dane przez SPI brał się z banalnej przyczyny - port SPI nie był skonfigurowany. Zapomniałem, że ten fragment kodu jest wywoływany przez FatFS w momencie montowania karty.

Jednak ręczne uruchomienie SPIE tylko częściowo usunęło problem. Powiem nawet, że zrobiło się dziwniej. :) Teraz pierwsze wywołanie funkcji przechodzi, ale gdy 5 sekund później funkcja zostanie wywołana ponownie, układ znów się zawiesza. I tak w kółko. ;)

Reply to
Atlantis

W kodzie sterownika karty SD nie mam żadnych struktur. Natomiast FatFS jest uniwersalną biblioteką, która powinna kompilować się gdziekolwiek, po dostarczeniu niskopoziomowych funkcji I/O. Już parę razy przenosiłem te pliki pomiędzy AVR, PIC24 i PIC32 i do tej pory taki problem się nie pojawił.

Jedyna "nowa" rzecz w tym przypadku, to zastosowanie kompilatora xc8 zamiast standardowego avr-gcc - testuję obsługę AVR-ów w MPLAB X IDE od Microchipa.

No i ta hipoteza nie tłumaczy jednak dlaczego nie chciała u mnie działać także sterownik z książki p. Francuza, pisany pod Xmegi...

Reply to
Atlantis

Ok, nieważne. Już mam. :) Winę za tkie zachowanie układu ponosiło znane przekleństwo AVR-óœ, które zdążyłem już wyrzucić z pamięci. Pin 4 portu z SPI pełni funkcję wejścia SS. Jeśli ustawimy go jak wejście, to sygnał niski przełączy SPI w tryb slave. U mnie miała miejsce właśnie taka sytuacja... Tak to jest, gdy człowiek już przyzwyczai się do układów z PPS i nie spodziewa się, że pin może pełnić specjalną funkcję, jeśli się jej samemu na nim nie włączyło. :)

Reply to
Atlantis

W dniu 2020-05-20 o 21:31, Atlantis pisze:

Od dawna używamy Xmega. Ja projektuję płytki, nigdy nie napisałem nawet programu mrugania LEDem i nie bardzo bym wiedział jak się do tego zabrać :)

Możliwość odwracania kolejności pinów w SPI, czy przerzucania USARTa na drugą część portu bardzo mi czasem pomaga (bo moje płytki są praktycznie jednowarstwowe z GND na bottom. O tej przypadłości SPI nie wiedziałem (wydawało mi się, że wszystkie piny mogę swobodnie wykorzystywać) aż raz, kilka lat temu, zdarzyło mi się podpiąć pod tę nogę nie to co trzeba i musieliśmy robić poprawki na płytkach. Ale moja wiedza o skutkach takiego podłączenia była za mała aby w ogóle skojarzyć to z Twoimi problemami :( P.G.

Reply to
Piotr Gałka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.