Unable to read data on SPI MISO line with STM32G07 when communicating with ADS124S06.

[spd-kalyan]

Hii Team, 

I'm using STM32G070RBT6 MCU to communicate with ADS124S06. 
I've configured the SPI on the MCU for Mode1 and GPIOs CS, RST, START pins as output (NO pull up/ pull down) and DRDY as input (NO pull up/ pull down). 
GPIO Configuration:

SPI Configuartion:

Clock Configuration: 
 

Code : 

the ADS124S06_Init function: 

bool ADS124S06_Init(ADS124S06_Handle *dev) {

DEBUG_PRINT("Entered init Function");

// RESET pin sequence

HAL_GPIO_WritePin(dev->reset_port, dev->reset_pin, GPIO_PIN_RESET);

HAL_Delay(1);

HAL_GPIO_WritePin(dev->reset_port, dev->reset_pin, GPIO_PIN_SET);

HAL_Delay(5);

ADS124S06_WriteRegister(dev, 0x02, 0x54); // I/p MUX: AIN5-AIN4 0x54

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x03, 0x00); // GAIN: PGA=1, 20SPS

ADS124S06_WriteRegister(dev, 0x04, 0x14); // DataRAte : 20SPS, osc-4.096MHz

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x05, 0x0A); // REF : internal 2.5V On always.

ADS124S06_WriteRegister(dev, 0x06, 0x00); // IDACMAG

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x07, 0xFF); // IDACMUX

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x08, 0x00); // VBIAS

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x09, 0x10); // SYS

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x0A, 0x00);

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x0B, 0x00);

ADS124S06_WriteRegister(dev, 0x0C, 0x00);

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x0D, 0x00);

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x0E, 0x00);

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x0F, 0x40);

ADS124S06_WriteRegister(dev, 0x10, 0x00);

HAL_Delay(1);

ADS124S06_WriteRegister(dev, 0x11, 0x00);

HAL_Delay(1);

return true;

}


bool ADS124S06_WriteRegister(ADS124S06_Handle *dev, uint8_t reg, uint8_t data) {

uint8_t cmd[3] = { ADS_CMD_WREG | (reg & 0x1F), 0x00, data };



cs_low(dev);

bool ok = HAL_SPI_Transmit(dev->hspi, cmd, 3, ADS_TIMEOUT) == HAL_OK;

cs_high(dev);

return ok;

}


in the ADS124S06_ReadRegister function I'm just doing
{
uint8_t txData[20];
uint8_t rxData[20];

txData[0] = 0x20 ; //RREG

txData[1] = 0x11;

txData[2] = 0x00;

txData[3] = 0x00;

txData[4] = 0x00;

txData[5] = 0x00;

txData[6] = 0x00;

txData[7] = 0x00;

txData[8] = 0x00;

txData[9] = 0x00;

txData[10] = 0x00;

txData[11] = 0x00;

txData[12] = 0x00;

txData[13] = 0x00;

txData[14] = 0x00;

txData[15] = 0x00;

txData[16] = 0x00;

txData[17] = 0x00;

txData[18] = 0x00;

txData[19] = 0x00;


cs_low(dev);
HAL_SPI_TransmitReceive(dev->hspi, txData, rxData, sizeof(rxData), 100);

cs_high(dev);

for (uint8_t i =0; i<20;i++)

{

DEBUG_PRINT("rxdata[%d] = 0x%02X",i, rxData[i]);

}


///////////////////////

static void cs_low(ADS124S06_Handle *dev) {

HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_RESET);

}



static void cs_high(ADS124S06_Handle *dev) {

HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_SET);

}

this is what I'm doing. I've configured all the SPI settings as per the datasheet of ADS124S06 and able to receive the data on MISO line,
I've verified it using logic analyser.

written data zoom out view

read data RREG

zoom out view

by seeing the logic analyser output, I can say that the data is available on MISO line but through firmware unable to receive/store it into buffer.
in debug mode keeping the rxData[20] in global and addded it into LiveExpressions, I'm facing an issue that rxData is not filling.

in this only SPI1 is enabled and also uart for debugging.

Please help me out from this issue. I hope I've given all the necessary information to debug this issue in detail, I can also provide any further information needed regarding the same.

Thank you, Kindly Please help me. 

---

Edited to apply source code formatting - please see How to insert source code for future reference.

[Andrew Neil]

---

@spd-kalyan wrote:

I shorted the MISO and MOSI pins to create a loopback while the ADC was also connected. Surprisingly, instead of receiving the data sent on the MOSI line, I received the expected data from the ADC.

---

Have you got it in a mode where MOSI is bidirectional ?

[spd-kalyan]

Hii @Saket_Om, Thanks for your time. 

I tried with the data type you've given too, but the rx_buf is not being updated. 
In my observations this issue is based on configuration of SPI. I'm expecting MISO line to be high in idle. 

[spd-kalyan]

Good morning @Andrew Neil, 
No, I don't think so. I got to check the SPI control registers of STM32G070 board. 
when I read the SPI1_CR1, SPI1_CR2, SPI1_SR gives me below data.

//After initialisation of SPI (haven't communicated with peripheral)
CR1 -> 0x032D [0000 0011 0010 1101]
CR2 -> 0x1700 [0001 0111 0000 0000]
SR -> 0x0002 [0000 0000 0000 0010]

// After Data transfer (communicated with peripheral)
CR1 -> 0x036D [0000 0011 0110 1101]
CR2 -> 0x1700 [0001 0111 0000 0000]
SR -> 0x0002 [0000 0000 0000 0010]

 
everything seems fine but, in my observation, the MISO line should be high in idle condition, but it is being low. 
Are there any configuration/ parameters to set, to keep the MISO line high in idle. 

[Saket_Om]

Hello @spd-kalyan 

Please try to configure the SPI GPIO as in the example below:

STM32CubeG0/Projects/NUCLEO-G071RB/Examples/SPI/SPI_FullDuplex_ComIT_Master/Src/stm32g0xx_hal_msp.c at master · STMicroelectronics/STM32CubeG0 · GitHub

    /**SPI1 GPIO Configuration
    PB3     ------> SPI1_SCK
    PB4     ------> SPI1_MISO
    PB5     ------> SPI1_MOSI
    */
    GPIO_InitStruct.Pin = GPIO_PIN_3|GPIO_PIN_4|GPIO_PIN_5;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_PULLDOWN;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
    GPIO_InitStruct.Alternate = GPIO_AF0_SPI1;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

[spd-kalyan · Accepted solution]

Hii @Saket_Om, @Andrew Neil 

Thank you for your detailed and insightful responses regarding the SPI states.

I’m pleased to inform you that the issue has been resolved, and I can now be able to successfully receive data on rxData. The problem was traced to improper soldering at the controller end, which has been corrected now.

I sincerely apologize for my oversight. I hope that your expertise will continue to guide me in my future tests. Thank you again for your time and support.

[Andrew Neil]

---

@spd-kalyan wrote:

Thank you for your detailed and insightful responses regarding the SPI states..

---

You're welcome!

---

@spd-kalyan wrote:

The problem was traced to improper soldering at the controller end, which has been corrected now.

---

That was the reason behind this.

#ProbeAtThePin