S32K3 學習筆記

S32K3 學習筆記

1.啟動詳解篇

所謂MCU的啟動過程，就是MCU上電一直到運行Main 函數，這中間的所有執行過程。 MCU的啟動過程是MCU的學習難點，也是部分嵌入式工程師的知識盲點。雖然不了解啟動過程不影響大部分應用程序的編寫，但當你希望更深入地編寫涉及存儲區域、安全啟動、多核程序、Bootloader等，就需要對啟動過程有一定了解。

BAF 處理流程

芯片復位後，最先進入BAF（Boot Assist Firmware），即啟動固件，這是芯片出廠就已經固化在芯片內部的，用戶不可見，所有復位方式複位後都會運行。 BAF並不運行在芯片的CM7核，而是在Security模塊HSE-B 內部的Cortex-M0+內核來運行。

首先，BAF 會區分當前啟動是正常啟動還是從Standby低功耗模式喚醒的，如果從Standby喚醒，可以支持Normal weakup 和 Fast weakup。如果是正常的複位，會解析IVT（Image Vector Table），是Flash 中斷向量表之前的數據，用於配置整個應用工程和內核的關鍵配置信息。

通過解析IVT信息，會得到是不是Security boot，如果安全啟動的話會檢測芯片的Life cycle，Life cycle類似一個不可逆的安全狀態機是為了做信息安全的管控和密鑰的管理。如果安全啟動沒有問題，會到應用核CM7的啟動，從IVT裡會獲得應用核的啟動地址，跳轉執行，同時會把 HSE-B 內部的Cortex-M0+ 內核進入低功耗模式

IVT 解析

上文提到BAF會解析IVT（ImageVector Table）獲得應用工程和內核的關鍵配置信息。 IVT 總共256 Bytes，必須放在每一個Pflash 或者Dflash 最開始的256個字節，S32K344總共有4個Pflash 的Blocks 和1個Dflash 的Block，總共有5個可選地址，程序會按Block 依次去找，找到後就不再往下尋找。

00H偏移地址：第一個word （4個字節） 是IVTMarker，固定為0x5AA55AA5，用於確定是不是合法的IVT。

04H偏移地址：第二個 word （4個字節）是Boot configuration word，保存信息為是否SecuretyBoot。

0CH偏移地址/14H 偏移地址：兩個應用核啟動地址。

24H偏移地址：存放Lifecycle。

Boot Configuration Word 配置

上文提到 IVT 04H 偏移地址為Boot configuration word，具體配置數據如下。

Bit3：Boot_SEQ ，Securety boot 是否使能。

Bit5：應用核CM7的看門狗是否使能。

Bit1Bit0: 兩個CM7應用核是否使能，雙核啟動的話一定是先啟動一個核，主核配好時鐘後，從核再起來。 IVT 裡Enable 的核必須是主核，bootloader也必須在這個上面。

RTD工程啟動所需文件

程序從BAF跳出來後，首先運行的是startup_cm7.s 的Reset_Handler 程序入口（IVT 地址指向），整個的啟動過程代碼都在這個彙編文件裡，文件同時會調用到startup.c 和system.c 中的各種初始化函數。實現的是數據的初始化，全局變量的初始化和MPU 的初始化，Cache 的初始化，FPU初始化，看門狗初始等。

另外，啟動過程非常重要的是鏈接文件，鏈接文件會保存段 section 的定義，也會提供初始化時各類段的地址信息，比如全局變量存儲地址，保留多大空間等。鏈接文件的另外一個作用是工程代碼代碼編譯後，具體的存儲的地址，會提供據實際目標MCU的Memory的地址映射。

NXP Demo工程中LD文件一般有兩個，一個是Flash 的，一個是RAM的。 RAM只用臨時Debug，編譯後的代碼會下載到RAM裡執行，重啟後數據會丟失。

RTD啟動流程圖

RTD的啟動流程即 startup_cm7.s 具體的處理過程：

第一步 清CPU的通用寄存器

第二步 打開MSCM 的時鐘

第三步 中斷向量表重映射到RAM，映射到RAM後 用戶可以應用install中斷服務函數

第四步 初始化CPU的堆棧，堆棧在CortexM 內核就是R13寄存器，他的值來自 中斷向量表0 地址的第一個word

