ホンダTLR250R修理改造とか: Z3805Aファームウェア関連/ MC68331/ Atmega AVR / MSP430 /Ghidra

2026-5～

Z3805A電源断トラブル復帰再稼働関係

https://rkphs.blogspot.com/2022/01/ups.html

Chapter 1 .

2026-5

メーカー？消滅ツールからリバースして流用出来るか(AVR系)

AVR（ATmega）のHEXファイルを解析するための最も優れた無料かつ標準的なリバースエンジニアリングツールは、米国家安全保障局（NSA）がオープンソース化した Ghidra（ギドラ）です。

手元にあるAVR8HEXソースを、ブラックボックスから「人間が読めるC言語に近い状態」までリバースするための手順とツール、そして今回の目標（恒星時変換の追加など）への繋げ方を詳しく解説します。

🛠️ AVR（ATmega）のバイナリをリバースする最強のツール群

バイナリファイル（HEX）しか手元になく、元のC言語ソースコードがない状態から通信仕様を暴くには、以下のツールが非常に強力です。

1. Ghidra（ギドラ） — 推奨・最高峰のデコンパイラ

特徴：完全に無料のプロフェッショナル向けリバースエンジニアリングツールです。 [1]
AVRへの対応：ATmega328PやATmega8などのAVRアーキテクチャに標準対応しています。
最大の強み：アセンブリ言語だけでなく、アセンブリを解析して人間が読める「C言語風のソースコード」に自動変換（デコンパイル）する機能を持っています。
解析の手順：
1. Ghidraを立ち上げ、新規プロジェクトを作成してHEXファイルをインポートする。
2. 言語選択で AVR8（またはターゲットのATmega型番）を指定する。
3. 自動解析（Auto Analyze）を実行すると、本体との通信で使われている「隠された文字列（SCPIコマンドなど）」や、ボタン処理の条件分岐がC言語風のコードとして右画面に表示されます。

2. Radare2 / Cutter — 高機能なオープンソース・ディスアセンブラ

特徴：ハッカーコミュニティで愛用されるリバースツールで、AVRマイコンのバイナリ解析（特にCTFやハードウェア解析のチャレンジ）で非常によく使われます。 [1, 2]
GUI版（Cutter）を使用すれば、プログラム全体の構造がフローチャート（グラフ表示）として視覚化されるため、「ボタンが押されたときに、どこへジャンプしてどのシリアルデータを送っているか」の処理の流れを目で追うことができます。

3. avr-objdump — 確実なコマンドラインツール

特徴：Arduino IDEやMicrochip Studio（旧Atmel Studio）の裏で動いている公式の開発ツールチェーンに含まれるツールです。 [3]
コマンドライン（ターミナル）で以下のコマンドを叩くだけで、HEXファイルを一瞬で標準的なAVRアセンブラコードに書き直してテキスト出力してくれます。
```
avr-objdump -m avr -D your_file.hex > disassembled.txt
```

🔍 このHEXソースから「何を」読み取るべきか？

元のサイトが消えており、HEXやbin しか残っていなくても、HEXをGhidraなどで開けば「追加機能の実現」に必要な核心データが数分で手に入ります。特に、バイナリ内の「データセクション（文字列プール）」を最優先で覗いてみてください。

以下のような、HP 58503A（またはZ3801A）本体をコントロール・照会するための SCPIコマンド文字列がそのままの形（ASCIIテキスト）で埋め込まれている可能性が極めて高いです。

:GPS:POS?（位置・経度情報の取得 ➡️ 恒星時計算に必要な経度の自動取得に使えます）
:TIme:UTMe? または :SYST:TIME?（UTC時刻の取得 ➡️ JST変換や恒星時計算のベースになります）
:SYST:ERR?（アラーム内容・エラーログの取得 ➡️ アラーム表示に必須です）
*CLS（ステータスクリア ➡️ アラームクリアボタンを押した時に本体へ投げるコマンドです）

もしこれらのコマンド文字列がバイナリ内に見つかれば、先人の苦労（どのコマンドをどのタイミングで投げれば応答が返ってくるかという通信シーケンスの設計）をすべてそのまま拝借できます。

🎯 最終的な「勝ちルート」の提案

先人のATmega用のHEX（バイナリ）をそのまま100%リバースして完璧なコードに戻すのは骨が折れますが、「58503A本体とRS232Cでやり取りするためのテキストコマンド」さえ上記ツールで抽出できれば、もう勝ったも同然です。

その抽出したコマンドをメモし、コード自体は現代の使い慣れた環境（Arduino IDEなど）で、ESP32やRaspberry Pi Pico、新しいATmega向けに一からC言語で書く方式をおすすめします。これなら、

抽出したコマンドを定期的に58503A本体へ投げる。
返ってきたUTC時刻と経度を受け取る。
マイコン内の使い慣れたC言語ライブラリで、JST（+9時間）や恒星時（LAST）を計算し、現代の綺麗なカラー液晶に表示する。
アラームクリアボタンが押されたら、本体にクリアコマンドを送信する。

という仕様が、リバースエンジニアリングの「良いとこ取り」だけで最も安全かつスマートに実現できます。

