Just a joke!
Got this while debugging USB CDC, Windows was not happy after halting the stm32, complaining with a "What Da F*** violation" message
.
Messing with USB development is a reliable method to see a bluescreen on W7..10. The best solution is to have the USB host separate from the machine that runs the IDE. I am not sure whether a virtual machine might suffice, I suppose not.If you only have one machine available, just reduce the number of running apps and open documents to a minimum and do regular backups.
I know! It was just a joke!
Playing with CDC, I programmed the stm32 while the terminal was open , went *bang*.
I usually unplug the USB before doing so, but I forgot that time
When doing USB development, I'd highly recommend Linux. I've managed to get the USB controller to get into an error state, but I've never had a kernel panic. Furthermore, the error messages in dmesg are way more helpfull then Windows just saying "something is wrong".
agreed. Though I have had Linux do 'weird stuff' - USB controllers/busses ending up off in the weeds, essentially requiring a reboot. At least you have an opportunity to examine things a bit first though
Same here... I haven't crashed linux, but I've crashed the hardware multiple times. The worst required full power cycle of standby power, just power down and power-up did not help.
Once I get the thing working under Linux, only then I start to try windows. First in a VM under Linux host (easier to debug), then native.
* When using a desktop computer, better have a way to shut down the machine in a proper way without loosing too much work if the keyboard and mouse disappear (ie VNC from another machine).
* Test on different machines. Machines with EHCI and XHCI behave somewhat differently in some corner cases.
I'm such a butterfinger I always use an USB isolator when programming/developing my own microcontroller stuff.
I know the USB bus is supposed to handle e.g. indefinite-duration VUSB-GND shorts, but with my luck, my particular hardware would just release the magic smoke...
In Linux, there are some default udev rules (that cause the devices to be used or at least probed by different services; a particularly annoying one being ModemManager) that can cause a lot of grief for unwary developers, but once you get those tamed, things become much easier, and you can even use those to your advantage. (I also object to just disabling ModemManager, because I have a 4G/LTE FrankenModem using Huawei ME909s-120 that works very well in Linux.. under ModemManager.)
As an example, I have a script I use when dealing with Pro Micro clones (the ones that look like SparkFun's Pro Micro, but use Arduino Leonardo bootloader, and have an ATmega32u4 microcontroller with native 12 Mbit/s USB on it). You see, if you do something that does not enable USB Serial, you need to reset/power cycle the MCU to reprogram it, but at that point the device can get re-enumerated (appear as a different port, that is). Mine outputs (showing it in the status window in Arduino) that it's okay to reset the board now, and then waits until the device vanishes, and reappears, calling avrdude (which does the firmware upload) with the new port details. Works like a charm.
No, I'm not saying Linux is any better. I'm just mentioning a nasty hurdle many have stumbled on Linux, and while annoying, taking a closer look at the details can give you the knowledge to build tools that make life easier, no matter what your OS. Me, I'm happy to release the magic smoke of a $5 microcontroller, as long as my computer is protected from my fumblery; the USB isolator is golden for that (and that too is a $10 clone off eBay).