STM32F1 + FATFS - nie wysyła danych po SPI do TFT

Witam

Najprostszy przykład - montuję FATFS (karta SD), otwieram plik tekstowy np. do zapisu, wpisuje dowolny tekst, zamykam plik. Do tego momentu jest wszystko dobrze tzn. tworzy mi i zapisuje plik z danymi na karcie SD (nie ma też problemu z dopisywaniem danych do istniejącego pliku). Następnie próbuję wysyłać po SPI do wyświetlacza TFT jakiekolwiek dane (np. obrazek) i nic. Gdy pominę kod obsługi SD to wszystko działa bez zarzutu. Nie wiem ale ten FATFS coś blokuje. Wyświetlacz jest zainicjowany przed obsługą FATFS.
Sprawdziłem i też czytam dane z istniejącego pliku np. do bufora i podobnie wyświetlacz jest blokowany. Procka nie blokuje program się wykonuje tzn. odpala taski na FreeRTOS i co ciekawe odblokowuje się wyświetlacz. Obsługa wyświetlacza dokładnie na tych samych funkcjach.
Dla testu umieściłem funkcję wysyłającą np. obrazek do wyświetlacza zaraz za obsługą karty SD i nie wyświetla się na ekranie. Gdy tylko usunę fragment obsługi plików na SD to obrazek jest na ekranie. Uprościłem maksymalnie obsługę SD tzn. tylko otwarcie i zamknięcie pliku bez funkcji odczytu/zapisu i też blokuje TFT. Nie wiem co jest grane. Tragedia. Z góry dziękuję za pomoc

Procek STM32F103, karta SD (SDIO 4-bit), TFT (SPI), kod wstępnie wygenerowany STM32CubeMX (FATFS - domyślne ustawienia, FreeRTOS)

Zauważyłem, że po obsłudze karty SD wysyłam bajt komendy do wyświetlacza i do tej chwili jest dobrze. Następnie wysyłam bajt danych i tu funkcja HAL_SPI_Transmit_IT() zwraca wartość HAL_BUSY. Zagłębiając się dalej w powyższej funkcji sprawdzany jest warunek:

Zamiast HAL_SPI_STATE_READY (wtedy byłoby dobrze) jest HAL_SPI_STATE_BUSY_TX
Tak jak pisałem gdy usunę fragment z obsługą karty SD (czyli reszta kodu bez zmian) to wszystko działa dobrze. Straszne dziadostwo ten STM32

Dodano po 4 [godziny] 28 [minuty]:

Uprościłem maksymalnie:


Dodano po 16 [minuty]:

Samo zamontowanie FATFS buraczy

jabu74 - ekspert wrote:

Straszne dziadostwo ten STM32

Jeśli już to nie STM32 ale biblioteki HAL.
Nie pokazałeś kodu tylko jakieś fragmenty schematu też nie więc nie wiadomo czy problem jest w HAL czy w dziadowski kodzie lub złym schemacie. Stawiam na dziadowski kod lub schemat, bo obsługiwałem TFT i kartę SD w kilku projektach z F1 i wszystko działało.

Tu naprawdę nie trzeba nic więcej pokazywać bo nie ma nic ciekawego. Tak jak pisałem wystarczy że usunę fragment kodu z f_mount() i wszystko śmiga. Zaraz za MX_xxx_Init() umieszczona jest inicjacja wyświetlacza a za nią kod który podałem. Może jeszcze coś z priorytetem przerwań. Wszystko miałem ustawione na 5, a druga wersja że SPI na 6 a reszta na 5 ale nie pomogło. To jest ciekawe, że dopiero po drugiej próbie wysłania zwraca, że TX jest zajęty a pierwsza wysyłka jest ok. Kolejne próby wysłania nic nie dają gdyż jest cały czas zajęty.

Później jak przejdzie ten kod i odpali taski we FreeRTOS to wszystko działa włącznie z obsługą wyświetlacza

jabu74 - ekspert wrote:

Tu naprawdę nie trzeba nic więcej pokazywać bo nie ma nic ciekawego.

A błędy transmisji callbackerror w HAL są obsługiwane? Nie widząc kodu nie wiem ale zgaduję, że nie.

jabu74 - ekspert wrote:

