「スマートエネルギー」太陽光発電に関する意見 追記：皆さん、ありがとうございます。ご意見ありがとうございます！彼らには「とっとと失せろ」と言ってやるよ。どうせ私は何も約束する準備ができていないんだから。 今日はスマートエナジーという会社の訪問販売員が何人か来て、太陽光パネルについて話したがっていました。太陽光発電に興味はあるのですが、初期投資をする資金がありません。そこで、初期費用ゼロで利用できる政府資金による制度があると聞きました。 もちろん、私は非常に懐疑的です。彼らと取引したことのある方からのご意見をぜひお聞かせください。

Does i.MX6UL provide any mechanism (timer/register) to delay or control ZMK zeroization after tamper Does the i.MX6UL provide any hardware mechanism (register, timer, counter, or configuration) to prevent or postpone automatic ZMK zeroization after a valid external tamper event? If such a mechanism exists, could you please point me to the relevant register(s), timer, or configuration described in the Security Reference Manual? Platform: i.MX6UL  Bootloader: U-Boot 2016.03 OS: Linux + OP-TEE Reference used: Security Reference Manual for the i.MX 6UltraLite Applications Processor, Rev. 0, 04/2016 @nxp 

FreeMasterプラグインモジュールはありません 私はフリーマスターバージョン3.2.7をインストールしました。いろいろな方法を試しましたが、プラグインモジュールの下には何もありません。急いでるんだ。これは私の仕事に欠かせない道具です。どなたか助けていただけますか?どうもありがとうございます。 1. FreeMASTERを「管理者として」インストールするか、「c:\NXP\FreeMASTER 3.2\FreeMASTER\register.bat」を実行してください。効果はありません！！！ 2. Re: there has no FreeMaster plug-in module こんにちは、 私の知る限り、最新のWindowsアップデートではCOM+およびActiveXオブジェクトの動作方法は変更されません。これは関係ない。あなたが直面している問題は、実に奇妙です。 一つのプラグイン(CAN通信)を選んで登録情報を確認しましょう。 再度「コマンドプロンプト」を管理者として実行し、「c:\NXP\FreeMASTER 3.2\FreeMASTER」に移動して、/s (サイレント) オプションなしで regsvr32 コマンドを実行します。 regsvr32 プラグイン/CAN/focpgi.dll 確認メッセージは以下に表示されます。 次に、同じコマンドプロンプトコンソールで、以下のコマンドを使用してレジストリエディターを起動します。 レジストリエディタ 数分かかることもありますが、その後エディターが表示されます。ナビゲート先 Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{C10A92C3-7D47-4FDC-94B6-64B8E5C85E01} この項目はFreeMASTER-over-CANプラグイン(focpgi.dll)を表しています。それは登記簿に記載されなければならない。 InprocServer32のエントリポイントを正しいfocpgi.dllファイルに確認できます。 「実装済みカテゴリ」IDは、FreeMASTERがWindows COMカテゴリAPIを使用してすべてのプラグインを特定するために使用するIDです。プラグインカテゴリが存在することを確認するために、レジストリエディタでComputer\HKEY_CLASSES_ROOT\Component Categories\{48A185C0-FFDB-11D3-80E3-00C04F176153}キーを確認してください。「MCB Communication Plugins」というテキスト値が表示されます。 もう一つの実験は、スクリプトから/sスイッチを外して実行register.batことです。各DLLごとに登録確認ボックスが表示されます。 該当するスクリーンショットまたはエラーメッセージを共有してください。ご協力ありがとうございました。 よろしくお願いいたします。 ミハル Re: there has no FreeMaster plug-in module もし誰かがこの問題を解決する手助けをしてくれたら、コーヒーをご馳走します。 Re: there has no FreeMaster plug-in module あなたの方法を試しましたが、モジュールはまだ表示されていません。 これは、Windowsシステムが最新バージョンにアップデートされたことと関係がありますか？ Re: there has no FreeMaster plug-in module こんにちは、 インストーラーとregister.batの両方が「 regsvr32.exe 」を使用します。システムユーティリティであり、すべてのWindowsオペレーティングシステムにデフォルトでインストールされる。 まず、システムにregsvr32ユーティリティが存在することを確認してください。Win+Rキーを押して、「regsvr32」コマンドを実行してください。 次のようなヘルプボックスが表示されるはずです。 このユーティリティが動作しない場合は、お使いのコンピュータに管理者によるシステム制限が適用されている可能性があります。修理してもらう必要があります。 regsvr32が正常に動作している場合、register.batが出力するエラーを確認してみましょう。 スタートメニューを開きます。 「コマンドプロンプト」アプリケーションを探してください 右クリックして「管理者として実行」を選択してください（下の画像を参照）。 コンソールで「cd "c:\NXP\FreeMASTER 3.2\FreeMASTER"」と入力します。 register.batを実行します。 エラーは表示されないはずです（最後の画像のように）。 エラーがなければ、プラグインはFreeMASTERに表示されます。誤りがあれば、こちらでお知らせください。 よろしくお願いいたします。 ミハル

メートル 部品の中からメーター制御装置を探しているのですが、見つかりません。

