PCA10059 dongle keeps disconnecting from BLE

[Michael]

Hi All,

I am running a modified example of the 'ble_app_multilink_central_pca10056_s140' project.... I am running this on a PCA10059 dongle. The project connects fine to my peripheral device when it is running from the JTAG debugger. but when I disconnect the debugger and try to run the project stand alone the peripheral device keeps reporting back the the device have connected and then almost imediatly disconnects.

This is an example of the debug data from the peripheral.

<info> app: Connection 0x0 has been disconnected. Reason: 0x3E

<info> app: Connection 0x1 has been disconnected. Reason: 0x8

<info> app: Connection with link 0x2 established.

<info> app: Connection 0x2 has been disconnected. Reason: 0x8

<info> app: Connection with link 0x0 established.

<info> app: Connection with link 0x1 established.

<info> app: Connection 0x1 has been disconnected. Reason: 0x3E

<info> app: Connection with link 0x2 established.

<info> app: Connection 0x0 has been disconnected. Reason: 0x8

<info> app: Connection with link 0x1 established.

<info> app: Connection 0x2 has been disconnected. Reason: 0x8

Any idea why the device would run on the JTAG debugger and not stand alone (causing it to disconnect from the peripheral)??

Kind regards

Michael

[Einar Thorsrud]

Hi,

It should not normally matter if you are debugging or not.

Looking at the disconnect reasons, 0x8 is BLE_HCI_CONNECTION_TIMEOUT and 0x3E is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. Essentially the latter is what you would get if there was a timeout immediately after the central initiated the connection, so both disconnect reasons probably represent the exact same problem. The question is what causes the disconnects. A few possible explanations come to mind:

• Inaccurate clocks. This does not seem to be the case here though, as it should be independent of whether you are debugging or not.
• Firmware behaves differently when not debugging (for some reason), and enter an error state that causes a reset.
• Reset of another reason.

Can you check if the device is being reset, for instance by toggling a GPIO during startup and checking with a logic analyzer? Also, can you add UART logging (not via the debugger!) and see if you can get some sensible logging from the nRF?

[Michael]

Hi Einar

I think I got around my problem (but I'm not sure why it is fixed - maybe you can shed some light on it).....

I found that the BLE link stayed solid once disconnected from the JTAG if I use the PCA10059 dongle from an external 3.3V power supply connected to VDD Out pin (after I had cut SB2 and soldered SB1). Any ideas why this may be (as the code is the same).

Cheers

Michael

[Einar Thorsrud]

Hi,

I would not have expected to see such issues anyway, but is REGOUT0 set properly? If not, then the supply voltage will be 1.8 V (which should have been OK as long as you don't use a simple debugger). Did you set BOARD_PCA10059 instead of BOARD_PCA10056 in the Preprocessor Definitions? If you do, the firmware will set REGOUT0 correctly after the first reset. It would be interesting to know if that improves things.

[Michael]

Hi, No I have not changed the processor definitions (it is still set to PCA10056)

[Einar Thorsrud]

Hi,

I see. Can you try setting it to BOARD_PCA10059? (See nRF52840 Dongle Programming Tutorial for details).

[Michael]

Hi Okay, I will try that..... when I follow the example on how to change the processor definition, on my project it is showing inherits (shown here using the blinky project as a test for the PCA10056) - what should I do ?

[Einar Thorsrud]

You have to select the Common configuration instead of Release