This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nrf52-dk in nrf52805 mode, sending long BLE UART command works on DK, not on external chip

Hi all,

I'm a beginning hobbyist with nRF52. I'm programming a BC805m using my nRF52-dk and nRF Connect SDK v1.9.0 (zephyr & Segger Embedded Studio).

The learning curve was quite steep, but I'm 99% done with my project. There is one issue remaining.

My project is a key fob to turn on an e-bike over BLE. There are three commands: A) turn bike on, B) turn bike off, C) toggle lights. These use two different GATT services. A+B are done by sending a single byte via a device specific GATT service. C is via the standard UART over BLE GATT service.

On the DK (even in 52805 mode) everything is working great.

On the external module, A and B work great. C does nothing. There is no error. This is the code snippet that I'm using (the exact same code and config are working the nrf52-dk in both 52805 and 52832 mode).


static void function toggleLights() {
    uint8_t d[] = {0x0A, 0x10, 0x00, 0x01, 0x00, 0x01, 0x02, 0x00, 0x00, 0xd4, 0xb1}; // off
    bt_gatt_write_without_response(default_conn, 0x38, d, 11, false);
}

The only configuration change I had to make for the external module to work was to use CLOCK_CONTROL_NRF_K32SRC_RC as there is no external crystal attached to the BC805m.

Can someone point me in the right direction to start debugging this? Let me know if you need more information.

Edit 1: Via the debugger I've confirmed that the handle (0x38) is the same on the BC805m module.

Edit 2: For reference, this is the function that does work on both modules.

static void bike_turn_off() {
    uint8_t d[] = {0};
    bt_gatt_write_without_response(default_conn, 0x19, d, 1, false);
}

Thank you!

Jouke

  • Hi Jouke, 

    I don't think using 32kHz RC clock source would cause the issue that you have. 
    I would suggest to use a sniffer to capture the packets so we can check if they actually got corrupted and to check if the peer device actually received them correctly. 

    Please try to capture the trace for both the DK and the BC805m. 

    Could you give more information about the central ? Is it a phone or another nRF52 ? 

  • Thank you, will try to get the sniffer to work! It's protected with level 3 security, so that makes it a bit hard.

    The key fob is actually the central, see this picture (but then a BC805M instead of BT832A, the BT832A has the same problem). The e-bike (a Cowboy - https://cowboy.com/ ) is the peripheral.

     

  • The sniffer is pretty neat! However, even with debug keys and BT_SMP_ENFORCE_MITM disabled, I can't get to sniff the data after the pairing sequence. According to the docs it should be automatic with debug keys. I've tried filling in the debug private key  from the BLE 5.2 spec manually ( 0x3f49f6d4a3c55f3874c9b3e3d2103f504aff607beb40b7995899b8a6cd3c1abd ), but it's not working yet. Any pointers?

  • Aha, level 3 security is actually not SC (aka LESC) but Legacy. Using "Legacy Passkey" I'm able to sniff the traffic. As I have only one nrf52dk I can not sniff successful traffic from that, but I did compare it to my phone (had to re-pair for the sniffer to pick up the encryption key). Will investigate and post results / questions here once I get further.

  • successful-phone.pcapng

    failed-bc805m.pcapng

    Hm, I'm stumped. Here are two pcap files, one successful from my iPhone, the other unsuccessful from the bc805m. Check out the writes to handle 0x38. I modified the code a bit to try with/without the command flag in the ATT write, but it seems not to make any difference.

    I can't find the difference between the iPhone commands and the bc805m, but the iPhone works, and the bc805m does not!

Related