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

[Sydney]

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?

[Edvin]

Hello,

Is it possible to reproduce the issue with the armgcc folder, so that I can try to replicate it just using the makefile from the armgcc folder? 

If so, could you send the project?

Best regards,

Edvin

[Sydney]

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

[Sydney]

Hi,

I understand that the examples ultimately use the nrfx drivers, but my issue when trying to reproduce the IRQ handler issue with one of the examples is that none of the examples use the nrfx drivers _directly_. Like you said, the examples all use the nrf_drv -> nrfx legacy translation layer, which reconfigures a lot of the #defines and makes it hard to do an apples-to-apples comparison with my app because my app was ported to use the nrfx drivers directly. I spent a bit of time trying to port an example to use the nrfx drivers directly without the legacy layer, but I ran into some issues.

Ultimately my expectation is that if one of the TWI or SPI SDK 15.2 examples was ported to use nrfx directly and modified to enable both TWI0 and SPIM1, you would run into the same IRQ handler compilation error I'm seeing. It seems like a bug in the SDK because TWI0 and SPIM1 is supposed to be a valid combination. If it is an SDK bug, I'm okay patching it myself, but I need to make sure I actually understand the problem before I can have confidence that my fix is sufficient.

Regarding the TWI clear bus function, I did notice that it's still in the legacy translation layer, but I'm curious why it was removed from the actual nrfx driver. Doesn't Nordic recommend using the nrfx drivers directly in new applications instead of using the legacy layer? Does Nordic expect that new applications that use the nrfx TWI driver directly won't/shouldn't need the clear bus function?

[Edvin]

TWI0 and SPIM1 is a valid combination, as you say. If you can send a project that I can compile, e.g. using segger embedded studio, or any of the other IDEs used in the SDK(or armgcc), I'd be happy to take a look. 

[gauthamranganathan]

EdvinHello Edvin, I am facing the same issue right now. I am trying to using TWI0 TWI1 and SPI 1. I have the following linker error. (SDK 15.2)

.\_build\nrf52840_xxaa.axf: Error: L6200E: Symbol SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler multiply defined (by nrfx_spi.o and nrfx_twi.o).

Can you please tell me how I can fix it? I don't mind using any other SPI instance if necessary. 

Thank you. 

[Edvin]

Hello,

SPI (SPIM and SPIS) and TWI (TWIS and TWIM) all share the same IRQ Handler. This means that if you use TWI0, you can't use SPI0. If you use TWI1, you can't use SPI1, and vice versa. 

So if you need two TWIs and one SPI, you can use TWI0, TWI1 and SPI2, not SPI1, because TWI1 is already using the SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler, so SPI1 can't use this.

Best regards,

Edvin

[gauthamranganathan]

Thank you for your reply Edvin. 

So you are telling me that it's impossible to have two instances of SPI and 2 instances of TWI running simultaneoulsy on nrf52840? 

[gauthamranganathan]

Edvin I also have one additional query. If it is in fact not possible to have 2 TWI and 2 SPI instances running simultaneously, I expect the system to give me a fault at run-time when I initialise all the ports. I do not expect a build break. Is it possible to get a build through? as I will ensure that I de-initialze the SPI and TWI instances so as to ensure that only 1 SPI ever runs simultaneously with 2 TWI instances. 

[Nguyen Hoan Hoang]

The 840 has 4 spi so you can have 2 twi & 2 spi at the same time.  SPI0 & 1 are shared with TWI0 & 2.  SPI2 & 3 are independent.  

[gauthamranganathan]

I can't seem to find SPI 3

[Nguyen Hoan Hoang]

Don't know about the Nordic driver implementation.  But data sheet said it and this driver has support for it.  https://github.com/I-SYST/EHAL/blob/master/ARM/Nordic/src/spi_nrf5x.cpp

[gauthamranganathan]

Thank you for your reply nguyen hoan hoang. Our project is more than half way through now and we have been using nordic drivers. I would like to implement two instances of TWI and two instances of SPI.