13. OTP

RP2350 provides 8 kB of one-time programmable storage (OTP), which holds:

• • Preprogrammed per-device information, such as unique device identifier and oscillator trim values
• • Security configuration such as debug disable and secure boot enable
• • Public key fingerprints for secure boot
• • Symmetric keys for decryption of flash contents into SRAM
• • Configuration for the USB bootloader, such as customising VID/PID and descriptors
• • Bootable software images, for low-cost flashless applications or custom bootloaders
• • Any other user-defined data, such as per-device personalisation values

For the full listing of predefined OTP contents, see Section 13.10 .

OTP is physically an array of 4096 rows of 24 bits each. You can directly access these 24-bit values, but there is also hardware support for storing 16 bits of data in each row, with 6 bits of Hamming ECC protection and 2 bits of bit polarity reversal protection, yielding an ECC data capacity of 8192 bytes.

On a blank device, the OTP contents is all zeroes, except for some basic device information pre-programmed during manufacturing test. Each bit can be irreversibly programmed from zero to one. To program the OTP contents:

• • Directly access the registers using the SBPI bridge
• • Call the bootrom otp_access API ( Section 5.4.8.21 )
• • Use the PICOB00T interface of the USB bootloader ( Section 5.6 )

RP2350 enforces page-based permissions on OTP to partition Secure from Non-secure data and to ensure that contents that should not change do not change. The OTP address space is logically partitioned into 64 pages, each 64 rows in size, for a total of 128 bytes of ECC data per page. Pages initially have full read-write permissions, but can be restricted to read-only or inaccessible for each of Secure, Non-secure and bootloader access.

The page permissions themselves are stored in OTP. Locking pages in this way is an irreversible operation, referred to as hard locking . The hardware also supports soft locking , where a page's permissions are further restricted by writing to the relevant register in SW_LOCK0 through SW_LOCK63 ; this restriction remains in effect until the next OTP reset. Resetting the OTP block also resets the processors, so soft locking can be used to restrict the availability of sensitive content like decryption keys to early boot stages.

OTP access keys ( Section 13.5.2 ) provide an additional layer of protection. A fixed challenge is written to a write-only OTP area. Pages registered to that key require the key to be entered to a write-only register in order to open read or write access. This supports configuration data that can be accessed or edited by the board manufacturer, but not by general firmware running on the device.

13.1. OTP address map

The OTP hardware resides in a 128 kB region starting at 0x40120000 (OTP_BASE in the SDK). Bit 16 of the address is used to select either the OTP control registers, in the lower 64 kB, or one of the OTP read data aliases, in the upper 64 kB of this space.

The OTP control registers ( Section 13.9 ) are aliased at 4 kB intervals to implement the usual set, clear, and XOR atomic write aliases described in Section 2.1.3 .

The read data region starting at 0x40130000 divides further into four aliases:

• • 0x40130000 , OTP_DATA_BASE : ECC read alias. A 32-bit read returns the ECC-corrected data for two neighbouring rows, or all-ones on permission failure. Only the first 8 kB is populated.

• • 0x40138000 , OTP_DATA_GUARDED_BASE : ECC guarded read alias. Successful reads return the same data as OTP_DATA_BASE . Only the first 8 kB is populated.
• • 0x40134000 , OTP_DATA_RAW_BASE : raw read alias. A 32-bit read directly returns the 24-bit contents of a single row, with zeroes in the eight MSBs, or returns all-ones on permission failure.
• • 0x4013c000 , OTP_DATA_RAW_GUARDED_BASE : raw, guarded read alias. Successful reads return the same data as OTP_DATA_RAW_BASE .

Bit 14 of the address selects ECC (0) vs raw (1). Bit 15 of the address selects unguarded (0) vs guarded (1) access. Guarded reads return the same data as unguarded reads, but perform additional hardware consistency checks and return bus faults on permission failure. For more information, see Section 13.1.1 .

! IMPORTANT

The read data regions starting at 0x40130000 are accessible only when USR.DCTRL is set, otherwise all reads return a bus error response. This bit is clear when the OTP is being programmed via the SBPI bridge.

Writing to the read data aliases is not a valid operation, and will always return a bus fault. The OTP is programmed by the SBPI bridge, which is used internally by the bootrom otp_access API, Section 5.4.8.21 .

13.1.1. Guarded reads

Reads through the guarded aliases differ from unguarded reads in the following ways:

• • Permission failures return bus faults rather than a bit pattern of all-ones.
• • Uncorrectable ECC errors return a bus fault if detected.
• • Guarded reads perform an additional hardware consistency check to detect power transients. If this check fails, the read returns a bus fault.

These checks help to make the OTP fail-safe in contexts where deliberate fault injection is a possibility. For example, the RP2350 bootrom uses guarded reads to check boot configuration flags.

The data returned from a successful guarded read is the same as the data returned by a successful read from the corresponding unguarded alias.

! IMPORTANT

Users relying on OTP data in a Secure context should always perform guarded reads, and it is strongly recommended to use ECC. For rows where ECC is not possible, software should take care to ensure the consistency of data across multiple overlapping reads.

13.2. Background: OTP IP details

The RP2350 OTP subsystem uses the Synopsys NVM OTP IP, which comes in 3 parts:

• • Integrated Power Supply (IPS), including:
  • ◦ Charge Pump (for programming)
  • ◦ Regulator (for reading)
• • OTP Macro (SHF, Fuse)
  • ◦ \( 4096 \times 24 \) (8 kB with ECC, 16-bit ECC write granularity)
• • Access port (AP), providing:

• ◦ Basic read access
• ◦ Programming access
• ◦ ECC and bit redundancy
• ◦ BOOT function, which polls for stable OTP power supply at start-of-day

13.3. Background: OTP hardware architecture

This diagram shows the integration of the three Synopsys IP components, and the Raspberry Pi hardware added to make this all function in the context of RP2350's system and security architecture. More specifically:

• • APB interface(s) to connect to the SoC
• • Internal ring oscillator with clock edge randomisation
• • Power-up state machine, running off the ring oscillator
• • Lock shim, sitting between the SNPS RTL and the memory core (fuse)

Figure 142. OTP architecture

The OTP subsystem clock is initially provided by the OTP boot oscillator (Section 13.3.3) during hardware startup, but switches to clk_ref before any software runs on the processors. The frequency of clk_ref must not exceed 25 MHz when accessing the OTP.

13.3.1. Lock shim

