Some i.MX 7S are not booting without extra reset cycle

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Some i.MX 7S are not booting without extra reset cycle

696 Views
peterlischer
Senior Contributor I

After starting a first small production lot, we have several i.MX 7S systems that are not booting after the power rails are ramped up. The systems boot always successful if the POR_B signal is cycled a second time (over an external reset button). It does not help if the POR_B signal is kept low for several seconds and released later (by holding the reset button during power up). Only if there is a second reset cycle, the system boots successful.

We can put the SoC into the USB download mode even without the extra reset cycle. In this USB download mode, we are able to connect with the DDR Stress Test tool (Version 2.5.2). It is possible to do successful memory read and writes. But the DDR stress test always hangs even at the lowest possible speed (350MHz). The last output we get is the following: 

DDR Stress Test Iteration 1
DDR Freq: 349 MHz
t0.1: data is addr test

If we do a reset cycle before entering the USB download mode, the DDR stress test is running successful until a frequency of 622MHz without issues. Therefore, I do not think the issue is related to the DDR RAM. 

The system boots perfectly from the NAND flash if a second reset cycle is issued. Without this reset cycle, there is no serial output from the U-Boot. Measuring the NAND data lines with a scope shows, that the NAND communication stops after a few milliseconds. It seems that the SoC loads the DCD table, but then crashes.

The power up sequence seems to be OK, also the oscillators are starting as expected. There is no voltage rail missing. The issue seems to be somehow temperature related. At some temperatures, the system works without the additional need for a reset cycle.

What could cause such a behavior? In which direction should I do my further investigations? Do you have any further inputs for resolving the issue? I checked for the latest errata (Rev. 0, 05/2016). I was not able to find anything related to such an issue.

Thank you in advance for any help.

Labels (2)
2 Replies

527 Views
art
NXP Employee
NXP Employee

The possible cause of the issue is the effect of the silicon erratum #e9516. Should be fixed in the upcoming silicon releases.


Have a great day,
Artur

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

0 Kudos

527 Views
peterlischer
Senior Contributor I

Hi Artur,

Thank you for your answer. In the errata document there is a workaround for this issue:

Set the ctrl_ref in register DDR_PHY_MDLL_CON0 [4:1] to 4’b1111 to disable the de-asserting

of dfi_init_complete until rst_n is asserted.

I checked the stress tester script file as well as the DCD table we have linked in our U-Boot. On both files, the workaround is already implemented:

memory set 0x307900b0 32 0x1010007e

If I understand the workaround correctly, it cannot be that issue since the workaround is already in place. Please correct me if I am wrong here.

By the way, in the meantime we have seen the issue also on i.MX 7D devices. We have tested now around 50 systems in the temperature chamber. About half of them do not show the issue at all. On the other half I was able to see the issue. Some of them only at very high temperatures, others only at a certain temperature. I have a few which show the issue even at room temperature.

Kind regards

Peter.

0 Kudos