apply_old_config.h not working as expected?

Hi guys,

I'm currently using SDK 15.0.0 in Keil MDK and making use of the new NRFX drivers.

Similar to the issue detailed here:, when I attempt to enable NRFX drivers, apply_old_config.h is overriding the behaviour and disabling them.

My assumption would have been that if I have the legacy driver enabled, it'll override the settings, but if it's not enabled, it shouldn't do anything, but that's not what's happening. For example, in my project I have:

#define UART_ENABLED 0
#define TWI_ENABLED 0

However the following statements when compiled, are coming out as true and overriding my settings (this is contrary to what Keil's clang code-completion thinks):

#if defined(UART_ENABLED)
#if defined(TWI_ENABLED)

I've found a temporary workaround of simply removing the defined() so:


I think maybe apple_old_config.h needs revisiting in the next SDK to fix this issue or am I missing something?

Many thanks

  • Hello,

    Thank you for your feedback.

    I would agree that the implementation is not too intuitive in the examples. I believe it is done so that it would be easier to port from older SDKs to SDK15. A common misunderstanding is that if you have e.g.:

    #define TWI_ENABLED 1

    in sdk_config, then you will use the old TWI drivers. That is not true. It is correct that the file apply_old_config.h overwrites the NRFX_TWI_... defines, but it will still use the new nrfx drivers.

    But I would agree with you that it could have been done differently. You are not the first person pointing this out (but it is still a good thing that you, so that we get a better feel to how the user experience is).

    I agree that it is confusing that there are two defines, where the old one overwrites the new one, which is the one, which we are trying to make you familiar with. But as I mentioned, I believe that the apply_old_config.h file will be reviewed before the next SDK.

    But in my opinion, the best solution would be to remove the old defines, which is what I believe is the intention. 

    If UART_ENABLE is not defined at all, then it would only be one UART-define, NRFX_UART_ENABLE, which will make it a bit less confusing.


    Again, thank you for your feedback.


    Best regards,


  • Hi Edvin,

    I've found for a new project the best thing to do is go into the SDK and comment out the include of apply_old_config.h from the nrfx include chain completely, this has resolved all of my issues.

  • This has worked well for me as well. Since Segger embedded studio doesn't include the header files it is harder to find the reference from the IDE than it might be in a different development environment.

    In SDK 15.2 the include is on line 57 of nrfx_glue.h

  • I signed up just in the hopes of pointing out to someone at Nordic how terrible this is.

    I open the TWI header and I see this:


    So I -DNRFX_TWI0_ENABLED, then get build errors. Two hours and fifteen minutes later I realize another unrelated header is doing the following:

    #undef NRFX_TWI0_ENABLED
    #define NRFX_TWIM0_ENABLED 0

    I'm dumbfounded. I have professionally used and designed / implemented SDKs for things ranging from Graphics APIs to system / controller APIs, and I have never seen anything as terrible as this. 

    I want the two hours of my life back, and I want you to stop doing this. A header file is a contract, and breaking locality by having an unrelated header mess up my defines is a big no-no. Do not pass Go, do not collect $200.