cancel
Showing results for 
Search instead for 
Did you mean: 

Pointers and HAL libs => HardFault?

David Martins
Senior

I'm having a problem that I don't understand why it happens.

I am using STM32CUBEIDE (updated).

Each time the code below runs, the PC jumps to "HardFault_Handler". But I can't understand what the problem is ...

uint8_t buff_cfg[10] =
    { 0 };
 
    buff_cfg[0] = 1;
    buff_cfg[1] = 2;
    buff_cfg[2] = 3;
    buff_cfg[3] = 4;
 
    HAL_SPI_Transmit(&hspi1, &buff_cfg[1], 2, SPI_TIMEOUT);

If I don't reference the buffer pos, the code runs smoothly, and the data is correctly delivered by SPI

uint8_t buff_cfg[10] =
    { 0 };
 
    buff_cfg[0] = 1;
    buff_cfg[1] = 2;
    buff_cfg[2] = 3;
    buff_cfg[3] = 4;
 
    HAL_SPI_Transmit(&hspi1, buff_cfg, 2, SPI_TIMEOUT);

This situation is not making any sense to me ...

Thanks for your help!

4 REPLIES 4

The CM0 has little tolerance for unaligned reads. The library takes your odd aligned pointer and converts to a uint16_t* one, and chokes when it reads from it.​

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

Based on this question I have managed a way to put this working ...

https://community.st.com/s/question/0D50X00009XkdsnSAB/bug-stm32f0xx-hal-spi-transmit

        while (hspi->TxXferCount > 0U)
        {
            /* Wait until TXE flag is set to send data */
            if (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE))
            {
//                if (hspi->TxXferCount > 1U)
//                {
//                    /* write on the data register in packing mode */
//                    hspi->Instance->DR = *((uint16_t *) pData);
//                    pData += sizeof(uint16_t);
//                    hspi->TxXferCount -= 2U;
//                }
//                else
//                {
                *((__IO uint8_t *) &hspi->Instance->DR) = (*pData++);
                hspi->TxXferCount--;
//                }
            }

Making this modification between lines 627 and 644 ("stm32f0xx_hal_spi.c") solves the problem.

There seems to be a problem with cortex-M0 making unaligned accesses.

The ST team has been aware of this issue, reported in the forum since July 2018. We are in September 2019 and no fix has been applied.

Negative point for ST 👎

Those post are from 2017 originally.

Still it is probably down that fork because the SPI is initialized in 16 bits mode.

The CM0 has more alignment issues because they commit less transistors to the deign, so it doesn't do two 8 bit reads like the CM3 would have.

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

There should be a list of unresolved issues and possible workarrounds, so that the forum does not fill with issues like this.

ST is more concerned with ruining IDEs than solving lib problems.

Thanks Clive Two.Zero for the quick response!