最近STM32でCANとか使っているのですが、時々送信に失敗してしまうという問題がありました。

たまになので問題ないのですが、気になったので調べてみるとSTMicroが用意しているSTM32F10x standard peripheral libraryのバグでした。バージョンは04/16/2010 のV3.3.0と古いやつですが。

具体的に言うと、現在送信しようとしているメッセージの状態を確認する関数

CAN_TransmitStatus にあります。

ここでは CANxのTSRレジスタのTSS_RQCP0、TSR_TXOK0、およびTSR_TME0ビットの値を見て、

CANTXPENDING(送信中)、CANTXFAILED(失敗)、CANTXOK(成功)を返しています。

が、こんな風にレジスタにアクセスするようなコードになってます。

switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((CANx->TSR & TSR_RQCP0) << 2);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK0) >> 0);
      state |= (uint8_t)((CANx->TSR & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((CANx->TSR & TSR_RQCP1) >> 6);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK1) >> 8);
      state |= (uint8_t)((CANx->TSR & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((CANx->TSR & TSR_RQCP2) >> 14);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK2) >> 16);
      state |= (uint8_t)((CANx->TSR & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

これでは、レジスタに3回アクセスしてしまっており、アクセスとアクセスの間でレジスタの値が変わってしまうと変なstatusになってしまいます。その結果 default で CANTXFAILED がセットされてしまうというのが送信失敗の原因です(実際にはこの瞬間に成功しているが、失敗したと判断してしまう)。

最も修正量の少ない解決策は簡単で、CANx->TSRの値を一旦変数に入れてやればいいのです。

uint32_t _tsr =  CANx->TSR;
switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((_tsr & TSR_RQCP0) << 2);
      state |= (uint8_t)((_tsr & TSR_TXOK0) >> 0);
      state |= (uint8_t)((_tsr & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((_tsr & TSR_RQCP1) >> 6);
      state |= (uint8_t)((_tsr & TSR_TXOK1) >> 8);
      state |= (uint8_t)((_tsr & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((_tsr & TSR_RQCP2) >> 14);
      state |= (uint8_t)((_tsr & TSR_TXOK2) >> 16);
      state |= (uint8_t)((_tsr & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

こんな風に。

で、最新のV3.5.0ではちゃんと修正されてました。

  switch (TransmitMailbox)
  {
    case (CAN_TXMAILBOX_0):
      state =   CANx->TSR &  (CAN_TSR_RQCP0 | CAN_TSR_TXOK0 | CAN_TSR_TME0);
      break;
    case (CAN_TXMAILBOX_1):
      state =   CANx->TSR &  (CAN_TSR_RQCP1 | CAN_TSR_TXOK1 | CAN_TSR_TME1);
      break;
    case (CAN_TXMAILBOX_2):
      state =   CANx->TSR &  (CAN_TSR_RQCP2 | CAN_TSR_TXOK2 | CAN_TSR_TME2);
      break;
    default:
      state = CAN_TxStatus_Failed;
      break;
  }

一度でアクセスするようになってます。でも返値変わってて、最新版に置き換えるのは大変そう…

進捗状況が公開できるものは今日プロジェクトのブログで更新したライントレーサーですが、写真を撮ったのでこっちにも公開します。

合同ロボコン用ロボットの骨格

詳しくは大阪大学Robohanの今日の投稿をご覧下さい。

STM32を使う予定でいるのでそっちの研究にも役立つかと思っています。

CNCを購入してから基板がつくれたりかなり便利になってます。

近々別に開発しているシステムも完成するのでそちらも公開できると思います。(こっちは制御・回路中心です)

NHKロボコン2010「出場要項」

と、Robohanのブログに書きました。

あとは個人的な話を。
STM32を入手したので明日の昼休みは図書館で今まで構築してきた開発環境の動作確認ができそうです。

アルバに開発を頼まれているいくつかのセンサー情報をSDカードへの記録するロガーの方もすこしずつ実験をしていかないとなぁと。

こっちは以前に試作したGPSロガーを元にすればそんなに大変ではないと予想しています。

では。

そこで、最近無性にSTM32が使いたかったのでとりあえず開発環境でもを用意してみようかということで進めていきます。

今回は以下の二段構えになっています。

• コンパイル環境の構築
• 書き込み環境の構築

まず、前者についてはCortex M3開発環境 on Mac OS Xというページを参考にしました。

• ARM用gccのインストール (Targetがarm-eabiのgcc)

ARM用のgccはSHやH8の時とはちがい、コンパイル済みのdevkitARMを利用します。このページからdevkitARMのOSXバージョンの最新版をダウンロードし、インストールします。

こいつはインストーラが無いので解凍してできたdevkitARMディレクトリを /usr/local/ ディレクトリにコピーしておきます。

そして、PATHを通すために~/.bash_profileファイルに(無ければ新規作成)

export PATH=$PATH:/usr/local/devkitARM/bin

日本時間で15時20分に発注メールをOLIMEXに送信したら、19時40分にPDFの注文書が送られてきました。

たぶん今までで最速！。こんなに早いとうれしいなぁ

3パックに包まれてやってきました。

開封し、種類別に分けるとこんな感じ。

中身は

DCC関係

• シグナルデコーダ
• ポイントデコーダ
• 赤外線トランスポンダ受信ボード
• ファンクションデコーダ
• モーター車用デコーダ
• LocoUSB rev.2

その他

• XBee USB変換基板
• microSD変換基板
• JTAGデバッガ
• I2C接続モータードライバ

他には後輩が発注したものです。

製作結果は研究ノートに掲載予定です。

9月号にはグラフィックLCDなどが載るボードが付属するのでそっちも買わないと…