コグノスケ

北海道から東京へ

オミクロン株が若干不穏な気配ですが、今年は久しぶりに北海道に帰省しました。でも次の帰省はいつになるやら……。COVID-19の動向次第ですね。

今までは帰省時期に飛行機に乗るとほぼ必ずインフルエンザをもらっていたのですが、今年は風邪一つ引きませんでした。道行く人が全員マスクを着ける、というのは本当に伝染病予防に効くんですね。マスクの効果を疑っていたわけではないですけど、思った以上の効果が出ていて驚いています。

Windows電卓

Windows電卓は浮動小数点数を扱えます。10^9999から10^-9999という非常に大きい数から、小さい数まで扱えます。

単精度浮動小数点数の最小値は10^-38（正規化数）もしくは10^-45程度、倍精度浮動小数点数でも最小値は10^-308（正規化数）もしくは10^-324（非正規化数）程度ですから、IEEE 754準拠の浮動小数点数型ではなさそうです。

Windows電卓で1 - 1.e-204 - 1を計算した結果

そのためか少し変わった桁落ちの挙動を示します。同じ程度の大きさの数同士の演算（例: 1.e-9999 + 1.e-9999 = 2.e-9999）であれば桁落ちしませんが、大きい数と小さい数を演算（例: 1 - 1.e-204 - 1 = -9.807971461541689e-149）すると激しく桁落ちします。

Windows電卓はオープンソース

実はWindows 10の電卓のソースコードはGitHubに公開されていて（GitHubのプロジェクトへのリンク）、誰でも見ることができます。MITライセンスで、2019年に公開されたそうです。Windowsの標準アプリがオープンソースになっているなんて、調べるまで知りませんでした。

利用方法は簡単でGit cloneしたあと、Visual Studioでsrcディレクトリの下にあるCalculator.slnを開くだけです。私のノートPCが非力なせいか、ビルドは非常に遅いですね……。

デバッグの設定

デバッグする際は、設定を「マネージド＋ネイティブ」にしておかないと、ネイティブコードを実行している部分のデバッグが全くできず、ブレークポイントなどが無視されるので注意が必要です。

桁落ちしている箇所

コードのありかとデバッグ方法がわかったところで、Windows電卓のコードを調べます。桁落ちはどこで発生しているでしょうか？

先ほど示した1 - 1.e-204 - 1という演算の場合、CalcManagerプロジェクトのRatPack/rat.cppのaddrat() 関数にてtrimit() を呼んでいる箇所で桁落ちが発生します。

//calculator/src/CalcManager/Ratpack/ratpak.h

typedef uint32_t MANTTYPE;

...

//-----------------------------------------------------------------------------
//
//  NUMBER type is a representation of a generic sized generic radix number
//
//-----------------------------------------------------------------------------

#pragma warning(push)
#pragma warning(disable : 4200) // nonstandard extension used : zero-sized array in struct/union
typedef struct _number
{
    int32_t sign;   // The sign of the mantissa, +1, or -1
    int32_t cdigit; // The number of digits, or what passes for digits in the
                    // radix being used.
    int32_t exp;    // The offset of digits from the radix point
                    // (decimal point in radix 10)
    MANTTYPE mant[];
    // This is actually allocated as a continuation of the
    // NUMBER structure.
} NUMBER, *PNUMBER, **PPNUMBER;
#pragma warning(pop)

//-----------------------------------------------------------------------------
//
//  RAT type is a representation radix  on 2 NUMBER types.
//  pp/pq, where pp and pq are pointers to integral NUMBER types.
//
//-----------------------------------------------------------------------------

typedef struct _rat
{
    PNUMBER pp;
    PNUMBER pq;
} RAT, *PRAT;


//calculator/src/CalcManager/Ratpack/rat.cpp

