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

NRF52 timing

I'm modelling a complex system with multiple BT devices based on the NRF52 using a very detailed model of the RF.

The system is based on the NRF52 using the mesh stack to but with additional user specific packets added by my code. I need to understand the behaviour of the Rx engine when a packet is received.

After a  successful reception does it re-enter Rx mode in the same channel or switch channels, and how long will it then remain on that channel, i.e. does it reset the rx timer, use the remaining time based on when it entered rx on that channel, or use any remaining time excluding the time consumed by the packet it actually received.

Additionally what happens in the event of a failed Rx ( Framing or CRC error ), how long does it take to recover and what actions does it take.,

I have a very detailed model that models all possible RF states but need to add some more detailed timing to the state machine, so in general the timings for the latest soft device on the NRF52 would be extremely useful, e.g. how long does it take to switch channels in Tx / Rx mode, how is the dwell time managed,

The same issues apply for Tx timing, does it truncate an Rx event when a Tx is scheduled?.

All of my data is sent as advertising events.

Parents
  • 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. 

  • 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.

  • 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.

  • 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.

  • 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. 

  • 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.

  • 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.

Reply Children
  • 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. 

  • 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?.

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

  • 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.

  • 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. 

Related