AURIX™ TC3xx debug protection (with HSM)调试口保护

发布时间:2026/10/30 8:26:35
AURIX™ TC3xx debug protection (with HSM)调试口保护

AURIX™ TC3xx 设备的调试保护功能是 TriCore™ 和 HSM 核所采用的其中一项安全层级措施,其作用是锁定调试接口,以防止来自外部工具的未经授权的访问。它也防止来自外部调试器的未经授权的闪存读写访问。整个设备的调试访问可以通过 AURIX™ TC3xx 启动模式以及 HSM 本身以及闪存读取保护来启用或禁用。
本文介绍了 AURIX™ TC3xx 设备的调试保护功能,并列举了一些可能的使用场景。文中讨论了正确的配置设置指南,并通过示例展示了如何锁定和解锁调试访问。

1.AURIX™ TC3xx device debug protection

1.1调试保护方法的锁定条件

调试访问是 OCDS 系统与调试接口锁的结合。通过采用以下任一锁定条件,可以阻止对整个设备(TriCore™ 和 HSM)的调试访问:

通过 UCB_DBG 字段的 DMU_HF_PROCONDBG.OCDSDIS 位来禁用 OCDS 系统。(当通过 UCB_DBG 中的 DMU_HF_PROCONDBG.OCDSDIS 位禁用 OCDS 时(这适用TriCore™),HSM 调试支持不受影响。)

使用下述中的其中一种方式锁定TriCore™调试口:

使用UCB_DBG中DMU_HF_PROCONDBG.DBGIFLCK进行密码保护方法配置。

配置使用UCB_HSMz中的DMU_SP_PROCONHSM.DBGIFLCK位。

通过以下任一方式对 TriCore™ 调试接口进行锁定,并启用闪存读取保护功能。

UCB_PFLASH中的DMU_HF_PROCONPF.RPRO位禁止Pfls读取
UCB_PFLASH中的DMU_HF_PROCONDF.RPRO位禁止Dfls读取

通过UCB_HSM中的DMU_SP_PROCONHSM.HSMDBGDIS位禁止HSM调试访问。

锁定条件在mcu启动阶段(SSW)进行锁定条件的检查和应用。

调试保护方法锁定未锁定
OCDSUCB_DBG中的DMU_HF_PROCONDBG.OCDSDIS(_ORIG or _COPY)有正确的调试口密码
TriCoreUCB_DBG中的DMU_HF_PROCONDBG.DBGIFLCK(_ORIG or _COPY)有正确的调试口密码
TriCore配置fls读取保护通过UCB_FLASH(_ORIG or _COPY)中的DMU_HF_PROCONPF.RPRO
DMU_HF_PROCONDF.RPRO
OCDS寄存器需要被改变(通过OCDS_clear_interface_locked接口调用进行清除)
HSM Core

UCB_HSM(_ORIG or _COPY)中的DMU_SP_PROCONHSM.DBGIFLCK

UCB_HSM中的
DMU_SP_PROCONHSM.HSMDBGDIS

改变DBGCTRL.HOST和DBGCTRL.HSM

1.2 OCDS System Control Unit

OCDS 系统控制单元(OSCU)的目的是以标准化的方式对 SoC 设计中的 OCDS 特性进行控制。

特点控制包含如下内容:

OCDS 有助于与 HSM 进行合作。

复位后的暂停。

通过软件以安全方式实现OCDS的关键机制。

工具用于运行系统的热连接功能。

1.2.1 Enabling OCDS
OCDS常常因为如下原因进行禁能:

防止在没有工具的情况下,OCDS系统产生意外影响。

出于节能目的,禁用OCDS资源。

需要一种可靠的OCDS启用机制,以便以正确且安全的方式启用或禁用OCDS

下图展示了OCDS状态机如何以受控方式激活调试访问。

启动阶段时,仅可处于两种有效状态:

设备锁定

- 所有调试资源(例如断点和暂停逻辑)均已关闭,无法通过IOClient进行访问。
- Cerberus处于省电模式。
- OSTATE.OEN由硬件设置为0B。

安全锁定

- 所有调试资源均已禁用。
- OSTATE.OEN 为 0B。

在安全锁定状态下,可通过IOClient使用通信模式(COM模式)与HSM进行通信。除非SSW已完成且HSM同意,否则无法进入读写模式(RW模式)。然后:

• 调试可能
− 所有调试资源均被禁用。
− 可通过IOClient使用COM模式,但仅当OSTATE.IF_LCK被清除时,才能进行RW模式访问。

• 调试激活
− 所有调试资源均可使用。
− 当 OSTATE.IF_LCK 被清除时,可实现无限读写模式访问。可通过系统总线无限访问调试资源。

要从调试可能状态进入调试激活状态,必须使用OEC.PAT寄存器写入正确的模式。