The lock shim is inserted between the Synopsys AP block and the SHF block, and is used to enforce read/write page locks, based on:

• • The OTP address presented on the AP → SHF bus
• • The read/write strobe on the AP → SHF bus
• • The security attribute of the upstream bus access which caused this SHF access (assumed to be Secure if SBPI is currently enabled via USR.DCTRL )

Because the Synopsys AP performs both reads and writes in the course of programming an OTP row, it is impossible to disable reads to an address without also disabling writes. Three lock states are supported:

• • Read/Write
• • Read-only
• • Inaccessible

The full locking scheme is described in in Section 13.5 , but to summarise:

• • The lock state of each OTP page is read from OTP at boot time.
• • There is a separate copy of the lock state for Secure/Non-secure accesses. The lock shim applies the Secure read permissions to Secure reads, and the Non-secure read permissions to Non-secure reads. There is no such rule for writes, because Non-secure code is not capable of accessing the programming hardware.
• • The lock encoding in OTP storage is such that a page can always be locked down to a less permissive state (in the order RW → RO → Inaccessible) but can never return to a more permissive state.
• • Software can advance the state of each individual lock at runtime without programming OTP, and this lasts until the OTP PSM is re-run.
• • Software locks also obey the lock progression order (RW → RO → Inaccessible) and can not be regressed.

The full locking scheme is described in in Section 13.5 .

13.3.2. External interfaces

The OTP integration has one upstream APB interface, which splits internally onto two separate interfaces. This guarantees the hardware only serves a single upstream APB access at a time, with a single PPROT security level.

The first APB interface is the data interface (or data bridge) (OTPD). It has the following characteristics:

• • Read-only
• • Connects to the Synopsys device access port (DAP)
• • Data interface reads always return 32 or 24 bits of valid data
• • The data interface address is rounded down to a multiple of 32 bits, so that narrow reads return the correct byte lanes
• • There is an 8 kB window which supports 32-bit ECC reads
  • ◦ Each upstream bus read is split into two OTP accesses, each of which returns 16 bits of error-corrected data from the OTP
• • There is an 8 kB window which supports guarded 32-bit ECC reads, and returns a bus error if the guarding read fails.
  • ◦ Functions the same as the ECC read window, but reads the Synopsys boot word before accessing the OTP array, and return a bus error if the first read does not match the expected constant
  • ◦ Used to increase confidence in software OTP reads in the bootrom
• • There is a 16 kB window which supports 24-bit raw reads
  • ◦ Each access returns a single raw 24-bit OTP row, bypassing error correction
  • ◦ Software must provide its own redundancy (e.g. triple majority vote)
  • ◦ Allows bit-mutable data structures, such as boot flags, or thermometer counters

The second APB interface is the command interface. This provides two main functions:

• • Provides a bridge to the SBPI interface (Synopsys proprietary Serial and Byte-Parallel Interface bus)
  • ◦ SBPI connects to the Programmable Master Controller (PMC), with access to the DAP, DATAPATH, charge pump (IPS), and fuse memory (SHF)

• ◦ Allows arbitrary OTP operations, including programming
• ◦ Only accessible to Secure reads and writes
• • Provides control registers for Raspberry Pi hardware
  • ◦ Registers have different accessibility according to Secure/Non-secure and read/write
  • ◦ Software lock registers are always readable by both security domains

Hardware configuration data read from OTP during the power-up sequence drives system-level control signals, e.g. disabling CoreSight APs. This is described in more detail in (Section 13.3.4).

A single system-level interrupt output (IRQ) generates interrupts for the following sources:

• • Secure read failed due to locks
• • Non-secure read failed due to locks
• • Write failed due to locks
• • SBPI FLAG, used by the PMC to signal completion
• • Data port access when DCTRL is set error
  • ◦ USR.DCTRL tells the SNPS AP whether the SBPI bridge or data bridge can access the memory array; this help debugging SW if a data access is attempted whilst the DAP is inaccessible

Any failed access also returns a bus fault ( PSLVERR ). To determine whether an OTP address is accessible, query the lock tables.

Non-secure code cannot access the interrupt status registers.

13.3.3. OTP boot oscillator

The OTP startup sequence (Section 13.3.4) runs from a local ring oscillator, dedicated to the OTP subsystem. This is separate from the system ring oscillator (the ROSC) which provides the system clock to run the processors during boot.

• • The OTP boot oscillator is the only clock used by the OTP power-up state machine
• • The OTP boot oscillator dynamically randomises its own frequency controls, to deliberately add jitter to the clock
• • The OTP boot oscillator stops when the PSM completes, and does not start again until the OTP resets
• • The OTP clock automatically switches to clk_ref when the OTP boot oscillator stops

The boot oscillator has a nominal frequency of 12MHz. It provides the clock for reading out hardware configuration from OTP, including the critical flags (Section 13.4) which configure hardware security features such as debug disable and the glitch detectors.

Keeping this oscillator local to the OTP hardware subsystem reduces the power signature of the clock itself, due to the lower switched clock capacitance. Along with the random jitter of the frequency controls, this helps frustrate attempts to recover OTP access keys and debug keys via power signature analysis attacks, or to disable security features by timing fault injection against the OTP clock.

Only the OTP boot oscillator enables the ROSC frequency randomisation feature by default: for later operations using the system ROSC (Section 8.3), you must explicitly enable this feature on that oscillator, by programming the ROSC control registers. The crystal oscillator (XOSC) does not support frequency randomisation.

13.3.4. Power-up state machine

The OTP is the second item in the switched core domain's Power-On State Machine (Section 7.4), after the processor cold reset. OTP does not release its rst_done , or enable any debug interface (including the factory test JTAG described in Section 10.10), until the OTP PSM reads out OTP-resident hardware configuration. The rst_done output to the system

PSM holds the rest of the system in reset until the OTP PSM completes, so that no software runs until the OTP's contents are known.

The OTP boot sequence runs from a local ring oscillator. This oscillator is dedicated to the OTP subsystem, and is separate from the main system ROSC used by the processors at boot. The sequence is:

1. 1. First, the PSM runs the Synopsys boot instruction. This has the following steps:
   1. a. Wait for the power supply to return a 'good' value.
   2. b. Read consistency check location until hardware sees the correct value for 16 successive reads. Consistency checks use predefined words stored in mask ROM cells with similar analogue properties to OTP cells.
