SDK 15 software crash during SPI session.

RE: SDK 15 software crash during SPI session.

Dan Halbert — Wed, 23 Oct 2019 12:46:06 GMT

A few more notes here for anyone else reading: the errata mentions using a separate RAM "block", and it appears from the datasheet that a block includes both section 0 and section 1, so using two sections in the same block won't help (t_prachar used separate blocks).

Also see this support case: https://devzone.nordicsemi.com/f/nordic-q-a/52829/errata-198-has-additional-restrictions-and-resource-implications, which notes that if you use dcx, then the command and data buffers must also be in separate blocks.

RE: SDK 15 software crash during SPI session.

t_prachar — Wed, 23 Oct 2019 00:17:36 GMT

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;

RE: SDK 15 software crash during SPI session.

Dan Halbert — Tue, 22 Oct 2019 23:30:52 GMT

We also have seen this again, in a different context, but haven't had time to create a simple test program. The anomaly 198 workaround must be enabled to produce the failure.

Just now I found this in release_notes.txt for SDK 15.3.0, under known issues, there's this warning:

- The workaround for Anomaly 198 for nRF52840 SPIM3 peripheral that has been implemented in nrfx_spim cannot be used with a SoftDevice.
Flag NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED must be set to zero.
The workaround based on a dedicated RAM block for SPIM3 must be used instead.

RE: SDK 15 software crash during SPI session.

t_prachar — Tue, 22 Oct 2019 23:24:06 GMT

I'd like to re-open this thread. In our system we are using SPIM3 under SDK15.0 on nRF52840 and it's been working fine with no issues. But, we start SD140, the first attempt to call nrfx_spim_xfer() will cause a hard fault. If the SD140 isn't initialized, then everything works perfectly. SPIM3 has been fully initialized before the SD140 is started.

Looking at the resource usage document for SD140 6.0.0, it shows SPIM3 as completely open, so this behavior is unexpected.

Perhaps an issue with interrupts or DMA?

From sdk_config.h:

#define NRFX_SPIM3_ENABLED 1
#define NRFX_SPIM_EXTENDED_ENABLED 0

CFLAGS += -DNRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED

RE: SDK 15 software crash during SPI session.

MartinBL — Thu, 15 Nov 2018 12:43:08 GMT

Thank you for the update!

RE: SDK 15 software crash during SPI session.

Elkana — Thu, 15 Nov 2018 10:51:43 GMT

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;
    }
}

RE: SDK 15 software crash during SPI session.

MartinBL — Mon, 15 Oct 2018 09:05:07 GMT

Hi,

I tried to play around with S140 v6.1.0 and the SPIM, but I wasn't able to recreate you problem with this little to go on. If you don't think your problem is related to the original issue in this thread, can you please open a new thread and make summary of what you experience and what you have tried? Can you also try to do a DEBUG build as user "arturo182" suggests in your github link (and as I was trying to suggest with my own link earlier)? A lot of the code in the Nordic universe uses the Error module which resets your MCU on asserts unless you explicitly tell it otherwise.

RE: SDK 15 software crash during SPI session.

Dan Halbert — Fri, 12 Oct 2018 15:49:32 GMT

We were using SPIM3 on the nRF52840. One of our users discovered that if we disable SPIM3 in nrfx_config.h and use SPIM2 instead, the problem does not occur. This contrasts with MichaO's problem, which already has SPIM3 disabled.

This issue is being discussed here: github.com/.../1222

RE: SDK 15 software crash during SPI session.

MartinBL — Fri, 12 Oct 2018 08:43:52 GMT

Hi,

Not to my knowledge. If your system resets it is most likely recovering from a hard fault or (dependent on your compilation settings) an assert.

RE: SDK 15 software crash during SPI session.

Dan Halbert — Fri, 12 Oct 2018 03:25:29 GMT

Michao and MartinBL,

Was the cause of this problem ever diagnosed? Thanks.

We've seen what sounds like the same problem with the nRF52840 DK, using SD140 v6.1.0, and nrfx v1.3.1. We are not using the full SDK, only nrfx. After we advertise a BLE peripheral, a spim_xfer() causes what appears to be a reset. If we create the peripheral but don't advertise, the problem does not occur. The problem occurs with SPIM, but not with TWIM or UART peripherals.

I don't have a C test case right now because the code that causes this is written in CircuitPython, which is implemented as described above. But I could probably work one up if necessary.

I set the HardFault_Handler to loop on a fault, so I could get a backtrace, but the handler doesn't appear to be entered, so I'm not sure what's causing the reset.

RE: SDK 15 software crash during SPI session.

