STM32WL MBMUX
メールボックス･マルチプレクサ
レビジョン 1.0

STM32WLのメールボックス･マルチプレクサのプレゼンテーショ
ンへようこそ1

範囲• MBMUX の目的は 2 つの STM32WL コアであるCM4（CPU1）と CM0PLUS（CPU2）間の通信の容易化• MBMUX は、デュアル･コア動作の STM32WL デバイス上で実行する Sub-GHz のサ
ンプルとアプリケーションのニーズに特化したソフトウェア･フレームワーク• すべての種類のデバイスとアプリケーションで一般的なミドルウェアは対象外• MBMUX の設計は簡潔性と柔軟性とのトレードオフからの帰結

2

MBMUX の目的は 2 つの STM32WL コアであるCM4（CPU1）と CM0PLUS（CPU2）間の通信を容易にすることにあります。
MBMUX は、デュアル･コア動作の STM32WL デバイス上で実行する SubGHz のサンプルとアプリケーションのニーズに特化したソフトウェア･フレームワークです。
すべての種類のデバイスとアプリケーションで一般的なミドルウェアは対象外です。
MBMUX の設計は簡潔性と柔軟性とのトレードオフから得られています。

2

シングル･コアとデュアル･コア• シングル･コアとデュアル･コアの相違点• 2 つの独立したバイナリ• →共通のリンカなし• 通信を可能にするように 2 つのコア間のインタフェースを構築（プロセッサ間通信コントローラ（IPCC）と共有メモリ（SH-mem））• コア間で共通の言語を確立• 構造体型の共通化、交換する構造体へのポインタなど• 影響• 2 つのファームウェア（CM4 と CM0PLUS）に相互の互換性が必要• CM0PLUS バイナリの機能（サポート対象機能）を CM4 で認識することが必要• 異なるコンパイル･オプションを持つ同じリリース･バージョンのビルドが可能

3

デュアル･コア環境にこのようなフレームワークが必要な理由は何でしょうか。それは、2 つのコアが全面的に独立していて、2 つのバイナリで同じリンカ･ファイルを共有していないからです（FOUTA プロジェクトでの例外あり）。
MBMUX は IPCC と共有メモリを介して通信チャネルを提供
し、2 つのコア間で情報を交換できるようにする共通言語を確立します。
これは、2 つのコアのファームウェア･バージョンに相互の互換性が必要であることを意味します。2 つのコアのそれぞれには、相手コアでどの機能がサポートされているかを知るための手段が必要です（Sigfox ではなく、LoRa など）。

3

STM32WL の内蔵ソフトウェア･アーキテクチャ
ドライバ

LoRa アプリ
PingPong

LoRa アプリ
ATSlave

LoRa アプリ
EndNodeSigfox アプリ

ユーティリティ
タイマ･サーバ
シーケンサ
低消費電力マネージャ
トレース/キュー
Systime
NVM

CM4
非セキュア

ミドルウェアミドルウェア
RTOS

BSP

Flash
RAM_

HAL
LL

CMSIS

I2C
（環境センサ）UART/LPUART

タイマ

AES
PKA

Macac

LMHandler+FW 管理/同期/フラグ/
マルチキャスト

RNG
無線/プロトコル
テスト･ライブラリ

RTC
LPTIM
GPIO（無線ドライバ）

LoRaMac無線ドライバSigfox ライブラリKMS
NVM などTRxIP
4

このスライドは、シングル･コア･プロジェクトの一般的なアー
キテクチャを示しています。アプリケーション（LoRaWAN ま
たは Sigfox）は、同じコアに用意されているミドルウェアと無線ドライバを使用します。

4

ミドルウェア

STM32WL の内蔵ソフトウェア･アーキテクチャ

デュアル･コア

ドライバ

LoRa アプリ
PingPong

LoRa アプリ
ATSlave

LoRa アプリ
EndNode

LoRa アプリ
FUOTA

Sigfox アプリ

タイマ･サーバ
シーケンサ
低消費電力マネージャ
トレース/キュー
Systime
NVM

CM4
非セキュア

特権

LMHandler
Mb

無線 Mb

システム Mb

Sigfox Mb

ユーティリティSKMS Mb

ミドルウェア

BSP

Flash
RAM_

HAL
LL

CMSIS

I2C
（環境センサ）UART/LPUART

タイマ

RTOS

HSEM
IPCC

LMHandler
Mb

CM0
セキュア

無線 Mb

Macac

システム Mb

LMHandler+FW 管理/同期/フラグ/
マルチキャスト

Sigfox Mb

無線/プロトコル
テスト･ライブラリ

SKMS Mb

ユーティリティ
タイマ･サーバ
シーケンサ
低消費電力マネージャ
Systime

特権

LoRaMac

Sigfox ライブラリ

AES
BSP
（無線ドラ
イバなど）

PKA
RNG
RTC

HAL
LL

LPTIM
GPIO（無線ドライバ）

SKMS
NVM など

CMSIS

SBSFU

無線ドライバTRxIP

5

このスライドは、デュアル･コア･プロジェクトのより複雑なアー
キテクチャを示しています。この例では、実用的な部分をCM4 コアに実装し、各種スタックと無線ドライバを
CM0PLUS コアで実行しています。
このモデルの目的は、CM0PLUS コアでのスタックの動作に影響することなく、CM4 コア上のアプリケーションを変更できるようにすることです。
灰色のボックス（無線 Mb、Sigfox Mb など）は、MBMUX フ
レームワークを構成する各モジュールです。これらのモジュールは、アプリケーションとスタックまたは無線ドライバとの相互作用を実現します。

5

MBMUX の意味• MBMUXは、IPCC チャネルの IRQ を共有メモリ･バッファに結び付け、2 つの CPU の間でメッセージを交換できるようにするメールボックス（MailBox）レイヤ• MBMUX は、2x6 の IPCC チャネルに各種機能（LoRa、Sigfox、無線、Mwbus、KMS（SKS）、トレースなど）をマッピングできるマルチプレクサとしても機能共有 SRAM
データ･パス

MBMUX

CPU1
機能

IPCC

CPU2
機能

データ通知

6

MBMUX は、メールボックス（Mailbox）とマルチプレクサ（Multiplexer）の略です。
メールボックスは、2 つの物理的手段である IPCC と共有メ
モリを介して 2 つのコア間の通信を提供します。
マルチプレクサは、各機能と IPCC チャネル間の動的マッピ
ングを提供します。
次のスライドでは、IPCC、メモリ･バッファ、チャネル、機能などをもう少し詳しく説明します。

6

