おしゃべり時計withUSB開発日誌(12)、SOSC VT-200-Fクリスタルの所定数について。

 おしゃべり時計withUSBは、(株)秋月電子通商で売っている VT-200-Fクリスタルを RTCC用の発振子として使っています。　許容偏差±20ppm(±1.7秒/1日)の誤差で￥30-(20201028)のリーズナブルなクリスタルなのですが、PICで使っているとたまに壊れる事があります。

VT-200-Fの仕様を確認すると、水晶励振レベル(DL)が０．１μW、最大１μWと非常に低いドライブレベルです。その為PICに直接接続するとドライブレベル(DL)が大きすぎて壊れてしまうようです。

このドライブレベルを下げるためには、SOSCOピンに直列に抵抗(Rd)を入れて調整する必要があります。　この直列抵抗の値の選定については、PIC32MXのセカンダリオシレータ (SOSC) 水晶振動子回路の設計における注意点(AN2351)に詳しく書かれています。　この資料に記載がありますがPIC32MXのSOSCを確実に発信させる為には、A点の電圧が400mV必要です。　AN2351の資料では、調整時のRdのポテンションメータとオシロスコーププローブの影響を考慮して600~900mVのレンジ内になるよう、直列抵抗Rdの値を調整するように記載されています。　また残念ながらこの方法で求めた直列抵抗Rdの値が、VT-200-Fの仕様を満たす最大励振レベルとなるかどうかは分かりません。　

またAN2351の資料に、C1,C2の求め方も記載されていますが、コンデンサの値をいくつか試して最も安定している値にするよう記載されています。　実際の所C1,C2の値が小さくなれると周波数が高くなり、C1,C2の値が大きくなると周波数が低くなります。　またC1,C2の値が小さいと発信が不安定になり、C1,C2の値が大きいと発信が安定します。

手持ちのVT-200-Fとコンデンサで調べたところ、15pFで＋10ppmほど周波数が高くなり、33pFで-10ppmほど周波数が低くなるようです。その為おしゃべり時計withUSBではC1,C2を22pFとしました。　これについても水晶振動子やコンデンサの個々の状態によって変動するものであり目安でしかありません。

さて直列抵抗の値についてですが、PIC32MX250F128B,VT-200-F,C1/C2=22pf,気温20°C,電源電圧3.3Vでいくつか試した所、以下ようになりました。

• 2.6MΩ - 100mV
• 1.6MΩ - 200mV
• 1.0MΩ - 300mV
• 620KΩ - 400mV
• 510KΩ - 480mV

2.6MΩ - 100mV

1.6MΩ - 200mV

1.0MΩ - 300mV

620KΩ - 400mV
 

510KΩ - 480mV

注意点としては、A点の電圧が下がると水晶発振が始まるまでの時間が延びます。計測では300mVで約2秒、200mVで約8秒かかり、100mV以下では数十秒たっても起動しなくなりました。

1.0MΩ - 300mV

1.6MΩ - 200mV

以上を踏まえ、おしゃべり時計withUSBでは、C1,C2=22pF Rd=510KΩ としました。

水晶のドライブレベルを確認するため水晶振動子に流れるドライブ電流を計るには、トランジスタ技術2020年11月号に表面実装ｔｙｐｅの水晶振動子を使った発信回路の設計＆測定技術の記事に詳しく書かれています。　しかしながら自分は電流プローブもスペクトラムアナライザも持っていない為、記事の方法では残念ながらドライブ電流を計る事ができませんでした。

※20210723追記

新しいPICでは、RTCCの設定がLow Power Modeがデフォルトとなっており、この場合上記の設定ではRTCCが動かない現象に遭遇しました。RTCCがLow Power Modeの場合は、C1,C2=15pF Rd=0Ωとしています。

⇒https://planetxgear.blogspot.com/2021/05/vfdld8035eclock-15.html

参考文献

• PIC32MXのセカンダリオシレータ (SOSC) 水晶振動子回路の設計における注意点(AN2351)
•  VT-200-Fクリスタル
• トランジスタ技術2020年11月号、表面実装ｔｙｐｅの水晶振動子を使った発信回路の設計＆測定技術
• ドライブレベル・水晶振動子の回路（ムラタ）

PIC32MX250F128Bのコンパレータモジュールの設定でトホホな話し。

