nrf_gpio_pin_set causes random MCU resets during Manual-CS SPI transactions

[kobyatom]

I created a function, spi_read, that performs a SPI transaction to RAM, comprised of 400 chunks, each 96 bytes long.

The CS control is set to manual.

that function crashes every 5-30 runs, randomly, probably at the call to nrf_gpio_pin_set.

Please see its code below.

As a patch, I added a 1 microsecond wait after nrf_gpio_pin_set, which occurs after every chunk, which solves the issue,

If the PATCH segment is removed, the reset occurs randomly, every 5-30 runs.

I'm using the NRF52840, running SDK version 17.0.2.

astatus_t spi_read(const hal_spi_t * p_spi, uint16_t len, uint8_t reg_add, uint8_t * p_read_buf)
{
    astatus_t rc = AE_SUCCESS;
    spi_xfer_done = false;
    nrfx_spim_xfer_desc_t const tx_xfer_desc = NRFX_SPIM_XFER_TX(&reg_add, 1);
    nrf_gpio_pin_clear(p_spi->spi_manual_cs);
    if ( NRFX_SUCCESS != nrfx_spim_xfer(&m_spi_master[p_spi->spi_index], &tx_xfer_desc, 0) )
    {
        NRF_LOG_ERROR("atom_hal_spi_read_write nrfx_spim_xfer");
        rc = AE_FAILURE;
    }
    if (AE_SUCCESS == rc)
    {
        rc = wait_for_spi_completion(OP_TIMEOUT_MSEC);
    }
	if ( rc != AE_SUCCESS )
    {
        ATLOG_WARN("wait_for_spi_completion failed %d", rc);
        goto hal_spi_read_exit;
    }

    nrfx_spim_xfer_desc_t const rx_xfer_desc = NRFX_SPIM_XFER_RX(p_read_buf, len);
    spi_xfer_done = false;
    if ( NRFX_SUCCESS != nrfx_spim_xfer(&m_spi_master[p_spi->spi_index], &rx_xfer_desc, 0) )
    {
        NRF_LOG_ERROR("atom_hal_spi_read_write nrfx_spim_xfer");
        rc = AE_FAILURE;
    }
    if (AE_SUCCESS == rc)
    {
        rc = wait_for_spi_completion(OP_TIMEOUT_MSEC);
    }
hal_spi_read_exit:
    nrf_gpio_pin_set(p_spi->spi_manual_cs);
    
    /////////// PATCH
    atom_hal_time_delay_us(1);
    /////////// PATCH
    return rc;
}

How can I better solve this?

[Susheel Nuguru]

Yaakov,

One of my colleague saw some issue with RESETREAS when the reset is caused by too much decoupling on VDD (i.e. to much cap. load) which caused REG0 to become unstable that again led to POR. This POR bit seems to be not registered for some reason. Can you double check your schematics (or upload them here so that we can review them) to see if this is behavior is relevant to you.

[kobyatom]

Thank you Susheel. I will forward this to our HW engineer. 

[Susheel Nuguru]

Great, Please let me know if this helps.