IPCC
• IPCC： プロセッサ間通信コントローラ（Inter-Processor communication controller）• 多くの STM32 ファミリ（STM32MP1、STM32WB、STM32WL など）にこの IP を用意• 次の 2 つのチャネル･グループを扱うように IPCC を設計• IPCC_1TO2： CPU1 の Tx チャネルと CPU2 の Rx チャネルに対応• IPCC_2TO1： CPU2 の Tx チャネルと CPU1 の Rx チャネルに対応• チャネル数はチップセットに応じて固定（STM32MP1 では 2x2，STM32WB では 2x6、STM32WL では 2x6）
• バッファとメモリは IPCC の対象外
• STM32WL では、CPU1 は CM4、CPU2 は CM0PLUS

7

IPCC（プロセッサ間通信コントローラ）から説明を始めます。
この IP は、STM32MP1、STM32WB、STM32WL をはじめとする多数の STM32 ファミリに用意されています。
デバイス･ファミリに応じて、複数の通信チャネルを基本としています（STM32MP1 では 2x2、STM32WB では 2x6、STM32WL では 2x6）。
IPCC ではバッファもメモリも扱いませんが、この両方に対する割込みをトリガします。

7

共有メモリ• v1.0.0 リリースでの EndNode 向けリンカ･ファイルの例
0x0803FFFF
CM0PLUS0x08020000
ROM

SRAM2_PRIV

0x2000FFFF
0x2000C000

SRAM2_SH2

0x2000BFFF
0x2000B000
0x2000AFFF
0x20008000

SRAM2_SH1

0x0801FFFF

機能情報テーブル

メールボックス･テーブル

0x20007FFF
SRAM1

CM4

0x08000000

0x20000000
8

情報を交換するには共有メモリが必要です。
一般的に、ST の納品に付属する SubGHz アプリケーションでは、
リンカ･ファイルが次のようになっています。
主に CM4 で使用する SRAM1：C スタック、ヒープ、cm4 グロー
バル変数などCM0PLUS で使用する SRAM2_PRIV（セキュリティが有効な場
合に保護されます）：C スタック、ヒープ、CM4 のグローバル変数、
セキュア･コードなど
SubGHz のリンカ･ファイルでは、STANDBY モードで保持する必要があるプロパティが存在することから、MBMUX の共有メモリがSRAM2 に置かれます。また、アドレス 0x20008000 は、
IPCCDBA オプション･バイトのデフォルト値と一致しています（詳細は後ほど説明します）。
共有メモリは SH1 および SH2 の 2 つで構成されます。
SRAM2_SH1 は、CM4 で割り当てられる項目の共有メモリです（メールボックス･テーブルなど）。このテーブルは、Cmd/Resp とNotif/Ack の両方向での情報交換に使用します。
SRAM2_SH2 は、CM0PLUS で割り当てられる項目の共有メモリです（機能情報テーブルなど）。このテーブルは、CM0PLUS の機
能を公開するために初期化でのみ使用します。

8

MUX：機能とチャネルとの関係機能（CPU で用意される、アプリ、サービス、ファームウェアのエンティ
ティ）
システム
Radio_SubGh

チャネル
MB
MUX
CmdResp_0
CmdResp_1

SigfoxCmdResp_2
CmdResp_3

KMS

CmdResp_4

トレース
LoRaWAN
サンプル ID：
LORAMAC_INITIALIZATION_ID
LORAMAC_START_ID
LORAMAC_STOP_ID
LORAMAC_MIB_GET_REQUEST_CONFIRM_ID
LORAMAC_MIB_SET_REQUEST_CONFIRM_ID
LORAMAC_MLME_REQUEST_ID
LORAMAC_MCPS_REQUEST_ID

CmdResp_5
NotifAck_0
NotifAck_1
NotifAck_2
NotifAck_3
NotifAck_4
NotifAck_5
9

概念説明の最後は、機能とチャネルとの関係です。
チャネルは、IPCC のハードウェアで用意される物理エンティ
ティです。
機能は、IPCC の各ハードウェア･チャネルにマッピングされるモジュールやエンティティです（LoRa、Sigfox、KMS、ト
レースなど）。
このマッピングは動的で、ソフトウェアの登録を通じで実行されます。マッピングを扱うモジュールはマルチプレクサ（MUX）です。
この図の右側には、6 つのコマンド/レスポンス･チャネルと 6
つの通知/確認応答チャネルを示しています。これらのチャネ
ルは、左側の各機能にマッピングできます。

9ファームウェア･ディクショナリ：Cmd、Resp、Notif、Ack• Cmd： IPCCのTxチャネル上でCM4からCM0PLUSへ送信• Resp： IPCCのTxチャネル上でCM0PLUSからCM4へ送信• Notif： IPCCのRxチャネル上でCM0PLUSからCM4へ送信

CM4
アプリケーション

CM0PLUS
アプリケーション

Cmd
Resp

Notif
Ack

• Ack： IPCCのRxチャネル上でCM4からCM0PLUSへ送信

Cmd/Resp

MBMUX
IPCC

Notif/Ack
10

IPCC のチャネルは、Tx と Rx のペアを複数使用して編成されています。MBMUX では、Tx チャネルをコマンド/レスポン
ス、Rx チャネルを通知/確認応答に使用しています。

10

機能リスト• システム：システムに関連するすべての通信をサポート• システムの初期化• IPCC チャネルと機能との関係の登録• 機能の属性/能力に関する情報の交換• RTC 通知などの優先度が高い動作向けに RTC 追加システム･チャネルを追加可能• トレース：CM0PLUS では、IPCC を通じて CM4 に送信するログを循環キューに配置。CM4 では、
従来の CM4 ログの場合と同じ方法（USART など）でこの情報を出力して処理• KMS/SKS： セキュア･キー･ストレージ• 無線ドライバ：SubGHz 無線と直接のインタフェースが可能• LoRaWANスタック： このチャネルを使用して、LoRaWANコマンド（初期化やリクエストなど）およびLoRaWANプロトコルに関連するイベント（レスポンスや指示）すべてとのインタフェースを構成• Sigfoxスタック： このチャネルを使用して、Sigfoxコマンド（初期化やリクエストなど）およびSigfox
プロトコルに関連するイベント（レスポンスや指示）のすべてとのインタフェースを構成• これら以外の機能を追加可能

11

ここでは、現在利用可能な機能について簡単に説明します。
システムは実際には機能ではなく、メールボックスのコアを扱い、必ずチャネル 0 を使用します。
CM0PLUS のコアで何らかのデータをログに記録する必要がある場合にトレースを使用します。このログは、メールボッ
クスを介して CM4 に送信されます。
LoRaWAN、Sigfox、KMS などの他の機能については、他のプレゼンテーションで取り上げます。
Wmbus など、ここにない機能を追加できます。追加した機能
は動的に各チャネルにマッピングされます。

