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

Porting SDK14 project to SDK15.2 - IRQ handlers and other issues

I'm in the process of trying to port my SDK 14 project to SDK 15.2. I've made a pretty good amount of progress, but I have two issues that I can't seem to figure out.

The first is somewhat minor but very annoying. For some reason since I replaced the SDK 14 files with SDK 15.2 in my repo, the uint32_t type is no longer recognized by Eclipse even though other integers (uint16_t etc) are. APP_ERROR_CHECK is also marked as unrecognized. The compiler doesn't have issues with these though, so it seems to be something with Eclipse. If I go back to my SDK 14 branch (which just changes the code since my Eclipse settings are not tracked in my repo), uint32_t and APP_ERROR_CHECK are recognized by Eclipse without issue. This is annoying but not a blocker.

However, an issue I'm having with IRQ handlers is keeping me from progressing. Here's the output of my compiler (ARM GCC):

Compiling test_mode.c
In file included from /Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs.h:49:0,
                 from /Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/integration/nrfx/nrfx_glue.h:59,
                 from /Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/nrfx.h:46,
                 from /Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/components/libraries/delay/nrf_delay.h:44,
                 from /Users/user/Documents/source/firmware/system/app/inc/log_print.h:15,
                 from /Users/user/Documents/source/firmware/system/app/src/test_mode.c:9:
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:71:37: error: redundant redeclaration of 'SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler' [-Werror=redundant-decls]
 #define nrfx_twi_0_irq_handler      SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler
                                     ^
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:71:37: note: in definition of macro 'nrfx_twi_0_irq_handler'
 #define nrfx_twi_0_irq_handler      SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:66:37: note: previous declaration of 'SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler' was here
 #define nrfx_spim_0_irq_handler     SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler
                                     ^
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:66:37: note: in definition of macro 'nrfx_spim_0_irq_handler'
 #define nrfx_spim_0_irq_handler     SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:83:37: error: redundant redeclaration of 'SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler' [-Werror=redundant-decls]
 #define nrfx_twi_1_irq_handler      SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler
                                     ^
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:83:37: note: in definition of macro 'nrfx_twi_1_irq_handler'
 #define nrfx_twi_1_irq_handler      SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:78:37: note: previous declaration of 'SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler' was here
 #define nrfx_spim_1_irq_handler     SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler
                                     ^
/Users/user/Documents/source/firmware/nRF5_SDK_15.2.0_9412b96/modules/nrfx/soc/nrfx_irqs_nrf52832.h:78:37: note: in definition of macro 'nrfx_spim_1_irq_handler'
 #define nrfx_spim_1_irq_handler     SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/Users/user/Documents/source/firmware/build/obj/test_mode.o] Error 1

I'm not completely sure what's going on, but it seems like the compiler thinks I'm trying to define the SPIM/TWI IRQ handler twice each for modules 0 and 1. But I'm not- at least not intentionally. My project intends to use TWI0, SPIM1, and SPIM2. My nrfx_config.h sets TWI/TWIS/TWIM/SPI/SPIS/SPIM enable flags as follows:

NRFX_TWI0_ENABLED 1
NRFX_TWI1_ENABLED 0
NRFX_SPIM0_ENABLED 0
NRFX_SPIM1_ENABLED 1
NRFX_SPIM2_ENABLED 1
All TWIM, TWIS, SPIS, and SPI are disabled.

If I search my entire working directory for NRFX_SPIM0_ENABLED, I find it defined in several places (excluding example directories).

  1. sdk/config/nrf52832/config/sdk_config.h
  2. sdk/integration/apply_old_config.h
  3. sdk/modules/nrfx/templates/nRF52832/nrfx_config.h
  4. <my application directory>/nrfx_config.h

So it was confusing to figure out which enable flag the compiler was actually using. But I added .orig extensions to numbers 1-3 so they won't be included and commented out the inclusion of apply_old_config.h in nrfx_glue.h. And I still get the same problem.

Other possible points of interest- I originally intended to use the legacy files provided to minimize the amount of changes I'd need to make to my application code up front. But I wondered if something in that legacy layer was causing issues, so I excluded it and made the necessary code changes (mostly nrf_drv_x to nrfx_x) and modified linker and sdk_config.h (and nrfx_config.h) files from the SDK instead of trying to modify the corresponding files I carried over from SDK 14. But none of those steps helped this SPI/TWI IRQ issue.

Any thoughts?