2. 2. Read critical flags (non-ECC): each critical bit is redundant across 8 OTP rows, with three-of-eight vote for each flag.
3. 3. Read hardware access keys via ECC read interface.
4. 4. Read valid bits for hardware access keys, including the debug keys ( Section 3.5.9.2 )
5. 5. Initialise page lock registers from the lock page via raw read interface.
6. 6. Assert rst_done signal to the system power-on state machine
7. 7. The system reset sequence continues, starting with the system ROSC

RP2350 A3 adds correctness checks and robustness to the PSM. For more information about these additions, see RP2350-E16 .

13.4. Critical flags

Critical flags enable hardware security features which are fundamental to RP2350's secure boot implementation. The OTP power-up state machine reads critical flags very early in the system reset sequence, before any code runs on the processors.

Most critical flags are in the main Boot Configuration page, page 1. These are listed under CRIT1 in the OTP data listing. The exceptions are the Arm/RISC-V disable flags, which are in the Chip Info page, page 0. This page is made read-only during factory programming, so users can not write to the CRIT0 flags.

Critical flags define 0 as the unprogrammed value, and 1 as the programmed value. On a blank device, all of the CRIT1 flags are 0 . The reset value specified below is the value assigned to the internal logic net between the OTP reset being applied and the OTP PSM completing. For example, the reset value of 1 for the debug disable flags implies that debug is not accessible whilst the OTP PSM is running, but may be available afterward, depending on the value read from OTP storage.

• • ARM_DISABLE (reset: 0 ): Force the ARCHSEL register to RISC-V, at higher priority than RISC-V disable flag, secure boot enable flag, or default boot architecture flag.
• • RISCV_DISABLE (reset: 0 ): Force the ARCHSEL register to Arm, at higher priority than the default boot architecture flag.
• • SECURE_BOOT_ENABLE (reset: 1 ): Enable boot signature checking in bootrom, disable factory JTAG, and force the ARCHSEL register to Arm, at higher priority than the default boot architecture flag.
• • SECURE_DEBUG_DISABLE (reset: 1 ): Disable factory JTAG, block Secure accesses from Mem-APs, and block halt requests to Secure processors.
  • ◦ Prevents secure AP accesses by masking their ap_secure_en signals.
  • ◦ Prevents secure processor halting by masking the Cortex-M33's SPIDEN and NSPIDEN signals.
  • ◦ Secure debug can be re-enabled by a Secure register in the OTP block.
  • ◦ Re-enable of Secure debug can be disabled by a Secure write-1-only lock register, also in the OTP block.
• • DEBUG_DISABLE (reset: 1 ): Completely disable the Mem-APs, in addition to disabling everything disabled by the secure

debug disable flag.

• • BOOT_ARCH (reset: 0): set the reset value of the ARCHSEL register (0 → Arm, 1 → RISC-V) if it has not been forced by other critical flags.
  • ◦ Not critical, but hardware-read.
• • GLITCH_DETECTOR_ENABLE (reset: 0): pass an enable signal to the glitch detectors so that they can be armed before any software runs.
• • GLITCH_DETECTOR_SENS (reset: 0): configure the initial sensitivity of the glitch detector circuits.

Critical flags are encoded with a three-of-eight vote across eight consecutive OTP rows. Each flag is redundantly programmed to the same bit position in eight consecutive rows. Hardware considers the flag to be set if the bit reads as 1 in at least three of these eight rows. The flag is considered clear if no more than two bits are observed to be set.

i NOTE

As of RP2350 A3 the ARM_DISABLE flag has no effect, removing a potential unlock path for debug on a secured RP2350. Additionally, the combination of RISCV_DISABLE=1 and BOOT_ARCH=1 is decoded to an invalid state and the chip will not boot.

JTAG disable is ignored only if the customer RMA flag ( Section 13.7 ) is set.

For further discussion of the effects of the critical flags, see:

• • Section 3.5.9.1 for the effects of the debug disable flags
• • Section 3.9 for the effects of the Arm/RISC-V architecture select flags
• • Section 10.9 for the effects of the glitch detector configuration flags
• • Section 10.1.1 for discussion of the bootrom secure boot support enabled by the SECURE_BOOT_ENABLE flag

13.5. Page locks

The OTP protection hardware logically segments OTP into 64 pages (0 through 63), each 128 bytes in size, or equivalently 64 OTP rows.

Each page has a set of lock registers which determine read and write access for that page from Secure and Non-secure code. The lock registers are preloaded from OTP at reset, and can then be advanced (i.e. made less permissive) by software. Lock registers themselves are always world-readable.

Pages 61 through 63 are not so neatly described by a single set of lock registers. These pages store lock initialisation metadata. For more details, see Section 13.5.4 . This section describes the more common case of a page protected by a set of page locks.

13.5.1. Lock progression

Due to hardware constraints ( Section 13.3.1 ), read and write restrictions are not orthogonal: it's impossible to disallow reads to an address without also disallowing writes. So, the progression of locking for a given page is:

1. 0. Read/Write
2. 1. Read-only
3. 2. Inaccessible

Lock state only increases . This is enforced in two ways:

• • Due to the nature of OTP and the choice of encoding, you cannot lower the OTP values preloaded to the lock registers during boot.

• • The lock registers ignore writes of lower-than-current values.

Secure and Non-secure use separate lock values, which can advance independently of one another. There is no hardware distinction between Non-secure Read/Write and Non-secure Read-only, since Non-secure can not directly write to the OTP anyway. It is still worth encoding, because Secure software performing a write on Non-secure software's behalf can check and enforce the Non-secure write lock.

You can reprogram bits from any state to any higher state. Locks use a 2-bit thermometer code: the initial all-zeroes state is read-write, and locks are advanced by programming first bit 0, then bit 1.

Lock bits in OTP are triple-redundant with a majority vote. They can't be ECC-protected, because they may be mutated bit-by-bit over multiple programming operations.

The OTP-resident lock bits are write-protected by their own Secure lock level. The lock pages are always world-readable.

The Secure lock registers can be advanced by Secure code, and are world-readable.

The Non-secure lock registers can be advanced by Secure or Non-secure code, and are world-readable.

13.5.2. OTP access keys

Page 61 contains 128-bit keys. Each key has a valid bit : when set, the key becomes completely inaccessible to software. The keys are always read out into hidden registers by hardware during startup so that hardware can perform key comparisons without exposing the keys to software.

Pages can require specific keys for some page permissions. To unlock the page, the user writes their key to a write-only register in the OTP block. The page remains unlocked for as long as the correct key is present in this register. To re-lock the page, erase the active key by writing zeroes to the key register.

