To confirm whether i.MX6DQ boot issue is occurred by ERR006282 or not.

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

To confirm whether i.MX6DQ boot issue is occurred by ERR006282 or not.

Jump to solution
1,099 Views
satoshishimoda
Senior Contributor I

Hi community,

I have a question about i.MX6DQ ERR006282.

Acutally, i.MX6Q android boot issue is occurred on our partner's boot.

We want to confirm whether this issue is occurred by ERR006282 or not.

Is there some signal to confirm it?

Actually, our partner's board boots from eMMC, and eMMC clock is not output when this boot issue is occurred.

Can we determin this boot issue is occurred by ERR006282 with only clock for boot device?

Best Regards,

Satoshi Shimoda

Labels (2)
Tags (1)
0 Kudos
1 Solution
505 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Satoshi Shimoda,

Yes, there is no way of making sure this is the issue preventing you from booting just by the clock for the boot device as other variables may affect this signal as well.

You would need to review under which conditions this booting issue happens. As I mentioned, if this happens on cold boots and it’s very consistent I would say it’s not related to ERR006282. If it happens from time to time under stress-testing of the boot sequence then I would review possible workarounds as listed on the errata document.

Regards,

Gusarambula

View solution in original post

0 Kudos
4 Replies
505 Views
gusarambula
NXP TechSupport
NXP TechSupport

If the boot issue you’re encountering happens consistently at every power-on/reset chances are it is not related to ERR006282 as this issue appears only after boot “stress-testing” (please refer to the i.MX6 Errata, link below). Even then, once it happened it does not make it more likely for it to appear again, so it should appear rarely under normal usage conditions.

http://cache.freescale.com/files/32bit/doc/errata/IMX6DQCE.pdf

0 Kudos
505 Views
satoshishimoda
Senior Contributor I

Hi gusarambula,

According to your reply, there is no signal to confirm whether this issue is occurred by ERR006282 or not.

And we have to judge from the condition when the issue is occurred ("stress-testing" or not) and from frequency of occurrence.

Is my understanding correct?

Best Regards,

Satoshi Shimoda

0 Kudos
506 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Satoshi Shimoda,

Yes, there is no way of making sure this is the issue preventing you from booting just by the clock for the boot device as other variables may affect this signal as well.

You would need to review under which conditions this booting issue happens. As I mentioned, if this happens on cold boots and it’s very consistent I would say it’s not related to ERR006282. If it happens from time to time under stress-testing of the boot sequence then I would review possible workarounds as listed on the errata document.

Regards,

Gusarambula

0 Kudos
505 Views
Aemj
Contributor IV

Hello Gusarambula-san,

Recently, our customer also asked us very similar question as Shimoda-san asked.

In our customer's case, they can see non-boot issue from microSD once out of 100 times of boot. (i.e., around 1%)When problem happens, i.MX6 doesn't access to microSD at all.

XTAL(24MHz) is still running when this problem is seen, but if they put a probe(10pF) to XTAL, the rate of occurrence is reduced from 1/100 to 1/200 ~ 500. (i.e., around 0.5%).  I'm not sure if matching of XTAL affects this errata.

Do you think their problem is caused by this errata from their condition/rate of occurrence?

And "Stress-testing" means periodical system boot test? Or any other condition which can add "stress" to i.MX6 to cause this errata?

Your comment is very appreciated.

Thanks,

Norihiro Michigami

AVNET

0 Kudos