Reading a 16-bit word via SPI [STM32]

[XaviPacheco]

To receive data via SPI in polling mode, HAL library has the following definition:

HAL_SPI_Receive(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size, uint32_t Timeout).

I understand the first parameter. But, I'm confused about the second and third parameter. I've told CubeMx that the data size for SPI1 is 16 bits. Now, the second parameter need a 8 bits pointer. Let's say that

HAL_SPI_Receive(&hspi1, &SPIRx[0], 1, 1);

I've declared SPIRx as uint16_t SPIRx[1], but the compiler throws a warning saying that "passing argument 2 of 'HAL_SPI_Receive' from incompatible pointer type [-Wincompatible-pointer-types]"

So, obviously the pointer has to be 8 bits. So, if I want to read a 16 word data from a current sensor, do I need to declare a 8 bit pointer, and in the third parameter, uint16_t Size, do I say that I want to receive two bytes?

I would appreciate anyone help clear my mind.

[rjp]

normally these api's do everything as a block of bytes and its up to you to reconstruct the specific data types.

eg:
 
  uint8_t buffer[2];

  HAL_SPI_Receive(&hspi1, buffer, 2, 1);

  uint16_t value = ((uint16_t)buffer[0] << 8 ) | ((uint16_t) buffer[1]);
 

[XaviPacheco]

So, isn't it relevant that I told CubeMx the data size to be 16 bits instead of 8? Because I’m using a 8 bits pointer anyways, so I think if I say that my data size is 8 bits, it would be the same.

Another question, I set the timeout at 1. But I’ve seen timeouts at 5000. What's the criteria behind?

[newbrain]

So, isn't it relevant that I told CubeMx the data size to be 16 bits instead of 8? Because I’m using a 8 bits pointer anyways, so I think if I say that my data size is 8 bits, it would be the same.

Another question, I set the timeout at 1. But I’ve seen timeouts at 5000. What's the criteria behind?

Timeouts depend very much on the needs and constraints of the application, quite difficult to give a general rule, but yes 1ms seems a bit tight...

As for the SPI data transfer size: yes it's extremely relevant.

The SPI peripheral in STM32F7 (IIRC that's what you are using?) will send/receive the data differently if it's in <=8bit or >8bit mode.
If in 16bit mode, the reconstruction suggested by rjb will not work, as the MSByte will be in buffer[1] and the LSByte in buffer[0]: the data register is treated as an uint16_t and (this) Arm is little endian, so the lower address will hold the least significant part.

Note that this is true even if you use direct register access instead of the HAL.

If you are sending and receiving 16bit words, the best option IMO is to use a uint16_t variable, and cast its address to an a (uint8_t *) when passing it to the HAL (if you want to silence the warning).
The C standard guarantees that the cast gives the expected results: address of the first byte in the object.

In this way there's no need for reassembling the received values, assuming, of course, that they are transmitted as 16bit cvalues MSb first!

The size must still be given in bytes, so it will be something as:

Code: [Select]

  uint16_t val;
  HAL_SPI_Receive(&hspi1, (uint8_t *)&val, 2, 10);
Edit: corrected after richardman's finding!

[richardman]

The size must still be given in bytes, so it will be something as:

Code: [Select]

  uint16_t val;
  HAL_SPI_Receive(&hspi1, (uint8_t)&val, 2, 10);

Minor typo:

Code: [Select]

  uint16_t val;
  HAL_SPI_Receive(&hspi1, (uint8_t *)&val, 2, 10);

[XaviPacheco]

Thank you.

Actually, my SPI routine is called every 10ms by a timer-based interrupt. That's why I asked about the timeout.

[XaviPacheco]

I'm having problems to read the sensor 

This is my sensor datasheet TLI4970

This is my routine every 10ms:

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET); //Bring slave select low
HAL_SPI_Receive(&hspi1, (uint8_t *)&SPIRx, 2, 10);   //Receive data
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);    //Bring slave select high

However, I get random values even when the current is zero. I'm getting values like:
0x8800
0x8803
0x8801
0xA7FF
0x87FC
0x97FE
0xA802
0xA801
0x97FD
0x87FD
0xA800
0xA7FE

