MPC5644A DSPI CSSCK behaviour

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MPC5644A DSPI CSSCK behaviour

ソリューションへジャンプ
3,969件の閲覧回数
kaifalkenberg
Contributor I

Hello,

I have a question regarding the DSPI controller in the MPC5644A. I would like to configure a delay between the assertion of the chipselect and the first edge of SCK. When changing CSSCK[0:3] to something >0 I do indeed see a delay between the assertion of PCS and the first edge of SCK. But the same delay is now also present between each 8bit frame! Same goes for ASC[0:3].

Any ideas on what I might be missing? Or is this intended behaviour?

Thanks for your support

0 件の賞賛
返信
1 解決策
3,925件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

tCSC will be the always as you can see on the screenshot below:

davidtosenovjan_0-1677572661638.png

 

元の投稿で解決策を見る

0 件の賞賛
返信
5 返答(返信)
3,943件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

Yes, it is correct behavior, all these times are supposed to be there. The only time disappearing between frames in case continuous transfer, it is tDT.

0 件の賞賛
返信
3,935件の閲覧回数
kaifalkenberg
Contributor I

From the RM, chapter 30.9.5.2:

"The PCS to SCK delay is the length of time from assertion of the PCS signal to the first SCK edge."

CS is asserted the entire time..

0 件の賞賛
返信
3,926件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

tCSC will be the always as you can see on the screenshot below:

davidtosenovjan_0-1677572661638.png

 

0 件の賞賛
返信
3,946件の閲覧回数
kaifalkenberg
Contributor I

bump

0 件の賞賛
返信
3,968件の閲覧回数
kaifalkenberg
Contributor I

  Here are two screenshots illustrating the issue. Between both screenshots only CSSCK has been changed.

RigolDS0.png

RigolDS1.png

 

0 件の賞賛
返信