FEDEVEL
Platform forum

Lach , 09-20-2025, 06:46 PM

Hi ,
My board has an IMX6DL and 2GB of RAM. I was not aware of the "prime bits D0,D8,D16,D24 .. for write leveling as most of the SOMs such as Zynq, dedicating "prime bit" is not a requirement. My IMX6 board do swap the prime bits within byte lanes and that is the reason for Write calibration to fail. I used some default values from Rex boards and other sources so i can run the stress test at least. What I have noticed is after, say 3h of running that is 50 iterations of the NXP DDR3 stress test, the test hangs up. When the test hangs up( the console menu does not advance to the next iteration), i see the current draw drops from 340mA to 260mA, as if the CPU gives up or it is going on Idle. The junction temperature is 57C when it hangs. After rebooting the board and starting over with the same write level calibration settings(CPU temp at 51C), the stress test fail during the first or second iteration.

My question are:
- can the "hang up" and the dropped current consumption be caused by wrong Write Level calibration. Honestly, i was expecting to see on the console an error message of some sort. I hate to re spin the boards just to find out Write Level calibration passes but the stress test still hangs up

- during Layout I did run the Siemens DDRx Batch utility 2D Jedec simulation and everything passed there with comfortable margins. I can get the exact times of flights for CK/#CK and DQS 1,2,3,4 signal and calculate up to +/-2ps the Write Leveling delay. Then I could write the delay registers in my .inc script. Would that work for manual Write Level calibration?

Thanks,

Lach

Robert Feranec , 09-22-2025, 10:38 AM

you can boot up linux and run memory test

Robert Feranec , 09-22-2025, 10:38 AM

if it will be possible

Robert Feranec , 09-22-2025, 10:38 AM

the memory test can give you more information

Robert Feranec , 09-22-2025, 10:40 AM

but you will need to find a way to run the calibration, because your tracks are probably different from the other designs so putting there numbers from other boards may not help much

Robert Feranec , 09-22-2025, 10:41 AM

maybe there is a way to disable somehow the prime bit "feature"? I also only have seen this on iMX6, I dont think I have seen the smentioned anywhere else

Lach , 09-23-2025, 12:07 AM

Hi Robert,

Lach , 09-23-2025, 12:13 AM

I was able to find the first problem. It was the power on reset circuit POR causing the IMX6 to reset . As you may know the stress test is executing an elf file from the onchip memory at address 0x00900000 (aka OCRAM). After the reset, the CPU instruction counter pointed to an unknown address causing the CPU to halt or not executing the OCRAM stress test code. I am using the jtag stress test tool that gives me more flexibility that the USBOTG or Uboot version. I was able to calculate the tracks TOF( time of flight) including the pin package delays. Pin package delays can be taken from the SoM IBIS file and calculated as SQRT(L*C) for each pin. Altium allows you to include the pin package delay as part of the nets class constraints. Another way to find the exact delay between DQS and CK is using tools such as Hyperlynx Siemens including the IMX6 and DDR IBIS models inside HyperLynx, so one does not have to guess about the delays in Write leveling. The delay registers in IMX6 are calculated as delay = DDR_clkPeriod * N/256 , find N knowing the delay between the CK(clock) and DQS and update the Write level registers manually with the N value. I Will have to fix the POR issue first and I will update on the Write Leveling test

Robert Feranec , 09-23-2025, 02:26 AM

let me know then, i am curious if calculations are as good as real training