Documentation about the sdk_config.h file; remove unnecessary project files.

[brianreinhold]

I am trying to port an nRF51 project that runs on the nRF51 DK using Keil to the nRF52840 DK using Segger Embedded Studio. Clearly the best way to start is to take an example from the SDK which has all the Segger-specific stuff and hardware specific stuff and change those few files which the app developer actually writes (like main.c) and update for the new SoftDevice

In my case the Keil project uses SoftDevice calls for all the Bluetooth functionality and Flash. It handles the sd_ble_evt_get() and dispatching of events.  I know I will have to make a few modifications because there are changes in SoftDevice s130 to SoftDevice s140 but they are not extensive. However, the sdk_config.h file changes ARE huge and I don't know what 90% of it means. Is there any detailed documentation describing what all these config parameters mean? A few are obvious to me like turning off the service support like CTS, DIS, BATtery, etc. This project is an implementation of a proposed protocol and there is no support in the SDK for it. So I want to turn off all those items in the sdk_config.h file that I don't need, but I don't want to mess up something that will mess up that which is needed for the chip on the DK.

Eventually I want to remove all the files in the project that I don't need - that's not too easy either. It would be nice to have a final project which ONLY contains those files necessary to build this project.

How to proceed?

[Amanda Hsieh]

Hi, 

nRF52840 is supported from SDK12.3, but only S132. S140 support nRF52840 started from SDK13.0. See SDKs and SoftDevices

I would suggest you start from the ble_app_template in SDK12.3 then migrate to S140 of SDK13.0. You could use https://infocenter.nordicsemi.com/index.jsp to search for the configs in sdk_config.h to understand it. This Migrating from the nRF51 Series to the nRF52 Series might help. 

-Amanda H.

[brianreinhold]

I am using s140 and I am not using the SDK. Though I started with the hts project for segger from SDK 17.3.0 examples. I am trying to eliminate that what I don't need. Most of the content in the sdk_config.h file I do not understand.

[Amanda Hsieh]

Hi, 

This doc Health Thermometer Application can help you understand how to use the example. As I replyed previously, you should use https://infocenter.nordicsemi.com/index.jsp to find the doc of the config in the sdk_config.h. 

-Amanda H.

[brianreinhold]

Of course I have looked through that site. The search engine is poor (as I have pointed out many times) so finding what you need is very time consuming as you have to page through everything yourself. I have found 'documentation' on the sdk_config.h' file but it just lists what's in it ... it does not explain what they mean or what the consequences are from the various settings. You have to guess from the words in the defines. Its kind of like Linux 'man' pages - useless if you don't know what the commands mean, but good if you do and you have forgotten what the details of the settings are.

In any case, I cannot get NRF_LOG to work at all (with or without RTT) and I can only get printf to work with RTT in the 'main' function of main.c. Once a callback event is handled, nothing.

Something is seriously sick.

Absolutely no problem using s130 on the nrf51 DK in a Keil project. (No RTT of course.)

Try porting that SoftDevice only project to SES and the nRF52840 DK using s140 has been a nightmare. Thought it would be easy.

[Amanda Hsieh]

Hi, 

If you want to get RTT log, you need to enable NRF_LOG_BACKEND_RTT_ENABLED and disable NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED in the sdk_config.h as

//==========================================================
// <e> NRF_LOG_BACKEND_RTT_ENABLED - nrf_log_backend_rtt - Log RTT backend
//==========================================================
#ifndef NRF_LOG_BACKEND_RTT_ENABLED
#define NRF_LOG_BACKEND_RTT_ENABLED 1

// <q> NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED  - For each printed LF, function will add CR.
 

#ifndef NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0
#endif

[brianreinhold]

I tried that. Among many other combinations. Works are far as the main function in main.c but nowhere else. So my NRF_LOG_DEBUG works at the start of the main() function but in the event handler such print statements are not displayed - and I know the code is hit because the client gets a connection event and does service discovery and configures descriptors.

The template project wont even build!

cannot find ../../../../../../external/micro-ecc/nrf52hf_armgcc/armgcc/micro_ecc_lib_nrf52.a: No such file or directory

I was going to try and start with that perhaps but I guess not now.

I have have done nothing to that project. Something HAS to be bad here. Maybe a corrupted download of the SDK? SES?

template project has NRF_FPRINTF_ENABLED 1 and the auto carriage return enabled but not NRF_LOG

What is all this? What's the difference between FPRINTF, NRF_LOG, and RTT? What's the difference between LOG with BACKEND in the name versus that without the BACKEND? Are they separate entities? Does more than one need to be enabled or is that a sin?

[Amanda Hsieh]

Hi, 

brianreinhold said:

cannot find ../../../../../../external/micro-ecc/nrf52hf_armgcc/armgcc/micro_ecc_lib_nrf52.a: No such file or directory

Please Install micro-ecc. This library is required for the Cryptography library - nrf_crypto, which is used in the BLE Secure DFU Bootloader example.

 

brianreinhold said:

Something HAS to be bad here. Maybe a corrupted download of the SDK? SES?

 What do you mean "be bad" here? Could you elaborate in more detail? Are you able to provide the any log from the device or nRF Connect app? Maybe you could try to download SDK or SEGGER Embedded Studio (SES) for ARM again. 

 

brianreinhold said:

What's the difference between FPRINTF, NRF_LOG, and RTT?

FPRINTF works like a standard fprintf C function with some limitations. 

NRF_LOG provides logging capability for your application. It is used by SDK modules and can be also used in the application code.  

 

brianreinhold said:

What's the difference between LOG with BACKEND in the name versus that without the BACKEND?

 See Logger backend interface. 

-Amanda H.

[brianreinhold]

Let's go back to the original problem - no documentation for SDK_config.h.