To jest ciekawe, że dopiero po drugiej próbie wysłania zwraca, że TX jest zajęty a pierwsza wysyłka jest ok. Kolejne próby wysłania nic nie dają gdyż jest cały czas zajęty.

Nieobsługiwane błędy w czasie transmisji przez DMA czy na przerwaniach sa najczęstsza przyczyną "zakleszczania się" HAL.

Podczas działania programu nie wchodzi do obsługi HAL_SPI_ErrorCallback(). Co ciekawe SPI mam ustawione na Half-Duplex Master a podczas wysyłania danych jest obsługiwane HAL_SPI_TxCpltCallback() a wydaje mi się, że powinno być HAL_SPI_TxHalfCpltCallback().

jabu74 - ekspert wrote:

Podczas działania programu nie wchodzi do obsługi HAL_SPI_ErrorCallback(). Co ciekawe SPI mam ustawione na Half-Duplex Master a podczas wysyłania danych jest obsługiwane HAL_SPI_TxCpltCallback() a wydaje mi się, że powinno być HAL_SPI_TxHalfCpltCallback().

Będą oba. HAL już tak ma.

Żeby było jaśniej HAL_SPI_TxHalfCpltCallback() w ogóle nie jest obsługiwane. Procek skacze tylko do obsługi HAL_SPI_TxCpltCallback()

A jaki jest sens obsługiwać tutaj przerwanie w połowie transferu DMA? Wystarczy jedno - po zakończeniu transferu.
To nie Arduino, że wystarczy połączyć dwa programy i jakoś będzie działać. Proponuję najpierw zapoznać się z dokumentacją układu i zrozumieć co oznaczają poszczególne funkcje i bity w HAL i RM. Bez tego pozostaje ślepe zgadywanie lub wiara i modlitwa, że ktoś kiedyś poprawi Twój program.

O jakie DMA chodzi ? Przecież ja tu nie korzystam z DMA

Żeby było jaśniej HAL_SPI_TxHalfCpltCallback() w ogóle nie jest obsługiwane, ponieważ jego wywołanie może nastąpić tylko w trybie obsługi DMA (kiedy DMA zrealizuje połowę transferu).
Naprawdę warto przeczytać dokumentację, aby nie szukać błędów tam gdzie ich nie ma.

Faktycznie nie przeczytałem dokumentacji. Myląca nazwa do głowy by mi nie przyszło, że to zadziała dopiero w trybie DMA.

Dodano po 6 [godziny] 9 [minuty]:

Wydaje mi się, że coś jest zburaczone w tym CubeMX. Mam ustawiony tryb (Mode) SDIO na SD 4 bits Wide bus a generuje kod jak dla trybu SD 1 bit

plik sdio.c

podobnie w pliku stm32f1xx_hal_sd.c

Jest konflikt z FreeRTOS. Uprościłem maksymalnie i wygenerowałem nowy kod z i bez FreeRTOS. Okazuje się, że bez FreeRTOS działa. Przy dołączonym FreeRTOS źle działało przed wywołaniem MX_FREERTOS_Init() i osKernelStart() i to mnie też trochę zmyliło. Czy da się to naprawić ?

Prawdopodobnie już wiem dlaczego tak to działa jak działa. W pliku projektu STM32CubeMX w konfiguracji FATFS -> System Parameters jest parametr FS_REENTRANT. W przypadku kodu bez FreeRTOS ten parametr ustawiony jest na Disabled i dlatego działa dobrze. Jeżeli wygenerujemy kod z FreeRTOS to ten parametr jest ustawiony na Enabled i wtedy nie wnikając w szczegóły kod źródłowy FATFS jest inny tzn. korzysta z semaforów. W kodzie jest to dyrektywa kompilacji warunkowej _FS_REENTRANT (plik ffconf.h). Jako, że uruchamiałem obsługę FATFS w wersji dla FreeRTOS przed uruchomieniem Schedulera to faktycznie nie dziwi, że coś się buraczy.

Słabiutki ten FATFS i to środowisko CubeMX. Wielokrotnie zdarza się, że przy zapisie do pliku wykorzystywane metody nie zgłaszają żadnych błędów a dane nie są zapisane do pliku. Z odczytem jest ok.