S32K344 LPSPI cs is active too long

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

S32K344 LPSPI cs is active too long

995 Views
esmax
Contributor III

Hello. I am trying to work with SPI but have a problem . SPI transmission is too long. CS stays in active state after data is transferred. 

esmax_0-1685359817547.png

 

SPI configuration :

esmax_1-1685359960713.png

Has anyone encountered such behavior?

 

Tags (1)
0 Kudos
9 Replies

963 Views
esmax
Contributor III

Hello @VaneB . Thank you for the reply. 

When I disable continuous transfer I have this timings.

esmax_0-1685602469068.png

but I need  CS to be active during transferring all 3 bytes.

I have similar project and SPI configuration is the same but another behavior of CS.

esmax_1-1685602665001.png

 

 

 

0 Kudos

951 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @esmax 

The platform should behave similarly by having the same LPSPI configuration so that the problem may be due to the implementation.

Could you tell me the differences in your projects to verify if this is the reason?

0 Kudos

937 Views
esmax
Contributor III

Actually there are no differences. I read SPI registers during debug. They look correct. 

LPSPI_2/SR, 0x40360014, 0x00000001
LPSPI_2/CFGR0, 0x40360020, 0x00000000
LPSPI_2/CFGR1, 0x40360024, 0x00000001
LPSPI_2/CCR, 0x40360040, 0x27270000
LPSPI_2/CCR1, 0x40360044, 0xFF800303 

According to datasheet there are no any SPI registers that can affect SPI behavior. Am I right ?

It is written that write operation to CCR register overwrites CCR1 but there is no information how CCR1 can be calculated.

0 Kudos

920 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @esmax 

As I mentioned before the platform should behave similarly if it used the same LPSPI configuration for both projects. 

I would like to know if you are using an EVB or a custom board. If you are testing each project on a different board. I would like to discard all possible causes of the problem.

0 Kudos

845 Views
esmax
Contributor III

I am using the same hardware

0 Kudos

782 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @esmax 

Since you are using the same hardware and the same LPSPI configuration in both projects, what must be generating this difference in CS behavior could be another module.

Could you help me with information regarding what other modules each project uses or if you want you can create a case in which you can share your projects with us so we can carry out tests.

0 Kudos

678 Views
esmax
Contributor III

Hello.

I use for the tests next code.

esmax_0-1686646299510.png

I do not change the code . Just size of buffers. As you can see I set up two buffers for transmission. They will be sent during one sequence.

When the size of buffers equal to 1 I have a delay between transferring data and disabling CS is around 15 uS

esmax_1-1686646542464.png

esmax_2-1686646684689.png

 

When the size of buffers is 2 bytes a delay between transferring data and disabling CS is around 12 uS

esmax_3-1686646779708.png

esmax_4-1686646867800.png

When the size of buffers is 3 bytes a delay between transferring data and disabling CS is around 1 uS

esmax_5-1686647009890.png

esmax_6-1686647105424.png

When the size of buffers is 4 bytes a delay between transferring data and disabling CS is around 11 uS

esmax_7-1686647201809.png

esmax_10-1686647541893.png

 

When the size of buffers is 5 bytes a delay between transferring data and disabling CS is around 2.5 uS

esmax_8-1686647343756.png

esmax_9-1686647406882.png

When size of buffers 6 and 7 bytes, delays are the same as for 5 bytes length buffers.

Could you please tell me what can be a reason of such weird behavior of SPI ? 

 

0 Kudos

645 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @esmax 

Could you verify if you have the same behavior with the example SPI_Transfer_S32K344 or Lpspi_Flexio_Ip_Transfer_S32K344?

Also, I notice that your clock is not symmetric, could you share an oscilloscope image of this? 

0 Kudos

976 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @esmax 

Continuous Transfer configures to "keep PCS asserted between frames (as configured by FRAMESZ). A new command word is required to cause PCS to negate. Also supports changing the command word at the frame size boundaries."

If you disable continuous transfer you have the same behavior?

 

B.R.

VaneB

 

0 Kudos