Jest sobie układ z MCU STM32F107. Do magistrali SPI3 podłączone dwa
urządzenia: karta SD oraz pamięć RAM 23LC1024. Każde z urządzeń z osobna
dział prawidłowo. Mogę zapisywać i odczytywać dane do/z pamięci RAM, a
karta SD jest prawidłowo obsługiwana przez FatFS. Każde z urządzeń jest
aktywowane software'owo swoim własnym pinem CS.

Bardzo konkretny problem pojawia się natomiast w bardzo konkretnej
sytuacji. Mianowicie:
1) W programie mamy otwarty plik, z którego kilkanaście razy na sekundę
czytana jest porcja danych.
2) Raz na 25 sekund wykonywany jest test zapisu i odczytu do/z pamięci
23LC1024. Trafia do niej pewna porcja danych, która następnie jest
odczytywana.

Problem pojawia się w momencie, gdy po zakończeniu ostatniej operacji na
SPI RAM przychodzi czas na kolejną operację na karcie (czyli w
opisywanym przypadku odczyt kolejnego fragmentu danych z pliku, chociaż
próbowałem wstawiać też w tym miejscy operację zapisu do innego pliku i
efekt był taki sam). Mianowicie wywalany jest wtedy błąd funkcji
readSECTOR sterownika karty SD, którego numer wskazuje na odrzucenie
komendy READ_SINGLE, wysłanej do karty (funkcja wysyłająca komendę
odbiera z magistrali odpowiedź inną niż 0).

Problem występuje raz, odczyty kolejnych porcji danych już tego błędu
nie wywalają, to znaczy do czasu aż upłynie kolejnych 25 sekund i
przyjdzie kolej odczytania porcji tuż po zakończeniu kolejnej operacji
na pamięci SPI.

Same operacje na RAM-ie poprzedzające ten błąd wykonują się prawidłowo.

Dodatkowe informacje/co udało mi się wykluczyć:
1) Analizator stanów logicznych pokazuje, że linie CS obydwu urządzeń
nigdy NIE znajdują się w stanie niskim jednocześnie.
2) Czas jaki upływa od podniesienia linii CS_RAM-u do upuszczenia linii
CS_SD zdaje się nie mieć znaczenia. Normalnie pomiędzy tymi zdarzeniami
upływa trochę ponad 3ms (pomiędzy operacjami jest jeden printf) ale
próbowałem wstawiać tam ręcznie opóźnienia idące w setki ms - nie pomagało.
3) Magistrala SPI jest konfigurowana przy inicjacji karty SD. Sterownik
pamięci RAM nie ingeruje w konfigurację magistrali. Przyjmuje stan
zastany i jedynie wysyła/odbiera dane.
4) Nie używam RTOS-a. Wszystkie operacje są wykonywane sekwencyjnie w
pętli głównej.
5) Nie używam przerwań do transmisji SPI ani nie inicjuję transmisji z
funkcji obsługi przerwań.
6) Nie używam DMA do obsługi transmisji SPI.

Ktoś ma jakiś pomysł co może być przyczyną tak dziwnego zachowania
układu/programu? Co jeszcze mogę sprawdzić?

do góry

