Obtaining advertised ECSPI timing on SS_B

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

Obtaining advertised ECSPI timing on SS_B

Jump to solution
25,355 Views
skrap
Contributor IV

Hello,

I'm using the i.MX7d with the linux 4.1.15 2.0.0 GA kernel, with a SPI peripheral connected to ECSPI3.  This is on the MX7D sabre board.  I need to have precise timing on the ECSPI transactions, and having read the reference manual and the datasheet it seems that it should be able to meet my needs.  However, I'm seeing unexpected results.

I need transactions (SS assertions) to occur at 1 MHz, and the SCLK to run at 16 MHz.  Burst width is set to 14 bits.  From the timing diagram in section 4.11.1.1 of the IMX7DCEC Electrical Characteristics document:

pastedImage_1.png

pastedImage_2.png

Given a SCLK at 16MHz, I would expect the CS4 time to be half a SCLK period as advertised, so CS4 should be approximately 32ns.  However, I see a much larger CS4 time: about 220ns:

pastedImage_3.png

What could be causing this discrepancy?  I am not using the PERIODREG register:

# devmem  0x3084001C
0x00000000

I set the ECSPI ipg and per clocks to 48 MHz:

# cat /sys/kernel/debug/clk/clk_summary | grep ecspi3
                      ecspi3_src           1            1   240000000          0 0  
                         ecspi3_cg           1            1   240000000          0 0  
                            ecspi3_pre_div           1            1   240000000          0 0  
                               ecspi3_post_div           1            1    48000000          0 0  
                                  ecspi3_root_clk           2            2    48000000          0 0  

Relevant ECSPI3 registers:

CONREG: 0x00D020F5

CONFIGREG: 0x00000100

How can I achieve the advertised timing on the SS_B pulse width?

Labels (1)
0 Kudos
1 Solution
23,936 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

I got next update:
----------------------------

IC team confirmed that CS4 need 3.5 clk cycle after checking the RTL code , which conforms to the data from customer.

----------------------------

Best regards
igor

View solution in original post

26 Replies
23,860 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Jonah,

  • Can the CS hold time be lowered to the published timing?ANSWER.   Yes, we warranty that number publish
  • If not, will the CS hold time at least be guaranteed to be consistent, given that the TXFIFO is always kept filled? ANSWER. The value that you see, I don´t see any problem to warranty that it is going to be consistent

Saludos,

Jaime

0 Kudos
23,860 Views
skrap
Contributor IV

Hello Jamie,

Thanks for the reply!

  • Can the CS hold time be lowered to the published timing?ANSWER.   Yes, we warranty that number publish

Ok.  I would like to lower the CS time to the published number.  Can you explain how?

Thanks!

0 Kudos
23,860 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Jonah,

This is going to take further time, since we need to escalate the issue to our Apps team, so they can provide the steps to test it exactly to obtain this number,  I do not have an exactly time since it is based on the load of the team. Hope you understand.

igorpadykov, can you please open an internal thread, so the apps team help us, to obtain the steps to reproduced the exact number of the datasheet.?

Best Regards,

Jaime  

0 Kudos
23,860 Views
skrap
Contributor IV

Hi Jamie,

Thanks again for looking into this.  My team is asking for an update.  Do you have any news to share at this point?

Best,

Jonah

0 Kudos
23,855 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

 

I sent to case # 00110978 full copy of internal thread

with latest update.

 

Best regards
igor

0 Kudos
23,855 Views
skrap
Contributor IV

Hello igorpadykovjamesbone‌,

I need an answer on this.  We need to make a call ASAP on a BOM change due to this issue.  It's been a month since I raised this, and I don't think it's unreasonable to expect some sort of reply by this point. 

Please get me your final answer on this issue by Thursday AM at the latest.

0 Kudos
23,855 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

 

I sent this on internal thread


Best regards
igor

0 Kudos
23,855 Views
skrap
Contributor IV

Thanks, igorpadykov‌!

0 Kudos
23,937 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

I got next update:
----------------------------

IC team confirmed that CS4 need 3.5 clk cycle after checking the RTL code , which conforms to the data from customer.

----------------------------

Best regards
igor

23,855 Views
skrap
Contributor IV

Thanks for the update.  Not great news, but at least we know what we're dealing with.  It would be good to issue some sort of update to the timing specification to reflect this fact.

0 Kudos
23,858 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Jonah,

Our Apps team it is doing some research, as soon as we get an update,  Igor, would provide the update. I apologize for the latency response.

0 Kudos
23,860 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jaime 

internal thread

Obtaining advertised ECSPI timing on SS_B 

Best regards
igor

0 Kudos
23,860 Views
skrap
Contributor IV

Thank you, Jamie.  I look forward to hearing the results of your investigation.

Jonah

0 Kudos
23,860 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

for internal thread it is necessary to provide personal data info:

company name and customer e-mail. Could you provide it (one can provide it using service request)

Best regards
igor

0 Kudos
23,860 Views
skrap
Contributor IV

Igor,

I have filed case # 00110978 with this information.

Jonah

0 Kudos
23,860 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

 

I got update:
----------------------------

From the RM I got the folllowing:

 

"The SPI_RDY enables fast data communication with fewer software interrupts. By
programming the ECSPI_PERIODREG register accordingly, the ECSPI can be used for a
fixed data transfer rate."

 

SPI_READY is enabled by DRCTL (bits 17–16 of CONREG), which seem to be at 00 (SPI_RDY ignored) on your register 0x00D020F5

 

The SPI_READY reference is under 10.1.4.4.1 Typical Master Mode.

 

Let me know if this helps!

--------------------------------

 

Best regards
igor

0 Kudos
23,860 Views
skrap
Contributor IV

Hi Igor,

Thanks for the reply.  I am very familiar with this signal, as I use it in some of my other SPI peripherals.  However, I do not have a SPI_RDY signal from this specific SPI peripheral.  (Some SPI slaves emit this signal, but some do not.) 

So, you are saying that I can achieve the advertised timing with a SPI_RDY signal?

Jonah

0 Kudos
23,860 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

datasheet CS4 time to be half a SCLK period depicts as "min". time,

it may be bigger depending on internal latencies caused, for example

linux. One can try with baremetal test to achieve better timings.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
23,860 Views
skrap
Contributor IV

Also, I notice that this SS hold time is exactly the same (within 2 ns) on every single transaction, for millions of transactions in a row.  This makes me worried that this SS hold is a hardware limitation of some kind.  If so, I really need to know ASAP.

0 Kudos
23,860 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jonah

for example time necessary for moving  by A7 core next portion of data from ddr to ecspi fifo

might cause "internal latencies".

Best regards
igor

0 Kudos