void addrat(_Inout_ PRAT* pa, _In_ PRAT b, int32_t precision)
{
    PNUMBER bot = nullptr;

    if (equnum((*pa)->pq, b->pq))
    {
        // Very special case, q's match.,
        // make sure signs are involved in the calculation
        // we have to do this since the optimization here is only
        // working with the top half of the rationals.
        (*pa)->pp->sign *= (*pa)->pq->sign;
        (*pa)->pq->sign = 1;
        b->pp->sign *= b->pq->sign;
        b->pq->sign = 1;
        addnum(&((*pa)->pp), b->pp, BASEX);
    }
    else
    {
        // Usual case q's aren't the same.
        //★bを変更できないので見づらい書き方になっているが、通分して加算している
        //★pa = pa->pp / pa->pq = A / B, b = b->pp / b->pq = C / Dとおくと
        DUPNUM(bot, (*pa)->pq);          //★bot = B
        mulnumx(&bot, b->pq);            //★bot = BD
        mulnumx(&((*pa)->pp), b->pq);    //★pa = AD / B
        mulnumx(&((*pa)->pq), b->pp);    //★pa = AD / BC
        addnum(&((*pa)->pp), (*pa)->pq, BASEX);    //★pa = (AD + BC) / BC
        destroynum((*pa)->pq);
        (*pa)->pq = bot;                 //★pa = (AD + BC) / BD
        trimit(pa, precision);    //★★この呼び出しで桁落ち★★

        // Get rid of negative zeros here.
        (*pa)->pp->sign *= (*pa)->pq->sign;
        (*pa)->pq->sign = 1;
    }

#ifdef ADDGCD
    gcdrat(pa);
#endif
}

Windows電卓は内部ではRAT型（struct rat型）で数値を保持しています。RATは分子ppと分母pqの2つのNUMBER型で構成された有理数を表す型です。

有理数の加算は小学校で習った通りで、通分して足します。大きな数＋小さな数で通分すると、非常に仮数部（構造体のmant、mantissa: 仮数の意味）が長くなってしまいます。例えば1 + 1.e-9999だと仮数部が9511要素もあるint32_tの配列になります。trimit() は一定以上の仮数を切り落とす役目を果たします。

加算の桁落ちを削除したWindows電卓で1 - 1.e-204 - 1を計算した結果

桁落ちを防止したければtrimit() の呼び出しを削れば良いです。しかし不思議なことに完全にtrimit() を削除するとWindows電卓が起動しなくなります。

桁落ちは必須

桁落ちを防止すると起動しなくなる理由は、Windows電卓はなぜか起動時にCCalcEngineのコンストラクタにて10^100を計算しているからです。

Windows電卓はx^yをx^y = exp(y * ln(x)) で求めているので、logの実装を見ましょう。ソースコードはexp.cppの _lograt() です。見たところ、十分に小さい項までテイラー展開を続けるアルゴリズムのようです。

//calculator/src/CalcManager/Ratpack/exp.cpp

void _lograt(PRAT* px, int32_t precision)
{
    CREATETAYLOR();

    createrat(thisterm);

    // sub one from x
    (*px)->pq->sign *= -1;
    addnum(&((*px)->pp), (*px)->pq, BASEX);
    (*px)->pq->sign *= -1;

    DUPRAT(pret, *px);
    DUPRAT(thisterm, *px);

    n2 = i32tonum(1L, BASEX);
    (*px)->pp->sign *= -1;

    do
    {
        NEXTTERM(*px, MULNUM(n2) INC(n2) DIVNUM(n2), precision);
        TRIMTOP(*px, precision);
    } while (!SMALL_ENOUGH_RAT(thisterm, precision));

    DESTROYTAYLOR();
}

桁落ちを一切なくすとループが終わらなくなってしまいます。変数thistermが0にならないとループを抜けないところを見ると、ループ条件のSMALL_ENOUGH_RATがバグっているような気もするんですが……、これ以上の深追いはやめておきます。

他にも √ の計算も非常に遅くなります。パフォーマンスと実用性のバランスからtrimit() は必須といえるでしょう。

高速道路の合流と、自動運転の微妙な関係、その解決策

結論から先に書いておくと、高速道路合流の速度問題が解決されていたので、そのメモです。

問題の説明の記事は、プロパイロット2.0の実現で浮かび上がった、高速道路の制限速度問題【岩貞るみこの人道車医】 - レスポンス（Response.jp）、などいろいろ出ているので、詳細はお任せするとして。

