Bring-up issue with iMX6Q ref. IMX6Q5EYM12AC

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

Bring-up issue with iMX6Q ref. IMX6Q5EYM12AC

3,062 Views
michaëlburtin
Contributor II

Hi,

 

We're currently bringing-up two prototypes with nearly same hardware. PCB is the same and all the parts are identical except the CPU.

One board have a IMX6Q6AVT10AC, and the other one IMX6Q5EYM12AC (which support 1.2GHz).

The latter have issue with DDR which is unstable. After much investigation, we can't didn't find any explanation for this failure.

The other board is working well.

 

So we wonder if there is some specific considerations with IMX6Q5EYM12AC processor, despite we didn't find any specific notes in datasheet ?

 

We did not find much information about specific 1.2GHz IMX6 processor so we assumed there's no differences except max frequency, is that correct ?

Any hint would be appreciated.

 

In attachment the calibration log.

What has been tested so far:

- increasing RALAT/WALAT

- changing DSE in I.MX6DQSDL DDR3 Script Aid,

- changing DDR frequency for calibration

- changing CPU frequency for calibration

- doing stress test using working board calibration

- HW Design checklist

- bus length check with HW Design checklist

(And probably more that I forget)

 

I saw in another thread someone advising "try using different drive strength for DRAM signals for both  i.MX6 and DRAM part", what DSE is he referring to when saying for iMX6 part ?

 

 

Regards,

Michaël

Original Attachment has been moved to: calibration_log_jtag.txt.zip

Labels (1)
0 Kudos
20 Replies

2,006 Views
michaëlburtin
Contributor II

We've gone over everything that has been mentionned here and we could imagine:

- checking all the voltage

- checking power source stability during stress test

- duplicating capacitors on DDR_1V5 and DDR_VREF

- controling all passive component involved in DDR

- check every single configuration register in DDR init script

Still the same failure...

We may consider that there was a manufacturing issue but I'm a bit worried because it's one board out of two that fails.....

0 Kudos

2,006 Views
michaëlburtin
Contributor II

From Igor inputs, it seems that thinking the processor was in cause was a bad assumption.

Still we can't figure out why writing to DDR is failing.

We check the input voltage with a scope, no drop, everything seems stable while writing to DDR.

What else could we check ? Any advice would be greatly appreciated.

Regards,

Michaël

0 Kudos

2,006 Views
sinanakman
Senior Contributor III

Hi Michaël

You might have already done it this way but while

we were working on a similar problem we could

see the spikes only for a very short time. To capture

this you would need to set your scope in AC mode

and set a trigger right below the regular value. This

is the only way we could see a very short spike.

Also, how many of your boards are failing like this ?

(If you have only one or two boards failing and thoese

happen to be with faster SoC maybe there is a

manufacturing issue)

Regards

Sinan Akman

0 Kudos

2,006 Views
michaëlburtin
Contributor II

Hi Sinan,

I've just done some measurments with my scope, as you told, in AC mode.

I've looked at DDR VREF and I did not saw a clear voltage drop but variation reaching 20mv.

I wonder if this is within the DDR specifications...

Today we only have two prototypes, one with a 1GHz iMX6, the other one (with issues) with the 1.2GHz iMX6.

Michaël

0 Kudos

2,006 Views
GregDyess
Contributor III

Something I have personally seen with DDR bringup issues is power.  Make sure you are feeding your board with enough power (current) and your power supply/filtering circuitryis sufficient.  DDR when running full out under heavy read-write cycles will draw considerably more peak power than you could imagine. 

I've seen a board that can run steady state start to fail the stress test until the current limiter was turned way up.  It's VERY spikey and you'll never see the load on a voltmeter.

2,006 Views
michaëlburtin
Contributor II

Thanks for your inputs!

That's a good point and I'll made some electricals tests with our board designer to ensure that power is stable, that's really a good lead to understand our issues.

0 Kudos

2,006 Views
igorpadykov
NXP Employee
NXP Employee

except DQS gating calibration error:

"Can't find suitable values"

are all other tests passed ok ?

~igor

0 Kudos

2,006 Views
michaëlburtin
Contributor II

No, as soon as multiple writes are done to DDR (which is the normal use case), the system hang.

I mean that writing and reading bytes through DDR Stress Test does work.

DDR Stress test does FAIL at the very beginning of DDR (0x10000000).

0 Kudos

2,006 Views
sinanakman
Senior Contributor III

Hi Michaël

> as soon as I load an image that use DDR, the board hang

OK, so that shows whatever the values you use for ddr controller

does not work.

The way you are setting up the ddr controller, what are differences

between this and your working boards ? Perhaps the problem is