Atlantis <m...@w...pl> wrote:
> Jest sobie układ z MCU STM32F107. Do magistrali SPI3 podłączone dwa
> urządzenia: karta SD oraz pamięć RAM 23LC1024. Każde z urządzeń z osobna
> dział prawidłowo. Mogę zapisywać i odczytywać dane do/z pamięci RAM, a
> karta SD jest prawidłowo obsługiwana przez FatFS. Każde z urządzeń jest
> aktywowane software'owo swoim własnym pinem CS.
>
> Bardzo konkretny problem pojawia się natomiast w bardzo konkretnej
> sytuacji. Mianowicie:
> 1) W programie mamy otwarty plik, z którego kilkanaście razy na sekundę
> czytana jest porcja danych.
> 2) Raz na 25 sekund wykonywany jest test zapisu i odczytu do/z pamięci
> 23LC1024. Trafia do niej pewna porcja danych, która następnie jest
> odczytywana.
>
> Problem pojawia się w momencie, gdy po zakończeniu ostatniej operacji na
> SPI RAM przychodzi czas na kolejną operację na karcie (czyli w
> opisywanym przypadku odczyt kolejnego fragmentu danych z pliku, chociaż
> próbowałem wstawiać też w tym miejscy operację zapisu do innego pliku i
> efekt był taki sam). Mianowicie wywalany jest wtedy błąd funkcji
> readSECTOR sterownika karty SD, którego numer wskazuje na odrzucenie
> komendy READ_SINGLE, wysłanej do karty (funkcja wysyłająca komendę
> odbiera z magistrali odpowiedź inną niż 0).
>
> Problem występuje raz, odczyty kolejnych porcji danych już tego błędu
> nie wywalają, to znaczy do czasu aż upłynie kolejnych 25 sekund i
> przyjdzie kolej odczytania porcji tuż po zakończeniu kolejnej operacji
> na pamięci SPI.
>
> Same operacje na RAM-ie poprzedzające ten błąd wykonują się prawidłowo.
>
> Dodatkowe informacje/co udało mi się wykluczyć:
> 1) Analizator stanów logicznych pokazuje, że linie CS obydwu urządzeń
> nigdy NIE znajdują się w stanie niskim jednocześnie.
> 2) Czas jaki upływa od podniesienia linii CS_RAM-u do upuszczenia linii
> CS_SD zdaje się nie mieć znaczenia. Normalnie pomiędzy tymi zdarzeniami
> upływa trochę ponad 3ms (pomiędzy operacjami jest jeden printf) ale
> próbowałem wstawiać tam ręcznie opóźnienia idące w setki ms - nie pomagało.
> 3) Magistrala SPI jest konfigurowana przy inicjacji karty SD. Sterownik
> pamięci RAM nie ingeruje w konfigurację magistrali. Przyjmuje stan
> zastany i jedynie wysyła/odbiera dane.
> 4) Nie używam RTOS-a. Wszystkie operacje są wykonywane sekwencyjnie w
> pętli głównej.
> 5) Nie używam przerwań do transmisji SPI ani nie inicjuję transmisji z
> funkcji obsługi przerwań.
> 6) Nie używam DMA do obsługi transmisji SPI.
>
> Ktoś ma jakiś pomysł co może być przyczyną tak dziwnego zachowania
> układu/programu? Co jeszcze mogę sprawdzić?
>

O ile dobrze pamietam to karta SD wymaga taktowania jeszcze po wyłączeniu
CS, albo przed aktywowaniem CS, jakies cyrki z tym są; to nie jest tak jak
normalne SPI.
Nie pamietam już dokładnie.

jp

do góry

On 17.04.2021 15:32, jacek wrote:

> O ile dobrze pamietam to karta SD wymaga taktowania jeszcze po wyłączeniu
> CS, albo przed aktywowaniem CS, jakies cyrki z tym są; to nie jest tak jak
> normalne SPI.
> Nie pamietam już dokładnie.

Tak, wiem. Biblioteka do obsługi SD (wzorowana na przykładzie dla PIC32,
pochodzącym z książki Lucio di Jasio) to uwzględnia, po prostu nadając
jeden bajt 0xFF po przełączeniu linii CS w stan wysoki.
Myślałem o tym, ale to nie może być przyczyną, ponieważ:
1) Nie używam przerwań ani DMA do obsługi SPI, więc wykonywanie kodu
jest wstrzymywane do czasu zakończenia tej transmisji.
2) Nawet gdyby, to upływa dostatecznie dużo czasu (ponad 3 ms) żeby
zdążyć nadać ten jeden "pusty" bajt. Próbowałem zresztą wydłużać ten
czas do kilkuset ms.
3) Ta sekwencja sygnałów zegarowych jest nadawana po zakończeniu
transmisji przez SPI. U mnie problem występuje tylko wtedy, jeśli
próbuję skorzystać z SD po tym, jak korzystałem z pamięci SPI RAM.

do góry

