eta-systems / ADS1255

C library for ADS1255/ADS1256 ultra low noise 24-bit ADC for STM32 platform
Apache License 2.0
32 stars 8 forks source link

Issue reading register #1

Closed RobauxSydney closed 2 years ago

RobauxSydney commented 2 years ago

Dear Simon,

During my intership for my electronic degree, I'm using the LC Technology ADS1256 board with a Nucleo-F401RE and I can't manage to read a register. Using your library i'm able to read the voltage but the value that i get when using the ADS125X_Register_Read function is wrong.

Disclaimer : I haven't modified the library and both boards should be working fine

For instance,

/* USER CODE BEGIN WHILE */
  while (1)
  {
      float volt = 0.0f;
      ADS125X_ChannelDiff_Set(&adc1, ADS125X_MUXP_AIN0, ADS125X_MUXN_AIN1);
      volt = ADS125X_ADC_ReadVolt(&adc1); 
      printf("%.15f\n", volt);  // This part works fine

      ADS125X_Register_Write(&adc1, ADS125X_REG_DRATE, ADS125X_DRATE_10SPS); // Here i'm setting the Data Rate to 10 SPS 
          // According to the Datasheet (page 32) inside DRATE register (Address 03h) should be the value : 0b00100011

      HAL_Delay(2); // Just in case

          uint8_t pData=0x00;
      ADS125X_Register_Read(&adc1, ADS125X_REG_DRATE, &pData, 1); 
          // Here, i get : pData = 0b10010001

    /* USER CODE END WHILE */
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

After trying to read as carefully as possible the datasheet, i concluded the theoretical transaction should be : RReg_DRate

Here are my observations with my oscilloscope : (Yellow is DIN and Blue is DOUT)

I believe the first image is beginning of the transaction (the query) which is identical as the theoretical that i talked about above. On the image, we can't see the end of the 2nd byte but it keeps on being 0. IMG_20220429_140633

However, in the answer from the ADS1256, there is a few things i don't get. 1° Why is there some data on the DIN that looks more or less identical (with some late) to the DOUT ? 2° We can see on the blue channel that the first bit is halfed. 3° If we were to forget and the first halfed bit and focus on the rest we would actually get 0b00100011 which is, according to the datasheet, the right value.

Therefore i'm guessing that the issue is located during the receiption.

IMG_20220429_140709

IMG_20220429_144923

About the SPI2 bus on the Nucleo-F401RE board : I believe the default speed is 42 MHz and I'm using an 64 prescaler to slow it down. Also, my wiring should be correct.

How much of what we can observe is not normal ? Have you ever seen similar problem ?

I guess i'm doing something wrong but somehow I can't point it. As far as i know, your library since to be working fine since the beginning of the SPI transaction seems correct.

Best regards, Sydney ROBAUX

mnemocron commented 2 years ago

Hi Sydney I have not worked with the lib in a while. As far as I remember, I used to change the data rage successfully in the using Init function call as here. Furthermore, I used the ADS125X_Register_Read function extensively inside the library during debugging, which is why it should work.

1° Why is there some data on the DIN that looks more or less identical (with some late) to the DOUT ?

The blue signal seems to be in a Z-state before being forced high by the half bit. Not sure why. Maybe the STM32 SPI configuration sends back the received data as ACK, but that does not make sense because yellow is high before the blue signal exits the Z-state. Or maybe (although unlikely) you write to the same variable as the outgoing data. Are your sure the wiring is absolutely correct, I am worried because the high state of the blue signal is 0.5V smaller for the half bit than it is for the rest of the signal.

How much of what we can observe is not normal ?

The behaviour with the copied data on the other data line can be correct or incorrect. I would have to know the signals and would need to dig into the datasheets. But as I said, the lib and functions worked on my hardware.

Have you ever seen similar problem ?

Usually when there is a "bit shift" error in transmitted or received SPI data, it is because of the wrong SPI config (clock polarity and clock edge alignment). But I am not sure if that is the case here since the voltage is read back correctly according to you.

RobauxSydney commented 2 years ago

Hi Simon,

Thank you very much for you quick reply. I believe i've found the solution to our "half bit" problem by selecting "2 Edge" for the "Clock Phase" in the SPI settings. It must be what you refer by "clock edge alignment".

Capture

I now realise that if my voltage reading was halfed it wasn't due to the PGA or any other setting. It was because the spi was taking the half bit for the first of the byte, sorry to have misslead us.

To sum up, your library was flawless and the error was in the SPI config.

Thank you for your good work and reactivity, Sydney ROBAUX