[Rozwiązano] STM32H523: jak wyzwolić SPI DMA sygnałem TIM1 TRGO w trybie NORMAL?

Witam, mam STM32H523 i od kilku dni walczę z konfiguracją obsługi SPI przez DMA wyzwalaną przez TIM. Generalnie w CubeMX jest wszystko inaczej niż to z czym się dotąd spotkałem.. Chodzi o to ze chcę za pomocą TIM1 generować TRGO które z kolei będzie wyzwalało transmisję SPI z paczkach po DMA. Przekopałem cały internet i nie ma na ten temat nawet słowa. Inne rodziny SMT32 można bez problemu konfigurować w tym przypadku poległem. Chodzi o transmisję NORMAL a nie za pomocą list. Czy ktoś miał z tym już kontakt? Nie jest problemem konfiguracja TIM1 ani transmisji SPI. Kiedy konfiguruję kanał DMA zgodnie ze zdrowym rozsądkiem i tym co proponuje mi CubeMX w gotowym programie nie mam żadnej transmisji albo wręcz wchodzę w obsługę Error_Handler

Ok, Czy mógłbyś wrzucić jakiś kod? Czy CubeMX jest najnowszy? Jak masz skonfigurowane TIM1, GPDMA, SPI?

najlepiej jak załączę plik *.ioc tam wszystko będzie. W main tak inicjuję peryferia

w tej cześci HAL_SPI_Transmit_DMA(&hspi1, (uint8_t *)buff_VGA, 100); program się zawiesza konkretmnie w tym miejscu Jest to o tyle dziwne że dla 32F411 wszystko było OK?

rpal napisał:

Jest to o tyle dziwne że dla 32F411 wszystko było OK?

No tak, ale stm32F411 to ma bardzo stare DMA (podobne to jeszcze f103). Tutaj masz już adresowanie i wiele wiele innych opcji . Proponuję sprawdzić czy na pewno wszystko masz ustawione i czy w dobrej kolejności.

sprawdziłem cały DMA istotnie był pomylony kierunek powinno być Memory->DMA a był odwrotnie oraz rozmiar zmiennych źródła i docelowy. Jednak poprawiłem to potem i niestety dalej leżę i kwiczę. Spróbuję przestać wyzwalać DMA za pomocą TIM1 i zrobię to w przerwaniu tyle że pewnie rozjedzie mi się synchronizacja pozioma bo ma to być generator sygnału VGA. Na F411 chodzi całkiem nieźle ale na kolor to już za mało mocy on ma. Bo kiedy presyłam dane prosto do GPIO symulując jakąś prymitywną rozdzielczość kolorów to już uC się mocno zatyka. Szkoda bo ten H523 jest szybki i ma dużo RAM. Przekopuję różne przykłady i niestety nic nie ma na ten temat. Podejrzewam że STM dał ciała i coś skopał bo znalazłem post jakiegoś gostka który pisał do STM że mają właśnie ten temat zupełnie nieudokumentowany. Tym niemniej może ktoś to przerobił i się odezwie

rpal napisał:

sprawdziłem cały DMA istotnie był pomylony kierunek powinno być Memory->DMA a był odwrotnie oraz rozmiar zmiennych źródła i docelowy. Jednak poprawiłem to potem i niestety dalej leżę i kwiczę. Spróbuję przestać wyzwalać DMA za pomocą TIM1 i zrobię to w przerwaniu tyle że pewnie rozjedzie mi się synchronizacja pozioma bo ma to być generator sygnału VGA. Na F411 chodzi całkiem nieźle ale na kolor to już za mało mocy on ma. Bo kiedy presyłam dane prosto do GPIO symulując jakąś prymitywną rozdzielczość kolorów to już uC się mocno zatyka. Szkoda bo ten H523 jest szybki i ma dużo RAM. Przekopuję różne przykłady i niestety nic nie ma na ten temat. Podejrzewam że STM dał ciała i coś skopał bo znalazłem post jakiegoś gostka który pisał do STM że mają właśnie ten temat zupełnie nieudokumentowany. Tym niemniej może ktoś to przerobił i się odezwie

No to są właśnie uroki używania Cuba. Może lepiej było by przejść na programowanie na rejestrach? Z Cuba bierzesz ustawianie zegara, albo sam kombinujesz i potem przynajmniej wiesz co się dzieje. Zastanawia mnie tylko po co SPI do VGA, masz jakiegos DACa? Ale to 25MSPx3 kolory?

po co SPI do VGA. Sekret polega na tym że każdą linię poziomą można złożyć z transmisji szeregowej po SPI, czyli SPI generuje piksele obrazu dla każdej linii i tak po kolei dla każdej następnej. Jak się to robi w DMA które jest wyzwalane przez TIM to powstaje bardzo przyzwoity obraz, tyle że czarno/biały. Wszystko zamyka się czasach dla VGA 640/480. Żaden DAC nie wyrobi się w tym czasie zwłaszcza że to możliwe by było tylko dla analogowego sygnału Composite video. Jednak jeśli przesyła się dane do GPIO to na VGA można już jakiś kolor wykombinować, tylko że zaczyna się trasferować już 640 bajtów danych (no prawie) na jedną linię. A w wersji czarno/białej na 1 linię składa się tylko 100 bajtów. O taki to sposób na VGA

Nie podam co gotowego rozwiązania bo nie znam dokładnie rodziny STM32H5, głownie korzystam głównie z rodziny STM32H7
a tu są spore różnice. Korzystam również bibliotek LL a nie HAL.

Miałem podobny problem w H7 i popełniłem na początku taki sam błąd jak ty, czyli próba bezpośredniego wywalania transmisji DMA SPI z timera.
Nie da się tego w ten sposób zrealizować bo kanał/strumień DMA może mieć tylko jedno źródło wyzwalania albo TIMER albo SPI.
W momencie gdy wyzwolisz transmisję DMA z pamięci do SPI poprzez TIMER to zostanie wysłana tylko pierwsza dana, następne
dane nie zostaną wysłanie bo do DMA nie dociera zwrotna informacja że SPI już wytransmitował daną i może przyjąć następną.
DMA czeka na następny wyzwolenie ale z Timera a nie z SPI.

Należy to skonfigurować w ten sposób że DMA jest wyzwalane sygnałem gotowości z interfejsu SPI ale dodatkowo kanał/strumień DMA jest synchronizowany poprzez TIMER (opcja TRIGGER).
Czyli mamy sytuację że:
- skonfigurowany DMA i uruchomiony DMA
- skonfigurowany i uruchomiony SPI
Teraz SPI wysyła żądanie transmisji do DMA ale DMA nie rozpocznie transmisji dopóki nie otrzyma dodatkowego zezwolenia od Timera(trigger).
W H7 można ustalić jak duża paczka danych zostanie wysłana po takiej synchronizacji.
Jako dodatkowy trigger (synchronizator) możesz wybrać jeden z timerów LPTIMx, TIM2 lub TIM12,TIM15.

Przynajmniej tak to działa w H7. W H7 jest trochę trudniej bo dostępna jest tylko synchronizacja z TIM12 ale da się to obejść poprzez wygenerowanie EVENT z innego TIMERA i przekierowanie przez DMAMUX).

Sam czekam na moduł startowy dla STM32H563 więc pewnie niedługo będę musiał się podszkolić z tej rodziny.

Pozdrawiam
JarekC

cóż trzeba to przemyśleć, póki co dzięki

nie rozwiazany problem