TI E2E Community
Hercules™ Safety Microcontrollers
Hercules™ Safety Microcontrollers Forum
TMs570 SPI Reception - Compatibility mode
I am using TMS570 processor and currently working on the SPI module. My slave device is HI3593 which is used to interface SPI device with ARINC Bus.I am sending the 32 bit A429 data to the bus successfully using SPI in compatibility mode.Whenever the data is placed on the transmit buffer, the SPI clock is generated and chipselect will be activated. And everthing looks working fine in transmission part.To read the a429 data from the slave device, need to send the Opcode of 8bits for reading 32bit label data. After the opcode received by the slave, the slave is trying to place the data on the MISO bus, but as there is no SPI clockavaiable, the data is not received by master. Can anyone explain the SPI read operation of TMS570 ? Do i need to send the dummy data to generate SPI clock ? During transmission, CSHOLD bit is set while transmitting the data as the slave device requires CS to be low for completing write sequece.similarly read sequece also requires, CS to be low for predefined number of clock cycles (1 cycle = 8 clock pulses).The number of clock pulses depends on the Opcode.
How to set the CS to be low for required number of pulses while reading ?
A read from the HI3593 also requires you to send a "read command" first. This read command is a byte with its MS bit as '1'. This needs to be followed by subsequent transmissions for as many data bytes as required. The sequence would go something like:
thanks sunil. i have done the same as you mentioned above.
I have sent the 4 bytes of ARINC data, then did the loopback to check the receiver part. But i see that 3 bytes out of 4 bytes are received correctly. The Most significant byte of 32 bit word is always read as 0xFF. What might be the problem ?
SPI clock will be generated only when we write some data to the transmit buffer. Is that my understanding correct ? (as you suggested to send the dummy byte).
Yes, a dummy data write to the SPIDAT1 is necessary for the SPICLK to begin. Note that the HI3593 ignores the data on its input when a read command is issued until the chip select is driven High.
You will have to write to SPIDAT1 5 times in order to read 4 bytes: once to send the read command, and then to read 4 bytes. The master must ignore the first byte it receives from the slave when the read command is sent. The HI3593 drives high-Z on its output when it receives a command (first byte after chip select is low).
Thanks for the reply.
I have done the same. But i am facing one issue while receiving the data (Ex : 0xAB546798). Below is the procedure i followed while reading.
1) Send the Read Command.
2) Read the SPIBUF to reset the RXEMPTY .
3) Send the dummy byte
4) Read the Byte received on the MISO pin. (RXEMPTY flag is checked while reading each time) .The received byte is 0xFF instead of 0xAB.
5) The steps 3 and 4 are repeated for next 3 bytes.
6) The final value i read in the program is 0xFFAB5467 instead of 0xAB546798. One byte is missing. What might be the reason ?
I have used oscilloscope and observed that data is correctly sent by the HI3593 IC. i.e The data on the SO pin is correct. If i read SPIbuf one more time, the value is coming correctly.
Let me know what might be the issue.
The SPI module uses a double-buffered TX and RX structure. See figure below.
This is a simplified extract from the block diagram already included in the TRM (figure 24-1 on page 1457).
If both the RXBUF and SPIBUF are empty, the RX EMPTY flag is set in the SPIBUF register (bit 31). In this case, any new data received skips the RX BUF and gets copied directly into the SPIBUF for the CPU to read. If you read this data from the SPIBUF, the RX EMPTY should get set again.
If the SPIBUF already has received data that has not been read out by the CPU, then any new data arriving in the RX shift register will get copied into the RXBUF. The CPU can read out both the unread received data by performing two reads from the SPIBUF in this case. I believe this is the case you are observing.
But Sunil, in my case the first byte received by CPU is 0xFF instead of oxAB. How the above SPI module working is affecting my case ? And if that is the case, what is the solution ?
I will confirm the behavior with the design team and get back to you on this one.
The design team also confirmed the behavior as specified.
Please confirm that you are following the below sequence:
1) Write to the SPIDAT1 register to send the Read Command
- CSHOLD is set so that the chip select stays low
2) Wait for RX INT FLG to be set (or wait for SPI RX interrupt to occur)
3) Read SPIBUF
- Check if RX EMPTY is '1'
- If RX EMPTY is not '1', read SPIBUF one more time. This means that there was already unread data in the SPIBUF from an earlier reception.
4) Write dummy data to SPIDAT1
5) Wait for RX INT FLG to be set (or wait for SPI RX interrupt to occur)
6) Read SPIBUF
- This time the RX EMPTY will read as '1'
7) Repeat the steps 4 through 6 until all bytes have been received
- Configure CSHOLD = 0 on the write to the SPIDAT1 for the last byte read
I have done the same as you mentioned above. But i did not see the correct results.
I have one question here. After sending Read opcode, ideally nothing is available on the SOMI pin. But you have mentioned to wait for receive interrupt or flag to set. What is the reason for reading the buffer here ?( My slave device SO bus wiil be in high impendence state during read command. )
What is the idel state of SOMI bus ?
If i read the SPIBUf after sending the dummy byte for twice continuosly. I can see the result. Any idea why is it happening like this ?
Reply as early possible. Thanks in advance.
See my comments in the message below.
What is the idle state of SOMI bus ?
>> This slave device does not send anything (or tristates) its output (SOMI) when a Read command is sent. The SPI terminals have a default internal pull-up on the microcontroller, which is why you read 0xFF as the byte "received" from the slave after sending the Read command. Please confirm that you are indeed reading from the SPIBUF in this case, or your observations can be easily explained.
>> I need to verify this myself first and then with the design team. If you have no unread data in the RX BUF or the SPIBUF, then any new received data must be copied directly to the SPIBUF. It appears that it is first going through the RX BUF and then the second read is copying it to the SPIBUF.
>> I will get back to you with the confirmation from the design team.
Thanks Sunil. Please check with design team and confirm me.One more question regarding clock modes.The slave device HI3593 works in Mode 0 i.e Data is output on the falling edge of SPICLK and Input data is latched on the rising edge. So the master need to configure to the same mode.when i refer the Table14-2 of TMS570 TRM, the mode 3 is matching with description provided inslave application note. So i set the Polarity to 1 and Phase to 0 in the SPIFMT0 register.Is that correct ? I am confused because the mode number mentioned in the application note is mode 0where as in the TRM it is Mode3.As per my understanding the description provided for the Polarity and Phase bits in the SPIFMT register is not matching with the Table14-2 of TMS570 TRM. Please confirm what is the correct values to be set for this slave.when i set (Pol=1,Phase=0) or (Pol=0,Phase=1)then the data is transmitting to the salve correctly.
I will check the reception again and post my observations.
I read the clocking information wrong earlier. Please excuse me for that. It does capture incoming data on rising edge and transmits data on the falling edge of SCLK. It also requires the master to make the first data ready half-cycle before the first rising edge. This means a clock phase = 1 and a clock polarity = 0.
does the description provided for the clock modes in the table (mentioned above) of TRM is matching with the Polarity and Phase bits descriptions provided for the SPIFMT0 register under control registers section ?
does the master should be set in the reverse mode of slave SPI ? because the mode you mentioned is phase = 1 and polarity 0.
Can you provide me your reply.
Sorry about the delay. The correct clock setting to use for the TMS570 is clock phase = 1 and clock polarity = 0. The SPIFMT register also has the description correct.
You need the first SIMO bit to be output before the slave sees the first rising edge of SPICLK. All subsequent bits are output on the falling edge and incoming bits are captured with the rising edge. This matches the mode 0 of the HI-3593.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.