According to the datasheet, these are sensor status messages, but none of them are Sensor Current Messages. The hardware seems okay. This sensor is not so common I think, I haven't found much help.

[newbrain]

I'm having problems to read the sensor 

This is my sensor datasheet TLI4970

This is my routine every 10ms:

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET); //Bring slave select low
HAL_SPI_Receive(&hspi1, (uint8_t *)&SPIRx, 2, 10);   //Receive data
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);    //Bring slave select high

However, I get random values even when the current is zero. I'm getting values like:
0x8800
[...8<...]
According to the datasheet, these are sensor status messages, but none of them are Sensor Current Messages. The hardware seems okay. This sensor is not so common I think, I haven't found much help.

Nothing strange in that code, but those values really look random, not a legit status message.
That chip should really return something about 0 (4096) with no current through it, but:

• HW: Check all the connections are correct
• HW: If you have a scope, check for signal integrity (and SPI decode, if available).
• SW: The sensor is good for SPI clock frequencies up to 5MHz, how is the clock chain to the SPI set up?
• SW: Make sure the SPI is defined with the correct clock polarity and phase.

Actually, my SPI routine is called every 10ms by a timer-based interrupt. That's why I asked about the timeout.

I see, then I would not use a TO of 10ms...
Generally speaking, I try not to hang a long time in ISRs.
In any case, the maximum update frequency for the sensor is 70Hz, so a 10ms sampling time seems higher than needed (you are bound to get duplicated reads).

[XaviPacheco]

I'm now reading the sensor every second:

I've captured a new pattern of received data and all of them start at either 8 or A in the MSB position. I don't expect to receive "1" in the MSB bit after the first message which is the status. It's interesting that if I ignore the 3 top bits, the measurement makes sense a little bit. But, I have to receive a zero in the first top bit so that the message is about the current.


This is how my SPI is set:

/* SPI1 init function */
static void MX_SPI1_Init(void)
{

  /* SPI1 parameter configuration*/
  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES;
  hspi1.Init.DataSize = SPI_DATASIZE_16BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
  hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi1.Init.CRCPolynomial = 7;
  hspi1.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
  hspi1.Init.NSSPMode = SPI_NSS_PULSE_ENABLE;
  if (HAL_SPI_Init(&hspi1) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

}

[newbrain]

  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2;

Are you sure you are keeping the SPI clock rate below 5MHz as needed by the sensor?
What is your APB2 frequency?
On an L432 (is that what you are using? you mentioned it in some other post), it can be up to 80MHz, and with a /2 prescaler that would make 40MHz...slightly higher than what the sensor supports  .

Clock and polarity look good.

[XaviPacheco]

My APB2 frequency is 1 MHz. HCLK is 2 MHz. So, do you think that could be a potential problem? I will try 5 MHz as suggested in the datasheet. I thought 5 MHz was like the max frequency supported. I've misinterpreted that data.

[newbrain]

No, it's fine, as long as it less than 5MHz, no misinterpretation there!
No minimum frequency or maximum times are given, so it should be perfectly ok to drive it at 500kHz.

[XaviPacheco]

Ok. I'll continue checking. For some reason I don't get expected values.

[XaviPacheco]

Wait... according to the datasheet, I think I should set clock phase =1, which means that I have to modify the following line:

hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;

CubeMx says that 2 Edge, is clock phase =1

[richardman]

Do yourself a HUGE favor, and get something like a LOGIC logic analyzer or something. It's invaluable to make sure your SPI (or I2C etc.) timing and signals are what you expect. For example, you may need some delay between setting and unsetting the chip select, or time for the sensor to respond etc.

[XaviPacheco]

Indeed. That was my problem. I had SPI mode 0, when the right one is the Mode 1.  Everything works fine now.

[PAULN2]

Hi Xavi, Thanks a lot. I have learned so much with the info you have published. But, I want to ask you about the values you obtain when read the sensor. I am currently using a TLI4970 mounted on Hall Current Click Board of Mikroelectronika and STM32F4 Discovery Board. Apparently, I have done correctly all the config steps for spi port usign STM32CubeMx Tool and Hal Drivers to sense current about 1A but when I read the sensor I obtain erractic values. i.e I obtain positive, zero and negative values. I'd appreciate your help.

[A.Ersoz]

Hello guys,

I have almost same problem with this thread. I try to read 16 bit data from ADC (ADS7886) conversion with SPI. In the debug mode, I read only middle level and upper level of my signal values, but the lower level of signal values are missing. In the attachment, there is result of my code in debug mode and the input signal (yellow) of the ADC. Do you have any idea to solve the problem?

Code: [Select]

void ADC_Conversion_of_Voltage_Transients()
{
uint16_t ADC_Buf;

HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_RESET);
HAL_SPI_Receive(&hspi4,(uint8_t *)&ADC_Buf,2,100);
volt = (float)(ADC_Buf * 5 / pow(2,12)); //
testdata_in[i++]=volt;
HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_SET);
}