该保护方案可视为门1和门3的组合。

1.3 Internal gates for debug protection
调试保护可通过下图进行说明,图中已设置多个门控,以阐明所采用的渐进式安全层级机制:

Gate 1

通过OCDS模块控制对TriCore™调试的访问。
Gate 2

通过DMU模块控制对TriCore™调试的访问。
Gates 3 and 4

由HSM直接控制。
通过这两个门控,HSM可以锁定对主机CPU的调试访问,同时也可以禁用HSM自身的调试支持功能。
锁定机制由UCB_HSM_ORIG和UCB_HSM_COPY控制。

1.4 Configuration registers for debug protection

AURIX™ TC3xx 器件提供了多层安全保护机制,以限制调试器对整个微控制器的访问。

这些层的配置基于用户配置块(UCB),即非易失性存储器(NVM)中数据存储单元(DMU)内数据闪存(DFLASH)的一个子扇区(DFLASH0_UCB),属于特定的逻辑扇区。

• 大多数UCB包含用户可配置的保护设置及其他参数。
• DFLASH0_UCB包含48个逻辑扇区,即UCB0至UCB47,每个扇区大小为512字节。

在数据闪存的地址映射中,DFLASH0_UCB 从地址 0xAF400000 到 0xAF405FFF,大小为 24 KB。


下图详细展示了DMU内部DFLASH0_UCB扇区的结构,显示了用于保护机制的所有48个UCB。

• 通过UCB实现的有效保护由保护配置内容决定,例如PROCONxxx寄存器(如DMU_HF_PROCONDBG或DMU_SP_PROCONHSM)。
• PROCONxxx寄存器位于NVM的DMU中,起始地址为0xF8040000。

• PROCONxxx 寄存器在设备启动时(每次复位后)由硬件自动从 UCB 位置加载。
• 设备启动期间始终会评估 ORIG UCB。

1. 在本应用说明中,仅讨论UCB_HSM、UCB_DBG、UCB_PFLASH和UCB_DFLASH,因为它们是锁定HSM和TriCore™调试访问以及保护闪存区域免受外部工具访问所必需的唯一UCB。
2. 请参考AURIX™ TC3xx用户手册,以获取本文档未明确涵盖的其余UCB和PROCONxxx寄存器的更多信息(参见[2])。

1.4.1 User Configuration Block confirmation
独立的ORIG和COPY用户配置块(例如UCB_PFLASH_ORIG和UCB_PFLASH_COPY)可以处于以下状态:

• CONFIRMED.
• UNLOCKED.
• ERASED.
• ERRORED.
状态由确认码的内容决定:
• 0x57B5327F = 状态为CONFIRMED,导致UCB的读写访问被限制。
• 0x43211234 = 状态为UNLOCKED,允许UCB进行读写访问。
• 0x00000000 = 状态为ERASED,行为与ERRORED状态相同,即设备将无法再启动。
• 对于所有其他值(包括不可纠正的ECC错误),状态为ERRORED,意味着设备将无法再启动。

注意:任何包含密码的UCB,即使处于已确认状态,其UCB内容也可能被更改。
状态。可通过输入正确的密码并执行禁用闪存保护的命令序列来完成此操作。
注意:新的UCB内容(例如包含确认码的配置)的效果仅在下次复位后才会被评估并生效。

ERRORED state
当UCB的原始数据和其副本中至少有一个条目存在不可纠正错误时,该UCB即处于ERRORED状态。
在评估UCB时,若其原始数据和副本均检测到ERRORED状态,则保护错误标志DMU_HF_ERRSR.PROER将被置位。此外,若单个UCB中的ORIG处于ERRORED状态,原始错误标志DMU_HF_ERRSR.ORIER也将被置位。在此情况下,与处于错误状态的UCB相关的所有PROCONxxx寄存器所对应的保护机制将被完全激活。
启动过程中,若SSW检测到UCB处于错误状态,则视为闪存启动失败,SSW将不会启动设备。
由于ERASED状态也被视为ERRORED状态,因此可无需擦除UCB而直接从UNLOCKED状态转换至CONFIRMED状态。为此,可在包含确认码的页面及其副本中,将原本的UNLOCKED值(0x43211234)通过过编程方式覆盖为CONFIRMED值(0x57B5327F)。

注意:为避免ECC错误,在解锁状态及超编程数据中,确认码之后偏移量0x01F4处的4字节数据不得从原始值(0x00000000)进行修改。

CONFIRMED state
当UCB的至少一个条目在原始数据或其副本中具有“已确认”值时,该UCB即处于已确认状态。
复制。
当以下任一确认状态条件为真时,UCB 确认码即为“已确认”:
• UCB_X_ORIG 确认码为“已确认”。
• UCB_X_ORIG 确认码为“错误”,且 UCB_X_COPY 确认码为“已确认”。
注意:若在“已确认”状态下未输入密码值,则默认密码为 256 位零(0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000)。