The per-page lock config specifies the following:

• • a read key index 1-7, or 0 if there is no read key
• • a write key index 1-7 or 0 if there is no write key
• • the no-key state : either Read-only or Inaccessible, state of the page when no registered key has been entered by software into the key register

The no-key state is encoded as follows:

• • 0 for Read-only (lock level 1)
• • 1 for Inaccessible (lock level 2).

TIP

Key index 7 does not exist in the configuration. If you specify key index 7, it is guaranteed to never match.

The hardware determines the key lock level by comparing the entered key to the key config of the current page, as follows:

1. 1. If no keys are registered, the key lock level is 0
2. 2. Else if keys are registered and no matching key is entered, the key lock level is 2 or 1 depending on the "no-key state" config
3. 3. Else if a write key is registered and present, the key lock level is 0
4. 4. Else if a read key is registered and present, the key lock level is 1

Hardware compares the key lock level to the page's lock level for the current security domain (Secure/Non-secure) and takes whichever is higher . For example, if a page has been made Non-secure read-only, there is nothing a key can do to make it Non-secure writable.

There are six 128-bit access keys stored in the OTP. Keys 5 and 6 also function as the Secure debug access key and

Non-secure debug access key, respectively. See Section 3.5.9.2 for information on how the debug keys affect external debug access.

You might use OTP access keys if a bootloader contains OTP configuration that needs to be Secure-writable only to the board owner , not to general Secure software on the device.

13.5.3. Lock encoding in OTP

Page locks are encoded as a 16-bit value. This value is stored as a pair of triple-redundant bytes, each byte occupying a 24-bit OTP row.

The lock halfword is encoded as follows:

13.5.4. Special pages

The following pages require special case handling in their lock checks:

• • The lock word region itself (pages 62 and 63)
  • ◦ Lock words are always world-readable
  • ◦ Lock words are writable by Secure code if the lock word itself permits Secure writes
  • ◦ Consequently, lock words 62 and 63 are considered "spare", since they do not protect pages 62 and 63; the page 63 lock word is repurposed for the RMA flag
• • The hardware access key page (page 61)
  • ◦ Contains OTP access keys and debug access keys
  • ◦ Each key also has a valid bit ( rbit )
  • ◦ Page 61 (key page) has all of the usual protections from the page 61 lock word
  • ◦ If a key's valid bit is set, that key is inaccessible; the converse is not necessarily true

Page 0, known as the chip info page , is not a special page. Raspberry Pi sets page 0 to read-only during factory test, after writing chip identification and calibration values.

13.5.5. Permissions of blank devices

Each RP2350 device has some information programmed during manufacturing test. At this time, a small number of hard page lock bits are also programmed:

• • Page 0, which contains chip information, is read-only for all accesses.
• • Pages 1 and 2, which contain boot config and boot key fingerprints, are read-only for Non-secure access, read-write for Secure access, and read-write for bootloader access.
• • Page 62, which contains only the page 62 lock word, is read-only for Non-secure access, read-write for Secure access, and read-write for bootloader access (as a partial workaround for RP2350-E28 ).
• • Page 63, which contains the RMA flag, is read-only for Non-secure and bootloader access, and read-write for Secure access.

This minimal set of default permissions on blank devices avoids certain classes of security model violation, like Non-secure code being able to brick the chip by overwriting the boot key fingerprints with invalid data. In this context, the term blank device refers to a device that has gone through manufacturing test programming, but has not had any other OTP bits programmed by the user.

You can add additional soft or hard locks to these default permissions, with the exception of page 0. Page 0 cannot be hard-locked, since the secure read-only permission prevents a user from altering its lock word.

Lock words 2 through 61, covering all pages with user-defined contents, are left unprogrammed. On a blank device, these pages are fully accessible from all domains. Before launching any Non-secure application, you should apply at least a soft read-only lock to all pages that are not explicitly allocated for Non-secure use. To do this, write to SW_LOCK2 through SW_LOCK61 . For devices that you don't expect to RMA, such as those that have passed board-level manufacturing tests, you should lock secure writes to the RMA flag.

13.6. Error Correction Code (ECC)

ECC-protected rows store data in the following structure, accessible through a raw alias:

• • Bits 23:22 : bit repair by polarity (BRP) flag
• • Bits 21:16 : modified Hamming ECC code
• • Bits 15:0 (the 16 LSBs): data

RP2350 stores the following error correction data in the 8 MSBs of each 24-bit row:

• • a 6-bit modified Hamming code ECC, providing single-error-correct and double-error-detect capabilities
• • 2 bits of bit repair by polarity (BRP), which supports inverting the entire row at programming time to repair a single set bit that should be clear

Writes first encode ECC, then BRP. Reads first decode BRP, then ECC. When reading through an ECC data alias ( Section 13.1 ), hardware performs correction transparently. ECC programming operations (writes) automatically generate ECC bits when you use the bootrom otp_access API ( Section 5.4.8.21 ).

ECC is not suitable for data that mutates one bit at a time, since the ECC value is derived from the entire 16-bit data value. When storing data without ECC, use another form of redundancy, such as 3-way majority vote.

13.6.1. Bit repair by polarity (BRP)

Bit repair by polarity (BRP) compensates for a single bit present at time of programming.

When programming a row, hardware or software first calculates a 24-bit target value consisting of:

• • Two zeroes in bits 23:22
• • 6-bit Hamming ECC in bits 21:16
• • 16-bit data value in bits 15:0

Before programming, an OTP row should contain all zeros. However, sometimes OTP rows contain a single bit that is already set to 1 , either due to manufacturing flaws or previous programming. If a bit is already set ( 1 ) in an OTP row

before programming, BRP checks the status of the corresponding bit in the target value. BRP compensates for this single set bit in one of two ways, depending on the corresponding value in the target value:

• • If the bit is clear (0), BRP inverts the target row and writes two ones in bits 23:22.
• • If the bit is set (1), BRP does not invert the target row, leaving two zeroes in bits 23:22.

When you read an OTP value through an ECC alias (Section 13.1), BRP checks for two ones in bits 23:22. When both bits 23 and 22 are set, BRP inverts the entire row before passing it to the modified Hamming code stage.

BRP makes it possible to store any 22-bit value in a row that initially has at most one bit set, preserving the correction margin of the modified Hamming code. During manufacturing test, hardware scans the entire OTP array to ensure no rows contain more than one pre-set bit.

13.6.2. Modified Hamming ECC

