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.

do góry

Atlantis <m...@w...pl> wrote:
> 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().

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

--
Waldek Hebisch

do góry

On 20.05.2020 18:43, a...@m...uni.wroc.pl wrote:

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

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

do góry

Atlantis <m...@w...pl> wrote:
> 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.
>

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

do góry

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. ;)

do góry

On 20.05.2020 20:05, jacek wrote:

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

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

do góry

Ok, nieważne. Już mam. :)
Winę za tkie zachowanie układu ponosiło znane przekleństwo AVR-óoe, 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. :)

do góry

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

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

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.

do góry