1.4.2 UCB_DBG to lock and unlock TriCore™ debug access
UCB_DBG(ORIG 和 COPY)用于配置用户自定义的调试接口密码保护功能。
该功能通过密码 PW0 至 PW7 进行读写保护。
当 UCB 通过 UCB 确认码验证后,在 HSM 保持该接口处于解锁状态的前提下,可通过向 DMU 提供正确的 UCB_DBG 密码(即与 PW0 至 PW7 相同的密码)来解锁调试接口。
此保护配置将被传输至寄存器 DMU_HF_PROCONDBG。

DMU_HF_PROCONDBG(调试保护配置寄存器)中有两个与调试保护相关的位:
• 位0
− 若设置为1B,表示片上调试支持已配置为锁定状态,此时不提供任何调试支持。
允许。所有调试资源(例如断点和暂停逻辑)均被禁用。
• 位1
− 若设置为1注意:
1. UCB_DBG 控制“调试密码”门。该 UCB 可被视为外部工具必须管理的首个调试保护层之一,以获得访问权限。如果在 DMU_HF_PROCONDBG 寄存器中将 DBGIFLCK 位设置为 1B,则只有在提供正确的调试接口密码时,SSW 才会自动解锁调试接口。B,则表示调试接口已配置为锁定状态。

2. 当DMU_HF_PROCONDBG寄存器中的OCDSDIS位设置为1B,且DBGIFLCK位清零为0B时,即使提供了正确的调试接口密码,SSW也不会处理调试接口的解锁操作。用户必须在TriCore™应用程序代码中执行禁用保护命令序列。

只要原始确认码或其副本处于“未锁定”(UNLOCKED)状态,即可更改UCB_DBG的内容。当UCB处于“已确认”(CONFIRMED)状态时,可通过正确的调试接口密码(PW0-PW7)来更改UCB_DBG的内容。
3. 如果在 DMU_HF_PROCONDBG 寄存器中,DBGIFLCK 位和 OCDSDIS 位均设置为 1B,则调试接口将被锁定。通过输入正确的调试接口密码,可解锁调试接口以及 UCB 的读写保护。此后,无论 UCB 处于 UNLOCKED 状态还是 CONFIRMED 状态,其内容均可访问。
4. 如果DBGIFLCK位和OCDSDIS位均被清零为0B,且UCB_DBG处于CONFIRMED状态,则调试接口不会被锁定,但UCB的读写访问将受到限制。用户必须在应用程序代码中使用正确的调试接口密码执行禁用保护命令序列,以临时解除UCB的访问保护。

1.4.3 UCB_HSM to lock and unlock TriCore™ and HSM debug access
UCB_HSM(ORIG 和 COPY)用于配置整个设备的用户自定义调试保护功能,可控制 HSM 调试支持和芯片调试接口,从而启用或禁用外部调试工具的访问权限。
当 UCB 处于 CONFIRMED 状态时,仅 HSM 可以对其进行修改。
只有在启用 HSM 时,设备才会使用 UCB_HSM 中的内容。
该保护配置将被传输至 DMU_SP_PROCONHSM 寄存器。
注意:要启用 HSM,必须将 UCB_HSMCOTP0/1(ORIG/COPY)中的 DMU_SP_PROCONHSMCFG.HSMBOOTEN 位设置为 1B。

DMU_SP_PROCONHSM HSM 接口保护配置寄存器中有两个与调试保护相关的位:
• 位0
- 若设置为1B,表示HSM调试支持已配置为“禁用”(此处“禁用”指HSM调试支持)。
• 位1
- 若设置为1B,表示芯片调试接口已配置为“锁定”(此处“锁定”指AURIX™器件的调试接口)。
注意:位2和位3在AURIX™中未使用,可编程为1B或保持为0B。

将 DMU_SP_PROCONHSM.HSMDBGDIS 位设置为 1B 可以禁用 HSM 调试支持。此时,主机 CPU 或外部调试工具对 HSM 端的任何访问请求都将被限制。禁用 HSM 调试不会影响调试器对 TriCore™ 的访问,用户只能调试 TriCore™ 端。

注意:当 DMU_SP_PROCONHSM 寄存器中的 HSMDBGDIS 位被清零至 0B 时,将启用 HSM 调试功能。此时,主机 CPU 可通过主机系统地址空间中的一个 64 KB 窗口访问(读取和写入)HSM 的内部资源。为了安全
出于这些原因,用户应在带有HSM设备的AURIX™上将HSMDBGDIS位编程为1B,以确保HSM调试访问得到妥善保护。