11

チャネルでの機能の登録• MBMUX は、利用できる IPCC チャネルの数よりも "アプリケーション機能" の数が多い状況を考慮して実装済み。したがって、マッピングはハードコードではない。
• MBMUX では、各 "機能" を 1 つ以上のチャネルに関連付け。どの機能がメッセージを送信するかが上位レイヤから MBMUX に通知され、MBMUX は関連するチャネルを透過的に使用。
• 各機能は、登録とキャンセルによってチャネルを予約または解放。MBMUX は、使用できるチャネルに応じてチャネルを決定。
• MBMUX の "システム" チェック：• 登録を要求している機能を登録できるチャネルがまだ十分にあるかどうか• 登録を要求している機能が 2 回登録されていないかどうか• 登録を要求している機能がリモート CPU（CM0PLUS）に存在するかどうか• IPCC の Tx チャネルと Rx チャネルは方向が独立しているので、ある 1 つの方向には機能がチャネルを必要としないことが考えられるが、その他の方向に 2 つのチャネルを必要とすることもあり得る• その例として Tx 方向を使用しないトレース機能がある。
12

MBMUX は、利用できる IPCC チャネルの数よりも "アプリ
ケーション機能" の数が多い状況を考慮して実装されています。したがって、マッピングはハードコードではありません。
MBMUX では、各 "機能" を 1 つ以上のチャネルに関連付けます。どの機能がメッセージを送信するかが上位レイヤから
MBMUX に通知され、MBMUX は関連するチャネルを透過的に使用します。
各機能は、登録とキャンセルによってチャネルを予約または
解放し、MBMUX は、使用できるチャネルに応じてチャネルを決定します。

12

MBMUX：機能のマッピング• 登録とキャンセルによって自動的に機能をチャネルに割当て
機能

IPCC の Tx チャネル
（CPU1 → CPU2）

IPCC の Rx チャネル
（CPU2 → CPU1）

システム

0

0

LoRaWAN

登録による自動割当て

登録による自動割当て

無線登録による自動割当て

登録による自動割当て

Sigfox登録による自動割当て

登録による自動割当て

KMS*

登録による自動割当て

該当なし

トレース

該当なし

登録による自動割当て

RTC

該当なし

登録による自動割当て* CubeWL v1.0.0 では KMS が完全には実装されていない

13

この表は、これまでのスライドで説明したマッピングをまとめたも
のです。

13

機能によるチャネルの使用• 原則として、2 つのコア間で共通の言語が定義済みであれば、チャネルと共有バッファを使用してあらゆる種類のメッセージを交換可能• 実際上、"言語" には、"一方のコアから他方のコアで機能を実行できるようにして、その戻り値または処理済みバッファを取得する" という固有の目標がある• メールボックスの共有メモリは、この目標を達成できるように設計• CM4 で Cmd を使用して、CM0PLUS に実装されている関数を呼び出し• CM0PLUS で Resp を使用して、関数の実行が完了して戻り値が得られていることを通知• CM0PLUS で Notif を使用して、CM4 に実装されている機能を呼び出し• CM4 で Ack を使用して、関数の実行が完了して戻り値が得られていることを通知

14

2 つのコア間で共通の言語が定義済みであれば、チャネルと共有バッファを使用してあらゆる種類のメッセージを交換できます。
メールボックスの共有メモリは、この目標を達成できるように設計されています。
• CM4 で Cmd を使用して、CM0PLUS に実装されている関数を呼び出し• CM0PLUS で Resp を使用して、関数の実行が完了して戻り値が得られていることを通知• CM0PLUS で Notif を使用して、CM4 に実装されている機能を呼び出し• CM4 で Ack を使用して、関数の実行が完了して戻り値が得られていることを通知

14

通信言語
• 言語の目的に応じてメッセージを書式設定• 識別子（MsgId）を使用して呼び出す関数を特定する• バッファと構造体に関数のパラメータまたはポインタを渡す• 関数の実行が完了した通知を受け、戻り値を取得する
typedef struct {uint32_t MsgId;
void (*MsgCpu1Cb)(void* ComObj);
void (*MsgCpu2Cb)(void* ComObj);uint16_t BufSize;/*!< アプリケーションから渡される配列のサイズ */uint16_t ParamCnt; /*!< メッセージを構成する単語の数 */uint32_t* ParamBuf;
ParamBuf[]
uint32_t ReturnVal;} MBMUX_ComParam_t;• 緑色の値は登録時に設定（機能ごとに 1 回）
• 青色の値はメッセージ（Cmd、Resp、Notif、Ack）送信のたびに設定
15

したがって、言語の目的に応じてメッセージが書式設定されています。
• 識別子（MsgId）を使用して呼び出す関数を特定する• バッファと構造体にパラメータまたはポインタを渡す• 関数の実行が完了した通知を受け、戻り値を取得する
ここに挙げた構造体は、コードから直接抜粋したものです。後
ほど詳しく説明します。

15

通信テーブル

typedef struct {MBMUX_ComParam_t
MBCmdRespParam[IPCC_CHANNEL_NUMBER];
MBMUX_ComParam_t
MBNotifAckParam[IPCC_CHANNEL_NUMBER];
uint8_t
MBMUXMapping[FEAT_INFO_CNT][2];__IO uint16_t
SynchronizeCpusAtBoot;
uint16_t
ChipRevId;} MBMUX_ComTable_t;

16

各 IPCC チャネルには、通信のチャネル専用インスタンスがあり、これはすべての IPCC チャネル（Tx と Rx）と同様です。
したがって、前のスライドでは MBMUX_ComParam_t が 12回繰り返されています。
次のスライドの図は直感的でわかりやすく、C コードも示され
ています。

16

通信テーブル（1/5）
MBMUX_ComParam_t を 12 回繰り返し
MBMUX_ComTable_t
_

MUX
システム

MBCmdRespParam [0]MBCmdRespParam [1]Radio_SubGh

MBCmdRespParam [2]MBCmdRespParam [3]SigfoxMBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]

KMS

トレース
LoRaWAN

