STM32 - SPI Slave - Using Hal Drivers - Unreliable TXRX and Slow Initialization

[Matt Roybal]

Posted on February 02, 2018 at 19:15

Hello, I will first describe what I am trying to accomplish, what I have tried, and how it is not working; any help/advice is greatly appreciated.

I have an external MCU (Particle Photon) acting as the SPI Master. Approximately every half second it needs to send 64 bytes to the STM32F103. It can also be multiples of 64 bytes (e.g. 50x 64 byte chunks equaling 3,200 bytes in this example... maximum of 200x chunks). The STM32 also has its own data that needs to be sent back to the master MCU, same format.

I have stripped a lot of this down, and am just trying to get a single 64 byte exchange to happen reliably, and I am failing at that.

I used STM32CubeMX to generate the source code and configurations. Here are the functions I am using:

SPI Buffers & Init Flag:

    uint8_t txData[64]; //uint8_t txData[MAX_DEVICES_TRACKED * 64];

    uint8_t rxData[64]; //uint8_t rxData[MAX_DEVICES_TRACKED * 64];    bool spiReady = true;

Main Loop:

while(true)

{    if(spiReady)    {        spiReady = false;        InitSPISlave(&hspi1);    } }

Init SPI:

void InitSPISlave( SPI_HandleTypeDef *spiHandler )

{    memset(rxData, 0, sizeof(rxData));    HAL_SPI_TransmitReceive_IT(spiHandler, txData, rxData, sizeof(txData));}

Callbacks That Occur After SPI TXRX Complete, And Error Callback:

    void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi)

    {        printf('SP1 Data Received: ');         for(int i = 0; i < 64; i++)        {            printf('%lx ', (long)rxData[i]);        }        printf('\n');

memset(txData, 0, sizeof(txData)); //If I don't clear the data, it comes across ok

spiReady = true;

    }

    void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)

    {        printf('SPI1 ERROR: %d \n', hspi->ErrorCode);        spiReady = true;    }

For testing purposes I have a timer that periodically populates the txData buffer. As soon as the transaction is complete, and the master MCU has the data, I want to clear out the txData buffer.... when more data becomes available it will then go into the txData, which is what the timer is simulating.

I am experiencing 2 problems:

1. If I comment out 'memset(txData, 0, sizeof(txData));' the data goes to the master ok. If I leave it as is and clear it after every transaction, the master receives the data but either the first byte is zero, or the entire buffer is shifted over by a byte. This seems somewhat random. I also get SPI errors in the error callback, periodically get OVR error 'HAL_SPI_ERROR_OVR', and then eventually I get 'HAL_SPI_ERROR_FLAG' errors, at which point it stops working completely. It almost seems like something is going on with the STM32 SPI register TX buffer? But I don't fully understand this, or how I should fix it. It could be something else but I am not sure.[/li]
2. When I call 'HAL_SPI_TransmitReceive_IT(spiHandler, txData, rxData, sizeof(txData));' it is really slow to initialize and get up and running. I decided to time this by started a timer when calling that function, and when the callback gets executed, and it takes approximately 300 ms. If I increase the size of the buffers to 640 bytes, it takes several seconds to initialize and start the SPI transfer. I am wanting to do a max of 12,800 bytes, so something is seriously wrong here, there is no reason why it should be taking that long to set up a single SPI transfer. I am not sure what is going on or how to fix this either. I have to call this function again after each SPI transfer, so the MCU is basically always stuck in a state of initializing for several seconds to receive a single transfer.

I tried switching over to DMA SPI, e.g. 'HAL_SPI_TransmitReceive_DMA(spiHandler, txData, rxData, sizeof(txData));', and while it is slightly quicker to initialize-still way too slow, I experience the same problems.

I have been scouring the internet trying to read up on this, and most people say the HAL drivers don't work right, and to work directly with the registers yourself. If this is the case, I don't know where to start in accomplishing that... or if maybe there is a fix I can do to get this up and running?

Any help on working through this is greatly appreciated, thanks!

#stm32 #spi #slave #stm32cubemx #hal

[Jan Waclawek]

Posted on February 02, 2018 at 23:56

printf in embedded is a bad idea, and in ISR is a disaster.

JW