Flash configuration confusion RT1176 Octal DDR Hello NXP I got some issues configuring the flash memory for Macronix Octal DDR mode. I am using the PX4 code stack on a custom board based on the NXP FMU-6XRT reference design. I am using the MX25UM51245G instead of the MX25UM51345G, but the part differences are minimal. I am trying to run it in Macronix Octal DDR mode with DQS external sampling at atleast 100MHz. Reference design is running it at 200MHz. The Boot Memory Configuration succesfully tests the memory with the desired configuration even at 166MHz. The configuration I have tried is the following default config. The first one, "g_flash_config" succesfully boots, writes, read, etc, but is not ideal for the software. "g_flash_fast_config" fails. I have tried reducing the frequency to 166MHZ, 133MHz, 50 MHz, and 30MHz without results in the DTR mode in the "fast_config". I have tried using the FCB generated from the Boot Memory Configuration, but there is some struct layout differences which have made it hard to apply to the PX4 code.  I am tried different combinations of csHoldTime, csSetupTime and dataValidTime without results aswell. I tried DQS interal in low freq DTR Octal, but it did not work either. What could I try next? #include /**************************************************************************** * Public Data ****************************************************************************/ locate_data(".boot_hdr.conf") const struct flexspi_nor_config_s g_flash_config = { .memConfig = { #if !defined(CONFIG_BOARD_BOOTLOADER_INVALID_FCB) .tag = FLEXSPI_CFG_BLK_TAG, #else .tag = 0xffffffffL, #endif .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 1, .csSetupTime = 1, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Generic, .waitTimeCfgCommands = 1, .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_1Pad, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 0}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read Dedicated 3Byte Address Read(0x03), 24bit address */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x03, RADDR_SDR, FLEXSPI_1PAD, 0x18), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_1PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0),//0xb3048b20 }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; const struct flexspi_nor_config_s g_flash_fast_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 3, .csSetupTime = 3, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Spi2Xpi, .waitTimeCfgCommands = 1, .deviceModeSeq = { .seqNum = 1, .seqId = 6, /* See Lookup table for more details */ .reserved = 0, }, .deviceModeArg = 2, /* Enable OPI DDR mode */ .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable) | (1u << kFlexSpiMiscOffset_DdrModeEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_8Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 10}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read */// EEH+11H+32bit addr+20dummy cycles+ 4Bytes read data /* Macronix manual says 20 dummy cycles @ 200Mhz, FlexSPI peripheral Operand value needs to be 2N in DDR mode hence 0x28 */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0xEE, CMD_DDR, FLEXSPI_8PAD, 0x11), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x28),//0xb3288b20, [0 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), //0xa704, /* Read status */ [4 * 2 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x05, CMD_DDR, FLEXSPI_8PAD, 0xfa), [4 * 2 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x04), [4 * 2 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), /* Write enable SPI *///06h [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00000406, /* Write enable OPI SPI *///06h [4 * 4 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x06, CMD_DDR, FLEXSPI_8PAD, 0xF9), /* Erase sector */ [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x21, CMD_DDR, FLEXSPI_8PAD, 0xDE), [4 * 5 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, STOP_EXE, FLEXSPI_1PAD, 0x00), /*Write Configuration Register 2 =01, Enable OPI DDR mode*/ //72H +32bit address + CR20x00000000 = 0x01 [4 * 6 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x72, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000472, [4 * 6 + 1] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000400, [4 * 6 + 2] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, WRITE_SDR, FLEXSPI_1PAD, 0x01),//0x20010400, /*Page program*/ [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x12, CMD_DDR, FLEXSPI_8PAD, 0xED),//0x87ed8712, [4 * 9 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, WRITE_DDR, FLEXSPI_8PAD, 0x04),//0xa3048b20, }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; Re: Flash configuration confusion RT1176 Octal DDR Hello @SimonHugr, If you plan to use DDR mode, please keep in mind that the byte swapping configuration must also be considered. this post provides useful information about why important take in mind the byte swapping on the MX25UM51245GXDI00 when you are using DDR mode.  I highly recommend use the Boot Memory Configuration to generate the FCB, the Secure provisioning tool v26.6 offers a template of the MX25UM51245G, which can serve as a good starting point for your configuration. Also, as you may know, this tool allows you to test your configurations. Additionally, I recommend see this community post, particularly the steps starting from point 15. That section provides a more detailed explanation of how the Secure Provisioning Tool generates the boot memory configuration and may help clarify the parameters and output produced by the tool. Finally, you can use the flexspi_nor_polling_transfer_cm7 example to validate the generated FCB and verify that read and write operations are functioning correctly before proceeding with the boot configuration. BR Habib Re: Flash configuration confusion RT1176 Octal DDR No results yet sadly, I still think it has something to do with some data order swap is done and I am missing some configuration byte somewhere... Re: Flash configuration confusion RT1176 Octal DDR Thank you Masmiseim Indeed, I noticed that the data should be swapped for example. I will go through my LUT once more. Re: Flash configuration confusion RT1176 Octal DDR Refering to this thread: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Internal-Boot-from-Flash-memory-not-starting-on-imxRT1176-custom/m-p/1830699 I should swap the data order by editing the misc option and according to zephyr RTOS https://github.com/zephyrproject-rtos/hal_nxp/blob/3a36ee1f8b9fc2168fc0bf80377ace8298292993/mcux/mcux-sdk-ng/devices/RT/RT1170/MIMXRT1176/drivers/romapi/fsl_romapi.h#L340-L355 the dataswap byte goes in, but I think I am missing something. .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .isDataOrderSwapped = true .serialNorType = 2, .reserve2[0] = 0x7008200, Re: Flash configuration confusion RT1176 Octal DDR Hey @SimonHugr, One thing I would verify first is the actual difference between the MX25UM51245G and MX25UM51345G. Although the part numbers are very similar, they are not identical devices. According to the Macronix datasheets, the MX25UM51345G explicitly supports DOPI (Double Transfer Rate OPI) Byte Mode data sequence, while the MX25UM51245G belongs to a different product variant. This can affect the command format, byte ordering and LUT configuration used by the FlexSPI controller. You can also compare my configuration which works with MX25UM513 and MX25UW6345G: https://github.com/Masmiseim36/Coremark_iMXRT/blob/master/XiP/flexspi_flash_OSPI_Macronix.c Regars

i.MX6ULは、改ざん後のZMKのゼロ化を遅延または制御するためのメカニズム（タイマー/レジスタ）を提供しますか？ i.MX6ULは、有効な外部改ざんイベント後に自動ZMKゼロ化を防止または延期するためのハードウェア機構(レジスタ、タイマー、カウンター、または設定)を提供していますか?もしそのような仕組みが存在するなら、セキュリティリファレンスマニュアルに記載されている該当レジスタ、タイマー、または設定をご紹介いただけますか? プラットフォーム: i.MX6UL  ブートローダー: U-Boot 2016.03 OS: Linux + OP-TEE 参考文献: i.MX 6UltraLiteアプリケーションプロセッサのセキュリティリファレンスマニュアル、Rev. 0、2016年4月 @nxp 

Kinetis 和 LPC 的调试接口有什么建议？ 我目前主要从事 Kinetis 系列芯片的开发工作，未来可能还会开发一些 LPC 芯片。我抽屉里装满了 P&E Micro 的调试接口，其中最常用的是 Cyclone ACP。 我有时会发现自己从 600 美元的 Cyclone 换成了 20 美元的 LPC-Link2，因为 Cyclone 与 MCUXpresso 存在很多奇怪的问题。说实话，LPC-Link2 基本能满足我的需求，只是速度有点慢。 我应该考虑使用Segger接口吗？请问有人可以推荐一款可靠、速度适中、在 MCUXpresso（最好也能在 CodeWarrior 11）中支持良好的接口吗？这款接口不会经常导致程序崩溃，也不会无法停止正在运行的目标。如果能支持追踪功能就更好了。 谢谢您！ Re: Debug interface recommendations for Kinetis and LPC? 你好@zeref ， 这是重复发帖，请参考我在“Kinetis 和 LPC 的调试接口建议？”中的回复。 BR 塞莱斯特

