Usage of OCOTP peripheral to write eFuses

[rmaisto]

I have a custom board based on i.MX RT 1064. The BOOT_MODE pins are set to 00, having the micro booting from eFuses. That's because we don't have gpio availables to override boot_cfg.

In order to write eFuses I have to write an application loaded in RAM that uses OCOTP peripheral.

There is one thing I have not clear.

In the SDK documentation of OCOTP, about the function https://mcuxpresso.nxp.com/api_doc/dev/3151/a00055.html#ga43636ab96125958c9a14fe82c176e33e

The field address states "the fuse address to be written". Does it mean the address from the fusemap? in our case that would be 0x460, or the address of the OCOTP map? that would be ADDR 6.

Thanks for your help.

[EdwinHz]

Hi @rmaisto,

The "fuse address to be written" refers to the address of the OCOTP map, rather than the fusemap directly. I found another community post that will prove very useful for your inquiry, please check it out: https://community.nxp.com/t5/i-MX-RT/How-to-burn-BT-FUSE-SEL-on-RT1050/m-p/809581/highlight/true#M10...

BR,

Edwin.

[rmaisto]

I successfully managed to write the BIT_FUSE_SEL bit in the eFuse register, using the OCOTP SDK example just changing address and value.

In our custom board we have BOOT_MODE[1:0] = 00b and BOOT_CFG[11:0] = 0 to boot from internal flash.

Using these settings on the evaluation board (mimxrt1064-evk) works smoothly letting me debug.

On our custom board I just get to some out of program address and can't debug (it behaves just like before flashing the BIT_FUSE_SEL bit, when the mcu booted to to Serial Downloader instead of program).

Is there something on the evaluation board that makes it boot correctly and maybe we miss something on our custom board?

[comp1]

We ran into a similar issue on our custom board with the MIMXRT1021xxx4A and it was with the boot pins being used as inputs.

The internal boot mode reads the GPIO Boot Override pins EMC-18 through EMC-27 and our board had 2 interrupt lines for a sensor EMC_18+19 and a CAN bus line EMC_20 holding the lines high, which set BOOT_CFG[0-2] to EncryptedXIP HyperFlash 3V3.

By connecting both BOOT_MODE pins to ground, then blowing BT_FUSE_SEL=1, the device will use the eFuse settings, which are all 0 by default (FlexSPI boot) and it ignores the GPIO Boot Override pins (BOOT_CFG).

[rmaisto]

In our case BOOT_MODE pins are already forced to ground and BT_FUSE_SEL is set to 1.