Problem using the nRF52840 to interface an ADS1298 via SPI

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Fri, 18 Nov 2022 08:17:28 GMT

Hi ChKOR,

It has been a while since I worked on this, but I remember supplying the ADS1298-evalkit on the connector on the bottom with 3.0V (VDD) and GND from the nRF52840.

To do this, I looked up the schematics on Google for the ADS1298-evakit to see how it was being powered from the the Power-Board it was connected to when using the TI-evaluation software.

Br. Casper

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

ChKOR — Sun, 30 Oct 2022 07:17:37 GMT

I have solved my issue. But just for curiosity, I'd like to know how you powered up the ads eval board using nrf52840.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

ChKOR — Sat, 29 Oct 2022 09:53:39 GMT

Hi Casper, I'm currently developing nrf52840 spi communication with ads1198 as a newbie. But, There are so many things I cant solve... firstly how can nrf52840 dk power the ads1198 board? since the board is to be powered by MMb0 DSP board, how did you apply single VDD 3.0V power from nrf52840 to ads board?, so I made my own PCB for ads1198. and I tried to wake up ads1198. But I cant read ID from ADS1198. As I know, DRDY pin should begin pulsing after power up, but there is no response... even though I set START pin pull up, there is no response. Can you help me? or may I get your code for startup ads board?

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Tue, 18 Jun 2019 07:59:23 GMT

The problem with the ADS1298R evaluation board only answering to a specific sequence of commands, and not consistently has been solved!

It was a problem with the supply of the AVDD voltage only being supplied for periods of two seconds. This was, embarrassingly, overlooked by me when measuring the voltage supplies earlier in debugging.

Here is a scope snapshot of the board answering as expected on every RREG opcode.

Thank you all very much for your help, it is certainly appreciated!

Br. Casper

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Tue, 18 Jun 2019 07:54:26 GMT

Yes, it is unclear on the picture. It was only meant to show that the MISO signal was changing with no change in SCLK.

The problem is not noise, but improper supply of the AVDD voltage on the ADS1298R evaluation board. The voltage was high in two second periods and then low for two seconds, while the DVDD voltage and 3.3VCC being high all the time.
This was overlooked by my mistake when measuring. Embarrassing. Impressive that the board was able to communicate at all! This was probably also something that threw me off. It was only something I noticed when I did large zoom-out on the scope, and then I decided to look into the power supply again.

It is now functioning as expected, returning the correct values on every RREG opcode:

Thank you very much for your insight and help, it has been amazing!

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

hmolesworth — Mon, 17 Jun 2019 15:40:46 GMT

The noise very much depends on grounding, and whether the scope probe for a signal is locally grounded very close to the signal source (when probing source) or arrival point (when probing destination on the other board). The probe ground has to be moved each time with the probe, and be connected direct to the ground of the device being probed (not easy unless the board was laid out to accommodate this).

I am unclear as to what code the last traces are transmitting (MOSI) and receiving (MISO), as it doesn't look like the original request for device type (0x20, 0x01). Can you zoom in on each byte and the responses? I have never had an issue with noise on these parts; how long are the connections between the boards?

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

awneil — Mon, 17 Jun 2019 09:38:56 GMT

[quote userid="13562" url="~/f/nordic-q-a/48513/problem-using-the-nrf52840-to-interface-an-ads1298-via-spi/193116"]I suggest you ask TI and their community.[/quote]

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

haakonsh — Mon, 17 Jun 2019 09:35:22 GMT

I suggest you ask TI and their community. There might be something that we're missing in how you interface with this device, that they can easily answer.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Mon, 17 Jun 2019 09:09:39 GMT

Hi hmolesworth,

Thank you for replying!

Yes, I am using MSB first and SPI_MODE_1 (CPOL = 0 and CHPA = 1).

I tried using the enhanced drive setting you suggested, but sadly, it does not change the behavior.

I have also tried using up to a 120Ohm resistor in series with the SCLK pin, added as close as possible to the source.

I have taken further snapshots with the oscilloscope:

YELLOW: MISO

TEAL: SCLK

BLUE: MOSI

PINK: Not connected

The first picture is without the 120R in series with SCLK. At first glance it seems as if noise on SCLK triggers a response from the ADS1298R. The noise on the SCLK pin (teal) on the first snapshot is significantly reduced by the 120R resistor.

I then added the 120R to the SCLK pin. Then I waited until I noticed an unexpected output from the ADS1298R on the MISO pin and took a snapshot again. The changes in MISO and SCLK line up here.

