cancel
Showing results for 
Search instead for 
Did you mean: 

I need to use SPI without a clock, Cube MX won't let me do it.

MBC
Associate III

It's a niche application. STM32H5 QFN

I need SPI2_MOSI to make a specifically shaped wave. SPI is works well for this. I do not need the SPI_CLK pin/function. I set Cube MX to SPI2 Transmit Only Master, and of course it applies the CLK pin because almost everyone would want that.

I would just not hook the CLK up but for two reasons:

1. I don't really want a wiggling pin hooked to nothing.

2. I want to use that pin for OCTOSPI_nCS (for QSPI). It is a valid function of that pin.

 

I know roughly in code what I would need to change to select that pin for that function. However, Cube MX either allows me OctoSPI using that pin for SPI2. I can't find the answer to what pins are required for a peripheral in the reference manual.

Is it possible to use SPI2 for only it's MOSI pin and use the pin that would be SPI2 CLK for OCTOSPI_nCS instead?

1 ACCEPTED SOLUTION

Accepted Solutions

> The SPI may work without some signals mapped onto port pins.

Or may not. In particular, the "traditional" ('F1/'F4) SPI receiver is known to work out of the clock *input* from SCK, even in master mode; so the receiver simply does not work at all if there's no pin assigned to SCK, and low drive (OSPEEDR) on highly capacitively loaded SCK is known to result in strangely bit-shifted data (Corrupted last bit of data and/or CRC received in Master mode with delayed SCK feedback erratum). However, in that SPI, transmitter (i.e. MOSI in master mode) is unaffected afaik.

 

> SPI setup without HAL is much simpler than with HAL.

+1, although SPI in new higher-end STM32 appear to be overcomplicated beasts with potential unknowns ahead.

 

On a general note...

> It will be a couple weeks until I can get a development unit in hand, and I'd like to try and make plans for the layout.

I'd recommend to get a "known good" board with the given mcu, such as Nucleo or Disco or EVAL, for proof-of-concept testing before designing your own. It may also come handy later when debugging some hardware-related issues.

JW

View solution in original post

4 REPLIES 4

Cube/CubeMX inevitably cover only a small fraction of what the hardware allows, whatever its authors deemed "usual".

In other words, why don't you simply try, without Cube/CubeMX?

JW

Thanks for the time it took to answer but that is not helpful. If I could easily test this, I would. It will be a couple weeks until I can get a development unit in hand, and I'd like to try and make plans for the layout.

 

Perhaps someone else can answer what happens if only 1/2 a peripheral is used?

gbm
Lead III

Nothing special. The SPI may work without some signals mapped onto port pins. No problem with using just MOSI line. Did that many times, mostly for WS2812 control.

SPI setup without HAL is much simpler than with HAL.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

> The SPI may work without some signals mapped onto port pins.

Or may not. In particular, the "traditional" ('F1/'F4) SPI receiver is known to work out of the clock *input* from SCK, even in master mode; so the receiver simply does not work at all if there's no pin assigned to SCK, and low drive (OSPEEDR) on highly capacitively loaded SCK is known to result in strangely bit-shifted data (Corrupted last bit of data and/or CRC received in Master mode with delayed SCK feedback erratum). However, in that SPI, transmitter (i.e. MOSI in master mode) is unaffected afaik.

 

> SPI setup without HAL is much simpler than with HAL.

+1, although SPI in new higher-end STM32 appear to be overcomplicated beasts with potential unknowns ahead.

 

On a general note...

> It will be a couple weeks until I can get a development unit in hand, and I'd like to try and make plans for the layout.

I'd recommend to get a "known good" board with the given mcu, such as Nucleo or Disco or EVAL, for proof-of-concept testing before designing your own. It may also come handy later when debugging some hardware-related issues.

JW