阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领

  • 阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领已关闭评论
  • 112 人浏览
  • A+
所属分类:首页

  人人好,我是痞子衡,是正派搞手艺的痞子。本日痞子衡给人人引见的是恩智浦i.MX RTxxx系列MCU的OTP

  在i.MXRTxxx启动系列第二篇文章 Boot设置(ISP Pin, OTP) 里痞子衡提到了OTP,部份Boot设置都存储在OTP memory里,然则对OTP的引见仅仅浅尝辄止,没有深切,本日痞子衡就为人人再进一步引见OTP。

  OTP是i.MXRTxxx里一块特别的存储地区,用于寄存悉数芯片设置信息,个中有一部份设置信息和Boot相干。这块特别存储地区并不在ARM的4G system address空间里,需要用特别的体式格局去接见(读/写),怎样接见OTP是本篇文章的重点。

一、OTP基本原理

1.1 OTP属性(OTP, Shadow Lock)

  OTP本质上就是i.MXRTxxx内嵌的一块One Time Programmable memory,仅可被烧写一次,但能够被屡次读取。OTP memory的烧写大部份是按Word举行的(也有少少部份是按Bit举行的),初始状态下一切OTP bit均为0,经由过程特别的烧写时序能够将bit从0改成1,一旦某bit被烧写成1后便再也没法被修正(可理解为硬件熔丝烧断了没法恢复)
  i.MXRT600的OTP memory总地点空间有2KB(word index局限为0x000 - 0x1FF),分为64个BANK,每一个BANK含8个word(1word = 4bytes)。
  OTP memory空间除了OTP特征外,另有Shadow Lock掌握特征,Shadow Lock掌握是OTP memory的标配,Lock掌握有二种:第一种是WP,即写庇护,用于庇护OTP地区对应的shadow register不能被改写;第二种是RP,即读庇护,被庇护的OTP地区对应的shadow register不能被读取。看到这里,你会发明i.MXRTyyyy的efuse里的LOCK掌握是同时针对efuse自身和shadow register的;而i.MXRTxxx的OTP里的LOCK掌握仅针对shadow register,那末对OTP自身的庇护在那里呢?先别急,背面会给你答案。
  Shadow Lock掌握在OTP的BANK0_word4、BANK1_word8/9,以下是RT600详细Lock bit定义:

阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领

关于OTP空间一切bit定义详见Reference Manual里的otpmap Descriptions。

1.2 OCOTP掌握器与Shadow Register

  i.MXRTxxx内部有一个硬件IP模块叫OCOTP_CTRL,即OCOTP掌握器,对OTP memory的读写掌握操纵实在都是经由过程这个OCOTP掌握器完成的,下图是OCOTP_CTRL模块图:

阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领

  OCOTP_CTRL模块寄存器一共分两类:一类是IP掌握寄存器,用于完成对OTP memory的读写操纵时序掌握;一类是Shadow register,用于上电时自动从OTP memory猎取数据并缓存,如许我们能够直接接见Shadow register而不必接见OTP memory也能猎取OTP内容(注重:当芯片运转中烧写OTP,Shadow register的值并不会马上更新,需要实行IP掌握器的reload敕令或许将芯片reset才同步)。
  下图是RT600里的OCOTP_CTRL模块寄存器map,个中Shadow register寄存器偏移地点局限是0x000 - 0x7FF(注重并非一切OTP Word都会被加载到Shadow register里,虽然Shadow register预留了悉数的OTP位置。这点与i.MXRTyyyy efuse会悉数加载到Shadow register差别,原因是i.MXRTxxx的OTP里会有许多Peripheral寄存器加载初值,假如这些OTP值目标是加载Peripheral,那就没有必要再加载到Shadow register里,而i.MXRTyyyy的efuse值没有加载Peripheral寄存器的用处)。IP掌握寄存器偏移地点局限是0x800 - 0x82C:

阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领

  痞子衡写过关于i.MXRTyyyy的eFUSE烧写的文章 飞思卡尔i.MX RTyyyy系列MCU启动那些事(5)- 再聊eFUSE及其烧写要领 ,实在i.MXRTxxx的OCOTP掌握器与i.MXRTyyyy里的OCOTP掌握器异常类似,虽然二者在寄存器构造上有差别,但其共同点更多。不过说起差别,有一个处所痞子衡不得不提,那就是CTRL寄存器的bit15,在i.MXRTyyyy上这个bit是保存的,然则i.MXRTxxx上这个bit为WORDLOCK,望文生义即供应对操纵的OTP word地区举行庇护(主如果写庇护),下一节引见的efuse-program-once敕令第三个可选参数[nolock/lock]实在就是利用了这个bit

阿里云,腾讯云_痞子衡嵌入式:恩智浦i.MX RTxxx系列MCU启动那些事(4)- OTP及其烧写要领

二、运用blhost烧写OTP

  OTP memory的烧写是经由过程OCOTP_CTRL模块来完成的,我们固然能够在Application中集成OCOTP_CTRL的驱动程序,然后在Application挪用OCOTP_CTRL的驱动程序完成OTP的烧写,但这类体式格局并非痞子衡要引见的重点,痞子衡要引见的是经由过程Serial ISP形式配套的blhost.exe上位机东西完成OTP的烧写。
  痞子衡在前面的文章里引见过怎样进入Serial ISP形式与BootROM通讯,此处假定你已运用blhost与BootROM建立了通讯。让我们再来回忆一下blhost的敕令help,能够得知efuse-program-once这个敕令就是我们想要的敕令。

PS D:\NXP-MCUBootUtility\tools\blhost2_3\win> .\blhost.exe
usage: D:\NXP-MCUBootUtility\tools\blhost2_3\win\blhost.exe
                       [-p|--port <name>[,<speed>]]
                       [-u|--usb [[[<vid>,]<pid>]]]
                       -- command <args...>

Command:
  efuse-program-once <addr> <data> [nolock/lock]
                               Program one word of OCOTP Field
                               <addr> is ADDR of OTP word, not the shadowed memory address.
                               <data> is hex digits without prefix '0x'
  efuse-read-once <addr>
                               Read one word of OCOTP Field
                               <addr> is ADDR of OTP word, not the shadowed memory address.

  让我们试一下efuse-program-once这个敕令,入手下手试之前要处理2个问题:
  addr参数究竟是什么地点?协助里说是OTP word address,实在这个地点就是1.1节里引见的word index,index局限为0x000 - 0x1FF,对应512个可读写操纵的OTP Word。
  data参数究竟是什么花样?协助里说是hex digits without prefix '0x',然则好像没有指明长度,我们晓得每一个index对应的是4byte,那就应该是8位16进制数据(实测下来必需要填8位,假如黑白8位会返回Error: invalid command or arguments)。
  弄清了问题,那我们做一个小测试:请求将OTP里的REVOKE_IMG_KEY word的最低byte烧写成0x5A。翻看OTP Memory Footprint表,找到REVOKE_IMG_KEY的index地点是0x66(对应Shadow register地点是0x40130198),敕令搞起来:

PS D:\NXP-MCUBootUtility\tools\blhost2_3\win> .\blhost.exe -u -- efuse-program-once 0x66 0000005A

Inject command 'efuse-program-once'
Successful generic response to command 'efuse-program-once'
Response status = 0 (0x0) Success.

PS D:\NXP-MCUBootUtility\tools\blhost2_3\win> .\blhost.exe -u -- efuse-read-once 0x66

Inject command 'efuse-read-once'
Response status = 0 (0x0) Success.
Response word 1 = 4 (0x4)
Response word 2 = 90 (0x5a)

  看起来敕令实行一般,假如此时你用J-Link去读取对应Shadow register的值,你会发明适才烧写的OTP数据并没有自动同步更新到Shadow register里。与i.MXRTyyyy系列下Flashloader里efuse program操纵有所差别的是,i.MXRTxxx Serial ISP形式下blhost里的efuse-program-once敕令仅包括program敕令,没有集成reload敕令。因而想要革新Shadow register,必需复位芯片

  至此,恩智浦i.MX RTxxx系列MCU的OTP痞子衡便引见终了了,掌声在那里~~~

腾讯云双十一活动