There's a catch

_Peter · April 22, 2016, 11:09am

Are USB and NetMf ever gonna be buddies ?

github.com/NETMF/netmf-interpreter

Correct code with wrong call to USB_OpenStream

NETMF:dev ← josesimoes:patch-2

opened 02:07PM - 20 Apr 16 UTC

josesimoes

+11 -4

If USB_ALLOW_CONFIGURATION_OVERRIDE is defined and the call to USB_Initialize ha…s a debugger port in the argument, USB_OpenStream is already called there (@ line 265). After a successful return from Initialize the call to USB_OpenStream will fail because the stream is already opened. Note: I've stumbled onto this when debugging the CMSIS USB driver I'm working on. The result is that the USB device is enumerated and shows in the device manager but it's not picked up by MFDeploy or VS because after the initial enumeration the USB module is too busy being initialized again and again. This may explain the behaviour reported in issue #376. The root cause is that the call sequence (...) DebuggerPort_Initialize -> USB_Initialize is repeated over and over from CLR_HW_Hardware::ProcessActivity() because the debugger port never has the chance to initialize. This is not 100% repetible. It seems to occur only if the USB init falis for some reason when sending the initial debug ping message, which call the above sequence. After that the ProcessActivity() starts calling that sequence again and most likely a race condition occurs with the USB stream.

…there seems to be a start…