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

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

Nguyen Hoan Hoang — Tue, 19 Feb 2019 14:09:01 GMT

I only present you options. How you you want to solve the issue is up to you. Of course you can base on that and write your own nrfx version. When there is will, there is a mean.

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

Nguyen Hoan Hoang — Tue, 19 Feb 2019 14:06:21 GMT

Then you are out of luck. SPI3 is DMA only.

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

Edvin — Tue, 19 Feb 2019 13:34:50 GMT

Hello gauthamranganathan,

This is not really related to porting from SDK14 to SDK15. Please create a new ticket.

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

gauthamranganathan — Tue, 19 Feb 2019 09:39:45 GMT

thank you for your reply Edvin,

I understand that SPI 3 is only master. I am okay with that. But i don't see an instance for SPI 3 (as seen in screenshot above).

I do not want to use spim as that would enable DMA controller. This will increase my current consumption.

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

Edvin — Tue, 19 Feb 2019 07:56:31 GMT

From e.g. the SPI section in the nRF52840 there is a section regarding Shared Resources. In this section there is a link to Instantation.

So basically, in the last link, you can't have two peripherals sharing the same ID from the table active at once.

If you need 2xSPI and 2xTWI, then you can use e.g:

TWI0, TWI1, SPI2, SPI3. Note that SPI3 is only master, not SPI slave.

Are you aware of that you can have several devices connected to one SPI bus and several devices connected to one TWI bus? That is the nature of these protocols. With the TWI you only need to connect all devices with the two wires, while on SPI you would need a chip select (CS) line for each slave, and then they share the other lines (MOSI, MISO, CLK).

BR,,

Edvin

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

gauthamranganathan — Tue, 19 Feb 2019 05:11:36 GMT

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.

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

Nguyen Hoan Hoang — Tue, 19 Feb 2019 05:05:04 GMT

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

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

gauthamranganathan — Tue, 19 Feb 2019 05:00:52 GMT

I can't seem to find SPI 3

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

Nguyen Hoan Hoang — Tue, 19 Feb 2019 04:54:01 GMT

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.

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

gauthamranganathan — Tue, 19 Feb 2019 04:44:43 GMT

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.

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

gauthamranganathan — Tue, 19 Feb 2019 04:36:16 GMT

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?

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

Nguyen Hoan Hoang — Mon, 18 Feb 2019 19:39:22 GMT

For the uint32_t in Eclipse, I found something on StackOverflow that might help https://stackoverflow.com/questions/11666094/eclipse-does-not-recognize-types-from-stdint-h-for-arm-windows-gcc-toolchain

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

Edvin — Mon, 18 Feb 2019 11:52:02 GMT

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

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

gauthamranganathan — Mon, 18 Feb 2019 10:05:57 GMT

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.

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

Edvin — Mon, 10 Dec 2018 09:29:37 GMT

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.

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

Sydney — Fri, 07 Dec 2018 19:22:50 GMT

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?

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

Edvin — Fri, 07 Dec 2018 11:56:18 GMT

Hello,

All of the examples from SDK15.2.0 uses the nrfx drivers. They use the old names, but if you follow the definitions for these, you will find that they are redefined to the nrfx_ drivers. It is convenient if you try to port your applications, but it can be a bit confusing with the defines in sdk_config.h. If you look at the file apply_old_config.h you will see what that is happening when both the old legacy defines are defined, and the new nrfx defines are defined. Maybe this file is causing some issues with your project.

Regarding the clear_bus function, it is present, but not in the nrfx part. It is found on line 173 in nrf_drv_twi.c, and is used in e.g. the twi_master_using_nrf_twi_mngr example in SDK15.2.0.

so depending on nrf_drv_twi_init(..., p_config, ...) is called with p_config->clear_bus_init = 0 or 1, it will clear the bus before calling nrfx_twi(m)_init().

Best regards,

Edvin

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

Sydney — Thu, 06 Dec 2018 06:20:30 GMT

I ran into another issue/question regarding porting my TWI usage from SDK 14 to SDK 15.2, but I'm not sure if it belongs here or in a new ticket. I noticed when porting my application from the nrf_drv_x driver interface to the new nrfx_x interface, nrfx_twi_config_t no longer has the clear_bus_init option that nrf_drv_twi_config_t had. If I include the legacy layer and continue to use nrf_drv_twi, the legacy nrf_drv_twi.c layer has a local twi_clear_bus() function that implements the bus clear option. But if I use nrfx_twi directly, I don't appear to have access to the bus clearing function.

Am I correct in my understanding that the new nrfx_twi driver doesn't have the bus clearing function? What was the thinking behind removing it? My SDK 14 application always had that option enabled, so I'm a bit worried that I may be exposing myself to stuck bus issues with SDK 15.2.

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

Sydney — Thu, 06 Dec 2018 06:09:42 GMT

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.

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

Edvin — Tue, 04 Dec 2018 10:41:51 GMT

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

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

Sydney — Mon, 03 Dec 2018 17:18:44 GMT

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?

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

Edvin — Mon, 03 Dec 2018 09:38:06 GMT

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

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

Sydney — Mon, 03 Dec 2018 06:16:38 GMT

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?

devzone.nordicsemi.com/.../2664.sdk_5F00_config.h devzone.nordicsemi.com/.../nrfx_5F00_config.h

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

Edvin — Tue, 27 Nov 2018 11:29:12 GMT

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

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

Sydney — Fri, 23 Nov 2018 18:45:55 GMT

Understood about Eclipse not being officially supported. I wouldn't have posted about it except that I was going to be posting about this IRQ issue anyway, so I was just hoping someone in the community had come across this issue before and knew how to sort it out.

The only places TWI0/TWI1/SPIM0/SPIM1/SPIM2_ENABLED are defined are in my working copy of sdk_config.h in my application directory in the "legacy layer" sections. But they're all set to 0. I noticed SPI_0_USE_EASY_DMA was set to 1, so I tried setting it to 0 just in case, but I still get the same issue. Also, as mentioned previously, apply_old_config.h has been renamed to apply_old_config.h.orig to prevent inclusion.

I don't have two files called nrfx_config.h. I copied the one from inside the SDK into my application directory and renamed the original file nrfx_config.h.orig to avoid the issue you described.

The compiler output in my original post is from after renaming those three files. I have since gone back and renamed all sdk_config.h and nrfx_config.h files in the SDK (not including examples), even in directories for nRF52840 and nRF52810 just to be sure that my compiler isn't looking to those, and it didn't help.

In trying things out, I've found that in nrfx_irqs_nrf52832.h, if I comment out line 66 (#define nrfx_spim_0_irq_handler SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler) since I'm not trying to use SPIM0 and line 83 (#define nrfx_twi_1_irq_handler SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQHandler) since I'm not trying to use TWI1, my code compiles and things seem to work. But this doesn't seem like the correct solution and leaves me wondering what other problems might be caused by the underlying issue. (If I comment out these lines, the next thing I notice is issues with SAADC events, but I'll worry about that later in case I still have bigger issues with interrupts in general than I realize.)