ERR005852 : what is "analog bypass mode"?

[norishinozaki]

Hello Igor,

Sorry, seems I have made you confused.

Let me confirm "analog bypass mode" again.

-- Using "(digital) bypass mode(0x1F)" and entering to DSM causes the errata, which is, slow rising of VDDARM_CAP.

- The workaround is to go to "analog bypass mode(0x1E)" before entinrg DSM.

These sentences in the error is fine.

Here is a real question:

Is going to "analog bypass mode(0x1E)" the only workaround?

Because my custmer observed that any applicable ragulation values such as 0x12 or 0x18 also make VDDARM_CAP rise quick.

I guess the reason why the official workaround suggested to use "analog bypass mode(0x1E)" is to achieve lower power comsumption rather than using actual regulator values enabling LDO.

Is this correct understaning ?

Best regards,

Nori Shinozaki

[norishinozaki]

Igor,

Thanks! I created a new thread.

"LDO turning from 0x1F to 0x1E cause i.MX6DL hang"

Best regards,

Nori Shinozaki

[norishinozaki]

Hello Igor,

Reminder: here is a question switched from "LDO turning from 0x1F to 0x1E cause i.MX6DL hang"

The customer clings to what "0x1E" is.

Could you explain the differences between "0x1E" and "0x1F"?

The customer is not expecting to hear such as, the 0x1F is for bypass LDO and the 0x1E is for preventing VDD_ARM_CAP from slow rising after DSM.

The customer would like to know the physical or logical differences between the two modes.

You explained me about 0x1F makes the LDO switch full-on and the dropout voltage becomes almost 0V, which causes VDD_ARM_CAP to rise slowly.

However, why 0x1E can prevent from this phenomenon?

Remember 0x1E is not a relurator value, it's a some kind of "special" value, that is what the costomer would like to know.

Best regards,

Nori Shinozaki

[norishinozaki]

Hello Igor,

Sorry for complecated situation but is it taking time to get answers from engineering?

Since the word "analog bypass mode" only appears in the errata, it confuses us.

Best regards,

Nori Shinozaki

[igorpadykov]

Hi Nori

I am afraid I can not add something else.

I would suggest to work with local FAE

on this issue.

From my point of view there is misunderstanding

due to language problems.

Best regards

igor

[norishinozaki]

Hello Igor,

Ok, I will do that.

Thank you for supporting on this for long.

Best regards,

Nori Shinozaki

2014-10-28 20:22 GMT+09:00 igorpadykov <admin@community.freescale.com>:

<https://community.freescale.com/>

ERR005852 : what is "analog bypass mode"?

reply from igorpadykov

<https://community.freescale.com/people/igorpadykov?et=watches.email.thread>

in i.MX Community - View the full discussion

<https://community.freescale.com/message/448191?et=watches.email.thread#448191>

[igorpadykov]

Hi Nori

>Is going to "analog bypass mode(0x1E)" the only workaround?

This is just not very good wording: meaning is that any value (such as

0x12 or 0x18), except "bypass mode(0x1F)" will also make VDDARM_CAP rise

quick. Background is that enabled LDO has lower output buffer impedance,

it will charge VDDARM_CAP capacitor faster, than in case of "bypass mode(0x1F)"

There are no timing specifications of VDDARM_CAP.

The slope of the ramp may controlled by

the time spent at each 25-mV step and is controlled by the

step time field in the PMU_MISC2 register:

CCM_ANALOG_MISC2n, REG0_STEP_TIME .

Best regards

igor

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

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

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

[norishinozaki]

Igor,

Thank you, let's forget about "analog bypass mode" and resume this thread.

The customer clings to what "0x1E" is.

Could you explain the differences between "0x1E" and "0x1F"?

I mean it's NOT the difference that 0x1F is for bypass LDO, 0x1E is for preventing VDD_ARM_CAP from slow rising after DSM.

The customer is requesting the physical or logical differences between them.

You explained me about 0x1F makes the LDO switch full-on and the dropout voltage becomes almost 0V, which causes VDD_ARM_CAP to rise slowly.

However, why 0x1E can prevent from this phenomenon?

Remember 0x1E is not a relurator value, it's a some kind of "special" value, that is what the costomer would like to know.

Best regards,

Nori Shinozaki

[norishinozaki]

Hi Igor,

Thanks for your hard work answering lots of our qustion!

Ok, then do you agree that the following sentence is better than the one in the Errata?

"The software workaround to prevent this issue is to switch to analog bypass mode (0x1E) or any values except LDO bypass mode(0x1F), prior to entering DSM, and then, revert to the normal bypass mode(0x1F), when exiting from DSM."

Howerver!

My customer encountered a CPU hang when going to analog bypass mode(0x1E) from LDO bypass mode(0x1F).

Here is what they did:

1

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG4–0）= 10010(1.150V:LDO Enable )

2-1

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 11111(0x1F:LDO Bypass )

3

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 11110(0x1E:Analog Bypass )

However, when they add an intermediate step 2-2 below,  they can move to analog bypass

1

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 10010 (1.150V, LDO Enable )

2-1

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 11111 (0x1F:LDO Bypass )

2-2

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 11100 (1.425V, LDO Enable )

3

-  CPU=396MHz, PMIC-ARMCORE(SW1A/B)=1.3V

-  PMU_REG_CORE-REG0_TARG（4–0）= 11110 (0x1E:Analog Bypass )

Any idea?

Best regards,

Nori Shinozaki

[igorpadykov]

Hi Nori

yes, I think your sentence is better.

For cpu hang suggest to create new thread.

Best regards

igor

[norishinozaki]

Igor,

I forgot this.

The customer is also asking for timing specifications of VDDARM_CAP.

Is there?

Best Regards,

Nori Shinozaki