第五步 關閉看門狗，HSE-B 跳到CM7時看門狗打開的，如果不關掉或不及時餵狗，MCU就會復位

第六步 RAM ECC的初始化

第七步 TCM 及TCM ECC 初始化，S32K3 每個核有 32bit ITCM和64bit 的DTCM

第八步 Wait for debugger to hold the core，這是調試器相關的，為了保證我們可靠的調試需要的代碼，是由我們應用工具鏈決定的

第九步 C代碼用到的全局變量 bss段和data段初始化

第十步 調用 SystemInit() ，主要完成以下功能，中斷具體應用的核配置，FPU使能，MPU配置和cache 配置

第十一步 使能全局中斷

第十二步 可選，應用Autosar 時應用

最後，跳轉到main 函數。

總結

可以說理解了MCU的硬件和軟件啟動過程才是真正理解了這顆MCU，也為用戶更深入的通過配置IVT 鏈接文件等來定制化啟動過程成為可能。

2.S32K3 FOTA

Reset vectors to bootloader, which is never erased

FLASH SWAP SUPPORT
閃存交換由NVM參數控制
（OTA啟用和OTA指示器）
• OTA啟用參數啟用了閃存交換
支援；默認情況下關閉閃存交換
• OTA指示器選擇1MB區塊，這些區塊將在設備重置後映射到低地址空間。
• 更新方法：
− 活動區塊中的代碼將新韌體寫入被動區塊 [左圖示]
− 在新代碼驗證後，OTA指示器將被更新以進行區塊交換
− 活動區塊中的新/更新韌體將在低地址空間中執行 [右圖示]
− 新韌體可以複製到被動區塊中，以提供更多的容錯能力
• 閃存區塊的交換在電源周期內受到控制和維護

Use cases

Both active and passive images stored in the internal code flash

• 目前的韌體執行並同時上傳新的韌體映像到被動的快閃區塊
• 當新映像上傳到被動的快閃區塊後，經過驗證並且在被動快閃區塊中的OTA指示器已更新，設備可以啟動重置
• 設備重置後，新映像將執行

HSE FW Update Procedure for Full Mem

(1) (OTA)應用程式從程式編寫實體接收新的HSE韌體（pink image）。
(2) 在一次性模式下，應用程式將映像存儲在應用程式NVM區域中；在流式模式下，則存儲在RAM區域中。
(3) (OTA)應用程式請求進行韌體更新服務。
(4) 經過基本的健全性檢查後，目前運行的韌體會從數據flash中擦除備份韌體。

(5) HSE解密新的韌體，進行驗證，並編程到數據flash中。
(6) 在新韌體成功編程後，將控制權移交給SBAF。

(7) SBAF從數據flash中恢復韌體到程式flash。
(8) SBAF將控制權移交給新的韌體。
(9) 新的韌體將回應發送回應用程式。

HSE FW Update Procedure for A/B Swap

(1) (OTA)應用程式從程式編寫實體接收A/B切換HSE韌體（pink image）並將其儲存到其非揮發性記憶體（NVM）中。
(2) (OTA)應用程式將自身和IVT複製到0號和1號NVM中。
(3) (OTA)應用程式向HSE發出韌體更新服務請求。
(4) HSE解密、複製並驗證A/B切換HSE韌體到1號NVM中。
(5) HSE編程A/B切換計數器的值。
(6) HSE編程UTEST中的OTA啟用旗標。
(7) HSE韌體回應應用程式。
(8) 應用程式發出重置以切換到被動區塊。

HSE and application image layout in A/B Swap configuration after update

• Block 0 and Block 1 becomes active.
• Block 2 and Block 3 becomes passive.
• HSE and application boots from active area

HSE FW update when device is configured in A/B Mode

(1) (OTA)應用程式將新的HSE韌體映像編程到flash記憶體中。
(2) (OTA)應用程式將自身或應用程式的新映像複製到區塊2、3中。
(3) (OTA)應用程式向HSE發出韌體更新命令。
(4) HSE解密、編程和驗證區塊2、3中的新HSE韌體。
(5) HSE增加被動區塊的OTA計數器並返回回應。
(6) 如果回應成功（OTA），應用程式發出破壞性重置。
A/B Swap 更新成功後