ECC generates six parity bits based on the data value stored in bits 15:0 of an OTP row. When programming a row, ECC generates those six parity bits and includes them in the target value as bits 21:16. This code consists of:

• • A 5-bit Hamming code that identifies single-bit errors
• • An even parity bit which allows two-bit errors to be detected in the Hamming code and the original 16-bit data

When you read an OTP value through an ECC alias (Section 13.1), ECC recalculates the six parity bits based on the value read from the OTP row. Then, ECC XORs the original six parity bits with the newly-calculated parity bits. This generates 6 new bits:

• • the 5 LSBs are the syndrome , a unique bit pattern that corresponds to each possible bit flip in the data value
• • the MSB distinguishes between odd and even numbers of bit flips

If all 6 bits in this value are zero, ECC did not detect an error. If the MSB is 1, the syndrome should indicate a single-bit error. ECC flips the corresponding data bit to recover from the error. If the MSB is 0, but the syndrome contains a value other than 0, the ECC detected an unrecoverable multi-bit error.

You can calculate 5-bit Hamming codes and parity bits with the following C code (adapted from the RP2350 bootrom source):

uint32_t even_parity(uint32_t input) {
    uint32_t rc = 0;
    while (input) {
        rc ^= input & 1;
        input >>= 1;
    }
    return rc;
}

const uint32_t otp_ecc_parity_table[6] = {
    0b0000001010110101011011,
    0b000000011011001101101,
    0b000001100011110001110,
    0b0000000001111110000,
    0b0000011110000000000,
    0b01111111111111111111
};

uint32_t s_otp_calculate_ecc(uint16_t x) {
    uint32_t p = x;
    for (uint i = 0; i < 6; ++i) {
        p |= even_parity(p & otp_ecc_parity_table[i]) << (16 + i);
    }
    return p;
}

}

13.7. Device decommissioning (RMA)

Decommissioning refers to destroying a device's sensitive contents and restoring some test or debug functionality when a device reaches the end of its security lifecycle. The OTP hardware can't actually destroy user data without circumventing write protection in some way. Instead, decommissioning is implemented with the RMA flag , which modifies devices in the following ways:

• • re-enables factory test JTAG which is otherwise disabled by the secure boot critical flag
• • makes pages 3 through 61 inaccessible

The RMA flag doesn't change permissions for page 0 (manufacturing data), pages 1 and 2 (boot configuration), page 61 (OTP access keys), or pages 62 and 63 (locks).

The RMA flag is encoded in a spare bit of the page 63 lock word. This lock word would otherwise be unused, since page 63 is one of the lock pages; consequently, it is not protected by a lock word. Instead, each lock word protects itself.

Like all other lock words, the page 63 lock word is protected by its own locks, which means it can be hard- and soft-locked to prevent the RMA flag being set. Locking the RMA flag makes it impossible to re-enable the factory JTAG interface if any of CRIT1.SECURE_BOOT_ENABLE , CRIT1.DEBUG_DISABLE or CRIT1.SECURE_DEBUG_DISABLE is set. This makes it impossible for Raspberry Pi to re-test such devices if they are returned for fault analysis.

! IMPORTANT

Setting the RMA flag does not destroy OTP contents, it merely renders it inaccessible. The design intent is for this to be irreversible, but hardware is never perfect. This is something the user's threat model must account for when programming the RMA flag on devices with sensitive OTP contents – for example, by personalising per-device OTP secrets to avoid class breaks if an attacker is able to retrieve the keys.

13.8. Imaging Vulnerability

The RP2350 OTP is intended to store boot key fingerprints and boot decryption keys. The ability to protect encrypted contents in external flash storage depends on the ability to protect the OTP contents from unauthorised or external reads. The OTP uses antifuse bit cells, which store data as a charge, similar to a flash bit cell. They do not make use of a physical structural change as used in a traditional fuse cell. This makes them resistant to many imaging techniques, such as optical and scanning electron microscopy. However antifuse cells can be imaged using a novel technique called passive voltage contrast (PVC), using a focused ion beam (FIB) device.

PVC Whitepaper

For more information on passive voltage contrast imaging, read the whitepaper by IOActive:

https://www.ioactive.com/wp-content/uploads/2025/01/IOActive-RP2350HackingChallenge.pdf

This process involves decapsulating the die. Therefore physical access to the device is a strict requirement, and there is a moderate chance of destroying the die without being able to recover its OTP contents.

13.8.1. Best Practices

The following best practices minimise your susceptibility to imaging of OTP contents:

• • Provision unique keys per device, rather than sharing secrets across a fleet of devices.
• • Use chaff as described in the next section to make imaging more difficult.

13.8.2. Chaff

OTP bits come in pairs: two bits are stored in the isolated gates of two transistors, with a common bit line between them. This structure is known as a bit cell . In each 64-row OTP page, rows i and \( 32 + i \) share the same bit cells. For example, the ECC halfwords BOOTKEY0_0 and BOOTKEY2_0 are physically colocated.

The particulars of the PVC technique make it difficult to distinguish which of the two bits in a bit cell is set. If one bit in each pair is known to be zero – for example, a key stored at the bottom of an otherwise blank page – then the data can be trivially read from the PVC image. However the presence of unknown data in both bits frustrates these attempts. This fact can be exploited by storing data redundantly in the top and bottom half of each page. Specifically:

• • Store arbitrary data in each row i from 0 to 31.
• • Store the 24-bit bitwise complement of those values in each row \( 32 + i \) .

The bitwise operations specified here are on the entire 24-bit raw row contents, including the ECC bit pattern.

An alternative technique is to store a random value in row \( 32 + i \) and the XOR of that random value with the desired data value in row i . This is advantageous from a power side channel perspective because it avoids reading the secret value directly from OTP, and the example RP2350 encrypted bootloader uses a similar technique with a 4-way XOR. However the bitwise complement technique described above is recommended for pairwise chaff. This is the same as the XOR technique with a fixed XOR pattern of 0xfffff .

13.9. List of registers

The OTP control registers start at a base address of 0x40120000 (defined as OTP_BASE in the SDK).

Table 1332. List of OTP registers

OTP: SW_LOCK0, SW_LOCK1, ..., SW_LOCK62, SW_LOCK63 Registers

Offsets: 0x000, 0x004, ..., 0x0f8, 0x0fc

Description

Software lock register for page N .

Locks are initialised from the OTP lock pages at reset. This register can be written to further advance the lock state of each page (until next reset), and read to check the current lock state of a page.