只要原始文件或其副本中的确认码处于“未锁定”(UNLOCKED)状态,就可以更改UCB_HSM的内容。这意味着当用户决定将状态从“未锁定”更改为“已确认”(CONFIRMED)时,TriCore™将无法再更改UCB_HSM的内容。然而,当其内容一经确认,只有HSM才能修改此UCB。

注意:如果UCB_HSM被设置为CONFIRMED,且DMU_SP_PROCONHSM.HSMDBGDIS位被设置为1B,则会导致仅HSM可在下次复位前临时重新启用调试器对HSM的访问。此操作可通过HSM使用一个名为DBGCTRL(调试控制寄存器)的寄存器实现,具体方法参见AURIX™ TC3xx HSM TS Rev 2.0 [1]中的说明。

1.4.4 UCB_PFLASH/UCB_DFLASH to enable or disable read protection
UCB_PFLASH(ORIG 和 COPY)以及 UCB_DFLASH(ORIG 和 COPY)用于配置程序闪存和数据闪存存储位置的读写保护,该保护通过密码 PW0 至 PW7 进行设置。这是
限制任何外部工具对这些区域进行读写操作的可能性。

保护配置被传输到寄存器 DMU_HP_PROCONPps(其中“p”遍历已实现的程序闪存银行,“s”遍历32个扇区的组)和 DMU_HF_PROCONPF。

DMU_HP_PROCONPps、PFLASH 银行保护配置寄存器以及 DMU_HF_PROCONPF 和 PFLASH 保护配置寄存器,会镜像 UCB_PFLASH 所设置的配置。

• 当UCB_PFLASH未处于错误状态时:
- DMU_HP_PROCONPps将指示哪个PFLASH扇区被写保护。
- DMU_HF_PROCONPF将指示PFLASH被读保护。
• 当UCB_PFLASH处于错误状态时,设备将无法启动。

写保护的粒度以扇区为单位提供。
全局读保护可应用于程序闪存模块,同时涵盖全局写保护。
注意:如果配置了带全局写保护的读保护,则已配置的扇区级写保护将被覆盖。

保护配置被传输到以下寄存器中:
• DMU_HF_PROCONUSR
• DMU_HF_PROCONDF
• DMU_HF_PROCONRAM

DMU_HF_PROCONDF DFLASH保护配置寄存器仅存在于DFLASH0_EEPROM中,它镜像了来自UCB_DFLASH的配置设置。当UCB_DFLASH处于错误状态时,设备将无法启动。

UCB_PFLASH and UCB_DFLASH
两个寄存器都包含一个与读保护机制相关的位:
• 位31
− 若设置为1B,则启用全局读/写保护。
注意:当应用任何Flash读保护时(DMU_HF_PROCONPF.RPRO或DMU_HF_PROCONDF.RPRO为1B),SSW将保持调试接口锁定状态(OSTATE.IF_LCK保持为1B)。

注意:为加强安全防护,用户应在AURIX™器件上将RPRO位编程为1B,以实现冗余保护,从而提高抗攻击能力。

1.5 Flash command sequence definitions
所有CPU均可对UCB进行编程和擦除。此处描述了执行这些操作的机制。
命令序列中使用的参数“Data”可以是以下之一:

PA

• Flash页面的绝对起始地址。
• 对于“写入突发”操作,必须对齐到突发大小;对于“写入页面”操作,必须对齐到页面大小。

WA
闪存字线的绝对起始地址。

SA
• 闪存扇区的绝对起始地址。
• 允许使用PFLASH扇区Sx以及DFLASH扇区EEPROMx和UCBx。

UC

用于执行密码检查的UCBx标识:
− xx10H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用所有PFLASH的全局读写保护。
− xx11H,对应UCB17 = UCB_DFLASH_ORIG 和 UCB25 = UCB_DFLASH_COPY。
− xx12H,对应UCB18 = UCB_DBG_ORIG 和 UCB26 = UCB_DBG_COPY。
− xx20H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用PFLASH0的全局读保护和扇区特定写保护。
− xx21H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用PFLASH1的全局读保护和扇区特定写保护。
− xx22H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用PFLASH2的全局读保护和扇区特定写保护。
− xx23H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用PFLASH3的全局读保护和扇区特定写保护。
− xx24H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用PFLASH4的全局读保护和扇区特定写保护。
− xx25H,对应UCB16 = UCB_PFLASH_ORIG 和 UCB24 = UCB_PFLASH_COPY,用于禁用全局读保护。
保护功能,以及针对PFLASH5的特定扇区写保护。

PWx

256位密码的一个32位字。

1.5.1 Command sequence overview
所有可用的闪存控制命令序列如下所示,但本应用说明中仅考虑其中部分命令序列。

Disable protection
此命令用于在所有密码 PW0-PW7 与相应 UCB 中配置的值相匹配时,临时禁用所选 UCB 的密码保护功能(如果 UCB 支持此功能)。