• Block 0 and Block 1 becomes passive.
• Block 2 and Block 3 becomes active.
• HSE and application boots from active area

3.認識MQTT

MQTT最初代表的意思是Message Queueing Telemetry Transport（訊息佇列遙測傳輸），現在已經不用這種說法，MQTT就是MQTT，不是其他單字的縮寫。由於MQTT協定的訊息內容很精簡，非常適合用於處理器資源及網路頻寬有限的物聯網裝置，再加上已經有許多MQTT程式庫被陸續開發出來，用於Arduino控制板（C/C++）、JavaScript(Node.js, Espruino控制板), Python,…等等，還有開放原始碼的MQTT伺服器，使得開發MQTT物聯網、機器之間（Machine-to-Machine, M2M）的通訊變得非常簡單。Facebook Messenger的即時通訊也是用MQTT協定。

比較HTTP和MQTT通訊協定

MQTT和HTTP的底層都是TCP/IP，也就是物聯網裝置可以沿用既有的網路架構和設備，只是在網路上流通的「訊息格式」以及應用程式的處理機制不同。

假設某個裝置透過Web瀏覽器，以HTTP協定傳送溫度值給網站伺服器，此HTTP POST訊息內容大概像這樣：

除了HTTP請求指令以及代表21度的訊息本體，這段訊息中間夾帶了一堆描述用戶端的的標頭（header）資訊，相當於向伺服器介紹：我來自Chrome瀏覽器、作業系統是Android 7、我讀懂中文和英文…等等。這些額外的標頭訊息在許多物聯網通訊應用不僅僅是多餘的，還會佔用網路頻寬、記憶體並且浪費處理時間。

MQTT訊息格式

採用MQTT發布溫度的訊息格式類似這樣：

不同於HTTP的標頭採用文字描述，MQTT的標頭採用數字編碼，整個長度只佔2位元組，等同兩個字元，後面跟著訊息的主題（topic）和內容（payload），實際格式如下：

MQTT標頭裡的訊息類型、品質…等內容，留待下文說明。除了精簡的標頭，讀者可以發現，MQTT的標頭區並沒有標示傳送目標的IP位址。

MQTT的Publisher, Broker和Subscriber

根據MQTT 3.1.1版本規格書的描述，MQTT是一種基於「發布∕訂閱」機制的訊息傳輸協定（MQTT is a Client Server publish/subscribe messaging transport protocol），我們可以把它想成雜誌發行和訂閱的機制。MQTT訊息發送端，相當於雜誌出版社，雜誌出版之後並不直接寄給消費者，而是交給經銷商或者書店一般的代理人（broker），來統籌管理發行和訂閱事宜。每一個訊息來源（刊物）都有個唯一的主題名稱（刊物名稱）。

代理人是個伺服器軟體，向伺服器發送主題的一方是發布者（publisher），從伺服器獲取主題的一方則是訂閱者（subscriber）。以下圖為例，傳送感測器資料的一邊是發布者，接收感測器資料的一邊則是訂閱者。每個感測器∕微控器的訊息都需要有個主題名稱以利識別，像下圖的主題A、B和C。

代理人（broker）可儲存發布者的訊息，在發布者中斷連線的情況下，提供訂閱者最近更新的訊息。「訂閱者」需要告知代理人想要訂閱的主題，每當「發布者」傳入新訊息時，代理人就會依照主題，傳送給所有訂閱者。「發布者」和「訂閱者」都是用戶端，代理人是伺服器。由於兩個用戶端之間有伺服器當作中繼站，所以兩邊並不需要知道彼此的IP位址。

MQTT的主題（Topic）名稱

MQTT主題名稱是UTF-8（萬國碼）編碼的字串，我們可以自行決定主題名稱，例如，傳送溫度的訊息主題可命名成「溫度」、傳送亮度的訊息主題叫做「照度」…等等。主題名稱也支援類似檔案路徑的階層式命名方式，假設住家裡面有許多感測器，我們可依照測器所在位置，規劃如下的命名階層結構：

每個階層之間用斜線分隔，例如，位於庭院的人體感測器#1，其主題名稱可命名為：

