Error reading efuse BOOTCFG0 - Error 52805

[dachancellor]

We plan to boot our program for serial NOR flash on FlexComm SPI 1.

I went through the following steps:

Read efuse 96 - result = 0x0

Write 0x00020000 to efuse 96 to set REDUNDANT SPI PORT 1 - result = success

Read efuse 96 - result = 0x20000

Write 0x00020007 to efuse 96 to set FlexComm SPI as primary boot source - result = success

Read efuse 96 - result = ERROR 52805 (kStatus_OTP_EccCheckFail - ECC check failed during OTP operation

Now, any read of efuse 96 results in this error.  I read some other efuses (97-99) successfully.  I am sure the write to 96 succeeded as reported, as the program I wrote to our serial NOR runs on power up.

Any suggestions ? 

[gusarambula]

Hello dachancellor,

This error is reported by the opt_fuse_read function when the OTP ECC Check has failed.

The fuses are One Time Programable (OTP). Technically speaking the fuses can only transition from 0 to 1, so you are able to write a new value if it can be written by only changing zeros to ones. However, the ECC would fail on the second write as you can’t assure that the new ECC will only cause zero-to-one transitions.

My apologies for the inconvenience.

Regards,
Gustavo

[dachancellor]

Hi Gustavo,

Thank you for the response, but I'm a little confused.

The error is reported in the fuse read after the second write, but the second write was successful, as indicated by the fact I am successfully booting from serial nor on flex comm spi 1.

I understand that the fuses are one time programmable from 0 to 1. Are you saying that the entire 32 bit register has to be written once and only once, and a second write will make the read fail forever ? (ie, Had I written 0x00020007 then subsequent reads would report correctly as long as I never tried to write that register again ?)

The reference manual has a 3rd parameter, bool lock, for the otp_write_fuse function.  The documentation is lacking, but I assumed writes would be locked out if this was set to true when calling the function.  I have always passed false, and I seem to have written successfully twice, but my read is broken.  I also assume that if I was to do the write with that flag set to true, then subsequent writes would return an error indicating it was "locked".

[gusarambula]

Hello dachancellor,

I agree that the documentation could be better, my apologies for that. However, in this case it’s not so much that the OTP is locked, rather that the ECC for the new value would be invalid.

Leaving the lock parameter aside, the OTP can electrically just transition from zeros to ones, so if you want to write a new value it will send the instruction, but any one to zero transitions wouldn’t have any effect. That means that it is valid to write the OTP again to go from 0x20000 to 0x20007, as only zero to one transitions are required.

The problem is that the Error Correction Code, the ECC will be calculated for the value you have written, in this case 0x20000. The new value would have a new ECC, but if the new ECC requires a one to zero transition, it won’t be saved, leaving an outdated ECC.

Answering your question, yes, writing 0x00020007 would be successful on an i.MXRT1060 where this fuse had not been blown before.

I hope that this information helps.

Regards,
Gustavo