簡単に言うと、SAEレベル3以上、つまり機械が人の代わりに運転するタイプの自動運転では、法規上の最高速度に問題があります。普段の道路でも最高速度60km/hで走っている人はあまりいなくて、それも問題なんですけど、そこはさておき。当初、問題として取り上げられていたのが、高速道路への合流でした。

最高速度は道路交通法施行令という法律で定められていて、高速道路の加速車線の制限速度は一般道同様に60km/hでした。ご存じのとおり、高速道路の本線は100km/hなので、法律を守って運転すると、次のようになります。

• 加速車線60km/h
• 本線合流（★問題点1: 後ろの車と速度差がありすぎて危ない）
• 本線100km/hに加速（★問題点2: 急加速すぎる）

追突の危険性があるのと、本線で急加速せざるを得ない、ギクシャクした運転になってしまいます。

これは昔から存在していた法律上のおかしな点なんですが、人間が運転する場合はあえて法律（＝加速度車線の最高速度制限）を無視し、取り締まり側も厳密なことは言わず見逃す、というゆるい運用で問題を避けてきました。しかし自動運転車まで法律を無視する？それは本当に正しいのか？？と問題が再燃したわけです。

法律の方がおかしい

引き続き運用でごまかすのも辛いでしょうし、この問題はどうやって直すのかな？と思っていたんですが、どうやら法律の方を直したみたいです。

第四章の二　高速自動車国道等における自動車の交通方法等の特例

（最高速度）
第二十七条　最高速度のうち、自動車が高速自動車国道の本線車道又はこれに接する加速車線若しくは減速車線を通行する場合の最高速度は、次の各号に掲げる自動車の区分に従い、それぞれ当該各号に定めるとおりとする。
　一　次に掲げる自動車　百キロメートル毎時
　　　★★↑60km/hから100km/hに変わった★★
　　イ　大型自動車（三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。）のうち専ら人を運搬する構造のもの
　　ロ　中型自動車（三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。）のうち、専ら人を運搬する構造のもの又は車両総重量が八千キログラム未満、最大積載重量が五千キログラム未満及び乗車定員が十人以下のもの
　　ハ　準中型自動車（三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。）
　　ニ　普通自動車（三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。）
　　ホ　大型自動二輪車
　　ヘ　普通自動二輪車
　　二　前号イからヘまでに掲げる自動車以外の自動車　八十キロメートル毎時

自動運転の実現に向けて、継続して警察庁にて話し合いが持たれている（自動運転・自動走行 各種有識者会議等 - 警察庁）ので、今後も法律改正されていくことでしょう。

バッテリーさんさようなら

目次: 車

正月寒いなか放置しすぎたせいか車のバッテリーが死にました。テスターで電圧測ると2.3Vで室内灯すら点きません。またバッテリー交換コースかなー。

メモにあるだけでも2007年11月17日、2013年3月20日、2016年7月24日、2020年7月28日にバッテリー交換しています。次で5回目です。

車に乗る頻度が激減した理由は明確です。東京はあらゆる場所が「車で来るな！」とおっしゃるからです。それでも車で行くと

• 入れない
• すごい待つ
• めちゃ高い（駐車代が）

のどれかです。行く気がしませんのよ〜……。

デスクトップPCのATX電源を交換

デスクトップPCの部品のいくつかは昔のPCから引き継いで使っています。なかでもATX電源は交換を怠りがちですが、いざ壊れると起動しなくなるだけでなく、巻き添えでCPUやマザーボードまで故障する可能性もあって故障が怖い部品です。トラブルに遭う前に、予防的に交換します。

買ったのはCoolerMaster V650 GOLD V2（MPY-650V-AFBAG-JP, 650W）です。ヨドバシで14,000円くらいでした。ちらっと他店の値段を見たら11,000円くらいでした。ヨドバシはPCパーツがやや高いのかも？

今まではCoolerMaster SilentPro M600（RS-600-AMBA-D3, 600W）を使っていました。Core2 Quadマシンの時代（2009年〜）から使っていましたから、ほぼ付けっぱなしで13年使ったようです。CoolerMasterの電源は優秀ですね。これからも応援してます。

