Running simple project with Softdevice and SDK 17.1.0

RE: Running simple project with Softdevice and SDK 17.1.0

Edvin — Thu, 10 Apr 2025 20:35:55 GMT

Hello Christophe,

I agree that this file can be a bit confusing. And yes, it varies between the examples.

The thing is that there is nothing magical about this file. It is just a file containing a lot of #define statements. When you are pulling features from one application example into another, you typically first start with the .c and .h files that define the functions that you want to use, and include them in your project. Then you may see that the functions are not declared even though you included the file. Take for example nrfx_clock.c, you added it to your project, but still it can't find the definition for any of the functions defined inside that file, such as nrfx_clock_init().

If you look close to the top of that file, you will see the line:

#if NRFX_CHECK(NRFX_CLOCK_ENABLED)

This checks if:

1: NRFX_CLOCK_ENABLED is defined, and,

2: NRFX_CLOCK_ENABLED is set to anything other than 0.

Now, to "activate" this file, you need to set NRFX_CLOCK_ENABLED to 1. You can look for it in the sdk_config.h of the file in your current application, but if you can't find it there, you can copy it from the application that you are copying from.

I like to include everything that looks related to the driver/library that I am trying to import, so in this case, I would copy this chunk from the application that I was looking at into my own application:

// <e> NRFX_CLOCK_ENABLED - nrfx_clock - CLOCK peripheral driver
//==========================================================
#ifndef NRFX_CLOCK_ENABLED
#define NRFX_CLOCK_ENABLED 1
#endif
// <o> NRFX_CLOCK_CONFIG_LF_SRC  - LF Clock Source
 
// <0=> RC 
// <1=> XTAL 
// <2=> Synth 
// <131073=> External Low Swing 
// <196609=> External Full Swing 

#ifndef NRFX_CLOCK_CONFIG_LF_SRC
#define NRFX_CLOCK_CONFIG_LF_SRC 1
#endif

// <o> NRFX_CLOCK_CONFIG_IRQ_PRIORITY  - Interrupt priority
 
// <0=> 0 (highest) 
// <1=> 1 
// <2=> 2 
// <3=> 3 
// <4=> 4 
// <5=> 5 
// <6=> 6 
// <7=> 7 

#ifndef NRFX_CLOCK_CONFIG_IRQ_PRIORITY
#define NRFX_CLOCK_CONFIG_IRQ_PRIORITY 6
#endif

// <e> NRFX_CLOCK_CONFIG_LOG_ENABLED - Enables logging in the module.
//==========================================================
#ifndef NRFX_CLOCK_CONFIG_LOG_ENABLED
#define NRFX_CLOCK_CONFIG_LOG_ENABLED 0
#endif
// <o> NRFX_CLOCK_CONFIG_LOG_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRFX_CLOCK_CONFIG_LOG_LEVEL
#define NRFX_CLOCK_CONFIG_LOG_LEVEL 3
#endif

// <o> NRFX_CLOCK_CONFIG_INFO_COLOR  - ANSI escape code prefix.
 
// <0=> Default 
// <1=> Black 
// <2=> Red 
// <3=> Green 
// <4=> Yellow 
// <5=> Blue 
// <6=> Magenta 
// <7=> Cyan 
// <8=> White 

#ifndef NRFX_CLOCK_CONFIG_INFO_COLOR
#define NRFX_CLOCK_CONFIG_INFO_COLOR 0
#endif

// <o> NRFX_CLOCK_CONFIG_DEBUG_COLOR  - ANSI escape code prefix.
 
// <0=> Default 
// <1=> Black 
// <2=> Red 
// <3=> Green 
// <4=> Yellow 
// <5=> Blue 
// <6=> Magenta 
// <7=> Cyan 
// <8=> White 

#ifndef NRFX_CLOCK_CONFIG_DEBUG_COLOR
#define NRFX_CLOCK_CONFIG_DEBUG_COLOR 0
#endif

// </e>

// </e>

The <e> and <o> stuff is not strictly necessary, but Keil IDE has a tool that can be used to parse these files, and it uses these to understand how to present it.

Please note that if you are struggling with enabling something, then you should be aware that there is a file called apply_old_config.h, and it checks for duplicates between the old legacy names and the "new" nrfx driver names. So if both are present, then the old name, without NRFX will be the one that becomes valid, and "overwrite" the new one.

