C++によるRXマイコンCANドライバー(その2)

MB (メールボックス)レジスタクラスを一応改修

CAN で、厄介なのは、MB レジスタ。
ここだけは、概念がかなり他と違う、一つのパーテーションが 16 バイトなので、通常のレジスタアクセスクラスではサポート出来ない。

そこで、専用の実装を考えた。
※本来は、直接アクセスしなくても、サポートクラスを定義して、丸ごとコピーすれば良い。
※技術的な興味から実装

  • 「DLC」はバイトアクセス
  • 「DATA」は 8 バイト分のアクセスを行うクラスを追加
  • 「TS」は 16 ビットアクセス
  • それ以外は 32 ビットアクセス
  • SID、EID をまとめて設定、読出し出来るように関数を追加「get_id()、set_id()」
  • 全体を初期化する関数を追加「clear()」
  • 全体をコピーする関数を追加「copy()」(他のメールボックスから丸ごとコピーする場合)
  • 「=」オペレーターを「private」に(代入禁止)
        //-----------------------------------------------------------------//
        /*!
            @brief  メールボックスレジスタ j ( MB[j] )( j = 0 ~ 31 )
        */
        //-----------------------------------------------------------------//
        struct mb_t {
            typedef rw32_index_t<base +  0> io0_;
            typedef rw8_index_t <base +  4 + 1> io1_;
            typedef rw16_index_t<base + 12 + 2> io3_;

            bits_rw_t<io0_, bitpos::B0,  18>  EID;
            bits_rw_t<io0_, bitpos::B18, 11>  SID;
            bit_rw_t <io0_, bitpos::B30>      RTR;
            bit_rw_t <io0_, bitpos::B31>      IDE;

            bits_rw_t<io1_, bitpos::B0, 4>    DLC;

            struct data_t {
                volatile uint8_t& operator [] (uint32_t n) {
                    return *reinterpret_cast<volatile uint8_t*>(io0_::address() + 6 + n);
                }
            };
            data_t  DATA;

            io3_    TS;

            void set_index(uint32_t j) {
                if(j < 32) {
                    io0_::index = j * 16;
                    io1_::index = j * 16;
                    io3_::index = j * 16;
                }
            }

            void clear(uint32_t d = 0) {
                auto a = io0_::address();
                wr32_(a,      d);
                wr32_(a +  4, d);
                wr32_(a +  8, d);
                wr32_(a + 12, d);
            }

            void copy(uint32_t idx) {
                wr32_(io0_::address() +  0, rd32_(base + idx * 16 +  0));
                wr32_(io0_::address() +  4, rd32_(base + idx * 16 +  4));
                wr32_(io0_::address() +  8, rd32_(base + idx * 16 +  8));
                wr32_(io0_::address() + 12, rd32_(base + idx * 16 + 12));
            }

            uint32_t get_id() {
                return SID() | (EID() << 11);
            }

            void set_id(uint32_t id) {
                SID = id & 0x7ff;
                EID = id >> 11;
            }

            mb_t& operator [] (uint32_t idx) {
                set_index(idx);
                return *this;
            }
        private:
            void operator = (const mb_t& t) {
            };
        };
        typedef mb_t MB_;
        static  MB_ MB;

これで、CAN 関係で、気になっていた部分は、納得いく範囲で、抽象的にアクセス出来るようになったと思う。

割り込み関係の整備と設計

本格的な上位層を実装する前に、割り込み関係の動作を確認しようと思う。

また、FIFO の機能をどうするか?
ハードウェアーで持ってる FIFO も、中途半端で微妙だよなぁー・・・
FIFO が4つくらいあっても、1パケット(フレーム)が100マイクロ秒前後なので、激しい通信がある場合は足りないと思う。
結局、ソフトで FIFO を作って、突発的に増えた場合の通信量を吸収するしかない。

経験的に、割り込み関数内でガッツリ実装するのは良くないと判っている。(それしか方法が無い場合もあるけど・・)
大抵、そんな事をしなくても、何とかなるし、割り込み内からコールバックを呼んでも、そこから出来る事は限られる。
※本当はコールバックも呼びたくない、もし、重い処理を実装されたら、終わってしまうから・・


RX64M の CAN では、割り込みは、SELB 選択型割り込みになっていて、4つの割り込みがある。
エラー割り込みは、BE0 グループ割り込みになっている。

    typedef can_seli_t<0x00090200, peripheral::CAN0,
        ICU::VECTOR_SELB::RXF0, ICU::VECTOR_SELB::TXF0,
        ICU::VECTOR_SELB::RXM0, ICU::VECTOR_SELB::TXM0, ICU::VECTOR_BE0::ERS0> CAN0;