没有 FreeMaster 插件模块 我安装了freemaster 3.2.7版本，我尝试了很多方法，但插件模块里什么都没有。我很着急。这是我工作中必不可少的工具。有人能帮帮我吗？非常感谢。 1.我以管理员身份安装FreeMASTER，或者运行“c:\NXP\FreeMASTER 3.2\FreeMASTER\register.bat”——均无效！！！ 2. Re: there has no FreeMaster plug-in module 你好， 据我所知，最新的 Windows 更新并没有改变 COM+ 和 ActiveX 对象的工作方式。这两件事无关。你遇到的问题确实很奇怪。 我们选取一个插件（CAN 通信）并查看其注册详情。 再次以管理员身份运行“命令提示符”，然后切换到“c:\NXP\FreeMASTER 3.2\FreeMASTER”目录，并使用不带 /s（静默）选项的 regsvr32 命令： regsvr32 插件/can/focpgi.dll 确认信息将显示： 然后在同一命令提示符控制台中，使用以下命令启动注册表编辑器： 注册表 需要一些时间（可能需要几分钟），然后编辑器就会出现。导航至 计算机\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{C10A92C3-7D47-4FDC-94B6-64B8E5C85E01} 此条目代表 FreeMASTER-over-CAN 插件 (focpgi.dll)。它必须登记在册。 您可以检查 InprocServer32 入口点是否指向正确的 focpgi.dll 文件。 “已实现类别”ID 是 FreeMASTER 使用 Windows COM 类别 API来查找所有插件的 ID。为了确保插件类别存在，请在注册表编辑器中检查Computer\HKEY_CLASSES_ROOT\Component Categories\{48A185C0-FFDB-11D3-80E3-00C04F176153}项，您应该会看到“MCB Communication Plugins”文本值： 另一个实验方法是从 register.bat 脚本中删除 /s 开关并运行它。每个 DLL 文件都会显示一个注册确认框。 请分享相关的屏幕截图或错误信息。感谢您的合作。 问候， 米哈尔 Re: there has no FreeMaster plug-in module 如果有人能帮我解决这个问题，我请他喝咖啡。 Re: there has no FreeMaster plug-in module 我尝试了你的方法，但模块仍然没有出现。 这是否与我的Windows系统更新到最新版本有关？ Re: there has no FreeMaster plug-in module 你好， 安装程序和 register.bat 都使用了“ regsvr32.exe ”。系统实用程序，应默认安装在任何 Windows 操作系统中。 首先，请确保您的系统上存在 regsvr32 工具。只需按下 Win+R 键，然后运行命令“regsvr32”。 你应该会看到类似这样的帮助框： 如果此工具无法正常工作，则可能是您的计算机受到了管理员的系统限制。你需要把它修好。 如果 regsvr32 运行正常，我们来看看 register.bat 会输出什么错误信息： 打开开始菜单。 找到“命令提示符”应用程序 右键单击并选择“以管理员身份运行”（见下图） 在控制台中，输入cd "c:\NXP\FreeMASTER 3.2\FreeMASTER" 运行register.bat 您应该看不到任何错误（就像最后图片中显示的那样）。 如果没有错误，插件将出现在 FreeMASTER 中。如有任何错误，请在此处告知。 问候， 米哈尔

IMX95 { 15 x 15 }はLPDDR4/4X 16 GB RAMをサポートしていますか? こんにちは、NXPチームの皆さん、 IMX95{ 15 x 15 }について一般的な情報が欲しいです。MIMX9556CVTXN"は16GBのRAMをサポートします{ LPDDR4/4X } "MT53E4G32D8GS-046 WT:C ?" 16GB RAMをIMX 95に接続するための回路図の参照が見つかりませんでした { 15x 15} 16GB RAMのIMX95 { 19 x 19 }の回路図しか見つけられませんでした。 もし対応しているなら、16GB RAM{ LPDDR4/4x }とimx95{ 15 x 15 }の接続について教えていただけませんか? そしてBSPファイルはどうですか?16GBのRAMに対してDTSファイルが存在するのか、それとも手動で生成する必要があるのか。 Yocto Project Re: Is IMX95 { 15 x 15 } supported LPDDR4/4X 16 GB RAM こんにちは、 @Asadeds さん。 NXPサポートまでご連絡いただきありがとうございます。 当社の メモリ互換性ガイドによると、メモリ部品番号MT53E4G32D8GS-046はi.MX95と完全に互換性があり、このプラットフォーム上で徹底的に検証・テストされています。 したがって、このデバイスは推奨される構成および 設計ガイドラインに従い、i.MX95と併用可能です。 よろしくお願いします、 アレハンドロ・ガルシア

Opinions on "Smart Energy" solar Edit: thanks everyone. Appreciate the input! I'll tell them to bugger off, I'm not ready to commit to anything anyway. I had some door knocker salesmen around today from Smart Energy wanting to talk about solar panels. I'm interested in solar but don't have the funds to invest up front and they said something about a govt funded scheme with $0 upfront. Naturally I'm very sceptical. Would love to hear from anyone who has dealt with them.

mex config generate code different from windows and linux The same XEM file generates different code on different systems. Windows  file generate code normal but linux system generate abnormal precondition：the same as RTD and SDK version install Re: mex config generate code different from windows and linux Hi @Litten  Currently, RTDs are supported only on the Windows platform and are not officially supported on Linux. Even if you are able to install them on Linux, you may encounter additional issues during development and integration. One of the main reasons is that Linux is a case-sensitive operating system,  details about this situation have been discussed in the thread Problems with Lpi2c_Ip_MasterConfig and Lpi2c_Ip_SlaveState struct generation on S32DS for S32K344. BR, VaneB

