connectivity firmware and pc-ble-driver issues

[Tavish Naruka]

Hi,

I have two problems with pc-ble-driver, I've tested hrc_v5 example program on my Linux machine, along with connectivity_2.0.1_115k2_with_s132_5.0.hex firmware (using https://github.com/electronut/ElectronutLabs-bluey/ which has same RX/TX pins etc.), and it seems to work. However the same combination is not working on mac OS, it fails with 'Failed to open nRF BLE Driver. Error code: 0x0D', baud rate is the same on both sides. What might be the issue in this case?

Second problem is with building the connectivity firmware. I download sdk 14.0.0 (using the bootstrap script), and apply the patch using 'git apply --directory=. -p1 --ignore-whitespace ../../hex/sd_api_v5/sdk140_connectivity.patch' (which the bootstrap script fails to apply). I write this firmware by first erasing the chip, then writing softdevice and then the generated firmware 'pca10040/ser_s132_hci/armgcc/_build/nrf52832_xxaa.hex'. This is presumably the same firmware as above afaik, with the bad rate 115200, but it does not work with hrc_v5 binary. Is there any difference between this and the pre-built hex file?

Thanks

[Jørgen Holmefjord]

Hi,

I will check with the developers if the first issue is a known issue, we have gotten at least one report on the exact same issue recently. I will get back to you as quickly as possible with the response from the developers.

I'm not able to run the bootstrap script either, I will report this issue. When you apply the patch manually, please make sure the changes are actually applied to the files. When I tested this, git apply seems to succeed, but no changes are made to the SDK. It looks like there is an issue in git that will not allow you to apply patches from other repos inside a cloned repo. I had to use the method described in this post.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

The pc-ble-driver library is written for use with SEGGER J-Link devices. The J-Link OB firmware have a flow control sensing mechanism that will enable HWFC if it is detected on the other side. In the example, the flow control is set to none, but in the connectivity firmware, HWFC is enabled. If the serial to USB chip on your board does not support this automatic sensing, you might get error or unstable connections. Please try to modify the example to use flow control in line with the connectivity firmware.

We have confirmed that there is an issue with the bootstrap script on Linux (it works on Windows, where we build the connectivity firmware). The issue seems to be related to line endings in the SDK. A workaround is to run dos2unix on the whole SDK (or at least the files that will be patched). This can be done using the command "find . -type f -print0 | xargs -0 dos2unix" from the root of the SDK directory. You can then apply the patch using the command "patch -p1 --binary < ../../hex/sd_api_v5/sdk140_connectivity.patch". We will try to find a better solution and fix this issue in our bootstrap scripts.

Best regards,
Jørgen

[Tavish Naruka]

Regarding the patch, I can apply it now with your dos2unix suggestion, but the firmware doesn't build still. Firstly I had to disable `-Werror` because of

Compiling file: conn_mw_ble_gattc.c
../../../../../../components/serialization/connectivity/codecs/ble/middleware/conn_mw_ble_gattc.c:53:0: warning: "BLE_GATTC_WRITE_P_VALUE_LEN_MAX" redefined
 #define BLE_GATTC_WRITE_P_VALUE_LEN_MAX    (GATT_MTU_SIZE_DEFAULT - 3)
 
In file included from ../../../../../../components/serialization/connectivity/codecs/ble/middleware/conn_mw_ble_gattc.c:42:0:
../../../../../../components/serialization/common/ble_serialization.h:169:0: note: this is the location of the previous definition
 #define BLE_GATTC_WRITE_P_VALUE_LEN_MAX    (247 - 3)

and also at link time, the RAM section is overflowing, and I tried to see if `-Os` or link time optimizations make any difference, but it still fails with `/home/tavish/embedded/bluey/gcc-arm-none-eabi-6-2017-q1-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack`. I'm not sure if compiler version should make any difference in RAM usage in this case, but I also tried with the version used in SDK docs, same result `gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack`.

[Bjørn Inge]

Thanks for the input. We're not seeing any error message about RAM overflow when compiling in Keil. However we will check and see if there are any hidden issues, and if any values are oversized.