C2000このトピックには24件の返信が含まれ、2人の参加者がいます。5 年、 2 ヶ月前に 
-
投稿
-
ttkkttkkさん
StepOverで進めると、ITRAPのESTOP0で停止した時点でSTACKが全て0とのことですが、ESTOP0で停止しするF6操作直前のコードは特定できておりますでしょうか。
また、StepIntoで実行されたときには、0x200008で停止するとありますが、Stackの内容を確認すると、本来0x0008958CにReturnするところが、スタックポインタが1word分ずれている、あるいはStack領域が間違って更新されているために発生しているものと推察いたします。
実行コードで、不正なポインタ変数の操作や、内部変数にスタックより大きな配列を定義されていると、スタックの内容がおかしくなります。メモリビューやレジスタビューを参照しながらステップ実行を行うことで、不正アクセスの原因が特定できるのではないかと考えます。
ご確認のほど、よろしくお願いいたします。
回答ありがとうございます。
2点質問なのですが、17日に張り付けたデータは既に1word分ずれてしまっている状態なのでしょうか
メモリブラウザで[ SP]とアクセスした箇所が 0x00000428を指していた場合、
0x00000420 か 0x0000041FがReturn Addressになっているのでしょうか？停止したアドレスと一致する内容がスタックに保存されており、その1word前をみると、それまでの履歴から近いアドレスが保存されていることから、1wordずれていると判断させていただきました。
_stack
C054 0000 952D 0008 95EF 0008 95FB 0008 8920 0008 938B 0008 0000 0001 00C8 0018
0001 0000 0000 0000 0003 FFFF EA0A 0033 0004 001F 958C 0008 0020 0000 0000 0004
0096 FFFF 0000 0001 C1E2 0000 0001 0000 0000 0000 0000 0000 0000上記太字の内容が停止したアドレス「0x0020_0008」と一致しますが、斜体の値にありますように、0x0008_9xxxが問題発生よりも前に動作していたアドレスと推測できます。太字の 0008 0020 から1wordずらすと、0x0008_958C になることから、このような判断しております。
SP-8がReturn Addressというのは、あくまでもITRAP ISRが発生したときのReturn Addressです。その他の通常の関数や、ペリフェラルの割り込みハンドラからの戻りアドレスは、その関数の内部変数の定義内容により変化します。ステップ実行されていたプログラムが何によるものかは、こちらでは判断できませんので、実際のSPとReturn Addressの関係につきましては、ttkkttkkさんにてご確認頂けますでしょうか。
全てステップ実行されているという条件と、頂いたStackの内容から推測すると、0x0008958Cから呼び出した関数（またはその関数から呼び出した関数）でなんらかの問題が起こっている可能性が伺えます。
ご確認のほど、よろしくお願いいたします。
ありがとうございます
どのコードが悪いかまでは追えませんでしたが
どのあたりで飛んで行っているかまでは分かりました。
この情報をもとに詰めていきたいと思います別の質問で申し訳ないのですが
PWMの割込みモジュールが定期的に発生しているのですが
ePWM1の割込みかePWM7の割込みで来ているのかを知る方法はないのでしょうか？
割込み関数に入った箇所で何かのレジスタ（フラグ）を見れば分かる、等
あれば教えていただけませんでしょうかttkkttkkさん
ご確認のほど、よろしくお願いいたします。
PWM割り込みのモジュール番号を知る方法ですが、何の割り込みで発生したかは、レジスタでは知ることができません。
PIEIFRxレジスタで、参照時点で発生している割り込み要因は判断できますが、割り込み発生から実際に割り込みハンドラが動作するまでに、別の割り込みが発生した場合は、その要因フラグが発生する可能性があるからです。
ePWM1からePWM7までそれぞれ独立したPIEハンドラが登録できます。
共通のハンドラをPIEベクタテーブルに登録されるのではなく、個々のハンドラをPIEハンドラとしてご登録いただき、共通関数には個々のハンドラから識別子などを引数として共通関数に渡すことをお薦めいたします。なお、異なる質問をご投稿の際には、新しいトピックとしてご投稿頂けますと、私共も管理しやすくなりますので、ご協力のほど、よろしくお願いいたします。
以上、よろしくお願いいたします。
-
この返信は5 年、 2 ヶ月前に
Yojiro さんが編集しました。
回答ありがとうございます
ePWM7についてはPHSEN=1を設定していることが原因で、
ePWM1と同期されておりました。ありがとうございました。話が戻り、割込み処理ですが
割込み関数(epwm7_isr)がLSRAM0の最初00008000に
割り当てられている場合、割込みが発生。下記のように、
割込み処理epwm7_isrより容量の大きい関数をコピーした場合
IllegalISRの不正割込みが発生することがわかりました。ramfuncs_ReadEEPROM
* 0 00088000 000000b9 RUN ADDR = 00008000
00088000 000000b9 MainLoop.obj (ramfuncs_ReadEEPROM)ramfuncs_epwm7_isr
* 0 000880b9 0000004c RUN ADDR = 000080b9
000880b9 0000004c Interrupt.obj (ramfuncs_epwm7_isr:retain)ベクタテーブルにepwm7_isrのアドレスを設定はしております。
コピー処理を行うと容量の大きいモジュールから順にRAMに割り当てられるのでしょうかたびたび申し訳ございませんが
何かわかりませんでしょうかリンク時の配置につきましては、大きいモジュールから順に割り当てられます。
弊社環境での確認では、順番が入れ替わっても、PieVectTableの対象ベクタに正しくアドレスが登録されており、プログラムのRAMへのコピーが正しく行われていれば、正常に割り込みハンドラは実行されております。
ePWM7の割り込みベクタは、0xD6C番地ですが、ここにepwm7_isrのアドレスが正しく設定されておりますでしょうか。
ご確認のほど、よろしくお願いいたします。
ご回答ありがとうございます
ご指摘の通り
割込みベクタ(0xD6C番地)へのepwm7_isrのアドレスが正しく設定がされていないことが原因でした。
(0xD8C番地に設定をしておりました）0D6c番地にepwm7_isrのアドレスを設定しましたところ
IllegalISRも発生しなくなり、プログラムのRAMコピー処理も正常に動作いたしました長々とありがとうございました。
-
この返信は5 年、 2 ヶ月前に
すみません、
問題は解決しましたが一点教えていただきたい点がありますTMS320F28379Dのベクタテーブルの記載がされている資料は
どこにあるのでしょうかspruhm8h.pdf
上記リンク先のベクタテーブル(96ページ～103ページ)は古い内容なのでしょうかttkkttkkさん
ベクタテーブルの記載ですが、提示いただいた資料（TMS320F2837xDのTechnical Reference Manual SPRUHM8H）の記載で間違いありません。資料は Revision i がリリースされておりますが、ベクタテーブルに関しては、変更ございません。
EPWM7の割り込みベクタは、「Table 3-2. PIE Channel Mapping」よりINT3.7が対象となります。
INT3.7のベクタアドレスは、「Table 3-4. PIE Interrupt Vectors」から0x0D6Cになります。レジスタ設定などは、ビットフィールド構造体をご利用いただいていると思いますが、PIEベクタテーブルは構造体変数”PieVectTable”で定義されております。PieVectTableは PIE Interrupt Vectors のアドレスに配置されております。EPWM7割り込みハンドラは、 PieVectTable.EPWM7_INT = &epwm7_isr; と記述いただくだけで、0x0D6Cへ登録できますので、ご活用いただければと思います。
ご確認のほど、よろしくお願いいたします。
回答ありがとうございます。
助かりました。 -
この返信は5 年、 2 ヶ月前に