mex 配置生成的代码与 Windows 和 Linux 不同 同一个XEM文件在不同的系统中会生成不同的代码。 Windows系统生成的文件代码正常，但Linux系统生成的文件代码异常。 前提条件：与 RTD 和 SDK 版本安装相同 Re: mex config generate code different from windows and linux 嗨@Litten 目前，RTD 仅在 Windows 平台上受支持，Linux 平台尚未获得官方支持。即使您能够在 Linux 上安装它们，在开发和集成过程中也可能会遇到其他问题。 主要原因之一是 Linux 是一个区分大小写的操作系统，有关此情况的详细信息已在 S32DS 上针对 S32K344 的 Lpi2c_Ip_MasterConfig 和 Lpi2c_Ip_SlaveState 结构体生成问题线程中进行了讨论。 BR，VaneB

meter I'm trying to find the meter control within the components, but I can't find it.

フラッシュ構成の混乱 RT1176 オクタル DDR こんにちは、NXP Macronix Octal DDRモード用にフラッシュメモリを設定する際に、いくつか問題が発生しました。 NXP FMU-6XRTのリファレンスデザインをベースにしたカスタムボード上でPX4コードスタックを使っています。私はMX25UM51345Gの代わりにMX25UM51245Gを使用していますが、部品の違いはごくわずかです。 Macronix Octal DDRモードで、DQS外部サンプリングを少なくとも100MHzで実行しようとしています。リファレンスデザインでは200MHzで動作させています。ブートメモリ構成は、166MHzの場合でも、目的の構成でメモリを正常にテストします。 私が試した設定は、以下のデフォルト設定です。最初の「g_flash_config」は起動、書き込み、読み込みなどを成功させていますが、ソフトウェアには理想的ではありません。「g_flash_fast_config」が失敗します。 「fast_config」のDTRモードで、周波数を166MHz、133MHz、50MHz、30MHzに下げてみましたが、効果はありませんでした。 ブートメモリ構成から生成されたFCBを使用してみましたが、構造体のレイアウトにいくつかの違いがあり、PX4コードに適用するのが困難でした。 csHoldTime、csSetupTime、dataValidTimeのさまざまな組み合わせを試してみましたが、結果は得られませんでした。 低周波DTRオクタールでDQS内部を試してみましたが、うまくいきませんでした。 次に何を試せばいいでしょうか? #include /**************************************************************************** * Public Data ****************************************************************************/ locate_data(".boot_hdr.conf") const struct flexspi_nor_config_s g_flash_config = { .memConfig = { #if !defined(CONFIG_BOARD_BOOTLOADER_INVALID_FCB) .tag = FLEXSPI_CFG_BLK_TAG, #else .tag = 0xffffffffL, #endif .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 1, .csSetupTime = 1, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Generic, .waitTimeCfgCommands = 1, .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_1Pad, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 0}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read Dedicated 3Byte Address Read(0x03), 24bit address */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x03, RADDR_SDR, FLEXSPI_1PAD, 0x18), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_1PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0),//0xb3048b20 }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; const struct flexspi_nor_config_s g_flash_fast_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 3, .csSetupTime = 3, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Spi2Xpi, .waitTimeCfgCommands = 1, .deviceModeSeq = { .seqNum = 1, .seqId = 6, /* See Lookup table for more details */ .reserved = 0, }, .deviceModeArg = 2, /* Enable OPI DDR mode */ .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable) | (1u << kFlexSpiMiscOffset_DdrModeEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_8Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 10}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read */// EEH+11H+32bit addr+20dummy cycles+ 4Bytes read data /* Macronix manual says 20 dummy cycles @ 200Mhz, FlexSPI peripheral Operand value needs to be 2N in DDR mode hence 0x28 */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0xEE, CMD_DDR, FLEXSPI_8PAD, 0x11), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x28),//0xb3288b20, [0 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), //0xa704, /* Read status */ [4 * 2 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x05, CMD_DDR, FLEXSPI_8PAD, 0xfa), [4 * 2 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x04), [4 * 2 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), /* Write enable SPI *///06h [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00000406, /* Write enable OPI SPI *///06h [4 * 4 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x06, CMD_DDR, FLEXSPI_8PAD, 0xF9), /* Erase sector */ [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x21, CMD_DDR, FLEXSPI_8PAD, 0xDE), [4 * 5 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, STOP_EXE, FLEXSPI_1PAD, 0x00), /*Write Configuration Register 2 =01, Enable OPI DDR mode*/ //72H +32bit address + CR20x00000000 = 0x01 [4 * 6 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x72, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000472, [4 * 6 + 1] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000400, [4 * 6 + 2] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, WRITE_SDR, FLEXSPI_1PAD, 0x01),//0x20010400, /*Page program*/ [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x12, CMD_DDR, FLEXSPI_8PAD, 0xED),//0x87ed8712, [4 * 9 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, WRITE_DDR, FLEXSPI_8PAD, 0x04),//0xa3048b20, }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; Re: Flash configuration confusion RT1176 Octal DDR こんにちは、 @SimonHugr さん。 DDRモードを使用する場合は、バイトスワッピングの設定も考慮する必要があることにご注意ください。この記事では、DDRモードを使用する際にMX25UM51245GXDI00のバイトスワッピングを考慮することがなぜ重要なのかについての役立つ情報を提供します。 FCBを生成するにはBoot Memory Configurationを使うことを強くお勧めします。 Secure Provisioning Tool v26.6はそのMX25UM51245Gのテンプレートを提供しており、構成の良い出発点として役立ちます。また、ご存知かもしれませんが、このツールを使用すると設定をテストできます。 さらに、このコミュニティ投稿、特に15番目の手順から始まる部分を参照することをお勧めします。そのセクションでは、セキュアプロビジョニングツールがブートメモリ構成を生成する方法についてより詳細な説明を提供しており、ツールによって生成されるパラメータと出力の理解に役立つ可能性があります。 最後に、flexspi_nor_polling_transfer_cm7例を使って生成されたFCBを検証し、読み書き操作が正しく動作しているか確認してから起動設定を進めることができます。 BR ハビブ Re: Flash configuration confusion RT1176 Octal DDR 残念ながらまだ結果は出ていません。やはり何らかのデータ順序の入れ替えが行われているか、どこかで設定バイトが不足しているのではないかと考えています。 Re: Flash configuration confusion RT1176 Octal DDR マスミセイムさん、ありがとうございます。 確かに、例えばデータを入れ替える必要があることに気づきました。もう一度LUTを確認してみます。 Re: Flash configuration confusion RT1176 Octal DDR このスレッドを参照して:https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Internal-Boot-from-Flash-memory-not-starting-on-imxRT1176-custom/m-p/1830699 Zephyr RTOSの指示に従って、ミスオプションを編集してデータの順序を入れ替えるべき https://github.com/zephyrproject-rtos/hal_nxp/blob/3a36ee1f8b9fc2168fc0bf80377ace8298292993/mcux/mcux-sdk-ng/devices/RT/RT1170/MIMXRT1176/drivers/romapi/fsl_romapi.h#L340-L355 データスワップバイトは挿入されるのですが、何か見落としているような気がします。 .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .isDataOrderSwapped = true .serialNorType = 2, .reserve2[0] = 0x7008200, Re: Flash configuration confusion RT1176 Octal DDR やあ、 @SimonHugr 、 まず最初に確認したいのは、MX25UM51245GとMX25UM51345Gの実際の違いです。部品番号は非常によく似ていますが、それらは同一の機器ではありません。Macronixのデータシートによると、MX25UM51345GはDOPI(Double Transfer Rate OPI)バイトモードのデータシーケンスを明示的にサポートしていますが、MX25UM51245Gは別の製品バリアントに属しています。これにより、FlexSPIコントローラで使用されるコマンドフォーマット、バイト順序、LUT構成に影響を与えることがあります。 私の設定も比較できます。MX25UM513とMX25UW6345G: https://github.com/Masmiseim36/Coremark_iMXRT/blob/master/XiP/flexspi_flash_OSPI_Macronix.c よろしく

