Solution approach for handling GPIO interrupts. SDK 15.3 S132

[cemerick]

Went through the pin_change_int example and of course it works fine.

Migrated that to custom board and it also worked fine with main loop.

So I then tried to use that as basis for real application that has to service an external interrupt.

In the main application, there are spi read and write functions.

When they are active and in a wait loop, the external interrupt is not triggered.

I am assuming that is because the priority level is the same and is therefore blocked.

I set the gpiote priority to 2 and still the interrupt is not triggered.

I am sure anyone reading sensors etc must deal with this type of problem everyday.

Right now the bluetooth stack and services are not being used and the interrupts still don't trigger.

The interrupt triggers once at startup but then never again.

In the pin_change_int example I did not see where the interrupt is cleared and enabled.

Is that what I am missing ? 

[cemerick]

Is is screenshot after breaking in middle of program.

[cemerick]

Looking into the spi code I was using, is using the legacy SPI driver an option or  is there another solution that would integrate better with this application ?

[cemerick]

Assuming that I can use a sdk 15.3 spi dirver/solution I wanted to point out how the CC3100 is ported in case it makes a difference. Required is an Open,Close, Read and Write function. The Read is always triggered by an IntRQ from the CC3100.  The data read/write is simplex in that any data received during a write is discarded. They use a write and read synchronization pattern to mark the start of data.

I was wondering if the spi driver functions could do this readily. It was not clear to me if there was a way to Write and Read in a simplex manner. 

In case it help explains better he is a link to the CC3100 spi flow : http://processors.wiki.ti.com/index.php/CC3100_SPI_Host_Interface

Summary of flow below.

I have assumed that using the original register based spi code I had is  a bad idea and will not work reliably..   The CC3100 can use up to a 20 Mhz clock. Any recommendations on a reliable clock speed for a nrf52832 running at a minimum active beacon scans where good data is required from beacons sending 5 -  20 broadcasts per second is appreciated. For example, is 4 Mhz expected to work reliably assuming the interrupt priorities are set correctly ?   

[bjorn-spockeli]

Quote:

Are you saying that if I clean up per your suggestions that the GPIOTE driver will work. If the GPIOTE interrupt priority in the sdk_config is set to 2 then the CC3100 interrupt handler defined in the gpio_init in main will execute from that interrupt. Or is that wrong since main itself if a much lower priority ? 

I just want to remove any issues that could be related to the driver overwriting the configuration done at register level for the GPIOs or vice versa that the register level configuration is overwriting the confiuration set by the driver. 

The GPIOTE register values look correct so you you should get the interrupt handler to fire due to the GPIOS being pulledhigh or low. Since the SPI code is running at mains context there should not be any priority issue, main always runs at the lowest priority, i.e. 7.  So as long as the GPIOTE interrupt priority is set higher than mains you should get the interrupt. 

The pins configured in the registers are pin 27 and pin 0 ( which is the P0.00/XL1 pin which is used for the 32kHz crystal on our nRF52 DK) is this correct for your board?

Quote:

Any recommendations on a reliable clock speed for a nrf52832 running at a minimum active beacon scans where good data is required from beacons sending 5 -  20 broadcasts per second is appreciated. For example, is 4 Mhz expected to work reliably assuming the interrupt priorities are set correctly ?  

The SoftDevice will always have the highest priority so it will preempt any application code running if there is a BLE event that is handled. 

[cemerick]

Yes is the button is on pin 27 and the interrupt request  on pin 0.  The button interrupt works but not the intRQ. I see that the CC3100 SoC already has the intRQ high so there is no lotohi transition to catch.

Can I get an interrupt whenever the pin is high ?  What do you do in those cases where maybe the transition was missed (since higher priority was in process or other )  ?  So is it possible to get interrupt when a pin is already high ? I tried many variants and monitored all the key pins in/out of the CC3100 and NRF52832.  The intRQ goes high when the CC3100 is enabled but I never get the interrupt. When that is happening, the interrupt on pin 27 is working but it is a push button with a hitolo transition.