N32替換STM32，這些細(xì)節(jié)別忽略！

前言

目前大形勢影響，芯片價格日益上漲，采購周期變長，導(dǎo)致國產(chǎn)芯片替代進(jìn)口芯片成為大趨勢，該文章記錄了使用國民技術(shù)的N32替換STM32的操作流程。

話不多說，上步驟。

一、工程配置

 

1.安裝硬件庫

硬件庫為廠家提供的資料，如下圖所示，雙擊安裝，使得keil能夠找到該芯片。

2.更改J-Flash配置

由于Keil官方?jīng)]有對該芯片的支持，所以J-Link下載時也無法找到該芯片，所以需要手動添加芯片。更改步驟官方提供有說明文檔。

主要步驟是：

修改JLinkDevices 配置文檔

添加Nationstech 的下載算法文件

添加Nationstech 的JFlash 工程文件

添加解鎖Nationstech 芯片讀保護L1 等級的應(yīng)用程序

進(jìn)行如上步驟后，啟動J-Flash就能夠掃描并連接到芯片，但是有可能keil鏈接的J-Flash和安裝的J-Flash不是一個路徑，所以將配置好的J-Flash文件替換keil下Keil5\ARM\Segger目錄文件，就能夠正常下載調(diào)試。

3.更改芯片

4.添加驅(qū)動文件

將N32的底層驅(qū)動庫拷貝到工程目錄下，并將include路徑添加進(jìn)去。

5.更改全局變量

6.將啟動文件和驅(qū)動文件替換為N32庫文件

7.將所有的stm32l1xx替換為n32g45x

二、底層驅(qū)動函數(shù)接口對照表

更改代碼，將STM32的驅(qū)動函數(shù)替換為N32的驅(qū)動函數(shù)，這部分比較繁瑣，需要慢慢替換，下面是我整理的替換對照表。

三、踩坑記錄

經(jīng)過上面的替換，應(yīng)該可以編譯過去了，但是這指示開始，后面悲劇的踩坑大戰(zhàn)才剛剛開始。

1.仿真卡死

程序仿真卡死，單步調(diào)試發(fā)現(xiàn)卡死在OSInit()函數(shù)里面，這個函數(shù)是OS的初始化函數(shù)，所以應(yīng)該是OS配置的問題，排查下來發(fā)現(xiàn)是啟動文件里面的OS啟動項沒有更改，更改如下：

2.DMA配置出錯

程序能夠進(jìn)入到任務(wù)中后，調(diào)試發(fā)現(xiàn)無法進(jìn)入到串口接收中斷，但是示波器中有數(shù)據(jù)，而且中斷都沒有進(jìn)入，應(yīng)該是卡死在優(yōu)先級高的中斷中，排查發(fā)現(xiàn)，是DMA發(fā)送中斷的配置有問題，導(dǎo)致一直卡死在DMA中斷中。下面是DMA部分的配置。

3.Flash配置

由于國民芯片和STM32芯片的FLASH劃分有區(qū)別，所以FLASH的替換是比較費事的部分，先對比一下兩個片子的區(qū)別：

STM32L151的flash部分：

N32G455芯片的flash部分：

可以看出STM32單獨有EEPROM的劃分，而N32是沒有的，只有flash部分。所以要注意兩點：

Flash空間的問題，STM32可用空間要比N32的空間大；

底層接口函數(shù)，STM32有操作EEPROM的函數(shù)，而N32沒有，只能使用flash操作函數(shù)。

下面是flash部分的操作：

4.bootloader移植

由于本項目采用bootloader引導(dǎo)主程序的方式，因此要注意燒寫空間的配置，配置點在下面位置：

當(dāng)單獨調(diào)試其中的程序時，燒寫程序需要將整個flash擦除，要不運行不正常。

5.OS初始化卡死

又遇到程序卡死問題，這次是主程序，而且主程序起始地址為0x8000000時單獨運行良好，但是改成0x8007000用bootloader跳轉(zhuǎn)過去就卡死，也是卡死在OS的初始化中。因為單獨運行良好，所以排查起來困難些。最終定位是堆棧和堆的空間設(shè)置太大了，設(shè)置小了后就可以運行。更改該空間的位置如下：

而且問題還不是堆棧的空間不夠用，是空間設(shè)置太大了。有點無語。

6.程序跳轉(zhuǎn)后運行不正常

這是最后的問題，程序能夠從bootloader跳轉(zhuǎn)，但是運行不正常，咨詢了廠家技術(shù)人員，技術(shù)人員反饋可以采用分散加載的方式進(jìn)行排查，也就是讓芯片直接在主程序燒錄的位置啟動，分散加載的教程網(wǎng)上比較多，主要需要設(shè)置燒錄域和啟動域地址，還有VTOR寄存器，

配置如下所示：

需要編寫*.ini文件更改VTOR，ini文件編寫如下：

在keil中加載，使得軟件啟動后先配置單片機：

配置好后可以實現(xiàn)分散加載，能夠是程序在燒錄位置啟動，發(fā)現(xiàn)程序分散加載可以運行正常，但是bootloader跳轉(zhuǎn)不正常，因此需要排查跳轉(zhuǎn)部分的問題。最終定位STM32在主程序啟動時不會重啟向量表，而N32會重啟向量表，在主程序啟動位置更改如下：

跳轉(zhuǎn)部分代碼如下：

————————————————

版權(quán)聲明：本文為CSDN博主「德瑪西亞吳彥祖」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/zhang421412170/article/details/116779169