Pracuję nad projektem przez ostatnie dwa tygodnie i debugowanie tego jednego problemu zajęło cały tydzień. Zastanawiam się, czy ktokolwiek może pomóc, postaram się wyrazić jak najlepiej.
Usiłuję zaimplementować port USB Virtual Comm na mikrokontrolerze opartym na STM32F302K8 (Cortex M4). Użyłem STM32CubMX do wygenerowania kodu potrzebnego do skonfigurowania urządzenia USB Full Speed USB implementującego klasę CDC. Moje urządzenie wyświetla się zarówno w systemie Windows (Menedżer urządzeń), jak i Linux. Jestem w stanie zaimplementować prostą funkcję echa opartą na przykładowym kodzie, ale kiedy teraz próbuję użyć funkcji USBD_CDC_SetTxBuffer do wysyłania danych do komputera, uruchamia się Hard Fault Handler. Zawęziłem to do faktu, że pole UsbDeviceFS.pClass (które jest wymagane przez USBD_CDC_SetTxBuffer) nigdy nie jest inicjalizowane, ponieważ USBD_CDC_Init () nigdy nie jest wywoływane podczas inicjalizacji urządzenia USB.
Zaimplementowałem poprawki do kilku błędów (w tym zmianę wielkości sterty, naprawienie flagi transmisji w USBD_CDC_TransmitPacket i zmianę rozmiaru CDC_DATA_HS_MAX_PACKET_SIZE na 256 z 512) w przykładowym kodzie, jak udokumentowano na forum ST, ale wciąż otrzymuję ten sam błąd.
Mój kod konfiguracji urządzenia to
* USB Device Core handle declaration */
USBD_HandleTypeDef hUsbDeviceFS;
/* init function */
void MX_USB_DEVICE_Init(void)
{
/* Init Device Library,Add Supported Class and Start the library*/
USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);
USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC);
USBD_CDC_RegisterInterface(&hUsbDeviceFS, &USBD_Interface_fops_FS);
USBD_Start(&hUsbDeviceFS);
}
Odpowiedzi:
Aby odpowiedzieć na moje pytanie, problem polega na tym, że mój kod nie czekał na zakończenie inicjalizacji USB i natychmiast zaczął wysyłać dane. Wstawienie aktywnego oczekiwania na wartość logiczną lub dodanie opóźnienia (jak wskazał @ramez) rozwiązuje problem.
AKTUALIZACJA Ten błąd został naprawiony w kolejnych wersjach sterownika CDC USB od ST. W konfiguracji jest teraz HAL_Delay. Zastrzeżenie polega na tym, że jeśli z jakiegokolwiek powodu Sys_Tick nie działa / jest dezaktywowany / jeszcze nie zainicjowany, kod się zawiesi.
źródło
Użyłem CubeMX do wygenerowania kodu do wykrywania STM32F4. Użyłem go jako wirtualnego portu COM tak jak ty. Nie korzystałem bezpośrednio z funkcji USBD_CDC_SetTxBuffer () . W pliku usbd_cdc_if.c znajduje się funkcja o nazwie CDC_Transmit_FS () . W wygenerowanym kodzie był błąd, funkcja przyjęła bufor jako parametr i nic z tym nie zrobiła. Poprawiony kod funkcji jest następujący:
Właściwie musiałem dodać memcpy do kodu. Po tej korekcie mogłem przesłać dane z mikrokotrolera do komputera z tą funkcją transmisji. Na przykład:
Inicjalizacja w MX_USB_DEVICE_Init () jest dla mnie taka sama jak twoja.
źródło
Najpierw sprawdź, czy hUsbDevice_0 ma wartość NULL (brak elementu w twoim rozwiązaniu):
Zapobiegnie to zawieszeniu twojego komputera i nie będzie wymagało zajętego oczekiwania w opóźnieniu.
Możesz umieścić go gdzieś w CDC_Transmit_FS:
źródło
Miałem ten sam problem, ale okazało się, że jedyne, co muszę zrobić, to ponownie podłączyć połączenie USB do komputera. Najczęściej flashujesz kod i resetujesz mikrokontroler, ale po stronie komputera wyliczenie nie jest aktualizowane. USBD_CDC_Init jest wywoływany, gdy host zaczyna sondować twoje urządzenie i dlatego pClassData ma wartość NULL.
źródło