Resume protection
此命令用于重新启用之前配置的闪存保护功能。

1.5.2 Flash Protection Status Segister
闪存保护状态寄存器用于报告闪存保护的状态,并包含与保护相关的控制字段。
当已设置密码并执行了带有匹配调试密码的“禁用保护”闪存命令序列时,DMU_HF_PROTECT.PRODISDBG 被置为 1B。
当已设置密码并执行了带有匹配 PFLASH 密码的“禁用保护”闪存命令序列时,DMU_HF_PROTECT.PRODISP 被置为 1B。
当已设置密码并执行了带有匹配 DFLASH 密码的“禁用保护”闪存命令序列时,DMU_HF_PROTECT.PRODISD 被置为 1B。

DMU_HF_PROTECT(闪存保护状态寄存器)包含三个与上述保护相关的位:
• 位0
- 若读取值为1B,表示当密码匹配时,PFLASH保护被禁用。
• 位1
- 若读取值为1B,表示当密码匹配时,DFLASH保护被禁用。
• 位2
- 若读取值为1B,表示当密码匹配时,调试接口已解锁。

1.6 SSW debug access evaluation
SSW 是芯片复位后首先执行的软件。
SSW 执行的最后几个设备配置步骤之一是调试访问评估。该过程将根据以下评估顺序检查是否可以授予调试接口:

1. 清除SSW内部标志“允许调试”(OSTATE.IF_LCK被设置)。
2. SSW 通过向 CBS_COMDATA 寄存器写入特定内容(32 位值 CMD_KEY_EXCHANGE)来检查外部工具是否请求了调试访问权限。
- 对于 AURIX™ TC3xx,CMD_KEY_EXCHANGE = 76D6E24AH。
- 如果工具未在 CBS_COMDATA 寄存器中写入正确的值,则 SSW 将在 CBS_COMDATA 中写入调试芯片 ID 值,以识别连接到外部工具的设备。
- 调试芯片 ID 是一种特定的标记选项值,用户应直接从该寄存器读取此值。
设备。
3. SSW 检查调试接口是否被配置为锁定状态(DMU_HF_PROCONDBG.DBGIFLCK = 1)。
4. 仍处于Cerberus通信模式下,SSW确认收到请求,并通过CBS_COMDATA寄存器接收另外8个字(256位调试密码)。
5. 接收到的数据由SSW发送至DMU,通过“禁用保护”DMU命令序列作为调试接口密码进行验证,结果由SSW进行评估。
6. 一旦调试密码正确,请检查该设备是否已启用“调试自毁入口”功能(DMU_SP_PROCONHSMCFG.DESTDBG = 11B)。
7. 调试访问权限授予后,清除SSW内部标志(OSTATE.IF_LCK)。调试接口将
已解锁。退出序列。
8. 如果未配置调试接口锁且启用了闪存读保护,则SSW内部标志(OSTATE.IF_LCK)将保持置位,调试接口将保持锁定状态,并退出该序列。
9. 如果未启用闪存读取保护,但调试接口被配置为锁定状态,则调试访问仍将保持锁定(即使SSW内部标志位(OSTATE.IF_LCK)已被清除),因为DMU通过硬件进行了阻断。

此解锁协议可由外部调试工具支持,例如英飞凌Memtool、PLS UDE、Lauterbach、iSystem等。

注意:
1. 在用于锁定和解锁调试访问的门控概述中,该保护层适用于门1和门2,其中SSW可以控制调试访问。
2. 有关评估序列的更多详细信息,请参见AURIX™用户手册。

2 Debug access protection use cases
为了涵盖与调试访问机制相关的所有可能情况,本文描述了多种保护调试访问的使用场景。
以下使用案例展示了适用于AURIX™ TC3xx器件的配置所具备的高度灵活性。
1. TriCore™ 可自行配置调试访问保护,并具备闪存读取保护功能。
2. TriCore™ 和 HSM 可配置自身的调试访问保护,并具备闪存读取保护功能。
3. HSM 配置了 TriCore™ 和 HSM 的调试访问保护,并具备闪存读取保护功能。
4. HSM 配置了 TriCore™ 和 HSM 的调试访问保护,并设有闪存读取和调试密码。
保护。

2.1 TriCore™ configures its own debug access protection, with flash read
protection (Use case 1)
此使用场景涵盖仅由TriCore™内核以及通过闪存读取保护机制的DMU执行保护的情况。
该保护由门1和门2实施,而门3和门4则保持未锁定状态。
注意:
1. 为加强安全防护,用户应在启用HSM的AURIX™器件上将HSMDBGDIS位编程为1B,以禁用HSM调试访问(如第1.4.3章所述)。
2. 为加强安全防护,用户应将AURIX™器件中的PROCONPF.RPRO或PROCONDF.RPRO位编程为1B,以启用闪存读取保护(如第1.4.4章所述)。

