This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 BLE disconnect after 2 minutes

I have a custom board with nRF52840 (with SDKv17.0.0 + s140_7.0.1). I'm making a BLE peripheral out of it, but it disconnects after 2 minutes. Things seem to work fine during these two minutes and I'm able to stream notifications. I don't believe it's a connection interval issue since the central (Android tablet) works fine with the same connection interval (8.25ms) on a custom nRF52832 based board that also acts as a peripheral. (In fact, the nRF52840 FW is just a port of the nRF52832 FW, so they are quite similar.) I'm using the same 32MHz xtal (US3200005Z) and 12pF load caps on both boards (based on 8pF*2-4pF). The 32kHz clock is different on the two boards though. I'm using an xtal on the nRF52832 board but the SiT1572 on the nRF52480 board. I did the appropriate setup code shown here for the external osc and also tried using the internal RC osc, but they made no difference in the disconnect, so I'm thinking that the 32MHz xtal is the issue. I was unable to do any logging with my JLInk since I need to update by nRFgo Studio SW (nrfjprog is showing "error: does not match the device connected") due to an issue with my PC, but I'll try to get the disconnect message as soon as my PC is updated tomorrow. In the meantime, any advice would be appreciated. Thanks!

  • Are you basing your work on a Nordic example?

    Lots of the Nordic examples do go to sleep after something like 2 minutes - have you left that in ... ?

  • it is a custom FW (that is based on the HRS example). It does not go to sleep nor disconnect on my nRF52832 system, so I don't expect it to disconnect on the nRF52840 system either.

  • The unmodified HRS example shouldn't disconnect after 2 minutes. Does it do that in your case?

    Possible reasons:

    -As says, most examples go to sleep if they don't connect within a couple of minutes (180 seconds to be accurate). This comes from the advertising timeout event. So if you e.g. added support for more connections, and start advertising after you have connected, and this advertisement times out the timeout event may still trigger sleep mode (which is basically turning off the chip). Perhaps this is what's going on?

    -Another reason may be that the peripheral doesn't like the connection parameters (connection interval is not within the min-max settings), and the peripheral decides to disconnect after a couple of retries.

    -Some other kind of timeout.

    Can you please check the log from the nRF? Do you see the disconnect event, or do you just see a reset?

    If you see a disconnect, can you please check the disconnect reason? (Let me know if you don't know how to check this on the nRF. It should be mentioned in a fair amount of tickets here on DevZone).

    Best regards,

    Edvin

  • It was an application error in my port from the nRF52832 board to the nRF52840 board. The power management chip had changed and I had changed some startup code incorrectly, leading to a call for advertising to restart, and hence the disconnect. RTT Viewer showed NRF_ERR_CONN_COUNT, helping me to trace down this error. Thanks for your tips in looking for application rather than crystal issues.

Related