This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS1298ECGFE-PDK: Problem reading data from channels 1 through 8

Part Number: ADS1298ECGFE-PDK
Other Parts Discussed in Thread: ADS1298, , ADS1198, ADS1292

Hi,

I have problems reading data from channels 1 through 8 and need some help to figure out why.

I run the first half of the test in chapter 10.1.1 of SBAS459K –JANUARY 2010–REVISED AUGUST 2015, where the inputs are shorted,
and I expect data to be around +/- 0, i.e. 0x00 0x00 0x0? and 0xFF 0xFF 0xF? width some variation in the least significant digit, like in the example below:
0xC0 0x00 0x00
0xFF 0xFF 0xFD
0x00 0x00 0x02
0xFF 0xFF 0xFD
0x00 0x00 0x03
0xFF 0xFF 0xFC
0x00 0x00 0x06
0xFF 0xFF 0xFF
0x00 0x00 0x01

Instead I get something like this:
0xC0, 0x0, 0x0                     // Seems ok to me.
0xDD, 0x64, 0x8E                // To big negative value when having a shorted input.
0x80, 0x0, 0x0                      // I did not expect values like "-0" and they seem a little bit to steady.
0x80, 0x0, 0x0
0xBF, 0x9F, 0xFB
0x80, 0x0, 0x0
0x80, 0x0, 0x0
0x80, 0x0, 0x0
0x80, 0x0, 0x0
Please see attached log file for more data.

The initial bits of the status data 0xC0 and then 0x00 0x00 seems ok but the rest of the data seems wrong to me.

The channels that have values like 0x80, 0x0, 0x0 seems odd to me also the two channel values of 0xDD, 0x64, 0x8E and 0xBF, 0x9F, 0xFB seems faulty.

Can you please confirm if I am right about the data not being ok, or otherwise why it is right?

Belov is a short description of my test setup.
brdgs
Jerker
This is how I configure the board from the firmware:
<debug> app: ads1298_drv.c(182) Reset of ADS1298 done. //
<debug> app: Start of Hello World
<debug> app: ads1298_drv.c(269) ADS_SDATAC.
<debug> app: ads1298_drv.c(284) WREG CONFIG1 0x86.
<debug> app: ads1298_drv.c(291) WREG CONFIG2 0x00.
<debug> app: ads1298_drv.c(255) WREG CHnSET 0x88 0x0 0x1 for all eight channels // Configure 0x81 - 0x88
<debug> app: ads1298_drv.c(300) ADS_START.
<debug> app: ads1298_drv.c(304) RDATAC.
<debug> app: ads1298_drv.c(308) ADS_SDATAC.
Please see the attached log file for more data.
I'm using a nRF52840-DK from Nordic which I connected to the ADS1298ECGFE-PDK via SPI as described below:
#define SPI_SCK_PIN 3   // Connected from P0.3 to J3:3
#define SPI_MOSI_PIN 4  // Connected from P0.4 to J3:11
#define SPI_MISO_PIN 28 // Connected from P0.28 to J3:13
#define SPI_SS_PIN 29   // Connected from P0.29 to J3:7
#define SPI_DRDY_PIN 30 // Connected from P0.30 to J3:15
#define ADS_RESET_PIN 31 // Connected from P0.30 to J3:8
J4:5 is connected to GND
J4:9 is connected to +3v3
J4:10 is connected to +5v0
The jumpers on ADS1298ECGFE-PDK are set this:
JP15 2-3, JP1 1-2, JP26 - JP33 1-2, JP5 NC, JP10 2-3, JP18 2-3,
JP19 1-2, JP4 1-2, JP2 1-2, JP20 2-3, JP21 2-3, JP22 2-3, JP23 1-2

