R8C Protection Types

R8C MCUs have several independent protection mechanisms that you can hit in standard serial I/O mode (the mode TGSN uses). They are easy to confuse, but they behave very differently — and which one an MCU is in decides whether it can be recovered. This page explains each one and what MultiProg reports.

Based on our own research and the R8C Hardware Manual.

1. ID code check (lock by ID)

The normal lock. A 7-byte ID code is stored in flash at fixed addresses (0FFDFh, 0FFE3h, 0FFEBh, 0FFEFh, 0FFF3h, 0FFF7h, 0FFFBh). In standard serial I/O mode the bootloader compares the ID you send with the one stored in the MCU:

• match → commands (read / write / erase) are accepted;
• mismatch → commands are not acknowledged → MultiProg shows “R8C locked by ID”.

The MCU still talks (you can connect and read the bootloader version) — it just refuses operations until the right ID is given.

If the reset vector (0FFFCh–0FFFEh) is FFFFFFh, the ID is not checked and all commands are accepted (an un-programmed / blank MCU).

Recovery: enter the correct ID, or — if the ID is unknown — try Forced Erase.

2. Forced Erase — the ALeRASE reserved ID

An escape hatch for an ID-locked MCU whose ID is unknown. Sending the reserved ID word ALeRASE makes the bootloader mass-erase its own user ROM, after which the MCU is blank and accessible again (the data is lost — it is an “unlock by erase”).

ALeRASE = 41 4C 65 52 41 53 45   ("A" "L" "e" "R" "A" "S" "E", case matters)

• Only on the R8C/3xC generation (R8C/32C, 33C, 35C, 36A/36C/36M/36T-A, 38C, 38W·X·Y·Z, …). Older R8C/1x and R8C/2x do not have this function.
• It does not always succeed — it is gated by ROM code protect (see §3 and the table below). On a ROM-code-protected MCU ALeRASE is refused.

3. ROM code protect (the OFS register)

A separate protection from the ID lock. It lives in two bits of the OFS register at flash address 0FFFFh:

Bit	Name	Meaning
b2	ROMCR	1 = ROMCP1 bit takes effect
b3	ROMCP1	0 = ROM code protect ENABLED · 1 = disabled

• Enabled = ROMCR=1, ROMCP1=0. A blank/erased MCU has OFS = FFh, i.e. protect disabled.
• It is an option byte programmed as part of the user firmware image (e.g. .org 0FFFFh in the program) — it is deliberately set by whoever flashed the MCU, it does not turn on by itself.
• In parallel I/O mode it prevents flash from being read, rewritten or erased. In standard serial I/O mode its effect is to gate the Forced Erase: with ROM code protect enabled and the stored ID not equal to ALeRASE, ALeRASE is treated as an ordinary (failing) ID check — no erase.
• It can only be cleared by erasing the OFS block via CPU rewrite mode (i.e. by the MCU's own running program). An MCU that is both ID-locked and ROM-code-protected cannot have it cleared by an external programmer.

There is no way to read the OFS bits while the MCU is ID-locked — reading flash (including OFS at 0FFFFh) requires the ID check to pass first. So the only way to detect ROM code protect from outside is behavioural: TGSN sends ALeRASE and, if the MCU answers with an ID-check mismatch (status SR1 bits 3,2 = mismatch) instead of starting an erase, ROM code protect is enabled. MultiProg then reports “ALeRASE refused: ROM code protect enabled” with the raw status bytes.

4. The Protect reserved ID word

A different reserved word, stored in the same ID area:

Protect = 50 72 6F 74 65 63 74   ("P" "r" "o" "t" "e" "c" "t")

When the stored ID equals Protect, the bootloader performs no serial / OCD communication at all — the MCU is effectively silent over serial and cannot be read, rewritten or erased that way. ALeRASE cannot help here (there is no working serial channel to send it through). If Protect is combined with ROM code protect enabled, even a parallel programmer cannot recover it.

TGSN also always rejects Protect as an ID you send — there is no benign use for transmitting it.

Don’t confuse “Protect” with “ROM code protect.” Protect is a stored ID word that kills serial communication (the MCU goes silent). ROM code protect is a pair of OFS bits that leave the MCU talking but block the Forced Erase. An MCU answering with an ID mismatch is ROM-code-protected, not Protect-locked.

Conditions for Forced Erase (summary of HW manual Table 12.2)

ID you send	ID stored in MCU	ROM code protect	Result
ALeRASE	not ALeRASE	disabled	Forced erase — user ROM wiped
ALeRASE	not ALeRASE	enabled	ID check → mismatch, no erase
ALeRASE	ALeRASE	any	Forced erase — user ROM wiped
not ALeRASE	ALeRASE	—	ID check → mismatch
not ALeRASE	not ALeRASE	—	ordinary ID check

(For a stored Protect word, see §4 — serial communication is disabled, so none of the above applies.)

What is recoverable with TGSN

MCU state	Connect?	Recoverable over serial?
Locked by ID, ROM protect off	yes (locked)	Yes — ALeRASE force-erases and unlocks
Locked by ID, ROM protect on	yes (locked)	No — ALeRASE refused; needs the correct ID
Stored Protect word	no (silent)	No — serial disabled
Blank / reset vector FFFFFFh	yes	n/a — already open

Safety guard

On Special Read, if the ID recovered from an MCU turns out to be ALeRASE, MultiProg refuses to feed it back into an unlock — so a read operation can never accidentally erase the MCU. A Forced Erase only ever runs from an ID a user typed in deliberately.

Firmware

R8C Forced Erase handling (the ALeRASE flow, the Protect/ROM-code-protect guards, and the clear status reporting above) requires TGSN firmware 3.3.7 or newer.