S32K144 SPI communication problem with other chips

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K144 SPI communication problem with other chips

1,947 Views
liuqimin
Contributor IV

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

liuqimin_0-1628081970331.jpeg

   Use Freemaster to observe the data read back from the MCU SPI port..

  Could a wrong MCU setting cause this situation?

  Best regards!
  QiminLiu

0 Kudos
6 Replies

1,934 Views
adriantudor
NXP Employee
NXP Employee

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. 

adriantudor_0-1628249093622.png

 

Best regards,

Adrian

 

1,924 Views
liuqimin
Contributor IV

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:

liuqimin_0-1628327539478.jpeg

  The SPI sending sequence of the chip:

liuqimin_1-1628327588612.jpeg

 

  Best regards!

  Qimin

 

 

0 Kudos

1,908 Views
mariuslucianand
NXP Employee
NXP Employee

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. 

mariuslucianand_0-1628489349529.png

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

 

 

1,880 Views
liuqimin
Contributor IV

Hi @mariuslucianand 

  Thank you for your reply!

   Indeed, due to the sequence of chip data transmission, the sequence needs to be reversed when the MCU side outputs data.

  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.
For example, 0xED80EC00000004, because it needs to be sent in the same module in Simulink, split it into 0xED00000080 and 0xEC00000004 or into 0xED80000000 and 0xEC00000004,
None of the chips can return correct data. It seems that the data is split incorrectly in this way. (According to the rules of the chip, 0XED, 0XEC are the address of the chip register, which needs to be placed in the high order. The data sent after the address)
Are there any good suggestions to send this data?

 Best Regards!

 Qimin

Tags (1)
0 Kudos

1,845 Views
mariuslucianand
NXP Employee
NXP Employee

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.

mariuslucianand_0-1628842329994.png

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

0 Kudos

1,832 Views
liuqimin
Contributor IV

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.

liuqimin_0-1628945825441.png

    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:

liuqimin_1-1628946008293.png

    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.

liuqimin_2-1628946160428.png

   The following figure shows the structure of TMC_CONTROL_CHIP forwarding data.

liuqimin_3-1628946229386.png

 

    Best Regards!

    Qimin

 

0 Kudos