SPI problem with MTFE on MKS22

[chris_f]

My 25MHz SPI master application (CPOL=0,CPHA=0) is seeing occasional errors in the received data from the slave.

MISO data from the slave to the MKS22 only has ~10ns setup time to the rising clock edge which is less than the specified 16ns required.

Simple solution would seem to be to enable Modified Transfer Format to delay the MKS22 sample of SIN by Tsys.

Setting the MTFE bit in MCR however breaks communication completely.

We're using two 16 bit transfers per transaction and using the CONT flag to make 32 bits per CS.

With MTFE set we get two 17 bit transfers!!

This is the only code change:

// SPI0_MCR = SPI_MCR_MSTR_MASK | SPI_MCR_PCSIS(0b11111) | SPI_MCR_CLR_TXF_MASK | SPI_MCR_CLR_RXF_MASK | SPI_MCR_HALT_MASK;

SPI0_MCR = SPI_MCR_MSTR_MASK | (1<<26) | SPI_MCR_PCSIS(0b11111) | SPI_MCR_CLR_TXF_MASK | SPI_MCR_CLR_RXF_MASK | SPI_MCR_HALT_MASK;

[kerryzhou]

Hi chris_f ,

    What's the SPI slave you are using? Whether that Slave setup time is fixed?   

    You said, with 25MHz SPI master application, KS22 occasional errors in the received data from the slave.

    Could you share the detail errors? eg, check the SPI bus, then give the KS22 received wrong data.

    When use MTFE=1, In this Modified Transfer Format both the master and the slave sample later in the SCK
period than in Classic SPI mode to allow the logic to tolerate more delays in device pads and board traces. These delays become a more significant fraction of the SCK period as the SCK period decreases with increasing baud rates.

    I think, this mode will have more delay, then the setup time maybe more long, why you need to select this mode?

    When you have problems, if your slave can change the CPHA, can you try to change the CPHA =1 in the KS22 and test it? Do you also try to cut down the SPI requency, whether that useful or not?

    BTW, you also can share the MTFE=1 SPI bus wave.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[chris_f]

"What's the SPI slave you are using?"

- It's an Allwinner H5 - can adjust timing as master but not as slave.

"25MHz SPI master application, KS22 occasional errors ... Could you share the detail errors?"

- It's an audio streaming application. We have no way of recording both ends of the stream but have demonstrated that there are data dependant bit errors occurring (approximately 1 in a few million packets) in this interface.

- I suspect the cause of occasional error is setup time (SIN from slave to master -> SCK rising edge)

My understanding from the datasheet was that I could use MTFE mode to delay the MKS22 SIN sample point by one cycle of Tsys (50MHz) or in other words to the next falling edge of SCK.

However, when I set MTFE=1 I get 17 SCK cycles for each write of PUSHR. I didn't expect that!

Below image shows a saved trace (top) with MTFE=0, and a trace with MTFE=1. In both cases there are two writes to PUSHR and FMSZ=15.

[chris_f]

I've added a parity bit to the spi communication and confirmed the error rate at around 1 bit error per 500k transactions without MTFE.

There are two slaves on the bus. I can reduce the error rate a lot (not sure if it's eliminated completely) by removing one of the slaves. This seems to confirm (?) lack of setup time as the problem.

Can someone confirm that MTFE mode is functional in these devices?

[kerryzhou]

HI chris_f,

  Please share your test project, and tell me the IDE you are using.

  I will try to find one KS22 board and test it on my side.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[chris_f]

Hi Kerry Zhou,

Thanks for the offer to look in to it and sorry for the delay. I have been working on using the FlexIO module as an alternative. That might work but MTFE would be better!

I'm working on a large bare metal project built on eclipse and haven't built a standalone test example but any SPI example would show the effect. Set a break point before the first write to PUSHR and modify SPI0->MCR.

- Does setting MTFE=1 change the number of SCK cycles in a burst?

[kerryzhou]

Hi chris_f,

   From the RM, if you set the MTFE, send n+1 bits data, the SCLK should also n+1.

Do you get one more sck, no matter you send how many bits with MTFE=1?

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[chris_f]

The number of bits in a transfer is determined by CTARx -> FMSZ where number of bits = FMSZ+1.

With MTFE=0, I get number of bits = FMSZ+1.

With MTFE=1, I get number of bits = FMSZ+2.

If you look at the scope image I posted earlier, there are two bursts of 17 SCK cycles. Given the 0<FMSZ<=15, getting 17 SCK cycles shouldn't be possible?

[kerryzhou]

Hi chris_f,

  Yes, I have checked your wave, when MTFE=1, it really one more cycle than MTFE=0.

  But from the RM, I didn't find any description that MTFE =1 will be need one more SCK.

  What's the fsck relationship with fsys on your side? Can you test these information:

1. MTFE=1, CPHA=0, fsck = fsys/4

2. MTFE=1, CPHA=0, fsck = fsys/2

3. MTFE=1, CPHA=0, fsck = fsys/3

4. MTFE=1, CPHA=1, fsck = fsys/2

Any different result? You can set FMSZ=15.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[chris_f]

System is running at fsck=fsys/2. I get the same effect (extra SCK pulse with MTFE=1) at fsck=fsys/4 but have not tried fsys/3 or CPHA=1.

I have concluded that the MTF mode will not work for my application due to a problem with the eCSPI module. I'm surprised that this behaviour isn't documented elsewhere.

I have worked around the problem using the FLEXIO module to split my communications on to two SPI buses.

It is simple to set up the equivalent of MTF mode using the FLEXIO module in standard datasheet SPI master settings (RM 47.5.3 SPI Master) and setting TIMPOL to 1 (negative timer edge) in the receiving shift register's SHIFTCTL.

Additionally, the SPI0 errors in my application are eliminated by dropping the baud rate from 24MHz to 16MHz (PBR=0x01). This keeps the SCK high period at 20ns and increases the low period to 40ns allowing sufficient setup time on MISO.

[kerryzhou]

Hi chris_f,

   Thanks for your updated information.

   If you already make the FLEXIO works abotu the MTF mode, then you can use the flexio, that module will be more flexible. The the MTF mode in the SPI module is not very popular, and it is also not very flexible than the flexIO.

    About the SPI0, what's the bus clock you are using? 48Mhz? do you use the CLKOUT to test the clock, whether that is correct or not, just make sure the SPI0 module input clock is correct. BTW, if your PBR is 01, then your baudrate prescaler value is 3, not 2. so if your bus clock is 48Mhz, then SPI0 baud rate is 48Mhz/3=16Mhz, it is correct. Please tell me your bus clock at first.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------