• State Verified Answer
  • Replies 2 replies
  • Subscribers 63 subscribers
  • Views 631 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 268535
Options
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

Stephan Walter

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?

Parents
  • +1

    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).

Reply
  • +1

    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).

Children
No Data
Related