User's Manual

RYZ012 Multi-Standard Wireless Communication Module for Bluetooth 5 Low Energy and 802.15.4
R15UH0002EU0103 Rev.1.03 Page 20 of 206
Apr.21.21
Table 4. Flash Memory Partition
Partition
No of contained ...
...Bytes
...Pages
...Sectors
...Blocks
Device
512k
2k
128
16
Block
32k
128
8
1
Sector
4k
16
1
-
Page
256
1
-
-
For chip identification and traceability, the Flash is preloaded with a Unique ID (UID). The user is not allowed to modify this preloaded UID, but
the user can read the UID through the corresponding API interface. The MCU uses the system frequency to load instructions, and it adopts the
flash driver to access (read/write) flash with the speed of half of the system clock.
2.2.1.1 E-Fuse
As shown in Table 5, the non-volatile E-Fuse section is preloaded with a 4-byte decryption key and a 4-byte chip UID.
Table 5. E-Fuse Information
Decryption Key
Chip UID
Internal Information
Wafer Number
Lot Number.
Internal Information
Bit0–31
Bit32–47
Bit48–52
Bit53–55
Bit56–63
2.2.1.2 Readout Protection
The RYZ012 supports multiple firmware encryption methods to achieve anti-cloning protection including: UID-based authentication and
Bootloader-based firmware encryption.
2.2.1.2.1 UID-based Authentication Code Generation
During firmware burning (such as through specific burning jig), the user can encrypt the UID read from the chip flash through AES, generating
a unique cipher text that is written into the E-Fuse section.
During application startup, an encryption authentication procedure is added. The user should use the same key and AES encryption algorithm
and key to encrypt the UID read from the chip flash and generate new cipher text. Before running the main application firmware, the new cipher
text is compared with the cipher text read from the E-Fuse section. When the authentication passes (that is the comparison result matches),
the main firmware is up and running; otherwise, the chip stops before running the main firmware.
2.2.1.2.2 Bootloader-based Firmware Encryption/Decryption
The firmware can be encrypted using a customer-provided security key. The customer security key is written into a specific secure register and
becomes unreadable. Any attempt to read the key results in either all 1's or all 0's.
The encrypted firmware can be generated based on the plaintext firmware and the customer security key. The customer can burn both, the
security key into the obscured memory area and the encrypted firmware into Flash.
The firmware is readable by all, but it does appear as unreadable binaries to a third party.
2.2.2 SRAM Memory
The SRAM is split into 4 independent blocks. The lower three blocks can be configured as a retention area that allows data to remain valid in
Deep Sleep mode. The contents of the standard SRAM block are lost in Deep Sleep mode.