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

[keitanagashima]

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

[keitanagashima]

Hi Jiri,

Do you have any update?

More than 5 months have passed about this topic from my first question (2014-Jun-2).

And, my customer is very angry.

Please send me your answer as soon as possible.

BR,

Keita

[jiri-b36968]

Hi Keita,

I’m sorry I’ve being involved in the issue only 2 weeks. Not sure about the history. Designers replied, but we have not solved it so far.

/Jiri

[keitanagashima]

Hi Jiri,

Thank you for your reply.

Please confirm the designer about below 2 things.

1. Have you reproduced this problem on SABRE-AI board?

2. How long does it take to solving this problem?

BR,

Keita

[jiri-b36968]

Hi Keita,

1. No - you reproduced it on SABRE AI DL. Designers had been already asked that time. If you are not sure, I can order it. What was board number? MCIMX6DLAICPU1 ?
2. The issue was seen in when iMX read the code from NOR flash - so it was part of BootROM code. It would be hard to change it, but we still do not know if it is real issue. Designer started to reply so hopefully we will get replies soon.

/Jiri

[keitanagashima]

Hi Jiri,

>What was board number? MCIMX6DLAICPU1 ?

I reproduced it on MCIMX6QAICPU1.

And, my customer reproduced on their custom board with i.MX6DL.

BR,

Keita

[jiri-b36968]

Hi Keita,

I just get the board - revision A1 (2012). On the board is rev SCH-2742 REV C and 700-27142 REVA. Do you have the same?

/Jiri

[keitanagashima]

Hi Jiri,

Did you reproduce this issue on SABRE-AI?

And, do you  have any update?

Keita

[jiri-b36968]

Hi Keita,

Here are simulation from designer.

No-muxed mode:    interval between CS/OE asserted  is “0”  when RCSA=ROEA=0,   

        muxed mode.   :      interval between CS/OE asserted  is “22ns”  when RCSA=ROEA=0,   

No-muxed mode.   RCSA=ROEA=0, and CS/OE asserted at the same time in RTL simulation.  interval between CS/OE asserted  is “0”

muxed mode. RCSA=ROEA=0, and interval between CS/OE asserted   is 22ns in RTL simulation:

Going to replicate it here on real HW.

/Jiri

[keitanagashima]

Hi Jiri,

Thank you for your update!

>Going to replicate it here on real HW.

OK. I got it.

If you replicate it, please inform me.

[Additional questions]

- If the simulation result & real HW are true, this phenomenon will out of specification range.

- Does it cause some problem?

- Will you have plan to change a document (Data sheet or Errata)?

Best regards,

Keita

[jiri-b36968]

Hi Keita,

Simulations are OK. In  the case of non-muxed Adress and data - there is no delay. In the case of muxed mode there is a delay. No differ to datasheet.

I presumed that you are using non-muxed mode - please send me setting of switches S1 (10 pins) S2 (4 pins) and bootmode (4 pins) on your AI board.

I have to finish something else prior to the testing on real HW - give me one or two days.

/Jiri

[keitanagashima]

Hi Jiri,

>please send me setting of switches S1 (10 pins) S2 (4 pins) and bootmode (4 pins) on your AI board.

S1 (10 pins) : 0100100000

S2 (4 pins) : 0010

bootmode (4 pins) : 0010

>I have to finish something else prior to the testing on real HW - give me one or two days.

OK. I'm waiting for you update.

Best Regards,

Keita

[jiri-b36968]

Hi Keita,

the setting you described is to boot from SD card not from NOR flash. To boot form parallel NOR flash setting is different. See QSG: (SW2 0000, SW1 0000010000) non-muxed. I'm little bit confused.

I tested to boot from parallel NOR flash on SABRE AI with correct setting. I have not programmed the NOR yet. I can see delay between CS and OE 15 ns. There is no difference between 1st and following reads. Attached.

Since EIM_BOOT[2] is 1 so EIM_CS0RCR1[OEA] is 0b010 which are 2 EIM clocks. EIM clocks during boot time (BootROM code) is 133MHz, then 15 ns are exactly 2 EIM clocks. So it fits.

Please send mo more details:

- what is exact moment when you measure 1st assert of /CS

- what is exact moment when you measure 2nd assert of /CS (or what is time period between them)