Ghidraの導入や、このHEXファイルを一度アセンブラや文字列に落とし込んでみる初期解析のステップなど、さらに進めたい手順があればお気軽につぶやいてください！

[1] https://www.wonderfulpcb.com

[2] https://www.youtube.com

[3] https://github.com

ATmega644ベースのHP Z3801A用カスタムコントローラの回路図の設計思想をベースに、今回hp 58503-60010フロントパネル側で新しく判明した「3.6864MHzで駆動するSPIバス」へ適応（アドオン）させるための明確な方針を解説します。

1. 現状の回路図の構造分析（RS-232C直叩き）

回路では、左側の ADM232（RS-232CドライバーIC）を介して、本体背面のDSUB9（RS-232Cポート）とATmega644の PD0(RXD0) / PD1(TXD0) を繋いで通信しています。
表示は右側の並列（パラレル）接続されたキャラクター液晶 LCD1 へ出力し、ボタンは PA0〜PA3 に割り当てられた極めてストレートな調歩同期シリアル（UART）制御方式です。

2. 「フロントパネル用内部SPIバス」に対応させるための回路変更点

オリジナルのフロントパネル（58503-60010）と本体を繋ぐ J19コネクタ（IDC16ピン）内のSPIバスと直接通信させる場合、回路は以下のようにアップグレードする必要があります。

① MISO / MOSI / SCK ピンの割り当て変更

ATmega644（またはATmega1284P等）には、ハードウェアSPI機能が標準搭載されています。
回路図最上段にあるISP（書き込み用）コネクタに繋がっている以下のピンを、そのままJ19のSPI通信ピンへ「兼用」として引き出します。

PB5 (MOSI) ➡️ 本体からの表示データ受信、または本体へのコマンド送信（本体側の仕様に合わせる）
PB6 (MISO) ➡️ 双方向通信時の割り当て
PB7 (SCK) ➡️ 本体側から供給される（またはマイコン側から送る）シリアル同期クロック
任意の空きGPIO（例：PB4など） ➡️ SS / CS（チップセレクト）として割り当て

② レベルシフタ（電圧変換）の検討

現状の回路：ATmega644は +5V で駆動しています。
58503Aの内部バス側：もし本体側の内部SPIバスの信号が 3.3Vロジックだった場合、5V駆動のATmegaに直接繋ぐとポートを破損するか、正常に認識しません。これは確認が必要です。
3.3Vだった場合の対策：J19のSPI信号線の途中に、安価な双方向ロジックレベル変換モジュール（FXMA108や4回路タイプのものなど）を挟み、安全に5V ↔ 3.3Vの変換を行います（本体側が5Vロジックであれば直結で構いません）。

③ ADM232（RS-232Cポート）の処遇

内部バス（SPI）との通信が確立できれば、左側の ADM232およびDSUB9ピンは回路から完全に削除（無実装）することが可能です。これにより基板サイズを大幅にコンパクトにできます。

3. ファームウェア（移植・アドオン）の設計イメージ

手元にあるHEXソースのロジックを、SPI通信へと舵を切る場合のプログラムの書き換え構成（擬似コードイメージ）です。

// 現代のArduino(ATmega)環境での実装イメージ
#include <SPI.h>

void setup() {
    // ハードウェアSPIをスレーブ（またはマスター）として初期化
    // 3.6864MHzの4分周（460.8kHz）や16分周など、本体の速度に合わせる
    SPI.begin(); 
    
    // スイッチ（PA0-PA3）やLEDの初期化
    pinMode(A0, INPUT_PULLUP);
    ...
}

void loop() {
    // 1. 本体からJ19のSPI経由で送られてくる表示セグメント/テキストデータをバッファに受信
    if (SPI_data_available()) {
        char rx_byte = SPI.transfer(0x00);
        // りりっく氏の液晶表示ルーチンへデータを引き渡す
        update_custom_LCD(rx_byte); 
    }

    // 2. もし「アラームクリア」などのボタン（PA1等）が押されたら
    if (digitalRead(A1) == LOW) {
        // RS-232Cに送る代わりに、SPIバス経由で本体へクリアコマンド（キーコード）を送信
        SPI.transfer(CMD_ALARM_CLEAR); 
        delay(200);
    }
    
    // 3. 同時にUTCをJSTに変換、および経度から恒星時を計算して LCD1 へ描画
    display_time_modes();
}

💡 結論

この回路図の「ATmega644 ＋キャラクター液晶＋スイッチ」の基本骨格は100%そのまま活かせます。

変更するのは「左側のRS-232C回路を無くし、上側のSPIピン（PB5〜PB7）をJ19コネクタへ繋ぎ変えるだけ」です。ハードウェア的には非常にシンプルなマイナーチェンジで対応可能です。

この構成であれば、液晶をさらに大きなOLEDやカラー液晶に変更して「UTC / JST / 恒星時」を3行同時に表示させるような、オリジナルを遥かに凌駕する高機能コントローラへ発展させることができます。

58503-60010 J19側のピンの物理的な配置（ピッチやコネクタ形状）など、基板設計に向けて次に詰めたい要素はありますか？

