GPIOTE trigger of SPIM read using EasyDMA with manual CS

RE: GPIOTE trigger of SPIM read using EasyDMA with manual CS

Pallavi Patil — Thu, 27 Aug 2026 11:05:07 GMT

Hie,

If this is a continuous acquisition, add NRFX_SPIM_FLAG_REPEATED_XFER together with NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER, so each DRDY re-runs the same held transfer without you re-arming it every time. Without that you get exactly one read and then silence
if the CS is still the manual GPIOTE one, the same DRDY edge should both pull CS low and start the SPIM, which stays a single handle, you just attach the second task with nrfx_gppi_ep_attach()

Regards

Pallavi

RE: GPIOTE trigger of SPIM read using EasyDMA with manual CS

Jason0123456 — Wed, 26 Aug 2026 15:30:37 GMT

Thanks for the response Pallavi. If you look at the drdy_init() routine in the relevant code snippet above you will note that I’ve performed each of your recommendations.

GPIOTE Task/Event Enables:

CS Pin: Once you configure the CS pin as an output using nrfx_gpiote_output_configure(), make sure to call nrfx_gpiote_out_task_enable() on the CS pin. (see line 139).

DRDY Pin: The IN event won't generate until you execute nrfx_gpiote_trigger_enable(inst, DRDY_PIN, false). (see line 63)

Also, please check the parameter order in the nrfx_gppi_conn_alloc() function signature, the parameter order strictly expects the triggering event address first, followed by the target task address second. Passing them in reverse order won't trigger a compiler error since both are standard integer addresses, but it will map the signal routes backward, preventing the PPI channel from triggering. (see line 122).

SPIM CS Line Ownership:

The next thing I would check is whether the SPIM is still holding the CS pin. With a manual CS you have to set ss_pin = NRF_SPIM_PIN_NOT_CONNECTED, otherwise the driver keeps driving the pin and ends up fighting the GPIOTE task. (see below).

	nrfx_spim_config_t spim_config = NRFX_SPIM_DEFAULT_CONFIG(SPIM_SCK_PIN,
                                                              SPIM_MOSI_PIN,
                                                              SPIM_MISO_PIN,
                                                              NRF_SPIM_PIN_NOT_CONNECTED);

	spim_config.frequency = 8000000;

	err = nrfx_spim_init(&spi_inst, &spim_config, NULL, NULL);
    if (err) {
        return 0;
    }	

	uint32_t flags = 0;	
	uint16_t reg_data = 0;

	nrf_gpio_cfg_output(SPIM_CS_PIN);

I would like to also note that I have a convst_init() routine that successfully uses the high-level gppi routines to connect a timer to a GPIOTE output. See below.

// ----------------------------------------------------------------------------
// ----------------------------------------------------------------------------	
void convst_init(nrfx_gppi_handle_t* gppi_h) {

	int err;	
	
	uint8_t out_channel;		
	
	// ---------------------------------------
	// INIT GPIOTE
	// ---------------------------------------	
	if(!nrfx_gpiote_init_check(&gpiote_inst))
	{
		err = nrfx_gpiote_init(&gpiote_inst, NRFX_GPIOTE_DEFAULT_CONFIG_IRQ_PRIORITY);
		if (err != 0) {
			LOG_ERR("GPIOTE init fail: %x", err);	
		}
		LOG_INF("GPIOTE status: %s", nrfx_gpiote_init_check(&gpiote_inst) ? "initialized" : "not initialized");
	}

	// ---------------------------------------
	// CONVST Output
	// ---------------------------------------	
	err = nrfx_gpiote_channel_alloc(&gpiote_inst, &out_channel);
	if (err != 0) {
		LOG_ERR("Channel alloc fail: %x", err);	
	}
	
	nrfx_gpiote_output_config_t gpiote_out_cfg = {
		.drive = NRF_GPIO_PIN_S0S1,
		.input_connect = NRF_GPIO_PIN_INPUT_DISCONNECT,
		.pull = NRF_GPIO_PIN_NOPULL,
	};

	nrfx_gpiote_task_config_t gpiote_task_cfg = {
		.task_ch = out_channel,
		.polarity = NRF_GPIOTE_POLARITY_TOGGLE,
		.init_val = NRF_GPIOTE_INITIAL_VALUE_HIGH,
	};

	err = nrfx_gpiote_output_configure(&gpiote_inst, CONVST_PIN, &gpiote_out_cfg, &gpiote_task_cfg);
	if (err != 0) {
		LOG_ERR("GPIOTE configure fail: %x", err);	
	}

	nrfx_gpiote_out_task_enable(&gpiote_inst, CONVST_PIN);
	
	// ---------------------------------------
	// INIT TIMER
	// ---------------------------------------
	nrfx_timer_config_t timer_cfg = {
    	.frequency = NRFX_MHZ_TO_HZ(1), 
    	.mode = NRF_TIMER_MODE_TIMER,
    	.bit_width = NRF_TIMER_BIT_WIDTH_16,
    	.interrupt_priority = NRFX_TIMER_DEFAULT_CONFIG_IRQ_PRIORITY,
	};    
	
   	err = nrfx_timer_init(&timer_inst, &timer_cfg, NULL);
     if (err != 0) {
		LOG_ERR("TIMER init fail: %x", err);	
	}

    nrfx_timer_clear(&timer_inst);   

    nrfx_timer_extended_compare(&timer_inst, NRF_TIMER_CC_CHANNEL1, 4, NRF_TIMER_SHORT_COMPARE1_CLEAR_MASK, false);	

	// ---------------------------------------
	// 3. CONNECT GPIOTE w/ TIMER via GPPI
	// ---------------------------------------
	err = nrfx_gppi_conn_alloc(
        nrfx_timer_compare_event_address_get(&timer_inst, NRF_TIMER_CC_CHANNEL1),
        nrfx_gpiote_out_task_address_get(&gpiote_inst, CONVST_PIN), gppi_h);
    if (err != 0) {
		LOG_ERR("GPPI channel allocation fail: %x", err);	
	}	

    nrfx_timer_enable(&timer_inst);		  

	nrfx_gppi_conn_enable(*gppi_h);	
}

