topic Re: MFGtools stops for some boards in i.MX Processors

MFGtools stops for some boards

chris321 — Tue, 31 Jul 2018 14:33:25 GMT

Hello imxcommunity,

I have a small batch of custom i.MX6ULL boards. Nearly the half of them is flashable via mfgtool, to other ones not.
The flashed boards can boot from eMMC.

i.MX: MCIMX6Y2CVM08AA
RAM: ISSI IS43TR16256AL-125KBLI
eMMC: Micron MTFC4GACAJCN-4M IT

For the boards wich can be flashed:

* Mfgtool detects the i.MX6ULL HID device

* a mass storage device is opening
* mfgtool copies the image
* linux and uboot outputs shown via debug uart

for the boards which can't be flashed:
* Mfgtool detects the i.MX6ULL HID device
* no mass storage devices opens
* no debug uart outputs

I measured the supply voltages and they look not bad at all.

I attached the mfgtool.log for one board which can be flashed and for one which can't. According to them it looks like the board is in the wrong state for further instructions because it has wrong VID and PID.

What are the next steps you suggest to track this issue down?

Re: MFGtools stops for some boards

chris321 — Tue, 31 Jul 2018 15:14:46 GMT

update:

I also played around with the termination resistors between differential ddr clock pair with values between 100 and 400 Ohm. Makes no changes.

Re: MFGtools stops for some boards

Yuri — Wed, 01 Aug 2018 04:40:04 GMT

Hello,

Perhaps it makes sense to check and calibrate memory for all boards.

https://community.nxp.com/docs/DOC-105652

Have a great day,

Yuri

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

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

Re: MFGtools stops for some boards

chris321 — Wed, 01 Aug 2018 07:59:36 GMT

Hi Yuri,

has a first quick test, to ensure the RAM is soldered correctly, I started the NXP DDR Stress Test v2.9 (GUI variant) and used the unmodified reference init script "EVK_IMX6ULL_DDR3L_400MHz_512MB_16bit_V1.2.inc"

* Set Target MX6ULL and remaining things to default/auto.

* Started DDR calibation test with 300 MHz

The calibration routine runs till the end on both boards (the one wich boots and the one wich doesn't boots).

I attached both logs, the are different in some register values. Please don't mind the difference in boot configuration registers. That is because the successfully flashed devices has already set its efuses.

Just for fun I set up the tool a second time for the 'OK'-board. And even that register values are a little bit different then the ones out of the first try.

With the assumtion I had set up the tool correctly, which calibration values should we use now?
a) good board, first try

b) good board, second try

c) bad board

d) something else, e.g. average from multiple runs

Should I be worried about the following part in each log (also in the good ones)?

[...]

Note: Array result[] holds the DRAM test result of each byte.
0: test pass. 1: test fail
4 bits respresent the result of 1 byte.
result 01:byte 0 fail.
result 11:byte 0, 1 fail.

[...]

Re: MFGtools stops for some boards

chris321 — Wed, 01 Aug 2018 08:28:06 GMT

update:

stress test successfully runs in the range from 300 till 528 MHz

Re: MFGtools stops for some boards

bernhardfink — Mon, 06 Aug 2018 08:18:30 GMT

For me this doesn't look like a DDR problem. It seems that on the "bad" boards the USBIO mass storage device could not be established. The HID is not really a stress test for the USB port, so maybe this is working for all your boards. If you are at the edge of USB performance, then it could be that some of your boards are on the bad side when switching to the MSC profile.

In a first step you should try to change things on the USB connection for the bad boards:

- use a shorter and better USB cable

- put a USB 2.0 hub inbetween

- check it with another host computer

Regards,

Bernhard.

Re: MFGtools stops for some boards

chris321 — Mon, 06 Aug 2018 09:47:35 GMT

Hello Bernhard,

that the issue is on the USB side was also one of my first ideas. But since that DDR stress test is also copied via USB I thought I can exclude that. Other USB-HUB and cables and also another host computer I tested already in that first stage.

Do you know other USB related adjustment which I could set? In the meanwhile our SW devs will implement new DDR calibration settings.

Re: MFGtools stops for some boards

bernhardfink — Mon, 06 Aug 2018 12:10:46 GMT

You could make a crosscheck on u-boot level:

U-Boot USB Mass Storage gadget - Boundary Devices

Download u-boot with usb_loader and mount the SD-card or the eMMC as mass storage device with ums.

Maybe you can also do something with the boot utility here:

https://community.nxp.com/docs/DOC-103834

Adjustments on USB PHY level to match the characteristic of your PCB in a better way would be possible, but for the moment I don't know how to do this in a smart way.

Regards,

Bernhard.

Re: MFGtools stops for some boards

chris321 — Tue, 07 Aug 2018 15:01:47 GMT

It seems like I get the boards running with a calibrated RAM.

But I still have the two asked questions:

Should I be worried about the following part in each log (also in the good ones)?

[...]

Note: Array result[] holds the DRAM test result of each byte.
0: test pass. 1: test fail
4 bits respresent the result of 1 byte.
result 01:byte 0 fail.
result 11:byte 0, 1 fail.

[...]

because some of the results are '11' or '01'

which calibration values should we use now?

for example register MPRDDLCTL

DUT	register	RD_DL_ABS_OFFSET1	RD_DL_ABS_OFFSET0
DUT#1	0x40403234	50	52
DUT#2	0x40402E32	46	50
DUT#3	0x40403030	48	48

So which is the most meaningful approach?
* choosing the max values for each read delay offset
* using some kind of (weighted) average

Re: MFGtools stops for some boards

Yuri — Thu, 09 Aug 2018 05:53:21 GMT

Hello,

use https://community.nxp.com/docs/DOC-101708 with tools descriptions

and recommendations how to select proper calibration values.

Regards,

Yuri.