- do you think that what you measured is part of BootROM code in i.MX6Q? Or is it possible that your board booted from SD card and your program initiated read from NOR flash? (you can remove SD card to be sure that it is booting from NOR flash)

Keep on testing and discussing with designers.

/Jiri

[keitanagashima]

Hi Jiri,

Thank you for your testing!

>the setting you described is to boot from SD card not from NOR flash. To boot form parallel NOR flash setting is different. See QSG: >(SW2 0000, SW1 0000010000) non-muxed

I'm very sorry.

My colleague had changed the boot setting on my AI board.

Your setting is correct and my setting, too.

(I didn't use SD card.)

>I tested to boot from parallel NOR flash on SABRE AI with correct setting.

>I have not programmed the NOR yet. I can see delay between CS and OE 15 ns.

I'm you too.

>There is no difference between 1st and following reads.

>- what is exact moment when you measure 1st assert of /CS

>- what is exact moment when you measure 2nd assert of /CS (or what is time period between them)

I confirmed delay for 1st clock.

And, I measured after a little time passed, cannot see the delay.

Sorry, I haven't measured on 2nd clock.

>- do you think that what you measured is part of BootROM code in i.MX6Q?

I consider this phenomenon happened at the Reading DCD table in NOR-Flash.

Best Regards,

Keita

[jiri-b36968 · Accepted solution]

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

[keitanagashima]

Hi Jiri,

Thank you for your answer!

I got it 1.2. and 4.

Let me clarify 3.

[Q1]

Refer to 22.9.3 Chip Select n Read Configuration Register 1 (EIM_CSnRCR1) in IMX6SDLRM(Rev.1).

OEA reset value = 0b000

Why is default setting of EIM for CS0  OEA = 0b010?

(Boot ROM setting? Typo of document?)

[Q2]

My customer observed 20ns delay with 1st clock on custom board.

Maybe they can use non-muxed mode.

Which is the default setting non-muxed or muxed mode in i.MX6SDL?

Best Regards,

Keita

[jiri-b36968]

Hi Keita,

• default setting of OEA depends on EIM_BOOT[2]. EIM_BOOT[2] is part of EIM_BOOT_CFG, which hardwired on i.MX6 families. EIM_BOOT[2] is hardwired to logic 1 - it is a designer information. see Table 6-2. EIM boot configuration.
• If EIM_BOOT[2] is 1 then OEA for CS0 is 0b010 - see RM EIM_CSnRCR1[OEA] note.
• Reset value for MUM equals to EIM_BOOT[2] - so it is muxed, but then it is changed by BootROM code.
  BootROM sets MUM and DSZ from switches or from fuses.
  setting (SW2 0000, SW1 0000010000) equals to not-muxed. determined by S1 7:6 on SDB AI
  - see BOOT_CFG2[7:6] in table Table 8-9. EIM Boot eFUSE Descriptions

/Jiri

[keitanagashima]

Hi Jiri,

I apologies for the delay in replying to you.

My customer worried about below points.

Please check it again.

>Reset value for MUM equals to EIM_BOOT[2] - so it is muxed

1. i.MX6 become muxed-mode with the first access.

  Is it possible to access normally?

2. which timing does it change OEA from 010b to 000b?

BR,

Keita

[jiri-b36968]

Hi Keita,

Yes, but it is changed in boot rom code based on BOOT_CFG2[7:6]. So reset value is irrelevant after BootROM code.

/Jiri

[keitanagashima]

Hi Jiri,

Thank you for your reply.

I'd like to know the timing of changing the OEA value from 010 to 000.

Is it changed OEM value in BootROM?

Keita

[jiri-b36968]

Hi Keita,

BootROM code leaves OEA set to 0b010. Change to 0b000, if is done, than it is done later. It can be done during boot as part of DCD in the image (NOR, SD,...) or later from code.

/Jiri

[keitanagashima]

Hi Jiri,

Thank you for your great support!

I understood these phenomenon.

But, refer to 22.9.3 Chip Select n Read Configuration Register 1 (EIM_CSnRCR1) in i.MX 6Solo/6DualLite Applications Processor Reference Manual, Rev. 1, 04/2013.

OEA reset value = 000b. (Actually OEA = 010b && Muxed mode)

So, please fix the Data sheet or add to Chip Errata.

BR,

Keita