いつも大変お世話になっております。

早速ですが、37pinへの外部入力信号が添付のようにピン端でなまってしまいます。
お手数ですが、原因についてご教示願います。

なお、回路図は添付の通りであり、
37pinの設定は以下の通りとしております。

GpioCtrlRegs.GPBMUX1.bit.GPIO37=0;
GpioCtrlRegs.GPBDIR.bit.GPIO37=0;

お忙しい中、大変恐縮ですが、宜しくお願い致します。

Attachments:

1. 

   5df8463b6b1f655111488539f4839149.png
   

2. 

   9aa6a58a5cc41d04223ac1432d44a909.png
   

PCIインタフェースにDP83816を使用しておりますが，下記のような事象が発生しております。
そこで同様の事象や発生する条件，通信対象との相性の影響があればご教示いただきたく
よろしくお願い致します。
(通信対象により事象の発生頻度が大きく異なっております。)

【事象】
　DP83816を使用したイーサネットパケットの受信で，実際に受信したパケット長が64Byteであるにも関わらず
　デスプリクタで通知されたパケット長が1536Byteであり受信したパケットサイズになっていない。

必要に応じて周辺回路や使用部品の情報提供可能ですので必要あればご連絡をお願い致します。

[QT従業員]

aoki様

ご連絡ありがとうございます。

HB端子電圧がHS, HO端子にも表れる事につきましては、

下図の通り各端子は保護ダイオードを介して接続されております。

そのため、今回の様なケースでは電圧が現れているものと推測されます。

以上、何卒宜しくお願い致します。

QT

[aoki参加者]

QT様

D2を外し、HBに外部電源を接続したところHS端子の電圧が外部電源の電圧と同じになりました。

そのため、D2 → HB → HS(HO)の経路で間違いなさそうです。

なぜこのような経路で電流が流れるのか、原因/メカニズムを教えていただきたいです。
UCC27712の中で何が起きているでしょうか。

[aoki参加者]

QT様

無負荷状態でHS端子ーGND端子間に抵抗を接続した際に下記のようになりました。

開放　12V(正確には10.8V)が出力される。
20kΩ　1V
1kΩ　0V

以上、よろしくお願いいたします。

[Yojiro従業員]

doublesh6198さん

VREFHI-VREFLO間のコンデンサ容量につきましては、ADC変換のサンプリングーホールド時間（S/H時間）に影響を与えるものではございません。

S/H時間の求め方として、TMS320F2837xS Technical Reference Manual（SPRUHX5）の”10.3.2 Choosing an Acquisition Window Duration”に計算方法が記載されております。

こちらをご参照のうえ、S/H時間を算出、ご確認頂けますでしょうか。

よろしくお願いいたします。

[aoki参加者]

QT様

負荷は圧電素子です。ただし、負荷の接続未接続にかかわらずフローティングノードに12Vが出ています。

＞また、上記の電圧はDC的な（しばらくLI, HIをLowにした状態での）電圧という理解でよろしいでしょうか？
＞ブート容量（C22）に電荷がチャージされていない様ですので、スイッチングはしばらくしていない状態と認識しております。
→そのような認識で会っています。

以上、よろしくお願いいたします。

[Yojiro従業員]

amatsu1さん

(IoutCommand_Ch1 – IoutDetect_Ch1) < 0になった時に　(IoutCommand_Ch1 – IoutDetect_Ch1)が
マイナスになることを想定しているのですが、そうなっておらず、
0になると仮定すると辻褄が合う気がします。

ご指摘頂いた点ですが、_iq宣言は実際はsigned longですので、減算で負になる場合でも0になることはありません。

制御ループ内の次回に使用する演算結果（CtrlVal1_Ch1）をCMPAレジスタへの設定値から保存されていますが、CMPAの小数部は8ビットになり、CtrlVal1_Ch1=EPwm3Regs.CMPA.all;により演算結果の下位8ビットは切り捨てられます。

例として、エラー（IoutCommand_Ch1 – IoutDetect_Ch1）が1000 だった時を考えてみたいと思います。
エラーが1000の場合、左14ビットシフトしているので Ierror0_CH1は1000 << 14= 0x3E8 * 16384 = 0xFA0000になります。
K0=0.00002(=0x0000_0001)で、__IQmpy(K0,Ierror0_Ch1,16)を計算しても、0x0000_00FAとなり前回の反映値に対し加算したとしても、CMPA/CMPAHRレジスタの設定値に変化はありません。
これが、原因であると考えます。

次回に使用する演算結果（CtrlVal1_Ch1）は、CMPAレジスタ設定値ではなく、以下のように、演算結果を使用してご確認頂けますでしょうか。

NxtCntVal_Ch1 = __IQmpy(K0,Ierror0_Ch1,16)+__IQmpy(K2,CtrlVal1_Ch1,16);
EPwm3Regs.CMPA.all=__IQsat(NxtCntVal_Ch1, MAX_CNTVAL, MIN_CNTVAL);
CtrlVal1_Ch1=EPwm3Regs.CMPA.all;

↓