クリーンルームの火災

2020年10月の旭化成の半導体工場、火災事故調査報告書が出ていた（報告書へのリンク）ので読んでみました。人に犠牲がなかったのは良かったなと思いますが、報告内容はなかなか衝撃的でした。

チタン除去装置部材の燃焼試験

各状況から火元の可能性が高い、とされた装置に対し、燃焼試験を行ったそうです。仕様上、筐体カバーは「難燃性ポリプロピレン」のはずが、難燃剤が検出されず、可燃性でした。仕様がウソなんて、そんなのありかよ……？という項目でした。全装置に燃焼試験なんてできませんし、もはや何を信じたら良いんだろう。

延焼の原因推定（クリーンルーム部材）

クリーンルームを構成する多くのプラ部材（パーテーション、HEPAフィルタなど）、半導体原料（アルコールなど）が可燃性で、延焼の原因と推定されています。
「装置一台の炎上から全棟延焼なんて、そんな設計ダメ！」
と言うのは簡単ですが、塩ビすら燃えていたようで、何の材質使えば良かったんだろ？って思いました。

延焼の原因推定（防火エリア）

通常火災に耐えうる家屋設計だっただろうし、防火エリアも設置されていたにも関わらず、防火エリアが耐えきれず全棟延焼ってのが衝撃的でした。

通常の部屋と違い、クリーンルームは強力なダウンフローがあるし、天井と床下で繋がってる点は特殊です。クリーンルーム火災なんてレアな事例、積み上げもなさそうです。火災まで視野に入れると、設計めっちゃ難しそうですね……。

メモ: 技術系？の話はFacebookから転記しておくことにした。

ハチミツ入りの飴とボツリヌス菌

ハチミツ入りの飴を食べていたら、パッケージに
「はちみつを使用していますので1歳未満の乳児には食べさせないでください。」
と警告があることに気づきました。ハチミツを乳児に与えてはいけないのは、比較的有名な話（ハチミツによる乳児のボツリヌス症 - 消費者庁）だと思います。飴の形に加工されていてもやはりダメなのでしょうか？

乳児ボツリヌス症の原因はハチミツに含まれるボツリヌス菌の芽胞です。ボツリヌス菌「食品衛生の窓」 - 東京都福祉保健局によると、ボツリヌス菌の芽胞は熱に強く、殺菌には120℃4分間の加熱処理が必要です。

ハチミツ入りの飴の話に戻ると、

• ボツリヌス菌の芽胞は土壌に広く分布している（ハチミツにも入る可能性はある）
• 市販のハチミツは120℃4分間の加熱処理をしない
• 飴も120℃4分間の加熱処理をしない

なるほど、殺菌するタイミングがなさそうです……。

一般のご家庭でボツリヌス菌を倒せるか？

通常の鍋では、水の沸点（100℃）を超える加熱処理は不可能ですが、圧力鍋を使った場合はどうでしょう？我が家の圧力鍋、パール金属H-3551（メーカーサイトへのリンク）をみると、高圧側100kPa、低圧側60kPaとあります。

飽和水蒸気圧曲線（Wagnerの式を使用）

120℃ の飽和水蒸気圧は198.7kPaのため、大気圧＋100kPa = 約200kPaとすると、沸点は120℃まで達します。したがって圧力鍋のロックピンが上がり、圧力が規定値に達したときから、4分間以上加熱することで「一般のご家庭でもボツリヌス菌の芽胞は倒せる」と思われます。やるじゃないか、圧力鍋さん。

とはいえ圧力が必ず200kPaまで達する保証はありませんし、そもそも圧力鍋は殺菌装置ではないので、過信は禁物です。加熱後はちゃんと冷蔵して早めに食べましょう。

飴は……？

圧力鍋が凄いことはわかりましたけど、飴を圧力鍋で煮込むわけにはいきませんから、やっぱりハチミツ入りの飴を乳児にあげてはいけません。

圧力鍋の圧力設定の意味

我が家の圧力鍋は圧力切り替え式でゲージ圧（大気圧 = 0kPaとする記法）で「低圧60kPa」「高圧100kPa」となっています。なぜこの数字なんでしょう？