PIC32MX250F128Bにおしゃべり時計のプログラムを構築している。
電源電池の電圧低下と明るさセンサーの検出にコンパレータモジュールCMP1/2を今回使用する事にしたので、そのロジックをテストしていたのだが、これがどうやっても動かない。　
結局1日かかってMCCの出力したコードが、CMP1/2のレジスタ設定をうまく出来ないという事が分かった。

MCCで下記のように設定して、CMP1の入力をCVREFとC1INBに設定する。

するとMCCの出力したレジスタ設定コードは、CM1CONSET = 0xA010;となるが、、

残念ながら CM1CON = 0xA010;とCM1CONの方に設定しないと、PIC32MX250F128Bのコンパレータは思った通りに動かない。

PIC32MX250F128Bのヘッダーファイルの中身は下記の通りで、COM1CONSETは記述されてはいる。

しかしながら、PIC32MX1xx/2xx DataSheetには、COM1CONSETの記載が無い。


ふと考えてPIC32MX3xx/4xx DataSheetを確認した所、こちらにはCOM1CONSETの記載がある。

思うに PIC32MX1xx/2xxのチップでは、COM1CONSETはマッピングされていないのではないだろうか。。。　20200723(+8.0h)

PIC32MX DMA転送サンプル "文字列" ⇒UART2 TX へDMA転送

DMA転送のサンプルです。
文字列 "Hello World!" を UART2 TX レジスタへ１バイトずつDMA転送します。
転送のトリガーは TMR5 の割り込み発生です。
また、メッセージデータを半分まで転送したら LED2をONにし、全メッセージを転送終えたら、LED2をOFFします。　これはDMAチャンネル1の割り込みで処理します。
全てのメッセージを転送（ブロック転送）終えたら、再度転送を再開します。


const BYTE bMsg_DMA[] = {
    "Hello World!\r\n" 
};


void vDMA_Test_SettingAndStart (
)
{
    //DMA Channel 1 settings
    DCH1CON = 0x0000; // DMA Channel 1 disabled
    DMA_SourceAddressSet(DMA_CHANNEL_1, (uint32_t)&bMsg_DMA);
    DMA_SourceSizeSet(DMA_CHANNEL_1, sizeof(bMsg_DMA));
    DMA_DestinationAddressSet(DMA_CHANNEL_1,(uint32_t)&U2TXREG );
    DMA_DestinationSizeSet(DMA_CHANNEL_1,1 );
    DCH1ECON = (_TIMER_5_IRQ << _DCH1ECON_CHSIRQ_POSITION ) | ( 1 << _DCH1ECON_SIRQEN_POSITION); // Trigger on TMR5 interrupt
   
    // CHSDIF All source data transfer  finished.
    // CHSHIF 1/2 of source data transfer finished.
    DCH1INT =  ( 1 << _DCH1INT_CHSDIE_POSITION) | ( 1 << _DCH1INT_CHSHIE_POSITION);  // DMA interrupt setting
   
    // CHEN:1=Enable channel
    // CHAEN:1=Keep channel auto enable after block transfer completes
    DCH1CON =  ( 1 << _DCH1CON_CHEN_POSITION) | ( 1 << _DCH1CON_CHAEN_POSITION);  // DMA START with Repeat
}


void vDMA_Test_InterruptCheck (
)
{
    if (DCH1INTbits.CHSDIF == 1)    // All source data transfer  finished.
    {
        LED2_SetLow();
        DCH1INTbits.CHSDIF = 0;
    }
    if (DCH1INTbits.CHSHIF == 1)     // 1/2 of source data transfer finished.
    {
        LED2_SetHigh();
        DCH1INTbits.CHSHIF = 0;
    }
   
}

 MCC settings  

DMA Channel 1 setting

TMR5 setting

Interrupt Setting

実行結果

参考情報
・セクション31. DMA コントローラ
・PIC32のDMA機能を使ったLEDディスプレイ表示実験

PIC32MX USBMSC USBメモリで音声再生4_読みだす単位を4096byteへ変更

20200225(+6.0h)

前回のUSBメモリとのデータ転送とNAKの問題を解決しました。　USBメモリからの1回のデータ転送のByte数をセクタに合わせて512Byteに設定していたのが問題でした。　これを8倍の4096Byteにしたところ、NAKの返信回数が減り、16bit-Stereoのデータもそれなりに再生できるようになりました。