Table 1333.
SW_LOCK0,
SW_LOCK1, ...,
SW_LOCK62,
SW_LOCK63 Registers

OTP: SBPI_INSTR Register

Offset: 0x100

Description

Dispatch instructions to the SBPI interface, used for programming the OTP fuses.

Table 1334.
SBPI_INSTR Register

OTP: SBPI_WDATA_0 Register

Offset: 0x104

Table 1335.
SBPI_WDATA_0
Register

OTP: SBPI_WDATA_1 Register

Offset: 0x108

Table 1336.
SBPI_WDATA_1
Register

OTP: SBPI_WDATA_2 Register

Offset: 0x10c

Table 1337.
SBPI_WDATA_2
Register

OTP: SBPI_WDATA_3 Register

Offset: 0x110

Table 1338.
SBPI_WDATA_3
Register

OTP: SBPI_RDATA_0 Register

Offset: 0x114

Table 1339.
SBPI_RDATA_0
Register

OTP: SBPI_RDATA_1 Register

Offset: 0x118

Table 1340.
SBPI_RDATA_1
Register

OTP: SBPI_RDATA_2 Register

Offset: 0x11c

Table 1341.
SBPI_RDATA_2
Register

OTP: SBPI_RDATA_3 Register

Offset: 0x120

Table 1342.
SBPI_RDATA_3
Register

OTP: SBPI_STATUS Register

Offset: 0x124

Table 1343.
SBPI_STATUS Register

OTP: USR Register

Offset: 0x128

Controls for APB data read interface (USER interface)

Table 1344. USR Register

Debug for OTP power-on state machine

Table 1345. DBG Register

During BIST, count address locations that have at least one leaky bit

Table 1346. BIST Register

OTP: CRT_KEY_W0 Register

Offset: 0x138

Table 1347.
CRT_KEY_W0 Register

OTP: CRT_KEY_W1 Register

Offset: 0x13c

Table 1348.
CRT_KEY_W1 Register

OTP: CRT_KEY_W2 Register

Offset: 0x140

Table 1349.
CRT_KEY_W2 Register

OTP: CRT_KEY_W3 Register

Offset: 0x144

Table 1350.
CRT_KEY_W3 Register

OTP: CRITICAL Register

Offset: 0x148

Description

Quickly check values of critical flags read during boot up

Table 1351. CRITICAL
Register

OTP: KEY_VALID Register

Offset: 0x14c

Table 1352.
KEY_VALID Register

OTP: DEBUGEN Register

Offset: 0x150

Description

Enable a debug feature that has been disabled. Debug features are disabled if one of the relevant critical boot flags is set in OTP (DEBUG_DISABLE or SECURE_DEBUG_DISABLE), OR if a debug key is marked valid in OTP, and the matching key value has not been supplied over SWD.

Specifically:

• • The DEBUG_DISABLE flag disables all debug features. This can be fully overridden by setting all bits of this register.
• • The SECURE_DEBUG_DISABLE flag disables secure processor debug. This can be fully overridden by setting the PROC0_SECURE and PROC1_SECURE bits of this register.
• • If a single debug key has been registered, and no matching key value has been supplied over SWD, then all debug features are disabled. This can be fully overridden by setting all bits of this register.
• • If both debug keys have been registered, and the Non-secure key's value (key 6) has been supplied over SWD, secure processor debug is disabled. This can be fully overridden by setting the PROC0_SECURE and PROC1_SECURE bits of this register.
• • If both debug keys have been registered, and the Secure key's value (key 5) has been supplied over SWD, then no debug features are disabled by the key mechanism. However, note that in this case debug features may still be disabled by the critical boot flags.

Table 1353. DEBUGEN Register

OTP: DEBUGEN_LOCK Register

Offset: 0x154

Description

Write 1s to lock corresponding bits in DEBUGEN. This register is reset by the processor cold reset.

Table 1354.
DEBUGEN_LOCK
Register

OTP: ARCHSEL Register

Offset: 0x158

Description

Architecture select (Arm/RISC-V). The default and allowable values of this register are constrained by the critical boot flags.

This register is reset by the earliest reset in the switched core power domain (before a processor cold reset).

Cores sample their architecture select signal on a warm reset. The source of the warm reset could be the system power-up state machine, the watchdog timer, Arm SYSRESETREQ or from RISC-V hartresetreq.

Note that when an Arm core is deselected, its cold reset domain is also held in reset, since in particular the SYSRESETREQ bit becomes inaccessible once the core is deselected. Note also the RISC-V cores do not have a cold reset domain, since their corresponding controls are located in the Debug Module.

Table 1355. ARCHSEL Register

OTP: ARCHSEL_STATUS Register

Offset: 0x15c

Description

Get the current architecture select state of each core. Cores sample the current value of the ARCHSEL register when their warm reset is released, at which point the corresponding bit in this register will also update.

Table 1356. ARCHSEL_STATUS Register

OTP: BOOTDIS Register

Offset: 0x160

Description

Tell the bootrom to ignore scratch register boot vectors (both power manager and watchdog) on the next power up.

If an early boot stage has soft-locked some OTP pages in order to protect their contents from later stages, there is a risk that Secure code running at a later stage can unlock the pages by performing a watchdog reset that resets the OTP.

This register can be used to ensure that the bootloader runs as normal on the next power up, preventing Secure code at

a later stage from accessing OTP in its unlocked state.

Should be used in conjunction with the power manager BOOTDIS register.

Table 1357. BOOTDIS Register

OTP: INTR Register

Offset: 0x164

Description

Raw Interrupts

Table 1358. INTR Register

OTP: INTE Register

Offset: 0x168

Description

Interrupt Enable

Table 1359. INTE Register

OTP: INTF Register

Offset: 0x16c

Description

Interrupt Force

Table 1360. INTF Register

OTP: INTS Register

Offset: 0x170

Description

Interrupt status after masking & forcing

Table 1361. INTS Register

13.10. Predefined OTP data locations

This section lists OTP locations used by either the hardware (particularly the OTP power-on state machine), the bootrom, or both. This listing is for RP2350 silicon revision A2.

OTP locations are listed by row number, not by address. When read through an ECC alias, OTP rows are spaced two bytes apart in the system address space; when read through a raw alias, OTP rows are four bytes apart. Therefore the row numbers given here should be multiplied by two or four appropriately when reading OTP contents directly from software. The OTP APIs provided by the bootrom use OTP row numbers directly, so this row-to-byte-address conversion is not necessary when accessing OTP through these APIs.