Best regards,

Edvin

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Thu, 10 Apr 2025 12:36:42 GMT

Quick question for my understanding: why sdk_config.h file is different between examples. When we are building project with BLE, UART, SPI and so on, how can we trust any examples !!!! and documentation !!!!

RE: Running simple project with Softdevice and SDK 17.1.0

Edvin — Tue, 08 Apr 2025 09:27:47 GMT

I am glad you found the cause of the issue! Best of luck with the rest of the development 🙂

Best regards,

Edvin

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Tue, 08 Apr 2025 09:14:04 GMT

I think I found the issue. I use a ublox chip on my custom board and realized that ublox remapped gpios to different pin numbers. I am now able to toggle LEDs on the ublox dev kit. :-)

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Tue, 08 Apr 2025 08:55:14 GMT

I have a ublox dev kit on hand. I have ran simple blinky app on the kit and have same issue than with my custom board. I guess there is something simple to fix in configuration of the project. Looking deeper in project configuration ...

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Tue, 08 Apr 2025 08:02:22 GMT

Hello,

I am able to run example with advertising. I have tried couple of things like using internal oscillator instead of external crystal (no success toggling GPIO). I have few years of experience running project on nRF52832 (until 2022). I am back to this micro for a new project but hard to make simple things working. Maybe, my custom board have an issue but I have to figure where issue is.

RE: Running simple project with Softdevice and SDK 17.1.0

Edvin — Tue, 08 Apr 2025 07:56:08 GMT

Hello,

Are you sure you have mapped the GPIOs correctly? That your IO_13 is connected to P0.13 on the nRF? And if you run the same application on the DK, does the corresponding GPIOs toggle? On your custom board, do you have an LFXTAL? If not, have you told your application that it doesn't have it?

If you flash the softdevice and a BLE sample, do you see any advertisements?

Best regards,

Edvin

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Mon, 07 Apr 2025 16:11:02 GMT

Hi, I have moved a step forward. First of all, I got a nrf52832 dev kit and run simple blinky example using sdk 17.1.0 without any problems. I am now moving to my own custom board.

I have 1 LED (IO_13) and 3 test_pins (IO_29 to 31) I can easily use to start running simple project. Unfortunately, I have not been able to see any gpio toggling right now.

I have created my custom board, and modify simply blinky example to match with my board. I can run program step by step and can through assembly code, but none of the GPIOs toggle.

If you have any suggestions for my next steps, it would be helpful :-)

RE: Running simple project with Softdevice and SDK 17.1.0

Edvin — Fri, 04 Apr 2025 09:46:33 GMT

Ok. That sounds weird. Do you think it is possible for me to reproduce what you are seeing? Is it possible to zip and upload the application folder? When you were working on SDK17, did you do any changes to any of the files outside the SDK folder? You could, for instance, try to extract a new copy of the SDK, and copy your application into this one to see if the behavior remains the same.

Best regards,

Edvin

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Thu, 03 Apr 2025 13:14:41 GMT

with SDK 15.0.0, I have no issue running the application. I will remain on this version for now.

RE: Running simple project with Softdevice and SDK 17.1.0

Syntima_Chris — Thu, 03 Apr 2025 13:08:46 GMT

Hi,

thanks for the first reply. I tried your suggestion without success.

As stated in my initial message, application stops running and messages don't come as expected (with delay) but in one shot.

See below # of loop iterations before issue according to delay specified in nrf_delay_ms():

100ms: # = 37

500ms: # = 0

1000ms: # = 3

I am going to try with an older version of sdk and softdevice to compare behaviour

RE: Running simple project with Softdevice and SDK 17.1.0

Edvin — Thu, 03 Apr 2025 12:50:40 GMT

Hello,

It may be that since you are printing the same thing over and over, it actually writes it again, but since the content of the buffer doesn't change, the RTT terminal doesn't realize it is a new log record. The RTT buffer is just an area in the RAM that the debugger continuously monitors.

Can you try the following:

int main(void)
{
    uint32_t dummy_counter = 0;
    SEGGER_RTT_printf(0, "firmware started\n");
    
    while(1)
    
    {
        
        SEGGER_RTT_printf(0, "test %d\n", dummy_counter);
        dummy_counter++;
        nrf_delay_ms(1000);
        
    }

}

and see if the behavior changes?

Best regards,

Edvin