[SiliconWizard]

Hello guys,

I have almost same problem with this thread. I try to read 16 bit data from ADC (ADS7886) conversion with SPI. In the debug mode, I read only middle level and upper level of my signal values, but the lower level of signal values are missing. In the attachment, there is result of my code in debug mode and the input signal (yellow) of the ADC. Do you have any idea to solve the problem?

Code: [Select]

void ADC_Conversion_of_Voltage_Transients()
{
uint16_t ADC_Buf;

HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_RESET);
HAL_SPI_Receive(&hspi4,(uint8_t *)&ADC_Buf,2,100);
volt = (float)(ADC_Buf * 5 / pow(2,12)); //
testdata_in[i++]=volt;
HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_SET);
}


Well, I think so. Take a look at "Figure 1. Interface Timing Diagram" of the datasheet.
You'll receive the sample word in a "most significant bit first" manner. But you're storing the result in a 16-bit integer. The thing to know here is that ARM-cortex MCUs are low-endian (at least by default).
ADC_Buf will thus contain a word in which the sample bytes are swapped... You need to swap them back.

Since you can't take advantage of the fact that the ADC gives you a low-endian value, here it's simpler to declare ADC_Buf as "uint8_t ADC_Buf[2];", then later you can call "HAL_SPI_Receive(&hspi4, ADC_Buf,2,100);" (no cast needed anymore - besides, you don't need to put a "&" before an array in C, it's a pointer.)

You'll reconstruct the value with something like (assuming "Sample" is declared as uint16_t): "Sample = ((uint16_t) ADC_Buf[0]) << 8 | ADC_Buf[1];", and finally you can write: "volt = (float)(Sample * 5 / pow(2,12));"

The DS of the ADC states that the (4) upper bits sent through SPI are 0, but for good measure, since it's a 12-bit ADC, you can write this instead of the above:
"Sample = (((uint16_t) ADC_Buf[0]) << 8 | ADC_Buf[1]) & 0x0FFF;"

Also, take another good look at the SPI diagram in the DS. Use the correct SPI mode, else you may have a 1-bit shift in the values you read...

[A.Ersoz]

Thank you for your response!

I set the SPI as receive only master mode. Clock polarity as high and phase is 2edge. Its prescaler is 8 and baudrate is 13.5Mbits/s. Baudrate should be maximum 16 Mbit/s, shouldn't it?

The other thing is that should I control the conversion with a timer interrupt? Because of on of my trial is that setting a timer with 10 times bigger frequency than input signal frequency. Then, when the interrupt occurs, the conversion will happen. With this way, I imagine to control the sampling time.

[rstofer]

I haven't looked at the exact details of the SPI peripheral but on many, you are writing the value to a register.  The register then shifts the data.  So far, no surprise....  But when you send the byte to the register and raise CS' too early, the transmission is garbled because the sender stops sending.

It is sometimes helpful to test if the send operation is actually complete before raising CS'.

Now, there is a possibility that the HAL supplied code doesn't return before the transmission is actually complete.  Maybe...

[A.Ersoz]

The interesting thing is that the ADC SCK has 48 clocks are generated in between CS reset and set changing. Maybe because of that the conversions are not true. For example, I have attached the ADC SCK (yellow), ADC SDO (green), and CS (green in another figure) responses.

[SiliconWizard]

Looks like you have multiple problems here.

