SPI behaviour differs between debug and release modes

RE: SPI behaviour differs between debug and release modes

Simonr — Tue, 17 Nov 2020 12:52:28 GMT

Sorry about the delayed response, but Edvin is out of office for the time being, and we've only now gotten to his backlog. Does this spi_xfer_done event return true even though you are receiving the wrong values in release mode? Is it reached/trigged at all when your application is running?

I also think that what Edvin said about the speed of the application in Release mode is what's causing this. You can try confirming this by setting the Optimization Level in SEGGER's project options to NONE for instance?

Best regards,

Simon

RE: SPI behaviour differs between debug and release modes

Ronnie Tango — Thu, 12 Nov 2020 18:23:17 GMT

Hi, thanks for the response.

The spi read function does indeed have a callback:

void spi_event_handler(nrf_drv_spi_evt_t const * p_event,
                       void *                    p_context)
{
   spi_xfer_done = true;
}

but unfortunately waiting for this to be completed before checking the register result did not change anything...

Is there any other info I can provide that might give a clue? I believe I'm using the SPI driver (nrfx_spi_xfer) rather than SPIM.

Thanks

RE: SPI behaviour differs between debug and release modes

Edvin — Mon, 02 Nov 2020 10:01:28 GMT

without knowing too much about this driver, it may look like there is an event handler that you should wait for somewhere. The reason why it is working in debug is that the release version may have some more optimization (particularly for time), so that the function that "reads the registers" (basically triggers the SPI transaction) returns, but the callback hasn't triggered yet.

So does the SPI have a callback? If yes, try to wait for the callback before you check the tmpData. The callback (if present) is set in the init function of your SPI. Something like this snippet from the SDK\examples\peripheral\spi example:

APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL));

If the SPI is set up with an event handler, the SPI calls are none-blocking, meaning they will return before the SPI transactions are done. If you do not have an SPI handler the calls are blocking, meaning they will not return until the transaction is complete.

Depending on whether you are using the spim or spi driver this is implemented a bit differently, but looking at the SPIM implementation:

From spim_xfer() in nrfx_spim.c:

    if (!p_cb->handler)
    {
        while (!nrf_spim_event_check(p_spim, NRF_SPIM_EVENT_END)){}

#if NRFX_CHECK(NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED)
        if (p_spim == NRF_SPIM3)
        {
            anomaly_198_disable();
        }
#endif
        if (p_cb->ss_pin != NRFX_SPIM_PIN_NOT_USED)
        {
#if NRFX_CHECK(NRFX_SPIM_EXTENDED_ENABLED)
            if (!p_cb->use_hw_ss)
#endif
            {
                if (p_cb->ss_active_high)
                {
                    nrf_gpio_pin_clear(p_cb->ss_pin);
                }
                else
                {
                    nrf_gpio_pin_set(p_cb->ss_pin);
                }
            }
        }
    }
    else
    {
        spim_int_enable(p_spim, !(flags & NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER));
    }

So if there is a callback, p_cb->handler, the task will be triggered, and then return.

What you are seeing is probably that bmi160_get_regs() returns, but the callback is not yet triggered, so the data is not actually received. Then you trigger a new SPI read, but in the meantime, the callback is received, and the data is updated. Try to wait for the callback, and set spi_xfer_done = true in the callback (like in the example):

volatile bool spi_xfer_done;

void spi_event_handler(nrf_drv_spi_evt_t const * p_event,
                       void *                    p_context)
{
    spi_xfer_done = true;
    ...
    
}

static void my_function()
{
    uint8_t tmpData = 0;
    
    spi_xfer_done = false;
    uint8_t rslt = bmi160_get_regs(BMI160_CHIP_ID_ADDR, &tmpData, 1, &bmi160);
    while (spi_xfer_done == false)
    {
        // Wait
    }
    if (tmpData == BMI160_CHIP_ID)
    {
        ledOn(GREEN_LED_MASK);
    }
    ...
}

Try something like that.

Best regards,

Edvin

RE: SPI behaviour differs between debug and release modes

Ronnie Tango — Fri, 30 Oct 2020 15:22:21 GMT

Hi,

Thanks for your reply - sorry, I should probably have included both points you mention in the original post.

The bmi160_get_regs() function comes from the bmi160 driver provided by Bosch, and is as follows:

int8_t bmi160_get_regs(uint8_t reg_addr, uint8_t *data, uint16_t len, const struct bmi160_dev *dev)
{
    int8_t rslt = BMI160_OK;

    /* Variable to define temporary length */
    uint16_t temp_len = len + dev->dummy_byte;

    /* Variable to define temporary buffer */
    uint8_t temp_buf[temp_len];

    /* Variable to define loop */
    uint16_t indx = 0;

    /* Null-pointer check */
    if ((dev == NULL) || (dev->read == NULL))
    {
        rslt = BMI160_E_NULL_PTR;
    }
    else if (len == 0)
    {
        rslt = BMI160_READ_WRITE_LENGHT_INVALID;
    }
    else
    {
        /* Configuring reg_addr for SPI Interface */
        if (dev->interface == BMI160_SPI_INTF)
        {
            reg_addr = (reg_addr | BMI160_SPI_RD_MASK);
        }
        rslt = dev->read(dev->id, reg_addr, temp_buf, temp_len);

        if (rslt == BMI160_OK)
        {
            /* Read the data from the position next to dummy byte */
            while (indx < len)
            {
                data[indx] = temp_buf[indx];
                indx++;
            }
        }
        else
        {
            rslt = BMI160_E_COM_FAIL;
        }
    }

    return rslt;
}

The dev->read function pointer (line 30) in turn calls the user spi read function bmi160_spi_read() from the original post.

In both debug and release mode, bmi160_get_regs() is always returning no error (BMI160_OK).

As far as I can tell, tmpData should definitely be getting set correctly in bmi160_get_regs(). Using the debugger, the result of the two get_regs calls from the first code snippet in the original post are:

Debug mode:

bmi160_get_regs(BMI160_CHIP_ID_ADDR…) -> data[0] = 0xD1 // 0xD1 is the correct chip id

bmi160_get_regs(BMI160_ACCEL_RANGE_ADDR…) -> data[0] = 0x0C // 0x0C is the correct accelerometer range

Release mode:

bmi160_get_regs(BMI160_CHIP_ID_ADDR…) -> data[0] = 0x00

bmi160_get_regs(BMI160_ACCEL_RANGE_ADDR…) -> data[0] = 0xD1 // 0xD1 is the chip id that should have been returned last time

RE: SPI behaviour differs between debug and release modes

Edvin — Fri, 30 Oct 2020 14:17:26 GMT

Hello,

Can you try to check what bmi160_get_regs() returns when you are running in release mode?

Does it return NRF_SUCCESS?

I don't know what your drivers looks like. What does bmi160_get_regs() look like? Is there any chance that it doesn't set the tmpData? I think you need to debug (actually debug and monitor logging or something, not setting it back to "Debug mode").

BR,
Edvin