RX66T では、エラー割り込みの「型」は同一だが、他は通常割り込みになっている。

    typedef can_norm_t<0x00090200, peripheral::CAN0,
        ICU::VECTOR::RXF0, ICU::VECTOR::TXF0,
        ICU::VECTOR::RXM0, ICU::VECTOR::TXM0, ICU::VECTOR_BE0::ERS0> CAN0;

icu_mgr クラスは、「割り込み型」により異なる関数が定義してあるので、C++ コンパイラが自動的に適切な関数を選ぶ、ドライバー側は「型」を意識する必要が無く、プログラムがシンプルになる。

  • #ifdef などで、CPU の違い毎に動作を別ける実装をしなくて済む。
  • 実際には、can のレジスタ定義では、CPU 毎の定義で「別けて」いるけど、その上位層では、感知しなくて済む。
  • つまり、この仕組みは、新規に CPU が追加されても、下位層でそのサポートを行えば、上位層のコードをケアする必要が無い。
 static ICU::VECTOR set_interrupt(ICU::VECTOR vec, utils::TASK task, uint8_t lvl) noexcept;
 static ICU::VECTOR set_interrupt(ICU::VECTOR_SELB sel, utils::TASK task, uint8_t lvl) noexcept;

※ちょっと不思議なのは、MIER メールボックス割り込み許可レジスタが、RESET 時不定になっている。
他にも不定になっているレジスタがいくつかある・・・


割り込み関係では、厄介な事がある、割り込みが起動した時、どのメールボックスによる要因なのかが判らない。
一応、調べる機構はあるが、送信と受信がシェアされているので、受信にしか使えない・・

送信は、同時に複数のフレームを送信しないので、それでも良いかもしれない・・

とりあえず、メールボックス 4 を送信専用にして、それを使って送信を行った。
問題無く、送信出来ていて、送信割り込みも機能する事を確認した。
※割り込みを使わない場合は物理的に難しいので、割り込みを使う事が前提となる。

CAN での受信は、色々と考える事が多い:

  • 固定 ID で来るデータを周期的に観るだけの場合。
  • 固定 ID で来るデータ全てに応答する場合。
  • どんな ID が来ているかを集計したい場合。(アナライザ的な機能)
  • ID 集計後に、無視する ID、観測する ID、応答する ID を決定する場合。
  • ID に個別の処理(コールバック)を設定する場合。

アプリケーションを作る場合、柔軟な構成にしたいので、上記の事を考えた設計をしたいが、RX マイコンの CAN 機能だけでは、難しい・・・

ID の範囲が「標準」のみなら、2048個なので、ルックアップするのは現実的だが、「拡張 ID」だと29ビットあるので、少し難しい。
STL の場合、「std::set]、「std::unorderd_set」を使えば、簡単に出来るが、内部で記憶割り当てを使うので、メモリの少ないマイコンの場合は使いたくないのも事実・・・
さてどうするか?

CAN 動作モードの切り替え(注意)

            // CAN オペレーションモードに移行
            uint8_t idfm = 0b10;  // 標準 ID モード、拡張 ID モード、ミックス
            uint8_t bom  = 0b00;  // ISO 11898-1 規格、バスオフ復帰モード
            CAN::CTLR = CAN::CTLR.CANM.b(0b00) | CAN::CTLR.SLPM.b(0) | CAN::CTLR.IDFM.b(idfm)
                | CAN::CTLR.BOM.b(bom);

            // CAN オペレーションモードに移行するまで待機
            while(CAN::STR.RSTST() != 0 || CAN::STR.HLTST() != 0) {
                sleep_();
            }

上記のように、CAN の動作モードを切り替えると、実際にモードが切り替わるまで遅延があるようだ。
オペレーションモードに移行した事を確認してから、次の動作を行う必要がある。
※そうしないと、制御レジスターの書き換えが失敗するなどの問題がある。
※一応、それらしい事が書いてあるが、レジスタの説明に書くべきだろうと思う。

MCTL レジスタの書き換えには注意

ハードウェアーマニュアルに書いてあるが、ビットを OFF にするには、色々と制約と順番などがある。
これは、注意を要する。

