Pointers and HAL libs => HardFault?

[David Martins]

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!

[Tesla DeLorean]

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.​

[David Martins]

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 :thumbs_down:

[Tesla DeLorean]

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.

[David Martins]

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!