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

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

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

Jump to solution
4,426 Views
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

1 Solution
3,284 Views
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

View solution in original post

0 Kudos
Reply
46 Replies
1,826 Views
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 Kudos
Reply
1,826 Views
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 Kudos
Reply
1,826 Views
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 Kudos
Reply
1,826 Views
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 Kudos
Reply
1,826 Views
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?

1,826 Views
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 Kudos
Reply
1,826 Views
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 Kudos
Reply
1,826 Views
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 Kudos
Reply
1,826 Views
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

1,826 Views
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 Kudos
Reply
1,826 Views
karina_valencia
NXP Apps Support
NXP Apps Support

cyborgnegotiator please continue with the  follow up.

0 Kudos
Reply
1,826 Views
keitanagashima
Senior Contributor I

Dear Karina and Jozef,

Do you have any update?

Keita

0 Kudos
Reply
1,826 Views
karina_valencia
NXP Apps Support
NXP Apps Support

Jozef Maslik any update?

0 Kudos
Reply
1,826 Views
keitanagashima
Senior Contributor I

Dear Karina and Jozef,

Do you have any update?

Please send me your answer as soon as possible.

Keita

0 Kudos
Reply
1,826 Views
karina_valencia
NXP Apps Support
NXP Apps Support

cyborgnegotiator do you have an advance?

0 Kudos
Reply
1,826 Views
cyborgnegotiato
Senior Contributor II

jiri-b36968, vilemzavodny-b50857 could you help?

Jozef

0 Kudos
Reply
1,826 Views
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

1,824 Views
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 Kudos
Reply
1,824 Views
karina_valencia
NXP Apps Support
NXP Apps Support

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

0 Kudos
Reply
1,824 Views
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 Kudos
Reply