As a baseline, when I use the stock firmware (which is not fully open, which is making it hard for me to set up how I want), USB works. I have an app which creates a USB serial port and sends stuff. The host enumerates, I can connect to the port, and I can see the data it's sending. So the hardware is working.
I cloned ChibiOS from GitHub and checked out version 20.3.2. The testhal/STM32/STM32F2xx/USB_CDC app seemed like a good place to start. There's no native support for my board, so I decided to start tweaking the ST_NUCLEO144_F207ZG as it's pretty close. You can see the changes I made relative to GitHub commit ffe54d63c here: https://pastebin.com/ZChgKC2A
- * The board has an LED on A15, so I changed that pin's configuration.
* The board uses PB14/PB15 for the USB port according to the schematics, which correspond to OTG2 on the datasheet, so I set up the alternate behavior on those pins, and tweaked the app to use USBD2 instead of USBD1.
* According to the documentation of the WICED module, there's an onboard 26mhz crystal, so I set up the clock and PLL configuration for that.
* I made it possible to set RTCPRE to 0 (more on this below)
I have a ST Link and I can connect to the board with gdb, so I can inspect things, both with the stock firmware, and the ChibiOS demo.
For the PLL config, I was able to connect to the running board with an ST Link and read out the RCC registers. I configured ChibiOS to behave identically. (In particular, the stock firmware sets RCC_PLLCFGR PLLM to 26, which is consistent with the module documentation, so I do the same.) This did require changing some of the validity checks in hal_lld.h. This seems safe, as RTCPRE is (according to the datasheet) only used when RCC_BDCR RTCSEL is set to HSE, but in my configuration, it is set to NOCLOCK, same as the stock firmware does.
I also confirmed the GPIOB_* register bits for PB14 and PB15 are identical.
I tried setting breakpoints in the interrupt handler, and ask far as I can tell, the reset interrupt gets set, but then no other interrupts ever happen. In particular, GINTSTS_ENUMDNE is never set.
At this point, I'm stumped. How should I proceed to debug why USB isn't working? I don't have any kind of hardware capable of debugging the USB traffic itself, so that isn't an option. Is there something else I should try?