ads1298.log

  • Hi Jerker,

    Welcome to the E2E forum. Thanks for using the ADS1298ECGFE-PDK for your evaluation.

    For input short testing, you should get around +/-500uV (offset error) of output on all the channels. The output you are getting (0x800000) which translates into an input voltage of -Vref which is incorrect for an input-short test.

    To isolate what is the issue, you can start by using the EVM with the GUI to make sure all settings of the EVM are correct before using the nRF52840-DK and your own software for data capture. There is a step by step debugging procedure in the ADS129x BIOFAQ to ensure the device and EVM is functioning properly. I listed the link below for your reference.

    https://e2e.ti.com/support/data-converters/f/73/p/775288/2868597#2868597

    I hope this will help with your debugging. 

    Thanks.

    -TC

  • Thanks for your advice TC.

    A collegue of mine have the motherboard and the EVM worked as expected when we connected it to the mother board.

    But when I reconnect it the EVM the nRF52840-DK it hangs on the DRDY pin.

    And here are the register settings:
    0x11
    0x81, 0x00, 0xA5
    0x82, 0x00, 0x12
    0x85 0x0 0x11
    0x86 0x0 0x11
    0x87 0x0 0x11
    0x88 0x0 0x11
    0x89 0x0 0x11
    0x8A 0x0 0x11
    0x8B 0x0 0x11
    0x8C 0x0 0x11
    0x08
    0x10
    0x11

    // Here the FW hangs on the DRDY pin.

    1. Do you have a recommendation which pins of the ADS1298 must be handled by the MCU?
    2. Is there anything I should change in the jumper settings?
    3. Also which register settings must be done, have I missed anything?

    Below is a detailed description of the configuration sofar.

    brdgs

    Jerker

    Right now I have connected the pins of the EVM like this:

    J4:5 - GND
    J4:9 - 3v3
    J4:10 - 5v0

    J3:1 - GND // START
    J3:3 - SPI_SCK_PIN
    J3:7 - SPI_SS_PIN
    J3:11 - SPI_MOSI_PIN
    J3:13 - SPI_MISO_PIN
    J3:15 - SPI_DRDY_PIN
    J3:8 - ADS_RESET_PIN

    After the session with the motherboard the Jumper are now set like this
    JP15 2-3 // Shield drive is open
    JP1 1-2   // RLD feedback
    JP17 ---  // Header not installed, ECG shield drive
    JP3 --     // Header not installed, External Vref buffer not connected
    JP25 --- // Header not installed, No external reference selected
    JP24 2-3 // DVDD supply = 3.3V
    JP18 2-3 // CLK connected to OSC1
    JP19 1-2 // OSC1 enabled
    JP2 1-2 // AVDD selected for bipolar supply operation selected (AVDD = +2.5V)
    JP20 2-3 // AVSS selected for bipolar supply operation (AVSS = -2.5V)
    JP4 1-2 // EVM +5V provided from J4 (power header)
    JP21 1-2 // CS connected to DSP via J3.1
    JP22 2-3 // START comes from J3.14 Please note: Since I write the START register from FW J3:14 is connect to GND.
    JP23 1-2 // CLKSEL set to 0 (ADS1198 uses Ext Master Clock (OSC1))
    And all jumper JP26a through JP33b are installed.

    The setting done by the FW are listed below:

    First the reset handling:
    nrf_gpio_pin_set(ADS_RESET_PIN);
    nrf_delay_ms(100);
    nrf_gpio_pin_clear(ADS_RESET_PIN);
    nrf_delay_ms(100);
    nrf_gpio_pin_set(ADS_RESET_PIN);
    nrf_delay_ms(2500);

    Then the configuration of the pins I control from the FW:
    spi_config.ss_pin = NRF_DRV_SPI_PIN_NOT_USED; // Manual control of the CS pin, set the Slave Select pin to not used.
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
    spi_config.frequency = NRF_DRV_SPI_FREQ_500K; // Ensure less than 4 clk cycles for ADS1292/8}
    spi_config.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
    spi_config.mode      = NRF_DRV_SPI_MODE_1;

  • Hi Jerker,

    Your EVM jumpers setting looks fine. Are you following the power-up sequence at power-up, as shown in Figure 93 in the datasheet? I'm not sure how to read the register settings that you posted above. Another test you can do is pull the START pin to HIGH after the power-up sequence and see if you get the DRDY signal on the oscilloscope.  

    Thanks.

    -TC

  • Thx for your replay TC.

    Good to hear that the Jumper settings looks ok.

    I connected J5:5 (!PWDN) to a gpio pin on the MCU so I can control it (JP5 is left open for that purpose).

    The START pin (J2:14) is permanently connected to 3v3.

    The CLK_SEL pin is set to 0 (JP23 1-2) as I'm using the external clock connected to OSC1.

    Here is the confinguration of the registers I use know. I changed it a bit since I found some deviation from the flow chart in figure 93.

    The byte in the middle for all the register writes (0x8x) are set 0x00 indicating that there is 1 byte that should be written in each register,
    9.5.2 SPI Command Definitions.

    0x11                       SDATAC - Stop Data Continues Mode
    0x81, 0x00, 0xA6   WREG CONFIG1 set to High Resolution, OSC1 enabled and Data Rate 110 Note: I assume here that the suggested 0x86 in figure 93 is if you use the internal clock setting.)
    0x82, 0x00, 0x00   WREG CONFIG2 set to Chopping frequency varies, Test signals are driven externally, Test Amplitude 1 × –(VREFP – VREFN) / 2400 V, Test freq Pulsed at fCLK / 2^21
    0x85 0x0 0x1         WREG CHnSET for channels 5 through  12. Set to Normal Operation, PGA Gain 6, Input Shorted
    0x86 0x0 0x1
    0x87 0x0 0x1
    0x88 0x0 0x1
    0x89 0x0 0x1
    0x8A 0x0 0x1
    0x8B 0x0 0x1
    0x8C 0x0 0x1
    0x08                     START - Start/Restart Conversions
    0x10                     RDATAC - Resume Data Continues Mode
    0x11                     SDATAC - Stop Data Continues Mode

    Here the code waits for DRDY but that never happens.

    I have checked with the scope on DRDY but I could not see DRDY going low then high.
    It was high all the time.

    brdgs

    Jerker

  • I measured the output from J3:13, SPI_OUT, and the signal is to weak to interpret.

    The red signal is measured on J3:11, SPI_IN and the blue signal is measured on J3:13, SPI_OUT.

    SPI_OUT is much to weak.

    Can the jumper setting on the EVM affect the SPI signals?

    What are the HW requirements for the SPI master?

    brdgs

    Jerker

  • Hi Jerker,

    Are you still connecting the MMB0 motherboard to the EVM when you are using your own nRF controller? You may want to isolate all the SPI and control signals that you are using from the MMB0 so there are no contentions between the two. Can you read all the register settings after the power-up sequence so we know all the device setup is correct?  

    Thanks.

    -TC

  • Hi TC,

    No the EVM is not connected to the MB, it is connected to the nRF development kit only.

    I finally got the reading of the device ID to work. I had to retry it once to get the numbers.
    The FW reads back 0x92 which I interpret as ok as I'm working with a 1298 device.

    When I read all 25 register I get the following result which was a bit unexpected.
    Why are register 0x0 and 0x1 set to 0x0 and the device ID placed in register 0x2?
    I'd expect it to be in register 0x0, It seems that all register have offset of +2!
    So I read 27 registers instead of 25 in hope of getting all the register settings.

    <debug> app: ads1298_drv.c(259) Register 0x0 = 0x0 <--- I expected ID to be here
    <debug> app: ads1298_drv.c(259) Register 0x1 = 0x0 <--- and Config 1 to be here.
    <debug> app: ads1298_drv.c(259) Register 0x2 = 0x92 ID
    <debug> app: ads1298_drv.c(259) Register 0x3 = 0x85 Config 1
    <debug> app: ads1298_drv.c(259) Register 0x4 = 0x0   Config 2
    <debug> app: ads1298_drv.c(259) Register 0x5 = 0x40 Config 3
    <debug> app: ads1298_drv.c(259) Register 0x6 = 0x0   VLED_OFF
    <debug> app: ads1298_drv.c(259) Register 0x7 = 0x1  CHN1SET
    <debug> app: ads1298_drv.c(259) Register 0x8 = 0x1  CHN2SET
    <debug> app: ads1298_drv.c(259) Register 0x9 = 0x1  CHN3SET
    <debug> app: ads1298_drv.c(259) Register 0xA = 0x1  CHN4SET
    <debug> app: ads1298_drv.c(259) Register 0xB = 0x1  CHN5SET
    <debug> app: ads1298_drv.c(259) Register 0xC = 0x1  CHN6SET
    <debug> app: ads1298_drv.c(259) Register 0xD = 0x1  CHN7SET
    <debug> app: ads1298_drv.c(259) Register 0xE = 0x1  CHN8SET
    <debug> app: ads1298_drv.c(259) Register 0xF = 0x0   RLD_SENSP
    <debug> app: ads1298_drv.c(259) Register 0x10 = 0x0 RLD_SENSN
    <debug> app: ads1298_drv.c(259) Register 0x11 = 0x0 LOFF_SENSP
    <debug> app: ads1298_drv.c(259) Register 0x12 = 0x0 LOFF_SENSN
    <debug> app: ads1298_drv.c(259) Register 0x13 = 0x0 LOFF_FLIP
    <debug> app: ads1298_drv.c(259) Register 0x14 = 0x0 LOFF_STATP
    <debug> app: ads1298_drv.c(259) Register 0x15 = 0x0 LOFF_STATN
    <debug> app: ads1298_drv.c(259) Register 0x16 = 0xF GPIO
    <debug> app: ads1298_drv.c(259) Register 0x17 = 0x0 PACE
    <debug> app: ads1298_drv.c(259) Register 0x18 = 0x0 RESP
    <debug> app: ads1298_drv.c(259) Register 0x19 = 0x0 CONFIG4
    <debug> app: ads1298_drv.c(259) Register 0x1A = 0x0 WCT1
    <debug> app: ads1298_drv.c(259) Register 0x1B = 0x0 WCT2

    The noise reading seems awkward too, I expect it to be much lower values.
    The status bytes start with 0xC0 and that is correct I think.

    <debug> app: 0xC0, 0x0, 0x0
    <debug> app: 0x24, 0xA4, 0x63
    <debug> app: 0x26, 0x4, 0x1
    <debug> app: 0xC, 0xA3, 0xB7
    <debug> app: 0x28, 0x2D, 0x51
    <debug> app: 0x4, 0x5D, 0xE8
    <debug> app: 0x4, 0x9B, 0xB8
    <debug> app: 0xF, 0xF3, 0xD5
    <debug> app: 0x18, 0xB8, 0xBE

    So why do I get the offset of 2 when I read the register values
    and why are the read values from the ADC channels like they are?
    Is there something in my register settings that are faulty apart form the offset?

    brdgs
    Jerker

  • Hi Jerker,

    Is your FW SPI also captures the DOUT data when you are sending the first 2 opcodes using the RREG command? For debugging purposes, you can probe the SPI signals with an oscilloscope to make sure what you send from your FW is correct. For the ADC channels data, I would suggest that you use the internal test signal as a starting point to make sure all the SPI functionality is correct and you can capture the correct internal test signal waveform as shown in Figure 31 of the EVM user guide.

    Thanks.

    -TC

  • Thx for your answer TC!

    I can now read the ADC output from Data Out and are working on getting a good enough signal. I'll start a new tread about that if need.

    As to what solved the problem is that I had problem with the startup sequence. After revisiting the timing of when to do the reset solved the problem.

    TCT said:
    Is your FW SPI also captures the DOUT data when you are sending the first 2 opcodes using the RREG command? For debugging purposes, you can probe the SPI signals with an oscilloscope to make sure what you send from your FW is correct.

    I'll will invesitgate this and try find the root cause of the problem. If need I start a new thread regarding this problem.

    brdgs

    Jerker