SDK 15 software crash during SPI session.

Question

Hi 
 After migration from SDK 14.0.0 to 15.0.0 our FW crashes during SPI session 
 We use EasyDMA , so we use SPIM driver directly without wrapper nrf_drv_spi 
 The crash occurs in spim_xfer function, immediately after spim_int_enable function calling. 
 We found some weird workaround. The problem disappears if we add delay in spim_xfer function, immediately after nrf_spim_task_trigger (p_spim, NRF_SPIM_TASK_START); 
 It looks like voodoo, so I would like to know what's going on and what's a write way to manage the problem appropriately. 
 
 Regards

Elkana · Answer

Michao and I found the problem - it was in our code. 
 We used to take FreeRTOS semaphore before OS Scheduler running and somehow it caused a fault. We used to trigger the SPIM and wait in a loop for FreeRTOS semaphore until the completion callback gives it. The problem was calling this code before FreeRTOS scheduler was run. I still don't know why the hard fault (taking semaphore per-se doesn't do that), but replacing the semaphore with nrf_delay_us(..) in case scheduler not running solved the issue. 
 
 {
//
// ... 
//
 context->busy = true;
 
 // init the context as non-blocking SPI
 if (NRF_SUCCESS != nrfx_spim_init(context->spi,
 &context->spi_config,
 xfer_complete_handler,
 context))

 {
 return 0;
 }

 xfer_desc.p_tx_buffer = write_buf;
 xfer_desc.tx_length =len;
 xfer_desc.p_rx_buffer = read_buf;
 xfer_desc.rx_length = len;
 
 // start SPI xfer
 if (NRF_SUCCESS != nrfx_spim_xfer (context->spi,
 &xfer_desc,
 0))
 {
 return 0;
 }
 
 while (context->busy)
 {
 //
 // !! this code block was wrong !!
 //
 
 // wait for xfer-complete
 if (xTaskGetSchedulerState() == taskSCHEDULER_RUNNING)
 xSemaphoreTake(context->tx_ready, SPI_MAX_BLOCKING_WAIT_TIME);
 else
 nrf_delay_us(10);
 } 

 spi_uninit(context);
} 

//
// ... 
//

static void spi_uninit(spi_context_t* context)
{
 nrfx_spim_uninit(context->spi);
 
 // fix SPIM3 current usage - according to errata 195
 // http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.rev1.errata%2Fanomaly_832_17.html
 if (context->spi == &g_spi_3_instance)
 {
 *(volatile uint32_t *)0x4002F004 = 1;
 }
}

t_prachar · Answer

Creating a dedicated transfer buffer for SPIM3 transfers and locating it in RAM3.section1, and having our app RAM start at RAM5.section0 seems to resolve the issue. I've removed the 198 workaround from CFLAGS. SD140 and SPIM3 both seem to work now as expected.

source file: 
 uint8_t rx_buf[RX_BUF_SIZE] __attribute__((section(".spim3_safe"))); uint8_t tx_buf[TX_BUF_SIZE] __attribute__((section(".spim3_safe"))); 
 
 .LD file: 
 MEMORY { FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000 RAM_SPIM3 (rwx) : ORIGIN = 0x20007000, LENGTH = 0x03000 RAM (rwx) : ORIGIN = 0x2000A000, LENGTH = 0x35F00 RAM_NOINIT (rwx) : ORIGIN = 0x2003FF00, LENGTH = 0x00100 } 
 SECTIONS { . = ALIGN(4); .spim3_safe (NOLOAD) : { } > RAM_SPIM3 .mem_section_dummy_ram : { } .log_dynamic_data : { PROVIDE(__start_log_dynamic_data = .); KEEP(*(SORT(.log_dynamic_data*))) PROVIDE(__stop_log_dynamic_data = .); } > RAM .fs_data : { PROVIDE(__start_fs_data = .); KEEP(*(.fs_data)) PROVIDE(__stop_fs_data = .); } > RAM .noinit (NOLOAD) : { } > RAM_NOINIT 
 } INSERT AFTER .data;