Problem using the nRF52840 to interface an ADS1298 via SPI

Hi DevZone,

I am using the nRF52840 to interface an ADS1298 (ECG Chip) via SPI.

I want to test if the communication between the devices are working by:

    -  Sending a RREG (Read From Register) opcode from the nRF52840 to the ADS1298

    -  And then read its ID Register.

The RREG command is two bytes long, and for multi-byte commands the following needs to be done:

    1.  Send the first byte and then wait for 4 * tCLK  before sending the next byte.

    2. The CS (or SS) pin needs to be held low during the entire session for both transfer and receive.

I am trying to test this with the example provided in the nRF5 SDK 15.3 by using this function:

    -  nrf_drv_spi_transfer(&spi, m_tx_buf, m_length, m_rx_buf, m_length);

My problem is that:

    -  I cannot insert a delay between the bytes when using the nrf_drv_spi_tranfer() for multiple byte transfers

    -  If i use separate calls of the nrf_drv_spi_transfer() for each byte, then the CS pin is not held low.

Is there any way I can use this driver to send multiple bytes with a fixed delay between them, without the CS pin going high during the session?

Thank you for reading

Br. Casper

No Data
  • Update:

    I have found out that I did not wait long enough for VCAP1 to reach a stable value above 1.1V. This takes approx. 2.5 seconds in my setup.

    With this fixed I now have some communication. But I am not getting expected values consistently. Here are some oscilloscope pictures.

    YELLOW = MISO (DOUT on ADS1298R)

    TEAL       = SCLK

    PINK        = /CS

    BLUE      = MOSI (DIN on ADS1298R)

    I think the problem is synchronization related. The way that MISO is left high, almost as if the ADS1298R is expecting more SCLK pulses to finish what it was writing.

    HOWEVER, I have by coincidence found a setting where I get expected values on every second transfer for my read. Here I read the
    ID register and CONFIG1 register as 0xD2 and 0x06 as expected.

    But the initial 1's on the first byte of the SDATAC command are not expected.

    Here is a scope picture of every second attempt to read the registers:

    Has anyone experienced anything similar?

    Thanks for reading,

    Br. Casper