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信号をソフトウエアの準備ができるまで出力しない様に固定してしまえば、一つのドライブに沢山の電流が流れ込んでしまう危険性が減ります。
とは言えプログラムが暴走しても上記問題が発生する可能性は否定できないので、適切な電流制限抵抗の設定と、場合に拠っては出力に高ドライブなバッファを入れてみては如何でしょうか。
> 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以外はいじらない。
なるほど、あんまり良くないのが存在するんですね。
こいつを今後どうするのか(個人的には更新版を正式リリースして頂くのが良いと思いますが)はさておき、これを解消するとkoheiさんの初期挙動「書き込みモード時にLEDがあちこち点灯する」が解決するのかが、気になるところでしょうか。
問題箇所を修正したものを暫定リリースいただき、koheiさん環境で試す(≒人柱)が宜しいのかなーと思ったりしますが、如何でしょうか?>koheiさん
みなさま、多数のReplyありがとうございました。
ぼくへの回答は、
①リセット・書き込み中は、(本体LED点灯等で故意にHighを出力してるポート以外は)各ポートは「入力」の設定で、Hiインピーダンス状態。
②外に付ける基板(に限らないデジタル回路)の入力部には、微小なノイズを拾って誤作動しない様に、適切なプルアップorプルダウンをつける。
で、充分です。
意外な盲点が存在してたようで、盛り上がって何よりです。
なお、別スレ「SAKURA暴走について」の方に、回路図・基板写真等、載せてます。初心者の作品例として、参考まで~。
(しかし…、という事は、ぼくが作ったLEDキューブ制御用の回路・基板は、コントローラ=SAKURAを外した状態で電源を入れると、それだけでノイズを拾って誤作動で壊れる可能性がある、という事なのかしら…。もちろん、ノイズを拾う「アンテナ」の受信能力によるでしょうから、SAKURAを繋いだ分だけノイズも拾いやすくなるだろうし、SAKURAが発生するノイズが乗る可能性もあるでしょうけど…。)
(これ以上ICが壊れるのはイヤなので、やってみないけど…。)
> リセット・書き込み中は、(略)各ポートは「入力」の設定で、Hiインピーダンス状態。
ここが疑わしいってハナシと思われますが、認識あってますですかね?外部バス有効という事は、マイコンが内部でメモリ等にアクセスしてる様子が、ピンにダダ漏れしてきてたりする?という事ですので、(バス仕様にもよりますが)「出力」になってる、という事です。しかも、koheiさん作品にピンポイントな事に、PortDとEがソレのようです。
書き込み時に一瞬ビカビカするってのは、まさにコイツの可能性がありますが。。
GR-SAKURAのUSB MSCファームのソースコードを見てみたのですが、(i)『外部バス許可ビット』というので『外部バス有効』にしているものの、(ii)端子の設定を外部バスとして使う設定にしている訳では無い、ようですので、岡宮様が先日書かれた動作内容の『P53(IO27)からBCLK出力(その後ライブラリ側で無効化)』しか影響が出ないような気がします。明日、岡宮様に要確認ですね。以下はUMの『16.2.8 バスの設定』からの抜粋なのですが、上記の(i)と(ii)がそれぞれ以下の(4)と(2)のことです。(他にも設定が必要ですが。)
(2)端子の設定を、CS 出力許可レジスタ(PFCSE)、CS 出力端子選択レジスタ0(PFCSS0)、 CS 出力端子選択レジスタ1(PFCSS1)、アドレス出力許可レジスタ0(PFAOE0)、アドレス出力許可レジスタ1(PFAOE1)、外部バス制御レジスタ0(PFBCR0)、外部バス制御レジスタ1(PFBCR1)で行います。
(4)システムコントロールレジスタ0(SYSCR0)の外部バス許可ビット(EXBE)を“1”(外部バス有効)に設定します。
ただ、外部バスを有効にすると、MPCの設定に関係無く一部の制御線が有効になってしまうんですよね。もともと発覚したのがXBeeと繋がらないと言うもので、これはXBeeの出力に使用している端子がRDになってしまったからです。
具体的にはWR0、RD、データバスの下位8bitです。
そのお話を聞いてUMを探してみたところ『22.3 外部バスインタフェース設定方法』の表が見付かりました。この表で『MPCのレジスタの設定』が『-』になっているところが該当する訳ですね。勉強になりました。(昨夜調べた時、なぜ気付かなかったのだろう、、、) あと、USB MSCファームのソースコードを見ていて思ったのですが、このコードはROMの後半の一部をROMの前半(先頭からベタ詰め)へプログラムコピーする処理を含んでいる訳ですが、コピーされるプログラムに新しいUSB MSCファームのバイナリを合体させておいて、コピーされたプログラムが自動的にその合体させておいた新しいUSB MSCファームのバイナリをROMの最後の64Kへプログラムコピーするというプログラムを作れそうな気がします。私はGR-SAKURAを持っていなくて、GR-CITRUSでということになってしまうのですが、チャレンジしてみようかと思います。(たぶん、GR-SAKURAへ流用できるかと、、、 とはいえ、来週の月曜日になっても出来なかったらギブアップします、、、)
今思ったのですが、Hi-zかどうかという観点では、外部バス空間への書き込みを行っていない筈ですので、データバスはHi-zのような気がします。そうだとすると、WR0#/WR#(P50,High出力)、RD#(P52,High出力)、BCLK(P53,クロック出力)ということですかね。
22.3 外部バスインタフェース設定方法http://resource.renesas.com/resource/lib/jpn/online_docs/um/RX/RX63N_RX631_ja/?MPC_63N#TOC_22_3
内部空間へのアクセス時に、外部空間のデータバスが動くかどうかまでは、わかりません。
GR-SAKURAがUSBマスストレージになっているときの全端子の状態を調べてみましたが、NoMaYさんがおっしゃる通り、IO24(P50/#WR)、IO26(P52/#RD)からはHIGHが出力されていました。その2端子とIO27(BLCK)以外のバス端子はHi-Zでした。もとの投稿も修正しました。
期待の挙動(全端子Hi-Zにより外部へ影響を与えない)と異なっており申し訳ありませんが、ご理解のほど宜しくお願いいたします。製品ページへの追記を検討したいと思います。
okamiyaさん
え、修正版FWは公開されないという事でしょうか?差し支えなければ、その理由をお聞きしたいですが。。
そもそもXBEEで不具合が発生している、のですよね?また、修正すべき箇所も判っており、修正しても問題が無い事も判っているんですよね??正式版ではなく暫定版としてすら公開の予定は無いという事なんでしょうか?
修正ファームは公開すべきと考えています。別件CITRUSのこともあり、また別スレでもmotの公開をするとリプライしてました。
現状motの書き込みツールがRFPしかなく、Windowsしか対応していないため、Mac対応をどうするか悩んでいる最中でした。
とはいえ、まずはWindowsだけでも対処すべきと考え、motの公開を来週11/25までにするよう、動作検証を進めていきたいと思っています。
お騒がせした今回の件、ようやく自作基盤の改良が終わりました。
自作基盤の信号入力にプルダウンを追加し、リセット・書き込みモード時にあちこちのLEDが点いてしまう現象は、ぴったりなくなりました。
詳細は別スレ「SAKURA暴走について」の方に書きます。
10個前の書き込みで書いた通り、SAKURA側にも疑わしい箇所があったとの事ですが、ぼくの件はやはり、自作基盤側の問題で確定でしょう。
「そもそもこのおっさんは何故、PortDとEを使ったのか?」という疑問がおありでしょうか?
8個の74HC595に一遍にデータを送るのに、ポートレジスタで1BYTE丸ごとで出力してます。(Arduinoでは「しないほうがいい」プログラムらしいですが、PICや他のマイコンだったら、普通にやりますよね?)
ピン配置を眺めて、ポート8bit全部使うのにPortDがよさげに見えたので。また、きれいにならんでるので、配線する時悩んだり間違えたりせずに済みそうだったので。(層選択のPortEは、結局1個ずつ出力してますが、同様の理由です。)
また、ラッチ・シフトクロック用に使ったIO52,53と+5V,GND含めて、全部の配線をSAKURA基板の片側からのみ引き出すので、繋げた時にかわいいSAKURAの基板がよく見える!というのも理由のひとつです~(なんてね~)