先交代一下背景：

bootloader為自行實(shí)現(xiàn)版本，占據(jù)0x00000-0x7FFF，功能為通過USB和UART下載hex文件，已經(jīng)驗(yàn)證過一切正常。

bootloader本身和BLE協(xié)議棧沒有任何關(guān)聯(lián)，可以下載任何類型的hex文件。

用戶app從0x8000開始，使用BLE\Broadcaster這個(gè)demo，修改Link.ld文件，將FLASH起始地址改到0x8000，SRAM起始地址0x4800，長度14kB。

BLE協(xié)議棧鏈接LIBCH57xBLE.a這個(gè)文件，將協(xié)議棧編譯到app中，編譯完成使用bootloader直接下載app的hex文件，運(yùn)行一切正常。

由于每次要下載的hex包含協(xié)議棧體積較大，耗時(shí)長，因此希望將app和協(xié)議棧分離，app按以下步驟修改：

• 定義全局宏 #define CH57xBLE_ROM，這樣會(huì)使用CH57xBLE_ROM.h這個(gè)頭文件

• 定義全局宏 #define LIB_FLASH_BASE_ADDRESSS? ?0x50000? BLE所有函數(shù)從這個(gè)地址開始

• startup_CH573.S文件將mstatus寄存器改為0x1888(默認(rèn)是0x88)，MPP=3，RISC-V內(nèi)核一直保持機(jī)器模式

• startup_CH573.S文件在mret指令之前增加 j 0x50000指令，startup文件執(zhí)行完成退出之前先跳轉(zhuǎn)到協(xié)議棧開始地址運(yùn)行

再次編譯BLE\Broadcaster工程，生成的hex文件大大減小，使用bootloader將app下載到器件，使用bootloader將CH57xBLE_ROMx.hex下載到設(shè)備，協(xié)議棧起始地址為0x50000

app和協(xié)議棧分別完成下載以后重新運(yùn)行，實(shí)測app無法正常運(yùn)行，由于協(xié)議棧以二進(jìn)制方式提供，問題排查比較困難。幾個(gè)疑問：

1）startup_CH573.S將RISC-V內(nèi)核設(shè)置為機(jī)器模式，請(qǐng)問協(xié)議棧運(yùn)行是否強(qiáng)制要求機(jī)器模式？

2）用戶的startup_CH573.S文件在mret之前通過j 0x50000命令跳轉(zhuǎn)到了協(xié)議棧，將CPU控制權(quán)交給了協(xié)議棧，并且沒有保存返回地址，協(xié)議棧是如何將控制權(quán)交還給用戶程序的？

感謝回復(fù)。

不要在Broadcaster例程原有的Link.ld和startup_CH573.S中修改，把工程中的Ld文件夾,Stratup文件夾移除,拷貝WCH提供的SDK中EVT>EXAM>BLE>OnlyUpdateApp_Peripheral工程里的LD文件夾和Startup文件夾到Broadcaster工程里，按照你上面的修改即可。

機(jī)器模式并不是必須的，OnlyUpdateApp_Peripheral例程也是使用的0x88。

還是我來給個(gè)更清晰的回答吧：

APP和協(xié)議棧分離以后，預(yù)留給了協(xié)議棧4kB空間，0x20003800-0x200047FF，用戶app中的gp寄存器應(yīng)該避開這個(gè)空間，解決方法是修改Link.ld文件

• 在Link.ld文件中修改__global_pointer$地址，大約141行，PROVIDE( __global_pointer$ = . + 0x800 );改為PROVIDE( __global_pointer$ = 0x20004800 );

這是個(gè)明顯的坑，沒見到之前有地方提到，希望給其他朋友有個(gè)參考，正文移植步驟需要加上這一條。