• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 73 subscribers
  • Views 2604 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 239574
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 DK running ble_app_uart_c disconnects 6 seconds after connecting to peripheral error code: 0x08

EricDelangis

We have an nRF52 DK system running ble_app_uart_c example code and communicating with a peripheral device.  We setup a second development system using another nRF52 DK system running the exact same code as the first system but after about 6 seconds after a connection we get a timeout error 0x08 and it disconnects.  

I've tried changing the clock accuracy settings as you describe above but no effect. 

<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8
<info> app: Connecting to target 520822071920
<info> app: ATT MTU exchange completed.
<info> app: Ble NUS max data length set to 0x14(20)
<info> app: Discovery complete.
<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8
<info> app: Connecting to target 520822071920
<info> app: ATT MTU exchange completed.
<info> app: Ble NUS max data length set to 0x14(20)
<info> app: Discovery complete.
<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8

You can see from the debug window that we are stuck in this loop.

We are also running the exact same development configuration on both systems:

SDK 15.3

Segger SES V 4.10

nRF DK PCA 10040

Please advise.

  • 0

    Hi Eric

    I think this timeout is caused due to the bonding information still being stored on your peripheral, as the two centrals are trying to connect to the same peripheral, correct?

    If you connect using the "working" central, you should be able to delete the bonding information of both devices from there, and then the peripheral will be open for business with both centrals. Keep in mind that you'll have to delete bonding information every time you want to switch which central you'd like to connect to. So if this is going to be regular in your application, you might want to implement it as part of the disconnection procedure.

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hi Simonr,

    Sorry, I wasn't clear.  Both development systems are completely independent and are each using their own nRF52 DK and peripheral, i.e. one central connecting to one peripheral.  Both centrals are running exactly the same code (ble_app_uart_c), SDK version and SES version.  Both peripherals running exactly the same code (ble_app_uart) as well. Reading some other's blog posts I've tried changing the clock accuracy settings but no effect.

    Eric

  • 0

    Thank you for the clarification, Eric!

    Very well then. Can you try erasing the flash memory and flashing the application code on both the peripheral and central that won't connect just to make sure this isn't a bonding information issue? If that doesn't work, are you able to connect to any peripherals what so ever using the "faulty" central? We need to confirm whether the issue is in the central or peripheral device. Also, which LF clock are you using? The external LF crystal or the internal RC oscillator?

    Best regards,

    Simon

  • 0 in reply to Simonr

    Hi Simonr,

    I'm not sure, but I don't believe that the Nordic UART service supports bonding.  If it does, I haven't been able to bond with any devices running the UART service.  Am I wrong?  Also, we use the default LF crystal settings on the development boards.  I am in the process of setting up a third development system that will be independent of the first two.  I'll let you know.  I haven't tried erasing the memory and re-flashing yet.  I'll do that shortly.

  • 0

    Hi Eric

    You're right of course, the ble_app_uart_c examples don't include bonding from scratch, but you can modify the example to do so if you'd like. My bad that I initially jumped to that conclusion.

    Can you tell me more about your peripheral devices? Are they DKs as well, and are they running an example code or custom code? Are the two/three peripherals the same devices as one another. Also, please update me on the status of the third set up as well as the memory erase.

    Best regards,

    Simon

Related
Terms of service