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
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.....
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
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
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
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.
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.
except DQS gating calibration error:
"Can't find suitable values"
are all other tests passed ok ?
~igor
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).
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
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
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
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!
-----------------------------------------------------------------------------------------------------------------------
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
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
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
Hi Michael
yes it should have no problem running at 800MHz.
1.18v is OK according to datasheet Table 6. Operating Ranges
~igor
Thanks for your valuable inputs.
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
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
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.