SPI Clock goes low when Cable Select does

[jagauthier]

Hello,

I am interfacing with a peripheral where code exists for Arduino, but using it as reference for STM32. The SPI mode is 3. The Arduino code works, so I am attempting to reproduce it's methods for communication. An issue I am seeing is that the SPI CLK signal is going low as soon as I lower CS. For instance, if you take a look at this snippet of code:

void pwm3901_write(uint8_t reg, uint8_t value) {
 uint8_t buffer[2];
 reg |=0x80u;
 SPI1_CS_GPIO_Port->ODR %= SPI1_CS_Pin;
 delay_us(50);
 spi_transfer(&reg, 1);
 spi_transfer(&value, 1);
 delay_us(50);
 SPI1_CS_GPIO_Port->ODR |= SPI1_CS_Pin;
 delay_us(200);
}

You can see that after setting SPI1_CS_Pin low there is a 50us delay. (Eventually I want to see if this can be removed, but first I need to mirror the Arduino code functionality to get this to work)

When I look at this with my logic analyzer, I am seeing this:

As soon as CS goes low, so does CLK. This doesn't make any sense to me because they are completely independent of each other. This causes an issue with the data. I am expecting the first byte to be 0xBA (10111010), but instead it is 0x5D(01011101)

The equivalent output on the Arduino looks like this:

 

I just set CS to low, without an SPI transaction the same thing occurs:

 

However, this seems to begin acting normally after the first "write":

 

I thew a 10K pull up resistor in there, and it's still being drawn down.

[gbm]

And what's THIS supposed to be?

SPI1_CS_GPIO_Port->ODR %= SPI1_CS_Pin;

-> looks like a funny error, clearing the CS_Pin and all higher-numbered pins of a port.

I guess you want to implement SPI in software, right? Not a good idea with SPI hardware peripheral available.

BTW, do not use ODR for changing output pin state. Use BSRR and BRR:

SPI1_CS_GPIO_Port->BRR = SPI1_CS_Pin;

[jagauthier]

No, I don't want to implement SPI in hardware. I may have been manipulating the CS pin incorrectly, and I will check that.

[S.Ma]

If this is an STM32 Nucleo board, there is an LED on SCK. You need to disconnect it by solder bridge or jumper depending on the board schematics, if this is the confirmed root cause.

[jagauthier]

I will check that, thanks!