NRF52 timing

RE: NRF52 timing

Hung Bui — Tue, 15 Jan 2019 13:54:21 GMT

Hi Phil,

I'm sorry indeed. It's my mistake. We don't provide Keil projects in the SDK. We have a blog post here on how to create Keil project for mesh a while ago. It was for SDK v0.10 but it should still work now I would assume.

I tested here with -DTOOLCHAIN=armcc and didn't have any issue. Please make sure you have the SDK_ROOT point to the correct SDK folder and that you have installed the uECC library as instructed here.

Segger RTT should be available in (SDKv15.2)external\segger_rtt folder.

RE: NRF52 timing

Phil Young — Mon, 14 Jan 2019 13:37:29 GMT

I am using nrf5SDKforMeshv310src and there are no Keil projects there, there are 2 subfolders ble_app_proximity_coexist and ble_app_uart_coexist, but neither of these contains any Keil projects.

RE: NRF52 timing

Phil Young — Mon, 14 Jan 2019 12:49:04 GMT

I am using nrf5SDKforMeshv310src and there are no Keil projects there, there are 2 subfolders ble_app_proximity_coexist and ble_app_uart_coexist, but neither of these contains any Keil projects.

RE: NRF52 timing

Hung Bui — Mon, 14 Jan 2019 12:03:59 GMT

Please use latest SDK. You can find the Keil project at (MeshSDKv3.0.0)\examples\sdk_coexist\

RE: NRF52 timing

Phil Young — Fri, 11 Jan 2019 16:40:20 GMT

yes, I can rebuild all of the projects now, but I can't find any keil projects for the mesh examples.

I created a project for all the files used in beaconing and they all compile ok, but it fails to link.

using ninja it passes --via=CMakeFiles\beaconing_nrf52832_xxAA_s132_6.1.0.rsp to the linker but I cannot find this file to work out what else it was trying to link with. There are 102 source files used but it also seems to be linked to libraries as I get

