STM32F3 SPI HAL-Driver Problem

martin239955_stm1 · ‎2016-02-01

Posted on February 01, 2016 at 17:58

Hi

A while ago we developed a simple application in which data from an ADC (MCP3910) was read via SPI. The SPI-HAL (stm32f3xx_hal_spi.c) driver was version V1.1.1 (from 19-June-2015)

Example:

void MCP3910_ReadData(SPI_HandleTypeDef *hspi,MCP3910REGS *adc){

uint32_t i;

uint8_t adcbuf[6];

adc->ctrlbyte.control_bit.devID = 0x01; // Device ID

adc->ctrlbyte.control_bit.regadd = REG_CHANNEL0; // Start register to read

adc->ctrlbyte.control_bit.rw = 0x01; // read

memset(adcbuf,0,sizeof(adcbuf)); // init buffer

HAL_NVIC_EnableIRQ(EXTI3_IRQn); // Enable interrupt for DR-Signal

adc->DataReadyFlag = 0; // Init DataReady flag

for (i = 0; i < BufferLen; i++){ // read 128 values (24bit)

while(!adc->DataReadyFlag);

adc->DataReadyFlag = 0;

MCP3910_Select();

HAL_SPI_Transmit(hspi,&(adc->ctrlbyte.value),1,1000); // Send control-byte

HAL_SPI_Receive(hspi,adcbuf,6,1000); // receive two values (6 bytes)

MCP3910_DeSelect();

// merge values

adc->raw_I[i] = ( (adcbuf[0] << 16) | (adcbuf[1] << 8) | (adcbuf[2]) );

adc->raw_V[i] = ( (adcbuf[3] << 16) | (adcbuf[4] << 8) | (adcbuf[5]) );

memset(adcbuf,0,sizeof(adcbuf));

}

HAL_NVIC_DisableIRQ(EXTI3_IRQn);

}

Everything worked fine...

Now, we updated the STM32CubeF3 Firmware Package to version V1.4.0 / November 13, 2015

stm32f3xx_hal_spi.c = V1.2.0 (13-November-2015)

In this new configuration, we receive wrong data from the ADC (totally garbage). Has anyone an idea how to fix this issue?

Note: If we overwrite the new SPI-HAL driver with the previews one, everything works fine.

Thanks for your help

Kind regard

Martin

Tesla DeLorean · ‎2016-02-01

Posted on February 01, 2016 at 18:27

Pro Tip : WinMerge or Araxis Merge

http://www.araxis.com/merge/index.en

Understand What changed

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

martin239955_stm1 · ‎2016-02-02

Posted on February 02, 2016 at 12:56

It would be nice if ST documents major changes and side-effects in the behavior of its HAL so we don't have to figure it out by our self.

Walid FTITI_O · ‎2016-02-05

Posted on February 05, 2016 at 17:47

Hi Cami,

Thanks for your feedbacks. To figure out the change done between versions, please, refer to STM32Cube_FW_F3_V1.4.0\Drivers\STM32F3xx_HAL_Driver\Release_Notes.html

I suggest that you try to proceed by testing the return of the HAL_SPI_Receive ()function to see the type of return ( HAL_error or HAL_OK) and if it is an error to see what type of error exactly.

You can test with similar code like the following:

Error = HAL_SPI_Reveive ();

If (Error != HAL_OK)

{

#Error stop code here and check error code

}

The received data are shifted by 1 bit for example or corrupted periodically compared to the expected one/ or a random frame ?

-Hannibal-

Rob.Riggs · ‎2016-02-14

Posted on February 14, 2016 at 20:30

It sounds like you are running into the same problem that I am while reading/writing an EEPROM. The HAL SPI code attempts a 16-bit transfer when more then one bytes needs to be read or written and scrambles the data while doing so. Removing the code within the HAL functions that does 16-bit transfers in these cases fixed the problem for me. (See my post from earlier today.)

It's likely that the DMA functions don't suffer from this problem, but a polling solution (with their timeouts) is a more natural fit for my needs.