Help with interfacing STM32 with ADS1256 ADC

[broughley488]

Hi everyone,
I'm trying to build a DC load as a project and I'm running into trouble when it comes to getting the STM32 G431RBT to talk to my ADS1256 ADC. I'm trying to write the drivers myself, utilizing the HAL, just to get some practice with embedded programming.
I have attached a github repo I have created for better viewing of the code, and it also contains screenshots of my oscilloscope and logic analyser.
I have a function (ADS1256_RegDump), which basically sends the RREG command (RREG, Start at address 0, read 11 registers), and then dumps the resultant data into an array (also screenshotted and in the repo). The reset values for the registers are noted in the datasheet, page 30, table 23. As you can see, the data I am receiving is actually close to the reset values, but some are just slightly off. I am aware of the T6 delay that needs to be observed and you can see the communication in the repo. Also when I read the data (CH0) I get some sort of insane reading that is not correct. I'm thinking it's some sort of issue with SPI, but I've tried all the modes (CPHA 1/2, CPOL) and the results get no better or worse.
I was wondering if anyone has experience with this IC, and can help me out? better still, if you have one available to you and can quickly set it up and send me readings from a logic analyser or a scope if you have the time, I would be incredibly grateful.
As you can see, on my scope screenshots, CH3 (MISO) has some funky things going on at the end of some of the packets, but not all, I'm not sure why this is? I can spot some crosstalk between the lines as I am currently using the nucleo dev board and a ADS dev board connected with some short jumpers, but the crosstalk doesn't look too bad (<.5Vpp).

Scope: CH1: SCK, CH2: MOSI, CH3: MISO, CH4:CS

https://github.com/BRoughley488/STM32-DC-Load
https://www.ti.com/lit/ds/symlink/ads1256.pdf

Any help would be appreciated (Settings listed below).
(SPI 3 is used for the ADS1256, SPI2 is for a shift register / 7 seg display)
Frame: Motorola, 8 bits, MSB First
Prescaler: 64 (2.65625MBits/s) I know this is a bit over the datasheet, however the results do not change at 1.328125MBits/s which I usually run it at.
CPOL:Low
CPHA: 2 Edge
CRC: disabled, NSS: Software

 
Thanks in advance

[pcprogrammer]

I have not looked at your repository, but what anomaly do you think you have in the channel data.

You are working with a 24bit ADC which will be very sensitive for noise, so wildly varying measurement data might be due to ground issues or supply noise issues and not per se faults in the SPI connection.

Best to provide more information, like for instance a picture of your setup, a schematic, etc.

[broughley488]

The data is miles off, like orders of magnitude off, after conversion to a float. I have considered the possibility that the maths for the conversion is off, however when I run the register dump function the register values (hex) is off, but only a bit if that makes sense? If you look at the screenshot for the logic analyser and compare it to the reset values in the register table you will see what I mean.
I will post a picture of my setup tomorrow, however it's nothing special, just the nucleo board connected to a generic ADS dev board via short jumper wires.

[Unixon]

As you can see, on my scope screenshots, CH3 (MISO) has some funky things going on at the end of some of the packets, but not all, I'm not sure why this is?

Looks like ADC shuts the line off to Hi-Z at the end of transaction and it just floats (charges through a weak pull-up).
Maybe it worth loading the line with a pull-down resistor of a reasonable value to dump all the noise to GND.
Also I would add some serial resistance to SPI line at the transmitter end to reduce HF crosstalk and reflections, however, this will limit the bandwidth.

[Scrts]

What if you run SPI even slower? Like 16 times slower than now? This would most likely eliminate interface hypothesis.

[jheissjr]

Send a RREG command followed by reading registers 0x00 to 0x03. Send it after the ADS1256 is first powered on. Provide the logic analyzer capture starting from CS falling low ending at CS rising high.

[ace1903]

