CH573使用MRS編譯，.S堆?？臻g定義在哪里？臨時(shí)變量使用老是不正常。全局變量又沒問題。

變量使用內(nèi)存是自低地址向高地址分配，堆棧是從高地址向低地址，默認(rèn)都是全部RAM可用。
看下RAM編譯是多少，如果超過95%，就很危險(xiǎn)了。

如果RAM用的不多，那就要打印看看到底是在什么位置導(dǎo)致變量被改變的。

如果根據(jù)這個(gè)文章里的內(nèi)容:?RISC-V MCU堆棧機(jī)制

修改Link.ld文件去主動(dòng)設(shè)置stack的大小, 是否有助于解決這種問題呢?

我這邊開發(fā)好像也遇到了stack溢出后, 可能覆蓋了highcode區(qū)域的問題.

意思是這個(gè)堆棧是默認(rèn)的，反正一直從高地址往下壓。

我用ch582也發(fā)現(xiàn)有這個(gè)問題，由于堆棧使用剩余內(nèi)存，一個(gè)向下增長，一個(gè)向上增長，控制不好就容易堆棧溢出，最要命的是還不報(bào)異常，有時(shí)RAM編譯后使用80%時(shí)，就莫名出現(xiàn)跑飛或死機(jī)，降到70%時(shí)就能通過，自己的程序中也控制malloc的使用，但庫里的使用情況就不知道了，有什么方法能查看堆棧使用情況，堆棧溢出時(shí)有報(bào)異常的機(jī)制嗎

RISC-V MCU 堆棧機(jī)制 - Wahahahehehe - 博客園 (cnblogs.com)
這個(gè)是通過修改ld文件給堆棧預(yù)留空間；

但是這個(gè)實(shí)際是解決不了各位代碼的問題的，假設(shè)當(dāng)前RAM使用已經(jīng)很緊張了，給堆棧劃分空間，也就是是縮小用戶區(qū)RAM，這樣好處是超出預(yù)期內(nèi)存可以直觀看到報(bào)錯(cuò)信息，解決不了RAM過多消耗的問題；

其實(shí)這個(gè)問題要分程度來看，比如如果差的不多，比如幾百字節(jié)RAM，還能緊湊緊湊代碼和全局變量，省出來一部分RAM，如果差的比較多，比如超了2K左右，甚至更多RAM，那說明這個(gè)芯片就不適合當(dāng)前應(yīng)用，應(yīng)該選RAM打一個(gè)檔次的芯片；

關(guān)于堆棧，其實(shí)解決辦法也是有的，就是函數(shù)嵌套深度適當(dāng)縮減，比如通過2到3層代碼能解決的，就不要用4-5層甚至更深層數(shù)去調(diào)用，這樣也能省以一些堆棧；

有的代碼異?？赡苁且?yàn)樽兞课闯跏蓟?，或者某個(gè)變量在中斷和外部都有對(duì)它進(jìn)行寫操作，這種情況也會(huì)導(dǎo)致變量異常；