“Z3805A-J19の推定を含む本体側現状では以下。マニュアルだと58503-60010キットのリボンを差し込むだけで認識するかのように書かれている。

解ってる範囲は、以下。解明出来ていないのは#9～#15pin

J19(IDC16pin)(LED駆動は+5V正論理) (挿入抵抗)(フロント基板側)

-1：LED(DS2)-Enable (909Ω) 　

-2：GND 　

-3：LED(DS3)-Active (909Ω) 　

-4：LED(DS4)-Alarm (909Ω) 　

-5：無実装(LED(DS5)-(NC)) (909Ω) 　

-6：LED(DS6)-GPS Lock (909Ω) 　

-7：GND 　

-8：LED(DS7)-Hold Over (909Ω) 　

-9：

-10：

-11：

-12：　

-13：GND 　

-14：

-15：　

-16：+5V/LED(DS1)-Power (1600Ω)

----

Ghidra 12.1, JDK 21

GhidraでAVR8のベアメタルファームウェア（ATmega644など）を解析するには、ハーバードアーキテクチャとメモリマップドI/Oを使用しているため、特別な処理が必要です。Ghidraは静的解析に依存しているため、バイナリメモリマップを正しくインポートし、プロセッサ言語バリアントを指定することが重要です。 Jonas Lieb +1 1. 初期設定と言語選択ダンプしたファームウェアをGhidraにインポートする際には、プロセッサアーキテクチャを手動で設定する必要があります。 Ghidraを開き、新しいプロジェクトを作成します。バイナリ（通常はavrdudeで抽出したもの）をプロジェクトにドラッグアンドドロップします。 Stack Overflow +1 インポートダイアログで、GhidraがATmega644を自動的に検出しない場合があります。「言語」の横にある3つの点（…）をクリックしてください。アーキテクチャとしてAVR8を選択し、atmega644（644がリストにない場合はatmega64）を選択し、バリアントを16（アドレス指定ビット）に設定して、little / gccを実行します。 Jonas Lieb ベースアドレスが0x0000に設定されていることを確認してください（GhidraはデフォルトでAVRのフラッシュメモリをここにマッピングします）。 Jonas Lieb 2. メモリセクションの定義最新のオペレーティングシステムバイナリとは異なり、ATmegaファームウェアは特定のメモリセグメント内にコードとデータを混在させています。Ghidraの自動解析でI/OポートまたはEEPROMのマッピングがうまくいかない場合は、手動でマッピングする必要があります。 GitHub +1 ウィンドウ > メモリマップに移動します。 starkeblog.com Atmel ATmega644データシートに記載されているとおりにメモリブロックを追加または確認してください。フラッシュ/コードセグメント：0x0000から始まります（実行可能、読み出し、実行）。内部SRAM：通常0x0000～0x10FF（読み出し、書き込み）。 I/Oレジスタ：通常0x0020～0x005F（拡張コントローラの場合は最大0x00FF）。 Jonas Lieb +1 3. 自動解析と逆アセンブルの実行 Ghidraの自動解析（解析→自動解析）をデフォルトオプションで実行します。 Jonas Lieb AVRは16ビット命令を使用するため、生の16進数として表示される（または制御フローの切り捨て警告が表示される）未解析バイトは、手動で逆アセンブルする必要があります。リストビューで未解析バイトを選択します。キーボードのDキーを押して強制的に逆アセンブルを実行します。 Fキーを押して、逆アセンブルされた命令を関数に変換します。 Medium ·Ryan Cornateanu +1 4. 割り込みベクタテーブルの解決リストビューを見る際に最も重要な最初のステップは、バイナリの先頭にある割り込みベクタテーブル（IVT）を確認することです。最初の命令は通常、RESETベクタへのJMP命令です。 Jonas Lieb +1 0x0000に移動します。 0x0000の命令をresetと命名します。 Ghidraが制御フローを追跡しやすくするために、後続のベクタ（例：INT0、TIMER0_OVF）をメモリマップに従って命名します。 Jonas Lieb 5. IOレジスタ定義の適用逆コンパイルされたCコードを読みやすくするために、レジスタマッピングをインポートできます。これにより、コードがRAM_0x3eのような生の16進アドレスを表示するのではなく、レジスタマッピングをインポートできます。 GitHub スクリプトマネージャを開きます（ウィンドウ > スクリプトマネージャ）。 CreateAVR8GDTArchiveScript.javaが存在する場合は実行し、存在しない場合はATmega644周辺機器領域（PORTA、DDRB、TCCR1Aなど）の列挙型を手動で定義してください。 Attify +1 AVRアーキテクチャ向けにGhidraを設定する方法、メモリマップと割り込みベクタを操作する方法については、以下を参照してください。

Chapter 2 .

ebayで売られていた中古、Penter inc.製 Model SA101 260042-01 rev C ; OncoreM12互換インターポーザー付。コントローラ(CPU)は　TI MSP430F1471

OncoreM12互換インターポーザー(NMEA>Motorola-BIN変換付き)　GT-8031H
(GT-8031F タイプもある模様)

