MSPM0G1506: When SPI TX FIFO underflow, it will cause receive wrong data?

Hi Zane,

The description you listed here is related the TX sent out data, not related to RX data.

I recommend you check the input data array, where the data is incorrect. So that we can further analyze the abnormal behavior.

B.R.

Sal

Hi Sal,

My customer is using FPGA implement SPI as controller, which will control 64 CLK and use FIFO to receive 64bit. and use IDLE interrupt to read it out.

please check customers describe:

SPI问题.docx

I try to reproduce customer's issue. I use idle interrupt to read FIFO data, I found some time it will get wrong data.

I send 0x8888(1000 1000 1000 1000), but sometimes I recieve 0x4444（0100 0100 0100 0100）， it seem that shift don't work well.

I attached the project, which can easy to reproduce this issue, but push NRST pin in controller, and see Rxdata in salve debug window. Please help find it out, thanks!

8244.spi_controller_multibyte_fifo_poll_LP_MSPM0G3507_nortos_ticlang.zipspi_peripheral_multibyte_fifo_poll_LP_MSPM0G3507_nortos_ticlang.zip

Best Regards,

Zane

Hi Zane,

I will do some test according to your description here. Hopefully I can update it on next Monday.

B.R.

Sal

Hi Zane,

I have done some test according your feedback, I do not think there has impact if user fill or not fill the data.

I even do not fill any data to TXDATA, all looks good.

From my perspective, using IDLE interrupt is not a good idea, as the IDLE status is set when SPI BUSY goes LOW.

While SPI BUSY will not goes to LOW if there has data in TX FIFO. There might have risks on data handling then miss some Rx data.

I recommend use RX interrupt or Rx Full if you only has the 4x 16-bit data, see the example I verify it works in 1MHz mode without any issues.

LP_MSPM0G3507_SPI_RX_TEST.ZIP

LP_MSPM0G3507_SPI_TX_Master.ZIP

Zane Wei said:

I send 0x8888(1000 1000 1000 1000), but sometimes I recieve 0x4444（0100 0100 0100 0100）， it seem that shift don't work well.

Please check you CS signal, as CS signal is works well, then the shifter register counter will be automatically cleared when CS stay in inactive state. While there has some limitations on CS signal:

B.R.

Sal

Hi Zane,

Updated the test project for your reference: RX_TEST_NEW_ZIP

This project also create the RX received data error when there is no data in TXFIFO (only show up in the first transmission).

Looks like the CSCLR function need be set as 0h to enable automatically clear shifter register when CS is inactive. Details please refer to the email.

B.R.

Sal

Sorry to interrupt, but does "the CSCLR function need be set as 0h to enable [...]" mean that CSCLR operates opposite to what the TRM says? Or is this just an artifact of the empty TX FIFO case?

I use CSCLR, but it's not something that gets exercised very often, so I want to be sure I'm setting it properly.

Hi Bruce,

This is something I am checking internally, I found it looks like an opposite behavior to TRM says.

Will update to this thread when this is confirmed with internal team.

B.R.

Sal

Hi Bruce,

After additional test, the TRM description should be correct. Set CSCLR=1 should enable the auto clear function for shifter counter.

The SPI_ERR_03 description might require a fix.

B.R.

Sal

OK, thanks for checking.