(EDIT: Second snapshot was uploaded twice, and was changed to correct zoomed in snapshot).

BUT, when I zoomed in as on the third snapshot it looks more like the noise on MISO, (Yellow) is not induced by the SCLK pin (Teal).

I think this, because the level-change on MISO (Yellow) is not being triggered by the peak voltage of the noise on the SCLK (Teal), but was already changing earlier than the peak.

I do not think that it is a SCLK pin specific problem with the noise, but I do suspect that noise could be the issue. Does anyone have any further suggestions to how I should proceed looking for the issue here?

Br. Casper

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

hmolesworth — Fri, 14 Jun 2019 14:41:37 GMT

Are you using SPI mode 1 and MSB first? The 'scope pictures are a little unclear, maybe displace the waveforms slightly from each other (vertically) so they are easier to read. This setup works:

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    ret_code_t err_code;

    spi_config.ss_pin    = ADS_CS_PIN;
    spi_config.miso_pin  = ADS_MISO_PIN;
    spi_config.mosi_pin  = ADS_MOSI_PIN;
    spi_config.sck_pin   = ADS_SCK_PIN;
    spi_config.frequency = NRF_DRV_SPI_FREQ_500K;  // Ensure less than 4 clk cycles for ADS1292
    spi_config.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
    spi_config.mode      = NRF_DRV_SPI_MODE_1;
    APP_ERROR_CHECK(nrf_drv_spi_init(&mAfeSpiInstance, &spi_config, afe_spi_event_handler, NULL));

However as you are going off-board with the signals, I would suggest start with enhanced drive on SCK, MOSI and CS. The traces above may look clean, but fast jitter on the edges are not visible at this 'scope resolution, and edge jitter can corrupt expected transactions, notably on SCK. Add this after spi init:

   // High power output pins to ensure clean edge transitions off-board
   nrf_gpio_cfg(ADS_SCK_PIN
                NRF_GPIO_PIN_DIR_OUTPUT,
                NRF_GPIO_PIN_INPUT_DISCONNECT,
                NRF_GPIO_PIN_NOPULL,
                NRF_GPIO_PIN_H0H1,       // Test with High Drive high and low level
                NRF_GPIO_PIN_NOSENSE);

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Fri, 14 Jun 2019 14:02:30 GMT

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

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Fri, 14 Jun 2019 13:53:23 GMT

Thank you for reading again, it is really appreciated!

1. I have now monitored the power supply upon startup and noticed that the VCAP1 voltage takes around 2.5 seconds to stabilize at a value above 1.1V. The charge curve looks like a normal RC charge. I made the mistake of not waiting long enough, assuming it wouldn't take that long. As you will see in a minute I have made contact with the ADS1298R, but I still have problems getting the expected values.

2. I am sending the SDATAC command before attempting to read with the RREG command.

3. Yes I have made sure that the clock signal is applied when it is supposed to.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

haakonsh — Fri, 14 Jun 2019 12:59:29 GMT

I suggest you scope the ADS1298's power supply line for any fluctuations or noise during startup.
From 9.5.2:
NDS Enable Read Data Continuous mode. RDATAC 0001 0000 (10h) — This mode is the default mode at power up.(1)

(1) When in RDATAC mode, the RREG command is ignored.

From 9.5.2.10:
When the device is in read data continuous mode (RDATAC), it is necessary to issue a SDATAC command before a RREG command can be issued.
From 11.1:
Allow time for the supply voltages to reach their final value, and then begin supplying the master clock signal to the CLK pin. Wait for time tPOR, then transmit a reset pulse using either the RESET pin or RESET command to initialize the digital portion of the chip. Issue the reset after tPOR or after the VCAP1 voltage is greater than 1.1 V, whichever time is longer.

Have you made sure that the clock signal is applied exactly when it's supposed to?

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Fri, 14 Jun 2019 11:14:56 GMT

Hi haakonsh,

Thank you for replying!

I am using the Internal Clock of 2.048MHz as recommended in the datasheet because this application will be powered by battery, and therefore has to be low power.

I am using Figure 93. Initial Flow at Power Up in section 10.1.1 as a guide for my Power-Up sequence.

All of the I/O lines have been monitored with an oscilloscope I have confirmed that they all start out LOW at power up, and then I turn them on in the sequence described in 10.1.1 and 11.1 of the datasheet for the ADS1298.

I am using the Development kit for the ADS1298, but I am not powering it with the MMBO board, but with the nRF82840 microcontroller. Single supply 3.0V.