RX マイコンの CAN 関係の実装は、落とし穴が沢山あって、簡単では無いなぁーと感じる・・・
要は、あまり完成度が高く無いと感じる、だから RX24T で新しい CAN (RSCAN) になったのかもしれない。
そんな事を言っても仕方無いので、少しづつ機能を確認しつつ追加して、何とか完成させるしかない。

受信割り込みの確認

結局、SCI と同じように FIFO を使って受信動作を実装した。
なので、現状では、ID をマスクしたり、監視する機能は、全てソフトで行う必要がある。
パフォーマンスは犠牲になるが、当面はそれで良い、柔軟性が重要だ、パフォーマンスに問題が起こったら、マスクフィルタの設定などを追加すれば良い。

Start CAN sample for 'RX64M' 120[MHz]
CAN0: SPEED: 1000000 [bps], BRP: 3, TSEG1: 12, TSEG2: 7, SJW: 4
    RX Interrupt level: 1, TX Interrupt level: 1
CAN1: SPEED: 1000000 [bps], BRP: 3, TSEG1: 12, TSEG2: 7, SJW: 4
    RX Interrupt level: 1, TX Interrupt level: 1
# send 0x100 0 1 2 3 4 5
#
CAN1:
  ID: std 0x100 (256)
  DATA(6): 00 01 02 03 04 05
  TS: 51713

# ch 1
# send 0x200 10 20 30 99 0x7f
#
CAN0:
  ID: std 0x200 (512)
  DATA(5): 0A 14 1E 63 7F
  TS: 43785

# ch 0
# send 0x450 0
#
CAN1:
  ID: std 0x450 (1104)
  DATA(1): 00
  TS: 12821

#

※ CAN0、CAN1 の送信、受信の確認


今回はここまで。

ソースコードは、github RX/CAN_sample にある。

C++によるRXマイコンCANドライバー(その1)

RX マイコン内蔵 CAN ドライバーの実装

RXマイコンには、CAN を内蔵しているデバイスがある。

RX マイコンの CAN ペリフェラルは機能が豊富で、CAN 全体の構成も複雑なので、柔軟な「管理」を考えるとインターフェースが難しい・・

「送信」も、「受信」も、色々なバリエーションが考えられるので、どのような構成が「正解」なのか色々考える必要がある。
※機能が豊富過ぎると、どのような構成にすると、メリットが大きいのか考える必要があり、実験や調査に時間がかかりそうだ・・

とりあえず、どのような構成にするのがベストなのかイマイチ判らないのと、CAN についての知識が不足しているので、ハードウェアー機能を網羅するような対話形式のインターフェースを作り、実験しながら考えていく事にする。
※もう十年以上前に、仕事で、Autosar 準拠の機器で Linux ドライバーを実装した事があるが、その頃とは状況が異なっている・・
Autosar は上位の層で、自分が担当したのは、下位の層、ハードウェアーを直接操作して、CAN デバイスを操作するドライバーだった、Linux ドライバーは初めてで、それなりに苦労した事を覚えている・・・

  • CAN の通信 IC は Philips 製で、それが、PCI を介して接続されていたと思う。
  • この時は、単純な機能しか無かったので、ソフトで色々な機能をサポートしていた、ドライバーはシンプルなものだった。

RX24T は、初期のバージョンでは、CAN が無かったが、新しいバージョンでは、CAN が追加された、ただ、今までの CAN とは異なる構成になっている。
その為、同じドライバーでは、面倒を見れないと思える、これもどうするのが良いのか悩む要因の一つだ・・・
※RSCAN と呼ばれるペリフェラルに置き換わっている。
※RX66Tは、従来通りの CAN となっている。


別の問題として、CAN 関連レジスタにアクセスするテンプレートが一筋縄ではいかない構成なので、それもスマートに解決する必要がある。
※メールボックスレジスタ(32個ある)などにアクセスするテンプレートが思うように作れなかったので、中途な状態になっていた、最初は、それの改善方法を考える事から始める。

レジスタクラスを改造する

CAN には、「メールボックス」が32個あり、同等なアクセスを提供している。

しかし、レジスタ定義テンプレートクラスは、単独、1個のレジスタを想定して設計されている為、どのようにアクセスするか、悩んでいた。