IMX95 { 15 x 15 } 是否支持 LPDDR4/4X 16 GB 内存 NXP团队您好， 我想了解一些关于 IMX95{ 15 x 15 } " MIMX9556CVTXN" 是否支持 16 GB RAM { LPDDR4/4X } "MT53E4G32D8GS-046 WT:C ?" 的一般信息。 我找不到将 16 GB RAM 连接到 IMX 95 { 15x 15} 的原理图参考资料。 我只找到了配备 16 GB RAM {LPDDR5} 的 imx95 { 19 x 19 } 的原理图。 请问能否帮我解决一下 16GB RAM{ LPDDR4/4x } 与 imx95{ 15 x 15 } 的连接问题（如果支持的话）？ 电路板支持包 文件呢？16 GB 内存的 DTS 文件是否存在，还是需要手动生成？ Yocto Project Re: Is IMX95 { 15 x 15 } supported LPDDR4/4X 16 GB RAM 嗨@Asadeds ， 感谢您联系恩智浦技术支持。 根据我们的内存兼容性指南，内存部件号 MT53E4G32D8GS-046 与 i.MX95 完全兼容，并且已在该平台上进行了彻底的验证和测试。 因此，按照推荐的配置和设计指南，该设备可以与 i.MX95 一起使用。 此致， 亚历杭德罗·加西亚

Is IMX95 { 15 x 15 } supported LPDDR4/4X 16 GB RAM Hi NXP Team,  I want some general Information about the IMX95{ 15 x 15 } "MIMX9556CVTXN" will support 16 GB of RAM { LPDDR4/4X } "MT53E4G32D8GS-046 WT:C ?" I could not able to find the reference of the schematic to connect the 16 GB RAM to IMX 95 { 15x 15}  ,  I only found the schematic of  imx95 { 19 x 19 } with the 16 GB RAM {LPDDR5}.  can you please help me out with connection of 16GB RAM{ LPDDR4/4x } with imx95{ 15 x 15 } if Supported. and What about the BSP file? , is DTS file present for the 16 GB of ram or need to generated manually.  Yocto Project Re: Is IMX95 { 15 x 15 } supported LPDDR4/4X 16 GB RAM Hi @Asadeds, Thank you for contacting NXP Support. According to our Memory Compatibility Guide, the memory part number MT53E4G32D8GS-046 is fully compatible with the i.MX95 and has been thoroughly validated and tested on this platform. Therefore, this device can be used with the i.MX95 following the recommended configuration and design guidelines. Best regards, Alejandro Garcia

