STM32U599 SPI1 EOT flag not updating

[desmond]

I am using `HAL_SPI_Transmit_IT()` API to transmits 6 frames. The TXP interrupt correctly fires and feeds the TXDR register however after feeding the last frame into TXDR the EOT never fires, actually no interrupt fire after the last frame is feed.

• Frame Size: 9 bits
• FiFo threshold: 1 
• All the interrupts that were enabled remain enabled including the EOT. (EIR=0x328)
• TSIZE: 6 (does not change)
• SCLK: 125KHz
  • Source CLK to SPI: HSI (16MHz
  • Prescaler: 128
  • The system clock is running 160MHz

It's worth noting polling mode also failed because EOT isn't being set either.

In other drivers we use HAL_SPI_Receive_DMA() and it works as expected. 

I reviewed  the STHAL driver but I do not see anything obvious wrong.

What criteria, besides TSIZE, triggers the hardware to set the EOT flag?

[tjaekel]

9 bits on a SPI frame? (SPI byte)

As I understand SPI: it is byte oriented, entire transmission must have N * 8 clocks (bits). If receiving 9 bits - the last byte can be "incomplete" (still waiting to fill a byte).

No idea how if it is possible to configure 9 bits as a word (I do not think so, SPI is byte oriented).

[desmond]

What you are saying is incorrect. SPI is a glorified shift register with timing around it, it isn't word/byte/half-word oriented protocol.

On this MCU, I am using SPI1. The datasheet indicates it can handle 4 to 32bits. Additionally the STHAL API allows you to configure anything from 4 to 32 bits. 

The peripheral also has a packing feature but this isn't activated based on how it's accessed.

Given the setup I stated above the TXDR is accessed as 16 bits which means the threshold is hit because it's setup for 1 data packet and the frame is 9 bits wide. So on one access to TXDRAsU16 will push to the FIFO which hits the threshold, which causes the FIFO to offload into the shift register which shifts out 9 bits. However after the last frame is sent the EOT is not generated.

Please note I can observe the handling of `TXP` because it suppose to generate 6 events since I am using a data packet size of 1. So I get 6 TXP events which means the hardware FIFO is popping correctly.

 

[TDK]

How are you determining that EOT isn't getting set? It will be cleared in the HAL IRQ handler so won't ever be set if you're in user code.

The HAL supported method would be to handle the end of transfer action in HAL_SPI_TxRxCpltCallback.

> What are the criteria EOT to fire, the datasheet is not explicit?

The reference manual will have the details. EOT fires when TSIZE words have been written.

> TSIZE: 6 (does not change)

TSIZE is not meant to change. You can track the progress using the CTSIZE field in SPIx_SR register.

[desmond]

• Yes, I am using the provided callbacks but they are not firing. The `HAL_SPI_IRQHandler()` handler never makes it pass the code that handle end of transfers. I have started debugging the STHAL code. My observations are after the last TXP event fires the EOT event never fires which means the IRQ is never called again so there is no way for the `HAL_SPI_IRQHandler()` to handle anything because there is nothing generated by the hardware.
• I have tried polling for the EOT flag using my own implementation as well as trying to use `HAL_SPI_Transmit()`. The `HAL_SPI_Transmit()` polls for the `EOT` in the last few lines but it is never set regardless of how long I wait.
• I have read the reference manual. Is the criteria for EOT firing only dependent on TSIZE?
• I have read similar issue on this forum but for other MCUs. I suspect it might affect this MCU unless STM makes a new IP block for each MCU, which I doubt 

[desmond]

@STOne-32 
Can you please provide some assistance? I believe I may have bumped into a issue with your SOC. 

• Please note setting up the SPI to work with 8 bit frames still doesn't fix anything. The EOT flag is still not being set.
• I found a post where someone observed the same behavior I am observing. However they are using a different MCU.
  
  • https://community.st.com/t5/stm32-mcus-products/stm32h743-does-not-set-eot-bit-when-sck-is-to-high/td-p/181972

[desmond]

Solution:

When the SCLK signal is incorrectly routed to the GPIO block the EOT flag is not set.

Ensure you correctly routed the GPIO block to the SPI SCLK signal using the correct alternative function for the GPIO block.

[STOne-32]

Hi @desmond ,

 

Glad to see you fixed the problem observed . Let us know if an assistance is needed from our side .

Cheers,

STOne-32

[TDK]

> In other drivers we use HAL_SPI_Receive_DMA() and it works as expected. 

I mean, glad you solved it, but it's hard to see how other drivers are working if SCK isn't even hooked up.

[desmond]

They are isolated it's not the same pin, nor peripheral.