I’ve tried getting the FEZ Cerb40 board to work in a Virtual Box environment (Guest: Windows XP x86, Host: Ubuntu x64). Flashing the tiny booter image via the STDFU Tester works without any problem, but as soon as MFDeploy comes into action, the whole thing gets messy.
Neither flashing the firmware, nor just deploying any project after having flashed the firmware on a native Windows system will work within VirtualBox. Flashing will fail with a Checksum error, and deploying will fail with “Check your hardware” messages from Visual Studio.
I assume that all these errors have something to do with MFDeploy re-booting the entire device before performing any action. My assumption is that the device is first connected to the Host operating system, and all the messages sent at this time are lost/will never arrive at the guest. It seems like VirtualBox takes too long to re-attach the device. I come to this conclusion as the “Ping” action in MFDeploy takes ages to finish, and when it does, it will display only have the status message instead of the full one:
What I expected to get:
something like "Pinging … STM Electronics …"
What I got instead:
“Pinging… eron microsystems, Inc.TinyCLR”
Has anyone tried something similar, and has any advice on how to MFDeploy to work under VirtualBox? I tried different versions (4.2 RC, Stable, …), but all of them have the same issue.
Your are correct in your thinking: When MFDeploy resets the device, this causes the device to reconnect to the host OS (Ubuntu in this case), then VirtualBox would request for permission to attach it to the guest OS (which due to the secure nature of Linux as a whole, will cause it to reconnect more slowly to VirtualBox), however, if deploying out-right fails please make sure that the device is explicitly set in VirtualBox as an auto-connecting device. You should be able to work with the device the same as on Windows (for the most part), just more slowly as there are 2 separate device layers the device must now go through to get to the end-application.
I’ve tried looking into other threads regarding VirtualBox, but none of them seemed to describe and solve the same problem. I have set up USB filters within Virtualbox for automatically attaching the device, and they seem to work pretty well/fast, but apparently not fast enough. Even a generic catch-all filter won’t do any difference. An other suggestions?
If I pre-connect the device in MFDeploy using File -> Connect, I’m able to read out the device capabilities and other settings fine. But commands like e.g. Ping will still reset the device before performing any action, even if you are already connected to it – and that will fail again.
I currently figure there are two possible approaches to this: a) Somehow prevent the host OS from finishing the USB enumerate/attach, and making the Cerb think that it is not yet fully connected to a computer, or b) Changing MFDeploy so that it will not wait for the initial bootloader msg after a reset. Not sure if any of those can be done easily though.
@ matze VirtualBox will be requesting access to the device through the USB Core. If you were able to get the host OS to ignore the device, it would be literally impossible to connect it to the Guest OS. Also, simple commands like ping should not be resetting the device, and you can verify this event by plugging in the Cerb, and in terminal type:
lsusb
And you should be able to see something like:
The resulting ID will be the same, but the Bus and Device will vary. Now, load the guest OS, load MFDeploy and attempt to initiate a ping command. When you do, go back to the terminal and type:
dmesg | tail
Now, if the device is infact resetting even on a ping command, you will be able to see something similar to the following:
[quote]usb 2-1.2: USB disconnect, device number X
usb 2-1.2: new full-speed USB device number X using ehci_hcd[/quote]
This is a generic USB Core disconnect/reconnect message, and if something else in the host OS is attaching itself to the device (like NDISWrapper, for instance) you would see similar to the following right after the disconnect/reconnect messages:
ndiswrapper version 1.57 loaded (smp=yes, preempt=no)
usbcore: registered new interface driver ndiswrapper
I will also look into this and attempt to connect a Cerb to Windows in VirtualBox on my Ubuntu 12.04 box to verify if the device is resetting, and report the results.