This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MOSI not correctly driven on nRF53 SPIM

We are using nRF5340 Engineering D and are having issues with the SPIM peripheral.

In some transactions, the MOSI line is not correctly driven.

The following capture shows a transaction where the expected data is 31 00 01 00 B6 ...

MOSI is not connected to a slave and is shown in green.

The expected bits seem to be driven to a few mV (see red circle)

Some more details on the transaction: We are using SPIM via the Zephyr SPI driver. The first two bytes are transmitted with options (SPI_LOCK_ON | SPI_HOLD_ON_CS).

The issue occurs on both SPIM2 and SPIM3.

Is this a known problem with the nRF53?

  • The problem seems to depend on the value of the first byte.

    Here is an example code snippet:

        uint8_t tx_a[] = { 0x31, 0xCC, 0xAA, 0xCC, 0xAA };
        nrfx_spim_xfer_desc_t xfer = {
          .p_tx_buffer = tx_a,
          .tx_length   = sizeof(tx_a),
          .p_rx_buffer = NULL,
          .rx_length   = 0,
        };
        nrfx_spim_t spim = NRFX_SPIM_INSTANCE(2);
        nrfx_spim_config_t config = NRFX_SPIM_DEFAULT_CONFIG(10, 11, NRFX_SPIM_PIN_NOT_USED, NRFX_SPIM_PIN_NOT_USED);
        config.frequency = NRF_SPIM_FREQ_250K;
        nrfx_spim_uninit(&spim);
        nrfx_spim_init(&spim, &config, NULL, NULL);
        nrf_gpio_pin_clear(19); /* pull CSN low */
        nrfx_spim_xfer(&spim, &xfer, 0);

    Here is the resulting signal on MOSI:

  • I'm terribly sorry, this is probably a false alert.

    While we disconnected the SPI slave on the CSN pin in question (pin 19), we had another slave on the bus.

    This other slave was a LIS2DW12 / IIS2DLPC acceleration sensor. We did not activate the chip select to this pin, however that sensor also has a I2C interface on the same pins as MOSI/MISO which is enabled by default.

    This chip has a I2C address of 0b001100x, which would explain why we see it interfering when transmitting 0x31.

    I suspect that the issue will be resolved when we disable the I2C function on that chip (which the iis2dplc driver in Zephyr apparently doesn't do).

Related