USBメモリをフォーマットする時にアロケーションサイズを指定できます。　このアロケーションサイズに合わせて一回のデータ転送Byte数を設定したいところですが、最近のUSBメモリのアロケーションサイズは8Kbyteや16Kbyteと大きめです。 PIC32MXマイコンはRAMの容量が限られていますで、しかたなく4096Byteとしました。　

PIC32MX USB PLAYER 16bit Stereo 20200225

USBからのデータ転送を4096byte単位にして 16bit Stereo dataの再生に間に合うようになりました。

PIC32MX USB PLAYER 8bit Mono 20200225

比較用の 8bit Mono dataの再生。　USBからのNAKが減り、処理自体が安定しました。

PIC32MX USBMSC USBメモリで音声再生3_何とか再生、しかし、、

PIC32MX USB PLAYER  8bit Mono
開発中の USBメモリから音楽データを演奏するPLAYER のテスト1。　
8bit 1Channel(Mono) のデータを再生し、パソコンのマイクで拾って録音した再生音です。

https://youtu.be/B0l3OPqjvjg

PIC32MX USB PLAYER  16bit Stereo
開発中の USBメモリから音楽データを演奏するPLAYER のテスト2。
16bit 2Channel(Stereoo) のデータを再生し、パソコンのマイクで拾って録音した音声です。
USBの転送レート12Mbps(Full Spead)では、データの転送が音楽の再生に間に合わず、音がわれてしまっています。　手持ちの中でも応答の速いbuffaloのUSBメモリをつかっていますので何とか聞き取れます。　

https://youtu.be/Yj5Gu7LXn14

しかし応答の遅い格安USBメモリになると、NAKの返信が多くなり、まともに音声を再生できません。

PIC32MX USBMSC USBメモリで音声再生2

20200216
wave file の再生プログラムのコーディングで、またまたトラブル発生。
短いテキストファイルを、ダーッと表示するだけならば問題なく表示されるのですが、ちょっと長いwave file を読みだそうとすると途中で無応答となりエラー(オレンジ色)となる現象が発生。

※黄色の'N'の連続は、メモリがNAKを返している部分です。

これは、トークン処理の終了を通知するU1IRbits.TRNIFのONを上手くとらえる事が出来ていない現象でした。

割り込み処理で同じU1IRレジスタのU1IRbits.SOFIFフラグをチェックしているのですが、このビットクリアをすると、ほかのU1IRのビットもクリアされてしまっていました。
これについては、一旦U1IRbits.TRNIFを別変数で保存してそれを参照・チェックする暫定処理を入れて逃げています。　


ここが何とか通ったと思ったら、次は　U1EIR.EOFEF(END OF FRAMEを検出)エラーが出るようになりました。これについては、U1SOF(SOF Threshold)の幅を0x4A→0x80に増やしてしのぎました。 20200216(+4h)


先に対応した、トークン処理の終了を通知するU1IRbits.TRNIFのONが上手くとらえる事が出来ない現象ですが、どうやってもまれに取りこぼしが発生します。　
いろいろと検討して、U1CONのトークン処理BUSYフラグの状態とBDTのUOWNフラグの状態を組み合わせてチェックする事で何とか解決出来ました。20200217(+4.0)

PIC32MX USBMSC USBメモリで音声再生１

20200210
USBメモリのアクセスがそこそこ出来るようになったので（アクセス出来ないUSBメモリには目をつむって）、次はUSBメモリを使って音声再生するガジェットを作ります。 WAVE PLAYER／PCM PLAYERというやつですね。

以前作った、おしゃべり時計のプログラムを移植すれば行けそうです。　しかしながら、昔コーディングしたプログラムでは、いろいろ拙いところが目に付くので、手を入れたいところ。。。

まずはFIFOの処理あたりから見直そうと修正したのですが、しかしながら見直したロジックではちっとも動かず。一体なにが悪いのか？　一度作戦を練り直さねば。20200210(+4.0h)

FIFO処理の見直しは一旦横において置いて、以前作ったSpeakingClockからメインとなる処理をCopyしてテストしています。　一日ほどの作業でファイル操作関連の処理がそれなりに動くようになりました。　短いファイルならば問題なくファイルの中のデータを取得表示できるのですが、音楽ファイルはどうやっても途中でUSBメモリの読み出しが途切れてしまいます。20200212(+8.0h)


以前アクセスできなかった アマゾンの格安メモリですが、最初につないだ直後なら、それなりにUSBメモリのファイルにアクセス出来ることに気が付きました。　しかしながら、エラーになるとドライバの初期化手順を実施しただけでは復帰しません。　USBメモリデバイス自体をリセットするような方策が必要なようです。20200214

