2020-06-23 07:20 AM
Hi there,
Variations of this question have been asked before, but I have had no luck so far.
I am attempting a very simple setup where I am using SPI to write to a display, where the screen does not talk back. I am using SPI1 on the STM32F091 and cannot get any signals on the CLK and MOSI lines. I am using other GPIO for CS, RST, and DC. I simply want to use the SPI drivers to control the CLK and MOSI, I am doing the rest manually.
I used CubeMX to generate code and am still not getting anything. I am sure it is a stupid control bit somewhere that needs to be flipped, but I am at a loss.
Here are the generated Init functions:
Here is my main. I am simply sending one byte over and over looking for signals on the line.
Here is the state of my SPI1 registers right before I transmit over SPI.
It seems like the NSS and NSST have caused a lot of problems for people but I have NSS pulse disabled. I admit that I dont have the greatest understanding of what NSS and NSST are doing.
Any help is appreciated!
Solved! Go to Solution.
2020-06-23 08:37 AM
> Is a combination of my CR bits making me actually receive bits instead of transmit?
When you send a byte over SPI, you also receive a byte. This is not unexpected. That's just how SPI works in two-direction mode.
> I dont see the DR register change from 0 at all.
The DR register is not a memory cell. It's a register to send data out and receive data from. If you write something to DR, you should not expect to be able to read it back. In your setup, you write MOSI and read MISO.
> And RXE changes from 0 to 1 after I step over that line. That seems backwards?
By reading SPI->DR in your debugger, you are resetting the RXNE bit. Probably not what you want.
I think it all could be explained by a hardware error. If you set the pins as GPIO, can you toggle them?
2020-06-23 07:51 AM
What hardware is this? Are the SCK pins connected to the point where you observe then? Aren't they pulled by something else, e.g. some onboard connection if you use Nucleo or Disco?
Read out and check/post the relevant GPIO registers' content.
Write to SPI_DR in the debugger and observe.
JW
2020-06-23 07:54 AM
The code and register dump looks flawless to me.
2020-06-23 08:23 AM
Hi JW, thank you for your response. Hardware is just a STM32F091 micro on a custom PCB. I am holding my probe directly on the SCLK line.
My GPIO registers are below. The PA5 and PA7 pins (CLK and MOSI) look like they are correctly set up for alternate functions.
Interestingly enough when I call the SPI_Write function and eventually get to where it puts the data into DR:
I dont see the DR register change from 0 at all. But the SR does change when I step over that line:
My TXE bit stays 0x01 the entire time which seems odd. And RXE changes from 0 to 1 after I step over that line. That seems backwards? My FIFO reception level bits change as well. Once again this seems backwards?
Is a combination of my CR bits making me actually receive bits instead of transmit? This seems very weird to me.
2020-06-23 08:26 AM
Thanks for the reply Knarf! If you read my reply to JW above it seems like my receive bits in the SPI register are being altered when I "send" data. It seems like somehow something is backwards. I am wondering if a combination of CR bits is putting me in a weird state. If I am "receiving" this would explain no clock generation and activity on the MOSI line.
2020-06-23 08:37 AM
> Is a combination of my CR bits making me actually receive bits instead of transmit?
When you send a byte over SPI, you also receive a byte. This is not unexpected. That's just how SPI works in two-direction mode.
> I dont see the DR register change from 0 at all.
The DR register is not a memory cell. It's a register to send data out and receive data from. If you write something to DR, you should not expect to be able to read it back. In your setup, you write MOSI and read MISO.
> And RXE changes from 0 to 1 after I step over that line. That seems backwards?
By reading SPI->DR in your debugger, you are resetting the RXNE bit. Probably not what you want.
I think it all could be explained by a hardware error. If you set the pins as GPIO, can you toggle them?
2020-06-23 08:46 AM
> I am holding my probe directly on the SCLK line.
What do you mean by "SCLK line"?
Hold it *directly* on the mcu's pin. Disconnect any target (cut lines if needed, remove chips). Check for shorts to (neighbouring pins/tracks) and bad solder joints.
> If you set the pins as GPIO, can you toggle them?
+1
JW
2020-06-23 09:05 AM
Thank you for the reply TDK! I did not know you receive a byte when you send. I can toggle both pins fine. Weirdly enough, and I can't really explain it but it just started working. I wish I could give you a reason why but I am baffled. I will go with you have the magic touch. Thanks for your help.
2020-06-23 09:07 AM
Thanks for your reply Jan. It actually just started working and I am not sure why. I'm assuming I was an idiot somewhere along the line. Regardless I appreciate your help a ton. Thanks!