Strange CCM_CGR Behavior of IMX6

[tengri]

Hi All,

I've developed few custom boards based around IMX6Q processor and ran into a strange problem when getting the board up !

1. First the board cannot pass DDR_Stress_Test (V2.7) for calibration and always ends up reporting a DCD_Write_Failed error (MR value - 0004, DCD Verification un-ticked). But after tweaking a bit I found out that the issue was caused by CCM_CGRx register values. The initial DDR script is meant to write reset values to those registers when DDR calibration starts (via OTG, Boot mode switches) :

setmem /32 0x020c4068 = 0xffffffff
setmem /32 0x020c406c = 0xffffffff
setmem /32 0x020c4070 = 0xffffffff
setmem /32 0x020c4074 = 0xffffffff
setmem /32 0x020c4078 = 0xffffffff
setmem /32 0x020c407c = 0xffffffff
setmem /32 0x020c4080 = 0xffffffff  // CCM_CCGR6
setmem /32 0x020c4084 = 0xffffffff

For some reason, the highlighted register write cannot be performed and this seemed to be the issue for DCD_Write_Failed. After commenting this and also after lowering the ARM_Speed I was able to do the calibration. However even manual write to CCM_CCGR6 through Stress_Tester is not successful. This can be performed in some of the Sabre Reference boards though ! But when reading the address in Stress_Tester, it gives the value of 0xFFFF0003 ! The DDR calibration result is shown below (5th Run) :

[Bash] DDR_Calibration_Arm_Speed_800MHz - Pastebin.com 

2. After updating the u-boot with above calibrated values, I successfully burnt the serial flash and got the board to boot, but at some point of the boot process, kernel starts to hang giving a kernel panic. I am using Yocto Krogoth version and kernel 4.1.15 ! The panic message is reproducible :

[Bash] Kernel Panic - Pastebin.com  (Showing two instances of kernel panic)  

3. The external crystal oscillator generates 24MHz for XTAL frequency. 

So does this look like an issue of clocking of the system ? Why accessing CCM_CCGR6 is restricted, although its address is valid under serial mode DCD address range ? Further could this be due to a faulty chip ?

Thanks in Advance

Anuradha 

[art]

Q. So does this look like an issue of clocking of the system ?

A. Yes, it is possible.

Q. Why accessing CCM_CCGR6 is restricted, although its address is valid under serial mode DCD address range ?

A. Any out-of-specification powering or clocking of the chip may cause any unpredictable behaviour, such as the one you observe.

Q. Further could this be due to a faulty chip ?

A. Most likely, no.

Have a great day,
Artur

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

[tengri]

Hi All, the problem was associated to one power rail. After fixing the components of correct ratings, we resolve the issue. Thanks all for your suggestions.

Anruadha

[joekozio · Accepted solution]

Hello Anuradha,

We were able to run our software (Kozio VTOS DDR) on your design working with one of your co-workers. In order to run, we disabled all software that automatically enables the various clocks associated with CCGR registers. This allowed us to run and then perform some initial DDR3 PHY calibration. Based on your information, and our experience, we believe the issue is related to power, not due to a faulty chip or register access.

Our software allows you to use an advanced mode to turn on clocks individually. By turning on clocks while running VTOS DDR, you can test power levels before and after turning on clocks. Using our software tool will allow you to verify power levels.  I hope this is helpful.

Best regards,

Joe Skazinski

Kozio