※左側の青いUSBメモリだけアクセスできない。

PIC32MX USBMSC USBメモリのアクセス、不調の原因

アクセスがエラーになるUSBメモリがあるものの、それ以外のUSBメモリのアクセスが出来るようになりましたので、FatFsを組み込んで、いつものpicクラブの情報交換会に発表に行ってまいりました。

しかしながら持参したパソコンの調子が悪く、後閑先生からノートパソコンをお借りしてデモを実施したのですが、これがどうやっても途中でエラーが発生して、USBメモリのアクセスが上手くいきません。　なんとか持参したパソコンを再起動して、情報交換会の最後でデモを行う事ができました。　

この事象により今まで不安定だった原因がいくらか判明しました。
実はこのプロジェクトで作成したデモ用の基板は、秋月のUSB-シリアル変換器からのバスパワーで動かしています。　この USB-シリアル変換器の回路図を確認したところ、バスパワーの供給ラインの途中に保護用に100mAのポリスイッチが入っていました。



　
つまり、このUSB-シリアル変換器で供給できる電流は100mAまでです。USBによってはアクセスが発生した場合に大きな電流を消費し電源電圧が下がって不安定になったものと思われます。

この100mAのポリスイッチをバイパスし、USBメモリの根本に100uFのコンデンサを追加してかなり安定してUSBメモリにアクセスが出来るようになりました。

今回判明したUSBメモリの消費量が意外に大きいので、これは今後の設計の課題となりそうです。

20200204

PIC32MX USBMSC USBメモリのアクセスが出来ない

なかなか進まない、USBメモリドライバの開発です。
PIC32MXでUSBメモリにアクセスするの、ようやく何とか出来るようになってきました。

20200111
前回までで、下記写真の右側のUSBメモリに、SCSIコマンドでアクセス出来るようになりましたが、左側のアマゾンで買った格安の青いUSBメモリと黒いUSBメモリが上手く動きません。　その為今一度、全てのUSBのDESCRIPTORを調べてみました。

20200115
DESCRIPTORを調べて対応して、下記写真の右側については、SCSIコマンドも上手く通りリードライトが出来るようになりました。
前回より一歩進んで黒いUSBメモリにもアクセス出来るようになりました。

黒いメモリが読めなかった原因が、IN/OUTのエンドポイント番号が他のUSBメモリと異なっていた為で、前回まで決め打ちでIN=EP1、OUT=EP2としていたのを、ENDPOINT DESCRIPTORを読込んで対応するようにしました。

その他、通信の各エンドポイントのDATA0/1の切り換えとか、BDTテーブルのピンポンバッファの指定が上手くなかったようでそのあたりも見直しました。

残るは、左側のアマゾンで買った格安のUSBメモリです。　これについてはSCSIコマンドのINQUIRYコマンドまでしか通らず、SCSIコマンドでのREAD・WRITEコマンドが出来ません。

20200116
アマゾンで買った格安USBメモリ(左の青いやつ)がどうしてもエラーとなるので、パソコンにWiresharkというソフトをインストールして、パソコンとUSBメモリとの通信をキャプチャする事にしました。　パソコンと 問題のUSBメモリとの間でどんなやり取りをしているのかを参考にしようというわけです。※パソコンからは問題のUSBメモリが普通に使える。

1点見つけたのは、"Test Unit Ready"のSCSIコマンドが上手く行かなかった原因が、CBWCB長（SCSIコマンド長）の指定が間違っていたことでした。そこを直し"Test Unit Ready"コマンドが通るようになりました。

このWiresharkというソフトは優れものでパソコンのいろんな通信の内容をパケットキャプチャできるのですが、残念ながら実際のUSBとパソコンの間の通信をキャプチャしている訳ではないので、PID、DATA0/1 などのいくつかの情報は取れないようです。　気になっていた、通信上のDATA0/1の遷移はわかりませんでした。


                       https://www.wireshark.org/

20200121
左側のアマゾンで購入した青い格安USBメモリは、どうしてもアクセス出来ないのでついに諦めました。。。パソコンからは読み書きできるのですけど、何が悪いんだろうなぁ。

PIC32MX USBMSC ドライバ試作

PIC32MX USBMSC ドライバがようやく何とか動き始めたので、一旦Githubにアップロードしました。