from void ADS1256_Read(ADS1256* dev, int32_t* pData){
int32_t val;
uint8_t receive[3];
val = (receive[0] << 16) | (receive[1] << | receive[2];

I would prefer explicite casting to uint32 of receive before shifting.
Quick test with uint32 receive [3]; might show something interesting?

[pcprogrammer]

As you can see, on my scope screenshots, CH3 (MISO) has some funky things going on at the end of some of the packets, but not all, I'm not sure why this is?

Looks like ADC shuts the line off to Hi-Z at the end of transaction and it just floats (charges through a weak pull-up).
Maybe it worth loading the line with a pull-down resistor of a reasonable value to dump all the noise to GND.
Also I would add some serial resistance to SPI line at the transmitter end to reduce HF crosstalk and reflections, however, this will limit the bandwidth.

The OP did not have a trace with the CS line, and my guess is that this Hi-Z status of the MISO line is activated when the CS line goes high. No need for a extra pull up or down resistor, as this only happens outside of any communication.

Adding small series resistors in all the SPI lines, except CS, can improve signal integrity, but with a low clock frequency not a necessity.

It would help if the OP made a list of the read register values and the expect ones, instead of us having to look through the datasheet and the logic analyzer captures.

[Unixon]

Does your firmware read exactly the same values from SPI that LA is showing?
What data will your setup read if you attach a potentiometer to ADC input and make three measurements: low end, middle, high end of scale?
Obviously, high end must be connected to a voltage source equal to ADC's Vref, adding another divider with a fixed value resistor will do the job.

(Vcc)---[R1]---(Vref)---<high end>-[R2:pot]-<low end>---(GND)
                                   [R2:pot]-<middle>---(ADC IN)

[broughley488]

As requested, along with the resultant live register in cubeIDE, which matches to what the logic analyser is saying.

[broughley488]

As you can see, on my scope screenshots, CH3 (MISO) has some funky things going on at the end of some of the packets, but not all, I'm not sure why this is?

Looks like ADC shuts the line off to Hi-Z at the end of transaction and it just floats (charges through a weak pull-up).
Maybe it worth loading the line with a pull-down resistor of a reasonable value to dump all the noise to GND.
Also I would add some serial resistance to SPI line at the transmitter end to reduce HF crosstalk and reflections, however, this will limit the bandwidth.

The OP did not have a trace with the CS line, and my guess is that this Hi-Z status of the MISO line is activated when the CS line goes high. No need for a extra pull up or down resistor, as this only happens outside of any communication.

Adding small series resistors in all the SPI lines, except CS, can improve signal integrity, but with a low clock frequency not a necessity.

It would help if the OP made a list of the read register values and the expect ones, instead of us having to look through the datasheet and the logic analyzer captures.

Hi, sorry for not including that info, reg data array is included in the top post, I forgot to put in the reset values for the registers.

[Reset values]  x1, 01, 20 F0, E0
[Received]       31, 01, 20, F0, E1

As you can see some of them are correct, which is pointing me towards an SPI config issue, however I have tried all the modes and the results just get worse, I'm fairly confident I am on the correct settings (CPOL = LOW, CPHA = 2 Edge, 1.328125Mb/s)

Thanks

[jheissjr]

The data on the MISO pin looks correct. What is the function of the bit in 0xE1 that does not match?

[broughley488]

The data on the MISO pin looks correct. What is the function of the bit in 0xE1 that does not match?

5th register is the GPIO Control register. I have just re initialized the device and I am now reading 30, 01, 20, f0, e1, so this seems inconsistent? Could that be some sort of timing issue> I have double checked the delays needed with the timing diagram and I am observing all the necessary requirements as far as I can tell.

[broughley488]

UPDATE:
So, as a little bit of a last ditch attempt, I just Just passed the float (converted variable) into my existing 7 segment display and it works? I pass 1V into it and get 1V on the display. I asked AI (I know, I know) and it is something to do with the type casing in cubeIDE? If anyone else can explain it I would appreciate it, as I do doubt AI for the most part. The question is, why are the default set up registers incorrect, when it is passing the correct data to the STM32?

[pcprogrammer]

[Reset values]  x1, 01, 20 F0, E0
[Received]       31, 01, 20, F0, E1

As you can see some of them are correct, which is pointing me towards an SPI config issue, however I have tried all the modes and the results just get worse, I'm fairly confident I am on the correct settings (CPOL = LOW, CPHA = 2 Edge, 1.328125Mb/s)

I think they are all correct depending on two things.

The first byte (x1 read as 31) holds some pre programmed read only ID in the upper nibble. That is why it is specified as x1h after reset. The x can be any value, but should return consistently the same from your chip. The 1 bit in the lower nibble is the status of the Data Ready signal, and will become zero when new data is ready.

The last byte is for the GPIO the chip offers, where the lower nibble is the IO data. It is a bit odd that with the lowest bit set as an output it reads a one there. But the clock out option is enabled and maybe that causes the 1 to appear.

Does this last byte change when reading multiple times?

Based on the given I don't think you have a SPI issue.

[dietert1]

I have done like 10 devices with STM32 driving ADS1256 and ADS1263.
Those ADS1256 modules available from amazon can simplify the job.  The module provides a voltage regulator, the reference voltage with opamp buffer, the crystal and a simple RC low pass filter for each input pin. It also has the recommended damping resistors for the digital interface signals. I wired all digital signals to the MCU, including reset and data ready.
One common issue with SPI is clock phase and polarity that one needs to configure correctly on the MCU. I used CubeMX to generate configuration code and compared the SPI scope trace with the images in the ADS1256 datasheet. There is no way around this.
First step is to configure the ADC for regular conversion e.g. at 50 or 60 Hz. One selects a negative input and a positive input. One way to test is connect the negative input to the reference voltage and the positive input to the voltage of the power LED. Then one should enable the input buffer and select the proper PGA gain. Then the ADC outputs a conversion ready signal regularly and one can use that as an interrupt signal for the MCU to read the result.
Conversion noise depends on PGA setting and on integration time. As far as i remember the ADS1263 worked well as a nanovoltmeter/nullmeter. Gain stability can be like 5 ppm or so, depending on the reference voltage source.
Once it works with the expected results one can start multiplexing, i.e. take measurements on different interleaved input channels. One needs to step the channel multiplexer before reading the current result.

Regards, Dieter

[jheissjr]

I agree with pcprogrammer and the four bytes look correct. Which bits do you think are wrong?

[broughley488]

I agree with pcprogrammer and the four bytes look correct. Which bits do you think are wrong?

The 5th register (0x04h) is incorrect according to the reset values on the datasheet, also the first register has a tendency to be incorrect sometimes. If I repeat the dumpRegister function they do tend to change a bit, which shouldn't happen as they are just config registers.

As mentioned before in the update the ACD reading seems to work when I pass the converted float value into my 7 segment drivers, so I believe it was an error on my end with regards to the voltage reading being out, I don't know how I made that error, or what that error even was, if anyone can shed some light I would appreciate it.

[pcprogrammer]

I agree with pcprogrammer and the four bytes look correct. Which bits do you think are wrong?

The 5th register (0x04h) is incorrect according to the reset values on the datasheet, also the first register has a tendency to be incorrect sometimes. If I repeat the dumpRegister function they do tend to change a bit, which shouldn't happen as they are just config registers.

As mentioned before in the update the ACD reading seems to work when I pass the converted float value into my 7 segment drivers, so I believe it was an error on my end with regards to the voltage reading being out, I don't know how I made that error, or what that error even was, if anyone can shed some light I would appreciate it.

The registers are not just control registers. Some have status bits or input state bits.

Yes there is a small anomaly with bit 0 of register 0x04, but my explanation in my previous post might be the cause. When it is only that bit that changes when reading the register it is indeed the state of the clock out signal that is seen.

The first register (0x00) holds in bit 0 the status of the conversion, and it is perfectly normal that it changes some time after the reset has been lifted. Why, because the ADC will be done with a conversion.

In your logic analyzer captures you also have the data ready line and you can see that it is only high for a short period of time. Reading the first register will reflect this and return a high in bit 0 only when it is busy with a conversion. This can be used to do poll based checks on when to read the ADC result.

All this kind of information can be distilled from the datasheet, even if it is not literally written down. It just takes logic deduction.

On a side note there is no need to add a h after a hexadecimal number when 0x is added in front of it. So 0x04h is the same as 0x04.