テンプレートクラスの場合、アクセスするアドレスは固定となっている為、さらにインデックスを加えてアクセスするようには出来ていない。
そこで、「インデックス」付きアクセスを実現する為、最終的にレジスタメモリにアクセスするクラス「rw8_t」とは別クラスを追加した。

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  Read/Write 8 bits アクセス・テンプレート、インデックス付
        @param[in]  adr アドレス
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    template <address_type adr>
    struct rw8_index_t {
        typedef uint8_t value_type;

        static uint32_t index;

        //-----------------------------------------------------------------//
        /*!
            @brief アドレスの取得
            @return アドレス
        */
        //-----------------------------------------------------------------//
        static address_type address() noexcept { return adr + index; }

        //-----------------------------------------------------------------//
        /*!
            @brief  書き込み
            @param[in]  data    書き込み値
        */
        //-----------------------------------------------------------------//
        static void write(value_type data) noexcept {
            wr8_(adr + index, data);
        }

        //-----------------------------------------------------------------//
        /*!
            @brief 読み出し
            @return 読み出し値
        */
        //-----------------------------------------------------------------//
        static value_type read() noexcept {
            return rd8_(adr + index);
        }

...

    };

改造は簡単な物で、変数として「index」を追加して、事前に「index」を設定してからアクセスする事で、基底アドレス+index にアクセス出来る。
注意しなければならないのは、「adr」が同じテンプレートの場合、static で宣言されている「index」は共有されてしまうが、都合の良い事に、そのような場合が起こるのは「稀」だと思える。

メールボックス制御レジスタクラスは、元々、MCTL0 ~ MCTL31 が定義されている。
しかし、そのインスタンスでアクセスするのでは、冗長になる。
そこで、上記の「rw8_index_t」クラスを使い、index 分のアクセスを行えるように改修した。

さらに、「operator []」でアクセスできるように、「[]」をオーバーロードした。
operator の「戻り」は参照を使って、自分を戻しているので、インデックス付きアクセスが出来る。

    //-----------------------------------------------------------------//
    /*!
        @brief  メッセージ制御レジスタ j( MCTLj )( j = 0 ~ 31 )
        @param[in]  ofs オフセット
    */
    //-----------------------------------------------------------------//
    template <uint32_t ofs>
    struct mctl_t : public rw8_index_t<ofs> {
        typedef rw8_index_t<ofs> io_;
        using io_::operator =;
        using io_::operator ();
        using io_::operator |=;
        using io_::operator &=;

        void set_index(uint32_t j) { if(j < 32) { io_::index = j; } }

        bit_rw_t <io_, bitpos::B0>  SENTDATA;  // Send mode
        bit_rw_t <io_, bitpos::B0>  NEWDATA;   // Recv mode
        bit_rw_t <io_, bitpos::B1>  TRMACTIVE; // Send mode
        bit_rw_t <io_, bitpos::B1>  INVALDATA; // Recv mode
        bit_rw_t <io_, bitpos::B2>  TRMABT;    // Send mode
        bit_rw_t <io_, bitpos::B2>  TMSGLOST;  // Recv mode

        bit_rw_t <io_, bitpos::B4>  ONESHOT;

        bit_rw_t <io_, bitpos::B6>  RECREQ;
        bit_rw_t <io_, bitpos::B7>  TRMREQ;

        mctl_t& operator [] (uint32_t idx)
        {
            set_index(idx);
            return *this;
        }
    };
    typedef mctl_t<base + 0x0620> MCTL_;
    static  MCTL_ MCTL;

この改修で、以下のように自然にアクセスする事が出来るようになった。

    CAN::MCTL[idx] = CAN::MCTL.TRMREQ.b(1);

    CAN::MCTL[idx].TRMREQ = 1;

RX64M で送信、受信実験

以前に CAN バス・トランシーバー VP230 が乗った基板を購入した(中華製)このトランシーバーは 3.3V で動作するので、RX64M で動かすのには都合が良い、ターミネーター抵抗(120 オーム)も付いている。

ドライバーを作りこむのに、実験環境を作らなければならないが、送信側、受信側を別々にすると、二台のボードで実験する事になり、デバッグの手順が複雑になる。

RX64M は、CAN を3チャネル持っているので、CAN0、CAN1 を使って、相互に接続し、1台で、送信と受信が出来るような構成にした。

ボーレートの設定

RX マイコンの CAN はボーレートの設定が多少複雑だ、ドライバークラスは、複雑な設定を隠蔽して、簡単な設定を自動で行えるようにしなければメリットが薄い。
また、間違った設定を構造的に出来なくする事も重要だ。

CAN は、1ビットを送受信する過程で、色々な処理をするので、このような複雑なものになっているようだ。

