i.MX50: eFuse setting RD_BANK_OPEN OK nor not

[norishinozaki]

Hello Champs,

In the RM ver.2, page 2393, it says

"OCOTP_CTRL[RD_BANK_OPEN] : This bit is obsolete in i.MX50 and should not be set"

However in the OBDS, this bit is set here:

src/drivers/fuse/stmp_otp/stmp_otp.c

static int ReadOTPValues(

        // Open eFuses for reading

        HW_OCOTP_CTRL_SET(BM_OCOTP_CTRL_RD_BANK_OPEN);

Should we just follow the RM?

[norishinozaki]

Hello,

The customer says the OBDS code, setting RD_BANK_OPEN,  is working fine.

Do they disregard Reference Manual and just follow the OBDS code?

Best regards,

Nori Shinozaki

[norishinozaki]

Hello Champs,

OBDS is setting OCOTP_CTRL[RD_BANK_OPEN], though, RM ver.2, page 2393 says;

"OCOTP_CTRL[RD_BANK_OPEN] : This bit is obsolete in i.MX50 and should not be set"

OBDS code can set fuses fine, why should RD_BANK_OPEN" not be set?

I just like to confirm if it's just Ok to set the bit.

Best regards,

Nori Shinozaki

[jamesbone]

Hello Nori,

Please do not TURN ON this bit, it is not available in Silicon version 1.1.1 of the i.MX50 for previous version of the device it is still Ok to use it.  I hope this clarifies.

[norishinozaki]

Hello James,

Let me confirm  RD_BANK_OPEN bit again.

My customer is setting this bit.

Does it cause i.MX50 boot-up failures if the boot relies on the efuse setting which was programed by setting RD_BANK_OPEN 1?

Or does it just cause read failure when accessing with software which sets RD_BANK_OPEN then reads the efuse values?

Best regards,

Nori Shinozaki

[jamesbone]

Hello Nori,

Does it cause i.MX50 boot-up failures if the boot relies on the efuse setting which was programed by setting RD_BANK_OPEN 1?

ANSWER:  Yes, this can cause boot failures, because this efuse it is not longer available.

Have a great day,
Jaime

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

[norishinozaki]

Hello Jaime,

Thanks, No it doesn't fail to boot, even with setting RD_BANK_OPEN.

But I'm afraid it might cause any failure in some extreme condition such as high temperature.

Setting RD_BANK_OPEN is used when my customer *read" efuse values with this code in stmp_otp.c in OBDS.

static int ReadOTPValues(u32 * pau32Registers, u32 u32RegIndex, u32 u32Count)

{

    int i;                      // index used in for loops

    u32 u32Result = SUCCESS;

    for (i = 0; i < u32Count; i++) {

        if ((u32Result = Delay4Busy()) != SUCCESS) {

            goto done;

        }

        // Open eFuses for reading

        HW_OCOTP_CTRL_SET(BM_OCOTP_CTRL_RD_BANK_OPEN);

Do you mean this code may cause boot failure?

At first, isn't it Ok to use stmp_otp.c for i.MX502?

Best regards,

Nori Shinozaki

[norishinozaki]

Hello James,

Thanks for the info.

Do you have any idea what is will happen if this bit is set in rev 1.1.1 silicon?

They are doing this unfortunately...

I looked for the silicon version in RM and found out ID_CODE.

What is the bit value for ver. 1.1.1 silicon?

My customer is using MCIMX502CVM8B.

Best regard,

Nori Shinozaki

[jamesbone]

Hello Nori,

Unfortunately  the behavior wiil be erratic, there is no path or idea about what it is going to occur. My recommendation would be that avoid to write it down if they are already done it, then test it . In normal  conditions.

Have a great day,
Jaime

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

[norishinozaki]

Jaime,

Thanks!

So if they could set all eFuses correctly by setting RD_BANK_OPEN_OK first, that should be Ok.

Correct?

What value is the revision 1.1.1 anyway in the RM?

BR,

N.Shinozaki

[jamesbone]

Yes, that´s correct. Let me investigate about the  value in the register for 1.1.1

[norishinozaki]

Hello Jamesbone,

Did you find a clue for the register value?

BTW where is the IDCODE address?

This one?

But I can't access to 0xB0C00000 with memtool.

root@freescale /unit_tests$ ./memtool 0xB0C00000 1

Reading 0x1 count starting at adUnhandled fault: external abort on non-linefetch (0x1018) at 0x2aaca000

dress 0xB0C00000

I also found the Debug ROM is mapped at 0x40000000 in System Memory Map,

But I read 00000000 at 0x40000000.

Where should I look at to know the revision?

Best regards,

N.Shinozaki

[jamesbone]

Hello Nori,

I am doing the research internally since the information it is not available in public.  I let you know as soon as get a response.

[norishinozaki]

Hello James,

Thanks, please use SR# 1-4140420901 if you need somewhere to respond.

Best regards,

Nori Shinozaki

[norishinozaki]

Hello James,

Any updates?

I don't believe there is no way to know the chip revision.

Best regards,

Nori Shinozaki