MFGtools stops for some boards

cancel
Showing results for 
Search instead for 
Did you mean: 

MFGtools stops for some boards

Jump to solution
691 Views
chris321
Contributor IV

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?

Labels (2)
Tags (2)
0 Kudos
1 Solution
384 Views
Yuri
NXP TechSupport
NXP TechSupport

 

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!

View solution in original post

9 Replies
385 Views
Yuri
NXP TechSupport
NXP TechSupport

 

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!

View solution in original post

384 Views
chris321
Contributor IV

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

But I still have the two asked questions:

1:

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'

2:

which calibration values should we use now?

for example register MPRDDLCTL

DUTregisterRD_DL_ABS_OFFSET1RD_DL_ABS_OFFSET0
DUT#10x404032345052
DUT#20x40402E324650
DUT#30x404030304848

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

0 Kudos
384 Views
Yuri
NXP TechSupport
NXP TechSupport

Hello,

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

and recommendations how to select proper calibration values. 

Regards,

Yuri.

384 Views
chris321
Contributor IV

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.

[...]

0 Kudos
384 Views
chris321
Contributor IV

update:

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

0 Kudos
384 Views
bernhardfink
NXP Employee
NXP Employee

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.

384 Views
chris321
Contributor IV

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.

0 Kudos
384 Views
bernhardfink
NXP Employee
NXP Employee

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.

0 Kudos
384 Views
chris321
Contributor IV

update:

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

0 Kudos