Architectural Overview for the Dual-Motor EV Control System 1 Introduction After introducing the Dual-Motor EV Traction platform and the Software & Hardware environment behind it, this article moves one step closer to the running application. It looks inside the Motor Control System and explains how the Simulink model is structured to control two PMSM motors using the NXP S32K396 MCU as the target hardware. The goal is to provide a clear architectural view of the application before diving into simulation, validation, or deployment details. We will follow the main signal paths, from vehicle-level CAN commands and inverter feedback to FOC execution, PWM generation, ADC measurement, and communication back to the vehicle network. The focus remains intentionally architectural. Instead of covering controller tuning, peripheral configuration, or low-level implementation, this article highlights the building blocks that make the dual-motor application understandable as a complete embedded control system. This article is organized around five architectural views: the application overview, the system interfaces, the CAN communication path, the Simulink model structure, and the peripheral-to-data-flow mapping. Together, these views explain how the dual-motor application receives commands, measures feedback, executes control, drives the inverters, and reports diagnostic information back to the vehicle network.   2 Table of Contents • Introduction • Application Overview • System Inputs and Outputs • Vehicle-Level Communication • Simulink Application Architecture • Peripheral Mapping • Data Flow • Conclusion • References   3 Application Overview The Motor Control System is implemented on the NXP S32K396 microcontroller and runs as a single-core embedded application. The ECU controls two PMSMs, each connected to its own three-phase inverter stage. From a control perspective, the application contains two Field-Oriented Control implementations. Each FOC instance is responsible for one motor and executes independently, based on its own sensing path, control states, and output generation. Both control loops are scheduled from independent interrupt sources and are triggered every 100 microseconds. This execution period supports the fast current-control layer required by traction inverter applications, while the single-core implementation requires both motor-control paths to complete within the available timing budget.   Figure 3-1. Overall Simulink Application At vehicle level, the Motor Control System behaves as a actuating end node. It receives enable and speed commands from the Central Node over CAN and sends back monitoring and diagnostic information at a slower periodic rate. The Motor Control System exchanges CAN data with the vehicle network through the South Zone Controller. 3.1. Control Strategy At the heart of the application is the Field-Oriented Control algorithm, which provides the control structure required to drive each PMSM efficiently and independently. In this architecture, FOC transforms the three-phase motor behavior into a control problem handled in a rotating reference frame, where torque-producing and flux-producing current components are regulated separately. The control strategy is built around speed control. The requested speed comes from the vehicle-level command interface, while the estimated rotor speed is provided by the sensorless observer. The speed controller compares these values and generates the current reference needed to reach the commanded operating point. For each motor, the FOC structure combines an outer speed loop with inner current-control loops. The current PI controllers regulate the direct-axis and quadrature-axis currents in the rotating reference frame, allowing the application to control the electrical behavior of the motor in a deterministic and decoupled way. Sensorless operation is achieved using an Extended EMF Observer. This observer estimates the rotor position and speed from the measured electrical quantities, removing the need for a physical position sensor in the control loop. The estimated position is then used by the Park and inverse Park transformations that connect the stationary and rotating reference frames. The feedback path is based on phase-current reconstruction using the dual-shunt measurement method. The reconstructed phase currents are processed through the Clarke and Park transformations, while the DC bus voltage feedback is used to keep the control and modulation stages aware of the available inverter supply. The two FOC implementations follow the same control structure, but each one operates on its own motor-specific inputs, states, and outputs. This separation allows Motor 1 and Motor 2 to be controlled independently, even though both algorithms execute on the same S32K396 device. Because the control loops are executed every 100 microseconds, the FOC layer must remain compact and deterministic. The model architecture therefore separates the fast control path from slower communication and monitoring tasks, ensuring that current regulation and PWM update remain the highest-priority activities in the application.   Figure 3-2. Sensorless Field-Oriented Control diagram 4 System Inputs and Outputs The application interface can be viewed through two categories of signals. The first category contains vehicle-level commands exchanged over CAN. These signals define how the traction application is started, stopped, and commanded from the rest of the vehicle. The second category contains real-time electrical feedback and actuation signals exchanged with the inverter hardware.   Figure 4-1. Split the Simulink model to Inputs, Outputs and Application layers 4.1. Inputs The main vehicle-level inputs are received from the Central Node over CAN through the South Zone Controller. The command message contains the CCS_EnableMotors signal, used to engage or disengage the motors, and the CCS_SetSpeed signal, used to provide the desired speed reference for the control application.   Figure 4-2. CAN Message Unpack block for receiving the command signals   These CAN inputs are not part of the fast current-control loop, but they directly influence its behavior. Once decoded, the enable command defines whether the control logic is allowed to drive the inverters, while the speed reference becomes the target followed by the outer speed controller. The hardware feedback inputs are acquired from the inverter stages through ADC measurements. For each motor, two phase currents are measured using the dual-shunt method, while the third phase current is reconstructed in software using Kirchhoff’s Current Law. The DC bus voltage is measured for each inverter so the control, modulation, and monitoring logic remain aware of the available supply voltage.   Figure 4-3. Gathering analog quantities via ADC Block   4.2. Outputs The primary real-time outputs are the PWM commands used to actuate the inverter phases for both motors. The FOC algorithm computes the voltage commands required by each PMSM, and these commands are translated into duty cycles for the three-phase inverter. Because each inverter leg requires a high-side and a low-side control signal, the application ultimately drives six PWM signals per motor. These signals are generated from the MCU timing path and routed to the gate-driver stage that controls the external power switches.   Figure 4-4. PWM Actuation Subsystem   In addition to the PWM outputs, the application sends CAN data to the South Zone Controller every 0.1 seconds. These messages are intended for diagnostics, monitoring, and vehicle-level observability. The transmitted CAN data includes the estimated speed of each motor, the fault status reported by each control channel, the measured DC bus voltage for each inverter, the current operating state of each motor-control instance and many more. The following table highlights the output data sent over CAN bus:   Name Description Unit MC_BusVoltageM1 DC Bus Voltage measured by inverter for Motor 1 V MC_BusVoltageM2 DC Bus Voltage measured by inverter for Motor 2 V MC_FaultStatusM1 Fault status reported by Motor 1 true/false MC_FaultStatusM2 Fault status reported by Motor 2 true/false MC_PhACurrentM1 Phase A current – Motor 1 A MC_PhACurrentM2 Phase A current – Motor 2 A MC_PhBCurrentM1 Phase B current – Motor 1 A MC_PhBCurrentM2 Phase B current – Motor 2 A MC_PhCCurrentM1 Phase C current – Motor 1 A MC_PhCCurrentM2 Phase C current – Motor 2 A MC_SpeedEstM1 Motor 1 estimated speed rpm MC_SpeedEstM2 Motor 2 estimated speed rpm MC_SpeedRefM1 Motor 1 desired speed rpm MC_SpeedRefM2 Motor 2 desired speed rpm MCS_StateM1 Motor 1 state. It can be Stand By, Running, Fault - MCS_StateM2 Motor 2 state. It can be Stand By, Running, Fault - MCS_PhAVoltageM1 Phase A Voltage – Motor 1 V MCS_PhAVoltageM2 Phase A Voltage – Motor 2 V MCS_PhBVoltageM1 Phase B Voltage – Motor 1 V MCS_PhBVoltageM2 Phase B Voltage – Motor 2 V MCS_PhCVoltageM1 Phase C Voltage – Motor 1 V MCS_PhCVoltageM2 Phase C Voltage – Motor 2 V   Figure 3-5. Example for CAN Pack Message 5 Vehicle-Level Communication The Motor Control System is part of a distributed EV control architecture. It does not operate as an isolated controller. Instead, it receives high-level commands from the vehicle network and reports measured and estimated values back to the rest of the system. The communication path is organized around the CAN interface between the Central Node, the South Zone Controller, and the Motor Control System Node. Commands such as motor enable and desired speed are received through this path, while feedback messages such as estimated speed, DC bus voltage, phase-current information, and fault status are sent back through the same zonal communication route. CAN receive handling is interrupt-driven. When a command frame is received, the application decodes the enable and speed request signals and updates the internal command variables used by the Simulink control model. This keeps the command interface responsive without placing CAN processing inside the 100 microsecond FOC interrupt.   Figure 4-1. CAN Receive Interrupt block   CAN transmit handling is periodic. A PIT interrupt schedules outgoing monitoring messages every 0.1 seconds. This separates network reporting from the real-time control path and ensures that diagnostics transmission does not disturb the deterministic execution of the motor-control interrupts.   Figure 4-2. Periodic Interrupt for transmitting CAN messages   The CAN database defines the mapping between application variables and network messages. For example, the enable and speed command are grouped in dedicated message, while fault information, estimated speed, DC bus voltage, and phase-current feedback are exposed through dedicated monitoring messages. More information about the CAN database created for organizing the CAN messages and signals will be presented in a dedicated article. 6 Simulink Application Architecture The Simulink model is organized around a dual-control structure. Each motor channel contains the algorithmic blocks required to transform measured currents, estimate rotor position and speed, regulate the control loops, and generate voltage commands for PWM modulation. Although both channels implement the same FOC strategy, they are treated as separate execution paths. This separation makes it easier to scale from a single-motor setup to a dual-motor configuration and to validate each channel independently before running both motors together. 6.1. Real-Time Control Layer The real-time control layer is executed inside the BCTU-triggered interrupt flow. The BCTU is synchronized with the PWM timing generated by eMIOS, so the ADC conversions are requested at the correct moment within the switching period. Once the required current measurements are available, the interrupt allows the control algorithm to run using a coherent feedback set.   Figure 5-1. FOC Implementation   Inside this layer, the application reconstructs the three-phase current set, executes the Clarke and Park transformations, estimates rotor position and speed through the Extended EMF Observer, runs the speed and current PI controllers, and generates the voltage commands required by the modulation stage. The voltage commands are then translated into PWM duty cycles. eMIOS provides the base PWM generation, while the LCU forms the complementary high-side and low-side signals needed by the inverter legs. LCU also adds the necessary dead-time in complementary PWM signals to avoid the DC source damage. TRGMUX routes the required trigger signals between these peripherals, maintaining alignment between actuation and measurement.   Figure 5-2. Fast Loop Subsystem   The same execution concept is applied to the second motor channel. The two FOC instances run on the same S32K396 core, so the application depends on the MCU processing capability and on a carefully scheduled interrupt structure to complete both control paths within the available timing budget. 6.2. Communication and Monitoring Layer The communication and monitoring layer connects the fast control application with the vehicle network. It receives the enable and speed commands from CAN, prepares diagnostic information, and schedules outgoing status messages. This layer runs at a lower rate than the FOC loops. It is intended for command exchange, observability, and integration with the Central Node through the South Zone Controller. 6.3. Hardware Abstraction and Peripheral Layer The hardware abstraction and peripheral layer connects the generated Simulink application to the physical resources of the S32K396 MCU. Its purpose is to keep the control algorithm separated from the low-level hardware access, while still allowing the model to read measurements, update PWM outputs, handle interrupts, and exchange data over communication interfaces. In practice, this layer contains the target-specific blocks used for ADC acquisition, PWM generation, and CAN communication. These blocks provide the interface between the algorithmic part of the model and the peripherals configured on the MCU. This layer also makes the model easier to understand and maintain. The FOC subsystems can remain focused on control behavior, while the peripheral layer handles how signals enter and leave the MCU. As a result, the same architectural structure can be reused when moving between simulation, generated code, and target execution. The NXP Model-Based Design Toolbox provides the Simulink blocks that expose these S32K396 peripherals at model level. This allows engineers to configure and connect hardware-facing functions directly in Simulink, while the generated embedded code uses the corresponding target drivers and configuration. 7 Peripheral Mapping The peripheral mapping is centered on the synchronization between measurement, control execution, actuation, gate-driver communication, and vehicle-level CAN communication. Each peripheral has a specific role in this chain, and together they allow the generated Simulink application to interact deterministically with the inverter hardware. SAR-ADC is used to measure the analog quantities required by the control algorithm. These measurements include the phase-current feedback acquired from the inverter stages and the DC bus voltage used by the modulation and monitoring logic. BCTU (Body Cross Triggering Unit) performs the triggering of the ADC conversions. Instead of sampling the analog signals at an arbitrary moment, BCTU waits for the synchronization event coming from the PWM timing path and then starts the SARADC conversions at the correct point in the switching period. eMIOS (Enhanced Multiple Input Output System) generates the three phase PWM signals for each motor channel. These PWM signals represent the base timing generated from the duty cycles computed by the FOC algorithm. LCU (Logic Control Unit) takes the three PWM signals generated by eMIOS and creates the six PWM outputs required by the inverter. For each motor phase, it generates the complementary high-side and low-side control signals with dead-time insertion used to drive the corresponding inverter leg. TRGMUX provides the internal routing between peripherals. It connects the three PWM outputs from eMIOS to the LCU inputs and also routes the synchronization signal between eMIOS and BCTU. This routing keeps the actuation path and the measurement path aligned. LPSPI is used as the communication layer between the S32K396 controller and the MC33937 gate driver. Through this interface, the application can configure and exchange diagnostic information with the gate-driver device, complementing the direct PWM actuation path. FlexCAN provides the CAN communication controller used by the Motor Control System. It enables reception of command messages from the South Zone Controller and transmission of monitoring and diagnostic data back to the vehicle network. In this mapping, the fast motor-control path is formed by eMIOS, TRGMUX, BCTU, SARADC, and LCU, while LPSPI supports gate-driver interaction and FlexCAN supports vehicle-level communication. This separation helps keep the time-critical control loop independent from slower configuration, diagnostics, and network tasks.   Figure 6-1. Peripherals Mapping Overview   PIT (Periodic Interrupt Timer) peripheral is used for slower periodic activity, such as CAN diagnostics transmission every 0.1 seconds. CAN receive interrupts are used for incoming command messages from the South Zone Controller. 8 Data Flow The data flow starts at the vehicle network and at the analog feedback interface. CAN provides the high-level operating commands, while the inverter sensing path provides the real-time electrical feedback required by the FOC loops. When a CAN command is received, the enable and speed references are decoded and stored as application-level command variables. These signals are then consumed by the motor-control logic during the next control execution. In parallel, synchronized ADC conversions provide the latest phase-current and DC bus voltage values. The control algorithm reconstructs the motor currents, estimates rotor position and speed, transforms the feedback into the rotating reference frame, and computes the required voltage commands. The voltage commands are converted into PWM duty cycles and applied to the inverter actuation path. The resulting gate-drive signals control the external power stage, which drives the PMSM phases. At a slower rate, selected internal variables are packed into CAN monitoring frames. These values allow the South Zone Controller and Central Node to observe the Motor Control System state without interfering with the fast control-loop execution. 9 Conclusion This article described the architectural overview of the Dual-Motor EV Control System application. It presented the main Simulink model structure, the system inputs and outputs, the vehicle-level CAN communication path, the peripheral mapping, and the data flow between command reception, sensing, control, actuation, and monitoring. The architecture is built around two independent FOC control paths running on the S32K396 in a single-core configuration. Each motor channel receives synchronized analog feedback, executes its control algorithm every 100 microseconds, and generates the PWM outputs required by its inverter stage. By combining Model-Based design with target-specific peripheral integration, the application provides a scalable foundation for validating dual-motor traction behavior in simulation and on real hardware. The next article can build on this architecture by focusing on Model-in-the-Loop development and controller validation before deployment. 10 References Developing a Dual-Motor EV Control System with Model-Based Design Toolbox Software & Hardware Enablement for the Dual-Motor EV Control System Sensorless FOC with Motor Control Blockset Extended EMF Observer – Motor Control Blockset NXP Model-Based Design Toolbox for S32K3 NXP S32K396 microcontroller documentation AN14481: MCSPTR2AK396 3-phase PMSM Motor Control Kit with S32K396 Application Note

