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

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

Parents
  • The way I interpret the following text from the datasheet:

    9.5.2.9 Sending Multibyte Commands
    The ADS129x serial interface decodes commands in bytes, and requires 4 tCLK periods to decode and execute.
    Therefore, when sending multibyte commands, a 4 tCLK period must separate the end of one byte (or opcode)
    and the next.
    For example, if CLK is 2.048 MHz, then tSDECODE (4 × tCLK) is 1.96 μs. When SCLK is 16 MHz, the maximum
    transfer speed for one byte is 500 ns. This byte transfer time does not meet the tSDECODE specification; therefore,
    a delay must be inserted so that the end of the second byte arrives 1.46 μs later. However, if SCLK is 4 MHz,
    one byte is transferred in 2 μs. Because this transfer time exceeds the tSDECODE specification, the processor can
    send subsequent bytes without delay. In the second scenario, the serial port can be programmed to use multiplebyte
    transfers instead of the single-byte transfers required to meet the timing of the first scenario .

    Is that the delay must be a minimum of 4 * tCLK

    I have tried looking at the other posts, and haven't had much luck with it I'm afraid. They don't seem to be concerned with adding a fixed delay in between  bytes.

    I have also tried managing the CS pin manually, but I seems that as soon as the SPI driver has been initialized, that pin is not affected by using nrf_gpio_pin_set(uint32_t pin_number) or nrf_gpio_pin_clear(uint32_t pin_number)

    Has anyone ever had similar issues?

Reply
  • The way I interpret the following text from the datasheet:

    9.5.2.9 Sending Multibyte Commands
    The ADS129x serial interface decodes commands in bytes, and requires 4 tCLK periods to decode and execute.
    Therefore, when sending multibyte commands, a 4 tCLK period must separate the end of one byte (or opcode)
    and the next.
    For example, if CLK is 2.048 MHz, then tSDECODE (4 × tCLK) is 1.96 μs. When SCLK is 16 MHz, the maximum
    transfer speed for one byte is 500 ns. This byte transfer time does not meet the tSDECODE specification; therefore,
    a delay must be inserted so that the end of the second byte arrives 1.46 μs later. However, if SCLK is 4 MHz,
    one byte is transferred in 2 μs. Because this transfer time exceeds the tSDECODE specification, the processor can
    send subsequent bytes without delay. In the second scenario, the serial port can be programmed to use multiplebyte
    transfers instead of the single-byte transfers required to meet the timing of the first scenario .

    Is that the delay must be a minimum of 4 * tCLK

    I have tried looking at the other posts, and haven't had much luck with it I'm afraid. They don't seem to be concerned with adding a fixed delay in between  bytes.

    I have also tried managing the CS pin manually, but I seems that as soon as the SPI driver has been initialized, that pin is not affected by using nrf_gpio_pin_set(uint32_t pin_number) or nrf_gpio_pin_clear(uint32_t pin_number)

    Has anyone ever had similar issues?

Children
Related