基板サイズ 40x60mm

https://www.ebay.com/itm/285983348465　　など
jp￥3000～6000円程度

(裏面)

MCX-fe

10pコネクタの向きなどOncoreVPとは異なる(M12互換)。

ebay紹介文：
「Furuno GT-8031H and GT-8031F GPS module for Symmetricom, Fei Zyfer etc」
「GPS Receiver Card Motorola M12+ Furuno GT-8031 Pentar SA101 /Good TIME Bad DATE」
“このカードは GPS システムから正しい時刻を取得しますが、Furuno GT-8031 モジュールに影響する週番号ロールオーバーイベントのため、日付は 1024 週間前の日付になります。これは、アップグレード中の正常に動作していた GPS 受信機 (Symmetricom Syncserver) から取り外されたものです。そのため、このカードは 2022 年 9 月に同期が停止した Syncserver (S200/S250/S300/S350)/XLi/XL-GPS ユニットの問題を解決しません。このカードは、ユニットを分解する前に (日付の問題を除いて) 正常に動作することがテストされています。M12+ ベースのデバイスが動作しているものの、週番号ロールオーバーイベント (つまり、報告される日付が約 20 年前の日付になっている) が発生している場合、このカードをインストールしてもその問題は解決しません。必要なのが正しい GPS 時刻および/または正確な 1PPS レート (ほとんどの GPS 受信機の 10MHz 発振器を同期させるために使用されるもの) である場合は、このカードは正常に動作するはずです。“
“ 使用済みのFuruno GT-8031HおよびGT-8031F GPSモジュール。Symmetricom、Fei Zyferなどに対応します。1024週ロールオーバー問題のため退役です。最新のGPSモジュールが必要な場合は、検索で「Furuno GT-8736D」または「Trimble MT48」をebays内で確認してください“

...つまり $GPZDA.... コマンド修正が起動都度必要らしい(又はバッテリーバックアップ)。インターポーザーCPUの初期化シーケンスにも追加が必要。ウチの場合、今回(2026)は、UPS故障での電源断なので、過去の全てのアルマナックなど履歴は失われ、再稼働させるにはその点もクリアしないといけない。

(AI(Gemini)検索　/2026-8/3)
“MSP430F1471 の、JTAG 書き込み読み出し、最安の方法は　?

MSP430F1471のJTAG書き込み・読み出しにおける最安の方法は、MSP430G2 LaunchPad（MSP-EXP430G2ET）のオンボードエミュレータ（eZ-FET）を流用する方法、またはAmazonやAliExpress等で販売されているMSP-FET430UIF互換の中華製USBプログラマを使用する方法です。

MSP430F1471は古い第1世代のデバイスであり、最新の「Spy-Bi-Wire（2線式JTAG）」には対応しておらず、4線式JTAG（4-wire JTAG）での接続が必須となります。

最安の選択肢2選

方法	概算費用	メリット	デメリット / 注意点
MSP430G2 LaunchPadの流用	約2,500円〜3,500円	信頼性が高い、公式IDEでそのまま動く	ジャンパーピンから4線式JTAGの配線を引き出す工作が必要
MSP-FET430UIF 互換品（海外製）	約3,000円〜5,000円	標準の14ピンJTAGリボンケーブルがそのまま使える	偽物チップによるドライバトラブルや、最新IDEで認識しないリスクがある

方法1：MSP430G2 LaunchPadをプログラマとして流用する（最推奨・最安候補）

テキサス・インスツルメンツ（TI）が提供する低価格評価ボード MSP-EXP430G2ET LaunchPad を購入し、ボード上のエミュレータ部分だけを外部のMSP430F1471に接続します。

接続手順（4線式JTAG）

LaunchPadの中央にある「J3」ジャンパーピン（TEST, RST, VCC, GNDなど）をすべて外します。エミュレータ側（USB端子側）のピンから、ターゲットのMSP430F1471へ以下のように5本（信号4本＋GND）を配線します。

TCK ➔ MSP430F1471の TESTピン（または専用のTCKピン）
TMS ➔ MSP430F1471の TMSピン
TDI ➔ MSP430F1471の TDIピン
TDO ➔ MSP430F1471の TDO/TDIピン
GND ➔ MSP430F1471の GND
VCC ➔ ターゲット基板に電源がない場合のみ、LaunchPadの3.3Vから供給

※LaunchPadのエミュレータ（eZ-FET）は通常2線式（SBW）ですが、一部のLaunchPadは4線式JTAGの信号線も引き出せるよう基板上にパターンが用意されています。

方法2：MSP-FET430UIF 互換品（中華製サードパーティ品）

AmazonやAliExpress、eBayなどで「MSP-FET430UIF 互換」や「MSP430 USB Debugger」として検索すると見つかる、グレーのケースに入った格安の互換機です。

注意点