Parents Reply Children
  • Sorry about the delayed response. I'm not sure I understand exactly what you mean. Do you mean to try to reproduce it with the armgcc makefile in one of the examples? Unfortunately the structure of my project's makefiles are pretty different from the example makefiles so I think there would be a non-trivial amount of work involved. Would it be sufficient to attach my config files? I have attached them just in case.

    In looking into this with fresh eyes just now, it seems odd to me that nrfx_spim.h includes prototypes for SPIM0, SPIM1, SPIM2, and SPIM3 regardless of which SPIM modules are enabled. And nrfx_twi.h includes prototypes for TWI0 and TWI1, regardless of which TWI modules are enabled. If I undo my previous comments/edits to nrfx_irqs_nrf52832.h as previously mentioned and instead gate all the nrfx_spim_x_irq_handler(void) and nrfx_twi_x_irq_handler(void) IRQ handler prototypes behind corresponding #if NRFX_CHECK(NRFX_XXXX_ENABLED) (like the corresponding IRQ handler definitions are gated), my project compiles. Shouldn't the IRQ handler prototypes be gated behind NRFX_CHECKS so that they're not duplicated when nrfx_irqs_nrf52832.h is included?

    2664.sdk_config.hnrfx_config.h

  • What do you mean by prototypes for SPIM0, SPIM1, SPIM2 and SPIM3? It doesn't look like to me that it gates all the nrfx_spim_x_irq_handler(void) when you enable one of them. They are all behind an

    #if NRFX_CHECK(NRFX_SPIX_ENABLED)
    nrfx_spim_x_irq_handler,
    #endif 

    Can you see if you get the same issue if you try the segger embedded studio (ses) project from SDK15.2.0? 

    Best regards,

    Edvin

  • Correct me if I'm wrong, but the part you just cited is where the irq_handlers[] array of function pointers is initialized to include each of the enabled IRQ handlers. I'm talking about the prototypes in the header files. So for example, lines 384-387 of nrfx_spim.h looks like this by default:

    void nrfx_spim_0_irq_handler(void);
    void nrfx_spim_1_irq_handler(void);
    void nrfx_spim_2_irq_handler(void);
    void nrfx_spim_3_irq_handler(void);

    Why shouldn't it look like this instead?

    #if NRFX_CHECK(NRFX_SPIM0_ENABLED)
    void nrfx_spim_0_irq_handler(void);
    #endif
    #if NRFX_CHECK(NRFX_SPIM1_ENABLED)
    void nrfx_spim_1_irq_handler(void);
    #endif
    #if NRFX_CHECK(NRFX_SPIM2_ENABLED)
    void nrfx_spim_2_irq_handler(void);
    #endif
    #if NRFX_CHECK(NRFX_SPIM3_ENABLED)
    void nrfx_spim_3_irq_handler(void);
    #endif

    Similarly, nrfx_twi.h has prototypes for nrfx_twi_0_irq_handler(void) and nrfx_twi_1_irq_handler(void) with no NRFX_CHECKs to make sure which of those modules are actually enabled. So when nrfx_irqs_nrf52832.h is included, line 66 and line 71 cause nrfx_spim_0_irq_handler and nrfx_twi_0_irq_handler to _both_ be replaced by SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler, which causes the compiler to think that SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler has two prototypes in two different locations (nrfx_spim.h and nrf_twi.h). Same for spim_1 on line 78 and twi_1 on line 83.

    Do I have this right? What am I missing? Is there any reason why the prototypes in nrfx_spim.h and nrfx_twi.h (and probably also other header files that I'm not using in my project) are not gated behind NRFX_CHECKs like the definitions are? Is editing the SDK to add those NRFX_CHECKs a correct way to fix the issue, or is there some bigger underlying issue I'm just covering up by doing this?

    Regarding your SES question, again, I'm not sure what you mean. Is there some generic SES project and makefile that I'm not aware of? Or are you suggesting that I try to reproduce this with one of the examples?

  • Hello,

    You are correct. It could have been like your second snippet. The thing is that even though it has the prototypes, it doesn't actually use them unless they are implemented in a .c file. 

    The SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler is used if one of these are enabled, and that is fine. If two of them are enabled, then you will get a compiling error, which is expected. This is also correct, since these instances share resources, and you can only use one of them.

    But if the last snippet from your reply solves your issue, I don't see any problems using that.

    Best regards,

    Edvin

  • But I _haven't_ enabled two of SPIx0/TWIx0 or SPIx1/TWIx1. I've enabled TWI0 and SPIM1 (and SPIM2, but that doesn't seem to be related). TWI0 and SPIM1 do not share resources, so there shouldn't be any conflicts. I had no issues with this exact same configuration in SDK14. It really seems like I'm either still missing something or there's some sort of issue with SDK 15.2. I can't imagine that it should be expected that I would get basic compilation issues when trying to use TWI0 and SPIM1 at the same time, so I still feel like I'm missing something, which makes me feel uneasy putting this code into production without actually understanding the issue.

    I spent some time tonight trying to reproduce the issue with one of the examples. I hoped to find either a TWI or SPIM example and edit it so that both TWI0 and SPIM1 are enabled to see if the issue would occur. But surprisingly none of the examples use the new nrfx_x drivers directly. They all seem to use the legacy nrf_drv_x interface.

Related