i.MX6D stalls when NACK is returned from MMPF0100.

[satoshishimoda]

Hi community,

I have a question about i.MX6 Android BSP (android_jb4.2.2_1.0.0).

A custom board of a customer does not boot rarely (about 3 / 2000 times).

Then, the customer investigated and found it was occurred when MMPF0100 returns NACK to I2C read access from i.MX6D on the timing between starting kernel uncompresssion and before mount rootfs of the boot sequence.

Actually, i.MX6D was stalled when NACK is returned, we think it is problem.

Then, please see our question as below.

[Q]

Is this i.MX6 stall issue by I2C NACK resolved with newer Android BSP (android_jb4.2.2_1.1.0)?

Best Regards,

Satoshi Shimoda

[igorpadykov]

Probably something wrong on customer board, please recheck

it on Freescale board. Also when doing "2000 times" reboot

had customer verified that board was completely powered down,

all capacitors discharged, was time between reboots sufficient long?

BTW, check that maxcpus=2 kernel parameter is used

(for  i.MX6D).

[satoshishimoda]

Hi chipexpert,

I got some additional report.

This issue was not i.MX6 issue, it was MMPF0100 issue.

Actually, VDDCORE (for VDDARM_IN) voltage is dropped to about 0.28V when this phenomenon.

So i.MX6 stalled by this voltage dropping.

And when this stall issue is occurred, occasionally VDDARM_IN voltage is not dropped, but about 322Hz 100mV glitches are occurred on VDDARM_IN.

Please see the attached file.

This is the waveform when this issue was occurred.

For your information, they have checked power supply (voltage and current) for MMPF0100 is no problem.

In addition, our partner found this issue is occurred when first I2C access to MMPF0100 after start kernel uncompression.

It means this issue is occurred even if they change the read access address from 0x00 to 0x03.

Do you know what is wrong?

Best Regards,

Satoshi Shimoda

[satoshishimoda]

Hi chipexpert,

Could you reply to me?

[igorpadykov]

Hi Satoshi, sorry for delay.

Could you please check this on Freescale reference board with latest Freescale Android

(from www.freescale.com) and if issue will persist, create new Community thread, since this appears as bug.

Best regards

chip

[satoshishimoda]

Hi chipexpert,

According to additional investigation, there is possibility this issue is occurred by "reboot -p" command.

Actually, customer uses "reboot -p" command to reboot i.MX6.

But we guess if this command is executed when i.MX6 accesses to MMPF0100 via I2C, I2C access is terminated suddenly and MMPF0100 holds a I2C access data in FIFO because power supply to MMPF0100 is continued.

Is this correct?

If this is correct, MMPF0100 combines this held data and I2C access data from i.MX6 on next i.MX6 power up sequence.

This occurs MMPF0100 unexpected behavior.

Best Regards,

Satoshi Shimoda

[satoshishimoda]

Hi chipexpert,

> Probably something wrong on customer board,

Yes, that's right.

Actually, this issue did not occurred on Freescale board (MCIMX6Q-SDP) even though tried reboot over 4,000 times .

When reboot process, I think power down time was sufficient because customer wait about 10 sec from power down to next power up.

> BTW, check that maxcpus=2 kernel parameter is used

I will check it to the customer.

Something is bad if the maxcpu=2 is not set?

Best Regards,

Satoshi Shimoda