如題，官方似乎沒有公布性能測(cè)試數(shù)據(jù)。目前想用低壓中斷切換電源，需求在100us內(nèi)完成，主頻任意（目前是60M）。
問題如下：
主頻高于20M時(shí)，每秒平均能夠執(zhí)行多少指令（最好能知道RAM和Flash的數(shù)據(jù)）？即MIPS。
低精度低壓監(jiān)控模塊的采樣間隔如何？延遲多少才能觸發(fā)中斷？
中斷嵌套如何配置？中斷優(yōu)先級(jí)最高位是0更高嗎？
BTW，測(cè)試時(shí)發(fā)現(xiàn)，前移棧尾地址（即_eusrstack）后，將數(shù)據(jù)存放至RAM尾部2K區(qū)域，會(huì)導(dǎo)致異常復(fù)位，顯示原因是RPOR，這是怎么回事？
您好，關(guān)于您的三個(gè)問題以及遇到的一個(gè)異常現(xiàn)象：
①ram中的代碼是一個(gè)clk執(zhí)行一個(gè)單周期指令；flash中的代碼是8個(gè)clk執(zhí)行一個(gè)單周期指令。在一般代碼中ram和flash的clk配置為同樣的，clk可以視作主頻。
②低壓監(jiān)控模塊是一直在監(jiān)控的，觸發(fā)到閾值就直接進(jìn)中斷，可以滿足100us的需求。
③支持2級(jí)中斷嵌套，即只能搶占1次。用PFIC_SetPriority()函數(shù)可以配置，最高位表示搶占優(yōu)先級(jí)位，為0優(yōu)先級(jí)更高。
④異常復(fù)位時(shí)，可能是進(jìn)了硬件錯(cuò)誤中斷，可以參考下篇博客，跟蹤一下代碼運(yùn)行情況。CH57x/CH58x/CH32V wch risc-v 芯片hardfault問題追蹤&程序卡死追蹤 - iot-fan - 博客園 (cnblogs.com)
找到了出問題的函數(shù)，是庫里面的ggs_ReadAttrCB()，
00007f46:
ggs_ReadAttrCB():
? ? 7f46: 452d? ? ? ? ? ? ? ? li a0,11 --> Here
? ? 7f48: 14071763? ? ? ? ? bnez a4,8096+0x150>
? ? 7f4c: 0005c803? ? ? ? ? lbu a6,0(a1)
? ? 7f50:4709? ? ? ? ? ? ? ? lia4,2
指示出錯(cuò)原因是00000002，mtval為0。
這明明是有效指令啊，怎么會(huì)HArdFault呢？望解答。
Edit：經(jīng)過排查，似乎是棧尾地址與數(shù)據(jù)重疊導(dǎo)致。多留出4Byte，故障消失。
但是原始棧地址也是RAM尾部，按理來說不會(huì)寫入，并不會(huì)發(fā)生這樣的問題，到底是怎么回事呢？和全局指針(gp)是否有關(guān)？
另外還有一個(gè)問題，TMOS和GAP的alloc是在定義的內(nèi)存數(shù)組中分配嗎？還是有利用到標(biāo)準(zhǔn)的alloc動(dòng)態(tài)分配？
排查一下是不是某個(gè)函數(shù)的taskID傳參傳錯(cuò)了，調(diào)用到了協(xié)議棧內(nèi)部的taskID，會(huì)導(dǎo)致不可預(yù)計(jì)的錯(cuò)誤。編譯完代碼，573的18kram剩余的部分會(huì)提供給局部變量和堆棧使用，注意使用標(biāo)準(zhǔn)庫的內(nèi)存分配注意不要占用太多的空間，如果申請(qǐng)超出了ram剩余的量，擠占到了協(xié)議棧內(nèi)的堆棧，也可能導(dǎo)致硬件錯(cuò)誤。
tmos的內(nèi)存分配是占用了BLE_MEMHEAP_SIZE這個(gè)宏配置的預(yù)留給協(xié)議棧的ram，沒有用到標(biāo)準(zhǔn)庫的內(nèi)存分配。建議使用tmos的內(nèi)存分配，在協(xié)議棧的監(jiān)管下不會(huì)導(dǎo)致堆棧溢出。
已解決，是3.40 版本ISP軟件錯(cuò)誤燒寫所致，鏈接腳本加NOLOAD解決。
