Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
LX2160ARDB 默认启动映像 您好, 请问有人知道如何获取 LX2160A-RDB-B 开发板使用的默认启动映像吗? 评估板 Re: LX2160ARDB Default boot images 您可以使用最新的Layerscape Yocto BSP v26.06。 以下预编译镜像托管在https://www.nxp.com/lgfiles/llsdk/walnascar/ 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img LX2160ARDB eMMC 启动的 电路板支持包。 固件映像 15 firmware_lx2160ardb-rev2_uboot_sdboot.img LX2160ARDB SD 启动 的 电路板支持包 固件映像 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img LX2160ARDB xSPI 启动的 电路板支持包 固件映像 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfs 支持 LX2160ARDB 上的基本网络功能 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfs 在 LX2160ARDB 上支持完整的网络功能 25 弹性安装程序 部署工具 4 boot_lx2160ardb-rev2_lts_6.12.tgz LX2160ARDB 的启动分区映像 Layerscape Yocto软件开发工具包用户指南: UG10374.pdf Layerscape Linux SDK 用户指南: UG10381.pdf
查看全文
PN7642 SPI 控制器接口 PN7642 文档和 PN7642.h 文件中提到了 SPI 控制器接口。以及在 OM27642EVK(作为 SPIM)上,但仅此而已。 我找不到该SPI控制器的示例或驱动程序(我指的不是主机SPI)。AI搜索显示有特定的SPI函数调用,例如phhalSpi.h和phhalSpi.c,但我找不到任何类似的内容。 它存在吗?我该如何找到它? 感谢您的帮助。 Re: PN7642 SPI controller interface 您好,感谢您对我们产品的关注。 PN7642 确实提供了一套 SDK 示例。我不确定你是否已经导入了其中一些。       如您所见,您可以直接从“快速入门”面板 -> “导入 SDK 示例”导入示例,然后搜索 SPI,如图所示。 请注意,OM27642EVK 具有从动引脚和引导引脚。另请参阅快速入门指南文档的第 7 部分。
查看全文
如何在 i.MX 8QuadXPlus / i.MX 8DualXPlus 上测试边带 ECC 错误注入? 您好,NXP团队, 我正在测试 i.MX 8QuadXPlus / i.MX 8DualXPlus 平台上的 DDR 边带 ECC 功能,该平台具有 40 位 DDR3L 接口(32 位数据 + 8 位 ECC)。 根据 AN13566,可以通过 ECC_REGION_PARITY_LOCK 解锁 ECC 奇偶校验区域并修改 ECC 奇偶校验位来注入内联 ECC 错误。然而,我找不到关于边带 ECC 的详细错误注入或验证程序。 AN13566 提到边带 ECC 使用额外的 ECC 字节,并且控制器在 DDR 读取期间检查此字节。它还提到,边带 ECC 在检测到可纠正的单比特错误后,支持自动清除 RMW 操作。 请问测试边带ECC的推荐方法是什么? 边带ECC是否有硬件错误注入或数据投毒寄存器? 软件如何注入一个可纠正的单比特错误? 软件如何注入双比特不可纠正错误? 应该检查哪些ECC状态寄存器和中断信号? 如何验证边带 ECC 纠错操作是否已纠正数据并将其写回? 是否有示例代码、测试步骤或DDR控制器寄存器序列可供参考? 我们的配置如下: SoC:i.MX 8 QuadXPlus / i.MX 8 DualXPlus DDR类型:DDR3L DDR接口:40位、32位数据+8位ECC 谢谢。 Re: How to test Sideband ECC error injection on i.MX 8QuadXPlus / i.MX 8DualXPlus? 嗨@kkfly 您可以参考 IMX8DXL RM 文档中的 ECC 寄存器描述。 https://www.nxp.com/products/iMX8XLite 具体而言,是ECC 配置寄存器 0 (ECCCFG0)和ECC 配置寄存器 1 (ECCCFG1)寄存器。 BR Re: How to test Sideband ECC error injection on i.MX 8QuadXPlus / i.MX 8DualXPlus? 文档中写道:“注意:此SoC不支持ECC数据投毒。”请确保此位设置为 0。那么,这是否意味着 IMX8DXL 和 IMX8QXP 不支持 ECC 错误注入?
查看全文
How to test Sideband ECC error injection on i.MX 8QuadXPlus / i.MX 8DualXPlus? Hello NXP team, I am testing the DDR Sideband ECC functionality on an i.MX 8QuadXPlus / i.MX 8DualXPlus platform with a 40-bit DDR3L interface (32-bit data + 8-bit ECC). According to AN13566, Inline ECC errors can be injected by unlocking the ECC parity region through ECC_REGION_PARITY_LOCK and modifying the ECC parity bits. However, I could not find a detailed error-injection or validation procedure for Sideband ECC. AN13566 mentions that Sideband ECC uses an additional ECC byte and that the controller checks this byte during DDR reads. It also mentions that Sideband ECC supports an automatic scrub RMW operation after detecting a correctable single-bit error. Could you please clarify the recommended method to test Sideband ECC? Is there a hardware error-injection or data-poisoning register for Sideband ECC? How can software inject a single-bit correctable error? How can software inject a double-bit uncorrectable error? Which ECC status registers and interrupt signals should be checked? How can we verify that the Sideband ECC scrub operation has corrected and written back the data? Is there any example code, test procedure, or DDR controller register sequence available? Our configuration is: SoC: i.MX 8QuadXPlus / i.MX 8DualXPlus DDR type: DDR3L DDR interface: 40-bit, 32-bit data + 8-bit ECC Thanks. Re: How to test Sideband ECC error injection on i.MX 8QuadXPlus / i.MX 8DualXPlus? Hi @kkfly  You can refer to the description of the ECC register in the IMX8DXL RM documentation. https://www.nxp.com/products/iMX8XLite In particular, the ECC Configuration Register 0 (ECCCFG0) and ECC Configuration Register 1 (ECCCFG1) registers. B.R Re: How to test Sideband ECC error injection on i.MX 8QuadXPlus / i.MX 8DualXPlus? The doc says 'NOTE: ECC data poisoning is not supported in this SoC. Please ensure this bit setting is 0.' So does that mean the IMX8DXL and IMX8QXP don't support ECC error injection?
查看全文
AEC-Q100 MFS2613HMDA2AD 是否符合 AEC-Q100 标准?所有 FS26 零件编号都符合 AEC-Q100 标准吗? 谢谢, 恩里科 Re: AEC-Q100 你好 ESof 再会! 是的,整个 FS26 系列产品均符合 AEC-Q100 标准。证明这一点的文件属于机密文件,因此如果您需要该文件,我建议您直接与我们联系,看看我们能做些什么并开始签署保密协议的流程。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 由此给您带来的不便,我们深表歉意。 祝你今天过得愉快,一切顺利。
查看全文
IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hello,     we are bringing up Bluetooth on a Verdin i.MX95 WB running the NXP Android 15 BSP (Linux 6.6.58). The onboard wireless module is a u-blox MAYA-W260 based on NXP IW612. Wi-Fi works correctly over SDIO, and the combo firmware is successfully loaded: Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active ,Bluetooth instead does not appear to work. Whenever we enable it on Android settings, the UI switch is frozen and no BT device is found. Bluetooth is connected to LPUART6 (/dev/ttyLP5). The NXP vendor HAL opens the UART successfully. We initially found that hardware flow control blocked transmission; after temporarily disabling CRTSCTS, the HAL sends the four-byte HCI Reset command: 01 03 0c 00 The UART counters then show: tx:4 rx:0 No response is received from the IW612. The same result occurs with a direct manual UART test at 115200 baud, 8N1, without hardware flow control. Our current configuration is: mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fw is left disabled because the combo firmware is already downloaded by the Wi-Fi driver. Could you please clarify: After loading sduart_nw61x_v1.bin.se through SDIO, should the IW612 Bluetooth UART respond directly to an HCI Reset at 115200 baud? Is a boot-sleep trigger, wake command, vendor command, or another initialization sequence required first? Is hardware flow control mandatory for IW612, and what should the expected CTS state be after firmware initialization? Should we use the UART firmware-download path with uartspi_n61x_v1.bin.se instead of relying on the combo firmware loaded by Wi-Fi? Is there a recommended bt_vendor.conf for IW612 on i.MX95? Any reference configuration or expected UART trace would be very helpful. Best regards. Android Linux Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  1. After loading sduart_nw61x_v1.bin.se through SDIO, should IW612 Bluetooth UART respond directly to HCI Reset at 115200? In principle, yes — once the combo firmware is active and the BT UART block is awake/ready, the controller should respond to HCI Reset with a Command Complete event. 2. Is a boot-sleep trigger, wake command, vendor command, or other initialization sequence required first? For normal Android bring-up, do not rely only on manually sending HCI Reset. Let the NXP vendor HAL or NXP UART driver perform the initialization sequence. 3. Is hardware flow control mandatory for IW612? What should CTS state be? For a production IW612 BT UART design, hardware flow control should be enabled and correctly wired. Disabling CRTSCTS is useful only as a diagnostic step; it should not be considered the final fix. 4. Should we use uartspi_n61x_v1.bin.se instead of combo firmware loaded by Wi-Fi? You  can have a try with the seperate FW to debug the issue, but it should not the root cause. With combo FW, should also work as expected. 5.Let me have a try on my local side then share to you a worked on my side conf file to you. Please allow me some time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  How is your side? I took some time to prepare the environment to build Android 16 source code. Now I can build it, it will need some time to finish building, please allow me some more time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  Sorry for my late reply and thanks for your patience. I already finished the local test on my side, and now IW612 can work fine on my I.MX95-19*19-EVK. Because there is no Verdin board,I use I.MX95-19*19-EVK to finish the test. Below is the bt_vendor.conf screenshot and also you can see BT can work fine on the right side. In fact, I just use the default bt_vendor.conf and do not modify anything in it. Hope it can help you somehow. If it still could not work on your side, please help to provide me your dts and also dmesg logs for further checking. Because here, the community is a public place, to save your security info, you can send your dts file to my private working email: [email protected].  Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  Did you get any chance to read my above comment? How is it going on your side? Please let me know if need any further info from my side. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  How is it going on your side? Please let me know if need any further info from my side. Best regards, Christine.
查看全文
LX2160ARDB Default boot images Hi, Can anyone please suggest a way to get the default boot images been used in LX2160A-RDB-B board. Evaluation Board Re: LX2160ARDB Default boot images You could use the latest Layerscape Yocto BSP v26.06 The following precompiled images are hosted on https://www.nxp.com/lgfiles/llsdk/walnascar/ > 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img BSP firmware image for LX2160ARDB eMMC boot 15 firmware_lx2160ardb-rev2_uboot_sdboot.img BSP firmware image for LX2160ARDB SD boot 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img BSP firmware image for LX2160ARDB xSPI boot 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfs supports basic networking functionality on LX2160ARDB 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfs supports full networking functionality on LX2160ARDB 25 flex-installer Deploy tools 4 boot_lx2160ardb-rev2_lts_6.12.tgz Bootpartition image for LX2160ARDB Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf
查看全文
PN7642 SPI controller interface SPI controller interface is mentioned in the PN7642 documents and PN7642.h, as well as on OM27642EVK (as SPIM) but that's all. I can't find an example or driver for that SPI controller (I don't mean Host SPI). AI search says that there are specific SPI function calls ,phhalSpi.h ,phhalSpi.c. , but I can't find anything even similar. Does it exist and how can I find it? Thanks for the help. Re: PN7642 SPI controller interface Hello, thank you for your interest in our products. PN7642 does have a set of SDK examples. I'm not sure if you have already imported some of them.       As you are able to see, you can just import the examples from the Quick Start panel -> Import SDK examples and search for the SPI as shown in the image. Please keep in mind that OM27642EVK has Follower Pins and Leader Pins. Please also mind section 7 of the Quick Start Guide documentation.
查看全文
[S32G3]LLCECANのCan_SharedMemoryワード0で異常値が発生しました。 NXPのエキスパートの皆様、こんにちは。 私たちのプロジェクトにおけるLLCE CAN 機能に異常がありました。時折、送信は正常なのにECUから報告された特定のCANメッセージの受信に問題が起きました。デバッグの結果、CAN割り込みは通常通りトリガーできることが判明しましたが、u32Word0の読み取りはCan_SharedMemoryから0x18008から0x1800fに変わり、異常な値でした。計算されたu32MbMessageIdは0でした。これによりメッセージが失われました。 RxMbDescIdxには値があり、変化していました。また、word1は0になることもありましたが、これも変化していました。この状況は断続的に起こり、影響を受けたCANラインもランダムでした。 この状況の分析にご協力ください。デバッグ用のスクリーンショットを以下に添付します。次のデバッグ手順はどのように進めればよいでしょうか?あるいは、どのような解決策がありますか? LLCEのバージョンは1.0.10です。 。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe お問い合わせいただきありがとうございます。 もう少し詳しく教えていただけますか? 1. あなたはどのバージョンのRTDを使用していますか? 2. 自分でボードやソフトウェアを使っていますか? BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe   承知いたしました。ご質問の優先順位を上げさせていただきます! 1. 受け取ったCANフレームは外部デバイスから来たものか、それともCANoeデバイスからのものか教えていただけますか?受信はCANフレームですか、それともCANFDフレームですか? 2. 設定されたボーレートは何ですか?どのポートを使用していますか? 3.フレームは内部コアで処理されますか、それともCAN2CAN経由でルーティングされますか? BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. NXPのエキスパートの皆様、こんにちは。 情報同期:異常な状況では、Can_Llce_GetControllerModeを通じてコントローラーの状態を「スタート」と読み取り、Can_43_LLCE_SetControllerModeインターフェースを通じて「停止>開始」の切り替えを実行します。異常なCANは回復可能です。word0の値から判断すると、LLCEの内部DTEカーネルが共有メモリにデータを転送する際にエラーが発生したようです。 現在、異常発生確率は依然として約20 %-30%とかなり高い。当チームは関連する秘密保持契約書に署名済みです。この問題の処理を優先していただけますか? Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ お返事ありがとうございます。この問題は、デバッグコードを追加する前に発生していました。具体的な原因を確認するために、デバッグコードを追加しました。デバッグコードは、特定の状態を読み取るだけです。共有メモリの値が異常なようです。パッチが提供されました。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 Can_Llce_ProcessRxMbに何らかの変更を加えたようですね。変更前に何か問題はありましたか?修正されたコードを教えてもらえますか? BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ 1.バスの乗車率は40%から50%の間で、それほど高いとは言えない。 2. BCAN_RXFIFO_OVERRUNは異常な状況下で発生していますが、正常動作時にもこの通知を確認しています。 3. 現在、LLCEにはルーティング機能は有効になっていません。ホストにデータを転送するだけです。使用されるフレームのほとんどはCAN FDであり、少数のCANフレームも存在します。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe 情報提供ありがとうございます。 問題に直面したシナリオ 1.In、CANバスのバス負荷はどれくらいでしたか?バスの乗車人数は多すぎますか? 2.フレーム損失が発生した場合、通知にはエラーが表示されますか?エラーメッセージが表示された場合は、私にお知らせください。 3. エラーはいつ発生しますか?ルーティング処理中ですか、それともフレームがホストに送信されるときですか?使われているのはCANフレームですか、それともCAN FDフレームですか? BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe 1.バス負荷を軽減するテストを行い、問題のあるフレームの頻度が減少するかどうかを観察します。 2.また、画像に示されているパラメータの数値を増やしてみてください。 BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ お返事ありがとうございます。負荷率を下げて、再度テストを実施します。2つ目の点として挙げられたMBサイズについてですが、20から300に増やしてみましたが、それでも異常が見られました。 さらに、LLCEには共有メモリの処理に関する内部ロジックがあるかどうかご存知ですか?「word0」フィールドに異常値が発生するのはどのような状況下でしょうか?例えば、「word1」の値が「word0」に書き込まれる場合。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ 1.受信したCANフレームは外部ECUから送信されました。現在、この異常はCANOE装置を用いたシミュレーションにより、試験台上で再現されている。実際には、どちらの状況でも異常事態が発生している。受信メッセージの大部分はCANFDフレームであり、少数はCANフレームです。 2. アービトレーションセグメントのボーレートは500k、データセグメントは2M、サンプリングレートは80%に設定されます。コントローラはBCAN1-BACN5を使用しています。 3. フレームは内部コアによって処理されます。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe 詳細な情報を提供していただきありがとうございます。 皆さんは受信フレーム操作にBCAN1-BACN5を使用していますか? 私はあなたと同じバージョンのLLCEと設定を使用して1つのポートで受信テストを行いましたが、あなたと同様のエラーは発生しませんでした。 BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ 主にBCAN1〜BCAN3を使ってほとんどのアプリケーションメッセージフレームを受け取ります。BCAN4は現在、データの送受信に対応していません。BCAN5は内部バスにコネクテッドされ、少数のメッセージを送信します。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ 助けてくれてありがとう。この事件は完了しました。追跡番号は00997151です。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe 下記のリンクからケースを作成してください。 https://support.nxp.com この問題については、関連するCASE情報を記入してください。ソフトウェアチームやLLCEの専門家に内部チャネルを通じて連絡するお手伝いをいたします。 BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe 以前のテストによると。 CANバスロードを減らして単一のCANチャネルを使うことには問題が起きませんか? BR ジョーイ Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、ジョーイ 現地のサポートや中国のオンラインサポートのために、現地のFAE(フィールドアプリケーションエンジニア)に連絡するのが都合が良いかお伺いしてもよろしいでしょうか?これは問題をより迅速に解決するのに役立つと思います。
查看全文
AEC-Q100 MFS2613HMDA2ADはAEC-Q100規格に適合していますか?FS26のすべての部品番号はAEC-Q100規格に適合していますか? ありがとう、 エンリコ Re: AEC-Q100 こんにちはESof 良い一日! はい、FS26ファミリ全体がAEC-Q100の資格を持っています。これを証明するドキュメントは機密扱いなので、必要なら直接私たちにケースを開いて、何ができるか確認し、NDAの手続きを開始することをお勧めします。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 ご迷惑をおかけして申し訳ございません。 良い一日をお過ごしください。幸運を祈ります。
查看全文
[S32G3]LLCECAN 的 Can_SharedMemory 字 0 中出现了异常值。 各位NXP专家,大家好! 我们的项目中,S32G399A 的 LLCE 罐功能使用出现了异常。有时,ECU 报告的某个 CAN 消息接收出现问题,而变速箱运行正常。经过调试,发现 CAN 中断可以正常触发,但是从 Can_SharedMemory 读取的 u32Word0 从 0x18008 变为 0x1800f,这是一个异常值。计算出的 u32MbMessageId 为 0。这导致消息丢失。 RxMbDescIdx 有一个值并且正在变化,word1 有时为 0,但也在变化。这种情况偶有发生,受影响的 CAN 总线也是随机的。 请帮忙分析一下这个问题,调试截图如下。我应该如何进行下一步的调试?或者有哪些解决方案? LLCE 版本为:1.0.10 。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 感谢您与我们联系。 您能提供更多信息吗? 1. 您使用的是哪个版本的RTD? 2.你们使用的是自己的电路板和自己的软件吗? BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 各位NXP专家,大家好! 同步信息:在异常情况下,我们通过 Can_Llce_GetControllerMode 读取控制器状态为“启动”,然后通过 Can_43_LLCE_SetControllerMode 接口执行“停止->启动”转换。异常的CAN可以恢复。从 word0 的值来看,LLCE 的内部 DTE 内核在向共享内存传输数据时似乎出现了错误。 目前,异常概率仍然相当高,约为 20 %-30% 。我方团队已签署相关保密协议文件。请优先处理这个问题好吗? Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe   好的,我们会提高您问题的优先级! 1.请问您收到的 CAN 帧是来自外部设备还是来自 CANoe 设备本身?它接收到的是 CAN 帧还是 CANFD 帧? 2.设定的波特率是多少?你使用的是哪个端口? 3.帧是由内部核心处理还是通过 CAN2CAN 路由处理? BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,canhe 您似乎对 Can_Llce_ProcessRxMb 进行了一些修改。在修改之前,您是否遇到过任何问题?能否分享一下修改后的代码? BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 感谢你的回复。这个问题在我添加调试代码之前就出现了。我添加了调试代码以确认具体原因。调试代码只是读取某些状态。共享内存的值似乎异常。补丁已提供给您。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 谢谢你提供的信息。 1.在您遇到问题的情况下,CAN总线的总线负载是多少?公交车载客量是否过高? 2.当发生丢帧时,通知是否会报告任何错误?如果您收到任何错误信息,请与我分享。 3.错误发生在路由过程中还是帧发送到主机时?使用的是 CAN 还是 CAN FD 机架? BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 1.总线载荷率在 40% 到 50% 之间,这似乎不是很高。 2. BCAN_RXFIFO_OVERRUN 是在异常情况下发生的,但我在正常操作期间也观察到了此通知。 3. 目前,LLCE 尚未启用路由功能;它仅将数据转发到主机。大部分帧使用 CAN FD 格式,少量使用 CAN 格式帧。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 感谢你的回复。我将降低负载率并再次进行测试。关于您提到的第二点,即 MB 大小,我已经尝试将其从 20 增加到 300,但仍然出现异常。 此外,您是否了解 LLCE 在处理共享内存方面是否有任何内部逻辑?在什么情况下“word0”字段会出现异常值?例如,如果将“word1”的值写入“word0”。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 1.接收到的 CAN 帧源自外部 ECU。目前,已使用 CANOE 设备在测试台上进行模拟,重现了该异常情况。事实上,这两种情况下都出现了异常情况。接收到的消息大部分是 CANFD 帧,只有少量是 CAN 帧。 2. 仲裁段的波特率设置为 500k,数据段的波特率设置为 2M,采样率为 80%。控制器使用 BCAN1-BACN5。 3. 这些帧由内部核心进行处理。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 1.测试降低总线负载,观察问题帧的频率是否降低。 2.另外,尝试增加图中所示参数的数值。 BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 感谢您提供详细信息。 你们都使用 BCAN1-BACN5 执行接收帧操作吗? 我在接收测试中,使用与你相同版本的 LLCE 和相同的配置,在一个端口上进行测试,并没有遇到与你类似的错误。 BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 我们主要使用 BCAN1-BCAN3 来接收大部分应用程序消息帧。BCAN4目前不具备发送或接收数据的功能。BCAN5 连接到内部总线,并传输少量消息。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 请尝试通过以下链接创建案例。 https://support.nxp.com 关于这个问题,请填写相关的案例信息,我会通过内部渠道帮您联系软件团队和 LLCE 专家。 BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 请问您是否方便联系当地的现场应用工程师(FAE)以获得中国境内的现场支持或在线支持?我认为这有助于我们更快地解决问题。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 根据之前的测试结果。 降低 CAN 总线负载并使用单个 CAN 通道会给您带来任何问题吗? BR 乔伊 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨,乔伊 感谢您的帮助。我已经结案了。追踪号码为:00997151。
查看全文
[S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi NXP Experts, There was an abnormality in the use of the LLCE can function of the S32G399A in our project. Occasionally, there was an issue with the reception of a certain CAN message reported by the ECU, while the transmission was normal. After debugging, it was found that the can interrupt could be triggered normally, but the u32Word0 read from Can_SharedMemory changed from 0x18008 to 0x1800f, which was an abnormal value. The calculated u32MbMessageId was 0.This led to message loss. The RxMbDescIdx had a value and was changing, and word1 sometimes was 0 but was also changing. This situation occurred sporadically, and the affected CAN line was also random. Please help analyze this situation,The debugging screenshots are provided below. How should I proceed with the next debugging steps, or what solutions are there? The LLCE version is: 1.0.10 . Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey_z Yes, we use our own boards and software. We employ LLCE in the M core and have integrated the MICROSAR com protocol stack of vector. RTD version:RTD_4.4_5.0.0_QLP03 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Thank you for contacting us. Could you tell us more information? 1. Which version of RTD are you using? 2.Are you using your own boards and your own software? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi NXP Experts, Syncing the information: In an abnormal situation, we read the controller status through Can_Llce_GetControllerMode as "start", and then executed a "stop->start" transition through the Can_43_LLCE_SetControllerMode interface. The abnormal CAN can recover. From the value of word0, it seems that there was an error in the internal DTE kernel of LLCE when transferring data to the shared memory. Currently, the abnormality probability is still quite high at around 20%-30%. Our team has signed the relevant NDA documents. Could you please prioritize the handling of this issue? Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe   Ok, we will raise the priority of your questions! 1.Could you please tell me whether the CAN frames you received originated from an external device or from such the CANoe device? Is it receiving CAN or CANFD frame? 2.What is the set baud rate? Which port are you using? 3.is the frame be processed by the internal core or routed via CAN2CAN? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe It seems that you have made some changes to Can_Llce_ProcessRxMb. Did you have any issues before the changes were made? Could you share the modified code? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey Thank you for your reply. This issue occurred before I added the debugging code. I added the debugging code to confirm the specific cause. The debugging code merely reads certain states. It seems that the value of the shared memory is abnormal. The patch has been provided to you. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Thank you for your information. 1.In the scenarios where you encountered problems, what was the Busload of the CAN bus? Is the Busload too high? 2.When frame loss occurs, does the Notification report any errors? If you have any error messages, please share them with me. 3.When does the error occur - during the Routing process or when the frame is sent to the Host? Is it CAN or CAN FD frame that is being used? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey 1. The bus load rate is between 40% and 50%, which doesn't seem very high. 2. BCAN_RXFIFO_OVERRUN has occurred under abnormal conditions, but I also observe this notification during normal operation. 3. Currently, LLCE does not have routing functionality enabled; it only forwards data to the host. Most frames used are CAN FD, with a small number of CAN frames. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey Thank you for your reply. I will reduce the load rate and conduct the test again. Regarding the second point you mentioned about the MB size, I have tried increasing it from 20 to 300, but there were still abnormalities. Furthermore, do you know if LLCE has any internal logic regarding the handling of shared memory? Under what circumstances would an abnormal value occur for the "word0" field? For instance, if the value of "word1" is written to "word0". Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe 1.Test to reduce the bus load and observe whether the frequency of the problematic frames decreases. 2.Also, try to increase the number in the parameters shown in the picture. BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey 1. The received CAN frames originated from the external ECU. Currently, the abnormality is replicated in the test bench using the CANOE device for simulation. In reality, the abnormality has occurred in both situations. The majority of the received messages are CANFD frames, while a small number are CAN frames. 2. The baud rate is set at 500k for the arbitration segment, 2M for the data segment, and 80% for the sampling rate. The controller uses BCAN1-BACN5. 3. The frames are processed by the internal core. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Thank you for your detail information. Are all of you using BCAN1-BACN5 to perform the receiving frame operation? I use the same version of LLCE and the same configuration as yours in a receiving testing on one port, and not encounter the similar error as yours. BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey We mainly use BCAN1-BCAN3 to receive most of the application message frames. BCAN4 is currently not capable of sending or receiving data. BCAN5 is connected to the internal bus and transmits a small number of messages. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe According to the previous tests. Will reducing the CAN busload and using a single CAN channel cause any problems for you? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey Thank you for your help. I have completed this case. The tracking number is: 00997151. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey Could I kindly ask if it's convenient for you to contact the local FAE (Field Application Engineer) for on-site support or online support in China? I think this would help us solve the problem more quickly. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Please try to create a case through the link below. https://support.nxp.com Regarding this issue, please fill in the relevant case information, I will help you contact the software team and LLCE experts through internal channels. BR Joey
查看全文
コンボファームウェアのダウンロード後、i.MX95でIW612 Bluetooth UARTが応答しない こんにちは、 Verdin i.MX95 WBでNXP Android 15 BSP(Linux 6.6.58)を搭載した上でBluetoothを起動します。搭載されている無線モジュールは、 NXP IW612をベースにしたu-blox MAYA-W260です。 SDIO経由でWi-Fiは正常に動作し、コンボファームウェアも正常にロードされました。 Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active Bluetoothは動作しないようです。Android設定で有効にすると、UIスイッチがフリーズし、BTデバイスも見つかりません。 BluetoothはLPUART6(/dev/ttyLP5)に接続されています。NXPベンダーのHALがUARTを正常に開きました。 当初、ハードウェアフロー制御が送信をブロックしていることが判明しました。CRTSCTSを一時的に無効にした後、HALは4バイトのHCIリセットコマンドを送信しました。 01 03 0c 00 UARTカウンタは以下のように表示されます。 tx:4 rx:0 IW612からの応答がありません。ハードウェアフロー制御なしで、115200ボー、8N1で直接手動でUARTテストを行った場合も同じ結果になります。 現在の構成は以下のとおりです。 mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fwは、Wi-Fiドライバーによってすでにコンボファームウェアがダウンロードされているため無効のままです。 もう少し詳しく教えていただけますか: SDIO経由でsduart_nw61x_v1.bin.seをロードした後、IW612 Bluetooth UARTは115200ボーのHCIリセットに直接応答するはずですか? ブートスリープのトリガー、ウェイクアップコマンド、ベンダーコマンド、またはその他の初期化シーケンスが最初に必要ですか? IW612ではハードウェアフロー制御は必須ですか?また、ファームウェア初期化後のCTSの状態はどうあるべきですか? Wi-Fiでロードされるコンボファームウェアに頼るのではなく、uartspi_n61x_v1.bin.seを含むUARTファームウェアダウンロードパスを使用すべきでしょうか? i.MX95上のIW612に推奨されるbt_vendor.confはありますか? 参考となる設定情報や想定されるUARTトレースがあれば大変助かります。 よろしくお願いいたします。 Android Linux Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download こんにちは、 @vins-idg 1.SDIO経由でsduart_nw61x_v1.bin.seをロードした後、IW612 Bluetooth UARTは115200bpsのHCIリセットに直接応答するはずですか? 原則的には、はい — コンボファームウェアがアクティブでBT UARTブロックが起動・準備完了すると、コントローラーはHCIリセットに対してコマンド完了イベントで応答するはずです。 2. ブートスリープトリガー、ウェイクコマンド、ベンダーコマンド、またはその他の初期化シーケンスを最初に実行する必要がありますか? 通常のAndroid起動では、手動でHCI Resetを送信するだけでは頼らないでください。NXPベンダーのHALまたはNXP UARTドライバーに初期化シーケンスを実行させます。 3. IW612ではハードウェアフロー制御は必須ですか?CTSの州はどのような州であるべきか? 量産型IW612 BT UART設計では、ハードウェアフロー制御が有効化され、正しく配線されるべきです。CRTSCTSを無効にすることは、診断手順としてのみ有用であり、最終的な解決策と考えるべきではありません。 4. Wi-Fiでロードされるコンボファームウェアの代わりに、uartspi_n61x_v1.bin.seを使用すべきでしょうか? 別のFWで問題のデバッグを試すこともできますが、根本原因ではないはずです。コンボファームウェアを使用した場合も、期待どおりに動作するはずです。 5.まずは私のローカル環境で試してみて、うまくいった設定ファイルをあなたに共有します。 少々お時間をください。 よろしくお願いいたします。 Christine。 Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download こんにちは、 @vins-idg そちらの状況はどうですか? Android 16のソースコードを構築するための環境準備に時間をかけました。 今はCAN、ビルディングできる。ビルディングの完成には少し時間がかかる。もう少し時間をくれ。 よろしくお願いいたします。 Christine。 Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download こんにちは、 @vins-idg 返信が遅くなり申し訳ありません。お待ちいただきありがとうございました。 すでに自分の側でローカルテストを終えていて、IW612はI.MX95-19*19-EVKで問題なく動作しています。Verdinボードがないため、I.MX95-19*19-EVKを使用してテストを完了しました。 以下はbt_vendor.confのスクリーンショットで、右側でもBTが問題なく動作しているのもわかります。 実際、私はデフォルトのbt_vendor.confをそのまま使用し、何も変更していません。 少しでも役に立てれば幸いです。 それでもあなたの側で動作しない場合は、DTSやDMESGのログを教えてほしいので、さらなる確認にしてください。 ここはコミュニティが公開の場なので、セキュリティ情報を保存するには、私のプライベートな作業用メール [email protected] にDTSファイルを送ってください。 よろしくお願いいたします。 Christine。 Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download こんにちは、 @vins-idg そちらの状況はいかがですか? 私の方から他に何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 Christine。 Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download こんにちは、 @vins-idg 私の上のコメントは読んでいただけましたか? そちらの状況はいかがですか? 私の方から他に何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 Christine。
查看全文
Software & Hardware Environment for Parking Sensor System 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail. 3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target. Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application. 4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface. Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces. Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100 Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization 5 References Developing a Parking Sensor System with Model-Based Design Toolbox Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool 6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.
查看全文
Zone Node Logic Control (Main model overview) 1 Table of Contents • Introduction • Black-Box Overview • Simulink Model Overview • Inputs • Algorithm • Outputs • References • Conclusion 2 Introduction This article explains the internal behavior of the Zone Node by opening the component "black box" and describing how information flows through the application. The objective is to provide a functional understanding of the model, starting from the incoming inputs, continuing through the internal processing logic, and concluding with the generated outputs. The Zone Node acts as an intermediary between the Central Controller and the Edge Nodes located within a vehicle zone. While previous articles introduced the component and the development environment, this article focuses on the application's behavior and the responsibilities performed by the embedded software. This article focuses on the functional behavior of the Zone Node and explains how information flows through the component. Detailed aspects such as CAN routing implementation, LIN scheduling mechanisms, peripheral configuration, and communication stack integration will be covered in dedicated articles later in the series. 3 Black-Box Overview From a system perspective, the Zone Node behaves as a communication gateway and data aggregation component. It receives information from different communication networks, processes that information according to predefined routing rules, and forwards the resulting data to other parts of the system. At a high level, the component can be represented as: Figure 1. Black-Box Overview The Zone Node does not implement vehicle-level control strategies. Functions such as braking decisions, steering calculations, or vehicle state management remain the responsibility of higher-level controllers. Instead, the Zone Node focuses on: Receiving messages from the Central Controller Receiving messages from Edge Nodes Acquiring data from local LIN-connected devices Routing information between networks Aggregating and forwarding data Providing monitoring and diagnostic information The result is a reusable communication component that can be deployed in different vehicle zones while maintaining the same overall behavior. 4 Simulink Model Overview The Zone Node functionality is implemented as a Simulink model organized around communication, routing, scheduling, and diagnostic subsystems. From a model perspective, the application can be divided into four logical areas: Input handling Routing and processing Communication scheduling Outputs and diagnostics Figure 2. Main Simulink Application The input layer receives information from CAN and LIN communication interfaces and makes it available to the application logic. The processing layer evaluates incoming messages and determines how they should be handled. The scheduling layer manages periodic communication activities, while the output layer is responsible for forwarding messages and generating diagnostic information. This separation helps keep the model modular and makes it easier to extend the application with additional communication paths or Edge nodes without changing the core routing behavior. 5 Inputs The Zone Node receives information from three main categories of inputs. 5.1 CAN Network Inputs CAN communication represents the primary source of information processed by the Zone Node. Messages can originate from: Central Controller Lighting modules Steering modules Motor control modules Other Edge Nodes within the zone Typical examples include: Vehicle commands Status reports Diagnostic information Fault indications Actuation requests The exact set of messages depends on the specific Edge Nodes connected to the zone. 5.2 LIN Device Inputs The Zone Node also acquires information from LIN-connected devices. In the reference implementation, LIN communication is used to retrieve parking sensor information. The Zone Node periodically requests data from the LIN device and receives measurement values in response. Examples include: Front parking distances Rear parking distances Other LIN-based sensor information From the perspective of the Zone Node, LIN data behaves similarly to any other external input source. 5.3 Configuration Inputs Before normal operation begins, the Zone Node initializes its communication interfaces and loads the required configuration information. Examples include: CAN interface configuration LIN interface configuration Communication schedules Routing rules These parameters define how the application interacts with the surrounding networks. 6 Algorithm Internally, the Zone Node performs three main processing activities. 6.1 Message Reception The first step consists of collecting incoming communication data. Whenever a message arrives, the application captures: Communication source Message identifier Data payload Message length This information becomes available to the routing and aggregation logic. Figure 3. CAN Reception Pipeline 6.1.1 Model Representation of Message Reception Within the Simulink model, message reception is implemented using communication interface blocks and dedicated processing subsystems that capture incoming network events and make the received information available to the rest of the application. Figure 4. CAN Reception Main Flow Figure 5. CAN Reception Subsystem At a high level, the reception subsystem performs three actions: Detects incoming communication events Stores the received information Makes the information available to the routing logic This allows the routing algorithm to operate independently from the physical communication interface. 6.2 Message Routing Message routing represents the primary responsibility of the Zone Node. The routing logic determines the origin of each incoming message and forwards it to the appropriate communication interface. The behavior can be simplified as: Figure 6. Bidirectional CAN Routing Messages received from the Central Controller are forwarded toward the Edge Nodes, while messages originating from Edge Nodes are routed back toward the Central Controller. The routing mechanism remains independent of the actual application payload, allowing the same software architecture to support different message sets and vehicle functions. 6.2.1 Model Representation of Routing Logic The routing functionality is implemented as a dedicated subsystem responsible for deciding where each received message should be forwarded. Figure 7. Message Routing Main Flow Figure 8. Message Routing Subsystem The routing subsystem evaluates the origin of the received message and selects the appropriate destination interface. At this level, the application does not interpret individual signal meanings; it simply ensures that information reaches the correct communication network. This approach keeps the routing layer independent from application-specific functionality and allows the same architecture to be reused across different deployments. 6.3 LIN Scheduling and Data Acquisition In parallel with CAN routing, the Zone Node periodically acquires data from LIN-connected devices. The sequence follows a simple request-response model: Figure 9. LIN Parking Acquisition Cycle This mechanism allows information originating on a LIN network to become available to the rest of the vehicle through CAN communication. 6.3.1 Model Representation of LIN Scheduling Periodic LIN communication is implemented using a dedicated scheduling subsystem. Figure 10. LIN Scheduling Main Flow The scheduler periodically requests data from LIN-connected devices, waits for a response, and updates the application data used by the rest of the system. Depending on the communication requirements, the scheduler may manage one or more request-response sequences while maintaining a deterministic execution pattern. 6.4 High-Level Data Flow The internal data flow implemented by the Zone Node can be summarized as follows: Figure 11. Zone Node Data Flow 7 Outputs The Zone Node produces several categories of outputs that are consumed by different parts of the vehicle architecture and by development tools used during validation and debugging. 7.1 Routed CAN Messages The primary outputs of the Zone Node are CAN messages forwarded between communication networks. Examples include: Commands sent from the Central Controller to Edge Nodes Status information returned from Edge Nodes Diagnostic messages Fault reports Configuration updates By routing these messages between communication domains, the Zone Node maintains communication between the central controller and the devices located within its assigned vehicle zone. 7.2 Aggregated Device Data In addition to forwarding CAN traffic, the Zone Node generates CAN messages containing information acquired from locally connected devices. One example is parking sensor data collected through a LIN interface and republished on CAN. This allows the Central Controller to access the information without requiring direct interaction with the LIN-connected device. The process can be summarized as: Figure 12. LIN-to-CAN Data Path This approach creates a unified communication interface while hiding the complexity of the underlying network topology. 7.3 Diagnostic Outputs The Zone Node generates diagnostic information that is useful during development, system integration, and troubleshooting activities. Examples include: Communication counters Status variables Network activity indicators Communication statistics Device data used for monitoring purposes These outputs provide insight into the current behavior of the application and can be accessed through development tools such as FreeMASTER. 7.4 Visual Indicators In addition to communication outputs, the Zone Node drives visual indicators available on the evaluation hardware. The on-board LEDs provide immediate feedback regarding: Message reception activity Message transmission activity LIN communication activity Application execution status Although these indicators are not used by the vehicle itself, they simplify application bring-up and validation by providing a quick visual confirmation that the software is operating correctly. 7.5 Output Destinations The outputs generated by the Zone Node are consumed by several different system components. Central Controller Receives: Status information from Edge Nodes Aggregated sensor data Diagnostic information generated within the zone Edge Nodes Receive: Commands originating from the Central Controller Configuration and control messages forwarded through the Zone Node Local Devices Receive: Periodic requests issued by the Zone Node Communication messages required to acquire local measurements Development Tools Receive: Monitoring variables Communication statistics Diagnostic information used for debugging and validation 7.6 High-Level Output Flow Figure 13. System Topology This output structure allows the Zone Node to act as a communication intermediary while simultaneously providing visibility into the behavior of the system during development and validation. 8 References NXP Model-Based Design Toolbox (MBDT) S32K3 Microcontroller Documentation S32K344-WB Evaluation Board Documentation 9 Conclusion This article described the internal behavior of the Zone Node by examining its inputs, processing logic, and outputs. By presenting the component as a functional black box, it explained how information is received, routed, aggregated, and distributed throughout the system without focusing on implementation-specific details. The next articles in the series will build upon this foundation by examining individual communication paths in more detail, including CAN-to-CAN routing, LIN-to-CAN routing, and the techniques used to validate and troubleshoot communication behavior.
查看全文
Creating virtual vehicle with MathWorks - SW & HW Environment 1 Table of Contents • Introduction • Software Environment • Hardware Environment • References • Conclusion 2 Introduction Turning a vehicle concept into an interactive Virtual Vehicle requires more than a standalone simulation model. It requires a connected software and hardware environment that can define the vehicle architecture, simulate the powertrain and vehicle dynamics, place the vehicle in realistic driving scenarios, visualize the behavior in 3D, and allow user interaction through driver-in-the-loop inputs. This article continues the Virtual Vehicle system series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks tools and host-side hardware resources that make the virtual vehicle demonstrator possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to configure the vehicle architecture with Virtual Vehicle Composer, model the powertrain and vehicle dynamics, define and execute driving scenarios, create 3D road environments, exchange CAN-based signals, and analyze simulation results. The same environment also supports interactive execution, where driver inputs from a steering wheel and pedals can influence the virtual vehicle behavior during scenario playback. 3 Software Environment The software environment provides the modeling, simulation, scenario definition, visualization, communication, and analysis capabilities required by the Virtual Vehicle system. Each MathWorks tool contributes a specific part of the workflow, from vehicle architecture definition and plant modeling to 3D scenario execution and CAN-based interaction with external systems. 3.1 MATLAB and Simulink R2025b MATLAB and Simulink form the central engineering environment for the Virtual Vehicle. Figure 1. MATLAB MATLAB provides the scripting, data management, parameterization, and analysis capabilities required to configure simulations, process logged signals, and evaluate test results. Figure 2. Simulink Simulink provides the model-based design environment in which the virtual vehicle, control logic, communication interfaces, and test harnesses are assembled. The system-level model can connect plant models, vehicle dynamics, driver inputs, scenario interfaces, and network communication blocks into a single executable simulation. 3.2 Virtual Vehicle Composer Figure 3. Virtual Vehicle Composer Virtual Vehicle Composer is the configuration and assembly environment used to create the Virtual Vehicle model. It allows the user to define the vehicle class, select the powertrain architecture, choose the vehicle dynamics fidelity, configure components, specify test scenarios, select logged signals, build the vehicle model, run the configured tests, and analyze the results. In this Virtual Vehicle system, Virtual Vehicle Composer acts as the entry point for building a consistent vehicle model. It assembles the selected architecture from predefined and customizable components and prepares the model for closed-loop simulation in Simulink. The app also supports repeatable test execution. The same virtual vehicle can be operated across selected scenarios, while relevant signals are logged for review. This makes it suitable for early design studies, component comparison, control validation, and system-level behavior analysis before moving to hardware integration. 3.3 Powertrain Blockset Figure 4. Powertrain Blockset Powertrain Blockset provides the vehicle powertrain modeling foundation for the Virtual Vehicle model. It includes reference applications and component libraries for conventional, hybrid, and battery-electric propulsion systems. In this system, Powertrain Blockset supports the definition of the propulsion architecture, energy storage, electric motors, drivetrain elements, tires, driver models, and supervisory control behavior. It also provides workflows that help configure, resize, calibrate, and analyze the selected powertrain components. The generated vehicle model can be used for performance analysis, energy management studies, range evaluation, component sizing, control parameter optimization, and hardware-in-the-loop preparation. Because the models are open, project-specific subsystems can be integrated into the generated architecture when needed. 3.4 Vehicle Dynamics Blockset Figure 5. Vehicle Dynamics Blockset Vehicle Dynamics Blockset provides the vehicle motion and handling foundation for the Virtual Vehicle. It includes reference applications and component libraries for propulsion, steering, suspension, vehicle body, brakes, tires, driver models, and supervisory controllers. For the Virtual Vehicle system, the blockset enables different levels of vehicle dynamics fidelity depending on the simulation objective. Longitudinal dynamics can be used for drive-cycle and energy studies, while combined longitudinal, lateral, and vertical dynamics can be used for handling, chassis behavior, and more complex driving scenarios. The blockset also supports 3D visualization workflows, allowing the virtual vehicle behavior to be observed in a realistic environment. This helps connect numerical simulation results with intuitive visual feedback during ride, handling, ADAS, and driver-in-the-loop demonstrations. 3.5 Automated Driving Toolbox Figure 6. Automated Driving Toolbox Automated Driving Toolbox supports the definition, simulation, and analysis of driving scenarios used to exercise the Virtual Vehicle. It provides capabilities for creating road layouts, actors, trajectories, sensor-related contexts, and repeatable test cases. In this setup, the toolbox is used to create controlled and repeatable traffic situations around the ego vehicle. These scenarios can be used to evaluate how the virtual vehicle behaves in predefined maneuvers, traffic interactions, lane-following conditions, or other driving situations relevant to the demonstration. By combining scenario definition with the vehicle model, the Virtual Vehicle can be validated in a structured way. Instead of testing only isolated model behavior, the complete system can be exercised against realistic road and traffic conditions. 3.6 Vehicle Network Toolbox Figure 7. Vehicle Network Toolbox Library Vehicle Network Toolbox brings vehicle network communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding messages over in-vehicle network protocols such as CAN, CAN FD, J1939, and XCP. In the Virtual Vehicle, the toolbox is used to exchange selected vehicle signals with external systems or hardware components. CAN messages can be packed and unpacked using database-driven definitions, allowing the model to follow the same signal structure expected by the vehicle-level architecture. This makes communication behavior visible and testable during simulation. Commands, feedback, status information, and selected virtual vehicle signals can be validated before deployment or integration with physical controllers, reducing late-stage integration risk. 3.7 RoadRunner Figure 8. RoadRunner RoadRunner provides the 3D scene creation environment used by the Virtual Vehicle system. It enables the design of detailed road networks, intersections, lane markings, traffic signs, buildings, terrain, and other environmental assets required for realistic driving simulation. In this workflow, RoadRunner supplies the visual and spatial context in which the virtual vehicle operates. The generated scenes can represent controlled proving-ground layouts, urban intersections, highway segments, or demonstration environments used for scenario execution. When combined with Simulink and the vehicle model, RoadRunner helps transform the simulation from a signal-level model into an interactive visual experience. This is especially useful for driver-in-the-loop demonstrations, ADAS workflows, and stakeholder-facing presentations. 3.8 Simulink 3D Animation Figure 9. Simulink 3D Animation Library Simulink 3D Animation connects Simulink models and MATLAB algorithms to a 3D simulation environment, enabling dynamic systems to be visualized in photorealistic scenes. In the Virtual Vehicle system, it provides the visualization and interaction layer used to observe vehicle behavior in a 3D environment during simulation. The toolbox can use prebuilt scenes or imported scenes created in RoadRunner, and it allows vehicles, objects, lighting, weather effects, and sensor-related elements to be controlled during simulation. This makes it suitable for connecting the Virtual Vehicle model to visually rich driving environments. For driver-in-the-loop operation, Simulink 3D Animation also supports interactive navigation and manual control through hardware devices. This allows steering wheel and pedal inputs to influence the simulated vehicle while the resulting motion is visualized in the 3D scene. 3.9 Stateflow Figure 10. Stateflow Library Stateflow provides the graphical environment for modeling state machines, decision logic, and event-driven behavior inside the Virtual Vehicle system. It is used when vehicle behavior must depend on operating modes, transitions, conditions, timers, or fault states. Within the Virtual Vehicle model, Stateflow can support supervisory control, mode management, scenario state handling, driver input interpretation, startup and shutdown sequencing, or fallback behavior. This helps separate discrete decision logic from continuous plant and controller behavior. Using Stateflow keeps the system behavior easier to understand, review, and validate. Complex conditions can be represented explicitly as states and transitions, which improves traceability during simulation and debugging. 4 Hardware Environment The hardware environment provides the execution platform, user input interface, and visualization resources required to operate the Virtual Vehicle system interactively. The main components are the GPU-accelerated PC and the Xbox-compatible steering wheel and pedal controller. 4.1 PC with GPU Acceleration The PC is the main host platform for the Virtual Vehicle system. It runs MATLAB, Simulink, Virtual Vehicle Composer, RoadRunner-related workflows, and the supporting toolboxes used to model, simulate, visualize, and analyze the vehicle behavior. GPU acceleration is important because the system includes visually rich 3D scenes and interactive simulation workflows. The graphics hardware helps render the driving environment smoothly, maintain responsive visualization, and support a more realistic driver-in-the-loop experience. In this setup, the PC also acts as the integration point between the simulation model, the 3D environment, the input devices, and any external communication interfaces. This makes it the central execution and orchestration node of the Virtual Vehicle demonstration. 4.2 Xbox-Compatible Wheel Controller Xbox-Compatible Wheel Controller The Xbox-compatible wheel controller provides the physical driver input interface for the Virtual Vehicle system. It allows the user to control steering, acceleration, and braking through a steering wheel and pedal set instead of using keyboard-based commands. This input device makes the simulation suitable for driver-in-the-loop demonstrations. User actions can be mapped into the Simulink model and used to influence the virtual vehicle response during scenario execution. The wheel controller improves the realism and accessibility of the demonstration. It allows engineers and stakeholders to experience the virtual vehicle behavior interactively, making it easier to evaluate the relationship between driver input, vehicle response, and 3D scene feedback. 5 References The following resources provide useful background for the technologies referenced in this article: MathWorks MATLAB and Simulink documentation MathWorks Virtual Vehicle Composer documentation MathWorks Powertrain Blockset documentation MathWorks Vehicle Dynamics Blockset documentation MathWorks Automated Driving Toolbox documentation MathWorks Vehicle Network Toolbox documentation MathWorks RoadRunner documentation MathWorks Simulink 3D Animation documentation MathWorks Stateflow documentation 6 Conclusion This section described the software and hardware enablement required for the Virtual Vehicle system. The software environment combines MATLAB and Simulink with Virtual Vehicle Composer, Powertrain Blockset, Vehicle Dynamics Blockset, Automated Driving Toolbox, Vehicle Network Toolbox, RoadRunner, Simulink 3D Animation, and Stateflow to support vehicle configuration, system-level modeling, scenario execution, 3D visualization, communication, and analysis. The hardware environment combines a GPU-accelerated PC with a steering wheel and pedal controller to support interactive driver-in-the-loop execution. Together, these elements provide the foundation for building, operating, visualizing, and validating the virtual vehicle before integration with physical controllers or target hardware.
查看全文
Streams and Transcode Video with Gstreamer This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below: This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false You can check the results with the 1080p@24fps.
查看全文
MCXN547: 利用可能な拡張Flex PWMインスタンスはいくつありますか? リファレンス・マニュアルには、PWMモジュールの2つのインスタンス(PWM0とPWM1)がMCXN547で提供されていると記載されています。しかし、ヘッダーファイル(MCXN547_cm33_core0_COMMON.h)では、PWM0のベースアドレスは含まれていますが、PWM1のベースアドレスは含まれていません。 私はMCXN547VKLTという部品を使用しており、PWM出力にはピン17(ポート2_3)を使用する予定です。データシートMCXN547、ポート2_3はALT5 - PWM1_B2機能として設定可能とされています。しかし、MCUXpresso IDEのピン設定ツールを使うと、ALT5 - PWM1_B2機能のためにPin17(ポート2_3)を選択するオプションがありません。 そこで、MCXN547VKLTが2つのEnhanced Flex PWMインスタンスをサポートしているかどうかを確認したいです。 クロック|タイマー MCX N Re: MCXN547: How many Enhanced Flex PWM instances are available? こんにちは、 @JawaharA さん。 投稿ありがとうございます。 MCXN547VKLT FlexPWMモジュールは1つ(FlexPWM0)しか持っていないことは確認できます。 リファレンス・マニュアルとピンマックステーブルは、いくつかのMCX Nシリーズデバイス(N94/N54/N53/N52/N24)に共通しているため、すべてのデバイスバリアントに存在しないペリフェラルに関連する信号が含まれている場合があります。 デバイス固有の機能の利用可否については、データシートの表4(機能比較)を参照してください。この表に基づくと、FlexPWM1はMCXN547VKLTでは利用できません。 したがって、P2_3は共通ピンマルチプレクサテーブルではPWM1_B2として記載されていますが、MCXN547VKLTではこの機能はサポートされていないため、MCUXpresso Config Toolsでは利用できません。 お役に立てば幸いです。他に質問がありましたら、お気軽にお知らせください。 BR セレステ
查看全文
Simulinkに統合されるNXP MBDTツールボックスを使用してOSを開発することは実現可能でしょうか? こんにちは、チームのみなさん。 私の目的は、MATLAB/Simulink、Embedded Coder、NXP MBDTを用いて、NXP S32G3向けの完全なベアメタルオペレーティングシステム/ソフトウェアプラットフォームを開発する実現可能性を評価することです。 目標は、Simulinkで完全なソフトウェアスタックを開発し、Embedded Coderを使ってCコードを生成し、生成されたコードを外部オペレーティングシステムやRTOS、AUTOSAR BSWに依存せずに直接S32G3 Gold Boxにデプロイすることです。 特に、NXP MBDTを用いて、Cortex-AコアとCortex-Mコアの両方をS32G3上で実装し、生成されたソフトウェアがシステムの初期化、スケジューリング、割り込み管理、メモリ管理、ハードウェア抽象化、周辺機器初期化、IPCメカニズム、その他オペレーティングシステムで通常提供されるサービスとして技術的に実装できるかどうかを理解したいです。 Boot ROMはハードウェア上に常駐しており、アプリケーションより先に実行されると理解しています。私の意図としては、ハードウェアの起動プロセス以降のすべての処理を、可能な限りNXP MBDTワークフローを通じてSimulinkで生成されたコードを使用して実装することです。 したがって、私の主な質問は次のとおりです。 1. NXP Model-Based Design ToolboxとMATLAB/Simulink、Embedded Coderを組み合わせて、Cortex-AおよびCortex-Mの両方を対象としたS32G3向けのベアメタルソフトウェアプラットフォーム(OS風フレームワーク)を開発することは技術的に実現可能か?MBDTのワークフローに制限がある場合、どの部分が手書きのCやアセンブリを必要とするのかを明確に教えていただけますか? MBDTはNXPによって開発されたものだと理解しています。しかし、もしこの質問にNXP MBDTチームがより適切に回答できる場合は、適切な連絡先やサポートチャネルをご案内していただけるとありがたいです。 ご指導ありがとうございました。 Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink こんにちは、 @charan032001 投稿ありがとうございます。 別のスレッドで言及され、返信もあったのに気づきました。 NXPの製品にご関心いただきありがとうございます。 BR チェイン
查看全文
Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink? Hi team, My objective is to evaluate the feasibility of developing a complete bare-metal operating system/software platform for the NXP S32G3 using MATLAB/Simulink, Embedded Coder, and the NXP MBDT. The goal is to develop the complete software stack in Simulink, generate C code using Embedded Coder, and deploy the generated code directly onto the S32G3 Gold Box without relying on an external operating system, RTOS, or AUTOSAR BSW. In particular, I would like to understand whether, using the NXP MBDT, it is technically feasible to implement software for both the Cortex-A cores and the Cortex-M core on the S32G3, with the generated software handling system initialization, scheduling, interrupt management, memory management, hardware abstraction, peripheral initialization, IPC mechanisms, and other services typically provided by an operating system. I understand that the Boot ROM is hardware-resident and executes before the application. My intention is for everything after the hardware boot process to be implemented, as much as possible, using Simulink-generated code through the NXP MBDT workflow. Therefore, my primary question is: 1. Is it technically feasible, using the NXP Model-Based Design Toolbox together with MATLAB/Simulink and Embedded Coder, to develop an entire bare-metal software platform (OS-like framework) for the S32G3 targeting both the Cortex-A and Cortex-M cores? If there are any limitations within the MBDT workflow, could you please clarify what portions would still require handwritten C or assembly? I understand that MBDT is developed by NXP. However, if this question is better addressed by the NXP MBDT team, I would appreciate it if you could kindly direct me to the appropriate contact or support channel. Thank you for your guidance. Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink Hello, @charan032001  Thanks for your post. I noticed it is mentioned via another thread and it had been replied. Thanks for your interest on NXP's product. BR Chenyin
查看全文