Hello:
Today I tested the SPI communication between S32K144 and other chips, and found that the communication data between the MCU and the chip's SPI interface is very strange. MCU sends data cyclically: 0X7F00000000 to the chip, read the value of 0X7F register. According to the chip technical manual, the normal situation should be that the MCU reads back the version number of the chip. But the data received by the MCU SPI port is still the data I sent out (0X7F00000000). This situation is very strange, it seems that the MCU cannot read the value of the chip register? But why does the SPI port return data again?
The CPOL CPHA of the MCU is set according to the timing of the SPI interface of the lower chip
Use Freemaster to observe the data read back from the MCU SPI port..
Could a wrong MCU setting cause this situation?
Best regards!
QiminLiu
Hi @liuqimin ,
From my experience, I know that when the SPI master doesn't transmit the data in the right format, the slave SPI device mirror your data or sends some default data.
I don't know what SPI device did you connect to S32K144, but if I take a look at the SPI characteristics data snapshot, I think you have to check this checkbox (continuous transfer). If this functionality is not activated, the SPI master device will send bursts of 8-bit data and the CS pin will be enabled for each 8bit data, not for all 40 bits, as you want.
Best regards,
Adrian
Hi Adrian
Thank you for your reply!
Yes, after checking "Continuous Transfer" in the MCU's SPI interface settings, the MCU can receive the data returned by the chip. But there is still a problem. The order of the data returned by this chip seems to be reversed. For example, after MCU sends 0X0000000000, according to the chip manual, it should receive "0x8300006020" returned by the chip, but the data displayed on Freemaster is "0x2060000083". Is this normal?
The SPI data structure of the chip is as follows:
The SPI sending sequence of the chip:
Best regards!
Qimin
Hello @liuqimin,
Yes, the order of the bytes might be normal, depending on the endianness type of the device you are using. You can reverse the bytes using the Byte Reversal block in the Embedded coder library blocks.
Also, make sure that the commands you are sending from the S32K144 don't need to be sent reversed. Right now you are sending the 0x00000000 and it is fine. But if it were to send the 0x00000001 and the SPI device actually waits for the 0x01000000, you have to use the byte reversal for the input of the SPI send.
Hope this helps,
Marius
Hello @liuqimin ,
Now I found another problem when I proceeded to the next test. When the MCU sends a 56-bit data to the chip, due to the limitation of the chip, it needs to be split into two data transmissions of 40-bit and 16-bit.
You can send directly from the S32K an array of 7xuint8 bytes in one transfer. Is the target you are using limited waiting only 4xuint8 and 2xuint8 for the described situation?
Can you please explain to me how the data have to be received by the TMC chip?
Also, from a previous screenshot you have attached, looks like the TMC only will alow a minimum of 40 bit transfer.
The only suggestion I have is, if you can, to use a Logic Analyser to "spy" the SPI signals transactions. and maybe from there, we can figure out how to send the data using our blocks in order to have successful communication.
Regards,
Marius
Hello @mariuslucianand
This problem needs to be explained from the hardware structure:
In fact, the hardware consists of 3 parts: S32K_MCU; TMC_CONTROL_CHIP; TMC_DRIVER_CHIP. The three parts of data exchange are transmitted through the SPI interface.
But the data from MCU to TMC_DRIVER_CHIP is not transmitted directly, it needs to be forwarded through TMC_CONTROL_CHIP. The TMC_CHIP SPI interface transmits 40 bits each time (1 byte register address plus 4 bytes of data). In this way, when TMC_CONTROL_CHIP forwards a 40-bit data, it needs to be split into two (one for one Byte plus 1 4 byte data).
For example, TMC_CONTROL_CHIP forwards 0x8000000004 and splits it into 0x80 and 0x00000004. Because the TMC_CONTROL_CHIP forwarding register address is 0xEC (low), 0xED (high), the data sent by the MCU to TMC_CONTROL_CHIP is 0xED00000080 and 0xEC00000004. The data forwarded by TMC_CONTROL_CHIP to TMC_DRIVER_CHIP should be 0x8000000004.
Now send these two data cyclically from MCU to TMC_CONTROL_CHIP, one every 10 milliseconds. Observe the data of the SPI interface with a logic analyzer:
You can see that the MCU sent the data correctly, and the TMC_CONTROL_CHIP also responded correctly
There is a suspicious point here: I hope to send data only once within 10 milliseconds, and the MCU will send this data repeatedly when the results are observed with the logic analyzer until the time is up to 10 milliseconds. Can this be modified?
Use the logic analyzer to observe the data of the TMC_CONTROL_CHIP SPI interface: there is no data output, as if the forwarding register has not received data.
The following figure shows the structure of TMC_CONTROL_CHIP forwarding data.
Best Regards!
Qimin