Unable to Run RT1180 EVK SDK Examples on RIOP RT1189 Board Hi Everyone, I am working with the RIOP RT1189 board and have a few questions regarding software compatibility and debugging. Initially, I successfully programmed the RIOP demo application using the Secure Provisioning Tool in Serial Download Mode, and the demo is working as expected. After that, I tried to run the MIMXRT1180 EVK SDK example projects (for example, the LED Blinky example) on the RIOP RT1189 board. What I tried Modified the LED pin configuration in the RT1180 EVK LED Blinky example to match the RIOP RT1189 board. Programmed the image using the Secure Provisioning Tool in Serial Download Mode. However, the application does not run on the RIOP board. To verify the hardware, I took the working RIOP demo project, commented out most of the demo functionality, added only the LED Blinky code, and programmed it again. In this case, the LED Blinky works correctly. This makes me think there are additional board-specific configurations in the RIOP demo that are required beyond simply changing the LED GPIO pin. Questions Can the MIMXRT1180 EVK SDK example projects be used directly on the RIOP RT1189 board? If not, what board-specific modifications are required (clock configuration, memory configuration, FlexSPI, linker script, startup code, etc.) to make the SDK examples work on the RIOP board? Debugging Issue I also tried to debug the demo application using MCU-Link, but the debugger fails during flash initialization with the following error: Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfx Image 'iMXRT1180_SFDP_FlexSPI1_A_QSPI Jun 26 2025 18:32:16' Opening flash driver MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfx VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Using SOFT reset to run the flash driver Driver V.2 dynamic startup failed - driver Init provided no flash parameters Flash Driver V.2 startup failed - rc Ef(55): Dynamic flash driver startup failed to provide flash parameters. Terminate (0x0, 0x0, 0x0) status 0x40 - driver reports init failure - EXTSPIJ driver rc 20107 (0x4E8B) chip initialization failed - Ef(55): Dynamic flash driver startup failed to provide flash parameters. failed to initialize flash driver MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfx Could this error indicate that the RT1180 EVK flash driver is incompatible with the external flash used on the RIOP RT1189 board, or is there an additional flash configuration that needs to be provided for debugging? Any guidance or suggestions would be greatly appreciated. Thank you!