For normal (non-guarded) reads, you can access error-corrected content starting at OTP_DATA_BASE ( 0x40130000 ), and raw content starting at OTP_DATA_RAW_BASE ( 0x40134000 ). The register listings below indicate whether or not a given OTP row contains error-corrected contents. OTP never mixes error-corrected and non-error-corrected content in the same row.

Table 1365. CHIPID2 Register

Offset: 0x003

Table 1366. CHIPID3 Register

Offset: 0x004

Table 1367. RANDID0 Register

Offset: 0x005

Table 1368. RANDID1 Register

Offset: 0x006

Table 1369. RANDID2 Register

Offset: 0x007

Table 1370. RANDID3 Register

OTP_DATA: RANDID4 Register

Offset: 0x008

Table 1371. RANDID4 Register

OTP_DATA: RANDID5 Register

Offset: 0x009

Table 1372. RANDID5 Register

OTP_DATA: RANDID6 Register

Offset: 0x00a

Table 1373. RANDID6 Register

OTP_DATA: RANDID7 Register

Offset: 0x00b

Table 1374. RANDID7 Register

OTP_DATA: ROSC_CALIB Register

Offset: 0x010

Table 1375. ROSC_CALIB Register

OTP_DATA: LPOSC_CALIB Register

Offset: 0x011

Table 1376.
LPOSC_CALIB Register

OTP_DATA: NUM_GPIOs Register

Offset: 0x018

Table 1377.
NUM_GPIOs Register

OTP_DATA: INFO_CRC0 Register

Offset: 0x036

Table 1378.
INFO_CRC0 Register

OTP_DATA: INFO_CRC1 Register

Offset: 0x037

Table 1379.
INFO_CRC1 Register

OTP_DATA: CRIT0 Register

Offset: 0x038

Description

Page 0 critical boot flags (RBIT-8)

Table 1380. CRIT0 Register

OTP_DATA: CRIT0_R1, CRIT0_R2, ..., CRIT0_R6, CRIT0_R7 Registers

Offsets: 0x039, 0x03a, ..., 0x03e, 0x03f

Table 1381. CRIT0_R1, CRIT0_R2, ..., CRIT0_R6, CRIT0_R7 Registers

OTP_DATA: CRIT1 Register

Offset: 0x040

Description

Page 1 critical boot flags (RBIT-8)

Table 1382. CRIT1 Register

OTP_DATA: CRIT1_R1, CRIT1_R2, ..., CRIT1_R6, CRIT1_R7 Registers

Offsets: 0x041, 0x042, ..., 0x046, 0x047

Table 1383. CRIT1_R1, CRIT1_R2, ..., CRIT1_R6, CRIT1_R7 Registers

OTP_DATA: BOOT_FLAGS0 Register

Offset: 0x048

Description

Disable/Enable boot paths/features in the RP2350 mask ROM. Disables always supersede enables. Enables are provided where there are other configurations in OTP that must be valid. (RBIT-3)

Table 1384. BOOT_FLAGS0 Register

OTP_DATA: BOOT_FLAGS0_R1, BOOT_FLAGS0_R2 Registers

Offsets: 0x049, 0x04a

Table 1385.
BOOT_FLAGS0_R1,
BOOT_FLAGS0_R2
Registers

OTP_DATA: BOOT_FLAGS1 Register

Offset: 0x04b

Description

Disable/Enable boot paths/features in the RP2350 mask ROM. Disables always supersede enables. Enables are provided where there are other configurations in OTP that must be valid. (RBIT-3)

Table 1386.
BOOT_FLAGS1
Register

OTP_DATA: BOOT_FLAGS1_R1, BOOT_FLAGS1_R2 Registers

Offsets: 0x04c, 0x04d

Table 1387.
BOOT_FLAGS1_R1,
BOOT_FLAGS1_R2
Registers

OTP_DATA: DEFAULT_BOOT_VERSION0 Register

Offset: 0x04e

Table 1388.
DEFAULT_BOOT_VERSION0
Register

OTP_DATA: DEFAULT_BOOT_VERSION0_R1, DEFAULT_BOOT_VERSION0_R2 Registers

Offsets: 0x04f, 0x050

Table 1389.
DEFAULT_BOOT_VERS
ION0_R1,
DEFAULT_BOOT_VERS
ION0_R2 Registers

OTP_DATA: DEFAULT_BOOT_VERSION1 Register

Offset: 0x051

Table 1390.
DEFAULT_BOOT_VERS
ION1 Register

OTP_DATA: DEFAULT_BOOT_VERSION1_R1, DEFAULT_BOOT_VERSION1_R2 Registers

Offsets: 0x052, 0x053

Table 1391.
DEFAULT_BOOT_VERS
ION1_R1,
DEFAULT_BOOT_VERS
ION1_R2 Registers

OTP_DATA: FLASH_DEVINFO Register

Offset: 0x054

Description

Stores information about external flash device(s). (ECC)

Assumed to be valid if BOOT_FLAGS0_FLASH_DEVINFO_ENABLE is set.

Table 1392.
FLASH_DEVINFO
Register

OTP_DATA: FLASH_PARTITION_SLOT_SIZE Register

Offset: 0x055

Table 1393.
FLASH_PARTITION_SLOT_SIZE Register

OTP_DATA: BOOTSEL_LED_CFG Register

Offset: 0x056

Description

Pin configuration for LED status, used by USB bootloader. (ECC)
Must be valid if BOOT_FLAGS0_ENABLE_BOOTSEL_LED is set.

Table 1394.
BOOTSEL_LED_CFG Register

OTP_DATA: BOOTSEL_PLL_CFG Register

Offset: 0x057

Description

Optional PLL configuration for BOOTSEL mode. (ECC)

This should be configured to produce an exact 48 MHz based on the crystal oscillator frequency. User mode software may also use this value to calculate the expected crystal frequency based on an assumed 48 MHz PLL output.

If no configuration is given, the crystal is assumed to be 12 MHz.

The PLL frequency can be calculated as:

Conversely the crystal frequency can be calculated as:

(Note the +1 on REFDIV is because the value stored in this OTP location is the actual divisor value minus one.)

Used if and only if ENABLE_BOOTSEL_NON_DEFAULT_PLL_XOSC_CFG is set in BOOT_FLAGS0. That bit should be set only after this row and BOOTSEL_XOSC_CFG are both correctly programmed.

Table 1395.
BOOTSEL_PLL_CFG
Register