命名主題的注意事項：
由於某些微控器或程式語言不支援UTF-8編碼或中文，主題名稱請使用英文，並且取個有意義的名字。
名稱長度不可超過216位元組（65536個字元）。
自訂的主題名稱請勿用$開頭（“$SYS”是MQTT伺服器的控制介面主題的保留字），也不可包含#和+字元；減號和乘號（*）在程式語言中有特殊意義，為了避免誤會，也不建議使用。
名稱的英文大小寫有區別，home和Home是兩個不同的名稱。
雖然名稱可以包含空格，但是英文的「半形」空格和中文的「全形」空格的內碼不一樣，若輸入名稱時沒有統一，會導致程式讀取不到，因此名稱最好不要加入空格。
階層名稱可以空白，像這樣的命名（連續的斜線）是合法的：“home//yard”，代表有三個階層，中間階層沒有名字，在語意上怪怪的。
有些程式設計師習慣在主題名稱最前面加上一個斜線（在Linux系統中，檔案路徑開頭的斜線代表根目錄），但這是不必要的。請注意，“/home”和“home”是兩個不同的名稱，前者代表「空白名稱的根階層」底下的“home”，單一個“/”也是合法的名稱。

除了依據裝置安裝地點來命名主題，當同一個地點包含許多感測器的時候，用編號或者唯一識別碼來命名主題是比較合理的選擇。例如，假設某個位於廚房的裝置的MAC位址是DEADBEEFFEED，它可以被命名成：

Home/kitchen/DEADBEEFFEED

3.TCP/IP，網際網路的基礎通訊架構

TCP/IP 四層架構

TCP/IP 的模型共有以下四層

Application Layer（應用層）
Transport Layer（傳輸層）
Internet Layer（網際網路層、網路層）
Network Access Layer（網路存取層）
這樣的模型在不同層級做了什麼事呢？舉個例子來說：

假設你用 Line 傳了一則訊息出去，應用層的 Line 會把你的訊息丟給傳輸層的程式，加上「連接埠」等資訊傳到下面網際網路層的程式。在這層，資料會被加上「IP 位置」等資訊，再被傳到下面的網路存取層，加上「MAC 位置」等等，最後被轉換成訊號送走。

TCP/IP 各層處理的資料

至於連接埠、IP 位置、MAC 位置的詳細作用為何？我們後續的文章接著聊。現在先回到 TCP/IP 的主要架構上，在不同層級會被加上 Header（標頭）的資訊，用來在傳遞訊息時標明來源及目的。

就有點像是你的訊息被丟進信封，寫上點什麼資訊、再被丟入信封，如此反覆數次。其中一層可能是寫你目的地的地址，例如：信義路一段 1 號，再往外一層寫上下一站要拿給誰。

封裝資訊，加上標頭

剛開始你可能把信拿到某個郵筒，但是你的信封外寫著「拿給：文山郵局」。郵差不需知道你真正的寄送目的地，看到後只要拿給文山郵局就好。

接著文山郵局會把最外層的信封打開，看一下你的目的地為何，發現是送到信義路一段，於是文山郵局再套上一層信封，寫上「拿給：信義郵局」。同樣的，郵差看到這封信也不需要知道你的真正目的地為何，只要拿到信義郵局即可，再由信義郵局決定下個中繼站為何，或是真的抵達目的地了。

加入 TCP/IP 家族

在 TCP/IP 的架構下，你可以挑一個層級加入，符合其規範開發就能順利的和其它層級的程式相容。例如瀏覽網站的協定 HTTP 就是屬於應用層的範疇，HTTP 規範了瀏覽網站的方方面面，像是傳輸內容的格式、快取、錯誤處理等等，但不需要去管這個網站內容傳輸時要走哪條路，掉封包了怎麼辦。

這類的問題要交給下面幾層的協定來做，像是傳輸層的 TCP 就是專門處理連線的穩定性，例如重送的機制是如何做的：要每隔 0.1 ms 還是多久重送一次？要等接收端回覆收到，要等多久？諸如此類的問題。傳輸層的協定基本上現今已經算是相當完善的了，但仍有演算法優化的空間，或是更適用物聯網架構的協定也有可能推陳出新。

而在網路層的 IP（Internet Protocol）則負責把訊息定義網路上的地址，也就是大家熟悉的 IP Address。又或是 OSPF（Open Shortest Path First），專門決定訊息走哪條路徑比較好。