Restricting debug access
调试访问通过以下步骤进行限制:
• 通过UCB_DBG禁用调试访问,设置方式如下所述的DMU_HF_PROCONDBG寄存器:
− 设置PROCONDBG.OCDSDIS = 1B。
− 设置PROCONDBG.DBGIFLCK = 1B。
− 设置调试密码以启用保护机制。
DMU保护通过闪存读取保护机制实现:
• 通过UCB_PFLASH(DMU_HF_PROCONPF)或UCB_DFLASH(DMU_HF_PROCONDF)禁用调试访问。
− 设置PROCONPF.RPRO = 1B 或 PROCONDF.RPRO = 1B(以关闭门2)。

Re-enable debug access
只有当外部实体提供正确的调试密码时,才会重新授予调试访问权限,同时将自动解除闪存读取保护。此操作将由SSW处理。

Unlock sequence
对于解锁序列,TriCore™ 应用代码需要执行以下步骤:

Debug access protection use cases
- (A) 可通过SSW调试接口经由TriCore™进行通信,具体方法如1.6节所述。
- (B) 此通信也可由TriCore™通过其他任何通信接口实现。为了
例如,TriCore™ 通过 CAN 接收此类请求(类似于 SSW 所使用的协议)。
- 为了临时禁用 OCDS 保护,必须按照第 4.2 章中描述的“禁用保护”命令序列进行操作。该命令序列在部分 1.A 的情况下由 SSW 自动执行,在部分 1.B 的情况下则需在应用程序代码中手动执行,前提是仅设置了 OCDSDIS 位且 DBGIFLCK 为清零状态。

如果 TriCore™ 接收到打开调试接口的请求:
− 它会通过向 OEC 寄存器写入正确的模式(如第 4.4 章所述)来释放 OSTATE.IF_LCK 中的锁。在 SSW 中此操作将自动完成,也可在应用程序代码中手动执行。

2.2 TriCore™ and HSM configure their own debug access protection, with
flash read protection (use case 2)
此使用场景涵盖当TriCore™和HSM双方均启用调试保护,但各自仅对自身生效,并且通过闪存读取保护机制由DMU模块实施保护的情况。该保护由门控1、门控2和门控4实现(通过DMU_HF_PROCONPF.RPRO和DMU_HF_PROCONDF.RPRO位添加UCB_PFLASH和UCB_DFLASH保护),而门控3则保持未锁定状态。

注意:
1. 为加强安全防护,用户应在启用HSM的AURIX™器件上将HSMDBGDIS位编程为1B,以禁用HSM调试访问(如第1.4.3章所述)。
2. 为加强安全防护,用户应将AURIX™器件中的PROCONPF.RPRO或PROCONDF.RPRO位编程为1B,以启用闪存读取保护(如第1.4.4章所述)。

Restricting debug access - TriCore™
调试访问通过以下步骤进行限制:
• 通过UCB_DBG禁用调试访问,设置方式如下所述的DMU_HF_PROCONDBG寄存器:
− 设置PROCONDBG.OCDSDIS = 1B。
− 设置PROCONDBG.DBGIFLCK = 1B。
− 设置密码以启用保护机制。
DMU保护通过Flash读取保护机制实现:
• 通过UCB_PFLASH(DMU_HF_PROCONPF)或UCB_DFLASH(DMU_HF_PROCONDF)禁用调试接口:
− 设置PROCONPF.RPRO = 1B 或 PROCONDF.RPRO = 1B(以关闭门2)。

Re-enable debug access
只有当外部实体提供正确的调试密码时,才会重新获得对TriCore™的调试访问权限,同时Flash读取保护也将自动解除。此操作将由SSW处理。

Restricting debug access - HSM
对于HSM侧,调试访问通过以下流程被锁定:

- 将 PROCONHSM.HSMDBGDIS 设置为 1B(以关闭门 4)。
- 将 PROCONHSM.DBGIFLCK 设置为 0B(此设置可保持门 3 处于未锁定状态)。

为了能够访问HSM核心,HSM必须解锁第4道门。

Unlock sequence
在解锁序列中,TriCore™ 应用程序代码和 HSM 应用程序代码必须执行与之前使用案例中描述的相同步骤,以打开两个调试接口。此外,在 TriCore™ 应用程序代码中还需考虑一些额外步骤:

