Programming fuses fails on some RT1051

[giuseppescarpi]

Hello fellow engineers,

I'd like to ask if some of you ever experienced problems in writing fuses on i.MX RT processors.

In production, we write the BT_FUSE_SEL to allow our device to start from QSPI.

We have had a small but significant number of cases where the writing operation seems to succeed, but the change is not permanent, so once we cycle power the board, the firmware does not start.

Please note that normally the operation succeeds!

Someone else experienced this problem? Suggestions?

Thanks. Please find below the code we use.

Giuseppe

    if (!(SRC->SBMR2 & SRC_SBMR2_BT_FUSE_SEL_MASK))  // ( check the bit if new device or not )
    {
        //ipg_clk=132MHz, Calculation described at Chapter 42.3.3 OTP Read/Write Timing Parameters
        int timing = OCOTP_TIMING_STROBE_PROG(1325) | OCOTP_TIMING_RELAX(2) | OCOTP_TIMING_STROBE_READ(11) |OCOTP_TIMING_WAIT(24);
        OCOTP->TIMING = timing;
        //Check that HW_OCOTP_CTRL[BUSY] and HW_OCOTP_CTRL[ERROR]are clear
        while ((OCOTP->CTRL & (1<<OCOTP_CTRL_BUSY_SHIFT)) || (OCOTP->CTRL & (1<<OCOTP_CTRL_ERROR_SHIFT)))
            ;
        // Page 6 bank 0 = 0x460
        uint32_t fuses = OCOTP->CTRL;
        fuses &= ~(OCOTP_CTRL_ADDR_MASK | OCOTP_CTRL_WR_UNLOCK_MASK);
        fuses |= OCOTP_CTRL_ADDR(6) | OCOTP_CTRL_WR_UNLOCK(0x3E77);
        OCOTP->CTRL = fuses;
        fuses = OCOTP->DATA;
        fuses |= (long)((1<<4));//burn BT_FUSE_SEL (1<<4)
        OCOTP->DATA = fuses;
    }

[jeremyzhou]

Hi  Giuseppe Scarpi,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, whether you can tell me what proportion of the issue happens in the sample chip.
In my experience, the Fuse field won't change after OCOTP Write operation success.
I'd like to suggest you reload the Fuse field after OCOTP Write operation to confirm the field be programmed successfully. In addition, there's ocotp demo project in the SDK library, please give a try for testing.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[giuseppescarpi]

Hi Jeremy,

the proportion at the moment is rather low - say 3-4 parts over 1000. Anyway, this should never happen, so I am worried that something is wrong in our process.

On defective parts, the failure happens systematically, even if we cycle power the board many times.

We detect that something went wrong because, after cycle power, the check:

if (!(SRC->SBMR2 & SRC_SBMR2_BT_FUSE_SEL_MASK)) 

fails, indicating that SBMR2 was not written.

[jeremyzhou]

Hi  Giuseppe Scarpi,

Thanks for your reply.
I'd like to suggest you run the aforementioned ocotp demo project for testing again, in addition, the NXP has provided another way to program the field, maybe you can give a try.
NXP-MCUBootUtility is a GUI tool specially designed for NXP MCU secure boot, it supports common eFuse memory operation.

Have a great day,
TIC

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------