OAK-Som-Pro USB connection.

PeterMilani

Hi All,

just trying to finalise a schematic for Som-Pro integration with another compute som, such as a RPi CM4. I'm connecting via USB 3.1, but its all entirely on the board, ie the CM4 and the OAK Som share the same carrier board.

Looking at the example of the FFC-4P, and doing some reading, I don't think that I'll need to really add any filtering caps or chokes, or esd diodes. I also don't think I need the USB Mux Switch or Controller, I've seen them on a few different schematics, but for a straight 1:1 matchup of ports I don't think they are needed either?

Is omitting these components a reasonable assumption? Also I assume the OAK-Som is fix in device mode with the USB*OTG*ID pulled low?

erik

Our EE team will take a look into this tomorrow, I hope that works.

PeterMilani

That sounds great!

erik

Hi @PeterMilani ,
From our EE team:

You can connect both USB 3.1 ports to each other between different SoMs. Just be careful, that you connect TX from one side to the RX on other side and vise versa. USB 2 lines should just go straight, no crossing needed.
No muxes/switches needed. Except if the USB2 is needed for flashing/updating device, then a MUX/Switch for USB2 lines is needed. Default should be routed to the connector and then switched in SW once booted.
Caps should be placed on both sides, usually close to the TX pins. But this depends, if the capacitors are not already populated on the SoM. If they are, then they are not needed to be populated on the carrier board.

PeterMilani

Thanks a lot @erik, just to clarify, does the OAK-Som-Pro require flashing and or updating. I know, the luxonis OAK devices do update the firmware during use (ie, not explicitly from an operator intervention) as the core is updated. Is this the kind of flashing updating they are referring to? Therefore does this mean that the MUX/Switch for the USB2 lines is required in all cases? And only the D- and D+ require the mux, not the super speed lines?

jakaskerl

PeterMilani
There is flashing/updating of bootloader which can be used to place the device in standalone mode. Otherwise you don't need to use it. By default, bootloader is not present on the SOM I think.

cc @filipjeretina on the second question and to confirm.

Thanks,
Jaka

PeterMilani

Hi @erik, just a little confused regarding the switch… is this just to interrupt the USB2 signals to the SoM, ie switching away from the default device? If so, is this something I would explicitly need to trigger using a generic io port to do the selection or is there a pin in the USB2 implementation that would handle this automatically?

If not, in what instances would this be necessary, ie when would I need to trigger this, at the start of a OAK-AI program? In this application we're applying, power cycling would be fairly regular, would that be sufficient?

PeterMilani

Hi @erik, is it possible to shed some light on the queries above?

filipjeretina

Hi @PeterMilani
Just to clarify on the USB2 MUX. If the USB 2 bus is only connected between two devices: from RPI to SoM (not further, for example to a port for outside communication), then a MUX is not required.
Hope this clears things up for you.

Thanks,
Filip

PeterMilani

Okay, thanks, for simplicity, for an external connection, I've used a separate USB3 device. So I think I should be good. Thanks for clarifying.