LPC-Link2のシリアル番号の一貫性について 複数のLPC-Link2チップのシリアル番号が同一である場合、それらのシリアル番号を変更する方法を教えていただきたいです。よろしくお願いいたします。 Re: 关于lpc-link2 SN码一致 こんにちは@chenwe97 このシリアル番号は変更できません。 複数のLPC-LINK2デバイスを同時に接続する場合は、CMSIS-DAPファームウェアにアップデートすることをお勧めします。これにより、各デバッガに固有のID番号が割り当てられます。 BR アリス

RIOP RT1189ボード上でRT1180 EVK SDKの例を実行できない こんにちは、皆さん 私はRIOP RT1189ボードを使っており、ソフトウェアの互換性やデバッグについていくつか質問があります。 最初は、シリアルダウンロードモードでSecure Provisioning Toolを使ってRIPデモアプリケーションを無事にプログラムでき、デモは期待通りに動作しています。 その後、MIMXRT1180 EVK SDKの例プロジェクト(例えばLED Blinkyの例)をRIOP RT1189ボード上で実行しようとしました。 私が試したこと RT1180 EVK LED点滅サンプルにおけるLEDピン配置を、RIOP RT1189ボードに合わせて変更しました。 セキュアプロビジョニングツールをシリアルダウンロードモードで使用してイメージをプログラムしました。 ただし、このアプリケーションはRIOPボード上で動作しません。 ハードウェアを検証するために、動作確認済みのRIOPデモプロジェクトを入手し、デモ機能のほとんどをコメントアウトし、LED点滅コードのみを追加して、再度プログラムを書き込んだ。この場合、LEDブリンキーは正常に動作します。 このことから、RIOPデモには、LEDのGPIOピンを変更する以外にも、ボード固有の設定がいくつか必要になるのではないかと考えています。 質問 MIMXRT1180 EVK SDKのサンプルプロジェクトはRIOP RT1189ボード上で直接使用できますか? もしそうでなければ、RIPボード上でSDKの例を動作させるために、どんなボード固有の変更(クロック設定、メモリ設定、FlexSPI、リンカースクリプト、スタートアップコードなど)が必要ですか? デバッグの問題 また、MCU-Linkを使ってデモアプリケーションのデバッグも試みましたが、フラッシュ初期化中にデバッガが以下のエラーで失敗しました。 SPI上でSVDP JEDEX ID MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfxを使ってv.2外部フラッシュデバイスを検査しました 画像『iMXRT1180_SFDP_FlexSPI1_A_QSPI 2025年6月26日 18:32:16』 フラッシュドライバーの開MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfx VECTRESETが要求されましたが、ARMv8-M CPUではサポートされていません。代わりにソフトリセットを使用してください。 フラッシュドライバを動かすためのソフトリセット ドライバV.2の動的起動失敗 - ドライバのInitがフラッシュパラメータを提供しませんでした Flash ドライバ V.2の起動失敗 - rc Ef(55): 動的フラッシュドライバの起動がフラッシュパラメータを提供できませんでした。 終了(0x0、0x0、0x0)ステータス0x40 - ドライバーがinit失敗を報告 - EXTSPIJドライバーrc 20107(0x4E8B) チップ初期化失敗 - Ef(55): 動的フラッシュドライバー起動時にフラッシュパラメータが提供されませんでした。 フラッシュドライバーの初期化に失敗MIMXRT1180_SFDP_FlexSPI1_A_QSPI.cfx このエラーは、RT1180 EVKフラッシュドライバーがRIOP RT1189ボードで使用されている外部フラッシュと互換性がないことを示唆しているのでしょうか?それともデバッグのために追加のフラッシュ構成が必要でしょうか? 何かご助言やご提案があれば、大変ありがたく思います。 ご回答をお待ちしています。