1. 建立与外部世界的通信通道,以接收打开调试接口的请求,并用于交换授权数据(挑战-应答机制)。
(A) 通信可通过TriCore™的SSW调试接口进行,具体如1.6节“SSW调试访问评估”所述。
(B) 此通信也可通过TriCore™的其他任何通信接口进行。为了
例如,TriCore™ 通过 CAN 接收此类请求(类似于 SSW 使用的协议)。
— 要暂时禁用 OCDS 保护,需按照第 4.2 章所述的命令序列“Disable Protection”执行。该命令序列在部分 1.A 的情况下由 SSW 自动完成;在部分 1.B 的情况下,若仅设置了 OCDSDIS 位且 DBGIFLCK 为低电平,则需在应用代码中手动执行。
2. 如果 TriCore™ 接受打开 TriCore™ 调试接口的请求:
− TriCore™ 代码通过向 CBS_OEC 寄存器写入数据来释放 OSTATE.IF_LCK 中的锁(如第 4.4 节所述)。
3. 如果 HSM 接受打开 HSM 调试接口的请求:
− HSM 代码通过将 DBGCTRL.HSM 寄存器设置为 11B 来释放 HSM 调试锁。

2.3 HSM configures both TriCore™ and HSM debug access protection, with
flash read protection (Use-case 3)
此用例涵盖当HSM仅对整个设备启用调试保护,而DMU模块也同时启用时的情况。

该保护通过门2、门3和门4施加,而门1保持未锁定状态。

注意:
1. 为加强安全防护,用户应在启用了HSM的AURIX™设备上将HSMDBGDIS位设置为1B,以禁用HSM调试访问(如第1.4.3章所述)。
2. 为加强安全防护,用户应在AURIX™设备上将PROCONPF.RPRO或PROCONDF.RPRO位设置为1B,以启用闪存读取保护(如第1.4.4章所述)。

Restricting debug access
通过 UCB_HSM 限制对 TriCore™ 和 HSM 的调试访问:
• 通过 UCB_HSM(DMU_SP_PROCONHSM)禁用调试访问并锁定 HSM 调试支持。
− 设置 PROCONHSM.HSMDBGDIS = 1B(关闭 Gate 4)。
− 设置 PROCONHSM.DBGIFLCK = 1B(关闭 Gate 3)。
• 通过 UCB_PFLASH(DMU_HF_PROCONPF)或 UCB_DFLASH(DMU_HF_PROCONDF)禁用调试接口。
− 设置 PROCONPF.RPRO = 1B 或 PROCONDF.RPRO = 1B(关闭 Gate 2)。

Re-enable debug access
HSM 应用程序代码可通过 DBGCTRL 寄存器重新启用调试访问:
• 设置 DBGCTRL.HSM = 11B,启用 HSM 调试。
• 设置 DBGCTRL.HOST = 11B,启用主机调试。

Debug access protection use cases
只有当外部实体向HSM核心提供正确的挑战和响应密码以解锁它,并且一段应用程序代码清除了OSTATE.IF_LCK位时,才重新授予调试访问权限。

Unlock sequence
对于解锁序列,HSM 应用程序代码需要按照以下步骤进行操作:
1. 需要与外部世界建立一条通信通道,以接收开启调试接口的请求,并进行授权数据的交换(包括挑战和响应机制)。
− 通信可以通过 HSM 与 OCDS COMDATA 寄存器进行,(类似于 SSW 所使用的协议)。
− 也可以通过任何其他通信接口进行通信。例如,TriCore™ 通过 CAN 接收此类请求,并将其转发给 HSM 进行检查。
2. 如果 HSM 接受了开启 TriCore™ 调试接口的请求:
− 它会通过将 DBGCTRL.HOST 更改为 11B 来解除自身对调试接口的锁定。
− 它会通过向 CBS_OEC 寄存器写入数据(如第 4.4 章所述)来解除 OSTATE.IF_LCK 中的锁定。
3. 当 HSM 接受了开启 HSM 调试接口的请求后:
− 它会通过将 DBGCTRL.HSM 更改为 11B 来释放 HSM 调试锁。

2.4 HSM configures both TriCore™ and HSM debug access protection, with
flash read and debug password protection (Use case 4)
此用例描述了以下场景:对整个设备的调试保护仅由 HSM 和 DMU 模块实施,并且还应用了调试密码保护机制。
该保护通过门 1、门 2、门 3 和门 4 来实现。

注意:
1. 为了加强安全性,用户应在启用了 HSM 功能的 AURIX™ 设备上将 HSMDBGDIS 位设置为 1B,以禁止 HSM 调试访问(如第 1.4.3 章所述)。
2. 为了加强安全性,用户需在 AURIX™ 设备上将 PROCONPF.RPRO 或 PROCONDF.RPRO 位设置为 1B,以启用闪存读取保护(如第 1.4.4 章所述)。

对 TriCore™ 和 HSM 的调试访问是通过 UCB_HSM 来加以限制的。

使用“UCB_DBG”来启用密码调试保护功能。

• 通过 UCB_HSM 封锁 HSM 调试支持(DMU_SP_PROCONHSM)。
− 将 PROCONHSM.HSMDBGDIS 设置为 1B(关闭门 4)。
− 将 PROCONHSM.DBGIFLCK 设置为 1B(关闭门 3)。