OTP_DATA: BOOTSEL_XOSC_CFG Register

Offset: 0x058

Description

Non-default crystal oscillator configuration for the USB bootloader. (ECC)

These values may also be used by user code configuring the crystal oscillator.

Used if and only if ENABLE_BOOTSEL_NON_DEFAULT_PLL_XOSC_CFG is set in BOOT_FLAGS0. That bit should be set only after this row and BOOTSEL_PLL_CFG are both correctly programmed.

Table 1396.
BOOTSEL_XOSC_CFG
Register

OTP_DATA: USB_BOOT_FLAGS Register

Offset: 0x059

Description

USB boot specific feature flags (RBIT-3)

Table 1397.
USB_BOOT_FLAGS
Register

OTP_DATA: USB_BOOT_FLAGS_R1, USB_BOOT_FLAGS_R2 Registers

Offsets: 0x05a, 0x05b

Table 1398.
USB_BOOT_FLAGS_R1,
USB_BOOT_FLAGS_R2
Registers

OTP_DATA: USB_WHITE_LABEL_ADDR Register

Offset: 0x05c

Table 1399.
USB_WHITE_LABEL_A
DDR Register

OTP_DATA: OTPBOOT_SRC Register

Offset: 0x05e

Table 1400.
OTPBOOT_SRC
Register

OTP_DATA: OTPBOOT_LEN Register

Offset: 0x05f

Table 1401.
OTPBOOT_LEN
Register

OTP_DATA: OTPBOOT_DST0 Register

Offset: 0x060

Table 1402.
OTPBOOT_DST0
Register

OTP_DATA: OTPBOOT_DST1 Register

Offset: 0x061

Table 1403.
OTPBOOT_DST1
Register

OTP_DATA: BOOTKEY0_0, BOOTKEY0_1, ..., BOOTKEY3_14, BOOTKEY3_15 Registers

Offsets: 0x080, 0x081, ..., 0x0be, 0x0bf

Table 1404.
BOOTKEY0_0,
BOOTKEY0_1, ...,
BOOTKEY3_14,
BOOTKEY3_15
Registers

OTP_DATA: KEY1_0, KEY2_0, ..., KEY5_0, KEY6_0 Registers

Offsets: 0xf48, 0xf50, ..., 0xf68, 0xf70

Table 1405. KEY1_0,
KEY2_0, ..., KEY5_0,
KEY6_0 Registers

OTP_DATA: KEY1_1, KEY2_1, ..., KEY5_1, KEY6_1 Registers

Offsets: 0xf49, 0xf51, ..., 0xf69, 0xf71

Table 1406. KEY1_1,
KEY2_1, ..., KEY5_1,
KEY6_1 Registers

OTP_DATA: KEY1_2, KEY2_2, ..., KEY5_2, KEY6_2 Registers

Offsets: 0xf4a, 0xf52, ..., 0xf6a, 0xf72

Table 1407. KEY1_2, KEY2_2, ..., KEY5_2, KEY6_2 Registers

Table 1408. KEY1_3, KEY2_3, ..., KEY5_3, KEY6_3 Registers

Table 1409. KEY1_4, KEY2_4, ..., KEY5_4, KEY6_4 Registers

Table 1410. KEY1_5, KEY2_5, ..., KEY5_5, KEY6_5 Registers

Table 1411. KEY1_6, KEY2_6, ..., KEY5_6, KEY6_6 Registers

Table 1412. KEY1_7, KEY2_7, ..., KEY5_7, KEY6_7 Registers

Valid flag for key 1. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1413.
KEY1_VALID Register

OTP_DATA: KEY2_VALID Register

Offset: 0xf7a

Description

Valid flag for key 2. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1414.
KEY2_VALID Register

OTP_DATA: KEY3_VALID Register

Offset: 0xf7b

Description

Valid flag for key 3. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1415.
KEY3_VALID Register

OTP_DATA: KEY4_VALID Register

Offset: 0xf7c

Description

Valid flag for key 4. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1416.
KEY4_VALID Register

OTP_DATA: KEY5_VALID Register

Offset: 0xf7d

Description

Valid flag for key 5. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1417.
KEY5_VALID Register

OTP_DATA: KEY6_VALID Register

Offset: 0xf7e

Description

Valid flag for key 6. Once the valid flag is set, the key can no longer be read or written, and becomes a valid fixed key for protecting OTP pages.

Table 1418.
KEY6_VALID Register

OTP_DATA: PAGE0_LOCK0, PAGE1_LOCK0, ..., PAGE61_LOCK0, PAGE62_LOCK0 Registers

Offsets: 0xf80, 0xf82, ..., 0xffa, 0xffc

Description

Lock configuration LSBs for page \( N \) (rows \( 0x40 * N \) through \( 0x40 * N + 0x3f \) ). Locks are stored with 3-way majority vote encoding, so that bits can be set independently.

This OTP location is always readable, and is write-protected by its own permissions.

Table 1419.
PAGE0_LOCK0,
PAGE1_LOCK0, ...,
PAGE61_LOCK0,
PAGE62_LOCK0
Registers

OTP_DATA: PAGE0_LOCK1, PAGE1_LOCK1, ..., PAGE61_LOCK1, PAGE62_LOCK1 Registers

Offsets: 0xf81, 0xf83, ..., 0xffb, 0xffd

Description

Lock configuration MSBs for page \( N \) (rows \( 0x40 * N \) through \( 0x40 * N + 0x3f \) ). Locks are stored with 3-way majority vote encoding, so that bits can be set independently.

This OTP location is always readable, and is write-protected by its own permissions.

Table 1420.
PAGE0_LOCK1,
PAGE1_LOCK1, ...,
PAGE61_LOCK1,
PAGE62_LOCK1
Registers

OTP_DATA: PAGE63_LOCK0 Register

Offset: 0xffe

Description

Lock configuration LSBs for page 63 (rows 0xfc0 through 0xfff). Locks are stored with 3-way majority vote encoding, so that bits can be set independently.

This OTP location is always readable, and is write-protected by its own permissions.

Table 1421.
PAGE63_LOCK0
Register

OTP_DATA: PAGE63_LOCK1 Register

Offset: 0xfff

Description

Lock configuration MSBs for page 63 (rows 0xfc0 through 0xfff). Locks are stored with 3-way majority vote encoding, so that bits can be set independently.

This OTP location is always readable, and is write-protected by its own permissions.

Table 1422.
PAGE63_LOCK1
Register