- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Today, while I was studying the problem of npuruss-san,
https://community.cypress.com/thread/37205
I encountered an interesting behavior of SPIS.
With this project I'm using a couple of CY8CKIT-044s,
one for SPI_Master and the other for SPI_Slave.
When I call SPIM_PutArray(), the SPI_Slave receives exact
data assigned by SPIM_PutArray().
But after I call SPIS_PutArray() and when SPI_Master
send another transaction, the MISO data sent out from
SPI_Slave is 1 byte off from the data assigned by SPIS_PutArray().
For example, for the first loop, before SPI_Master sends anything,
I put 0D,0C,0B,0A,09,08,07,06,05,04,03,02,01 to SPIS_PutArray().
When SPI_Master sends commands, SPI_Slave sends out
00,0D,0C,0B,0A,09,08,07,06,05,04,03,02
(See attached Oscilloscope Screen Shot)
Naturally, SPI_Master received
00,0D,0C,0B,0A,09,08,07,06,05,04,03,02
although it was expecting to receive
0D,0C,0B,0A,09,08,07,06,05,04,03,02,01.
Then for the next transaction, SPI_Slave prepares sTxBuffer with
F0,E1,D2,C3,B4,A5,96,87,78,69,5A,4B,3C
But SPI_Master receives
01,F0,E1,D2,C3,B4,A5,96,87,78,69,5A,4B
(This 01 seems to be the last byte of the previous PutArray())
Again, SPI_Slave prepare sTxBuffer with
0D,0C,0B,0A,09,08,07,06,05,04,03,02,01
And SPI_Master receives
3C,0D,0C,0B,0A,09,08,07,06,05,04,03,02
(This 3C seems to be the last byte of the previous PutArray())
So I suppose that with this project,
SPIM_PutArray() generates correct data on MOSI pin
but
SPIS_PutArray() generates 1byte data from previous SPIS_PutArray()
before sending the data assigned by current SPIS_PutArray().
Now my question is:
Am I missing something to make SPIS_PutArray() work correctly?
Or is/are there way to reset the data pointer of SPIS
so that I can send correct data?
Attached are my test projects and log/screen copies.
moto
Solved! Go to Solution.
- Labels:
-
PSoC 4 Architecture
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you are using the SPI Slave component (instead of the SCB SPI component in slave mode), look at the documentation of the _PutArray() method. It says:
If using modes where CPHA = 0, call the SPIS_WriteTxDataZero() function before calling the SPIS_PutArray() function.
The SPIS_WriteTxDataZero() method directly writes into the SPI shift register, which otherwise is pre-occupied with a zero.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Without looking at the code: this seems to be expected. When I understand your explanation correctly, your slave just echoes what it received from the master. But only seems to do so after reading one byte.
The master reads data from the slave at the same time it sends out data (or rather: it sends out data with e.g. the falling clock edge, and receives data at the next rising clock edge). So either the slave has data already available as soon as the master starts a transmission, or it can only send it later on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear user_78878863-san,
Thank you very much for your answer.
But I'm afraid that this is not the case, as from SPI_Slave, tx_buffer is filled by SPIS_PutArray()
way before Master starts the transaction. And it is not echo-ing the data from the SPI_Master.
Currently I am suspecting that there is some mis-implementation in SPIS_PutArray().
But also there is quite a good chance that either the original code or my modification
made some mistake(s) to prevent the function working correctly.
Best Regards,
10-Oct-2018
Motoo Tanaka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you are using the SPI Slave component (instead of the SCB SPI component in slave mode), look at the documentation of the _PutArray() method. It says:
If using modes where CPHA = 0, call the SPIS_WriteTxDataZero() function before calling the SPIS_PutArray() function.
The SPIS_WriteTxDataZero() method directly writes into the SPI shift register, which otherwise is pre-occupied with a zero.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear user_78878863-san,
Thank you, you made my day!
I was only referring the API summary and I could not figure out
what SPIS_WriteTxDataZero() was meant for.
Anyway, the program is working perfectly now! (^_^)v
Best Regards,
11-Oct-2018
Motoo Tanaka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
thank you very much! It looks like I've made some good progress.
The changes that I made were
1. use of SPIS_WriteTxDataZero() before each SPIS_PutArray()
2. reading the "fill" buffers with SPIS_ReadRxData() (before I did it only when expected meaningful (not fill) data) and this seems to make a lot of difference.
However I still see some problems on the master side:
Master receives sTxBuffer data from slave in sendCmd(). I expect to receive sFillBuffer data here. However readStatus() receives sFillBuffer while I expect to receive the sTxBuffer data here. Also, as you can see bellow, the received data is somehow shifted to the right by one byte.
What I find interesting is that if I don't use SPIS_WriteTxDataZero() with sFillBuffer then I seem to eliminate the shift problem.
Another strange thing that I noticed is that master doesn't print "SPI master is running" and "iteration 1" when it starts.
I attached my current updated workspace bundle in the top post of the original discussion(SPI bus: non SCB components ).
Thanks again for your help!
Nikolay Pruss
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Nikolay-san,
In general, "multi post" is supposed to be a bad manner.
And I think the discussion in this thread have been completed.
So let's continue the "egg hunting" at your original thread.
Best Regards,
12-Oct-2018
Motoo Tanaka