For example, in SDK 12.3. 0 there is no NRF_BLE_GATT_ENABLED option. What is that? In fact, in the 12.3.0 there is no NRF_ anything except logging related stuff. There is no place I can find that states what each of these options actually do, when you need them, what they bring to the table, if and when you have to use them, etc. There is a lot of 'NRF' stuff across the board in SDK 17.2.0 that was not present in SDK 12.3.0

If I am using sd_ methods to do pairing and encryption, do I need all these NRF crypto items enabled?

If I am using sd_ methods to write to flash. do I need NRF_FSTORAGE_ENABLED?

How about NRF_SDH_BLE_ENABLED 1

and

NRF_SDH_ENABLED 1?

I am using sd_get methods to get the events and dispatching them myself.

There is no where to information on what these things do or mean besides what is in the header file itself.

[Amanda Hsieh]

Hi, 

brianreinhold said:

there is no NRF_BLE_GATT_ENABLED option. What is that?

 NRF_BLE_GATT_ENABLED is used to Enable GATT Module. If you open sdk_config.h, there are simple comments for each config. 

 

brianreinhold said:

If I am using sd_ methods to do pairing and encryption, do I need all these NRF crypto items enabled?

Do you mean LESC? You could refer to examples\ble_peripheral\ble_app_hrs and its sdk_config.h. 

 

brianreinhold said:

If I am using sd_ methods to write to flash. do I need NRF_FSTORAGE_ENABLED?

Do you mean sd_flash_write? If so, you don't need to enable NRF_FSTORAGE_ENABLED. It is a function of the SoC Library API. 

brianreinhold said:

How about NRF_SDH_BLE_ENABLED 1

and

NRF_SDH_ENABLED 1?

NRF_SDH_BLE_ENABLED is used to Enable the SoftDevice Handler BLE module. 

NRF_SDH_ENABLED is used to Enable the SoftDevice Handler

 

brianreinhold said:

There is no where to information on what these things do or mean besides what is in the header file itself.

 Do you also check https://infocenter.nordicsemi.com/index.jsp? The information like the SoftDevice BLE event handler configuration could be found on the inforcenter. 

-Amanda H.

[brianreinhold]

I understand that NRF_BLE_GATT_ENABLED  enables the GATT module. That did not exist in 12.3.0 and since GATT has always been around, why is this present but not before. If I am using sd_ calls for ALL BTLE functions (think pc-ble-driver where ALL I have is sd_ methods) do I stilll need this GATT module? 

Since these SDK_config.h options are not explained anywhere, I don't know what I need, and what I dont. What will cause conflicts if enabled but I don't use? If the advertisement module is enabled but I use sd_ calls to create and start my advertisments, will that cause a problem? Will it bloat the final built project? What is softdevice-only related versus SDK-only related? What is SOC related and still needed if one is just using sd_ calls? Some NRF stuff appears to be associated with SoftDevice, but others arent - like the clocks.

Clearly I have looked through the infocenter. As many have stated the search engine is very weak and it is difficult to find topics unless you know EXACTLY where to look. If the search engine in the documentation was reasonable, far fewer people would need to ask so many questions on this site. The good thing is the responses are usually very timely. But no one can beat a decent search!

[Amanda Hsieh]

Hi, 

brianreinhold said:

That did not exist in 12.3.0 and since GATT has always been around, why is this present but not before.

In SDK 13, a "GATT module" was introduced and is enabled by default. This module enables MTU request and Data Packet Length Extension (DLE). For all phones supporting BLE 4.2 and above, the examples in the SDK will work out of the box.

For phones that support BLE 4.0 and/or BLE 4.1 only, MTU requests and DLE will not work. In that case, you will have to disable it in the SDK example: all you need to do is to comment out gatt_init(). See SDK13.0 Migration guide/GATT module 

brianreinhold said:

What will cause conflicts if enabled but I don't use? If the advertisement module is enabled but I use sd_ calls to create and start my advertisments, will that cause a problem? Will it bloat the final built project?

To enable the configs in the SDK can let you use the specific modules/libraries/features/drivers. It won't cause an issue in that case. 

Would you like to migrate the porject to SDK17.0.2  or start a new porject from SDK17.02? What is your application? I would suggest start from a similiar example to know what configs and features you would need. 

-Amanda H.

[brianreinhold]

In the end I ported my source code from Keil 12.3.0 (SoftDevice only for BTLE and Flash) to Segger 17.2.0 (SoftDevice only for BTLE and Flash), replacing the source files for the hts demo of 17.2.0. The part that caused me the greatest difficulty was the logging and the initialization of SoftDevice. In the end it turned out to be just two calls to SoftDevice that I needed and the removal of an SDK module that was getting called under the hood that was trapping and processing BTLE events before I could get them. Once I got logging and debugging to work I found that module was getting set up in the original ble_stack_init(). Otherwise the rest of SoftDevice API changes between s130 and s140 were minimal.

By trial and error I have removed files from the build and have reduced the size considerably. Most of the options in SDK_config.h are now disabled. It turns out I need to enable FPRINTF in order to use NRF_LOG. I don't think this was intended but the NRF Log source file for strings makes calls into FPRINTF so enabling NRF_LOG and disabling FPRINT will give you build errors. I don't think the reverse is true.

The project then built in Keil without an issue except it was 200 bytes too large to build in the size-limited free version that I have. Oh well, Segger does the job.

I think it would be nice if you had an example that used JUST SoftDevice as there are many advantages of such a project - especially when migrating between versions and/or platforms. SoftDevice changes little -  the SDK changes dramatically and the footprint is much smaller.

In my case I am working on a new standard for health devices and there is no support for it in the SDK. For experimental work, using SoftDevice only has great advantages!