Nicla Vision USB CDC driver

Arduino Boards
#1

Hello,

This might be the wrong place to ask, but I’ll try as this forum has somewhat more activity than the Arduino forum when it comes to the Nicla Vision. I’m trying to use the Nicla Vision bare metal as I’m developing an application where I would like to have as much control over my own firmware as possible and there are some quite tight realtime requirements. I do not really need the MBED layer in the Arduino Core and the general workflow just suits me better with just a plain project with a makefile.

Anyways, I’ve currently been attempting to create a driver for USB to enable CDC (with the help of libusb_stm32). I’ve modified libusb_stm32 for the H7 and ULPI, and I’m seeing some response when I’m connecting the board, but it doesn’t seem to deliver the setup address. I’ve triple checked the pins to the transceiver and I’m able to receive the request for the setup address, but then it seems like the board isn’t responding back with an ACK.

The kernel messages from my computer reports that the high-speed device is detected, but that it doesn’t respond to the setup address. It then tries several times to resend that frame, power cycle and then it finally gives up and reports that it is unable to enumerate the device.

I don’t currently have a debugger available, but from the debug messages printed over UART this is what happens, where event 0 is reset, 1 is start of frame, 1 is suspend and 6 is setup. So from what I can tell, the MCU receives the request to setup and from within libusb_stm32 is providing the ACK, but somehow it doesn’t seem to propagate to the physical lines.

Process evt: event: 2, endpoint: 0
Finished processing evt: event: 2, endpoint: 0

Process evt: event: 0, endpoint: 0
Set process reset
Finished processing evt: event: 0, endpoint: 0

Process evt: event: 6, endpoint: 0
Process ep0: event: 6, endpoint: 0
Process eprx: 0, device control state: 0
Process eprx 2: 0, device control state: 0
Setting address: 6
ACKING request type: 0 for ep: 0
Finished processing evt: event: 6, endpoint: 0

Process evt: event: 1, endpoint: 0
Finished processing evt: event: 1, endpoint: 0

I realise it’s a bit far stretched to be able to give any insights about this without any more code, but if anyone has any idea what could be causing this I’m more than happy to provide some more information or code.

#2

Hi, we’re not going to debug your custom driver.

HOWEVER, you can read our working USB CDC code and try to figure out what the difference is.

In general working at this level… you basically have to do it by yourself. But, given we have working code it shouldn’t be impossible to find where the issue is.

#3

Hi, thanks for the reply. I’ve ported over to a similar structure as within OpenMV with the use of the HAL drivers and the USB middleware from STM. Still seeing the same issue with he device not responding to the setup address though, so I guess I just have to investigate some more.

#4

Hello again, I’ve decided to try to make my USB driver as identical as possible with the one within OpenMV and the device is being registered now :slightly_smiling_face: However, it is only registered after I enter dfu-mode by double clicking the button on the board and then flashing my code. If I then restart the device by clicking the button the same problem with the setup address occurs.

I totally understand that I’m on my own with this as it isn’t related to OpenMV, and I appreciate all the help I can get. I was just wondering if you’ve seen something similar doing development of the firmware. Any obvious gotchas or something alike. For me it seems like some clocks for the USB are being set up correctly by the dfu-mode, which isn’t the case when the device goes directly into my code without going into dfu first. Currently the USB peripheral is clocked directly from HSI48, which seems to be the same you’re doing in OpenMV from the boardconfig of the nicla.

#5

You might want to open up a UART or use a jtagger to debug the board to print out info on what it is doing.

#6

It was the clock configuration. Got it working now :slightly_smiling_face:

1 Like