Tool/software:
Hello,
We are experiencing a problem with the SPI interface on our AM4376 where heavy traffic on the SPI bus can result in misreads of data. One of the MCSPI interfaces is connected to an Ethernet switch which we use for configuration and monitoring registers. We are connected to MCSPI4 on the AM4376 and have it configured in master mode with only one slave on the SPI bus. We were running into issues with register values being misread. After performing some tests on the SPI bus, we saw that when there was heavy traffic on the bus, occasionally, some of these SPI messages would interfere with each other.
Our application regularly initiates read commands on the SPI bus to certain registers within the Ethernet PHY. When we would perform multiple SPI reads on other registers, occasionally, one of the scheduled reads would interfere with the SPI read already occurring. Please see below:
To overcome some of these misreads, we have been attempting to read each register multiple times. However, when we read a register repeatedly, occasionally the successive reads will blend into one command where the chip select stays active between all of the data sent. The PHY we are using only accepts one read or write address at a time. The command is made of a read/write byte indicator (0x02 or 0x03 respectively), the address byte, and then the response from the switch. Any other clock toggling after that point while the Chip Select line remains active will be interpreted by our PHY as a request to read/write data from/into the addresses which follow the initial address sent. This is also causing us errors. Please see below.
Is there something that we need to do to ensure that SPI messages that are currently being processed on the bus lines are finished before new messages start? I attempted to turn on the bits to enable the FIFO in the MCSPI controller but this did not seem to change the result.