I played around with some C# code to test all Cerbuino features. After some testing I created unintentionally a VS project file (does nothing useful except some test code) which brings the cerbuino to be corrupted after starting a Debug Session from VS. I tried to have a breakpoint just on the first line without success…
Cerbuino has to be plugged off and on again and then is not recognized anymore by the computer.
I have to use DFU Tester to flash Loader and Firmware again to repair it.
This issue is replicable, it happens every time I try to debug my VS project… I haven’t found out what in this project cause this issue. I added lots of assemblies. Maybe it has something to do with this?
Seems I cannot attach files? If GHI is interested in this issue I can send them the VS project file via Email? Please let me know where to send…( I only have address of Gary. Can I send it to him?)
There’s a thread running within the CLR that handles communications to the debug engine on VS on your PC. If you deploy something (including “good” user code, but also “bad” code like you talk about) the CLR may not give that thread sufficient time to allow you to do any debugging or deploy a new app.
This is not uncommon. Often, it’s suggested you put some form of “wait” in your application while you’re debugging / developing, to allow the debugger time to connect - often a thread.sleep(2000) or a wait for button press are acceptable. There are two other workarounds that can also assist rather than going to STDFU; the first is when you’re attempting to deploy the next iteration of your app, hit reset when the “Iteration N” is counting and hope that the debugger thread gets enough time to start the deployment; another is connect to the device with MFDeploy and try erasing the application, but this often harder to get working, and usually reverting to booting into loader mode and redeploying the firmware is quickest.
Thanks for you answer. I understand this. But I made some further tests to nail down the issue:
I have a blank Console Application with only Thread.sleep at the beginning…
If I add System.Security as “Reference” then this issue begins to happen. Starting the debugger hangs forever. Cerbuino is not recognized anymore as USB device. So I have to flash it again…
@ Alex111 - We will look into why adding that reference causes the board to die for the next release. Usually unsupported functionality throws that exception.