你們好,我是痞子衡,是正經搞技術的痞子。今天痞子衡給你們介紹的是恩智浦i.MX RTxxx系列MCU的OTP。html
在i.MXRTxxx啓動系列第二篇文章 Boot配置(ISP Pin, OTP) 裏痞子衡提到了OTP,部分Boot配置都存儲在OTP memory裏,可是對OTP的介紹僅僅淺嘗輒止,沒有深刻,今天痞子衡就爲你們再進一步介紹OTP。git
OTP是i.MXRTxxx裏一塊特殊的存儲區域,用於存放所有芯片配置信息,其中有一部分配置信息和Boot相關。這塊特殊存儲區域並不在ARM的4G system address空間裏,須要用特殊的方式去訪問(讀/寫),如何訪問OTP是本篇文章的重點。緩存
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_word四、BANK1_word8/9,以下是RT600具體Lock bit定義:工具
關於OTP空間全部bit定義詳見Reference Manual裏的otpmap Descriptions。測試
i.MXRTxxx內部有一個硬件IP模塊叫OCOTP_CTRL,即OCOTP控制器,對OTP memory的讀寫控制操做其實都是經過這個OCOTP控制器實現的,下圖是OCOTP_CTRL模塊圖:code
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:htm
痞子衡寫過關於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。blog
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這個命令就是咱們想要的命令。ip
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),命令搞起來:get
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痞子衡便介紹完畢了,掌聲在哪裏~~~