https://github.com/KarlK90/ChibiOS-RISC ... /gd32vf103 (RT and OSLIB test cases are all successful, GPIO and PWM Timer and UART is working!)
Now for my problem that kept my busy for the past few days: I tried to figure at bug with the USB peripheral which is not the USB Device peripheral of the STM32F103 but the well known Synopsys Designware OTG FS peripheral, found on the STM32F107/STM32F4 etc. Which gives me quite a headache because it lock-ups after several seconds and I can't figure out the cause for this behaviour. Unfortunately my knowledge of USB is quite limited, in fact this is the first time a work with it on a low level basis.
Here is what I found out so far:
(Using the USB-CDC Demo which is in the repo, there is also a compiled elf binary in the ./build folder and a SVD descriptor in /docs)
Board: Sipeeed Longan Nano and own custom Board for testing purposes
* Enumeration succeeds, terminal is functional
* Reading the Device Descriptor and Device Status with lsusb/usbhid-dump succedes
* The CDC-Terminal becomes non-responsive after several seconds
* Lock-up occurs without input/output to the terminal
* Lock-up occurs with input/output to the terminal (e.g. the write command or issuing multiple test rt commands)
* The time varies, sometimes almost immediately, sometimes after 10s..30s
* Decreasing STM32_USB_OTG1_RX_FIFO_SIZE to 128 or 256 leads to a faster lock-ups
* Disabling interrupts during FIFO access with STM32_USB_OTGFIFO_FILL_BASEPRI makes no difference
* Lock-up is reproduce-able on multiple Boards and USB Hosts (2.0/3.0)
* Reading the Device Descriptor succeeds after lock-up, Device Status doesn't.
* Attaching to the process after lock-up I can reliably see that ITTXFE (IN Token received when TxFIFO empty) flag is set on IN Endpoint 1
Compiling the official USB-HID examples https://github.com/riscv-mcu/GD32VF103_ ... /HID_Mouse and this CDC example https://github.com/fabiopjve/ULWOS2/tre ... inal_GD32V doesn't lead to this lock-ups. Both use the official Driver from the GD32VF103_Firmware_Library. So I'm confident that this isn't a hardware problem, but a bug with the OTG peripheral.
So far I tried to isolate the bug and read multiple bug reports on the OTG peripheral on forums e.g. (https://community.st.com/s/question/0D5 ... 1stm32f413) to find the root cause, but had no luck. I started to compare the official OTG driver to the ChibiOS driver but this didn't lead to any new clues at the moment, but I am sure that I am missing something.
My questions are: Does this bug seem familiar? Any ideas what could trigger this behaviour? What could I do to find the cause?
Thank you!
