Przeszukaj forum

Witam, Posiadam dwa mikrokontrolery z rodziny STM32. Pierwszy na płytce Nucleo-64 STM32F103RB, drugi na płytce Waveshare CoreH7XXI STM32H743IIT6. Postawiłem sobie za cel zbudować przetwornik cyfrowo analogowy R2R w oparciu o mikrokontroler. Wiem, że można wykorzystać do tego FPGA, ale ja postanowiłem całość oprzeć o mikrokontroler - cele naukowe i rozwojowe. IDE z którego korzystam, to STM32CubeIde. Z racji tego, że nie mam na co dzień do czynienia z mikrokontrolerami, a traktuję to jako hobby, to z góry przepraszam, jeśli popełniam jakieś rażące błędy, lub posiadam braki w wiedzy, ale dopiero się uczę. Skonfigurowałem USB na płytce Nucleo, jako USB Device, przyłączyłem middleware USB_DEVICE, klasa Audio Device Class, ustawiłem parametr częstotliwości na 48000 sampli/s, RCC HSE ustawiony na Crystal/Ceramic Resonator. Zegary skonfigurowane na korzystanie z kwarcu i PLL, USB taktowane 48MHz. Wlutowałem kwarc 8MHz i dwa kondensatory 30pF (takie akurat miałem pod ręką), wlutowałem rezystor 1k5 (1448Ω) pomiędzy 3.3V a pin USB D+ skompilowałem projekt, wgrałem na płytkę. Zrobiłem sobie około 40cm przewód z taśmy 4 żyłowej z jednej strony zakończony wtykiem USB, z drugiej wtykami goldpin. Podłączyłem D+, D- i GND, zasilanie pobieram z USB od programatora (przy czym przestawiałem też zworkę na E5V i całość zachowuje się tak samo). Podłączam mikrokontroler pod USB - urządzenie znalezione, poprawnie zainstalowane, widnieje jako STM32 Audio Class https://imgur.com/nBjyhkV. Inicjalizacja urządzenia się powiodła, wszystko wygląda dobrze - https://imgur.com/1LDmdm7. Na oscyloskopie kwarc pokazuje stabilne 8.00MHz. I teraz się zaczynają schody. Uruchamiam audacity, częstotliwość projektu ustawiam na 48KHz (choć to bez znaczenia, na każdej jest ten sam problem), generuję falę prostokątną 1KHz, wybieram moje urządzenie i klikam play. Oto, co się dzieje w snifferze - https://imgur.com/JjXmSkf. Proszę zwrócić uwagę na czasy - pierwsze dwa pakiety URB_FUNCTION_SELECT_INTERFACE wykonują się bardzo szybko. PC wysyła do uC żądanie i otrzymuje odpowiedź w ciągu 2ms - to jest moment kliknięcia play. Następnie mamy pakiety transferu danych, których jest mało, ze względu na to, że bardzo szybko kliknąłem stop. I tutaj zaczyna się sedno problemu. Kliknięcie stop ponownie powoduje żądanie URB_FUNCTION_SELECT_INTERFACE, które od PC do uC idzie od razu, ale w drugą stronę całość się zamraża na równo 5 sekund (+czasami kilka-kilkanaście ms, co widać w różnicach czasowych). Kliknięcie play i ponownie 5 sekund zwłoki i później lecą dane. Stop - znów 5 sekund i tak w kółko. Odpięcie USB i ponowne jego podpięcie daje jednorazowy szybki play, a potem sytuacja się powtarza. Wygląda to tak, jakby mikrokontroler przez 5 sekund próbował coś robić (tylko co?) a potem przechodził do właściwej pracy. Dodatkowo nie jestem w stanie poprawnie debugować pracy USB na tym mikrokontrolerze. Debuger poprawnie zatrzymuje się na pierwszej linii kodu, następnie klikam resume, urządzenie się pojawia. Gdy natomiast klikam play w audacity, dostaję komunikat "Błąd otwierania urządzenia dźwiękowego". Pakiet URB_FUNCTION_SELECT_INTERFACE (odpowiedź od uC) zwraca status 0xc0000011 https://imgur.com/EzQhRPh. I teraz, żeby było ciekawiej, powtarzam dokładnie tą samą procedurę na płytce z STM32H743IIT6 i wszystko działa tak, jak powinno, play i stop działa zawsze i od razu. Dlaczego zatem nie użyję H7 do USB? Ponieważ chcę zrzucić operacje pobierania danych z komputera i wstępną obróbkę na jeden cpu, a odtwarzanie, precyzyjny timer 48KHz i kierowanie danych na GPIO na drugi procesor (tutaj też są cele naukowe i rozwojowe - chcę spróbować różnych podejść i zrobić to na dwóch procesorach, mogąc jednocześnie obserwować komunikację między nimi). Czy ktoś się spotkał z takim problemem? Być może jest to kwestia tego, że CubeMX coś źle generuje, ale niestety nie jestem jeszcze aż tak biegły, żeby ogarnąć całą bibliotekę USB i potrzebuję wsparcia od osób bardziej doświadczonych :) Pozdrawiam, Mateusz