古いソフトウェア環境が必要な場合がある：最新の「Code Composer Studio (CCS)」や「IAR Embedded Workbench」では、互換機のファームウェアのバージョンが古いためにエラーで認識されないケースが多発しています。その場合は、古いバージョンのCCS（v5やv6など）を使用するか、書き込み専用ツールの「MSP430 Flasher」の旧バージョンを使用する必要があります。
読み出し（ダンプ）の制限：もし既存のマイコンからプログラムを「読み出す（吸い出す）」ことが目的の場合、元々のマイコンのJTAGロック（セキュリティヒューズ）が切断されていないことが前提です。ロックされている場合はどのツールを使っても読み出せません。

ソフトウェア（書き込み・読み出しツール）

最安（無料）で読み書きを行うには、TI公式のコマンドラインツール MSP430 Flasher を使用するのが最も確実です。

読み出し（ダンプ）コマンド例：
MSP430Flasher.exe -n MSP430F1471 -r [output.txt, MAIN]
書き込みコマンド例：
MSP430Flasher.exe -n MSP430F1471 -w "input.txt" -v

現在、ターゲットのMSP430F1471はどのような状態（すでに自作基板や製品に実装されている、またはピッチ変換基板などの単体状態）でしょうか？

製品メーカーによってJTAGロックがかけられていて中身が「読み出せない」状態であっても、内部を強制的に一括消去（Mass Erase）すれば、別のプログラムを書き込んでチップを再利用することは可能です。

ただし、MSP430F1471の世代の仕様上、接続方法に以下の注意点があります。

ロックされている場合の挙動と再利用方法

MSP430F1471（第1世代）は、セキュリティロックを「物理的なヒューズを過電圧で焼き切る」ことで実現しています。そのため、メーカー側が量産時にヒューズを焼き切っているかどうかでアプローチが変わります。

パターンA：JTAGヒューズが焼き切られている場合（量産品で多い）

JTAG経由での消去・書き込みは「不可能」です。物理的にJTAGポートが破壊されているため、MSP-FETなどを繋いでも一切認識しません。
解決策（再利用方法）：マイコンに内蔵されている「BSL（ブートストラップローダー）」というUART（シリアル）通信機能を使用します。BSL経由であれば、パスワードが不明でも「一括消去（Mass Erase）」コマンドを送ることで、内部データを完全に消去し、新しいプログラムを上書きできるようになります（以降の書き込みもBSL経由で行います）。

パターンB：単に読み出しがガードされている、または未ロックの場合

JTAGヒューズが切られていなければ、JTAG経由でそのまま「一括消去」をかければ上書き・再利用が可能です。

ツール到着後のチェックポイント

JTAGピンの導通確認（最優先）
ツールが届いたら、まずはマイコンのJTAGピン（56: TMS, 57: TCK, 58: TDI, 59: TDO）が、基板上のどこに引き出されているかをテスターで特定します。おそらく上部の「P2」パッドか、右下の10ピンヘッダのどこかに繋がっているはずです。
JTAGロック（ヒューズ）の生死確認
LaunchPadを繋いで、公式ツール（Code Composer StudioやMSP430 Flasher）からターゲット（MSP430F1471）を認識させてみます。
認識できた場合：メーカーがヒューズを切っていないため、そのまま日付パッチを当てたプログラムを一括消去して書き込めます。
「Unknown Device」やアクセス拒否になる場合：残念ながらJTAGヒューズが物理的に焼き切られています。その段階で初めて「CPUを剥がして別の変換基板に載せる」か、「本体（Z3805A等）のEPROM改造にシフトする」かの決断になります。

画像の基板（Pentar Inc. 260042-01）からの考察

提供いただいた画像を確認すると、書き込み・デバッグに利用できそうなポイントがいくつか存在します。

右上のヘッダパターンと、右下の10pinヘッダ（オス）
- R2, R3 の近くにある2列×5ピンのヘッダは、MSP430F1471のJTAG信号（TCK, TMS, TDI, TDO）や、BSL信号（UARTのTX/RX、RST、TEST）が引き出されている可能性が非常に高いです。
中央（GT-8031の下）の10ピンソケット
- ここもインターフェース用、もしくはデバッグ用のポートとしてパターンが用意されている可能性があります。

これらの既存10ピンヘッダを、PCなどと通信する「純粋なUARTポート」として利用（あるいは元に戻す）するためには、ハードウェアの電気特性（電圧レベル）の確認と、場合によっては回路のバイパス工作が必要になる可能性が高いです。

具体的なチェックポイントと必要な工作は以下の3点です。

1. 電圧レベル（TTLかRS-232Cか）の確認と工作

ここが一番の関門です。モトローラのGPSバイナリデータ出力ポートは、接続先（PCや産業用機器）に合わせて信号の電圧が変換されているケースが多いです。

TTLレベル（3.3V）の場合【工作不要】
- 信号線がマイコンから直接（または数Ωの抵抗を介して）10ピンに届いている場合です。数百円の市販の「USB-UART変換モジュール」をジャンパー線で繋ぐだけでPCと通信できます。
RS-232Cレベル（±5V〜±12V）の場合【バイパス工作が必要】
- 基板上のIC（U2など）がレベル変換IC（MAX232等）の場合、信号が反転・高電圧化されています。これを3.3VのUARTとして使いたい場合は、変換ICの手前（マイコンの足）から直接配線をハンダ付けして引き出すか、RS-232Cに対応したUSBシリアルケーブルを使用する必要があります。