MartinBL — Fri, 08 Jun 2018 11:37:59 GMT

Solved here: https://devzone.nordicsemi.com/f/nordic-q-a/35145/crashing-during-the-spi-transfer-on-nrf52810

RE: SDK 15 software crash during SPI session.

MartinBL — Fri, 08 Jun 2018 11:37:47 GMT

Solved here: https://devzone.nordicsemi.com/f/nordic-q-a/35145/crashing-during-the-spi-transfer-on-nrf52810

RE: SDK 15 software crash during SPI session.

stone.xiang — Wed, 06 Jun 2018 11:49:02 GMT

Hi MartinBL,

I met the same crash when spim transfer on NFR52810, could you please help me, I spent a lot of time on this issue.

Thanks.

Regards.

RE: SDK 15 software crash during SPI session.

stone.xiang — Wed, 06 Jun 2018 04:04:53 GMT

Hi Michao,

I met the same crash problem on NRF52810, do you find the reason why it will crash and how to solve this problem? add a delay?

Regards.

RE: SDK 15 software crash during SPI session.

MartinBL — Thu, 03 May 2018 13:22:16 GMT

Have you tried without the Softdevice?
Can you upload your project? Or at least the SPIM related parts? We can make the case private if you want confidentiality.

RE: SDK 15 software crash during SPI session.

MichaO — Thu, 03 May 2018 13:05:45 GMT

It's true. We've flashed the Softdevice to our device ( in fact it's EB nRF52840-Preview-DK), but haven't called its API functions and not initialized it.

RE: SDK 15 software crash during SPI session.

MartinBL — Thu, 03 May 2018 10:07:47 GMT

Does it mean that you have flashed the Softdevice to your device, but not initialized BLE at all? You said above that you are using a Softdevice.

RE: SDK 15 software crash during SPI session.

MichaO — Thu, 03 May 2018 08:56:07 GMT

1. Yes, we are using the nRF52840

2. Softdevice version is S140 v6.0.0

3. This is happening on every call

4. We still didn't add BLE functionality to our project, so we are not advertising, etc.

RE: SDK 15 software crash during SPI session.

MartinBL — Thu, 03 May 2018 07:17:30 GMT

Can you confirm that you are using the nRF52840?
What Softdevice version is this? S140 v6.0.0?
Is this happening on every call to spim_xfer? Or just once in a while?
What else is going on at the time? Are you advertising, in a connection, etc.? Are you using the time slot API?

The PC indicates that something goes wrong inside the Softdevice. The more context we get, the easier it will be to figure out why it asserts.

RE: SDK 15 software crash during SPI session.

MichaO — Wed, 02 May 2018 14:43:55 GMT

1. I get a hard fault. PC register in fault_info is 0x0000064B

2. The minimum delay I have to add is 120 microseconds.

3. SPIM configuration is as follows:

NRFX_SPIM_ENABLED 1
NRFX_SPIM0_ENABLED 1
NRFX_SPIM1_ENABLED 1
NRFX_SPIM2_ENABLED 1
NRFX_SPIM3_ENABLED 0
NRFX_SPIM_EXTENDED_ENABLED 0
NRFX_SPIM_MISO_PULL_CFG 1
NRFX_SPIM_DEFAULT_CONFIG_IRQ_PRIORITY 7
NRFX_SPIM_CONFIG_LOG_ENABLED 0
NRFX_SPIM_CONFIG_LOG_LEVEL 3
NRFX_SPIM_CONFIG_INFO_COLOR 0
NRFX_SPIM_CONFIG_DEBUG_COLOR 0
NRFX_SPIM_NRF52_ANOMALY_109_WORKAROUND_ENABLED 0

p_config parameter of nrfx_spim_init function as follows:

p_config->sck_pin             =0x13
p_config->mosi_pin           =0x14
p_config->miso_pin           =0x15
p_config->ss_pin               =0xFF
p_config->ss_active_high =0
p_config->irq_priority         =0x07
p_config->orc                     =0xFF
p_config->frequency          =NRF_SPIM_FREQ_4M
p_config->mode                 =NRF_SPIM_MODE_0
p_config->bit_order            =NRF_SPIM_BIT_ORDER_MSB_FIRST

4. Interrupt priority is 7

5. We are using a Softdevice

Regards

RE: SDK 15 software crash during SPI session.

MartinBL — Wed, 02 May 2018 13:13:03 GMT

Hi,

What do you mean by crash? Do you get a hard fault or just some sort of assert? Are you debugging like this?
How long is the delay that you add?
How do you configure the SPIM?
What kind of interrupt priority does the SPIM use?
Are you using a Softdevice?