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

Third party module module BLE not working

Hi!

I just got my PCB with a Telit BlueMod+S42 Module on it (nRF52832).

I' using the LESC feature and ist works properly on the PCA1004 and on the Telit DevKit (same Module).

But when I flash my own board, I can't get BLE to work properly.

I'm using SES V3.32 with SD S132 v5.1.0.

RTT is working, and I get following output, without any hint on what went wrong:

<info> app: Initializing nrf_crypto.
<info> app: Initialized nrf_crypto.
<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: Notify observer 0x00036660 => ready
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<debug> nrf_sdh_ble: RAM starts at 0x200020E0
<info> app: Generating key-pair
<info> app: Converting to raw type
<info> app: Template example started.
<info> app: LFCLK OK!
<info> app: Fast advertising.
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected.

When using with the Telit DevBoard i get folowing output:

<info> app: Initializing nrf_crypto.
<info> app: Initialized nrf_crypto.
<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: Notify observer 0x00036670 => ready
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<debug> nrf_sdh_ble: RAM starts at 0x200020E0
<info> app: Generating key-pair
<info> app: Converting to raw type
<info> app: Template example started.
<info> app: LFCLK OK!
<info> app: Fast advertising.
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x13.
<info> app: PM EVT: 1
<debug> app: PM_EVT_CONN_SEC_START: peer_id=65535
<info> app: PM EVT: 5
<info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
<debug> nrf_sdh_ble: BLE event: 0x18.
<info> app: BLE_GAP_EVT_LESC_DHKEY_REQUEST
<debug> app: DHKEY Req by Handle: 0
<info> app: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 0
<debug> nrf_sdh_ble: BLE event: 0x1A.
<debug> nrf_sdh_ble: BLE event: 0x19.
<info> app: PM EVT: 2
<info> app: PM_EVT_CONN_SEC_SUCCEEDED conn_handle: 0, Procedure: 1
<debug> app: GAP AUTH STATUS: LESC: 1, AUTH STATUS: 0

Parents
  • Hi,

     

    Judging by your log, the link is disconnected immediately after receiving the BLE_GAP_EVT_CONNECTED.

    What's the disconnect reason?

    You can read it out like this:

            case BLE_GAP_EVT_DISCONNECTED:
                NRF_LOG_INFO("Disconnected, reason %d.",
                              p_ble_evt->evt.gap_evt.params.disconnected.reason);

     

    Also, do you have any old pairing data present on your peripheral or phone?

    it's recommended to do a "nrfjprog -e" in the case you have old bonds in flash.

     

    Cheers,

    Håkon

  • Hi,

    I'm doing Erases whenever I come across problems.

    As reason I get 62 or 0x3E, which seems to be BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

    Seems a bit generic to me though....

    Any clues?

    Thanks&Regards

    Chris

  • Hi,

     

    _FAILED_TO_BE_ESTABLISHED is normally a sign that one of the peers have lost packets during the initial "CONNECT_REQ" process.

    You can get into a scenario where you receive the request, but the central does not get the ACK from the peripheral. This can happen if the RF link quality is bad (ie: connecting at a long range), or when there is an issue with the RF layout (soldering is bad or similar).

     

    Do all BLE examples behave in this way on this particular device?

     

    Best regards,

    Håkon

Reply
  • Hi,

     

    _FAILED_TO_BE_ESTABLISHED is normally a sign that one of the peers have lost packets during the initial "CONNECT_REQ" process.

    You can get into a scenario where you receive the request, but the central does not get the ACK from the peripheral. This can happen if the RF link quality is bad (ie: connecting at a long range), or when there is an issue with the RF layout (soldering is bad or similar).

     

    Do all BLE examples behave in this way on this particular device?

     

    Best regards,

    Håkon

Children
Related