最後在網路存取層有 MAC（Media Access Control），網路卡中的 MAC Address 就是基於這個協定的；也有 ARP（Address Resolution Protocol），透過網路層的 IP Address 來找 MAC Address。

但實務上也不見得某個程式、服務就得完全屬於某一層，TCP/IP 的這個模型也只是盡可能的把抽象和實際的應用之間做一個連接，有些應用不見得可以很明確的歸類在某一層。

TCP 在做什麼？

回顧一下 TCP 的全稱：Transmission Control Protocol 傳輸控制協議，這個協定故名思義就是在控制傳輸的大小事。

在 IP，網路層這個階段，基本上只管我從哪來、我往哪去？但是封包不見了、裡面的資料壞掉了，IP 一概不管。這時候 TCP 就起到至關重要的作用了！確保連線的可靠性就是其主要任務，它有一系列的手段去確保資料能夠送到對方手中，

IP 不可靠的部分，就留給 TCP 做了，包括確保資料抵達目的地、資料的順序一致（這是由於一份資料可能會被切成數份傳送）、資料沒有損壞、流量的控制等等。

TCP 連線及連接埠

TCP 會在兩個端點間建立一個連線（稱做 Socket Connection）來確保雙方的溝通順暢，就像是一條電話專線一樣。在這個連線之中，會在來源及目的各指定一個連接埠（Port），作為確認這個連線的編號。

由於 TCP 是基於 IP 的上面一層，TCP 的連線都會在同一個 IP Address 下，可以理解為都與同一台設備進行連線。但兩個設備間的連線可能不只一個，就會需要編號來分開不同的連線。用 Port（港口，計算機領域譯成連接埠）來命名編號，就像是在同一個地區（同一個 IP Address）有不同的港口。

*TCP Socket Connection

例如在 IP 位置為 87.65.43.21 的伺服器中開了一個 Port 80，這是伺服器專門為 HTTP 開的 Port，伺服器會一直等待新的封包進來，看看有沒有 TCP 協定要傳的內容，Port 是指定 80 的，而這個等待連線產生的行為就被稱為監聽（Listen）。

IP 位置為 12.34.56.78 也是一台裝置，可能自己也有啟動一些服務，也有架設網站，因此也會監聽自己的 Port 80。但當這台裝置也想連到另一台裝置使用對方 HTTP 服務的時候，它會找一個目前沒有在用的 Port，如 12345（總之不能是現在有開的 22, 80 Port），當作來源，和對方的 Port 80 建立合法的 TCP 連線。

Port 的數字大小必須介於 1-65535 間，因為 TCP 要存放來源及目的 Port 的長度只有 16 bits 而已。一些常用的服務都會被保留起來，例如 HTTP 這個應用層的服務通常都是 80、SSH 都是 22 等等，這是約定俗成的定義，也就是說如果你想，你也可以佔用這些 Port 去啟用你自己的網路服務。

TCP 如何建立連線？三向交握

要建立可靠的連線，TCP 提出的辦法是我知道你知道我知道，很饒舌吧！這個建立連線的方法稱做「三向交握」（Three-way handshake），原理其實很簡單，就是先丟個訊息和對方確認，對方回答，我們再做最後回應。

*TCP 三向交握

三次傳遞訊息分別用來達成及確認一些事情

確認建立連線，確認我方到對方的網路是通的
回應是否建立連線（對的，有可能被對方拒絕），以及告訴我方，網路從對方來的這條路徑是通的
最後讓對方知道，我方到對方的路徑是通的
你可能會想，第 3 次的訊息有必要嗎？不是在第 1 次就讓對方知道我們的訊息傳的到了？

這幾次交握的訊息中還藏著「序列號碼」（seq, sequence number）及「確認號」（ack, acknowledgement number）。由於一筆資料可能會很大，並且 IP 這個協定有限制每個封包的最大大小，因此 TCP 用序列號碼來記錄被分割後的每一份小資料。

*序列號碼及確認號

有了序列號碼之後，在交握同時會附帶這個訊息，對方收到後的回覆則會包含「確認號」，也就是對方期待收到的下個序列號碼為何，藉此來確保封包是連續的。

確認過眼神，便可以開始傳輸資料了，接下來，我們繼續看看 TCP 如何管理資料傳輸。