2

IAR Embedded Workbench IDE と TI CC2540 Bluetooth Low Energy 8051 チップを使用して C プロジェクトに取り組んでいます。

プロジェクトの作業中に大量の XData スタックと Idata スタックのオーバーフローが発生しているようで、オーバーフローの原因を特定するのは非常に困難でした。UART ポート経由で大量の文字列を操作しています。

割り当てた後にメモリの割り当てを解除し、スタックとヒープの境界内にとどまるようにする方法について、誰かがヒントを持っているかどうか疑問に思っていました。

ありがとう

4

4 に答える 4

4

この TI のフォーラムから、TI の 2540/1 スタック サイズに光を当てようとしています。

プロジェクトをコンパイルしたら、「.map」ファイル (出力フォルダー) の下部を見ることができます。

たとえば、心拍数のサンプル プロジェクトは次のとおりです。

108 019 bytes of CODE memory
     26 bytes of DATA memory (+ 73 absolute )
  6 089 bytes of XDATA memory
    192 bytes of IDATA memory
      8 bits of BIT memory
    702 bytes of CONST memory

この情報は、プロジェクトで使用されているコード スペース (CODE メモリ) と RAM (XDATA メモリ) の合計量を示すという点で役立ちます。CODE メモリと CONST メモリの合計が、デバイスの最大フラッシュ サイズ (CC2540/41 のバージョンに応じて 128KB または 256KB) を超えてはなりません。CC2540/41 には 8kB の SRAM が含まれているため (256 バイトは予約済み)、XDATA メモリのサイズは 7936 バイトを超えてはなりません。

XDATA が最大 8k を超えないように注意しながら、コードで定義されたバッファー/大きな配列を調整することをお勧めします。最小限の SimpleBLEPeripheral アプリ自体は、6 ～ 7k 近くのメモリを消費しますが、その上に、アプリ リソースにメモリを割り当てるのに十分なスペースがあります。

[私は知っています、非常に遅い答えですが、他の読者を助けるかもしれません].

于 2015-11-16T19:55:38.773 に答える
4

スタック オーバーフローを回避するには、次のことを避ける必要があります。

1) 再帰 (組み込みシステムで再帰を使用するのは良い考えではありません)

2)動的割り当てを避けるようにしてください。ほとんどの場合、それは必要ありません。

自動車では、動的に割り当てられたメモリと再帰を使用しないようにアドバイスする MISRA ルールと呼ばれる、ECU のプログラミングに関するいくつかのルールがあります。ここにリンクがあります

IAR Embedded Workbench は、MISRA C をサポートする数少ない IDE の 1 つです。MISRA C オプションを有効にしてみてください (これにより、問題がどこにあるのかがわかります)。ここでどのように行われるかを参照してください。

于 2012-11-20T03:18:51.643 に答える
0

リンカー構成 (.icf) ファイルでスタックとヒープのサイズを変更できます。プロジェクト - >オプション - >リンカー - >構成。マイナーな変更は組み込みのエディターで行うことができますが、あまりにも哀れなので、テキスト エディターを使用する必要があります。

そこには次のようなものが表示されます。

define block CSTACK with alignment = 8, size = 0x0400 {};
define block HEAP with alignment = 8, size = 0x0200 {};
place in MY_RAM_region {block CSTACK, block HEAP};

必要に応じて変更できます。HEAP サイズを 0 に設定しても問題ないと思います。その後、すべての malloc 呼び出しは実行時に失敗しますが、クールな子供たちはとにかく組み込みシステムで動的メモリを使用しません。

スタックサイズを見積もる方法は? EWB マニュアルでは、これを .icf に追加することを提案しています。

check that size(block CSTACK) >= 
      maxstack("Program Entry") + totalstack("interrupt") + 100;

これは、CSTACK が小さすぎる場合にエラーをスローすると想定されています (100 は単なるファッジ ファクターです)。私の場合、リンカーは「スタック サイズがわかりません」というエラーをスローしました。

IAR の .icf 形式は、AppleScript を思い起こさせます (良い意味ではありません)。

于 2013-11-20T15:29:36.703 に答える
0

IAR のアーム以外のエディションでこれがうまく機能するかどうかはわかりません。私たちのアプローチを共有できます。

スタートアップ ファイルでは、IAR がスタック使用量を測定するために使用するパターンで RAM の初期化を編集するだけです。

    LDR R1, =__RAM_START
    LDR R2, =__RAM_END

    SUBS    R2, R2, R1
    SUBS    R2, #1
    BLE .LC5

    MOVS    R0, #0xCDCDCDCD ;; <- LOOK HERE!
    MOVS    R3, #4
.LC4:
    STR R0, [R1]
    ADD R1, R1, R3
    SUBS R2, #4
    BGE .LC4

次に、ノードのオプションで、linker->advanced で、Enable stack usage analysis をマークします。IDEオプションで、「グラフィカルスタックを有効にする」などを選択します。

ここで、デバッグ セッションで、[View] -> [Stack] を選択してスタックのグラフィック表示を有効にします。

このアプローチを使用すると、RAM 全体をダンプして、0xCDCD パターンがどこに残っているかを特定することもできます。

もう 1 つのアプローチは、uC の DWT または MPU を使用して、境界を越えるバス アクセスを監視し、例外をトリガーすることです。このアプローチを使用すると、スタックがオーバーフローしたときに誰が何をしていたかを正確に確認できます。

繰り返しますが、これは ARM に合わせたアプローチであり、これがあなたのシステムで機能するかどうかはわかりません。

韓国語

于 2021-02-24T14:06:55.477 に答える