adding Softdevice BLE (S140) with GPIO attached coprocessor to project without softdevice. hardfault calling existing code after Softdevice active

[rexxdad]

I am extending one of Qorvo's UWB platforms.. adding Softdevice BLE functions..  (which work ok) (this is on sdk 17_1_0)

the coprocessor uses a GPIO connected signaling mechanism,  using interrupts..

calling the existing code after BLE is active causes a hardfault.. 

this is running freetos,  we are in a freetos task. 

I've debugged (using ozone) it to  attempting to setup the interrupt handler for the GPIO pins. 

the existing code calls the nrfx libs 

       return qgpio_pin_irq_configure(&qm33_irq, QGPIO_IRQ_DISABLED);  //according to the doc, a gpio interrupt disable shouldn't impact softdevice.. 

```

enum qerr qgpio_pin_irq_configure(const struct qgpio *qgpio_pin, uint32_t flags)

{

nrfx_err_t r;

enum qerr err;

struct qgpio_cb_data *cb_data;

nrfx_gpiote_in_config_t trigger_config;

uint32_t abs_pin = NRF_GPIO_PIN_MAP(qgpio_pin->port, qgpio_pin->pin_number);  // this sets abs_pin = 25 

/* Init GPIOTE at least once. */

if (!nrfx_gpiote_is_init()) {   // this causes the hardfault.   

   r = nrfx_gpiote_init();

   if (r)

   return QERR_EBUSY;

}

if (flags & QGPIO_IRQ_DISABLED) {

   nrfx_gpiote_in_event_disable(abs_pin);

   nrfx_gpiote_in_uninit(abs_pin);

   return QERR_SUCCESS;

}

```

hardfault window
```
The target stopped in HardFault exception state.

Reason: A fault with configurable priority has been escalated to a HardFault exception at 0x00000000.
```

I don't see any mechanism to cause hardfault on a GPIO pin  with SD active. 
if SD is not active this code works as written 

what am I missing

if I run this code BEFORE setup of softdevice, it works, but softdevice init fails. 

[rexxdad]

I am talking about the post you made in January 12, above,,which introduced the SPIM3 workaround (no way to reference a post here)

the code example (you provided)  defines the buffer and places it via the ld file, but doesn't REFERENCE the buffer in the actual SPIM operations..  you comment in the referenced post 

>Then you should use this buffer for your SPI when you initialize it.
but the example doesn't

[Hung Bui]

Hi Sam, 
Oh sorry, it's been a few months :) 
I had a quick look at the code. You are right that the code doesn't use SPIM. It simply show how to define a dedicated RAM area for SPIM operation. 
But you can see this assigning at line 288 in main.c: 
__attribute__((section(".spim_buffer"))) static uint32_t m_spim_buffer[0x2000];

This buffer is what you should use when you call nrfx_spim_xfer(). The xfer_desc argument in that function contain the pointers to the tx and rx buffer. 

[rexxdad]

yes,  and HOW do you do transceive (both in and out concurrently in same operation) with the buffer??
transceive is used heavily by the firmware app.

that is the question..   I added code to copy the outbound to the top 4k and setup receive in the bottom 4k.
and copy the received data to the original rx buffer . that didn't work. should have been transparent to the app. (in my opinion) 

[Hung Bui]

Hi Sam, 

It's been a while with nRF5SDK but can you just define 2 dedicated buffers ? One for TX and one for RX ? 

Could you describe exactly the issue you are seeing  by "that didn't work" ?

[rexxdad]

I am using some else's firmware, which is quite complex. they NEED SPIM3 for some reason, undisclosed to me, and no answer on their forum site. 

so I just copied the data from their buffer (on send) and copied the data back to their buffer (on receive)
it should have just worked, transparently..  but the app crashed in different places..

I should note that with NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED set to 0,

AND WITHOUT the workaround code, the firmware works as expected..