https://github.com/PlanetxGear/PIC32MX_USBMSC_Driver_sample

PIC24F用に作成したUSBMSCドライバをPIC32MX用に移植したのですが、これがどうやっても動かない。。。USBメモリのAttach/Detachは検出するものの、USBメモリに最初にAddressを書き込みに行ったところでウンともスンとも言わなくなる状態です。　結局、USBのコントロールレジスタにBDTテーブルのメモリアドレスを設定する箇所が間違っていて、ここを「仮想アドレスから物理アドレスに変換して」設定しないといけなかったのです。　ここを見つけるのに一月かかってしまいました。　うっすらと以前に同じ経験をしたような記憶も、、、忘れていましたが。。。　なんにせよDMAなどを使うときは要注意、、いやいやDMAをもっと活用して「仮想アドレスから物理アドレスに変換する」ことを頭に入れておかないといけないですね。

20200105

ついでにこの問題点について、どうやって気づいたかも記載しておきます。

つまずいた点は、PIC側からUSBに向けて USB Addressを設定する SETUPコマンドを送信しても、それが ACKなのかNAKなのかのリターンが帰ってこない現象です。（※実際はBDTのアドレス設定が間違っていたので、そこにACK,NAKが書き込めていない。）

USB peripheral のレジスタ設定手順と、USBへの供給クロック設定を何度も見直しましたが原因わからず、、結果USBへの供給クロック設定についての以下の2点について疑問が残りました。
１．USB PLL のロックステータスフラグ(ULOCK@OSCCON)がどうやっても”１”が立たない。
２．DEVCONF2のUSBENBLの設定が、DATASHEETの記述と、MCCの設定表記と食い違いがあるように思える。
※ちなみに1.2.について現状はまだ判然としていません。20200108

これらについて、実際にPIC32MXでどのように設定されるのかネットを色々さがしたのですが見つからず、Harmony v3 で作ったプロジェクトと比較してみる事にしました。しかしながら Harmony v3は使った事が無かったので、プロジェクトを作るのにも一苦労して出来上がったプロジェクトも　またロクに動かすことができませんでした。　
USBモジュールやクロック設定した空のプロジェクトは出来てコンパイルも通す所までできますが、USB関連のFunctionが多くどれをどの順番でMain処理に並べて行けばよいのかがよくわからなかったのです。

そんな訳で続いて挑戦したのが、気分を変えてPIC32MMのテスト基板の組み上げと、MPLAB Xでのプロジェクト作成です。 PIC32MMのプロジェクトは、MCCからUSB（CDC、HID）の設定ができるので、 つまりこれを参考にしようというわけです。
MCCの設定は慣れたものなのでサクっと作り上げて、動かしてみたところDMA関係のレジスタに設定されたアドレス値が想定と異なっていたのでようやく気が付きました。　
後でマニュアルを確認しましたが Note にちゃんと「物理アドレスを設定せよ」と書いてありました。

最近は、取り組むプロジェクトが長丁場になる傾向があるのでブレッドボードはやめて、ユニバーサル基板にハンダ付けして組み上げるのですが、適当に作るのでいかんせん雑になります。作業も遅いので今回作ったPIC32MMの簡単なテスト基板でも４~５時間はかかってしまいました。

左から、PIC24FJ64GB002 / PIC32MX250F128B / PIC32MM0256GPM028

次のプロジェクトの準備、PIC32MX,PIC32MM など。

USB メモリ用のドライバを PIC32MX250に移植しようとしているのですが、32bitになってBDTの構成が変わり、またピンポンバッファ EVEN/ODDを切り換えて使わなければならなくなり、ちょっとてこずっています。

PIC32MX のMCCの出力コードと久しぶりに戯れてみたのですが、MCC出力コードのスタイルがちょっと古臭い印象を受けました。　もしかしたらMCCのどこかの設定をミスったかもしれません。

ついでに、PIC32MMにも移植予定なので、Microchip Directに PIC32MMを発注しました。　購入したのは、PIC32MM0256GPMのピン数違いの028,044,064です。　

PIC32MMxxxGPMのシリーズはDIP品が無いので仕方なく SSOP, TQFP を購入して秋月の変換基盤に載せました。

DIP品が少なくなってきているのは残念ですが、SSOP,TQFP の変換基盤へのハンダ付けもだんだん上手くなってきているような気がします。 20191215(+3.0h)