正直に言って設定の意味を理解していなかったんですが、昨日の日記で飽和水蒸気圧曲線（添付の写真、Wagnerの式から導出）を見ていて、設定の意味に気付きました。

飽和水蒸気圧曲線（Wagnerの式を使用）

グラフの圧力軸はゲージ圧ではなく、絶対圧です。沸点は大気圧を100kPaとして、ゲージ圧＋100kPaで概算しました。

• 通常: 100kPa → 沸点約100℃
• 低圧: 160kPa → 沸点約110℃（実際は113℃くらいか）
• 高圧: 200kPa → 沸点約120℃

これはもう見たままですね。10℃刻みです。とてもわかりやすいですね。ゲージ圧150〜160kPa（絶対圧250〜260kPa）の鍋もありますが、さらに上の約130℃設定（実際は127℃くらいか）を意味します。

調理器具ですから、温度は切り良く、覚えやすく、メーカーが作りやすい設定値を選んでいるはずです。当然と言えましょう。

全く理解していませんでした

こんなにわかりやすく考慮してくれているにも関わらず、当のユーザーたる俺ときたら……。全く設定の意味を理解せずに「常に高圧の一択」ですからね。メーカーの設計者は泣いてしまいますね。

メモ: 技術系の話はFacebookから転記しておくことにした。一部加筆。

SPIディスプレイを動かしてみる

目次: RISC-V

昨年、秋月で買って放置していた、怪しい中華製のSPI接続ディスプレイ（MSP2807）がやっと動きました。制御用のホストとしてSiFive HiFive1を使いました。OSはZephyrというRTOSを使っています。

HiFive1ではLinuxが動かないのも理由の一つではありますが、SPIの制御だけならZephyrがちょうど良い規模感でしょう。大掛かりなアプリを動かしたければ、別のハード（HiFive1はRAMがたった16KBしかない！）とLinuxを持ってきた方が良いでしょう。

SiFive HiFive1（黒い方）とSPI接続ディスプレイMSP2807（赤い方）

写真のとおり、画面が点灯して書き換えもできた（青と緑の縞模様を描いている）ので、リセット、コマンドとデータは送れているようです。ホスト → ディスプレイの接続は合っていると思われます。

しかし、ディスプレイ側から何か読み出そうとするとALL 0になり何も読めません。ホスト ← ディスプレイの接続をどこかで間違えているのかな……？？未だに理由がわからず直せないままです。

このディスプレイはILITEK ILI9341という液晶のドライバーICを使っています。ホストとの接続は何パターンか存在するのですが、

• ドライバーICとボードの端子の接続
• ドライバーICの設定ピン

が全く書いていないため、どのモードで動いているのか良くわかりません。イケてねえなあ。おそらく4-wireモード（SPI + コマンドかデータか示すGPIO 1つ）だと思われますが、確かめようがないです……。

メモ: 技術系の話はFacebookから転記しておくことにした。加筆。

バッテリーなんですぐ死んでしまうん？

正月、北海道から帰ってきて車の様子を見たら、完全にバッテリーが上がっていました。気づいたのはちょっと前（2022年1月10日の日記参照）くらいです。セルモーターは微塵も動かず、そもそもリモコンキーも効きません。ドアはカギで開けました。ドアを開けても室内灯すら点きませんね……。

今まで何度となくバッテリーをダメにしてきた悲しい経験から、これはバッテリー交換コースだと確信しました。またかよー。

JAFさーん

JAFに来てもらう間、暇だったのでバッテリーの電圧を測りました。電圧は2.16Vでした。これは乾電池でしたっけ？？正常な車のバッテリーは12V前後（セル電圧2V程度x6セル）であり、放電終止電圧は10V前後（セル電圧1.8V程度x6セル）です。2.16Vがいかに論外な状態であるか、おわかりいただけるかと思います。

バッテリーの電圧2.16V

バッテリーから流れる電流も測りました。電流はほぼ流れていないか、クランプメーターの検出限界以下と思われます。余談ですが、このクランプメーターはゼロ点が狂ってきたようで、何も繋がず、ゼロ点補正なしだと -0.31Aになってしまいます。直し方がわからない。