Still no luck though..

Again, thank you very much for replying!

Br. Casper

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

haakonsh — Fri, 14 Jun 2019 08:23:56 GMT

Are you using an external clock?
In that case, it seems you need to supply a clock signal on the SCK pin before resetting the device.

There's a fairly detailed start-up sequence description in 10.1.1 Setting the Device for Basic Data Capture.

From 11.1; "After releasing the RESET pin, program the configuration registers".
- It seems you must program the configuration registers before you can read the DEVICE_ID register.

I suggest you scope all I/O lines and all supply pins and compare their states with the datasheet's start-up and communication sequences.

Are you using the ADS1298 on a custom board or it's dev kit?
- If you're using a custom board I suggest you submit your schematics and design files for review at TI.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Fri, 14 Jun 2019 07:23:50 GMT

Hi hmolesworth,

Thank you for taking your time to reply again!

I am aware that the ADS1298 is starting in RDATAC mode by default, and I am sending the SDATAC command prior to attempting to send the RREG opcode to read the ID-register. At the moment I am running the SPI at a low 500kHz.

According to TI's FAQ for the ADS129x devices: https://e2e.ti.com/support/data-converters/f/73/t/772058

it could be a problem with my Power-Up sequencing.

I am supplying the ADS1298 Development board directly from my nRF82840 development board via 3.0V single supply. This is configured so that both the analog voltage (AVDD) and the digital voltage (DVDD) is supplied.

According to the datasheet, the correct Power-Up sequence is as follows: (I am using the internal 2.048MHz clock for now)

To try and adhere to these specifications I have made a simple test code:

    // Powerup Sequence:
    nrf_gpio_pin_set(ADS1298_PWDN_PIN);     // 1) Powerup the ADS1298
    nrf_gpio_pin_set(ADS1298_RESET_PIN);    // 2) Set the RESET pin high
    nrf_delay_ms(100);                      // 3) Wait after powerup until reset
    nrf_gpio_pin_clear(ADS1298_RESET_PIN);  // 4) Set RESET pin low for a minimum of 2 * tCLK
    nrf_delay_ms(10);                       // 5) wait > 2 * tCLK
    nrf_gpio_pin_set(ADS1298_RESET_PIN);    // 6) Setting RESET pin high now enables the digital portion of the ADS1298
    nrf_delay_ms(100);                      // 7) Wait > 18 * tCLK Before starting to use the device

But perhaps I am stilling missing something. Could it be that I actually have to toggle the power supply completely to the board, and using the /PWDN pin is not enough?

Thank you again for reading!

Br. Casper

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

hmolesworth — Thu, 13 Jun 2019 15:04:11 GMT

You may be overlooking the following; I think all family members start up in the read-continuous mode:

"If the device is in RDATAC mode, an SDATAC command must be issued before any other commands can be sent to the device."

    AdsReset();                      // Reset ADS - not necessary if using power-on reset
    AdsSendCmd(ADS_CMND_SDATAC);     // Stop continuous mode
    // Turn on internal reference and allow time to settle
    AdsWriteReg(ADS1x9x_REG_CONFIG2, 0xA0);
now read id ..

Otherwise the command looks correct:

/****************************************************************/
/* ADS1x9x COMMAND DESCRIPTION and definitions */
/****************************************************************/
typedef enum {
  // System Commands
  ADS_CMND_WAKEUP    = 0x02,   // Wake-up from standby mode
  ADS_CMND_STANDBY   = 0x04,   // Enter standby mode
  ADS_CMND_RESET_CMD = 0x06,   // Reset the device registers
  ADS_CMND_START     = 0x08,   // Start/restart (synchronize) conversions
  ADS_CMND_STOP      = 0x0A,   // Stop conversion
  ADS_CMND_OFFSETCAL = 0x1A,   // Channel offset calibration - needs to be sent every time there is a change to the PGA gain
  // Data Read Commands
  ADS_CMND_RDATAC    = 0x10,   // Enable Read Data Continuous mode.
                               // - This mode is the default mode at power-up.
  ADS_CMND_SDATAC    = 0x11,   // Stop Read Data Continuously mode
  ADS_CMND_RDATA     = 0x12,   // Read data by command; supports multiple read back.
  // Register Read/Write Commands
  ADS_CMND_RREG      = 0x20,   // Read n nnnn registers starting at address r rrrr
                               //  - first byte 001r rrrr (2xh)(2) - second byte 000n nnnn(2)
  ADS_CMND_WREG      = 0x40    // Write n nnnn registers starting at address r rrrr
                               //  - first byte 010r rrrr (2xh)(2) - second byte 000n nnnn(2)
} ADS1x9xCommand_t;

