LAT1429 进一步认识STM32H5 OBK_技术资料

1、前言

STM32H5 引入一个新的名词 OBK。OBK 是 Option byte key 的意思，本意用来存储密钥，也可以用来存储数据。传统 STM32 开发与量产需要考虑应用程序以及选项字节，对于STM32H5，则还需要考虑 OBK。本文在 STM32H5 官方文档的基础上带领读者进一步认识一下 OBK。

2、OBK 存储区的几个疑问

2.1. OBK 是 STM32H5 系列都有的吗？

并不是所有的 STM32H5 系列都存在 OBK。在 STM32H503 上相应的 DA【调试认证】功能是借助 OTP 来完成的，也就是说，STM32H503 并没有 OBK。

2.2. OBK 区是使用 STM32H5 必需的吗？

如果用户开发 STM32H5 应用，是否可以不使用 OBK？可以。STM32H5 引入了新的芯片生命周期概念，其 Open 状态类似于传统 STM32 的读保护RDP 0 级别。如果你的产品从来没考虑过读保护 RDP，那么意味着你过去使用 STM32 都是在默认级别读保护 RDP0。在这种需求下，产品量产时只需要关心应用程序和选项字节，不需要理会生命周期概念，自然也不需理会 OBK。

另外，如果用户希望在产品发布后 SWD/JTAG 都不能被访问，那么只需要将 STM32H5 设置成 Close 或者 Lock 状态，也不用理睬 OBK。

2.3. 不使用 OBK 区会不会是一种技术上的浪费？

如果在用户 Flash 使用已经紧张的情况下, 不使用 OBK 确实是一种浪费。OBK 总的大小有8K 之多，可以写入任何数据。如果用户 Flash 空间紧张，即使不考虑任何安全保护的需求，理论上也可以考虑使用 OBK。不过 OBK 的读写受到 OBK 存储区规则的限制，尽管有 8K 这么大，是否可以完全使用这 8K，依赖于特定的应用需求是否和 OBK-HDPL 规则相匹配。

2.4. 什么情况下一定需要使用 OBK 区?

STM32H5 的优势之一是引入芯片生命周期管理，例如支持将产品状态设置到 Close 状态。在 Close 状态，除非用户能提供相应的密码和证书作为凭证进行 DA 认证，否则通过SWD/JTAG 不能访问应用代码，也意味着代码得到了外部访问保护。在这种情况下，若需要使用 OBK 存储 DA 认证的相关的信息，这个时候 OBK 就必须使用。换句话说，你是否在脱离 Open/Provisioning 状态后还希望通过 SWD/JTAG 访问STM32H5，则建议使用 OBK 区。

3、OBK 文件

3.1. OBK 文件的格式

OBK 存储区既可以用来存放密钥也可以存放数据，即 OBK 的内容可以和应用有关。也就是说 OBK 不仅仅可以用来做 DA 认证，也可以作为应用程序的数据区。如果 OBK 用来做 DA 认证，则 OBK 的格式要符合 DA 认证的要求 ;如果 OBK 用来做应用程序的数据区，则 OBK 的格式要符合应用程序的要求。而应用程序需求千差万别。因此，OBK 烧录时，并没有定义它的内容符合什么样的要求，而只关心三个方面：

....uint32_t.destAddress：烧在哪个地址
....uint32_t.OBKeySize：大小是多大
....uint32_t.doEncryption：存储在 MCU 中是否需要加密

上位机的 OBK 文件相比较 OBK 存储区的实际内容就多了一个头部，头部的内容就是以上三项。头部信息的存在是为了告诉烧录程序，如何处理 OBK 文件中的 payload 负荷，头部信息本身在 OBK 存储区中并不存在。

OBK 文件中的 payload 负荷如果没有在头部指定加密的情况下，可以和存储区中的相应位置的数据一一对应。如果在头部指定加密，相应的 STM32H5 支持硬件加密，那么 OBK 文件依然是明文，但是 OBK 存储区则是密文。

这也说明，对于 OBK 烧录工具，不管是证书，密码，还是数据，都会一样被处理。

3.2. OBK 文件生成的方法

STM32 Trusted Package Creator 可以用来生成 DA 以及应用需要的 OBK 文件。它的输入是 xml 文件，可通过图形界面或者文本进行编辑。对于没有在图形界面上显示的配置项目，可通过编辑 xml 让它在图形界面上显示，也可以直接编辑 XML，然后再加载 XML 来进行 OBK生成。