First, you'll need to fix what I said; your code was interpreting the sample value with byte swapped. That's a guarantee.

But from the scope capture, you seem to have some kind of hardware issue there. Why are the clock and data lines looking like they become hi-Z towards the end of the transfer? Check your whole code. Did you really show us everything you do? EDIT: for the MISO line, it's probably perfectly normal. The ADC makes it Hi-Z once 16 clock pulses have passed. As to your SPI clock, you're controlling it, so it looks suspicious. I don't know why you'd configure the CLK line as HI-Z once the transfer is done... doesn't seem to be useful.

So now your main problem is why the 48 clock pulses? You probably configured the SPI peripheral incorrectly (like, probably not for 8-bit transfers...), which most likely explains both the 48 clock pulses AND the fact the clock line gets Hi-Z once the transfer is done.

Three things to do: 1. Check and fix the configuration of your SPI peripheral. 2. I wouldn't leave the MISO line floating when the ADC is not accessed; for this, I would configure the corresponding MCU I/O enabling the internal pull-down for instance. Floating inputs can increase your power consumption significantly. And 3. Implement the swapped bytes fix I suggested.

Oh, a last suggestion. While you're fixing the SPI configuration, you could just configure it as 16-bit, MSB first transfer. Then you wouldn't need to swap the bytes by hand.

[A.Ersoz]

Thank you your comments are valuable!

Firstly I modified the SPI mode the receive only master to full duplex master. Then, I make it pull-down of MOSI GPIO pin in its configuration window. Then I set the 16 bit data transfer (Motorola -default-). For the prescaler,  I set 8 for getting 13.5 Mbits/s. I understand from the datasheet that maximum SCK frequency would be 20 MHz. By the way, the SCK pin shows 16 square waves.

This is also the SPI configuration:

Code: [Select]

static void MX_SPI4_Init(void)
{

  /* SPI4 parameter configuration*/
  hspi4.Instance = SPI4;
  hspi4.Init.Mode = SPI_MODE_MASTER;
  hspi4.Init.Direction = SPI_DIRECTION_2LINES;
  hspi4.Init.DataSize = SPI_DATASIZE_16BIT;
  hspi4.Init.CLKPolarity = SPI_POLARITY_HIGH;
  hspi4.Init.CLKPhase = SPI_PHASE_1EDGE;
  hspi4.Init.NSS = SPI_NSS_SOFT;
  hspi4.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;
  hspi4.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi4.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi4.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi4.Init.CRCPolynomial = 7;
  hspi4.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
  hspi4.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
  if (HAL_SPI_Init(&hspi4) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

}
   

Then, I change the main function to do the conversion. I agree that 4 bit of data should be zero but with AND operation, don't we loose data. Instead of the doing AND, can we do shifting four zero bits to the top of the array?

Here is my conversion function:

Code: [Select]

void ADC_Conversion_of_Voltage_Transients()
{
uint8_t ADC_Buf[2];
float Sample;
uint8_t i=0;
float testdata_in[16];

HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_RESET);
HAL_SPI_Receive(&hspi4,ADC_Buf,2,100);
HAL_GPIO_WritePin(ADC_CS_GPIO_Port, ADC_CS_Pin, GPIO_PIN_SET);
Sample = (((uint16_t) ADC_Buf[0]) << 8 | ADC_Buf[1]) & 0x0FFF;
volt = (float)(Sample * (5.0 / 4096.0)); //
testdata_in[i++]=volt;
i %= 16;
}
}

For testing my code and configuration, I feed the ADC with 2.5V step function signal (yellow line and you can check its amplitude with (DELTA)Y variable). But the results show different values.

I have attached the ADC input signal and the results. I also attached the ADC SCK (yellow) and ADC SDO (green) signals.

[A.Ersoz]

The ADC requires 20MHz clock rate through SPI configuration (this is what I understand from its datasheet). But in the SPI4 configuration window, I can set only 13 Mbits/s or 26 Mbits/s baudrate. Do you think the problem is related with setting the baudrate issue? The other thing is that the clock shape of the ADC SCK is distorting (meaning not exact square shape) after 1 Mbits/s baudrate settings.