nrf51422 hardfault when disabling gpiote task

[kvrbek]

Hi everybody!

Im trying to implement slave spi to bluetooth bridge.

In short, when cs line goes low, i want that one handshake line automaticaly go in busy (high) state (nBLE_RTR_PIN), and i did that througt ppi (note that SPI_nCS_INT_PIN is shorted in hardware with slaves SPIS_nCS_PIN):

#define BUSY_PPI_CHANNEL    0
#define BUSY_EVENT_ID       0
#define BUSY_TASK_ID        1

void cs_int_init(void)
{
    nrf_gpio_cfg_input(SPI_nCS_INT_PIN, NRF_GPIO_PIN_NOPULL);
    nrf_gpiote_event_configure(BUSY_EVENT_ID, SPI_nCS_INT_PIN, NRF_GPIOTE_POLARITY_HITOLO);
    nrf_gpio_cfg_output(nBLE_RTR_PIN);
    nrf_gpiote_task_configure(BUSY_TASK_ID, nBLE_RTR_PIN, NRF_GPIOTE_POLARITY_LOTOHI, NRF_GPIOTE_INITIAL_VALUE_LOW);
    
    //sd_ppi_channel_assign(BUSY_PPI_CHANNEL, &NRF_GPIOTE->EVENTS_IN[BUSY_EVENT_ID], &NRF_GPIOTE->TASKS_OUT[BUSY_TASK_ID]);   
    NRF_PPI->CH[BUSY_PPI_CHANNEL].EEP = (uint32_t)&NRF_GPIOTE->EVENTS_IN[BUSY_EVENT_ID];
    NRF_PPI->CH[BUSY_PPI_CHANNEL].TEP = (uint32_t)&NRF_GPIOTE->TASKS_OUT[BUSY_TASK_ID];
    nrf_gpiote_event_enable(BUSY_EVENT_ID);
    nrf_gpiote_task_enable(BUSY_TASK_ID);

    //sd_ppi_channel_enable_set(BUSY_PPI_CHANNEL);
    NRF_PPI->CHEN = (PPI_CHEN_CH0_Enabled << PPI_CHEN_CH0_Pos);
}

and line nBLE_RTR_PIN is going automatically in high state - ok. Now when mcu finish with processing/sending I want that slave (nrf51) manually notify master (so it can initiate another spi transaction) by pulling nBLE_RTR_PIN in ready (low) state:

nrf_gpiote_task_disable(BUSY_TASK_ID);  // -> but I'm getting hard fault here...
nrf_gpio_pin_write(nBLE_RTR_PIN, 0);
nrf_gpiote_task_enable(BUSY_TASK_ID);

[kvrbek]

Hi,

Yes, I tried already disabling PPI channel, but with the same result. Softdevice is s110 v8.0.0.

It seems that I have problem somewhere else, and nrf51 hardfaults because of stopping during debugging. Maybe my slave spi processing function what executes in spis evennt handler was long (it wasnt blocking, and not too long in executnig but...).

Anywhay, In event handler only signal (rtos is used in application) is set now. All processing including clearing RTR pin as above is done in main thread after catching signal and everything is working fine now.

Regards

[RK]

You can't break whilst debugging with the softdevice going. As soon as you do, the timing is messed up and the softdevice errors the next time it gets an interrupt as it sees it's failed to properly service events within the critical BTLE time requirements and faults.

You get to stop once and that's it, you can't resume afterwards.