SLAVE Continuous Tranfer

Back to bugtracker overview.

Type :: BUG
Status :: CLOSED
Assigned to :: Jonny, Doin

In SPI_SLAVE.VHD, if the user does not write a new word (strobing 'wren_i') and the master sends more clocks (i.e., continuous transfer), the slave goes from state 1 to 0, then to state N .. 1 .. 0 again. This causes an error in bit sync, and received data has a 'bit shift' error.


Doin, Jonny Aug 9, 2011
v2.02.0123: to avoid MSb cluttering when a di_req cycle is ignored by the user at the slave parallel input port, MISO will output zeros (others => '0'). The new version is uploaded to the SVN. This code is tested for the 4 spi modes, and verified in hardware. See the scope screen shot:
slave CT with default transfer
Doin, Jonny Aug 8, 2011
The code for v2.02.0122 show a small side effect: if slave data loads are skipped, i.e., if the data requests 'di_req' are ignored, the last data is retransmitted again, but the MSb is set to '1' even if it was '0'. This only happens for skipped load cycles. For normal load cycles, i.e., when data is loaded and 'wren_i' is strobed at each data request 'di_req', transmission is normal.
Doin, Jonny Aug 8, 2011
This bug was discovered by Mateusz Starzycki, who is using the slave core in a project, in continuous transfer mode.
Doin, Jonny Aug 8, 2011
The bug is fixed in version v2.02.0122 of the SPI_SLAVE.VHD core.
The fix consists in engaging continuous transfer regardless of the user strobing write enable, and sequencing from state 1 to N as long as the master clock is present.
If the user does not write new data, the last data word is repeated.
The SVN is updated with the bugfix.

Post a comment:
Login to post comments!

Back to bugtracker overview.

© copyright 1999-2019, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.