ble_driver.py Failed to open. Error code: 3

[fmar]

Hi Nordic Support,

I'm getting this error while trying to connect two 52840 DK, one programmed with the connectivity firmware, and the other one with a sort of ble cli.

Complete error message:

ble_serial.py --com com3 --snr 683356557 --family NRF52 --name "Diapason DK215"
Board already flashed with connectivity firmware.
Socket created
Socket bind complete
Socket now listening
Connected with 127.0.0.1:60774
Traceback (most recent call last):
File "M:\nsapps\ncs\nRF5_SDK_17.1.0_ddde560\examples\FM\FM Diapason\pca10056\s140\ble_serial.py", line 242, in <module>
b = BLE_Serial(comport, args.name, conn)
File "M:\nsapps\ncs\nRF5_SDK_17.1.0_ddde560\examples\FM\FM Diapason\pca10056\s140\ble_serial.py", line 96, in __init__
self.adapter.driver.open()
File "C:\Python27\lib\site-packages\wrapt\wrappers.py", line 645, in __call__
args, kwargs)
File "C:\Python27\lib\site-packages\pc_ble_driver_py\ble_driver.py", line 127, in wrapper
raise NordicSemiException('Failed to {}. Error code: {}'.format(wrapped.__name__, err_code))
pc_ble_driver_py.exceptions.NordicSemiException: Failed to open. Error code: 3

Please be aware that:

1. the error comes out when connecting (putty) to 127.0.0.1:8889

2. the --com,  --snr,  --family  parameters for the 1st DK  are correct, as well as the  -- name for the second DK.   The two DK are connected and show up properly as CDC UARTs

3. the second DK (running the ble cli) works perfectly, and its ble cli can be connected to through the bluetooth low energy app.

4. the second DK is advertising  when connecting (putty) to 127.0.0.1:8889

5. the ble_serial.py I use is an exact copy of nRF5_SDK_17.1.0_ddde560\examples\ble_peripheral\experimental\ble_app_cli

6. Python 2.7.18, Windows 10, rRFConnect SDK v1.9.1

7. this setup was working before my holidays, all commands are saved in unmodified batch scripts to avoid typing errors.

8. I did not change any source code, and (at least voluntarily) I haven't updated anything.

9. Using the example ble_app_cli the error message is the same

Any idea?

Thanks.

[tesc]

Hi,

1. the error comes out when connecting (putty) to 127.0.0.1:8889

Does it work with other terminals than PuTTY?

Have the PuTTY terminal settings somehow been changed?

2. the --com,  --snr,  --family  parameters for the 1st DK  are correct, as well as the  -- name for the second DK.   The two DK are connected and show up properly as CDC UARTs

If you know the --snr, specifying --com shouldn't be necessary. Note that com might change on Windows, so double checking com (for both boards and for PuTTY connection settings) could be a good idea.

5. the ble_serial.py I use is an exact copy of nRF5_SDK_17.1.0_ddde560\examples\ble_peripheral\experimental\ble_app_cli

6. Python 2.7.18, Windows 10, rRFConnect SDK v1.9.1

I am a bit confused, which application runs where?

Please note that pc-ble-driver-py builds on pc-ble-driver which again uses connectivity firmware based on the ble_connectivity example of nRF5 SDK. See Compiling connectivity HEX files for details.

7. this setup was working before my holidays, all commands are saved in unmodified batch scripts to avoid typing errors.

Then something outside of what's in those batch scripts could have changed, such as e.g.:

• Python version
• COM port mapping
• Firmware on the board

8. I did not change any source code, and (at least voluntarily) I haven't updated anything.

Maybe something has automatically updated, or the COM mapping is different after a reboot, etc.

Regards,
Terje

[fmar]

Thanks for the reply.

The error was not related to putty, and its (putty) settings were unchanged. Python version is the same, as well as com port mapping and firmware on the board. 

Ugly to say, the error disappeared today without any change, except for a damn windows update.

[tesc]

Hi,

The main suggestion from me then, is that something was wrong with windows and/or the PC side serial drivers, which a restart of the computer solved.

I see you use DKs, which means the programmer MCU on the board is used as a bridge for USB to UART communication. If you haven't done so already, it is recommended to turn off the MSD feature. See SEGGER J-Link-OB Issues for details on how to do this. If MSD is enabled, the device will appear as a mass storage device, and Windows might try to do things with it such as reformatting, which will interfere with normal operation.

Regards,
Terje