MBNotifAckParam[1]緑青： 初期化と機能登録のときに設定： メッセージ交換のたびに設定
MsgId
void (* MsgCm4Cb)( void ComObj ）void (* MsgCm0 plusCb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal

MBNotifAckParam[2]MBNotifAckParam[3]ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf[ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_ CNT][2];ParamBuf[BufSize-1]

SynchronizeCpusAtBoot

パラメータとしてポインタも可*ParamBuf[..]

BufSize は、最もパラメータが多い関数によって決まる

ChipRevId
17

ここでは、MBMUX_ComTable_t で
MBMUX_ComParameter_t が 12 回インスタンス化されていることがわかります。
機能で登録をリクエストすると、空いているチャネルがその機能に割り当てられ、この登録が MBMUX のマッピング･テーブルに保存されます。

17

通信テーブル（2/5）
MBMUX_ComParam_t を 12 回繰り返し
MBMUX_ComTable_t
_

MUX
システム

MBCmdRespParam [0]MBCmdRespParam [1]Radio_SubGh

MBCmdRespParam [2]MBCmdRespParam [3]SigfoxMBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]

KMS

トレース
LoRaWAN

MBNotifAckParam[1]緑青：： 初期化と機能登録のときに設定
メッセージ交換のたびに設定
MsgId
void (* MsgCm4Cb)( void ComObj ）void (* MsgCm0plusCb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal

MBNotifAckParam[2]MBNotifAckParam[3]ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf[ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_ CNT][2];ParamBuf[BufSize-1]

パラメータとしてポインタも可*ParamBuf[..]SynchronizeCpusAtBoot
ChipRevId

BufSize は、最もパラメータが多い関数によって決まる
18

たとえば、トレース機能が登録を求め、それに
MBNotifAckParam[1] が割り当てられたとします。トレース機
能は Rx チャネルのみを必要とするので
MBCmdRespParam インスタンスの登録は不要です。CM4に対して CM0PLUS のみがトレース関数を呼び出し、他の呼び出し形態はないからです。2 つのコア間でのトレース関数の呼び出しごとに MsgID があります。トレースのParamBuf は、パラメータが多いほうのトレース関数から計算されます。パラメータが最も多い関数のパラメータ数が 5であれば、BufSize パラメータは 5 に設定されます。

18

通信テーブル（3/5）
MBMUX_ComParam_t を 12 回繰り返し
MBMUX_ComTable_t
_

MUX
システム

MBCmdRespParam [0]MBCmdRespParam [1]Radio_SubGh

MBCmdRespParam [2]MBCmdRespParam [3]SigfoxMBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]

KMS

トレース
LoRaWAN

MBNotifAckParam[1]緑青： 初期化と機能登録のときに設定： メッセージ交換のたびに設定
MsgId
void (* MsgCm4Cb)( void ComObj ）void (* MsgCm0plusCb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal

MBNotifAckParam[2]MBNotifAckParam[3]ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf[ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_ CNT][2];ParamBuf[BufSize-1]

パラメータとしてポインタも可*ParamBuf[..]SynchronizeCpusAtBoot
ChipRevId

BufSize は、最もパラメータが多い関数によって決まる
19

MBMUX に登録された機能は、IPCC チャネルとそれに関連付けられたバッファを予約します。このバッファのサイズは登録された機能によって決まります。一般的には、その機能の関数のうち、パラメータが最も多い関数に基づきます。
たとえば、"トレースの ParamBuf" は、パラメータが多いほうの "トレース関数" に応じて決まります。
パラメータが 3 つのみのトレース関数を呼び出すと、トレースの ParamBuf は部分的に使用され、その関数の実行中はParamCnt が 3 に設定されています。
ParamBuf は int32_t 型フィールドで構成され、これらのフィールドには、値、構造体へのポインタ、またはデータ･バッ
ファへのポインタが格納されます。

19

通信テーブル（4/5）
MBMUX_ComParam_t を 12 回繰り返し
MBMUX_ComTable_t
_

MUX
システム

MBCmdRespParam [0]MBCmdRespParam [1]Radio_SubGh

MBCmdRespParam [2]MBCmdRespParam [3]SigfoxMBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]

KMS

トレース
LoRaWAN

MBNotifAckParam[1]

緑
青

：
：

初期化と機能登録のときに設定
メッセージ交換のたびに設定
MsgId
void (* MsgCm4Cb)( void ComObj ）void (* MsgCm0plusCb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal

MBNotifAckParam[2]MBNotifAckParam[3]ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf[ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_ CNT][2];ParamBuf [BufSize-1]

SynchronizeCpusAtBoot

パラメータとしてポインタも可*ParamBuf[..]

BufSize は、最もパラメータが多い関数によって決まる

ChipRevId
20

交換するデータまたは 2 つの CPU からアクセスするデータを収めるバッファ（メールボックス･バッファ、パラメータ･バッファ、各パラメータが指すバッファ）は、すべて共有メモリとする必要があります。
通信テーブル全体および ParamBuf になる可能性がある 12 個のバッファは CM4 によって割り当てます。
パラメータ･バッファ引数が指すバッファは、CM4 またはCM0PLUS のどちらからでも割り当てることができます。

20

通信テーブル（5/5）
MBMUX_ComParam_t を 12 回繰り返し
MBMUX_ComTable_t
_

MUX
システム

MBCmdRespParam [0]MBCmdRespParam [1]Radio_SubGh

MBCmdRespParam [2]MBCmdRespParam [3]SigfoxMBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]

KMS

トレース
LoRaWAN

MBNotifAckParam[1]

緑
青

：
：

初期化と機能登録のときに設定
メッセージ交換のたびに設定
MsgId
void (* MsgCm4Cb)( void ComObj ）void (* MsgCm0plusCb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal

MBNotifAckParam[2]MBNotifAckParam[3]ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf [ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_ CNT][2];ParamBuf[BufSize-1]

SynchronizeCpusAtBoot

パラメータとしてポインタも可*ParamBuf[..]

BufSize は、最もパラメータが多い関数によって決まる

ChipRevId
21

トレースのサンプルに戻ります。ログ･メッセージは、パラメータのbuffer 引数で指す数バイトのバッファです。トレース機能では、このバッファは CM0PLUS によって割り当てられます。

21

SH1 メモリ（CM4 によって割り当てられたテーブル）

プライベート･バッファの共有

MBMUX_ComTable_t_
MBCmdRespParam [0]MBCmdRespParam [1]MBCmdRespParam [2]MBCmdRespParam [3]MBCmdRespParam [4]MBCmdRespParam [5]MBNotifAckParam[0]MBNotifAckParam[1]

MBMUX_ComParam_t を 12
回繰り返し
MsgId
void (* MsgCm4Cb)( void ComObj ）BufSize
ParamCnt* ParamBuf
ReturnVal
ParamBuf[0]MBNotifAckParam[4]ParamBuf[..]

MBNotifAckParam[5]ParamBuf[ParamCnt-1]

MBMUXMapping[ FEAT_ INFO_CNT][2];ParamBuf[ BufSize-1]

SynchronizeCpusAtBoot

プライベートメモリ

void(* MsgCm0 plusCb)( void ComObj ）MBNotifAckParam[2]MBNotifAckParam[3]SH1 または SH2
メモリ

パラメータとしてポインタも可*ParamBuf[..]*

ChipRevId

22

プライベート･メモリ領域にある "メモリ･スタック" または変数やバッファを関数パラメータのポインタが指している場合、そのバッ
ファには特段の注意が必要です。
このような場合、"機能の関数のラッパー" で "プライベート変数
やバッファ" の一時コピーを作成し、他の CPU がその関数を処理する前に共有メモリとする必要があります。他のコアの関数によってバッファが変更されている場合は、同様のラッパーでそのバッファを取得してプライベート･メモリに戻します。

22

シングル･コア･デバイスでの関数の実行
CM4
シングルコア23

シングル･コアの場合は、すべての関数が同じコア上に存在します。
特定の機能に属する関数 "X" をプログラムで実行する必要がある場合、そのプログラムから a、b、c の各パラメータを渡すことでその関数を呼び出します。
メールボックスを使用する必要はありません。

23

ある CPU 上の関数を別の CPU から実行できるようにする
メールボックス
CM4 から CM0PLUS

24

CM0PLUS コア上の関数を CM4 コアから呼び出す必要があるとします。
この関数は、チャネルで登録された機能に属しており、CmdRespParam
バッファが関連付けられています。
各機能にはラッパーが実装され、各関数にはその関数名を名前とする
ラッパー関数が存在します。
このラッパーは、次の値を CmdRespParam バッファに設定します。
• MsgId• ParamCnt• 関数 "X" のパラメータ（名前を a、b、c とします）
CM4 から IPCC を介して CM0PLUS に割込みをトリガし、その応答を待ちます。この呼び出しはブロッキング呼び出しです。
CM0PLUS が IPCC 割込みの処理を開始します。MsgId をデコードする
アンラッパー関数を呼び出し、そのパラメータを抽出して、実際の関数"X" を呼び出します。
CM0PLUS によって関数 "X" が実行され、その戻り値がCmdRespParam バッファに置かれます。
これで、CM0PLUS から CM4 に応答（IPCC フラグのクリアなど）を返送できるようになります。
CM4 は、自身をウェイト･ステートからウェイクアップする割込みを受け取
り、CmdRespParam バッファから戻り値を取得して、feature_func_x()関数の実行を終了します。
このような "ブロッキング呼び出し" 手法により、シングル･コア実行とデュ
アル･コア実行のどちらでも確実に同じ動作シーケンスが実現します。

24

ある CPU 上の関数を別の CPU から実行できるようにする
メールボックス
CM0PLUS から CM425

CM4 コア上の関数を CM0PLUS から実行する必要がある場合、その手順は前回の場合と全面的に対称です。
ただし、値が置かれる場所は CmdRespParam バッファではなく、
NotifAckParam バッファです。
関連する関数の名前に使用する文字も、Cmd が Notif、Resp
が Ack になります。

25

CM4
アプリケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X の
ラッパー

Cmd
Resp

Notif
Ack

機能 X のMBMUXIF

機能 X のMBMUXIF

CM4MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

26

次のスライドは、ここまで説明した概念とコード、ファイル、レイヤとの対応関係を理解するうえで効果的です。
この図では、例として挙げた LoRaWAN AT_Slave プロジェクトのディレクトリ･ツリーを示しています。
左側は、CM4 側で実行するプロジェクト部分を構成するファイル
であり、右側は、プロジェクトの CM0PLUS 部分を構成するファ
イルです。
MBMUX は、このアプリケーションの一部ですが、自身専用のディレクトリ MbMux を備えています。
ファイルはアプリケーションごとに複製されます（すべてのアプリ
ケーションやサンプルで横断的に使用されるミドルウェア、ユー
ティリティ、ドライバとはこの点が異なります）。
MBMUX はいくつかの方法で実装されます。このコードを理解するために、各レイヤについて説明します。

26

CM4 アプリ
ケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X のラッパー

Cmd
Resp

Notif
Ack

機能 X のMBMUXIF

機能 X のMBMUXIFMBMUX レイヤ（1/4）
Cmd または Notif での関数呼び出しを変換するラッパー

API に Msg_Id 表記あり

各機能には専用の表記

API に機能の表記あり

CM4
MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

API にチャネルの表記あり

27

MBMUX は 3 つのレイヤで構成されます。この図の最下部は、
基本的に物理レイヤである IPCC を示しています。
IPCC は HAL ドライバの一部です。IPCC_IF はインタフェース･レイヤです（IP ごとに存在）CM4 コアと CM0PLUS コア両方のこ
れらのインタフェースは MBMUX の一部ではありません。

27

CM4
アプリケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X のラッパー

Cmd
Resp

Notif
Ack

機能 X のMBMUXIF

機能 X のMBMUXIFMBMUX レイヤ（2/4）
Cmd または Notif での関数呼び出しを変換するラッパー

API に Msg_Id 表記あり

各機能には専用の表記

API に機能の表記あり

CM4
MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

API にチャネルの表記あり

28

MBMUX の下位レイヤは IPCC の直上に位置し、そのタスクはチャネルへの機能のマッピングです（登録と多重化を提供）。
IPCC_IF および MBMUX の下位レイヤは汎用サービスです（ユーザによる変更は想定されていません）。

28

CM4
アプリケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X のラッパー

Cmd
Resp

Notif
Ack

機能 X のMBMUXIF

機能 X のMBMUXIFMBMUX レイヤ（3/4）
Cmd または Notif での関数呼び出しを変換するラッパー

API に Msg_Id 表記あり

各機能には専用の表記

API に機能の表記あり

CM4
MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

API にチャネルの表記あり

29

各機能は、それに専用の MBMUXIF によって MBMUX とインタ
フェース接続します。新しい機能を追加するには、該当の
MBMUXIF を実装する必要があります。
パラメータ･バッファ･サイズやコールバックに対する反応性（タスクと割り込みのサービス･ルーチン間の関係）などのカスタマイズ
を、目的の機能で必要とする場合、既存の MBMUXIF の適応が求められることがあります。
MBMUXIF は次の各処理を実行します。
• CM4 と CM0PLUS との通信に使用する、機能専用バッファの割り当て• MBMUX バッファでの機能登録の開始（通信バッファの登録、
コールバックの登録）• feature_ID とメールボックス方向からの上位レイヤの抽象化• メッセージ ID スイッチの実装• シーケンサの取り扱い（他のドキュメントで取り上げている "カーネル/スケジューラ" の一種）

29

CM4
アプリケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X のラッパー

Cmd
Resp

Notif
Ack

機能 X のMBMUXIF

機能 X のMBMUXIFMBMUX レイヤ（4/4）
Cmd または Notif での関数呼び出しを変換するラッパー

API に Msg_Id 表記あり

各機能には専用の表記

API に機能の表記あり

CM4
MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

API にチャネルの表記あり

30

機能のラッパーは関数をメッセージに変換します。

30

鏡面性
• CM4 の IPCC_IF は CM0PLUS の IPCC_IF に対して鏡面関係

CM4
アプリケーション

CM0PLUS
アプリケーション

機能 X のラッパー

機能 X のラッパー

Cmd
Resp

Notif
Ack

• CM4 の MBMUX は CM0PLUS の MBMUX に対して鏡面関係

機能 X のMBMUXIF

機能 X のMBMUXIF• CM4 の MBMUX は、Cmd と Ack を送信するための API、およびNotif と Resp を扱うコールバックを提供

CM4
MBMUX

CM0PLUS
MBMUX

CM4
IPCC_IF

CM0PLUSIPCC_IF

IPCC

IPCC

• CM4 の IPCC_IF は、Cmd と Ack を送信するための API、およびNotif と Resp を扱うコールバックを提供• CM0PLUS の IPCC_IF は、Notif と Resp を送信するための API、および Cmd と Ack を扱うコールバックを提供• CM0PLUS の MBMUX は、Notif と Resp を送信するための API、および Cmd と Ack を扱うコールバックを提供• CM4 の MBMUXIF は CM0PLUS の MBMUXIF に対して鏡面関係• CM4 の MBMUXIF は、Cmd と Ack を送信するための API、およびNotif と Resp を扱うコールバックを提供• CM0PLUS の MBMUXIF は、Notif と Resp を送信するための API、および Cmd と Ack を扱うコールバックを提供

31

CM4 コアの各ブロックには、CM0PLUS コアの該当ブロックに対する鏡面性がありますが、ブロック自体は同一ではありません。
したがって、CM4/Mbmux/mbmux.c とCM0PLUS/Mbmux/mbmux.c のコードは異なっています。
CM4 の MBMUX ファイルでコマンドと確認応答を送信し、通知と応答を扱うコールバックを提供する場合、CM0PLUS 側でそれと鏡面性を持つファイルでは、通知と応答を送信し、コマンドと確認応答を扱うコールバックを提供します。

31

1 つの CPU 上のグローバル･スタック（他の CPU にミラーリング）
KMS
アプリケーション

LoRa
アプリケーション

その他のアプリケーションシステム
アプリケーション

KMS
ラッパー

トレース
アプリケーション

LoRa
ラッパー

その他の
ラッパー

システム
MBMUXIFKMS
MBMUXIF

トレース
MBMUXIFLoRa
MBMUXIFその他の
MBMUXIF

MBMUX

IPCC_IF

IPCC（6 チャネル x 方向）
32

これは、前の図にある 2 つの列の 1 つを詳しく表した図です。
すべての MBMUXIF と相互作用する "システム MBMUXIF" を除き、各 MBMUXIF ブロックは機能間で独立しています。
MBMUX とシステム MBMUXIF はメールボックスの中核的存在です。
注意：KMS への Notif/Ack の矢印と、トレースへの Cmd/Respの矢印がないのは誤植ではありません。これらの機能は次のよ
うに一方向性です。
• KMS は、CM0PLUS コアに暗号化を要求するために CM4 コアから呼び出されます。コールバックは不要です。
• トレースは、出力する CM4 コア文字列を IPCC を介して送信するために CM0PLUS コアで使用されます。
KMS のラッパーは実装されていません。SubGHz のサンプルでは、KMS 同様に CM0PLUS コア上に存在する SubGHz スタッ
クからのみ KMS が呼び出されます。
CM4 から CM0PLUS コア上の KMS API を呼び出すには、専用のラッパーを実装する必要があります。
スライドの左側は、コード間の移動に便利なファイル･ツリーのス
クリーン･ショットです。

32

初期化シーケンスと機能情報テーブル

33

次のスライドでは、MBMUX がどのように初期化されるかを説明するタイムライン シーケンスを提供します。これは、コードを変更する必要がある人にも役立ちます33デュアル･コア通信の初期化（1/2）• 初期化シーケンス• 共有メモリのアドレスを CM4 で設定（オプション･バイト）• CM4 から CM0PLUS をブート
CM4

CM0PLUS
ブート

•
•
•
•

コア初期化
HAL
システム･クロック設定
LPM 初期化
トレース/USART 初期化

MBMUXIF システム初期化• 共有テーブルのメモリ割り当て• OPTIONBYTE_IPCC_BUF_ADDR へのテーブル addr の保存• IPCC 初期化• チャネル 0 C/R へのシステム登録• PWR_CR4_C2BOOT = 1#define CPUS_BOOT_SYNC_PREVENT_CPU2_TO_START 0xFFFF#define CPUS_BOOT_SYNC_ALLOW_CPU2_TO_START 0x5555#define CPUS_BOOT_SYNC_CPU2_INIT_COMPLETED 0xAAAA#define CPUS_BOOT_SYNC_RTC_REGISTERED
0x9999SynchronizeCpusAtBoot = 0xFFFF
PWR_CR4_C2BOOT = 1

ブート

34

SubGHz のサンプルで最初にブートするコアは必ず CM4 コアです。CM0PLUS コアは、PWR_CR4 レジスタの C2BOOT ビット
部分を通じて保留状態になっています。
MBMUX テーブルや通信バッファなどの MBMUXIF システム･
ブロックが CM4 コアによって初期化されてから、CM0PLUS コ
アが解放されます。
このプレゼンテーションの最後で、
OPTIONBYTE_IPCC_BUF_ADDR の初期化を詳しく取り上げ
ます。

34

CM4

デュアル･コア通信の初期化（2/2）
CM0PLUSPWR_CR4_C2BOOT = 1
PWR_CR4_C2BOOT = 1

ブート

デバッグでは、SynchronizeCpusAtBoot =0x5555 とする前にブレークポイントを設定
可能

コア初期化
• HAL 初期化
• RTC 初期化
• LPM 初期化

• ここからは、MBMUX
を介して 2 つの CPUが通信

OPTIONBYTE_IPCC_BUF_ADDR で共有テーブル addr を取得
SynchronizeCpusAtBoot = 0x5555 を待機

SynchronizeCpusAtBoot = 0x5555

SynchronizeCpusAtBoot = 0xAAAA を待機

MBMUXIF システム初期化• 機能情報のメモリを割り当て• チャネルの N/Ack にシステムを登録• SynchronizeCpusAtBoot = 0xAAAA
SynchronizeCpusAtBoot = 0xAAAA

これで MBMUX を介して 2 つの CPU が通信可能

35

SynchronizeCpusAtBoot フラグが 0xFFFF で初期化されます。
CM4 でこのフラグを使用して、CM0PLUS で MBMUX の初期化が完了したことを検知します（このフラグの値が 0xAAAA になります）。
必要に応じ、このフラグをデバッグの際に使用して、
MBMUX_System_Init() 関数が実行されないように CM0PLUS
コアを保持できます。CM4 にブレークポイントを配置しないので、この動作は透過的です。
MBMUXIF システムが初期化されると、MBMUX を介して 2 つの CPU が通信できます。

35

MBMUX を介した初期化の継続
CM4

CM0PLUSMBMUX
CM0+ 機能リスト･ポインタへのリクエスト

Resp

RTC 用高優先度チャネルの登録

Command() への応答
Sequencer_run(idle)

Cmd
Resp

SyncrhonizeCpusAtBoot = 0x9999 の待機

Sequencer_run(idle)

Cmd

RTC 用高優先度チャネルの登録
Command() への応答
Sequencer_run(idle)

SynchronizeCpusAtBoot = 0x9999
Cmd

LoRaWAN 機能用チャネルの登録
Resp

LoRaWAN 機能用チャネルの登録
Command() への応答
Sequencer_run(idle)
36

どの機能についても登録のマスタは必ず CM4 コアです。
CM4 コアでは、機能を登録する前に、CM0PLUS コアにダウンロードされたバイナリ･ファームウェアがその機能をサポートしているかど
うかを知る必要があります。
CM0PLUS バイナリが Sigfox プロトコルのみをサポートしているとす
ると、LoRaWAN プロトコルを登録できないことを検知する手段がMBMUX に必要です。
これは、FEATURE_INFO_LIST テーブルによって実現できます。後ほど詳しく取り上げます。
インストールする必要があるシステム要素として、ほかに時間サーバのタイム･ベースがあります。SubGHz のサンプルでは、このタイム･ベースが実時間コントローラ（RTC）から提供されます。
両方のコアでタイム･ベースが必要なので、RTC 専用の IPCC チャネルがあります。ソフトウェア･アーキテクチャ設計の選択により、
RTC 割り込みは CM0PLUS コアでのみ扱われ、IPCC を介してCM4 に RCC 割り込みが転送されます。
SynchronizeCpusAtBoot フラグが 0x9999 になると、RTC チャネルも登録されます。
この時点から、MBMUX フレームワークの中核部が初期化されます。
トレース、LoRaWAN、Sigfox をはじめとする他のあらゆる機能を登録できます。

36

機能情報の交換• このプレゼンテーションの冒頭でも取り上げたように、CM4 と CM0PLUS のバイナリは互いに相違• CM4 で以下の点を知る方法• CM0PLUS にどの無線スタックが実装されているか。（LoRaWan、Sigfox、その他）• 各スタックと各機能のバージョンは何か• 目的のスタックと機能がどのように設定されているか（LoRaMAC がすべての領域、すべてのクラスをサポートしているかなど）• この情報は、CM0PLUS から FEAT_INFO_List_t テーブルで提供• このテーブルは、CM0PLUS によって SRAM2_SH2 メモリに割り当て• CM4 は、システム機能が提供するサービスを通じて、このテーブルのアドレスを要求（前のスライドの左上部分）
37

CM4 コアと CM0PLUS コアのバイナリは互いに異なります。
CM4 コアでは、どの無線スタックが CM0PLUS コアに実装されているか（LoRaWAN、Sigfox、その他）、各スタックと各機能の設定のバージョンは何かを知る必要があります。
この情報は、CM0PLUS コアから FEAT_INFO_List_t テーブルで提供されます。このテーブルは、CM0PLUS コアによってSRAM2_SH2 メモリに割り当てられます。
CM4 コアでは、システム機能が提供するサービスを通じて、このテーブルのアドレスを取得します。

37

Feat_info_list_t• 構造体を定義するヘッダ･ファイルは両方の CPU に共通• リストにある構造体はバージョンが変わっても変更なし• 各機能のパラメータはバージョンが変わると変更される可能性あり
typedef struct{
FEAT_INFO_IdTypeDef Feat_Info_Feature_Id;
uint32_t Feat_Info_Feature_Version;
uint32_t Feat_Info_Config_Size;void *Feat_Info_Config_Ptr;} FEAT_INFO_Param_t;
typedef struct{uint32_t Feat_Info_Cnt;
FEAT_INFO_Param_t *Feat_Info_TableAddress;} FEAT_INFO_List_t;

FEAT_INFO_Param_t Feat_Info_Table[] ={{.Feat_Info_Feature_Id= FEAT_INFO_SYSTEM_ID,.Feat_Info_Feature_Version = FEAT_INFO_SYSTEM_VER,.Feat_Info_Config_Size = 0,.Feat_Info_Config_Ptr = (void *) NULL},{
.Feat_Info_Feature_Id= FEAT_INFO_LORAWAN_ID,.Feat_Info_Feature_Version = __LORA_CM0_APP_VERSION,.Feat_Info_Config_Size = sizeof(LoraInfo_t),.Feat_Info_Config_Ptr = (void *) loraInfo},{.Feat_Info_Feature_Id= FEAT_INFO_RADIO_ID,.Feat_Info_Feature_Version = __SUBGH_MW_VERSION,.Feat_Info_Config_Size = 0,.Feat_Info_Config_Ptr = (void *) NULL}, ...

38

これは、CM0PLUS のバイナリがその機能をどのように公開しているかに関するコードの詳細です。
FEAT_INFO_List_t のサイズは機能の数に応じて変化します。
機能の数は Feat_Info_Cnt パラメータとして設定します。
この構造体と FEAT_INFO_Param_t 型は、レビジョンが変わっても変更しないようにします。
FEAT_INFO_Param_t 型には、各機能の説明が記述されています。この説明として、機能の ID、バージョン、設定テーブルのサイズ、そのテーブルへのポインタなどがあります。各機能に関連する設定テーブルには事前定義の構造体がありません。各機
能は自身を実装できます。LoRaWAN 機能を例に挙げると、設定テーブル名は LoraInfo_t で、サポートしている領域、クラス、モード（OTAA、ABP）、KMS サポートなどを記述しています。

38

視覚的に見た Feat_info_list_t
FEAT_INFO_List_t

Feat_Info_Cnt*Feat_Info_Tab

FEAT_INFO_Param_t Feat_Info_Table[]

System_Id
Ver (release)
Config_Size
Config_Ptr(Null)
Feature_Id
Ver (stack ver)Config_Size
Config_Ptr
Feature_Id
Ver (stack ver)Config_Size
Config_Ptr

クラス
領域
など
機能に固有
39

これは、前のスライドで紹介したコードを視覚的に表現した図です。
このテーブルに最初に記述されている機能はシステム機能です。
グローバル･リリースのバージョン（v1.0.0 など）を示し、設定テー
ブルはありません（Null）。
他のタブはバイナリによって異なります。CM0PLUS のバイナリでサポートされている機能のみがテーブルに記述されています。
LoraWAN_AT_Slave プロジェクトには、LoRaWAN、無線、トレースなどの各機能が属します。これらの機能ごとに、スタック･バージョンとそれに対応する設定テーブルへのポインタが指定されています。

39

共有メモリとIPCCDBA オプション･バイト

40

次の付録は、FW パックによって提供されるリンカー ファイルを使用しないユーザーに特に役立ちます。実際、FW パックによって提供されるリンカー ファイルを使用しないコードは無限ループによる保護状態に入る可能性があります。

40

メモリ･マッピング• v1.0.0 リリースでの EndNode 向けリンカ･ファイルの例
0x0803FFFF
CM0PLUS0x08020000
ROM

RAM2_PRIV

0x2000FFFF
0x2000C000

RAM2_SH20x2000BFFF FEAT_INFO_List テーブル
0x2000B000
0x2000AFFF MbMux_Com テーブル
0x20008000

RAM2_SH10x0801FFFF

0x20007FFF
RAM1

CM4
0x08000000

0x20000000
41

要約すると、MbMux_Com テーブルが CM4 コアによって割り当
てられ、SRAM2_SH1 メモリに置かれます（CM4 のリンカ･ファイ
ル）。
Feat_Info_List テーブルが CM0PLUS コアによって割り当てら
れ、SRAM2_SH2 メモリに置かれます（CM0PLUS のリンカ･
ファイル）。
これら 2 つのコアは、相互に通信するためにこれらのテーブルのアドレスを知る必要があります。
CM0PLUS は、IPCCDBA オプション･バイトを通じて
MbMux_Com テーブルのアドレスを取得します。
CM4 は、MbMux 通信を通じて Feat_Info_List テーブルのアドレスを取得します。

41

IPCCDBA オプション･バイト• "SubGHz サンプル" では、CM4 のリンカ･ファイルによって MbMux_Com テーブルが0x20008000 に置かれる• CM4 によって置かれた MbMux_Com テーブルのアドレスを CM0PLUS が次のように取得• OptionsBytesStruct.IPCCdataBufAddr = SRAM1_BASE + IPCCDBA <<4;

• STM32WL デバイスでは、オプション･バイト IPCCDBA はデフォルトで 0x800• したがって、OptionsBytesStruct.IPCCdataBufAddr = 0x20008000 は CM4 のリンカ･ファイルと一致• リンカ･ファイルで MbMux_Com テーブルを他の場所に置いた場合の動作• 初期化の際に、CM4 は IPCCDBA の値を読み取り、リンカ･ファイルに記述された
MbMux_Com テーブルのアドレスと比較。これらの値が一致しない場合、CM4 は IPCCDBA オ
プション･バイトを上書きしてボードをリブート。次回の実行ではこれらの値が一致し、CM0PLUS
が新しいアドレスを取得。
42

IPCCDBA オプション･バイト･レジスタには MbMux_Com テーブ
ルのアドレスが記述されています。
新しいボードでは、このレジスタのデフォルト値と、SubGHz サン
プルのリンカ･ファイルに用意されている値が一致します。
それ以外のボードでは、CM4 コアによってアドレス値が更新されていることが想定できます。CM0PLUS コアは、このテーブルを使用して MbMux_Com テーブルのアドレスを取得します。
このスライドは、この処理手順を詳しく示しています。

42

オプション･バイトに関するプログラミング上の問題• 現実的に、CM4 コアで IPCCDBA オプション･バイトを上書きするには、
CM4/mbmuxif_sys.c ファイルのコードをユーザが若干修正する必要あり• 実際、保護手段として無限ループが置かれているので、IPCCDBA とリンカ･ファイルの不一致があると、コードがこの無限ループを開始• この保護手段は次の 2 つの理由で存在• カット 1.1では、MSI のシステム･クロック周波数が 16 MHz を超えると、このオプション･バイトのプログ
ラミングによってバグが発生（SubGHz アプリケーションの場合）。したがって、OBProgram 関数とOBLaunch 関数を呼び出す前に MSI 周波数が低くなるようにコードを修正する必要あり。この問題は
カット 1.2 で修正。
• リンカ･ファイルで MAPPING_TABLE を定義していないと、リンカから警告が発行されずに、SRAM1のどこかに MbMux_Com テーブルが置かれ、それに応じて OB が設定される。この保護手段がないと、ユーザが気付かないまま、IPCCDBA オプション･バイトをプログラムが上書き。
43

IPCCDBA オプション･バイトが CM4 によって変更されないように、現在は保護手段が置かれています。これは、このスライドで説明している 2 つの理由によります。
ファームウェアの次回パッケージ WL_1.1.0 では、この保護手段が撤廃される予定です。

43

CubeMX とリンカ･ファイル• CubeMXを使用して白紙からコードを生成する場合に使用されるスキャッタ･ファイルは、導入パッケージ･アプリケーションに用意されているものではなく、CMSISのスキャッタ･ファイル• CMSIS のデフォルトのスキャッタ･ファイルでは MAPPING_TABLE が未定義

• これによって IPCCDBA と MbMux_Com テーブルのアドレスが一致せず、while(1) {} による保護状態に入る。この保護は、リンクとコード実行の前にリンカ･ファイルを設定することをユーザに促すもの• リンカ･ファイルを更新すると、MX でコードを再生成しても更新済みのリンカ･ファイルは消去されない。実際、MX で CMSIS デフォルトのスキャッタ･ファイルが使用されるのは、関係する IDE ディレクトリにスキャッタ･ファイルが存在しない場合のみ（USER CODE SESSIONと同様の原則）• 保護の除去は、その影響を把握しているユーザのみが実施のこと
44

CUBEMX では MBMUX の表記がない汎用のリンカ･ファイルのみが生成される点に注意します。
したがって、CUBEMX を使用して生成したコードは、このスライドで説明しているようなリンカ･ファイルの更新やコードの修正を適用しないと、無限ループ保護のトラップに入ります。

44