RX マイコンの CAN では、1 ビットを「TQ」と呼ばれる値(ビットタイム)で分割し、これが、8~25になるようにボーレートを設定する。

TQ は、SS、TSEG1、TSEG2、を合計した物で、以下のような関係になっている。

SS = 1 Tq
TSEG1 = 4 Tq ~ 16 Tq
TSEG2 = 2 Tq ~ 8 Tq
SJW = 1 Tq ~ 4 Tq
TSEG1 > TSEG2 ≧ SJW

まず、「余り」が0になるような TQ 値を求める。
※そうしないと、割り切れない場合、微妙な通信速度になり、標準的な機器と通信出来ない。

    // 通信速度に対する、TQ 値 8 to 25 で適切な値を選ぶ
    // より大きい値で適合した値を選択
    uint32_t tq = 25;
    while(1) {
        if((get_can_clock_() % (static_cast<uint32_t>(speed) * tq)) == 0) {
            break;
        }
        tq--;
        if(tq < 8) {  // 割り切れない場合エラーとする
            format("(1)BRP divider indivisible...\n");
            return false;
        }
    }

-「get_canclock()」は、PCLKB(60MHz)となる。

  • 「speed」は、enum class で定義してあり、キャストして整数としている。
    enum class SPEED {
        _50K  =    50'000,  ///<  50 Kbps(標準ではない)
        _100K =   100'000,  ///< 100 Kbps(標準ではない)
        _125K =   125'000,  ///< 125 Kbps
        _250K =   250'000,  ///< 250 Kbps
        _500K =   500'000,  ///< 500 Kbps
        _750K =   750'000,  ///< 750 Kbps(標準ではない)
        _1M   = 1'000'000   ///< 1 Mbps
    };

次に、TSEG1、TSEG2 の配分を決める。

    uint32_t tseg1 = 16;
    uint32_t tseg2 = 8;
    uint32_t sjw = 1;  // とりあえず固定

    while(1) {
        if(tq == (1 + tseg1 + tseg2)) break;

        tseg1--;
        if(tq == (1 + tseg1 + tseg2)) break;
        else if(tseg1 < 4) {
            format("(3)TSEG1 value indivisible...\n");
            return false;
        }

        tseg1--;
        if(tq == (1 + tseg1 + tseg2)) break;
        else if(tseg1 < 4) {
            format("(4)TSEG1 value indivisible...\n");
            return false;
        }

        tseg2--;
        if(tq == (1 + tseg1 + tseg2)) break;
        else if(tseg2 < 2) {
            format("(5)TSEG2 value indivisible...\n");
            return false;
        }
    }

RX64M PCLKB=60MHz の場合、1Mbps に設定すると、以下のような値となる。

CAN0: SPEED: 1000000 [bps], BRP: 3, TSEG1: 12, TSEG2: 7

※「SJW」はこの変数に関する説明が無かったので、とりあえず「1」にしているが、出来るだけ大きい方が良いのかもしれない・・

メールボックスをどのように割り振るか?

RX マイコンの CAN は、メールボックスを中心とした構成になっている。
メールボックスは32個あり、どのように割り振るのか、ケースバイケースとなると思うが、「受信」動作はかなり厄介だ・・

  • 特定の ID だけ受信する(オペレーションモードにする前に決めなければならない)
  • 全ての ID を受信して、ソフトで振り分ける。
  • 上記二つの混合

「特定 ID」の受信では、初期化時に ID が決まっていなければならないが、ハードウェアーが自動で行うので、ソフトの負荷が小さくなる。
※その ID の数分、メールボックスを消費する。
「ソフト処理」では、どんな構成でも可能だが、その分、CPU 負荷が大きくなる。
CAN の場合、1つのパケットは 100 マイクロ秒くらいなので、120MHz の RX64M でも、流れるパケットによっては、処理がオーバーフローするかもしれない。

対話式インターフェース

CAN レジスタの説明を読んだ理解と、実際の動作が異なる場合があると思うので(CAN の理解不足などから)対話式インターフェースを実装した。

最初のステップとして、メールボックス「ありき」で対話式インターフェースを用意した。
※最終的には、メールボックスをアプリケーションユーザーに意識させるのは良くないと思うので実験用だけ。