バッテリーから流れる電流はほぼゼロ

JAFさんにエンジンかけてもらった後に電流を測りました。やはり電流はほぼ流れておらず、充電されているように見えません。バッテリーが死んでいるのか、エンジン始動直後のせいか？どっちでしょうね？

エンジンを掛けた後もほぼ電流はゼロ

バッテリーの液量インジケーターは元々どうなっていたのかわからなくて、正常か異常か判別できませんでした。

バッテリーの液量インジケーター

仮に液量が正常でも、過放電でサルフェーション現象が発生して電極が死んでいる（＝充電ができない＝次止めたらエンジンが掛からない）でしょうから、素直にバッテリー交換に行きますか。

バッテリー交換

近所のイエローハットまで20分くらい走って、エンジンを切ってみたところ、電圧は11.8Vとなっていました。ん？充電されている？もしかしてバッテリーは生きてたのかな？

20分くらい走行後のバッテリー電圧11.8V

このまま帰ってまたバッテリーが上がったり、旅先で立ち往生されるのは困るため、潔くバッテリーを交換しました。当たり前ですが交換後は12.6Vと元気な電圧になっていました。

交換後のバッテリー電圧12.6V

バッテリーは今載っているものと全く同じものを買いました。特に変更する理由もないし。はー、こんなことで35,000円の出費は痛いな……。

エラー表示

メーターを見ると、エラーEr IUが出てました。なんじゃろ？これ？？

エラーIU

Facebookで会社の皆さまに教えていただいたところ、統合ユニットの通信エラーが発生したときに記録されるエラーとのこと。ずっと出続けていて気になりますけど、普通に走れて実害もなさそうなので、しばし放っておこうと思います。

OpenOCD on Rapberry PiでJTAGデバッグ

目次: OpenOCD

SiFiveのHiFive1というボード（SiFiveのサイトへのリンク）をデバッグするときは、HiFive1のオンボードUSB-JTAGを使うことが多いと思います。

非常に便利ですがUSB接続ゆえに近くにPCが必要です。PCを作業机の横に置けば何の問題もないんですけど、我が家の場合は諸事情でちょっと困った配置になっています。

• HiFive1は作業机の上（手の届く範囲）に置きたい
• PCは隣の部屋（ファイルサーバーの近く、有線ネットワークが繋がる範囲）に置きたい

PCを作業机の横に持ってくる手も考えましたが、悪あがきとしてRaspberry Pi 3でOpenOCDを実行してサーバー代わりにしてみました。結果から言うと、思っていたよりうまく動いてくれました。嬉しい、Raspberry Pi偉い。

各機器の接続

各機器の接続関係はこんな感じです。各ソフトに改造は不要です。GDBのTCP経由でデバッグできる機能と、OpenOCDのGDB serverとして振る舞う機能の合わせ技で実現できます。

（通常）
PCのGDB <-(TCP local接続)-> PCのOpenOCD <-(USB)-> HiFive1

（今回）
PCのGDB <-(TCP接続)-> Raspberry Pi 3のOpenOCD <-(USB)-> HiFive1

こんな変な使い方まで想定内とは驚きです。GDBもOpenOCDも良くできています。

Raspberry Pi 3側のログ（OpenOCD）

Raspberry Pi 3ではOpenOCDを実行します。

$ ./src/openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f ./tcl/board/sifive-hifive1-revb.cfg

Open On-Chip Debugger 0.11.0+dev-00551-gaad871805 (2022-01-16-22:30)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Info : J-Link OB-K22-SiFive compiled Nov 22 2019 12:57:38
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 4000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Info : datacount=1 progbufsize=16
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40101105
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : Found flash device 'issi is25lp032' (ID 0x0016609d)
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections


Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1606 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1523 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1599 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1610 ms). Workaround: increase "set remotetimeout" in GDB
Warn : Error writing to GDB socket. Dropping the connection.
Info : dropped 'gdb' connection
Info : accepting 'gdb' connection on tcp/3333
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1614 ms). Workaround: increase "set remotetimeout" in GDB

