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.
We have a new board designed off the reference. I followed the previous threads and the startup on PG 62. DRDY is clocking on startup, POWERDN and RESET are HIGH, VCAP is >1.1v . Sending a SDATAC and attemption to read the ID register 00. Three byte transfers are sent in SPI mode 1 with CS held low. MISO returns "random" data until consistently returning zeros. This data appears to be 4-24bit values (possibly the last analog sample) before DRDY goes HIGH when zero values are returned.
I'm stumped.
Here's the schematic
This is the SDATAC, First wide view showing DRDY pulsing,
Narrow view showing 8bit SDATAC command with miso clocking garbage back:
ID request, wide view of three clock transfers <CMD><NREG><Dummy>
first byte out, garbage clocked in
Second byte:
Dummy byte: (expecting data returned....), got garbage
We are using this chip at 1.8v dvdd -vs- the eval board at 3.3v dvdd. SPI is mode 1.
This is attached to an ARM with a PL022 SPI engine. I am currently using library calls for the transfer, but I can manipulate the registers directly if needed.
The DRDY signal pulses at the Spec frequency on "power-up", and observed before the reset is toggled through a GPIO pin. SDATAC is sent seconds later.
Hi Alex,
I am working with David Tyree on our ADS1299-4 SPI issue. We have VCAP1 tied to -2.5v through a 100uf cap. When I read the voltage across the cap I get +1.208 volts. Is -2.5v the correct reference point for my meter gnd or should I tie my meter gnd to chip gnd?
SDATAC BE wide:
SDATAC BE narrow:
ID BE Wide:
ID BE B1:
ID BE B2:
ID BE B3
Here's a reproduction of the last with the bit order changed. I understand what the spec says the transfers are, but in the absence of data, I've pretty much tried all the permutations. This is MSB first, SPI1.
The library in use is part of a proprietary SDK for the arm we are using, not a very vetted os, but "trustworthy" with single byte transfers, I'll have to write a lower level replacement to handle 16 bit transfers or better byte to byte transfer timings if needed.
Sorry, the last data set was from the wrong file, my board was being converted to 3.3v operation.
This morning I got to test the board and it works at 3.3 volts with the test read. Reg0 returns 0x3c and reg1 returns 0x96.
We'll try again with 1.8v, but can live with 3.3v.