.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol uECC_make_key (referred from prov_utils.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol uECC_secp256r1 (referred from prov_utils.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol uECC_shared_secret (referred from prov_utils.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol uECC_valid_public_key (referred from prov_utils.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol SEGGER_RTT_Write (referred from log.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol SEGGER_RTT_printf (referred from log.o).
.\Objects\Beaconing.axf: Error: L6218E: Undefined symbol SEGGER_RTT_vprintf (referred from log.o).
Not enough information to list image symbols.

where is the linker control file?.

RE: NRF52 timing

Hung Bui — Fri, 11 Jan 2019 14:59:13 GMT

Hi Phil,

I see, I think I had the same issue a bit long ago. Now you can generate the build with CMAKE and armcc ?

If you move to SDK v2.x or 3.x you can just reuse the Keil project we have in the co-existence examples we provided. It has all the stack libraries and dependencies.
Regard any detailed timing, I afraid that we don't have anything other than the documentation and softdevice specification we have.

RE: NRF52 timing

Phil Young — Fri, 11 Jan 2019 11:38:23 GMT

fixed by deleting and restoring the directories, seems that enable_lang had been called when I first ran the script without specifying armcc, then it created a build environment for gcc and tested that which failed. A bit crap of CMake, but it seems you cannot then change the build environment so I had to delete it.

RE: NRF52 timing

Phil Young — Fri, 11 Jan 2019 11:27:26 GMT

Yes, you are right, I was confused as I remembered changing my code because I could no longer use take control of the radio directly, so I use the Mesh stack to handle the Tx and Scanning operations, I also remember having to make a lot of changes to integrate the code in the old Mesh SDK with the BT-LE SDK since it had been created by importing part of the BT-LE SDK into the mesh SDK and editing it so it was no longer compatible with the main BT-LE SDK and was also unable to be integrated into a C++ project because of some coding style issues.
There are no projects for the keil environment to re-build the mesh SDK so yet again I will have to creat one by reverse engineering the output from CMake, but at the moment CMake is failing the compiler test when enable_lang is called despite me using the -D TOOLCHAIN=armcc, it is picking up the Keil compilers directly but testing them with gcc arguments, I even modified the script to dump the compiler options and it dumps the correct ones for armcc, but just test the compiler with the gcc ones.

RE: NRF52 timing

Hung Bui — Fri, 11 Jan 2019 10:05:33 GMT

Just to clarify, maybe we are talking to different mesh stack here, could you find the part where the mesh stack use the softdevice for scanning /advertising mesh? In my SDK v.0.10.1 alpha we access the radio in scanner.c file. I'm not aware of any time that we changed this architecture.

We do have examples for Keil that you can use. In the newer SDK (from SDK v2.1) we provide coexistence examples in Keil that you can integrate into nRF5 SDK.

RE: NRF52 timing

Phil Young — Thu, 10 Jan 2019 17:00:00 GMT

My code is currently based on the old Mesh SDK which was using the soft device, prior to that I was also using the timeslot API, but the timsslot API did not allow for multiple applications to be interfacing to it so I changed the code when integrating with the mesh SDK.

Now it seems I will first have to modify my code to work with the latest SDK, but that's problematic for me as all of my applications are built using the Keil environment and the mesh code does not build when using the arm compilers using cmake

Run Build Command:"D:/Tools/ninja.exe" "cmTC_bda53"
[1/2] Building C object CMakeFiles\cmTC_bda53.dir\testCCompiler.o
FAILED: CMakeFiles/cmTC_bda53.dir/testCCompiler.o
C:\Keil_v5\ARM\ARMCC\bin\armcc.exe --std=gnu99 -Wall -Wno-attributes -Wno-format -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums --depend=CMakeFiles\cmTC_bda53.dir\testCCompiler.o.d --depend_single_line --no_depend_system_headers -o CMakeFiles\cmTC_bda53.dir\testCCompiler.o -c testCCompiler.c
Fatal error: C3900U: Unrecognized option '--std=gnu99'.
Fatal error: C3900U: Unrecognized option '-all'.
Fatal error: C3900U: Unrecognized option '-no-attributes'.
Fatal error: C3900U: Unrecognized option '-no-format'.
Fatal error: C3900U: Unrecognized option '-ffunction-sections'.
Fatal error: C3900U: Unrecognized option '-fdata-sections'.
Fatal error: C3900U: Unrecognized option '-fno-strict-aliasing'.
Fatal error: C3900U: Unrecognized option '-fno-builtin'.
Fatal error: C3900U: Unrecognized option '--short-enums'.
ninja: build stopped: subcommand failed.

There are no instructions on how to use the ARM compilers that I can find in the documentation.

RE: NRF52 timing

Hung Bui — Thu, 10 Jan 2019 16:32:16 GMT

Hi Phil,

I'm not sure from where you get that the BTMesh use the softdevice to interface to the RF?

In scanner.c you can see that the RADIO is accessed directly. They way the mesh stack works is to request the timeslot from the softdevice so that it can access the radio directly (without using softdevice API). The mesh stack doesn't use the softdevice to do scanning /advertising.

You may need to explain to me a little bit more on how your own mesh stack running ? How do you disable the BTmesh and start yours ? I assume it use the softdevice API to do scanning and advertising ? If you disable the mesh stack you have the full control of the softdevice.

Also Mesh version 0.10.1 is a very old and primitive stack we had. Note that it's not on production level and is not qualified for Bluetooth Mesh.

RE: NRF52 timing

Phil Young — Thu, 10 Jan 2019 16:08:57 GMT

As I see it the Nordic BTMesh stack uses the softdevice in the SDK to interface to the RF, all BTMesh packets are simple non connectable advertising frames tagged as BTMesh and in parallel to this I am sending / receiving my own advertising frames tagged as manufacturer specific, the BTMesh stack does not recognize these and simply passes them to my code for processing using the API hooks.

When I send a frame I call the SDK using the API to schedule it, bypassing the BTMesh stack, providing my own buffers.

But the SoftDevice is initialized by the BTMesh code since it must tell the softdevice the parameters for scanning for BTMesh packets, and it is this scan process that receives my advertising frames.

In modelling the system with various assumptions about the soft device I identified some unusual system level behaviour with certain possible modes of soft device operation ( in particular what happens following packet reception depending on the remaining scan window time), so to ensure the behaviour is suitable for my needs I need to understand what happens following successful and failed packet reception which is of course down to the soft device, but also how does the BTMesh configure the SoftDevice in terms of ScanWindow and ScanPeriod, and also when scheduling a frame ( either BTMesh or my custom frames ) for transmission what happens in terms of timing when the soft device is scanning.

RE: NRF52 timing

Hung Bui — Thu, 10 Jan 2019 15:50:09 GMT

Hi Phil,

You mentioned "sending advertisement events and scanning for advertisement packets " Could you clarify which advertising events ? Is it mesh advertising or normal BLE advertising ? The softdevice doesn't do mesh.

We actually don't have the numbers or statistic on how the timing on the softdevice or the mesh stack is. You would need to measure this on your own. The easiest way of measuring this is to have a look at the power consumption of the chip when running the stack. Each state (TX, RX, Idle) would have different current consumption. You can use a Power Profiler Kit for this purpose.

RE: NRF52 timing

Phil Young — Thu, 10 Jan 2019 13:40:47 GMT

Yes, I understand that.
Currently my prototypes are based on nrf5_SDK_for_Mesh_v0.10.1-Alpha although I intend to update this.
This is using nRF5_SDK_14.0.0

RE: NRF52 timing

Hung Bui — Thu, 10 Jan 2019 12:19:37 GMT

Hi Phil,

Please be aware that the softdevice has nothing to do with mesh except for granting timeslot for the mesh stack to use the radio.

Please state exactly which softdevice and which Mesh SDK version you are using.

RE: NRF52 timing

Phil Young — Thu, 10 Jan 2019 08:47:42 GMT

It is a proprietary stack running in parallel to your BTMesh stack, under normal operation just one of the 2 stacks will be active and under these conditions I need to understand the behaviour of the proprietary stack, it would also be useful to have more precise details for the behaviour of the actual BTMesh stack when that is active. I have a model that supports a very detailed system with detailed timing for all RF activities but I need to update the soft device state machine model to accurately reflect how it manages the RF when sending advertisement events and scanning for advertisement packets since this code is common to both the WWMesh and our proprietary stack.

RE: NRF52 timing

Hung Bui — Wed, 09 Jan 2019 15:28:59 GMT

Hi Phil,

If possible could you give some more information of the purpose of the RF modelling ? Do you need to qualify for a certification or something ?

Could you tell what exact stack running on the device ? Is it a proprietary mesh or it's our BLE mesh stack ? If it's our stack, please state the version.

If it's our BLE mesh stack, most of the mesh activity is handled by mesh stack, not the softdevice.