PC側からmonitor resetを実行すると「1,000ms以内に返事が来ない！タイムアウトしたぞ！」というWarningログが頻発します。HiFive1の反応が遅いのか、Raspberry Pi 3の判断が遅いのか、どちらかよくわかりません。両方かな……？

PC側のログ（GDB）

PCではGDBを実行します。例ではZephyrのバイナリを送っていますが、Zephyr以外でも手順は同じです。

$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf

GNU gdb (crosstool-NG 1.24.0.378_e011758) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=riscv64-zephyr-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/zephyr/zephyr.elf...

(gdb) target remote 192.168.1.106:3333
Remote debugging using 192.168.1.106:3333
0x00001004 in ?? ()

(gdb) monitor reset halt
JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1615 ms). Workaround: increase "set remotetimeout" in GDB

GDBもタイムアウトがどうのこうのと怒っています。特に異常動作はしないので放っておいても良いですけど、邪魔であればメッセージのおススメ通りにset remotetimeoutの値を伸ばすと良いでしょう。

Raspberry Pi 3の変なエラー

基本的には以上です動きました良かったね！で終わりなんですけど、Raspberry Pi 3のdmesgを見ていたら見慣れないエラーが出ていたのでメモしておきます。

[  253.885123] usb 1-1.5: new full-speed USB device number 6 using dwc_otg
[  254.021413] usb 1-1.5: New USB device found, idVendor=1366, idProduct=1051, bcdDevice= 1.00
[  254.021440] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  254.021475] usb 1-1.5: Product: J-Link
[  254.021490] usb 1-1.5: Manufacturer: SEGGER
[  254.021505] usb 1-1.5: SerialNumber: 000979016829
[  254.023795] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
[  254.027758] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
[  254.031278] usb-storage 1-1.5:1.5: USB Mass Storage device detected
[  254.032081] scsi host0: usb-storage 1-1.5:1.5
[  254.875197] Under-voltage detected! (0x00050005)    ★★★★これと★★★★
[  255.037642] scsi 0:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
[  255.038948] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  255.043115] sd 0:0:0:0: [sda] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
[  255.052887] sd 0:0:0:0: [sda] Write Protect is off
[  255.052914] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
[  255.055179] sd 0:0:0:0: [sda] No Caching mode page found
[  255.055202] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  255.148361]  sda:
[  255.166356] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  259.035120] Voltage normalised (0x00000000)    ★★★★これ★★★★

このエラーはRaspberry Pi 3とHiFive1のUSB端子を接続したときに出現します（私の環境だと接続のたびに必ず発生）。電力供給ラインであるUSBのVBus端子電圧が下がっているという意味ですかねえ……？可能性としてはHiFive1が起動時だけ一気に大電力を消費することが考えられますが、深追いしておらず真相はわかりません。

HiFive1のJTAG周りについて

目次: OpenOCD

HiFive1のJTAGを使う際はJ-Linkの設定（tcl/interface/jlink.cfg）を使えばOKです。しかしSEGGER J-LinkのJTAG箱が見当たらないのに、なぜこの設定で動くのか若干気になりました。調べたら納得だったのでメモしておきます。

回路図を見るとマイコンでUSB-JTAG変換を実現しています。USB端子はNXP MK22FN128VLH10（MK22FN128VLH10 Product Information - NXP）に接続されており、このICからJTAGの信号（TDIなど）が出ています。JTAGの信号線はSiFive FE310に接続されています。

なぜ突然NXPのマイコンICが出てくるのか？J-Linkはどこから来た？？と思いきや、実はこれSEGGER J-LinkのオンチップJTAG、J-Link-OBというシリーズの1つで使われているマイコンです（参考: J-Link OB Debug Probe - SEGGER）。SEGGER J-Linkは専用のICがあるわけではなく、NXPやSTのマイコンで実現しているんですね、なるほど。

カタログ上はCortex-M/Cortex-A用となっていますが、これはSEGGER独自の機能が使えるか使えないかを表しているのでしょう。JTAGは4つの信号線（TMS, TCK, TDI, TDO）でJTAGのプロトコルを理解するデバイスが相手であれば良くて、CPUの種類は特に気にしないはず……。