I should add that if you are going off-board to the ADS development board it might be necessary to boost the drive to SCK, CS and MOSI pins from S0S1 to H0H1 after the SPI has been initialised; not usually necessary at lower SCK speeds however..

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Thu, 13 Jun 2019 10:48:40 GMT

Thank you very much for the insight!

I can now see on my oscilloscope that I can send two bytes with a delay in between, and also send SCLK signal afterwards to receive the answer.

I have not yet been successful in getting an answer from the ADS1298, but at least now I know that I am adhering to its datasheet requirements.

I have set the Jumpers on the ADS1298 EVM (Evaluation board) to use the internal 2.048MHz clock and I have set the SPI frequency

to 500kHz.

The SCLK signal is provided in bursts by the nRF52840 microcontroller as specified in the datasheet for the ADS1298, and aligns perfectly with the MOSI signal from the nRF52840 microcontroller.

Since I am not getting an answer, does anyone know what I might have overlooked?

I am still trying to send the RREG opcode and the read the ID Register value just like the picture in the original post.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

hmolesworth — Wed, 12 Jun 2019 19:29:35 GMT

You don't necessarily need to add a delay, just to conform to the AFE requirements.

// Sending Multi-Byte Commands
// The ADS1291, ADS1292, and ADS1292R serial interface decodes commands in bytes and requires 4 tCLK cycles
// to decode and execute. Therefore, when sending multi-byte commands, a 4 tCLK period must separate the end of
// one byte (or opcode) and the next.
// Assume CLK is 512 kHz, then tSDECODE (4 tCLK) is 7.8125 us. When SCLK is 16 MHz, one byte can be
// transferred in 500 ns. This byte-transfer time does not meet the tSDECODE specification; therefore, a delay must be
// inserted so the end of the second byte arrives 7.3125 us later. If SCLK is 1 MHz, one byte is transferred in 8 us.
// Because this transfer time exceeds the tSDECODE specification, the processor can send subsequent bytes without
// delay. In this later scenario, the serial port can be programmed to move from single-byte transfer per cycle to
// multiple bytes.

    spi_config.frequency = NRF_DRV_SPI_FREQ_500K;  // Ensure less than 4 clk cycles for ADS1292/8

Since transfers are only a few bytes, typically the slower clock speed is not an issue. Other issues tend to be more problematic; as an example the internal AFE clock has drift with respect to external timing sources, such as the crystal-clocks used further down the chain in ECG analytics. This has to be handled without introducing artifacts in the ECG stream.

Using an external crystal clock is only one option to minimise this, but as a tip note that without a clock the ADS129x AFE is unavailable via SPI. So if the clock select pin is set to external clock mode the SPI interface will simply not work until the external clock is present. A classic mistake is to use the AFE output pin to select the clock source, which if defaulted to external (via a pull-up) means first an external clock has to be supplied to allow SPI transfers, then the pin programmed low for internal clock via SPI, then the external clock can be removed again.

To manually control the CS pin, set the pin to not used; this is the nrf example, but may differ slightly depending on which library versions you are using

    spi_config.ss_pin = NRF_DRV_SPI_PIN_NOT_USED

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

awneil — Wed, 12 Jun 2019 15:43:28 GMT

[quote userid="80129" url="~/f/nordic-q-a/48513/problem-using-the-nrf52840-to-interface-an-ads1298-via-spi/192464"]The way I interpret the following text from the datasheet[/quote]

It's not entirely clear, is it!

You'd have to clarify that with the manufacturer.

You might also ask them how they expect people to implement this - since it is not common that microcontroller SPI controllers let you insert arbitrary delays!

But, if it is just a minimum, then it should be easy.

[quote userid="80129" url="~/f/nordic-q-a/48513/problem-using-the-nrf52840-to-interface-an-ads1298-via-spi/192464"]as soon as the SPI driver has been initialized, that pin is not affected by using nrf_gpio_pin_set[/quote]

So use a different pin.

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

Casper Kronborg Pedersen — Wed, 12 Jun 2019 15:31:24 GMT

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?

RE: Problem using the nRF52840 to interface an ADS1298 via SPI

awneil — Wed, 12 Jun 2019 14:28:38 GMT

Does the delay have to be exactly 4 * tCLK ?

You could manage the CS pin "manually"

Look at the 'Related' posts linked to the right --->