Start CAN sample for 'RX64M' 120[MHz]
CAN0: SPEED: 1000000 [bps], BRP: 3, TSEG1: 12, TSEG2: 7
CAN1: SPEED: 1000000 [bps], BRP: 3, TSEG1: 12, TSEG2: 7
# help
    ch CH-no               set current CAN channel (CH-no: 0, 1)
    id number              set current ID number
    ext                    set ext-id mode
    std                    set std-id mode
    data MB-no [byte ...]  set frame data (MB-no: 0 to 31)
    list MB-no             list frame (MB-no: 0 to 31)
    reset MB-no            reset MB (MB-no: 0 to 31)
    send MB-no             send frame (MB-no: 0 to 31)
    recv MB-no             recv frame (MB-no: 0 to 31)
    stat MB-no             stat frame (MB-no: 0 to 31)
    state                  report CAN state
    help                   command list (this)

簡単な通信を行い、送信、受信動作を確認。

# ch 1
# id 0x754
# data 0 0
# recv 0
# stat 0
MCTL: 0x40 (0b01000000)
# ch 0
# data 1 0x75 0x46 0xac 0xf8 0x40
# send 1
# ch 1
# stat 0
MCTL: 0x41 (0b01000001)
# list 0
ID: std 0x754 (1876)
DATA(5): 75 46 AC F8 40
TS: 31995
#

メールボックスの扱い方がある程度分かったと思う・・・

今回はここまで、次は、マネージメントを内部で自動で行い、扱いやすくする方法や構造を考える。
また、割り込みも使う必要があるので、その辺りを中心に実装する。

WR250X のクラッチ修理?(その1)

クラッチが微妙にすべる・・

最近、でも無いけど、アクセルを大きく開けてパワーをリアにかけた時にガクガクする症状が出始めた。

始めは、エアーフィルターかプラグの不良なのかと思ったけど、どうやら、微妙に半クラになって滑っているようだった。

急加速をさないようにアクセルをゆっくり開けると、まぁ乗れるので、しばらくそのままにしていた。

引っ越しの際、サービスマニュアルと部品カタログがどこかに梱包され、少し探したが見つからないので、対応を難儀していた。

クラッチを交換

このままでは、加速ができず楽しくないので、とりあえず、クラッチの消耗だろうと思って交換する事にした。

クラッチプレートは全部で7枚、結構高い!

カバーを開ける際、ブレーキペダルが邪魔なので、リアのマスターシリンダーを外して、タイダウンで引っ張って、避けるようにした。

クラッチプレートの厚みを計測したが、まだ交換限界には達していない、しかし、折角新品を買ったので、交換した。

しかし、症状は直らず・・・

クラッチの遊び調整ネジ

WR250 には、クラッチの遊びを調整する機構が、クラッチ側にある事が判り、色々調整したが、症状は直らず・・・


クラッチの交換パーツは、セットになっているものがある。
こちらは、クラッチプレート、金属プレート、バネの全セットだが、当然のようにバカ高い・・・(2.5万くらい)
他は、消耗はあまり考えられないので、クラッチプレートだけ買ったが・・・

クラッチプレートでは無いとすると、クラッチスプリングくらいしか思いつかない・・

クラッチスプリングを交換

一応、クラッチスプリングの自由長を計測してみた、「40.6mm」交換限界は、「39.6mm」だが、他に考えられる部分も無いので、新品を購入。
新品の自由長は「41.0mm」たった0.4mmしか改善しないのかと思ったが、交換してみた。


クラッチワイヤーに注油

ついでに、クラッチワイヤーに注油した。
ワイヤーインジェクターを使って注油するのだが、これが、結構駄目だ・・・
隙間から漏れて、入っていかない・・・

そこで、昔からの方法、注油するのは、今回は「ベルハンマー」、この液体は粘性が少ないので、パーツの袋を利用して、漏斗を作り、隙間に先を入れておく。
そこに、ベルハンマーを注ぐと、重力で中に入っていく。


ワイヤーの動きは渋くはなかったが、スルスルになった。

前より良くなったが改善しない・・・

交換して、試乗したが、やはり滑る・・・

どうしたものか・・・

WR250 には、アフターパーツとして「強化クラッチスプリング」とゆーのがある、しかし、純正の2倍以上のお値段・・・

うーーんどうしたものか・・・

ネットを調べると、YZ125(モトクロスレーサー) とか WR250R 用のスプリングが、WR250X より「強化タイプ」である事が判り、今度はそれを注文した。
部品の到着待ち・・・

今回はここまで・・・

後、クラッチを抑えているアルミ部品も注文しておこうか・・・