not so much related to using different (speed of) SoCs but rather

how you set up your memory controller in two different cases.

Are your layouts exactly same for the two different SoCs ?

Regards

Sinan Akman

0 Kudos

2,006 Views
michaëlburtin
Contributor II

Sinan,

There's no difference in DDR setup regards to working board as we have exactly the same PCB

and the same board components (except CPU). RAM is identical and initialized the same way.

As I said, the only "clear" difference is the SOC model, otherwise everthing should be identical.

Michaël

0 Kudos

2,006 Views
sinanakman
Senior Contributor III

Hi Michaël

I was going to suggest to check your pmic settings to see it they

satisfy 1.2 GHz SoC's voltage range but I noticed in an earlier

post you mentioned that you have no problem running an image

out of OCRAM. Still it is probably a good idea to go over all

pmic outputs and see if they would stress the range of faster

SoC. Failing that, one other possibility is that perhaps you have

a manufacturing or layout issue and it is showing up at higher

frequency although you do seem to have gone the complete

design check list.

I think checking all the pmic voltage points and observing if

there is a clear drop around the ddr failure and compare all

your scope readings to that of working slower SoC would be

one thing to do.

Regards

Sinan Akman

2,006 Views
igorpadykov
NXP Employee
NXP Employee

Hi Michaël

The parameters of the 1.2 GHz devices are identical to that of the 996 MHz devices, with the following

exceptions:

• ARM processor maximum frequency increased from 996 MHz to 1.2 GHz.

• ARM on-chip voltage regulator voltage (VDDARM_IN) changed from 1.35-1.5 V to 1.4-1.5 V.

• 1.2 GHz ARM operation limited to LDO enabled mode only (LDO bypass not allowed).

• ARM LDO output (VDDARM_CAP) operating point changed from 1.225 V to 1.275 V.

Best regards

igor

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

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

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

2,006 Views
michaëlburtin
Contributor II

Hi Igor,

We're using MMPF0100F0EP to power-up iMX6Q and it's configured to ouput 1.375v to VDDARM_IN.

This is out of the range you're mentioning (1.4-1.5v), do we need to switch to another version of MMPF?

Also, we're measuring 1.18v out of VDDARM_CAP/VDDSOC_CAP, which seems incorrect. Any clue about that?

Regards,

Michaël

0 Kudos

2,006 Views
igorpadykov
NXP Employee
NXP Employee

Hi Michael

MMPF0100F0EP will power-up iMX6Q and it will work

at default 792MHz. After that in software one can elevate voltage

(1.4-1.5v) and increase frequency.

~igor

2,006 Views
michaëlburtin
Contributor II

Igor,

So you confirm that with the exact same design as a SabreSD, this processor, running at 800MHz should have no problem with running DDR Stress test without any specific MMPF software voltage change (which is only required when scaling frequencies)?

Also, you did not answer about VDDARM_CAP/VDDSOC_CAP being at 1.18v?

Regards,

Michaël

0 Kudos

2,006 Views
igorpadykov
NXP Employee
NXP Employee

Hi Michael

yes it should have no problem running at 800MHz.

1.18v is OK according to datasheet Table 6. Operating Ranges

~igor

2,006 Views
michaëlburtin
Contributor II

Thanks for your valuable inputs.

0 Kudos

2,006 Views
michaëlburtin
Contributor II

Thanks Igor for the details.

So if I understand correctly there's no clear link between our DDR issues dans SOC version, right ?

Our design is very close to SabreSD ref design and we're powering-up iMX6 with a MMPF0100.

Michaël

0 Kudos

2,006 Views
sinanakman
Senior Contributor III

Hi Michaël

I will leave it to FSL to comment on exact differences between the two SoCs

but I wonder what you are exactly referring to with "unstable DDR". How does

your boards with IMX6Q5EYM12AC react to DDR stress tester ? Do

you see the problem in all boards with this particular SoC ?

Regards

Sinan Akman

0 Kudos

2,006 Views
michaëlburtin
Contributor II

Hi Sinan,

Our board with IMX6Q5EYM12AC fails DDR Calibration at DQS calibration state with error "Can't find suitable values".

DDR Stress test fails at first address 0x10000000.

With new DDR stress tools 2.3 that allow writing and reading arbitrary values, manually writing and reading to memory looks okay.

I've tried to tweak initial config without any success....

I've done some test with JTAG and as soon as I load an image that use DDR, the board hang. Running an image from OCRAM works fine.

Using openocd i can init DDR and run some basic tests (using runAllMemTests). I guess it's related to write rate....

Right now I don't really know where to dig.... that's why I'm suspecting the SOC.

0 Kudos