STM32F3 SPI HAL-Driver Problem

[martin239955_stm1]

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]

Posted on February 01, 2016 at 18:27

Pro Tip : WinMerge or Araxis Merge

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

Understand What changed

[martin239955_stm1]

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]

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]

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.