SPI communication error on MCX

[jimmyli]

Hi NXP,

       We are testing SPI communication between MCXA153 and MCXC142, but it is failed.

       Below are the details, hope you can help us to analysis and fix.

       Thanks.

       1>Hardware and software

         FRDM-MCXA153:  running lpspi_interrupt_b2b_master example from SDK V2.16.0, using default LPSPI0

         MCXC142: our own board, using SPI1,  running spi_interrupt_b2b_slave example from SDK V24.12

        IDE: MCXPresso IDE V24.12

         Attachments are the code for master and slave, and the log print from master.

[Habib_MS]

Hello @jimmyli,
Sorry for taking some time to respond to you.

I highly recommend using the latest SDK version from MCXA153 to avoid potential issues. Is there a specific reason you are currently using SDK v2.16 with your MXCA153?

To support you better, could you share the signals generated from the master, preferably on the bus of your custom board? This will help us identify and address any issues more effectively.
BR
Habib

[jimmyli]

Hi Habib,

       Thanks very much for replying.

       1> There is not a special reason to select 2.16.0 version sdk, I just have downloaded before and test by this version.  I will test latest SDK later.

       2> You can find the pin_mux from the two Projects. 

            Master to Slave pin link:

            CLK - CLK

            CS0 - CS0

            MISO - MISO

            MOSI - MOSI

       Thanks again.

[Habib_MS]

Hello @jimmyli,

Could you confirm if the MCXA153 is currently outputting any data?

If so, could you please share the details of these signals with me?

In the other hand, do you see the MCXC142 is outputting data?

BR
Habib

[jimmyli]

Hello Habib,

      Bellow is my testing result for MCXA153 (master) and MCXC142 (Slave).

      1> MCXA153 MOSI and MCXC142 MISO output is right when testing by oscilloscope.

      2>Based on the code provided before, I find that:

         2.1>When A153 SPI transfers one or two bytes, SPI bus will fail to finish.  --SPI in A153 needs buffer to send and receive data, while the buffer is 4 words.

         2.2>MCXC142 will re-send datas to A153 (master) , but from master printfing and MISO pin testing,  the datas are matched, but not the txbuff data from slave (different to master txbuff) , they are the datas from master txbuff.

        eg: master_txbuff[4] = {0x66,0x66,0x66,0x66};

                  slave_txbuff[4] = {0x55,0x56,0x57,0x58};

               When master send one master_txbuff[n] to slave, then slave send one slave_txbuff[n] to master; after finishing transfer, master printfs the receive datas, they are {0,0x66,0x66,0x66}         --first time transfer

{0,0x66,0x66,0x66}         --second time transfer

{0x55,0x66,0x66,0x66}   --third time transfer

{0x55,0x66,0x66,0x66}   --fourth time transfer

              That is so strange.

Hope you to check again.

Thanks very much.

[Habib_MS]

Hello @jimmyli,
I checked the codes and the strange issue is by part of the Master, I tested the slave code with the example spi_interrupt_b2b_master without  any changes and is working correctly, I will check the Master's code in more detail and I will come back to you as soon as possible.
BR
Habib

[jimmyli]

Hello Habib,

      Below is my new update for testing, hope you can verify and provide the solution.

1>Hardware

   FRDM-MCXA153   using LPSPI0 in master mode

   FRDM-MCXC242  using SPI1 in salve mode

2>Software

2.1>demo projects

   FRDM-MCXA153:  SDK_2.16.000_FRDM-MCXA153/lpspi_interrupt_b2b_master

   FRDM-MCXC242: SDK_2.16.000_FRDM-MCXC242/spi_interrupt_b2b_slave

2.2>source code

    FRDM-MCXA153:  replaced by lpspi_interrupt_b2b_master.c in attachment

    FRDM-MCXC242: replaced by spi_interrupt_b2b_slave.c in attachment

    Notes: Other code in projects aren't be changed !

2.3>Test steps

      Firstly, linking SPI from A153 to C242;

      Then, compiling two projects and downloading to boards;

      Then, opening two UART debug terminals for A153 and C242;

      Then, in uart debug terminal for A153, you can send one char (as 'a' ...) to start test.

      Then, the two uart debug terminals will print debug messages.

