What exactly starts the clk during spi communications?

What means "register 6 is active" ? You mean SPE bit in CR1 register ?

The clock starts when something is written in the DR register and stops at the end of this data transmission.

I disagree that the clock starts when something is written in the DR register, at least during the receive stage. on line 1072 of stm32f0xx_hal_spi.c, it states:

 if ((hspi->Instance->CR1 & SPI_CR1_SPE) != SPI_CR1_SPE)
 
 {
 
 /* Enable SPI peripheral */
 
 __HAL_SPI_ENABLE(hspi);
 
 }

In other words , check if spi is enabled, if it's not, then enable it. But If I remove the "if" section and just tell it to enable spi no matter what, then it starts the clock at that point. Yet I have not started writing to the dr register. Also, on receive, the external (slave) chip doesnt know to start sending until clk is active.

Read out and check/post the SPI registers content just before that line.

JW

As the clock runs only when the master has something to transmit, check if the TX FIFO is empty when you enable the SPI setting SPE bit.

And other SPI registers?

CR1 appears to be OK, there may be some internal state though which prevents the clocks, to which it arrived through previous history; so we need to know about that history. Maybe there's also some hardware dependency.

Please prepare a minimal but complete compilable example exhibiting the problem; best without using any "library" such as Cube.

JW

PS. @Nikita91​ , the SPI is here set to bidirectional mode (halfduplex, CR1.BIDIMODE=1), when you turn it into Rx, it ought to clock automatically.

Ok, So I checked all of the spi registers (cr1,cr2,sr,both i2c, and all 3 crc). Only CR1 changes between cycles:

1. CR1 = 831d (spe off, receive mode)
2. hal transmit
3. CR1 = c35d (spe on, send mode)
4. hal receive
5. CR1 = 835d (spe on, receive mode)
6. (next cycle)
7. CR1 = 835d (spe on, receive mode)
8. hal transmit
9. CR1 = c35d (spe on, send mode)
10. hal receive
11. CR1 = 831d (spe off, receive mode)
12. (start over)

What is strange is that before we go into receive mode both times, all of the registers are in the exact same states. Yet in one cycle, it remembers to turn on the CLK and the other one it does not.

Ill work on a minimal example, but it's as minimal as it gets (hal spi transmit, then hal spi receive). Delays if you want them but they dont change anything.

I don't use Cube/HAL so you may perhaps extract the relevant lines from it and insert it into your code directly.

JW

I keep reading that people avoid cube/hal. Is it that buggy?

It of course has its own share of bugs, but generally I don't think it's more buggy than any other software.

I don't use Cube/HAL - nor Cube/LL or SPL, for that matter - because I don't think it brings any benefit to me. I can read the manual and program accordingly. Would I use a "library", I would need to learn that library - and in the case of problem I would need to learn the real stuff anyway, so that's double work.

With Cube/HAL, there's one more thing which deters me. It tries to be relatively "smart". But doing so, it inevitably limits itself to the "most common usage modes", as it's impossible to be "smart" in every conceivable way a user wants to use the mcu and its features - there are simply too many, as you try to combine the already massive amount of features with the many ways how to use them. In other words, while doing "ordinary" things, Cube/HAL may be an immense help; but as soon as you try to do something "out of ordinary", Cube/HAL may start to be less helpful or even straight get into your way.

YMMV

JW

I follow this opinion about HAL.

But I often use LL because the most interesting parts are:

• naming each bit of each register with a clear name (this can be seen as a complement to the CMSIS MCU description file)
• Macros for set / reset each bits with a clear name. And some nice functions to initialize devices.

This gives a clearer and practically commented code.