GR-SAKURA
GR-KURUMI
GR-COTTON
GR-CITRUS
GR-PEACH
GR-KAEDE
GR-ADZUKI
GR-LYCHEE
GR-ROSE
GR-MANGO(*)
SNShield
Web Compiler
IDE for GR
TOPPERS関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
arduinoも使った事ないマイコン初心者です。
初心者なのに、いきなり8×8×8のLEDキューブを作っています。
ちょっとずつプログラム作っては書き込んで確認してたのですが、とある日、点かなくなってるLEDがある…。確認の結果、どうも、8ビットシフトレジスタ:74HC595が2個程壊れてる様です…。
(IC単体の動作確認はまだしてませんが、壊れてると思う595をほかの列と差し替えたら、点かない列も変わりました。)
SAKURAにプログラムを書き込む際に、いちいちLEDキューブと制御回路から外すのめんどうなので、繋いだままプログラムの書き込みをしています。
リセットボタン押して書き込みモードになった際に、キューブのLEDが何やらあちこち点くので、「変な出力が出ると困るなぁ…」と思ってはいたのですが、74HC595に無理な負荷がかかってしまったかも知れません。
書き込みモード中の、各ポートの出力は、どうなってるのでしょうか?
意図しない動作を防ぐために、プログラム書き込み中は、シールドやI/Oポートに繋がってるものを外すのは常識でしょうか?
LEDキューブのコントロールは、
①ポートD(36~43)に、74HC595:8個のシリアル入力を繋ぐ。
②IO52に全部の595のラッチクロックを繋ぐ。
③IO53に全部の595のシフトクロックを繋ぐ。
④ポートE(44~51)に、一番上の層~下の層の全8層のどれを点けるのかの「層選択」のシンク回路を繋ぐ。
(回路図書くのが面倒で、文章だけですみません…。)
層は1個ずつしか指定しないので、プログラムがちゃんと動いてれば、74HC595は1個の出力からLED1個だけ、595:1個当たり最大8個しか点きませんが、ポートEの複数ビットが同時にHighになってしまうと、595の出力1ヶ所当たり最大8個、全部で64個のLEDが駆動される羽目になり、595が耐えれなかった可能性があります…。
以上、乱筆長文すみません。
状況は判りませんが、通常RESET中はGPIOは入力モードになっていると思われます。
CMOSは静電気などに弱いですし、HC595の各入力ポートには適切なプルダウン、プルアップ抵抗を付けてみては如何でしょうか?
またSAKURAとHC595で電源が異なる場合、電源立ち上がり時の電源電圧の差異による破壊も考慮する必要があります。
信号線に直列に抵抗を入れたり、ダイオードを使って上限設定をしたりします。
特にOE信号をソフトウエアの準備ができるまで出力しない様に固定してしまえば、一つのドライブに沢山の電流が流れ込んでしまう危険性が減ります。
とは言えプログラムが暴走しても上記問題が発生する可能性は否定できないので、適切な電流制限抵抗の設定と、場合に拠っては出力に高ドライブなバッファを入れてみては如何でしょうか。
koheiさん、こんにちは。
GR-SAKURAについて詳細に調べたことは無いのですが、設計者の意図的には(つまりバグが無ければ)、書き込みモード中は『Low出力』でも『High出力』でも無く『入力(Hi-z)』だろうと思います。(@chobichan様のおっしゃっているRESET中の状態を引き継いでいると思います。)
あと、「プログラム書き込み時にシールドやI/Oポートに繋がってるものを外す」ことを要求されたら、それを要求する方が非常識かな、とも思います。(不具合を特定する為に一時的にそのように依頼される場合は除きます。)
> GR-SAKURAについて詳細に調べたことは無いのですが、設計者の意図的には(つまりバグが無ければ)、書き込みモード中は『Low出力』でも『High出力』でも無く『入力(Hi-z)』だろうと思います。
GR-SAKURAのファームウェアを介してのスケッチ書き込み中はオンボードのLEDは点滅するので少なくともそれらが接続されてるPORTAについては操作しているようです。
GR-SAKURAのファームウェアの内容は公開されておりませんが、過去のプロデューサーミーティング当時のフォーラムの投稿を見てみるとファームウェアが外部バスを有効化するらしいというものが複数ありました。PORTDやPORTEは外部バスとピンを共通としており、ファームウェアの動作が当時と変わらずこれらのピンを初期化するものであれば、RX63Nがリセットで初期化され外部ピンがハイインピーダンスとなった状態はファームウェア起動後は保証されない可能性は考えられます。
皆様ありがとうございます。
chobichanさんより「プルダウンかプルアップ」と言われ、思い当たりました。
シンク回路は、最大でLED64個をONしないといけないので、Tr2つのダーリントン接続にしてます。
「ダーリントン接続の場合は、増幅度が1万倍とかになるので、浮遊ノイズを拾ってTrがONしてしまう可能性があり、確実にOFFするには、プルダウンした方がいい」という記事がありました。
「SAKURAがLOWを出力=GNDに落ちるはずなので、プルダウンは必要ない」。また、「HC595もシリアルデータ・シフトクロック・ラッチクロックの3つが揃わないとONしないし、気にする事ない」と思っていましたが、リセット・書き込みモード中が「宙ぶらりん」なら、プルダウンしといた方がいいかもしれません。
(リセット・書き込みモード中のLEDは、うっすらと点灯します。Tr若干ON状態かもしれません。)
(高ドライブのバッファは厳しいです…。64個必要なので…。)
HC595は、11/3にaitendoに発注して、今日届いて2個取り替えたら、表示はちゃんと直りました。
完全にスッキリはしませんが、プルダウン又は、制御回路(HC595)側のVDDを切って(SW追加)、安全側に対策を取って書き込みをしようと思います。
(ちなみに、制御回路とSAKURA用の電源は共通で、制御基板側にDCジャックつけて5VのACアダプタ繋いで、SAKURAのJ2短絡で、制御基板側から+5V端子に繋ぎこんでます。USB差すと、電源がケンカしそうでちょっと心配ですが、逆流防止のダイオードがついてましたよね。)
ところで、暴走について続けて質問させて下さい。(別質問にて)
うーん、リセット&書き込み時に各ポートがどうなっているのかは、ルネサスさんに正式に開示して頂きたい気もしますね。基板設計の根幹に関わる話とも思います。せめてoutputになるポートは知りたいです。
> ファームウェアが外部バスを有効化するらしい
そんな事も有りましたっけ、、、と思ったら外部バスを無効にしてくれ!ってスレッド立てているのオレだった。
なんででしょうね?特に外部メモリとか搭載されている訳ではないですが。
PDとPEはArduinoコネクタ側には配線されていないので、Arduinoコネクタを使っている分には大丈夫そうですね。
いや、その後新しいファームウエアでは無効になっているとも書かれていますね。
2012年の話だし、新しいファームウエアが適用されていないなんて事はないですよねー、、、
わかりませ~ん。が、やっぱり宙ぶらりんは良くないでしょうから、対策取ります~。
すみません、書き込み中のポート出力についてどうなっているのか調べられていませんが(忘れてしまっているのですが)、SAKURAのUSBファームは公開してますのでご確認いただければと思います。
bitbucket.org/.../sakura_usbfw
藤田様
フォローして頂きまして、どうも有難う御座いました。
> SAKURAのUSBファームは公開してますのでご確認いただければと思います。
ポートへの操作は src\SmplMain\RX63nSakura.c の
404: PORTA.PDR.BIT.B0 = 1; /* LED1 PA0 */ 405: PORTA.PDR.BIT.B1 = 1; /* LED2 PA1 */ 406: PORTA.PDR.BIT.B2 = 1; /* LED3 PA3 */ 407: PORTA.PDR.BIT.B6 = 1; /* LED4 PA6 */ 419: PORTA.PODR.BIT.B0 = 1; /* LED1 PA1 */ 420: PORTA.PODR.BIT.B1 = 1; /* LED2 PA2 */ 421: PORTA.PODR.BIT.B2 = 1; /* LED3 PA3 */ 422: PORTA.PODR.BIT.B6 = 1; /* LED4 PA6 */ 449: PORTA.PDR.BIT.B0 = 1; /* LED1 PA1 */ 450: PORTA.PDR.BIT.B1 = 1; /* LED2 PA2 */ 451: PORTA.PDR.BIT.B2 = 1; /* LED3 PA3 */ 452: PORTA.PDR.BIT.B6 = 1; /* LED4 PA6 */ 506: case 1: PORTA.PODR.BIT.B0 = dat; break; /* LED1 */ 507: case 2: PORTA.PODR.BIT.B1 = dat; break; /* LED2 */ 508: case 3: PORTA.PODR.BIT.B2 = dat; break; /* LED3 */ 509: case 4: PORTA.PODR.BIT.B6 = dat; break; /* LED4 */ 805: PORT1.PMR.BIT.B4 = 1u; 806: PORT1.PMR.BIT.B6 = 1u; 1166: if( PORTA.PIDR.BIT.B7 == 0 ) 1202: if( PORTA.PIDR.BIT.B7 == 0 ) 1223: if( PORTA.PIDR.BIT.B7 == 0 ) 1242: if( PORTA.PIDR.BIT.B7 == 0 ) 1288: if( PORT3.PIDR.BIT.B2 == 0) 1292: if( PORT0.PIDR.BIT.B0 == 0 ) 1296: if( PORT0.PIDR.BIT.B7 == 0 ) 2225: PORT3.PMR.BIT.B6 = 1; 2236: PORT3.PMR.BIT.B7 = 1; 2380: PORT5.PMR.BIT.B3 = 1; 2431: PORT3.PMR.BIT.B6 = 1; 2443: PORT3.PMR.BIT.B7 = 1; 2582: PORT5.PMR.BIT.B3 = 1;
のみで、PORTD や PORTE を弄ってはいないみたいですが、
2368: SYSTEM.SYSCR0.WORD = 0x5A03; /* External Bus Enable */ 2570: SYSTEM.SYSCR0.WORD = 0x5A03;
以上の箇所で外部バスを有効にしてるようです。尚、プログラムを追っかけてはいないのでどの状況でこの操作が行われているかは把握していません。
> 以上の箇所で外部バスを有効にしてるようです。
あー、なんか思い出してきました。
USBのブートローダーはなひたふさんが作成したのではなく、ルネサスの物なんじゃなかったでしたっけ?と言うか多分えびすさん。
なひたふさんは自身のファームウエアで外部バスを無効にする処理を入れた気がする。
今一度起動シーケンスを明確にして欲しいですね!岡宮さん。
#外部バス有効時に出力されてしまうポートを追記しました。 2016 Nov 15th
GR-SAKURAのUSB MSCファームの起動シーケンスは以下の通りです。外部バス有効の処理は確かにRSK用の初期化処理がそのまま残ってしまっていますね。
リセット
↓
割り込みベクタ、スタック初期化(ポートはいじらない)
usbc_cpu_McuInitialize():クロック、USBモジュール、外部バス有効化
・P53(IO27)からBCLK出力(その後ライブラリ側で無効化)
・P50/#WR(IO24)、P52/#RD(IO26)からHIGH出力
メモリなど初期化(ポートいじらない)
usb_pmsc_MainInit():USB、DMA、LEDの初期化
・P14(IO32)→USB0_DPUPE、P16(IO34)→USB0_VBUS
・PA0(LED0)、PA1(LED1)、PA2(LED2)、PA6(LED3)を出力
ソフトウェアリセットを検出(SYSTEM.RSTSR2.BIT.SWRF == 1)していたらユーザーアプリへ分岐
パワーオンリセットを検出(SYSTEM.RSTSR0.BIT.PORF == 1)していたらユーザーアプリへ分岐
USBマスストレージになる。
以降、bin書き込みなどでもポートは上記のLED、USB以外はいじらない。