Atlantis <m...@w...pl> napisał(a):
> 3) Ta sekwencja sygnałów zegarowych jest nadawana po zakończeniu
> transmisji przez SPI. U mnie problem występuje tylko wtedy, jeśli próbuję
> skorzystać z SD po tym, jak korzystałem z pamięci SPI RAM.

Obstawiam, że niestety karty SD nie do końca przestrzegają standardu SPI.
Tutaj nawet ktoś opisuje przypadek (braku) współpracy z SPI RAM:
https://arduino.stackexchange.com/questions/44175/sw
itching-between-spi-devices-when-one-is-an-sd-card#c
omment87203_44176

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On Sat, 17 Apr 2021 18:38:46 +0200, "Grzegorz Niemirowski"
<g...@g...net> wrote:
> Tutaj nawet ktoś opisuje przypadek (braku) współpracy z SPI RAM:
> https://arduino.stackexchange.com/questions/44175/sw
itching-between-spi-devices-when-one-is-an-sd-card#c
omment87203_44176

Rzut okiem na szybko sugeruje problem z niezwalnianiem magistrali (a
konkretnie MISO) przy wysokim CS i koniecznością stosowania
dodatkowego bufora. To już grube przegięcie.

--
Marek

do góry

On 17.04.2021 19:34, Marek wrote:

> Rzut okiem na szybko sugeruje problem z niezwalnianiem magistrali (a
> konkretnie MISO) przy wysokim CS i koniecznością stosowania dodatkowego
> bufora. To już grube przegięcie.

Wygląda na to, że opisywany problem nie występuje w przypadku każdej
karty. Do tej pory układ był testowany z Kingstonem. Poza wspominanym
błędem parę razy pojawiły się też poważniejsze problemy, skutkujące
zmasakrowaniem systemu plików na karcie.

Po podmienieniu karty na SanDiska błąd przestał się pojawiać.
Problematyczny Kingston zdaje się działać prawidłowo w innym układzie
(bez tej pamięci SPI RAM) więc ewidentnie jakieś problemy z kartą
objawiły się dopiero, gdy obydwa urządzenia znalazły się na jednej
magistrali.

Co co mogło chodzić - nie mam pojęcia...

do góry

On Wed, 21 Apr 2021 22:08:50 +0200, Atlantis <m...@w...pl>
wrote:
> Wygląda na to, że opisywany problem nie występuje w przypadku
> każdej
> karty.

No ale zweryfikowałeś czy problematyczna karta w tym przypadku
prawidłowo zwalniała magistrale... moment bo się zgubilem teraz.
Problem był z kartą SD czy pamięcią? Bo problem niezwalnianiem
magistrali wpływałby na drugi slave czyli pamięć spi ram. No chyba,
że ta pamięć nieprawidłowo zwalnia.

> Problematyczny Kingston zdaje się działać prawidłowo w innym
> układzie
> (bez tej pamięci SPI RAM) więc ewidentnie jakieś problemy z kartą
> objawiły się dopiero, gdy obydwa urządzenia znalazły się na jednej
> magistrali.

A może to jednak problemy z pamięcią?

--
Marek

do góry

On 22.04.2021 09:00, Marek wrote:

> No ale zweryfikowałeś czy problematyczna karta w tym przypadku
> prawidłowo zwalniała magistrale... moment bo się zgubilem teraz. Problem
> był z kartą SD czy pamięcią? Bo problem   niezwalnianiem magistrali
> wpływałby na drugi slave czyli pamięć spi ram. No chyba, że ta pamięć
> nieprawidłowo zwalnia.

Nie mam pojęcia. Jak mówiłem, wszystko wskazywało na to, że przyczyna
leżała po stronie pamięci SPI RAM, bo problem pojawiał się dopiero
wtedy, gdy urządzenie próbowało skorzystać z karty SD po zakończonej
(sukcesem) sekwencji zapisu/odczytu na pamięci SPI. Sama pamięć i sama
karta działały prawidłowo, linie CS nigdy nie były w stanie niskim
jednocześnie.

Z drugiej strony wygląda na to, że problem ustąpił po zastąpieniu karty
SD innym modelem.

do góry