About EIM parameter of EIM_CSx_B Valid to EIM_OE_B Valid in MX6DL.

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

About EIM parameter of EIM_CSx_B Valid to EIM_OE_B Valid in MX6DL.

ソリューションへジャンプ
6,187件の閲覧回数
keitanagashima
Senior Contributor I

Dear Sir or Madam,

[Environment]

Boot: Parallel NOR Flash (EIM_CS0)

[Issue]

Refer to Table 43. EIM Asynchronous Timing Parameters Table Relative Chip to Select in IMX6SDLAEC(Rev.3.0).

There is below description.

"WE35" : Max "3 + (OEA - RCSA)"

My customer set the OEA = 0 and RCSA = 0.

So, It should become WE35 = Max 3 [ns].

But, my customer observed WE35 = 20 [ns] with 1st access on custom board.

[Reproduce Steps]

I reproduced this issue following steps on SABRE-AI.

1. Start-up the SABRE-AI from Parallel NOR.

2. Measured 1st clocks of CS and OE.

3. You can see the 20 [ns] delay. 


[Question 1]

Why was WE35 = 20 [ns] observed with 1st clock?

[Question 2]

Refer to OEA bit of EIM_CSnRCR1 field descriptions in i.MX6SDLRM(Rev.1) (P.1043).

There is description of "If EIM_BOOT[2] is 1, the reset value for EIM_CS0RCR1 is 0b010".

Could you tell me the external pin connected with "EIM_BOOT[2]"?

Keita

ラベル(7)
1 解決策
5,045件の閲覧回数
jiri-b36968
NXP Employee
NXP Employee

Hi Keita,

here is explanation why you can see two different delays between /CS and /OE:

  1. Power Up the board - POR
  2. BootROM code run.
  3. Booting from NOR selected. Default setting of EIM for CS0 is used -> OEA = 0b010 -> 2 EIM clocks not-muxed. 15ns (not 20ns which could indicate Muxed mode).
  4. Image in NOR configure EIM to OEA = 0b000. No delay after new configuration (not at 2nd assert of /CS, but later).

So observed behavior is correct.

/Jiri

元の投稿で解決策を見る

0 件の賞賛
返信
46 返答(返信)
2,676件の閲覧回数
gusarambula
NXP TechSupport
NXP TechSupport

Just to clarify, you are using an i.MX6S processor and the 20ns delay occurs only on the first clocks? From what I understand the delay is beyond the expected maximum only on the first events.

As for your second question, EIM_BOOT[1:0] are internal chip signals and are fixed. Signals that are mapped to GPIO pins for override are listed on table 8-9 of the i.MX6S Reference Manual Rev 1.

In table 6-2 of the Reference Manual you may see that EIM_BOOT[1:0] bits correspond to DSZ[1:0] bits of the EIM_CS0GCR1 register. The reset values are given and cannot be changed. In case you wish to configure these you would need to change the register after reset.

0 件の賞賛
返信
2,676件の閲覧回数
keitanagashima
Senior Contributor I

Hi, gusarambula

Thank you for your reply.

>Just to clarify, you are using an i.MX6S processor and the 20ns delay occurs only on the first clocks?

>From what I understand the delay is beyond the expected maximum only on the first events.

Yes. This phenomenon occurred only on the first clocks (events).

(i.e. There is no problem in the waveform after 2nd clocks.)

But, 20ns delay had exceeded the i.MX6SDL's spec "WE35".

So, my customer was worried with the specification violation.

Keita

0 件の賞賛
返信
2,676件の閲覧回数
jamesbone
NXP TechSupport
NXP TechSupport

Hello Keita San,

Are you using the SDK to test it? or do you think you can share the piece of code regarding the first event,  I am thinking the problem it is related to the way the register settings or the flag status check, maybe a flag that it is already set and never clear after the first event?.

Do you think your customer can test it using the SDK in case you reproduced the issue cn you please share the steps.

0 件の賞賛
返信
2,676件の閲覧回数
keitanagashima
Senior Contributor I

Dear jamesbone,

Hello.

[Steps on SABRE-AI]

I tested it on i.MX6 SABRE-AI and used L3.0.35_1.1.0.

1. Write the Linux image (bootloader) to Parallel NOR Flash.

2. Power On.