2. GPSモジュール（GT-8031）との衝突対策

中央にある「GT-8031」用の10ピンソケット（または裏面への実装）の状況によって工作が変わります。

GPSモジュールが未実装・取り外してある場合【工作不要】
- マイコンのUARTピン（RXD/TXD）がフリーになっているため、そのまま外部と通信させても衝突しません。
GPSモジュールが載ったままの場合【パターンカット等の工作が必要】
- GPSモジュールが常にデータを送信しようとするため、外部からUART信号を入力するとデータが衝突して壊れるか通信できません。GPSモジュールを取り外すか、基板の信号線をカッター等で切断（パターンカット）する必要があります。

3. マイコン自体の書き換え工作（必須）

現在の中身が「GPSからデータを受け取って加工して出す」プログラムになっているため、単なるパススルーや独自のUARTとして動かすには、前回触れたJTAGまたはBSLによる「プログラムの強制全消去」と「新規プログラムの書き込み」の工作（配線）がどのみち必要になります。

右下の10ピンヘッダのどこかがマイコン（U1）の12番ピン（UTXD0）や13番ピン（URXD0）に直接繋がっているかを確認すると、レベル変換ICを通っているかどうかがすぐに判別できます。

“ソケット部分には　GT-8031H がハンダ付け配線されているので、撤去が必要になりそう。このボードは3.3Vロジック仕様。残念ながら　U1の#12,#13 ピンは、GNDに落とされていた。設計意図はガッカリする方向かもしれない。これを再利用するには、Furuno GT-8031H 初期化コードに日付変更が必要なので、書き換える方法を考えないといけない。

それは確かにガッカリする、非常に「攻めた」設計ですね……　マイコン（MSP430F1471）のハードウェアUARTである 12番ピン（UTXD0）と13番ピン（URXD0）が直接GNDに直結されているということは、このボードの設計意図として「ハードウェアUART機能は一切使わない（使わせない）」という強い意志を感じます。

設計意図としては、以下の2つの可能性が非常に高いです。

ソフトウェア（タイマー）シリアルでの実装
ハードウェアUARTではなく、他の汎用GPIOピン（P1〜P4など）をタイマーで制御し、ソフトウェア的にシリアル通信（Bit-Banging）を実装しているパターンです。GPSデータ（Motorola BIN）の速度（一般的に9600bpsなど）であれば、MSP430の性能でもソフトウェア制御で十分に間に合います。
SPI通信など別のインターフェースの使用
GT-8031H側とUARTではなくSPIや別の通信方法でデータをやり取りし、右下の10ピンへ変換して出力しているパターンです。

今後の「工作」と「再利用」の分かれ道

この状態から、目的である「単機能のUARTポートに戻す（または独自のプログラムを書き込む）」ための現実的なアプローチは以下のようになります。

選択肢A：このボードのマイコンをそのまま活かして書き換える（難易度：高）

JTAGまたはBSLで無理やり一括消去してプログラムを書き換えることは可能ですが、12/13番ピンがGNDにベタで落ちているため、ハードウェアUARTを使うには「マイコンの12番ピンと13番ピンの足をピンセット等で慎重に浮かせ、そこに直接極細のワイヤーをハンダ付けして引き出す」という精密な外科手術が必要になります。

選択肢B：GT-8031Hを撤去し、ピンを乗っ取る（難易度：中）

GT-8031Hがハンダ付けされている部分を吸い取り線などで完全に撤去します。もしマイコンがソフトウェアシリアルでGT-8031Hと通信していた場合、そのソケット（パターン）部分にマイコンの別のGPIOピンが繋がっています。そのピンを「自作プログラム側のUARTピン」としてソフトウェアシリアルで制御すれば、右下の10ピンヘッダへ信号を導通させられる可能性があります。

選択肢C：部品取りとして諦め、マイコンだけを剥がす（一番スッキリするかも）

ボードの回路を追いかけるのが不毛なレベルでガチガチに固められているため、ヒートガンや低融点ハンダ等で U1（MSP430F1471）自体を基板から完全に剥ぎ取る方法です。
剥ぎ取ったマイコンを市販のQFP48ピン変換基板（数百円）に載せ替えれば、GNDの縛りから解放され、前述の「LaunchPad流用」などで純粋な4線式JTAGプログラマを繋いで、100%自由に再利用できるようになります。

再利用の目的が「マイコンを別の用途に使う」のではなく、「GT-8031HのGPSロールオーバー（週数ロールオーバー）による日付のバグを修正するために、初期化コード内の日付設定を書き換えて、このGPSユニット延命（修理）する」ということですね。

それであれば、マイコンの足を浮かせるような外科手術は不要です。既存の回路パターンをそのまま活かしてプログラムを修正・上書きするのが正解です。

ハードウェアUART（12, 13番ピン）がGNDに落とされている理由は、設計者がGPS（GT-8031H）との通信に別のピンを使ったソフトウェアシリアル（タイマー制御によるシリアル通信）を実装しているためです。