3> My findings:

    3.1> C242 will correctly receive the datas sending from A153;

    3.2> A153 will incorrectly receive the datas sending from C242;

          Notes: I tested the MISO signal by oscilloscope, finding that the wareform is matched to the datas received by A153.

    3.3> When the buffer size is changed to 1 or less than 4,  the code for A153 can't work.  

4> My questions:

     4.1> Why C242 can't correctly send the datas to A153 (master) ?

     4.2> Why Buffer size can't be changed to small in A153 ?

     4.3> How to fix the problems ?

5> Debug Log

5.1> A153 (master)

      see the attachment <master log.txt>

5.2> C242 (slave)

      see the attachment<slave log.txt>

Thanks very much.

[Habib_MS]

Hello @jimmyli,

Could you run the master's code with the modification of setting this function to false? This change is intended to alter the behavior of the Chip Select:

BR
Habib.

[jimmyli]

Hi Habib,

      I have verified as your suggestion, but it has no effect.

      Can you help to test the example code provided before, and analyse the reason.

      Thanks very much.

[Habib_MS]

Hello @jimmyli,

Due to not having the MCXC242, I tested your code on the MCXC444, but I was still able to replicate your issue:

Upon verifying the functionality of the example called "spi_interrupt_b2b_master", I observed the following:

The Chip Select must be in IDLE during each data transfer. However, when checking the signals with your example, the Chip Select remains low, which causes the issue:

Therefore, by modifying your master's code as follows:

Both codes work correctly:

Could you verify that the Chip Select functions as expected, similar to the previous frame?

BR
Habib.

[jimmyli]

Hi Habib,

       I have verified the code as your suggestion.

       1>Master point:

          LPSPI_SetPCSContinous(EXAMPLE_LPSPI_MASTER_BASEADDR, true); 

          modified to

          LPSPI_SetPCSContinous(EXAMPLE_LPSPI_MASTER_BASEADDR, false); 

          other codes aren't modified.

          Slave point:

          srcBuff[i] = i ;  --> srcBuff[i] = (i + 0x10);   --to be checked clearly.

       2>Test result

           Slave can receive datas from master correctly, while master can't receive datas from salve correctly.

           See attachments.

       3>Question

           3.1 why changing pcs mode from true to false affects master receiving the data ?

           3.2 the sequence of received datas from slave  is wrong, what's the reason ?

       Thanks very much.

[Habib_MS]

Hello @jimmyli,

In order to support you better, could you share the chip select functionality using an oscilloscope or logic analyzer when transmission occurs?

      3.1 why changing pcs mode from true to false affects master receiving the data ?

           3.2 the sequence of received datas from slave  is wrong, what's the reason ?

The issue could be related to the CPHA configuration. As mentioned in Chapter 35.5.7, "SPI Clock Formats," in the Reference Manual, when CPHA is configured to 0, the chip select must be idle between transfers.

For this reason, changing the chip select mode modifies the response of the MCXC142.

BR

Habib

[jimmyli]

Hi Habib,

       Thanks for your help.

       I recorded the slave data wave using oscilloscope, and find that the data wave is same to the data received by master. So, I am sure that the issue is in slave.

       Then, I changed the code shown as below, and solve the problem.

       Previous:  --in spi intterupt service

     if(SPI_GetStatusFlags(EXAMPLE_SPI_SLAVE) & kSPI_TxBufferEmptyFlag)

       Now:  --restrict the txIndex

      if((SPI_GetStatusFlags(EXAMPLE_SPI_SLAVE) & kSPI_TxBufferEmptyFlag) && (txIndex < BUFFER_SIZE))

      But I find that in slave: 

       1>when txIndex isn't restricted, only judging rxIndex (<BUFSIZE), then  txIndex will increase to 6, while master will receive error data.

      2>when txIndex is restricted at the same time, then both will receive correct datas.

      Do you have some tips about this ?

      Thanks again.

[Habib_MS]

Hello again @jimmyli,

I am glad to hear that it is working as expected. I do not have some tips.

Also, if you experience any issue do not hesitate to let me know.
BR
Habib

[jimmyli]

Hi Habib,

      Thanks very much for your testing.

      I will verify the code as you provided again, and give a feedback soon.

[jimmyli]

Hello Habib, Ok, I will try it as your seggestion. I'm out of office now, and will try it on sunday. Any update , I will give a feedback ASAP. Thanks.

[jimmyli]

Hi Habib,

       Thanks very much for your help.

       Waiting for your good news !