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

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];


Main Loop:

    while(true)
{
{
InitSPISlave(&hspi1);
}
}


Init SPI:

void InitSPISlave( SPI_HandleTypeDef *spiHandler )
{
memset(rxData, 0, sizeof(rxData));
}


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

void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi)
{

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

}

void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)
{
printf("SPI1 ERROR: %d \n", hspi->ErrorCode);
}


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.
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 are junk and 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?

• You can debug the HAL_SPI_TransmitReceive_IT call, you should try to see if you can find what it is waiting for if it is taking so long to get started. Let's see your initialization struct for the clocks and the SPI. FWIW, I use STM32 HAL drivers quite a bit (although it is mostly USB) and while they're a little buggy, they're not really that bad. Writing your own isn't that hard, you basically start with the datasheet and focus on first sending one byte over, then doing rx and tx, then increasing the buffer size. – Catsunami Feb 2 '18 at 18:37
• I have used the HAL_SPI and HAL_QSPI drivers for mass storage and I've never had the issues you are describing. You can also try running these commands in blocking mode and see if that works any better. If it doesn't, then at least you'll know it's your configuration. Also I do not typically approve of printing from an ISR callback, but that shouldn't cause your memset issues. Check your heap size as well. – Catsunami Feb 2 '18 at 18:39