STM32U5: Spi delay after start
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-12 6:09 AM
Hello,
after setup SPI1 and setting CSTART=1, I expected that SPI is send immidiatly on bus.
(I toogled PE00 with CSTART=1)
I couldn't find some that explains that behaviour. It behave the same, if I use DMA or writing directly to TXDR.
Do you have an idea ?
My testcode.
SPI1->IFCR = 0xFFFF; // Clear all flags
MODIFY_REG(SPI1->CR2, SPI_CR2_TSIZE, BufferSize);
SPI1->CR1 |= (SPI_CR1_SPE);
SPI1->CR1 |= SPI_CR1_CSTART;
GPIOE->ODR &= ~(1 << 0);
for (u32 i = 0; i < BufferSize; i++)
{
LL_SPI_TransmitData8(SPI1, pBuffer[i]);
}
CPU is set to 160Mhz and SPI Prescaler is 256
Solved! Go to Solution.
- Labels:
-
SPI
-
STM32U5 series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-14 12:19 AM
Hello FKaes.1,
In fact, hardware needs 5 clock cycles to have first clock edge from CSTART assertion. It corresponds to 5*256/150 = 8µs. Therefore, the SPI behavior that you can observe is the expected one.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-12 8:09 AM
Hello @FKaes.1
This bit is set to start SPI communication. However, communication cannot start if there is no data available in the TX FIFO.
Saket_Om
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-12 10:54 PM
Hi, I changed it for testing to "front load" the FIFO with some bytes. Bu still same behavior.
SPI1->IFCR = 0xFFFF; // Clear all flags
MODIFY_REG(SPI1->CR2, SPI_CR2_TSIZE, BufferSize);
SPI1->CR1 |= (SPI_CR1_SPE);
for (u32 i = 0; i < 8; i++) // front load before start
{
LL_SPI_TransmitData8(SPI1, pBuffer[i]);
}
SPI1->CR1 |= SPI_CR1_CSTART; // start
GPIOE->ODR &= ~(1 << 0);
for (u32 i = 8; i < BufferSize; i++) // send the remaining bytes
{
LL_SPI_TransmitData8(SPI1, pBuffer[i]);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-13 5:50 AM
For testing, I set the SPI Prescaler from 256 to 32. Then the delay was reduced by factor 8, too. So, I assume it is not caused by SW.
At the end, this isn't a problem for me. I was just interessed, if this was caused by a wrong setup or usage by my side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-13 6:32 AM
Hello FKaes.1,
Such delay can appear if MSSI bits of CFG2 register are not set to their reset values.
Could you verify this register please ?
Also I suppose your SPI is configured in Master mode, otherwise it is the received master clock which triggers the start of transfer and not CSTART bit.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-13 7:41 AM
This are the settings+config rigth before setting CSTART = 1.
MSSI = 0
Master = 1
HW SS is not indented to be used. Chip select is controlled by SW.
For testing, I set MSSI to the max. value and the delay increased. So, the direction seems to be right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-14 12:19 AM
Hello FKaes.1,
In fact, hardware needs 5 clock cycles to have first clock edge from CSTART assertion. It corresponds to 5*256/150 = 8µs. Therefore, the SPI behavior that you can observe is the expected one.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-05-14 2:08 AM
ok, thank you. That explains it. I was just not able to find that in the datasheet / ref manual.