• 通过 UCB_DBG(DMU_HF_PROCONDBG)使用调试密码禁用调试访问。
− 将 PROCONDBG.OCDSDIS 设置为 1B。
− 将 PROCONDBG.DBGIFLCK 设置为 1B。
− 设置密码以应用保护机制。

• 通过 UCB_PFLASH(DMU_HF_PROCONPF)或 UCB_DFLASH(DMU_HF_PROCONDF)禁用调试接口。
− 将 PROCONPF.RPRO 设置为 1B 或将 PROCONDF.RPRO 设置为 1B(以关闭门 2)。

Unlock sequence
对于解锁流程,HSM 应用程序代码必须执行与之前用例中所描述的相同步骤,以重新启用调试访问权限。此外,HSM 应用程序代码中还需执行一个额外步骤,以解锁调试密码保护机制:
1. 需要与外部世界建立一条通信通道,以便接收开启调试接口的请求,并进行授权数据的交换(包括挑战和响应机制)。
− 通信可以通过 HSM 与 OCDS COMDATA 寄存器进行,(类似于 SSW 所使用的协议)。
− 也可以通过任何其他通信接口进行通信。例如,TriCore™ 通过 CAN 接收此类请求,并将其转发给 HSM 进行检查。
2. 如果 HSM 接受了开启 TriCore™ 调试接口的请求:
− 它会通过将 DBGCTRL.HOST 更改为 11B 来解除自身对调试接口的锁定。
− 它会通过向 CBS_OEC 寄存器写入数据(如第 4.4 章所述)来解除 OSTATE.IF_LCK 中的锁定。
3. 如果 HSM 接受了开启 HSM 调试接口的请求:
− 它会通过将 DBGCTRL.HSM 更改为 11B 来解除 HSM 调试锁。
4. 通过使用“禁用保护”这一命令序列来提供密码。
− HSM 需要知道正确的密码才能进行此操作。
− 可能的解决方法:此调试密码存储在 HSM 数据闪存中。

3 Lock/unlock the debug access using debugger tools
用于解锁调试访问的 SSW 调试处理协议可以由外部调试工具(如 Memtool、PLS UDE、Lauterbach 或 iSystem)来支持。它也可以由应用程序代码中实现的软件来支持。所遵循的步骤已在第 1.4.1 节中进行了描述。
下图展示了位于 0xAF402400 位置的 UCB_DBG_ORIG 内容的内存视图。

3.1 Lock using the Infineon Memtool/PLS UDE Memtool
在 Memtool 中,有一个用户界面可让您轻松修改 UCB_DBG 和 UCB_PFLASH 的内容:

3.2 Unlock using the Infineon Memtool/PLS UDE Memtool
为了向 UCB_DBG(原始和副本)提供正确的密码,可以使用以下用户界面:

3.3 Lock using Lauterbach
使用劳特巴赫调试器设置 UCB_DBG_ORIG 密码的另一种方法是通过使用脚本来实现。
以下提取的代码设置了以下内容:
• DMU_HF_PROCONDBG.OCDSDIS 位设为 1。
• DMU_HF_PROCONDBG.DBGIFLCK 位设为 1。
• 在 ORIG UCB 中的用户自定义密码。

The following extracted code:
• Sets the DMU_HF_PROCONPF.RPRO bit to 1.
• Sets the user defined password in the UCB_PFLASH_ORIG.

3.4 Unlock using Lauterbach
为了提供用于解锁调试接口的调试密码,劳特巴赫提供了以下命令:

4 Lock/unlock debug access using software
4.1 Enable debug access password protection using software
为了对 UCB_DBG_ORIG 进行编程,这里提供了一个提取的示例代码。
该示例代码:
• 将 DMU_HF_PROCONDBG.OCDSDIS 位设置为 1 以禁用 OCDS。
• 将 DMU_HF_PROCONDBG.DBGIFLCK 位设置为 1 以在 UCB_DBG 中使用用户定义的密码锁定调试接口。

4.2 Disable protection mechanism for UCB_DBG using software
以下示例代码说明了如何使用“闪存”命令序列来通过输入正确的密码暂时解除 UCB 的保护。
对于其他 UCB,请参考第 1.5 章中提到的 UCBx 的说明。

4.3 Resume protection mechanism for UCB_DBG using software
以下示例代码展示了如何使用 UCB 命令序列来恢复 UCB 的保护。
对于其他 UCB,请参考第 1.5 章中提到的 UCBx 的标识信息。

4.4 Clear OCDS Interface locked indication bit using software
这段示例代码说明了如何从运行于 TriCore™ 或 HSM 核上的应用程序代码中解锁调试接口。
此代码还可用于在已应用闪存读保护配置位(HF_PROCONxF.RPRO)的情况下解锁调试接口。