今後の作業のロードマップと、必要な工作・手順を整理しました。

1. 接続方法の選定（JTAG か BSL か）

まずは、マイコン（MSP430F1471）のプログラムを書き換えるための通信経路を確保します。

第一候補：JTAG（右下の10ピンヘッダの調査）
右下の10ピンヘッダ（GPSデータ入出力ポート）に、JTAG信号（TCK, TMS, TDI, TDO, RST）が混ざって引き出されている可能性があります。もしここにJTAGが来ていれば、前述の「MSP430G2 LaunchPad」などを繋ぐだけで簡単に消去・書き込みができます。
第二候補：JTAG（U2周辺の空きパターン）
基板中央の U2 の上や、P2 と書かれた5つの四角いパッド（スルーホール）など、メーカーが製造時にテストや書き込みに使ったと思われるポイントがいくつかあります。特に P2 の5ピンは、JTAG（またはBSL）のピンアサインである可能性が非常に高いです。

2. 具体的な手順（延命修理への道）

JTAGピンの特定（テスターでの導通確認）
マイコン（U1）の以下のピンが、基板上のどこ（右下10ピン、またはP2など）に繋がっているかをテスターで探します。
- 5番ピン：TMS
- 6番ピン：TCK
- 7番ピン：TDI
- 8番ピン：TDO/TDI
- 58番ピン：RST/NMI（※型番によってピン番号が異なるため要確認、後述）
プログラムの「一括消去」と「新規書き込み」
メーカーがJTAGロック（ヒューズ切断）をしていない祈るような気持ちでJTAGプログラマを接続します。
- ロックされていない場合：ラッキーです。そのまま新しいプログラムを書き込めます。
- ロックされている場合：JTAGでのアクセスが拒否されるため、BSL（ブートストラップローダー）のピン（P1.1, P1.2など）を探してBSL経由で強制一括消去を行います。
ソフトウェアシリアルによる「新・初期化コード」の作成
元々の純正プログラムを読み出すことは（ロックの有無に関わらず）難しいため、「GT-8031Hに日付変更コマンドを送るためだけの、最小限の初期化用プログラム」を新しく自分で書きます。12, 13番ピンが使えないため、元の基板と同じピン（GT-8031HのRXに繋がっているマイコンのGPIOピン）を使って、9600bpsなどのソフトウェアシリアルで初期化コマンドを送信するコードを作成します。

モトローラの古いGPS受信機「Oncore」などを積んだ往年の名機（Z3801A、Z3805A等）は、2000年代以降のGPS週数ロールオーバー（WNRO）で日付が19.7年前に戻ってしまい、10MHzや1PPSの出力は維持できても、時刻表示や同期ステータスに異常が出る持病があります。

このマイコンを弄るよりも、GPSDO本体のファームウェア（EPROM）を直接改造するか、あるいはGPSモジュールとこの基板の間に別の安価なマイコン（ArduinoやPICなど）を割り込ませてコマンドを偽装（インターセプト）する方が、最終的なハードルは低いかもしれません。

もし、このMSP430F1471のJTAG特定に「最後の悪あがき」として挑戦される場合のために、64ピンパッケージ（LQFP-64）の正確なJTAGピン番号を整理しておきます。

MSP430F1471 (64ピン) のJTAG/電源ピン配置

テスターで右下の10ピンヘッダや、上部の P2 パッドへの導通を確認する際の参考にしてください。

56番ピン：TMS
57番ピン：TCK
58番ピン：TDI
59番ピン：TDO/TDI
54番ピン：RST/NMI（リセット）
62番ピン：AVCC / 1番ピン：DVCC（3.3V電源）
63番ピン：AVSS / 18番ピン：DVSS（GND）

次のステップへの展望

もしこの基板がJTAGロック等で「ダメだった」場合の、GPSDO（Z3805Aなど）側の対策アプローチは以下の2つが有名です。

本体側EPROM（ファームウェア）の書き換え
Z3805AなどのCPUボードに載っているUV-EPROM（27C512等）のデータをROMライターで吸い出し、日付やコマンド初期化コマンド、又は、日付計算のオフセット（1024週の倍数）を修正して焼き直す方法です。海外のタイムマニア（Time-Nuts）の間で解析されたパッチコードが共有されている場合があります。
GPSデータのインターセプト（シリアルデータ改変）
GT-8031Hから本体へ送られるNMEAやモトローラバイナリデータの「日付/週数」や初期化コマンドの部分だけを、中間に挟んだ小さなマイコン（ATmegaやRP2040など）でリアルタイムに数値を書き換えて本体に流す方法です。基板のパターンを1箇所カットするだけで済むため、一番安全な修理法としてよく使われます。

Chapter 3 .

2026-8

Z3805Aファームウェア　rev.D の、furuno GT-8031B 初期化コード探索

58503Aファームウェア参考
https://github.com/willhb/HP-58503A-Firmware

rev.Dファームウェアバックアップ
https://github.com/Bluestackson/Z3805A_rev.D_Samsung

---