Below is how I am calling each routine. I'm assuming I need two separate gppi handles since these are standalone and separate event/task and peripherals.

Any additional thoughts on what I could be missing?

nrfx_gppi_handle_t drdy_gppi_h, convst_gppi_h;		
	
	// timer triggers conversion start (convst) to ADC 
	convst_init(&convst_gppi_h);	

	// drdy from ADC triggers SPI read of 15 samples (240 bytes)
	drdy_init(&drdy_gppi_h);

RE: GPIOTE trigger of SPIM read using EasyDMA with manual CS

Pallavi Patil — Wed, 26 Aug 2026 11:29:17 GMT

Hie Jason,

Thanks a lot for your patience.

Your GPPI implementation looks solid to me. nrfx_gppi_conn_alloc() and nrfx_gppi_conn_enable() are the correct calls here they handle configuring the DPPI channel and managing the PPI bridge automatically if the endpoints cross power domains. I don't suspect the connection logic itself. You should probably check if the few initialization step have been implemented correctly

GPIOTE Task/Event Enables:

CS Pin: Once you configure the CS pin as an output using nrfx_gpiote_output_configure(), make sure to call nrfx_gpiote_out_task_enable() on the CS pin. Without this, the OUT task won't drive the pin via PPI, leading to the common issue of the hardware getting stuck in a half-configured state where the channel triggers but CS pin ignores it completely and never changes state.

DRDY Pin: The IN event won't generate until you execute nrfx_gpiote_trigger_enable(inst, DRDY_PIN, false).Setting the last parameter (int_enable) to false configures the hardware to generate the event locally without routing an interrupt to the CPU. This allows the PPI path to run entirely in hardware without invoking any software handlers or interrupting core execution.
Also,please check the parameter order in the nrfx_gppi_conn_alloc() function signature, the parameter order strictly expects the triggering event address first, followed by the target task address second. Passing them in reverse order won't trigger a compiler error since both are standard integer addresses, but it will map the signal routes backward, preventing the PPI channel from triggering.
SPIM CS Line Ownership:

The next thing I would check is whether the SPIM is still holding the CS pin. With a manual CS you have to set ss_pin = NRF_SPIM_PIN_NOT_CONNECTED, otherwise the driver keeps driving the pin and ends up fighting the GPIOTE task. Same goes for the spim node if they are using pinctrl.
[quote user=""]. I realize that I will likely have to add a timer to meet the CS timing requirements of the ADC IC,[/quote]
Since the Timer output (P1.12) and DRDY (P1.11) both sit on the GPIOTE20 instance, using GPIOTE20 for the CS pin as well keeps the whole event-task loop inside a single hardware domain and will keep your resource allocation clean.

Please get back to us if you have more questions.

Best Regards

Pallavi

RE: GPIOTE trigger of SPIM read using EasyDMA with manual CS

Pallavi Patil — Tue, 25 Aug 2026 11:54:46 GMT

Hie Jason,

We are currently looking into this.. I will update you as sonn as I have an answer from the team. Thanks for your patience and extremely sorry for the delay.

Regards

Pallavi