3. Measure on Parallel NOR (Pin#32) [= EIM_CS0] and Parallel NOR (Pin#34) [= EIM_OE] on SABRE-AI.

4. I was able to see the this issue.

Reproduced on customer's board is same.

Best Regards,

Keita

0 件の賞賛
返信
2,676件の閲覧回数
gusarambula
NXP TechSupport
NXP TechSupport

This problem is probably related to the way the registers and flags are set on the driver and that’s why it’s appearing only on the first events.

Even if it’s out of the datasheet parameters it shouldn’t cause any functional issue other than that first added delay. Are you encountering any functional issue other than this?

2,676件の閲覧回数
keitanagashima
Senior Contributor I

Hi gusarambula,

>This problem is probably related to the way the registers and flags are set on the driver and that’s why it’s appearing only on the first events.

Sorry. I couldn't understand well.

Let you clarify why occurred 20[ns] delay regardless OEA=1 && RCSA=0.

Best Regards,

Keita

0 件の賞賛
返信
2,676件の閲覧回数
gusarambula
NXP TechSupport
NXP TechSupport

I had some feedback on this issue:

From the u-boot, there is a setting in weim_norflash_cs_setup() in mx6q_sabreauto.c

     writel(0x0a020000, WEIM_BASE_ADDR + 0x008);

which means RCSA is 0, OEA is 0.   //EIM_BOOT[2] gives 2 cycles

After entering into kernel, there is another setting in mx6q_setup_weimcs() of board-mx6q_sabreauto.c

     writel(0x1C022000, nor_reg + 0x00000008);

which means RCSA = 0, OEA = 2.         //kernel should be 2 cycles

May we know which stages you set these values and at which stages is this delay being measured?

0 件の賞賛
返信
2,676件の閲覧回数
keitanagashima
Senior Contributor I

Dear gusarambula,

Hello.

Please send me your answer as soon as possible.

Many days have passed about this SR from my first question (Jun-2).

Best Regards,

Keita

0 件の賞賛
返信
2,676件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

Employee

Hi,

I checked boot rom. After fast look to code, I cannot see any changes to EIM_CS0RCR1 (use preset values).

But here can be another possibility, EIM_WIAR[ERRST] - first fetch access will be pended until device will be ready.

Regards,

Jozef

2,676件の閲覧回数
keitanagashima
Senior Contributor I

Dear Karina,

Thank you for your reply.

>I checked boot rom. After fast look to code, I cannot see any changes to EIM_CS0RCR1 (use preset values).

OK. I got it.

>But here can be another possibility, EIM_WIAR[ERRST] - first fetch access will be pended until device will be ready.

A user can't set the EIM_WIAR[ERRST] register at the ROM boot-up.

And, default setting of EIM_WIAR[ERRST] was RDY_INT After Reset Disable.

Is this register cause of the problem?

Does it make this register Enable in internal boot ROM?

Best Regards,

Keita

0 件の賞賛
返信
2,676件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

cyborgnegotiator please continue with the  follow up.

0 件の賞賛
返信
2,676件の閲覧回数
keitanagashima
Senior Contributor I

Dear Karina and Jozef,

Do you have any update?

Keita

0 件の賞賛
返信
2,676件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

Jozef Maslik any update?

0 件の賞賛
返信
2,676件の閲覧回数
keitanagashima
Senior Contributor I

Dear Karina and Jozef,

Do you have any update?

Please send me your answer as soon as possible.

Keita

0 件の賞賛
返信
2,676件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

cyborgnegotiator do you have an advance?

0 件の賞賛
返信
2,676件の閲覧回数
cyborgnegotiato
Senior Contributor II

jiri-b36968, vilemzavodny-b50857 could you help?

Jozef

0 件の賞賛
返信
2,676件の閲覧回数
jiri-b36968
NXP Employee
NXP Employee

Hi Keita/Jozef,

checked BootROM code. There is not anything which should cause the issue. WE35 can be longer in the case of multiplexed mode, but it is not the case. Maybe something in EIM controller itself. Asked designers to help with it.

/Jiri

2,674件の閲覧回数
keitanagashima
Senior Contributor I

Dear Jiri and Jozef,

Thank you for your reply.

Have you reproduced this problem?

I and my customer reproduces the problem on SABRE-AI and custom board.

Keita

0 件の賞賛
返信
2,674件の閲覧回数
karina_valencia
NXP Apps Support
NXP Apps Support

jiri-b36968  can you add the status of this case?

0 件の賞賛
返信
2,674件の閲覧回数
jiri-b36968
NXP Employee
NXP Employee

Hi Keita,

The issue is registered as designers request in our system and designers are working on it. Their manager is also informed.

/Jiri

0 件の賞賛
返信