実行機(Samsung版Z3805A(rev.D版/rev.C版))からのファームウェアチップから .bin 取り出し。-rev.D：Z3805-68003 (5NV00GP), -rev.C：Z3805A-68001 (6E901C3 3627)

(rev.D)

Bank_1　(id：27F010)

MSB　u14　8004_1M_u14_revD_00e44586_b.bin

LSB　u12　8002_1L_u12_revD_00f5a2e9_b.bin

Bank_2　(id：27F010)

MSB　u13　8003_2M_u13_revD_01079fb7_b.bin

LSB　u11　8001_2L_u11_revD_0114be42_b.bin

(AI(Gemini)生成powershell合成スクリプト)

$u14 = [System.IO.File]::ReadAllBytes("8004_1M_u14_revD_00e44586_b.bin")

$u12 = [System.IO.File]::ReadAllBytes("8002_1L_u12_revD_00f5a2e9_b.bin")

$u13 = [System.IO.File]::ReadAllBytes("8003_2M_u13_revD_01079fb7_b.bin")

$u11 = [System.IO.File]::ReadAllBytes("8001_2L_u11_revD_0114be42_b.bin")

$merged = New-Object byte[] 524288

# Bank 1 (U14 + U12) のインターリーブ処理

for ($i = 0; $i -lt 131072; $i++) {

$merged[$i*2] = $u14[$i] # MSB

$merged[$i*2+1] = $u12[$i] # LSB

}

# Bank 2 (U13 + U11) のインターリーブ処理

for ($i = 0; $i -lt 131072; $i++) {

$merged[262144 + $i*2] = $u13[$i] # MSB

$merged[262144 + $i*2+1] = $u11[$i] # LSB

}

[System.IO.File]::WriteAllBytes("Z3805A_D_comb_firmware.bin", $merged)

Write-Host "結合成功！ 'Z3805A_D_comb_firmware.bin' (512KB) を作成しました。" -ForegroundColor Green

---

バイナリエディタで下見した所、手元のRev.D, Rev.C, 及び、ネット上の　Rev.C(など複数)、全てが微妙に違う」困惑する結果に。Rev.Cは、概ね58503Aの物と同一(内部バージョンのみ相違？、Z3805A/Z3801A⇒58503)な様だ。Rev.D と Rev.C の違いは解る(GPSモジュールの違い/Furuno vs, OncoreVP)が、その他の違いは流布している情報以上に派生版が有る可能性を示しているのかもしれない(単に読み出しエラーのオチもありえるが)。また、Z3805A版の方がZ3801A版よりもコード部分が少し多く、逆にZ3805A版のメッセージ総数は減っている様だ。機種コードは「Z3801A」「Z3805A」「58503」の3種類があった。

rev.Dファーム内のGPSモジュール関連と見られるMODEL #記述には、 FURUNO GT-80, GT-77,GT-74, が有り、それらに対応しているらしい。rev.Cファーム内の相同位置のMODEL # は「空欄」の様だ。

Translate

2026/07/25

Z3805Aファームウェア関連/ MC68331/ Atmega AVR / MSP430 /Ghidra

🛠️ AVR（ATmega）のバイナリをリバースする最強のツール群

1. Ghidra（ギドラ） — 推奨・最高峰のデコンパイラ

2. Radare2 / Cutter — 高機能なオープンソース・ディスアセンブラ

3. avr-objdump — 確実なコマンドラインツール

🔍 このHEXソースから「何を」読み取るべきか？

🎯 最終的な「勝ちルート」の提案

1. 現状の回路図の構造分析（RS-232C直叩き）

2. 「フロントパネル用内部SPIバス」に対応させるための回路変更点

① MISO / MOSI / SCK ピンの割り当て変更

② レベルシフタ（電圧変換）の検討

③ ADM232（RS-232Cポート）の処遇

3. ファームウェア（移植・アドオン）の設計イメージ

💡 結論

最安の選択肢2選

方法1：MSP430G2 LaunchPadをプログラマとして流用する（最推奨・最安候補）

接続手順（4線式JTAG）

方法2：MSP-FET430UIF 互換品（中華製サードパーティ品）

注意点

ソフトウェア（書き込み・読み出しツール）

ロックされている場合の挙動と再利用方法

パターンA：JTAGヒューズが焼き切られている場合（量産品で多い）

パターンB：単に読み出しがガードされている、または未ロックの場合

ツール到着後のチェックポイント

画像の基板（Pentar Inc. 260042-01）からの考察

1. 電圧レベル（TTLかRS-232Cか）の確認と工作

2. GPSモジュール（GT-8031）との衝突対策

3. マイコン自体の書き換え工作（必須）

今後の「工作」と「再利用」の分かれ道

選択肢A：このボードのマイコンをそのまま活かして書き換える（難易度：高）

選択肢B：GT-8031Hを撤去し、ピンを乗っ取る（難易度：中）

選択肢C：部品取りとして諦め、マイコンだけを剥がす（一番スッキリするかも）

1. 接続方法の選定（JTAG か BSL か）

2. 具体的な手順（延命修理への道）

MSP430F1471 (64ピン) のJTAG/電源ピン配置

次のステップへの展望

0 件のコメント:

コメントを投稿