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

PC-BLE-DRIVER on FENSTEL EV-BT840F (nRF52840 MCU)

I am successfully able to use pc-ble-driver on nRF52840 Preview DK using latest connectivity firmware loaded by nRF Connect.

I want to use the same functionality on FENSTEL EV-BT840 which have the same controller as nRF52840.

nRF52840 have the connectivity IC on board which is used to connect in nrf-Connect and PC-BLE-DRIVER.

In my understanding the nRF52840 is doing communication with pc-ble-driver on UART which connectivity IC on board. And nrf-connect and pc-ble-driver both able to detect that while opening port.

In EV-BT840 there are UART pins available to access. When I use that pins using TTL to USB converter and try to open the port but i get the following error

"pc_ble_driver_py.exceptions.NordicSemiException: Failed to open. Error code: 13"

Is there anything that I misunderstood or I miss to implement. Any reference to pc-ble-driver implemented on FENSTEL BT840/BT832 chip wlll be very helpful.

  • Hi Jorgen,

    I have tried all the things. But it looks like pc-ble-driver code is written for J-link Com port only and will not work with any other USB to UART chip.

    Now as you have suggested earlier, that I need to recompile connectivity firmware as per this link. After following all the steps when I tried to run it on nRF52840 PDK using its USB ports only.

     I am using SDK15 and patch from this pc-ble-driver-py branch. Right now I want to understand and run the compiled connectivity example on nRF52840 PDK using j-link com port.

    I am not changing anything in the code. Fresh SDK15 with connectivity patch. And directly compiling the example code on nRF52840 (pca10056) (with ser_s140_hci) and trying to run it on nRF Connect app.

    But I am getting same timeout errors. I have doubts on version_info which is added from the patch file. Somehow the nRF Connect is not able to match “magic_number” from the version_info.

    What could be the problem with this?

  • nRF Connect does not support S140 softdevice yet. You can still use nRF52840 with S132 v3.0 softdevices. I tested with nRF Connect v2.4.0 and connectivity_1.2.2_1m_with_s132_3.0.hex.

  • I am also trying to create hex file for connectivity firmware using s132 for nrf52832 DK board, In it, I am able to Open the port. But it fails in enabling  BLE. It gives an error like

    Enabling BLE failed. (NRF_ERROR_INTERNAL)

    Error occured when enabling SoftDevice. Errorcode: NRF_ERROR_INTERNAL (0x3) 

    I have hex files which are working on both (nRF52840 and nRF52832) DK board, But I want to do that on a custom board so, need to compile connectivity firmware for that custom board. 

    Can you point out something which can help me with this problem?

  • Have you tried debugging the connectivity firmware that you built? You should check it to make sure there is no errors putting your device into the error handler. If your UART pins are floating at some point, this could cause errors in the UART peripheral.

  • Hi Jorgen, Thank you so much for your support.

    With the help of bootstrap_sd_api_v3.sh file from S132 v3.0 softdevices, I am able to download and patch the SDK12 file and able to compile and run the connectivity firmware for nRF52840 PDK board. After changing pin configurations I am able to compile and run the connectivity firmware on FANSTEL EV-BT840 board as well. 

    I used ble_connectivity\pca10040\ser_s132_hci\ code and disabled the hardware flow control for UART. and changed the pins as per UART connected pins on EV-BT840 board. 

    From this exercise, some points got cleared and those are. 

    - pc-ble-driver is not dependent on J-link Com port. It can run on any UART ports (Hardware flow control need to enable/disable as per the implementations). I am able to run UART code from ser_s132_hci example for hardware control disabled UART.

    -  I am not able to compile connectivity firmware and run it on nRF Connect or pc-ble-driver from SDK15

    Once again thank you so much Jørgen Holmefjord for your inputs on this topic

Related