OTP Issue with GP Word 0

[lpcware]

Content originally posted in LPCWare by ArriaLive on Mon Aug 03 20:12:59 MST 2015
First, I appreciate the help that so many provide on this forum!

I am working on a project that uses an LPC4330 processor.  We've been working with the processor for some time and have a great deal of experience and success with it.  However, I'm running into an issue with OTP that I need help with.

I am trying to write 3 words to the OTP.  I write two words (a MAC address) to the GP registers 1 and 2 (actually 6 bytes, so two bytes of GP register 1 are masked off).  This works great.

We have also set the boot code to boot from SPIFI.  That works great as well.

However, I then write a non-zero 32-bit code to GP register 0 (which is OTP bank 3, register 1), and the write fails.  The value always reads back as zero, suggesting that no fuses are blown, but the error code returned by the ROM API is 0x70002 which, according to the documentation means "ERR_OTP_SOME_BITS_ALREADY_PROGRAMMED."

So, OTP bank 3, registers 0, 2, and 3 work fine, but OTP bank3 register 1 (GP register 0) does not.

This has been repeated on 4 different processors with exactly the same results.

I have tried the OTP.1 recommended fix, but with no change in results.

Can someone shed light on why GP register 0 doesn't work and the others do?  Hopefully someone can help me figure out how to write to the GP register 0?

Thanks!

[lpcware]

Content originally posted in LPCWare by ArriaLive on Tue Aug 04 18:37:35 MST 2015
LPCXpresso support,

As a follow up, writing the GP registers in order works great.  Writing them out of order does not.  One of our team indicated that they had found information in an AppNote that this was a known bug in the 43xx processor, but we have not been able to find that information again.  Still, apparently order matters.

Thanks,

[lpcware]

Content originally posted in LPCWare by ArriaLive on Tue Aug 04 09:10:25 MST 2015
LPCXpresso support,

Thank you for the reply.  I, too, had read and studied the OTP documentation and came to the same understanding of OTP.  I still wonder why a word that is read as all zeros in the OTP could possibly already have bits set and return the error?

I have one new piece of information, however.  We had been writing to GP2_1, followed by GP2_2, followed by GP2_0.  We were not writing them in order.  The GP2_0 is the one that failed.  And once it failed, there was no way to write to it ever again (even thought the value remains all zeros).

However, late last night we tried writing in sequential order GP2_0, GP2_1, GP2_2, and that worked!  Apparently, you cannot write these words out of order.  Could that be a problem?  I am testing this with additional processors (although, I admit that burning a processor for every test is getting a little excessive).

Please test the out of order writes.  The in-order write is certainly a valid work around, but if that is the case it should at least be documented.

I also read that it takes about 1.6ms (application note) for a fuse to blow.  Could it be that when writing out of order we need to wait a couple ms before writing an out-of-order word?

Thanks,

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Aug 04 01:59:18 MST 2015
From my reading of OTP memory and underlying ROM functions, I have outlined this area of the OTP.

OTP Bank 3 contains 4 words mapped to address 0x40045030

Word 0 (0x40045030) - contains the boot source and JTAG disable and can be accessed through ROM functions:
otp_ProgBootSrc
opt_ProgJTAGDis

Word 1 (0x40045034) - is general purpose or USBID and is accessed through ROM functions:
otp_ProgUSBID or
otp_ProgGP2_0

Word 2 (0x40045038) - is general purpose and accessed through ROM function:
otp_ProgGP2_1

Word 3 (0x4004503C) - is general purpose and accessed through ROM function:
otp_ProgGP2_2

If you try to write multiple bits where any one of them is already set, you will see the error "ERR_OTP_SOME_BITS_ALREADY_PROGRAMMED.".

In my tests, I have written to words GP2_0, GP2_1 and GP2_2 without problem.

If you have not already done so, I suggest you take a look at the underlying mapped memory and check the value at the location you are trying to program and see if this sheds light on the situation.