SPI baud rate

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPI baud rate

Jump to solution
3,251 Views
rafaeldalazen
Contributor II

Hi,

I'm trying to send through the UART the data that I am acquiring in the SPI communication. At this moment I'm using KL26Z128 and trying to take data from the L3GD20 gyroscope. In the SPI communication I'm getting the data and putting in a variable, and after  I try to send via UART, but I'm not having success! The SPI data varies in time (I can see it in the oscilloscope), but the data in my serial terminal do not change, remain static in time. After several attempts without success, I began to think about the UART and SPI frequencies ... must they be equals?? In my case, the UART frequency is 19200 bps and SPI frequency is something around 15625 bps.

Could someone help me?

Thanks in advance,

Rafael

Tags (3)
1 Solution
2,357 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Omar:

Indeed, the signals look correct. I am getting out of ideas but I think this explanation in the Reference Manual might be the cause of your issue:

pastedImage_0.png

Try with a dummy read from the data registers (DH:DL) before calling your spi_read() function (or inside the function but before spi_write).

According to the manual new data is lost if you did not read the previous incoming data, which may be why you only see '0'.

Let me know how it goes.

Regards!

Jorge Gonzalez

View solution in original post

10 Replies
2,357 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Rafae Dalazen:

The SPI and UART frequencies are independent, but of course if the data is first received from SPI and then sent with UART, then you have to wait until receiving more data because SPI frequency is lower.

Have you checked with the oscilloscope if there is any activity in the UART TX pin?

Maybe you did not configure the pin mux setting to take the UART function. Also make sure that the UART baudrate matches the setting in the terminal.

I would first test the UART part without the SPI interface, just to have it working, then you can test the two interfaces together.

If you still meet issues, please let us know what kind of code you have (baremetal, RTOS, IDE, KSDK or not, etc) and if possible share your project.


Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

2,356 Views
omarvallecasas
Contributor III

Hello Jorge,

  My name is Omar and I work with Rafael in this project. We tested UART0 with I2C0 for FXOS8700, getting it data and sending to computer using the UART0 interface. It worked fine, instead when when configuring SPI0 for polling we are obtaining signal at KL26 MISO, but when we look for the UART_TX pin, only apears zero (when sending the SPI0_DL register by UART0). As you would see we are using Baremetal code in Codewarrior 10.6. Here we send our code.

Thanks in advance,

Omar Valle Casas

0 Kudos
2,356 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Omar:

Sorry for the delay.

As you describe it the problem is not the UART, but the SPI communication, i.e. the interface between the KL26 and the gyroscope. I looked at your code and it seems correct to me but I am not familiar with that sensor device so I can't be sure.

First thing I would check is the phase (CPHA) and polarity (CPOL) settings to see that they match the ones expected by the SPI slave.

Regards!

Jorge Gonzalez

2,356 Views
omarvallecasas
Contributor III

Hello Jorge,

Thanks for your quick answer. We tested changing the 4 combinations of phase (CPHA) and polarity (CPOL) settings, and it remained the same issue. The interesting thing is that signal measured at MOSI microcontroler pin (master), is receiving well gyroscope values, but it doesn't appears at UART pin or UART terminal at PC. We really don't know what we're missing. Maybe SPI read protocol timing from Slave would help to realize our problem.

Regards,

Omar Valle

SPI Read.jpg

0 Kudos
2,356 Views
omarvallecasas
Contributor III

Hi,

Here you have two images to illustrate more. The first is SPI SCLK with SPI MISO, and the second one is SPI SCLK with UART Pin. As you can see, there's no data at UART Pin, different to MISO behaviour.

Thanks really for your time,

Omar Valle

TEK0001.JPG

TEK0002.JPG

0 Kudos
2,356 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Omar:

Before scanning the UART TX pin it would be better to debug and confirm what is actually received by the SPI module, by reading the SPI data register (e.g. storing the data register in a variable). Watching a signal in the MISO pin does not necessarily mean that SPI transactions are working as expected.

The first screen is only the MISO pin. Can you also show the MOSI pin and Slave Select pin? You can compare the 4 signals you see on the pins (MISO, MOSI, SPSCK, SS) with the expected frame as in the picture you posted above.

Regards!

Jorge Gonzalez

2,356 Views
omarvallecasas
Contributor III

Hi Jorge,

Here it is MOSI signal with SCLK (Fig.1), and SS with SCKL (Fig.2). For me it seems fine, maybe you disagree. I already tested store in a variable for later visualization of data, but only appeared 0.

I wait for your comments.

Regards

Omar Valle

0 Kudos
2,358 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Omar:

Indeed, the signals look correct. I am getting out of ideas but I think this explanation in the Reference Manual might be the cause of your issue:

pastedImage_0.png

Try with a dummy read from the data registers (DH:DL) before calling your spi_read() function (or inside the function but before spi_write).

According to the manual new data is lost if you did not read the previous incoming data, which may be why you only see '0'.

Let me know how it goes.

Regards!

Jorge Gonzalez

2,356 Views
omarvallecasas
Contributor III

Hello Jorge,

It works!!!!!! Thanks a lot. We were having a overrun issue. Thank you so much. Now, Callibration...

Best regards,

Omar Valle

and

Rafael Dalazen

2,356 Views
omarvallecasas
Contributor III

Sorry, Images (Fig.1 and Fig.2)

TEK0003.JPG

TEK0004.JPG

0 Kudos