pc-ble-driver compiled hex fail to work

[dwBreezi]

Hi,

I have been having issues with the compile hex files I get when following the steps to build the pc-ble-driver ().  While I am able to build the hex files when I place them on my NRF52840 they fail to work with my pc-ble-driver-js code I have.  The connectivity_1.2.3_115k2_with_s132_3.1.hex file provided at (https://github.com/NordicSemiconductor/pc-ble-driver/tree/2d97262fa9940cb815778f01af9d05093558a72c/hex/sd_api_v3) works perfectly fine though.  I would assume when I build using the source code I would get a similar file.  Is there a compile time flag that I need to use to get this file?  My generated hex file is about 200 lines longer and has an extra segment in the nrfjconnect programming tool.  Below are the commands I issued to generate my hex files after setting up the build environments on my ubuntu vm.

git clone github.com/.../pc-ble-driver.git
cd pc-ble-driver/
mkdir build; cd build
cmake -G Ninja -DASIO_INCLUDE_DIR=~/build/vcpkg/installed/x64-linux/include -DCatch2_DIR=~/build/vcpkg/installed/x64-linux/share/catch2/ ..
cmake --build .
cd ../hex
mkdir build; cd build
cmake -G Ninja -DCOMPILE_CONNECTIVITY=1 -DCONNECTIVITY_VERSION=1.2.3 ..
cmake --build . --target compile_connectivity

[tesc]

Hi,

You should only need to compile the connectivity firmware yourself in special cases such as when you need to run it on custom hardware or you need some custom functionality. Otherwise you should use the precompiled hex files.

If you need to compile the connectivity firmware yourself, then these are the instructions you should follow: Compiling the connectivity. hex files.

Regards,
Terje

[dwBreezi]

Are these steps not done in the build process listed out at (https://github.com/NordicSemiconductor/pc-ble-driver)?  I would assume it is since the mergehex environment variable needs to be set.  Also the generated hex files have similar names as the final mergehex nomenclature listed in your example such as connectivity_1.2.3_115k2_with_s132_3.1.0.hex . 

I am doing my build on Linux.  Is Windows the recommended environment I noticed the the msi files in the zips you linked to?

I was testing building the base hex files since I do have some hardware that needs tweaks to the hex file to work but thought I would get the base correct first.

[tesc]

Hi,

The current version of pc-ble-driver-js uses an earlier snapshot of pc-ble-driver. If you check out the current master branch you will get connectivity firmware that is too new for pc-ble-driver-js v2.5.1.

The build process has changed recently, and the link in my previous answer goes to the older commit to be used with pc-ble-driver-js v2.5.1 (and also with the current pc-ble-driver-js master branch.)

The msi files in the nRF5 SDK are only for when you use one specific toolchain. The SDK is cross platform, as are also pc-ble-driver and pc-ble-driver-js. There are shell scripts under <pc-ble-driver directory>/hex/sd_api_v<api version>/, which will download the SDK, apply the patch, and build the appropriate connectivity firmware.

Regards,
Terje

[dwBreezi]

Ok, I see what you mentioned above.  So to build the corresponding hexes with an api that plays with the pc-ble-driver-js interface I did the following.

git clone github.com/.../pc-ble-driver.git

--to get to the same branch referenced above

git checkout 2d97262fa9940cb815778f01af9d05093558a72c

-- make the build file

cmake -G Ninja -DASIO_INCLUDE_DIR=~/build/vcpkg/installed/x64-linux/include -DCatch2_DIR=~/build/vcpkg/installed/x64-linux/share/catch2/ ..

-- do the build

cmake --build .

cd ../hex

mkdir build; cd build

cmake -G Ninja -DCOMPILE_CONNECTIVITY=1 -DCONNECTIVITY_VERSION=1.2.3 ..

cd sd_api_v3

--apply the pathces

./bootstrap_sd_api_v3.sh

cd pc-ble-driver-master/sdk/nRF5_SDK_12.2.0_f012efa/examples/ble_central_and_peripheral/ble_connectivity/pca10040/ser_s132_hci/armgcc

--compile the hex

make clean; make 

--merge the connectivity hex and soft device hex

../nRF-Command/mergehex -m /home/dwoot/build/pc-ble-driver-master/sdk/nRF5_SDK_12.2.0_f012efa/examples/ble_central_and_peripheral/ble_connectivity/pca10040/ser_s132_hci/armgcc/_build/nrf52832_xxaa.hex sdk/nRF5_SDK_12.2.0_f012efa/components/softdevice/s132/hex/s132_nrf52_3.0.0_softdevice.hex -o my-s132-hex.hex

Once I finished all of the steps above I ended up with a hex file that was still larger than the precompiled one that is provided and did not work/match.

Do my steps above look correct for how the build process should work?  

[tesc]

Hi,

Regarding SoftDevice version you should use s132 v3.1. You can use the one provided in the hex/ folder of pc-ble-driver.

Apart from that, it looks to me this should be the correct approach, yes.

Can you attach the connectivity hex file (before being merged to the softdevice) for me to test?

Regards,
Terje

[dwBreezi]

Thanks for that suggestion about the s132 v3.1 it was not included in my hex folder I had copied down from git.  I had a version that was built on the master branch and found the SoftDevice in the hex folder there.  Unfortunately my generated hex file using that soft device still was not a working version.  The size actually grew it seemed and was 30kb larger than the hex included in the solution.  

I attached the connectivity hex file generated in the sdk/nRF5_SDK_12.2.0_f012efa/examples/ble_central_and_peripheral/ble_connectivity/pca10040/ser_s132_hci/armgcc/_build folder.  Let me know if there is anything else I can answer.

Thanks,

Derek 

5238.nrf52832_xxaa.hex

[tesc]

Hi,

Instead of the master branches for pc-ble-driver and pc-ble-driver-js you should use proper releases. Otherwise you may get partial functionality and/or it may be difficult to find the correct combination of pc-ble-driver, pc-ble-driver-js and connectivity firmware. Up until now, pc-ble-driver-js has included the right commit of pc-ble-driver as a git submodule, which means that is the preferred way to get the right version of pc-ble-driver and connectivity.

Looking at the hex file that you provided it is evident that the version_info_t data structure is not present. Can you check the project (in the SDK folder that the bootstrap script downloaded) and confirm that <sdk folder>/examples/ble_central_and_peripheral/ble_connectivity/main.c contains from around line 40 a typedef for version_info_t, followed by an instance of that struct filled with values, as found in this patch file?

Regards,
Terje