NxtCntVal_Ch1 = __IQmpy(K0,Ierror0_Ch1,16)+__IQmpy(K2,CtrlVal1_Ch1,16);
CtrlVal1_Ch1 =__IQsat(NxtCntVal_Ch1, MAX_CNTVAL, MIN_CNTVAL);
EPwm3Regs.CMPA.all = CtrlVal1_Ch1;

ご確認のほど、よろしくお願いいたします。

[amatsu1参加者]

大変お世話になっております。

上記のご質問の件ですが、こちらでも原因解析しておりますが、
(IoutCommand_Ch1 – IoutDetect_Ch1) < 0になった時に　(IoutCommand_Ch1 – IoutDetect_Ch1)が
マイナスになることを想定しているのですが、そうなっておらず、
0になると仮定すると辻褄が合う気がします。

本仮定が妥当な場合、その点からのご見解もお聞かせいただけますでしょうか。
以上、宜しくお願い致します。

[Yojiro従業員]

amatsu1さん

GLOBAL_Qは16でしょうか。

小数部のビット数が16ビットの場合、小数部1ビットあたり 0.0000152587890625 となります。
そのため、GLOBAL_Q = 16において、K0= _IQ(0.00002); とすると、K0は0x0000_0001(0.0000152…)となり、約23%の誤差が発生します。K0=_IQ(0.0005)では0x0000_0020(0.00048828125)になり、約2.3%の誤差になります。

小数部のビット数に対し、設定されている係数が小さすぎるために不具合が発生しているものと考えます。

つきましては、小数部ビット数に応じた有効桁数内での係数設定、あるいは小数部ビット数を大きくして計算してからCMPA設定時に16ビットに合わせていただく方法のどちらかをご検討頂く必要がございます。

小数部のビット数を大きくすると、整数部の範囲が小さくなりますので、ご注意ください。

 

ご確認のほど、よろしくお願いいたします。

いつも大変お世話になっております。

早速ですが、現在、添付のような不具合が起こっております。
なお、添付の通り、K0の値を大きくすると本不具合の程度が収まります。
また、<< 14によりMSBが0になっているのではと考え、*16384に変えてみましたが、
効果はございませんでした。

ソースコード上でこのような不具合が起こりうりますでしょうか。

_iq IoutCommand_Ch1; //grobal 宣言
_iq IoutDetect_Ch1; //grobal 宣言
_iq Ierror1_Ch1; //grobal 宣言
_iq Ierror0_Ch1; //grobal 宣言
iq K0; //grobal 宣言
iq K2; //grobal 宣言

IoutCommand_Ch1=3070;　　//別関数で代入
K0= _IQ(0.00002); //別関数で代入
K2= _IQ(1); //別関数で代入

interrupt void ADCINT1_ISR(void){
_iq NxtCntVal_Ch1;

IoutDetect_Ch1=AdcResult.ADCRESULT2;
Ierror0_Ch1= (IoutCommand_Ch1 – IoutDetect_Ch1) << 14;
NxtCntVal_Ch1 = __IQmpy(K0,Ierror0_Ch1,16)+__IQmpy(K2,CtrlVal1_Ch1,16);
EPwm3Regs.CMPA.all=__IQsat(NxtCntVal_Ch1, MAX_CNTVAL, MIN_CNTVAL);
CtrlVal1_Ch1=EPwm3Regs.CMPA.all;
Ierror1_Ch1=Ierror0_Ch1;
}

以上、宜しくお願い致します。

Attachments:

1. 

   75c14dbfd9e14a44fb362d56a05b6f36.png
   

[astro383参加者]

補足説明いただき有難うございます。こちらの内容にも注意して設計を進め 適宜 ご確認とさせていただけますと幸いです。

[Kawai従業員]

尚、補足ですが、お考えのように出力ポートを分散頂いた方がジッタ特性は良くなると考えます。

また、電源設計に関してはデータシートに記載のようにフェライトビーズで分離されることを推奨します。

Figure 40に一例がございますが、CLKOUTxの電源は同じ周波数である限りグループ化が可能です。

こちらに関しても、10.1.1.1項をご参考ください。

よろしくお願い致します。

 

Kawai

[astro383参加者]

ご回答有難うございます。頂きました情報にて疑問が解消されました。データシート P42 の内容に関してましても承知いたしました。

[Kawai従業員]

お世話になります。

お問い合わせの件ですが、出力ポートはご自由にご選択頂けます。

注意点としまして、2点コメントさせて頂きます。

①
LVCMOS出力ををご使用になる場合、
コンプリメンタリLVCMOS出力、LVCMOS(Norm/Inv) または LVCMOS(Inv/Norm)を
選択頂くことで、スイッチングノイズやクロストークの影響を低減することが可能です。
未使用側の出力はOPEN処理頂けます。

データシート（SNAS489K）　P.125　10.1.1.1 項をご参考ください。

②
0-Delayでご使用になる場合、
必ず、最も低い周波数を位相比較器へFeedback頂く必要がございます。

データシート（SNAS489K）　P.42　”8.3.10 0-Delay Mode”　の項をご参考ください。

 

Kawai

• この返信は5 年、 8 ヶ月前に  Kawai さんが編集しました。