I have built an automated test system which includes a BLED112 dongle. In order to ensure that the device is in a well-known state prior to executing the test suite, I issue a BGAPI Reset command (from System command class).
Normally everything is fine, and the device restarts OK. But occasionally (and I can't see any pattern) the device does not restart properly. It is still visible in Windows' Device Manager, but it has a yellow exclamation mark and the status says 'This device cannot start (code 10)'.
Interestingly, I can bring it back to operating state via Device Manager by disabling the device and re-enabling it. But this is not really a feasible solution for an automated regression test system.
Is this a known issue? Any solutions?
I am using latest SDK 1.3.2 and the PC is running Windows 7.
Does this older post solve your problem?
I tried to replicate your problem by issuing reset from the BLEGUI but I always saw the device re-appearing normally in the device manager.
Same problem. The referenced answer (Post: Resetting BLED112 dongle) explains the root cause, but isn't a reliable solution. It's nearly impossible to ensure that the COM port closes properly after issuing the dongle reset. This frequently prevents the dongle from re-enumerating properly. "Most of the time" is not releasable!
Brainstorming other possible fixes:
1) Dongle firmware update: add reset command/option to re-init the BLE stack ONLY - leave USB driver (and enumerated COM port) in tact. Dongle already has a "booted" event which could easily trigger state-machine reset on client side.
2) Reset dongle via the USB system: Gather device's USB info, disconnect COM port safely, then issue USB-level reset which will re-enumerate reliably. I've started to look into this, but without vast knowledge of Windows USB APIs would take me a very very long time to implement. Maybe some example code from SiLabs would speed things up!? Managed C#/C++ please!
3) Write a reset routine that issues stop/disconnect/cancel commands for every possible operation that could be happening on the dongle. Not ideal, but sometimes brute force just gets the job done.
Any other ideas? Don't be shy, throw em' out there!
I'm afraid it doesn't solve my problem. My code already does the following:
I started looking into another way of bringing the device into a well-known state. As Craiger suggests, I would issue BGAPI commands to close down all active connections, stop advertising, etc.
But I eventually ran into a different problem (http://community.silabs.com/t5/Wireless/BGAPI-Controller-Busy-error-permanent/m-p/153467) which had the consequence that no SW command, except system reset, could bring the device back into a working state.
For the moment, I am considering attaching the BLED112 to a power-switchable hub (like https://www.yepkit.com/products/ykush). That would enable me to do a real power-cycle of the device by SW.
There is also a workaround by using Microsoft's devcon tool. devcon.exe can be used to disable/enable a device like you can do it from Device Manager. I have verified that it can actually recover a dongle with the code 10 error. But it is quite ugly... And devcon.exe has to be run as administrator.
Is your application C# based? We've had some reports of customers using C# that it doesn't close the COMPort fast enough.
Yes, it is a C# application.
To be more specific, it uses the .NET SerialPort and Stream classes to perform I/O. I never thought there could be performance issues in this design.
If it is essential to close the port before the dongle re-enumerates (as stated in the other post), I could try modifying the implementation to use Win32 directly.
But the best solution in my opinion would be - as Craiger suggests - a way to reset the FW without having to close and reopen the serial port. That would be highly appreciated!
I gave this feedback to our R&D. There will be a new BLE SDK release within the coming months so I'm hoping that this will be implemented as well.
To be notified for updates you can follow the product in the BLED112 product page.
FYI I did some testing with BlueGiga's BLEGUI, and I was able to cause the same problem. However, it happens much less often than in my .NET app (took me >50 tries before the first failure). That supports the theory that not closing the serial port quickly enough causes USB enumeration to fail. The BLEGUI c++ code is more efficient so it doesn't occur as often.
Still, would be nice to have a reset method that does NOT depend upon host system performance, as that will always be inherently unreliable. Hoping the pending firmware update can find an easy way to resolve this!
It is still happening in 2018. We bought BLED112-V1 and it throws the same error. Code 10 - Device cannot start. Do you have a solution? We have all latest drivers that we downloaded today.
Is there any solution to this issue? the last driver updated on 2017 still having this issue.
Have you tried to use the latest SDK? I believe the problem Code 10 - Device cannot start has been already fixed.
Let me know the result of your testing.