GuiGuiDer2.0.0是否只支持LVGL9.4了？ GuiGuiDer2.0.0是否只支持LVGL9.4了？ 没有V8.3.11或者V8.4的支持了吗 回复： GuiGuiDer2.0.0是否只支持LVGL9.4了？ 你好@wqy1103 是的，GUI Guider2.0.0 是为与 LVGL 9.4.0 一起使用而设计的。 BR 哈里

AM3354をSOMモジュールに置き換えることを推奨します こんにちは、エキスパートさん。   TI AM3354を置き換えるためのSOMモジュールで、以下の機能を備えたもの（モジュールTP付き）のおすすめはありますか？価格帯：US$40～US$44   必要な機能: イーサネット SGMII/RGMII SPI 24ビットLCDコントローラ eMMC 8GB RAM 512MB   目標価格に近い価格に到達できるとおすすめします。   よろしくお願いいたします、KPK     Re: SOM module recommendation to replace AM3354 TechNexionとVarisciteの両方がAPACの お客様をサポートしています。シンガポールにとっては、台湾本社を持つTechNexionがより便利な地域サポートを提供する可能性があります。TechNexion（[email protected]）とVariscite（[email protected]）に問い合わせることをお勧めします。シンガポールの流通カバレッジ、地域支援リソース、在庫化方針、デザインインサポートについて直接話し合うために Re: SOM module recommendation to replace AM3354 こんにちは、Yipingさん。私もVariscite DART-6ULやTechNexian PICO-IMX6ULLについて調べているところです。 APAC地域でローカルサポートがあるかはわかりません。何か連絡先を教えてもらえますか? Re: SOM module recommendation to replace AM3354 1. NXP i.MX93 SOM（長期的な最適選択肢） The i.MX93をサポートしています: 24ビットパラレルRGBディスプレイ eMMC 5.1 複数のSPIインターフェース TSN対応のギガビットイーサネット メリット 現行世代のMPU NXPの長期的な事業継続ロードマップ AM335xよりも低消費電力 長年活動しているLinuxサポート 短所 Layerscape/i.MX95のようにネイティブSGMIIが直接利用できない SOMの価格は、512MB DDRと8GB eMMCを含めると通常45米ドルを超える。 SOMの予想価格 数量に応じて約45～60米ドル 2. NXP i.MX6ULL SOM（最安値保証） i.MX6ULLは以下の機能を提供します。 24ビットパラレルRGB LCDインターフェースからWXGAまで eMMCサポート SPIポート 512MB DDRバリアントがすぐに入手可能 典型的なSOM構成は既に存在しており、以下のようなものがあります。 512MB DDR3 8GB eMMC デュアル・イーサネット メリット AM3354に最も近い価格 成熟したLinux BSP 大規模なSOM生態系 AM335xスタイルデザインからの簡単な移行 短所 ネイティブSGMIIなし イーサネットはほとんどのモジュールで高速イーサネット(10/100)に制限されています SOMの予想価格 生産量25～40米ドル   ネイティブSGMIIの場合、通常は次の場所に移動します。 i.MX94x / i.MX95ファミリー Layerscape LS1028A/LS1043A これらは通常、SOMの価格を44米ドルをはるかに超える水準に押し上げる。

SJA1105 SGMII 驱动程序 Petalinux 2020.1 大家好， 我目前正在使用PetaLinux 2020.1和SJA1105SEL交换机，我想知道此软件版本是否支持 SGMII 。 就我目前所见，我不确定 PetaLinux 2020.1 中提供的驱动程序是否支持 SGMII 接口，或者是否在后来的 Linux 内核/驱动程序版本中添加了支持。 请问有人能解释一下吗？ 运行PetaLinux 2020.1时是否可以使用 SJA1105SEL 的SGMII 端口，还是需要补丁代码？ 该版本中包含的 SJA1105 驱动程序是否支持 SGMII 操作？ 如果 PetaLinux 2020.1 不支持 SGMII，那么在哪个 Linux 内核版本（或 PetaLinux 版本）中， sja1105驱动程序添加了对 SGMII 的支持？ 任何信息、补丁、提交记录或文档的参考资料都将不胜感激。 提前感谢！ Linux Re: SJA1105 SGMII driver Petalinux 2020.1 你好， 你使用的是哪款处理器？ Re: SJA1105 SGMII driver Petalinux 2020.1 我使用的是搭载 PetaLinux 2022.2 的 Xilinx Zynq UltraScale+ MPSoC。SJA1105SEL 通过 SGMII 接口连接。我的问题是，SGMII 是否受 PetaLinux 2022.1 中包含的 sja1105 驱动程序支持，或者是否在后续的内核/驱动程序版本中添加了支持。

i.MX8MP：CSI0 接口搭配 TP2860 编码器芯片，运行于连续时钟模式 您好， 我们正在尝试将 TP2860 视频编码器集成到基于 IMX8MP 的平台中，但我们无法捕获任何视频。看来CSIS无法与传入的MIPI数据流同步。 平台：VAR CustomBoard 内核上的 Variscite DART-MX8M-PLUS：linux-imx 6.6.52（恩智浦 电路板支持包，imx8-mipi-csi2-sam 驱动程序），yocto 版本 摄像头：TechPoint TP2860 MIPI 编码器（AHD/TVI-> MIPI-CSI2 桥），输出 MIPI 时钟：297 MHz（测量） 接口：CSI0（mipi_csi_0 @ 0x32e40000），2 车道，500 Mbps/Lane，FHD30 (1920x1080 @30) 管道：TP2860-> MIPI D-PHY-> CSIS-> (MediaMix Gasket)- > ISI0-> /dev/video2 v4l2 管道看起来没问题（参见附件 pipeline_info.txt） 相关的（扁平化）设备树信息已附在 devicetree.txt 文件中。 DPHYSTATUS 报告 0xC2（所有通道均处于 HS 模式），但 CSIS帧起始计数器始终为零（实际上，所有 mxc-mipi-csi2.0 计数器均为零）。 我们已经研读了恩智浦（NXP）的AN13857文档，并有以下几个问题： TP2860 在两次突发传输之间将 MIPI 时钟通道保持在 HS 状态（连续时钟模式）。这通过 CSIS DPHYSTATUS = 0xC2 在驱动程序启用 s_stream 之前和之后均保持该值得到了证实： => CSIS 寄存器转储（CSIS 基址 0x32e40000）： CSIS_CMN_CTRL [0x04] = 0x00004105 (ENABLE=1, LANE_NR=1->2 条通道, HDR_MODE=0) CSIS_DPHYCTRL [0x24] = 0x13000007 (hs_settle=0x13, D-PHY 启用) CSIS_DPHYSTATUS [0x20] = 0x000000C2 (HSCLK=1, HSDAT1=1, STOPSTATE_CLK=0) CSIS_INTSRC [0x14] = 0x00000000 (未触发中断) => CSIS_DPHYSTATUS[0x20] = 0x000000C2 第 7 位：HSCLK = 1（时钟通道处于 HS 模式） 第 6 位：HSDAT1 = 1（数据通道 1 处于 HS 模式） 第 1 位： ULPS_CLK = 0（未处于 ULPS 状态） 第 0 位：STOPSTATE_CLK = 0（从未处于 LP-11 停止状态） 这与 NXP AN13857 中的警告一致： " i.MX 8MM、 i.MX 8MN 和 i.MX 8MP 要求连接的摄像头在启用 Rx DPHY 之前处于 LP 状态 。但如果相机处于连续时钟模式，时钟 通道可能始终处于HS模式。在这种情况下，Rx DPHY 可能无法检测到 HS 模式，导致 错误地保持在停止或 ULPS 状态。" TP2860 在直播期间通过 I2C 进行寄存器回读： 0x40 -> 0x08 (驱动程序在 s_stream 之后选择的 MIPI 页面) 0x02 -> 0x7d (MIPI_EN0=1, 所有位均已设置) 0x28 -> 0x00 (STOP_CLK=0, ULPM=0) 0x10 -> 0x20 (启用 MIPI TX, 未处于 RESET 状态) 0x29 -> 0x00 (数据通道停止/ULPS: 无) 我们尝试启用 TP2860 内部 BT.1120 测试模式（排除模拟编码器路径）： 0x40-> 0x08（MIPI 页面）0x 22-> 0x80（TP_ENA=1：绕过模拟解码器，发送数字图案） 但这并不能改善现状。 我们将按以下方式配置 TP2860： 写入 0x02=0x3d、0x03=0x35、0x04=0x35<-- MIPI_ENx=0（通道关闭） 计时：0x2b=0x09（T_PREP RESET 默认），0x2C=0x0A 解码器 PLL 重置：REG 0x06 |= 0x80，msleep (10) MIPI PLL RESET: REG 0x14 |= 0x80、msleep(10)、deassert msleep(50)（PLL锁定时的扩展稳定时间） 0x02=0x7d, 0x03=0x75, 0x04=0x75HS） 问题： 是否支持将 imx8MP Rx D-PHY 与处于连续时钟模式的摄像机配合使用 BSP 机制（STOPPSTATE_CLK 永久为 0）？CSIS / D-PHY 是否有一种模式，在使能 HS-RX 之前，无需依赖时钟通道上 LP-11 的观测结果？ 除了 AN13857 之外，还有关于使用连续时钟 MIPI-CSI2 源进行 CSIS 操作的 imx8MP 的已知勘误表或应用笔记吗？ 包含 TP2860 编码器芯片的相同硬件适用于边界设备 i.MX8 MQ 设置 任何帮助都将不胜感激。 图形与显示 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP: CSI0 with TP2860 encoder chip in continous clock mode 你好， 我也遇到了类似的问题，请问您找到解决方法了吗？

2026年最好的电子钱包应用开发公司是哪家？ 2026 年最佳电子钱包应用开发公司应具备以下条件：金融科技专业知识、强大的网络安全标准、可扩展的技术以及交付定制数字支付解决方案的良好记录。Nimble AppGenie专注于构建安全且功能丰富的电子钱包应用程序，以满足初创公司、金融科技公司、银行和企业的需求。 我们的解决方案包括多币种钱包、点对点支付、二维码和 NFC 支付、支付网关集成、KYC/AML 合规性、AI 驱动的欺诈检测以及无缝的第三方集成。Nimble AppGenie 专注于创新、监管合规和用户体验，帮助企业推出可靠的数字钱包平台，这些平台旨在适应当今快速发展的金融科技环境并实现规模化发展。

关于S32K388的安全手册相关 我目前在做s32k388的安全资料整理，我们已经签订了NDA，我之前申请过一次安全访问权限，在我还没有下载资料时候没几天安全访问权限就自动取消了，我前两周又重新申请访问安全权限，但到现在一直没有他通过，我昨天也通过邮件发送给支持团队附件也粘贴了NDA材料。我目前比较紧急需要拿到安全相关的材料，我需要在安全手册里整理出安全相关检测功能供我们团队使用。 Re: 关于S32K388的安全手册相关 尊敬的用户， 谢谢。让我确认一下，您的安全文件帐户已激活。您申请的 S32K3xx 功能安全手册目前处于待处理状态。是否授予您访问权限取决于文档所有者。您的访问权限获得批准后，我们将另行发送电子邮件通知您。谢谢。祝你今天过得愉快。 帕夫拉 Re: 关于S32K388的安全手册相关 xlele_0-1784014118814.png 这边一直处于还在审核的状态，但这个状态已经持续快两周了 Re: 关于S32K388的安全手册相关 xlele_0-1784013997876.png 现在重新提交就会处于这个注册失败的状态。 Re: 关于S32K388的安全手册相关 尊敬的用户， 您的安全文件注册信息被错误地拒绝了。 请重新注册： https://www.nxp.com/webapp-signup/docstoreReg 完成后请告知我，以便我尽快激活您的帐户并授予您访问权限。谢谢。 祝你今天过得愉快。此致 帕夫拉

2026年に最も優れたeウォレットアプリ開発会社はどこですか? 2026年に最高のeウォレットアプリ開発会社は、フィンテックの専門知識、強力なセキュリティ基準、スケーラブルな技術、そしてカスタムデジタル決済ソリューションの実績を兼ね備えた企業です。Nimble AppGenieでは、スタートアップ、フィンテック企業、銀行、企業のニーズに合わせた安全で機能豊富なeWalletアプリケーションの開発を専門としています。 当社のソリューションには、多通貨ウォレット、ピアツーピアペイメント、QRコードおよびNFCペイメント、ペイメントゲートウェイ統合、KYC/AMLコンプライアンス、AI搭載の不正検出、シームレスなサードパーティ連携が含まれます。イノベーション、規制遵守、ユーザー体験に重点を置き、Nimble AppGenieは、急速に変化するフィンテック環境に適応した信頼性の高いデジタルウォレットプラットフォームの立ち上げを支援しています。

how much i set tempSense Voltage supply? i am using s32k344. i wanna use tempSense in mcu.  how much i set tempSense Voltage supply? if i set 0x15, is that mean is 1.5V? Re: how much i set tempSense Voltage supply? Hi@rlaxortn I have already answered all of these in your previous questions. if i set 0x15, is that mean is 1.5V?， the answer is yes, But this value is not set randomly. I suggest you read Chapter 85 Temperature Sensor in the data sheet . Senlent_0-1752654010118.png Re: how much i set tempSense Voltage supply? Hi@rlaxortn Just to correct myself, there were some errors in my answer. The data format used was S11.4. Therefore, the actual value = original 16-bit signed number ÷ 16 For example: 1.0x15 = 21 / 16 = 1.3125V 2.0x35 = 53 / 16 = 3.3125V 3.0x50 = 80 / 16 = 5V

PTE4ABTE-32GX eMMC このPHISON製のeMMC PTE4ABTE-32GX をIMX8Mプロセッサと組み合わせて使用する予定です。起動に対応しているか確認してください。参考資料としてデータシートを添付します。 Re: PTE4ABTE-32GX eMMC はい、データシートによると、PHISON PTE4ABTE-32GXはi.MX8Mファミリー(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP)での起動をサポートしているはずです。ただし、i.MX8Mハードウェア設計ガイドに基づくUSDHCインターフェースに接続されている場合に限ります。 Re: PTE4ABTE-32GX eMMC @yipingwangご回答ありがとうございます。 私たちは MIMX8ML5CVNKZAB を使っています。これは i.MX8ML デバイス です。あなたの回答では 、 i.MX8Mファミリ(i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP) のみ が言及されています。 ハードウェア設計ガイドラインに従い、 PHISON PTE4ABTE-32GX が i.MX8ML デバイスに接続 された場合、USDHCインターフェースに接続した場合 の起動にも対応されている か確認していただけます か? Re: PTE4ABTE-32GX eMMC はい、i.MX8ML(MIMX8ML5CVNKZAB)はUSDHCインターフェース経由で接続されたeMMCデバイスからの起動をサポートしています。PHISON PTE4ABTE-32GXはeMMC 5.1デバイスであり、i.MX8Mハードウェア設計ガイドに従って接続・設定した場合、i.MX8MLブートフローに対応しることが期待されています。

如何设置温度感应电压？ 我使用的是 S32K344。我想在微控制器中使用 tempSense。 如何设置温度感应电压？ 如果设置为 0x15，是否表示电压为 1.5V？ Re: how much i set tempSense Voltage supply? 你好@rlaxortn 我已经在你之前的问题中回答了所有这些问题。 如果我设置 0x15，是否意味着 1.5V？ 但这个值不是随意设置的。 我建议您阅读数据表中第 85 章 "温度传感器"。 Senlent_0-1752654010118.png Re: how much i set tempSense Voltage supply? 您好@rlaxortn 更正一下，我的回答中有一些错误。 所用数据格式为 S11.4。 因此，实际值 = 原始 16 位有符号数 ÷ 16 例如： 1.0×15 = 21 / 16 = 1.3125V 2.0×35 = 53 / 16 = 3.3125V 3.0×50 = 80 / 16 = 5V

SJA1105 SGMIIドライバー Petalinux 2020.1 こんにちは、皆さん 現在、 PetaLinux 2020.1 と SJA1105SEL スイッチを使って作業しており、 このソフトウェアリリースでSGMIIがサポートされているかどうか知りたいです。 これまでのところ、PetaLinux 2020.1のドライバでSGMIIインターフェースがサポートされているのか、それとも後のLinuxカーネルやドライババージョンでサポートが追加されたのかはわかりません。 どなたか詳しく教えてもらえますか: PetaLinux 2020.1を実行している場合、SJA1105SELのSGMIIポートを使用することは可能ですか？それともパッチコードが必要ですか？ そのリリースに付属しているSJA1105ドライバはSGMIIの動作をサポートしていますか? PetaLinux 2020.1でSGMIIがサポートされていない場合、どのLinuxカーネルバージョン(またはPetaLinuxリリース)が sja1105 ドライバに追加されたのでしょうか? パッチやコミット、ドキュメントなどの情報や参考文献があれば大変ありがたいです。 よろしくお願いいたします！ Linux Re: SJA1105 SGMII driver Petalinux 2020.1 こんにちは、 どのプロセッサを使っていますか? Re: SJA1105 SGMII driver Petalinux 2020.1 私はPetaLinux 2022.2を搭載したXilinx Zynq UltraScale+ MPSoCを使用しています。SJA1105SELはSGMIIインターフェースを介して接続されています。質問は、PetaLinux 2022.1に含まれるsja1105ドライバーがSGMIIをサポートしているのか、それとも後のカーネルやドライバーバージョンでサポートが追加されたのかということです。

S32K388に関連する安全マニュアル 現在、S32K388のセキュリティ関連ドキュメントを作成中です。既にNDA（秘密保持契約）を締結済みです。以前セキュリティアクセスを申請しましたが、ドキュメントをダウンロードする数日前に自動的に取り消されてしまいました。2週間前に再度アクセスを申請しましたが、まだ承認されていません。昨日、NDA関連資料を添付ファイルとしてサポートチームにメールで送付しました。セキュリティ関連資料が緊急に必要です。チームで使用するセキュリティ関連の検出機能をセキュリティマニュアルにまとめる必要があるためです。 Re: 关于S32K388的安全手册相关 お客様へ、 ありがとう。お客様のセキュアファイルアカウントが有効化されていることを確認させていただきます。S32K3xxセーフティマニュアルのご要望は現在、保留中です。アクセス権を付与するのは文書所有者の責任です。アクセスが承認され次第、別のメールで通知いたします。ありがとう。良い１日を。 パブラ Re: 关于S32K388的安全手册相关 xlele_0-1784014118814.png 現在も審査中ですが、この状態がほぼ2週間続いています。 Re: 关于S32K388的安全手册相关 xlele_0-1784013997876.png 今再送信すると、登録失敗のステータスになります。 Re: 关于S32K388的安全手册相关 お客様へ、 お客様のセキュアファイル登録は、誤って拒否されました。 再度ご登録ください： https://www.nxp.com/webapp-signup/docstoreReg 終わったら教えてください。その後、アカウントを有効化してできるだけ早くアクセス権を付与できます。ありがとう。 良い１日を。よろしくお願いします パブラ

iMX 937处理器的最小和最大睡眠电流（毫安）是多少？   我的项目中使用的是 i.MX937 处理器，i.MX937 处理器的典型睡眠电流（mA）是多少？   Re: What is the min to max sleep current mA for the iMX 937 processor 有了这些维持正常运转所需的资源， 150 µA 的睡眠电流对于 i.MX 937 / i.MX 93 处理器本身来说并不现实。 。 为什么： 模式 电流/功率影响 适合 150 µA？ 功能性贴合 BBSM/RTC模式 数据表列表 1.8V 时功率为 0.14 mW 功率测量应用程序说明显示大约 总计 97.978 µW 仅  NVCC_BBSM_1P8  积极的。 就力量而言，是的。 不 — 只有 BBSM/RTC 逻辑保持通电；GPIO 唤醒关闭，定时器/PWM/ADC 不可用。 暂停 数据表列表 典型值 15.1 mW 在 25 °C 下。 不 远高于 150 µA 等效电流 无/有限 — 暂停会关闭时钟，Cortex-A55 掉电，并使可以关闭的内部逻辑/模拟模块掉电。 Linux 挂起 + M33 在 WFI 中 应用笔记列表 122.4 毫瓦 此用例的总计。 无 建筑风格上更接近了，但仍然远远高于你目前的目标。 低功耗运行/使用Cortex-M33的AONMIX AONMIX 可以在其他功能域断电时运行，并且包含定时器/PWM 和定时器资源。 未记录显示符合 150 µA 标准 如果外设必须保持活动状态，则这是相关的 i.MX 93 模式类别，但它不是 150 µA 级模式。   150 µA 的预算仅相当于 1.8V 时功率为 0.27 mW 或者 3.3V 时功率为 0.495 mW 。那与i.MX 93的性能范围相符。 仅限 BBSM/RTC 状态，不是具有活动定时器输出、ADC、PWM、RTC 和 GPIO 的状态。 推荐架构：保留 i.MX 937 BBSM/RTC 或完全断电睡眠 并将始终开启的功能（定时器输出、ADC 监控、PWM 和 GPIO 监控）移至超低功耗的配套 MCU 或模拟/RTC 电路。当满足特定条件时，配套设备可以唤醒 i.MX 937。 i.MX 937 只能在非常有限的 RTC/BBSM 模式下满足 ~150 µA 的电流；在该电流预算内，它无法保持定时器/PWM/ADC/GPIO 功能处于活动状态。 Re: What is the min to max sleep current mA for the iMX 937 processor 我们的应用程序在低功耗/睡眠模式下需要以下资源才能保持正常运行： 1. 定时器输出引脚 1个ADC输入 1 PWM RTC 2-3 个 GPIO 我们对睡眠电流的要求是 150 µA。 Re: What is the min to max sleep current mA for the iMX 937 processor 对于 i.MX 937 / i.MX 93 处理器本身，数据手册没有给出任何以毫安 (mA) 为单位的“睡眠电流”。它规定 SUSPEND 模式总功率在25°C时为 15.1 mW ，并指出该数值取决于使用情况。挂起是功耗最低的模式，时钟关闭，不必要的电源关闭，可关断电源的 SoC 部分被关断，Cortex-A55 完全关断电源，DRAM 处于自刷新/保持状态。 如果您需要用于预算的等效电流，请使用： yipingwang_0-1784086916714.png 因此， 15.1 mW大约相当于： 假定的供应基础 等效电流 5.0V 输入 3.0 毫安 3.3V 输入 4.6毫安 这是等效输入电流，而不是单个 SoC 电源轨电流；实际处理器电流分布在多个电源轨上。 如果您指的是电路板/SOM 深度睡眠电流，则测量值可能会更高，并且取决于配置。一项 i.MX93 SOM DSM 测量报告显示，在 5 V 时电流为 4.04 mA ，而其他优化/配置相关的报告显示，在 5 V 时电流约为 1.5 mA 至 9.3 mA 。 处理器规格中典型的 SUSPEND 功耗为 15.1 mW ；仅根据实际输入电压转换为 mA，例如5 V 时约为 3.0 mA 。

What is the min to max sleep current mA for the iMX 937 processor   In my project I am using I.MX937 processor, what is the typical sleep current (mA) for the i.MX 937 processor?    Re: What is the min to max sleep current mA for the iMX 937 processor With those resources required to stay functional, 150 µA sleep current is not realistic for the i.MX 937 / i.MX 93 processor itself . Why: Mode Current/power implication Fits 150 µA? Functional fit BBSM / RTC mode Datasheet lists 0.14 mW at 1.8 V , and the power-measurement app note shows about 97.978 µW total , with only  NVCC_BBSM_1P8  active. Power-wise, yes No — only BBSM/RTC logic remains powered; GPIO wakeup is OFF, and timer/PWM/ADC are not available. Suspend Datasheet lists 15.1 mW typical at 25 °C. No — far above 150 µA equivalent No / limited — suspend turns off clocks, powers down the Cortex-A55, and powers down internal logic/analog blocks that can be shut off. Linux Suspend + M33 in WFI App note lists 122.4 mW total for this use case. No Closer architecturally, but still far above your current target. Low-power run / AONMIX using Cortex-M33 AONMIX can run while other domains are powered down, and includes timer/PWM and timer resources. Not documented as meeting 150 µA This is the relevant i.MX 93 mode class if peripherals must remain active, but it is not a 150 µA-class mode.   A 150 µA budget corresponds to only 0.27 mW at 1.8 V or 0.495 mW at 3.3 V . That is in the range of the i.MX 93 BBSM/RTC-only state, not a state with active timer output, ADC, PWM, RTC, and GPIOs. Recommended architecture: keep the i.MX 937 in BBSM/RTC or fully power-gated sleep , and move the always-on functions — timer output, ADC monitoring, PWM, and GPIO supervision — to a very-low-power companion MCU or analog/RTC circuit. The companion device can wake the i.MX 937 when the condition is met. The i.MX 937 can meet ~150 µA only in a very limited RTC/BBSM-style state; it cannot keep timer/PWM/ADC/GPIO functionality active within that current budget. Re: What is the min to max sleep current mA for the iMX 937 processor In our application, the following resources are required to remain functional during the low-power/sleep mode: 1 Timer output pin 1 ADC input 1 PWM RTC 2–3 GPIOs Our requirement of sleep current is 150 µA. Re: What is the min to max sleep current mA for the iMX 937 processor For the i.MX 937 / i.MX 93 processor itself, the datasheet does not give a single “sleep current” in mA. It specifies SUSPEND mode total power = 15.1 mW at 25 °C , and notes that the number is use-case dependent . SUSPEND is the lowest-power mode where clocks are off, unnecessary supplies are off, power-gateable SoC portions are gated, Cortex-A55 is fully power-gated, and DRAM is in self-refresh/retention. If you need an equivalent current for budgeting, use: yipingwang_0-1784086916714.png So 15.1 mW corresponds approximately to: Assumed supply basis Equivalent current 5.0 V input 3.0 mA 3.3 V input 4.6 mA That is an equivalent input current , not a single SoC rail current; the actual processor current is distributed across multiple power rails. If you mean board/SOM deep-sleep current , measured values can be higher and configuration-dependent. One i.MX93 SOM DSM measurement reported 4.04 mA at 5 V , with other optimized/configuration-dependent reports around 1.5 mA to 9.3 mA at 5 V . Use 15.1 mW typical SUSPEND power for the processor spec; convert to mA only against your actual input rail, e.g. about 3.0 mA at 5 V .

Toolbox setup and how to run an application 1 Table of Contents •Introduction •Overview •Context •References •Conclusion 2 Introduction This article walks through the complete process of setting up the NXP Model-Based Design Toolbox (MBDT) and running a first application on NXP hardware. Before starting the installation, make sure that the prerequisite toolboxes are available in MATLAB. By the end of this guide, the reader will have a fully functional MBDT environment and will have successfully generated, compiled, and deployed embedded C code from a Simulink model to NXP hardware. 3 Overview This guide begins with the installation prerequisites and required toolboxes, then continues with the MATLAB Add-On Explorer flow for installing NXP_Support_Package_S32K3 . After the support package is installed, the guide explains how to launch the multistep installer, verify the required toolboxes and installation path, download the toolbox package from NXP, and complete the toolbox installation before running the first application. Installation Scope and Workflow This article focuses on practical installation flow required to start working with the NXP Model-Based Design Toolbox and run a first example application. It covers the software prerequisites, the toolbox setup sequence, and the validation steps needed before opening and deploying a model on the target board. The installation content in this guide should use the current multistep installer flow. Target Audience This article is intended for engineers and technical professionals who want to begin developing embedded applications for NXP hardware using a Model-Based Design workflow. The main target audience includes: Embedded software engineers MATLAB / Simulink developers evaluating NXP hardware Control and algorithm engineers Students and academic researchers using NXP evaluation boards Model-Based Design engineers Hardware integration engineers 4 Context 3.1 Prerequisites Before starting the installation, verify that the following prerequisite toolboxes and setup conditions are met: MATLAB installed - Required by the support package and multistep installer flow. Simulink installed - Required for model-based development and Simulink example execution. Embedded Coder installed - Required for embedded C code generation from Simulink models. MATLAB Coder installed - Required by the current S32K3 support package prerequisites. Simulink Coder installed - Required by the current S32K3 support package prerequisites. Embedded Coder Support Package for ARM Cortex-M Processors installed - Required by the installer verification step and target support flow. NXP account - Required to access the NXP download page and retrieve the toolbox package. Short local installation path - The installation path should be local, short, and should not contain whitespace to avoid setup issues. image1.png Figure 1 - MATLAB Add-On Manager confirming requirement are installed 3.2 Toolbox Setup NXP's Model-Based Design Toolbox is delivered as a MATLAB Toolbox Package that can be installed offline or online from MathWorks Add-ons. The recommended installation path uses the NXP Support Package, a graphical wizard that guides through download, installation, and license activation in a single workflow. Note: Throughout this guide, the placeholder {platform} refers to the NXP MCU family targeted by the toolbox (for example S32K3 , S32K1 , S32M2 , MPC57XX , etc.). Each family has its own dedicated Support Package and Toolbox in the MATLAB Add-On Explorer. When following the steps below, replace {platform} with the identifier matching the hardware family in use, for instance, for the S32K3 evaluation boards, the script name becomes NXP_Support_Package_s32k3.m and the path command becomes mbd_s32k3_path . Step 1 - Install NXP Support Package from MATLAB Add-On Explorer Install the current NXP support package directly from the MATLAB Add-On Explorer. This package provides the multistep installer flow used to verify prerequisites, download the toolbox, and guide the installation for S32K3. In MATLAB, navigate to Home → Add-Ons → Get Add-Ons. image2.png Figure 2 - Open the Add-On Explorer from the MATLAB Home tab Search for NXP_Support_Package_S32K3 in the Add-On Explorer. image3.png Figure 3 - Search results for NXP_Support_Package_S32K3 in the Add-On Explorer Open the package page and click Add to start the installation. image4.png Figure 4 - Open the NXP_Support_Package_S32K3 page and click Add Review the license agreement for NXP_Support_Package_S32K3 and click I Accept. image5.png Figure 5 - License agreement shown during installation of NXP_Support_Package_S32K3 Wait for the installation to complete. When finished, the Getting Started Guide opens automatically. image6.png Figure 6 - Support package installation completed successfully In the MATLAB Command Window, run sp_s32k3.nxp.setup(); to launch the multistep installer. sp_s32k3.nxp.setup(); image7.png Figure 7 - Run sp_s32k3.nxp.setup(); from the MATLAB Command Window Step 2 - Use the multistep installer to download and install the toolbox The multistep installer guides you through prerequisite verification, toolbox download, installation, activation, and access to the documentation for S32K3. image8.png Figure 8 - Welcome page of the S32K3 multistep installer In the installer, continue to the download step. On the NXP website, review the software terms and conditions and click I Agree before downloading the toolbox package. If the product download page does not open automatically, sign in to your NXP account and open the Product Download page for the required S32K3 toolbox release or click the link from Download page of the S32K3 multistep installer. image9.png Figure 9 - Download page of the S32K3 multistep installer image10.png Figure 10 - Accept the NXP software terms and conditions before downloading Download the toolbox package from the Product Download page. The installer accepts both .zip and .mltbx files. image11.png Figure 11 - Product Download page for the S32K3 MBDT package The setup verification step checks whether all required toolboxes are installed in MATLAB and whether the installation path is valid for the S32K3 toolbox setup. If any dependency is missing or an unsupported version is detected, resolve the issue before continuing to the download and installation steps. image12.png Figure 12 - Setup verification page showing required toolboxes and installation path checks Important: It is recommended to install MATLAB and the NXP Toolbox into a location that does not contain special characters, empty spaces, or mapped drives. Use a short local path whenever possible. After downloading the package, return to the installer and continue with the local file selection step. Browse to the downloaded archive or toolbox package and click Install to continue. The installer accepts both .zip and .mltbx files. image13.png Figure 13 - Browse to and download the S32K3 MBDT package from the Product Download page image14.png Figure 14 - Accept the license agreement for NXP_MBDToolbox_S32K3 Accept the toolbox license agreement to allow MATLAB to complete the MBDT installation. image15.png Figure 15 - Toolbox installation in progress After the installation is complete, use the Add-On Manager context menu to open the installed toolbox folder if you need to inspect the package contents or access installed files directly. Wait until the installation finishes. The process may take several minutes depending on the system configuration and package size. image16.png Figure 16 - Open the installed toolbox location from MATLAB Add-On Manager Step 4 - Set the Path for Toolchain Generation The MBDT uses Simulink's toolchain mechanism to enable automatic code generation with Embedded Coder. When installed as a MATLAB add-on, the toolbox path is configured automatically. If manual configuration is still required in your environment, run the platform path script from the installation directory. If manual setup is required, in MATLAB change the Current Directory to the toolbox installation folder: ..\MATLAB\Add-Ons\Toolboxes\NXP_MBDToolbox_{platform}\ Then run the configuration script: mbd_{platform}_path image17.png Figure 17 - Output of the mbd_{platform}_path script in the MATLAB Command Window 3.3 How to Run an Application With the toolbox installed and the compiler configured, the following steps demonstrate how to open, build, and deploy the LED blinky example - the embedded equivalent of Hello World to an NXP evaluation board. Open an Example Model Open MATLAB and start Simulink by typing simulink in the Command Window (or by clicking the Simulink button on the Home tab). In the Simulink Start Page, open the Simulink Library Browser (View → Library Browser, or press Ctrl+Shift+L). In the Library Browser tree, expand NXP Model-Based Design Toolbox for {platform} to confirm that the NXP blocks are available. This validates that the toolbox is properly registered with Simulink. Open the Example Projects tab from the Simulink Start Page, it lists every example shipped with the MBDT, grouped by peripheral (ADC, CAN, DIO, PWM, UART, etc.). Browse the list, select the example matching your hardware (for instance s32k3xx_dio_s32ct for the LED blinky on FRDM-A-S32K312 / FRDM-A-S32K344 ), and click Open to load the model. image18.png Figure 18 - MBDT Examples Library available from the Simulink Library Browser Open the example model ( .slx / .mdl file). Configure the Target Hardware image19.pngFigure 19 - Model Settings  image20.png Figure 20 - Code Generation Tip: Example models that ship with the MBDT are pre-configured for a specific evaluation board. Always verify the hardware target matches your physical board before building. Build and Deploy Connect the NXP evaluation board to the PC via USB. In Simulink, open the Hardware tab and click Build, Deploy & Start (or use Ctrl+B). Monitor the MATLAB Diagnostic Viewer for build status messages. Verify on Hardware Confirm that the application runs on the target hardware as expected - for example, observe the LED blinking at the rate defined in the model. If the application produces serial output, open a terminal and verify the expected data on the communication port. Use debugging or monitoring tools to inspect variable values and system signals from the running application in real time. 5 References NXP Model-Based Design Toolbox - Product Page Automotive SW - S32K3 - Model-Based Design Toolbox Model-Based Design Toolbox S32K3xx Quick Start Guide (PDF) MathWorks Embedded Coder 6 Conclusion This article described the complete setup of the NXP Model-Based Design Toolbox: from installation and compiler configuration to building and deploying a first application to NXP hardware. The next article in the series focuses on the Toolbox Workflow, presenting in detail the end-to-end development flow with the MBDT, from configuring a Simulink model with NXP blocks, through code generation with Embedded Coder, to building, deploying and validating the resulting application on NXP hardware.

Front and Rear Lights-Overview 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Automotive lighting systems play an essential role in vehicle safety, visibility, and communication with other road users. In general, these systems can be grouped into two main categories: Front Lighting and Rear Lighting. Both help provide road illumination for the driver and signal the vehicle's actions and presence to surrounding traffic. Front Lights - General Role and Functions Front lighting improves the driver's visibility in different driving conditions, including low light, nighttime driving, and adverse weather. It includes several key functions commonly found in modern vehicles, such as: Daytime Running Lights (DRL) - increase vehicle visibility during daytime driving Turn Lights - indicate the driver's intention to change direction Head Lights - provide road illumination during nighttime or low-light conditions Fog Lights - improve visibility in fog, rain, snow, or other low-visibility situations Rear Lights - General Role and Functions Rear lighting is primarily used to communicate the vehicle's status and intentions to other road users. It includes important functions such as: Stop Lights - signal braking actions Head Lights - make the vehicle visible from behind Turn Lights - indicate the intended direction of travel Fog Lights - improve vehicle visibility in low-visibility conditions 3 Overview The lighting system presented in this article is developed using a Model-Based Design (MBD) approach. This methodology enables early validation of system behavior, systematic refinement of the control logic, and a direct path from simulation to embedded implementation. The control behavior is modeled in MATLAB/Simulink, where the functionality is structured into modular and reusable components. Stateflow is used to describe the control logic, providing a clear and formal representation of operating modes, state transitions, and event-driven behavior. The Simulink model runs on the NXP S32K3 platform and communicates with other vehicle nodes via CAN Bus. Message reception and signal handling are managed using the Vehicle Network Toolbox, which simplifies CAN communication by utilizing DBC files without introducing additional hand-written interface code. This integration supports a smooth transition from simulation to embedded deployment through automatic code generation, minimizing the risk of discrepancies between modeled behavior and deployed software. Target audience: Engineers interested in Model-Based Design for automotive applications Those learning or experimenting with simulation-based development and control logic Anyone using NXP automotive hardware platforms who wants to faster develop complex applications on real embedded systems figure2-front-hazard-lights.gif Figure 2 - Front Hazard Lights Activated 4 Context In this project, separate models are implemented for front and rear lighting to showcase the physical layout of the car and keep the logic simple and easier to test. Each lighting area handles its own functions, while staying synchronized with overall vehicle behavior through standard vehicle communication. Roxana_Grigore01_1-1783070587610.png Figure 1 - Front and Rear Lights System highlighted within the EV architecture All lighting commands are received via the CAN bus, ensuring consistent and predictable behavior for functions such as Daytime Running Lights (DRL), Head Lights, Fog Lights, Turn Indicators, and Stop Lights. Using CAN-based commands reflects standard vehicle communication practices and allows the lighting logic to be evaluated under conditions close to those in a production system. Incoming CAN messages are processed by the lighting module. Based on vehicle states and received commands, the module: interprets CAN signals and system status, prioritizes lighting functions and handles fault-related conditions, turns on the lights. This structure keeps responsibilities clear: the CAN layer provides high-level commands, while the lighting control logic handles decision-making and execution. The result is a deterministic and easy-to-follow path from vehicle-level inputs to visible lighting behavior. In our project, the system uses addressable LEDs, allowing individual control of multiple light segments within each lamp. This enables a realistic representation of modern automotive lighting systems, where lighting units are no longer simple on/off devices but consist of multiple independently controlled segments. Addressable LEDs rely on a dedicated communication protocol to transfer control data such as color, brightness, and activation timing to each individual LED element. To simplify the integration of this protocol and ensure deterministic behavior, the LED communication was configured and integrated using NXP's Model-Based Design workflow. This approach allows the LED control logic and communication timing to be defined, simulated, and validated directly at model level. The system behavior can be easily followed from input to output, since each step is clearly defined. CAN messages trigger specific actions, and the result is directly visible in the LEDs. This makes the logic straightforward to understand and verify. 5 References Model-Based Design Toolbox (MBDT) Community Model-Based Design Toolbox (MBDT) - S32K3 - How To 6 Conclusion This article provides a simple overview of how Model-Based Design can be applied to develop an automotive lighting system using NXP hardware, focusing on the general architecture and design approach. In the following articles, we will explain the configuration, implementation, and deployment of the lighting system on the NXP hardware.

lowlight opensource ai-isp test on imx95   There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) FLOL cidautai/FLOL Lightweight CNN High SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low KinD zhangyhuaee/KinD Retinex + CNN Medium RetinexNet-lite Derived Light CNN Medium EnlightenGAN-lite Derived Small CNN Very High Fast LLIE CNN Various Small CNN High Tested above open-source models with UVC to perform performance evaluation on the exip-os08a20 module with linear mode. Found that SCI（GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexib...） computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed. weiping_liu_0-1784087656398.png i.MX Processors Sensor

PN7220 Android 16 Porting to i.MX95 FRDM EVK Board Introduction Many customers are using PN7220 + Android 16 recently. In this document, I will show you how to porting the PN7220 to Android 16. I use the i.MX95 FRDM board as a reference target board. NOTE :  All the modifications are just for reference. They are NOT a NXP official patches for the newer release of AOSP porting. So the modifications may not be the best solution. Customer please base on their needs to modify the AOSP source code. This is not for production. Customer still need to perform full testing after the porting.  Hardware boards: i.MX95 FRDM Board (FRDM i.MX 95 Development Board | NXP Semiconductors) FRDM-IMX95-TOP.jpg PN7220 EVK -- PNEV7220BP1 (PNEV7220BP1 Development Board for PN7220 NFC Controller | NXP Semiconductors) PNEV7220BP1-TOP-IMG.jpg There is a 40pins connector on both PN7220 EVK and i.MX95 FRDM board. So PN7220 + i.MX95 FRDM connecting together is like this: pn7220_imx95FRDM.jpg Build the Android BSP for i.MX95 FRDM board: The i.MX Android BSP that I used is Android 16.0.0_1.4.0 (L6.12.49_2.2.0 BSP). It could be downloaded from here: Android OS for i.MX Applications Processors | NXP Semiconductors 1. Download the "Documentation" and the "Install Source Package".  2. Follow the steps in Android User's Guide to build the Android BSP for "evk_95" first.  $ export MY_ANDROID=`pwd` $ source build/envsetup.sh $ lunch evk_95-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt According to the android_build/.repo/manifests/aosp-android-16.0.0_1.4.0.xml, you will see the AOSP version is android-16.0.0_r4. According to the PN7220 Android 16 porting guide (PN7160/PN7220 – Android 16 porting guide), the patches is for AOSP release android-16.0.0_r2. So fortunately, the AOSP release version between them is not big different.  Now, we start the porting: 1. Kernel Driver To establish connection with the PN7220, the Android stack uses the nxpnfc kernel driver.  You could download the driver from github below: nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev · nxp-nfc-infra/nfcandroid_platform_drivers · GitHub The command is : git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev There is driver for Kernel 6.6 and 6.12. So, please download the correct one for your porting. For example, the kernel in i.MX Android BSP Android 16.0.0_1.4.0 is 6.12. So I will use the 6.12 driver for my porting. In your porting, make sure the PATH in Makefile and Kconfig files are setting properly.  For example in my porting: android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7220$ tree . ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig └── Makefile 0 directories, 7 files For simplifying everything, we will only add a support for I2C and not SPI. Replace drivers/nfc/pn7220/Makefile default code with following code (for easier understanding) nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o The contents of drivers/nfc/Makefile. Add the PN7220 like below: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7220/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o The contents of drivers/nfc/Kconfig. Add the PN7220 like below: source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" source "drivers/nfc/pn7220/Kconfig" endmenu 2. Adding the "nxpnfc" to the i.MX95 FRDM board device tree file android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts We need to check the connection between two boards and then to decide which pins to use in the device tree file. Here is the 40 pins connector on the PN7220: PN7220EVK_40pinsConnector.jpg Here is the 40 pins connector on the i.MX95 FRDM board. FRDM-imx95-40pinsConnector.png FRDM-imx95-40pinsConnector_left.png FRDM-imx95-40pinsConnector_right.png According to the 40 pins connection between PN7220 EVK and the i.MX95 FRDM board, I decided to use the I2C6 and the GPIO2_20, GPIO2_21 and GPIO2_26. So, in the imx95-15x15-frdm.dts, I added: &lpi2c6 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpi2c6>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio2 26 0>; nxp,nxpnfc-ven = <&gpio2 21 0>; nxp,nxpnfc-mode_sw = <&gpio2 20 0>; }; }; And the IOMUX settings in the imx95-15x15-frdm.dts. pinctrl_nfc: nfcgrp { fsl,pins = < IMX95_PAD_GPIO_IO26__GPIO2_IO_BIT26 0x39e // IRQ IMX95_PAD_GPIO_IO21__GPIO2_IO_BIT21 0x39e // VEN IMX95_PAD_GPIO_IO20__GPIO2_IO_BIT20 0x39e // MODE_SW >; }; pinctrl_lpi2c6: lpi2c6grp { fsl,pins = < IMX95_PAD_GPIO_IO02__LPI2C6_SDA 0x40000b9e IMX95_PAD_GPIO_IO03__LPI2C6_SCL 0x40000b9e >; }; 3. Modify the imx95_gki.fragment File:  android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx95_gki.fragment Add the "CONFIG_NXP_NFC_I2C=m" into the imx95_gki.fragment 4. Add the settings in your corresponding board configuration files in Android - Go to the android_build/device/nxp/imx9/evk_95/  - Modify the BoardConfig.mk. # Add KVM support BOARD_BOOTCONFIG += androidboot.hypervisor.vm.supported=true + # ---- selinux permissive ---- + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive # -------@block_sepolicy------- BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx9/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc \ + vendor/nxp/emvco/sepolicy +include vendor/nxp/nfc/BoardConfigNfc.mk  - Add the "nxpnfc_i2c.ko" to the ShareBoardConfig.mk. Make sure the path and the filename are correct. ifeq ($(LOADABLE_KERNEL_MODULE),true) IMX_ANDROID_FIRST_STAGE_MODULES += \ $(KERNEL_OUT)/drivers/hwmon/hwmon.ko \ $(KERNEL_OUT)/drivers/hwmon/scmi-hwmon.ko \ .... .... .... $(KERNEL_OUT)/drivers/soc/imx/soc-imx9.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-adp5585.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-pca953x.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-vf610.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko .... .... BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/media/i2c/ap1302.ko \ $(KERNEL_OUT)/drivers/media/i2c/ox03c10.ko \ $(KERNEL_OUT)/drivers/media/i2c/max96717_lib.ko \ .... .... $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc-vf.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc4.ko \ $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/hwmon/pwm-fan.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko - Add the INxpNfc and INxpEmvco to the device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.ele 1 ISecureEnclave default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default  - Add the following to the evk_95.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc2-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx - Add the nxpnfc_i2c in init.rc exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep - Add nxpnfc to ueventd.nxp.rc /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc 5. Apply the NXP AOSP patches I write a script to download the patches from the github. The script file and the android_build folder is on the same directory. Run the AOSP_adaptation.sh.  AOSP_adaptation.sh # nfcandroid_nfc_modules git clone "https://github.com/nxp-nfc-infra/nfcandroid_modules_nfc.git" cd nfcandroid_modules_nfc git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/packages/modules/Nfc cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_16_comm_infra_dev mkdir ../android_build/packages/modules/Nfc/framework cp -rf * ../android_build/packages/modules/Nfc/framework cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_16_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_16_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. Apply a patch. $ cd android_build/system/logging $ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch Add TDA Test support: # Clone repositories for test applications and TDA support # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_16_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_16_comm_infra_dev cp -rf nfc_tda/ ../android_build/packages/modules/Nfc/libnfc-nci/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/ cd .. 6. Put changes into hardwatre/interfaces/compatibility_matrices  File: hardware/interfaces/compatibility_matrices/compatibility_matrix.202504.xml android.hardware.audio.effect 1-3 IFactory default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default nxp.hardware.ele 1 ISecureEnclave default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default android.hardware.authsecret 1 IAuthSecret default 7. Add the firmware $ git clone https://github.com/NXP/nfc-NXPNFCC_FW.git $ cp -r nfc-NXPNFCC_FW/InfraFW/pn7220/64-bit-2.5/pn7220_64bits.so android_build/vendor/nxp/pn7220/firmware/lib64/libpn72xx_fw.so 8. Add the NXPAndroidDTA $git clone https://github.com/NXPNFCProject/NXPAndroidDTA.git $cd NXPAndroidDTA $git checkout br_ar_new_dta_arch cp -r NXPAndroidDTA android_build/vendor/nxp/ 9. Some fixes before build: $ cd android_build $ mv hardware/nxp/nfc/snxxx/Android.bp hardware/nxp/nfc/snxxx/_Android.bp $ mv hardware/nxp/nfc/snxxx/halimpl/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl/power-tracker/_Android.bp $ mv hardware/nxp/secure_element/snxxx/aidl/Android.bp hardware/nxp/secure_element/snxxx/aidl/_Android.bp $ cd hardware/nxp/nfc $ rm pn8x -rf Now, build the Android BSP again. Use "mm" to build the Android source code. After fixed all the errors of the AOSP build, use "imx-make.sh" to build the whole i.MX Android image.  When building the Android, there may have some errors during the build. I listed some errors and the workaround below for your reference. Error: error: packages/modules/Nfc/tests/cts/tests/Android.bp:20:1: "CtsNfcTestCases" depends on undefined module "CtsAppTestStubsShared". Workaround : Comment out "CtsAppTestStubsShared" in packages/modules/Nfc/tests/cts/tests/Android.bp Error: error: hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp:17:1: "power_tracker_v2" depends on undefined module "nfc_nci_nxp_snxxx_headers_v2". Workaround: mv hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/_Android.bp Error: error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/NfcNci/nci/jni:libnfc-nci-jni-tests which is not visible to this module You may need to add "//platform_testing" to its visibility error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/libnfc-nci/tests:libnfc-nci-tests which is not visible to this module You may need to add "//platform_testing" to its visibility Workaround: nano packages/modules/Nfc/NfcNci/nci/jni/Android.bp In cc_test {     name: "libnfc-nci-jni-tests", .. ..     visibility: [         "//platform_testing:__subpackages__",     ], Same in packages/modules/Nfc/libnfc-nci/tests/Android.bp Error: FAILED: out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system-stubs.srcjar out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_annotations.zip out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_api.txt out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_removed.txt out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:52: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.emulateNfcTechnologyATag(boolean,byte,byte,byte,byte[],byte,byte[]) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:64: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.overwriteRoutingTable(int,int,int,int,int) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:77: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_INTERNAL [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:78: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_NFC_NOT_ENABLED [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:79: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_OK [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:120: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.Callback.onRoutingChangeCompleted() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:160: error: Binary breaking change: Removed method android.nfc.RoutingStatus.getDefaultFelicaRoute() [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Comment out the lines 52,64,77,78,79,120,160 in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest Error: out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:77: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isExitFramesSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:80: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeEnabled() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:81: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:91: error: Binary breaking change: Removed method android.nfc.NfcAdapter.setPowerSavingMode(boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:196: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:197: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopPatternFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:202: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceScreenOnRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:203: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceUnlockRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:214: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceScreenOnForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:215: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceUnlockForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:248: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.NfcEventCallback.onOffHostAidSelected(String,String) [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Same as the previous workaround. Comment out the lines (line number shown in error) in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest. Error: FAILED: out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw out/host/linux-x86/bin/checkpolicy -C -M -L -c 30 -o out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw out/soong/.intermediates/system/sepolicy/vendor_sepolicy.conf/android_common/evk_95/vendor_sepolicy.conf && out/host/linux-x86/bin/build_sepolicy filter_out -f out/soong/.intermediates/system/sepolicy/reqd_policy_mask.cil/android_common/reqd_policy_mask.cil -t out/soong/.intermediates/system/sepolicy/vendor_sepolicy.cil.raw/android_common/evk_95/vendor_sepolicy.cil.raw # hash of input list: 7a5f97fdfa590e2ec5a2c6b745c65293680d0202c9b5869c1425905c209b9bf1 vendor/nxp/emvco/sepolicy/service.te:1:ERROR 'Duplicate declaration of type' at token ';' on line 21764: type hal_emvco_service, hal_service_type, service_manager_type; #line 1 "vendor/nxp/emvco/sepolicy/service.te" checkpolicy:  error(s) encountered while parsing configuration 11:50:27 ninja failed with: exit status 1 Workaround: nano vendor/nxp/emvco/sepolicy/hwservice.te Change the hal_emvco_service to hal_emvco_hwservice like this: type hal_emvco_hwservice, hwservice_manager_type; nano vendor/nxp/emvco/sepolicy/hwservice_contexts vendor.nxp.emvco::INxpEmvco                             u:object_r:hal_emvco_hwservice:s0 nano vendor/nxp/emvco/sepolicy/hal_emvco_default.te + allow hal_emvco_default hal_emvco_hwservice:hwservice_manager { add find }; Error: FAILED: out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp if [ $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) = $(tail -1 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash') ]; then touch out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp; else cat 'system/tools/aidl/build/message_check_integrity.txt' && exit 1; fi ############################################################################### # ERROR: Modification detected of stable AIDL API file                        # ############################################################################### Above AIDL file(s) has changed, resulting in a different hash. Hash values may be checked at runtime to verify interface stability. If a device is shipped with this change by ignoring this message, it has a high risk of breaking later when a module using the interface is updated, e.g., Mainline modules. Workaround: echo $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) d9e99a62ff5ebed44083a79577ec7ed32d264775 Then,  nano hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash replace the value to d9e99a62ff5ebed44083a79577ec7ed32d264775 A runtime error: Problem: You will find the following failed about the permission in the log. java.lang.IllegalStateException: Signature|privileged permissions not in privileged permission allowlist: {com.android.nfc (/apex/com.android.nfcservices/priv-app/[email protected]😞 android.permission.OBSERVE_ROLE_HOLDERS} Workaround: Add :                 To the file : out/target/product/evk_95/system/etc/permissions/privapp-permissions-platform.xml 10. Download the image to the target board: - We use the tool UUU to download the image to the i.MX boards. Download the UUU from here : Releases · nxp-imx/mfgtools - Download the Android 16 BSP i.MX95 EVK demo image from the Android i.MX BSP web page first. There are UUU script and necessary image files already in the demo image package.  demo_image.png - Put the UUU executable file into the demo image folder. uuu_imx_android_flash.bat is the script also in the same folder. - After your Android BSP building is completed and succeed, copy the images to the demo image folder. The image files are located in android_build/out/target/product/evk_95/. - Switch the boot mode to "Download" mode on the i.MX95 FRDM board. - Run the UUU script to download the images to the FRDM board. uuu_imx_android_flash.bat -f imx95 -a -e -u 15x15-frdm -d 15x15-frdm uuu.png Run the "TagInfo" on the board: - Download the TagInfo apk file from the NXP TagInfo App web page . - Use the "adb install" command to install the TagInfo to the FRDM board. C:\>adb install com.nxp.taginfo-6.2.0-play-release-protected.apk * daemon not running; starting now at tcp:5037 * daemon started successfully Performing Streamed Install Success After TagInfo installed, the TagInfo icon will be available on the GUI. taginfo1.jpg Run the TagInfo, and then put a card on the board. taginfo5.jpg taginfo4.jpg The information of the card will be show on the TagInfo App. taginfo3.jpg taginfo2.jpg nxp.png Reference: PN7160/PN7220 – Android 16 porting guide PN7220 NFC Frontend IC with Integrated Power Management | NXP Semiconductors Android OS for i.MX Applications Processors | NXP Semiconductors nxp-nfc-infra · GitHub

S32 Design Studio - Export and Debug 1 Table of Contents • Introduction • Open the generated project in S32 Design Studio • Debug the generated application in S32 Design Studio • Debug the code generated from the Simulink model • Conclusion 2 Introduction This article explains how to take a project generated with the Model-Based Design Toolbox (MBDT) in Simulink and open, build, and debug it in S32 Design Studio. It focuses on the transition from model execution in Simulink to target-level debugging and validation on S32 hardware. 3 Open the generated project in S32 Design Studio MBDT generates code from Simulink models and exports it as an S32 Design Studio-compatible project. After a successful model build, the generated _Config folder contains the files required by the IDE. The project can then be opened directly from Simulink or imported into S32 Design Studio for further configuration, building, and debugging on S32 hardware. Before opening or debugging the project in S32 Design Studio, build the Simulink model. The build process generates the code and project structure required for IDE integration. You can open the generated project either directly from Simulink or manually from within S32 Design Studio. Use the Simulink option when you want to launch the generated project immediately after configuration. Use the IDE import option when you want to manage the project manually from an S32 Design Studio workspace. Open the project from Simulink To open the project from Simulink, open the model Hardware Settings from the Hardware tab or press Ctrl + E. Then go to Hardware Implementation → Hardware board settings → Target hardware resources → S32 Design Studio Project and select Open. ModelSettings.png Figure 1. S32 Design Studio project settings in Simulink A dialog appears and prompts you to select the S32 Design Studio installation path. CristinaGrosu_0-1784029205090.png Figure 2. S32 Design Studio installation path selection To select the S32 Design Studio installation path later, or to change it during toolbox usage, click Browse in the S32 Design Studio location field under the Tools Paths group. CristinaGrosu_1-1784029276242.png Figure 3. S32 Design Studio path changing The generated project opens in S32 Design Studio and is ready to build, configure, or debug. CristinaGrosu_2-1784029297722.png Figure 4. Generated project opened in S32 Design Studio Open the project inside the IDE To import the project manually into S32 Design Studio, follow these steps: Inside the IDE, select File → Import → Existing Projects into Workspace. CristinaGrosu_3-1784029322172.png Figure 5. Importing an existing project into the workspace Browse for the _Config folder in Select root directory. Before clicking Finish, make sure that Copy projects into workspace is disabled. If the project is copied into the S32 Design Studio workspace, the build process will fail. CristinaGrosu_4-1784029341994.png Figure 6. Directory selection for the generated project 4 Debug the generated application in S32 Design Studio To build and debug the project in S32 Design Studio, select the project and click Debug. S32 Design Studio builds the project and automatically switches to the Debug perspective. Note: Ensure that the target hardware board is connected before starting the debug session. CristinaGrosu_5-1784029377307.png Figure 7. Starting the debug session CristinaGrosu_6-1784029402671.png Figure 8. Debug perspective in S32 Design Studio After the debugger launches and the application is loaded on the target, you can use the following actions to control program execution and inspect the generated code: The Breakpoint action sets a breakpoint when you double-click in the left margin of a .c file:   CristinaGrosu_9-1784029512145.png Figure 9. Breakpoint set in the generated source file The Step Over (F6) action executes the current line while remaining in the same function: CristinaGrosu_10-1784029574437.png Figure 10. Step Over action in the Debug toolbar The Step Into (F5) action enters a called function: CristinaGrosu_11-1784029598699.png Figure 11. Step Into action in the Debug toolbar The Step Return (F7) action runs to the end of the current function: CristinaGrosu_12-1784029621660.png Figure 12. Step Return action in the Debug toolbar The Resume (F8) action runs until the next breakpoint: CristinaGrosu_13-1784029651085.png Figure 13. Resume action in the Debug toolbar CristinaGrosu_14-1784029663308.png Figure 14. Breakpoint reached after pressing Resume action The Suspend (F9) action pauses execution at the current instruction: CristinaGrosu_15-1784029686055.png Figure 15. Suspend action in the Debug toolbar CristinaGrosu_16-1784029703191.png Figure 16. Function paused after pressing Suspend action The Terminate (Ctrl + F2) action stops the debug session and disconnects from the target: CristinaGrosu_17-1784029727404.png Figure 17. Terminate action in the Debug toolbar The Disconnect action leaves the target running while detaching the debugger: CristinaGrosu_18-1784029746404.png Figure 18. Disconnect action in the Debug toolbar 5 Debug the code generated from the Simulink model The code generated by the Simulink model can be found in the _step() function. To enter this function, set a breakpoint before the function call, run the application until the breakpoint is reached, and then select Step Into. Alternatively, Ctrl + Click the function name to open the function and place a breakpoint inside it. CristinaGrosu_19-1784029773923.png Figure 19. modelName_step function In this function, you will also find the generated code for the blocks placed inside the Simulink model. CristinaGrosu_20-1784029789766.png Figure 20. Generated step function in the source code To monitor variable values, hover over a variable to see its current value: CristinaGrosu_21-1784029811632.png Figure 21. Variable value displayed on hover Alternatively, add the variable to the Expressions view by selecting Add new expression, entering the variable name, and pressing Enter. CristinaGrosu_22-1784029836554.png Figure 22. Add new expression in Expressions view CristinaGrosu_23-1784029861694.png Figure 23. Variable added to Expressions view Upon running the code, if the value changes, it will be highlighted. CristinaGrosu_24-1784029881749.png Figure 24. Variable value highlighted during debug The names of the variables in the generated code are the same as the names they have in the Simulink model, making it easier to debug the generated code. CristinaGrosu_25-1784029904920.png Figure 25. Variable name in Simulink model and generated code 6 Conclusion After identifying the generated function and monitoring key variables, you can validate how the Simulink model behavior maps to the generated application running on the target hardware. For more tutorials on installing, activating, and using S32 Design Studio, see the S32 Design Studio tutorials on the community page: S32 Design Studio Knowledge Base.

MCTPTX1AK324、FreeMASTER接続の問題 0x80000101 モーター開発にはMCTPTX1AK324の開発ボードを使っています。今、ボタン3を押すとモーターは動きます。設定を調整するためにMCATホストコンピュータを使う必要があります。しかし、シリアル接続でfreeMASTERを使うとエラーが表示されます:接続タイムアウト、0x8000 0101。デモプログラムに変更が必要かどうか確認してもらえますか? 現在、デモプログラムの一部のコードがブロックされています。M3でGD3000とIPCFを初期化するとプログラムがフリーズするため、FAEの提案に基づいてブロックしました。 3Q Re: MCTPTX1AK324, FreeMASTER connecttion problem 0x80000101 こんにちは、 FreeMASTERの接続タイムアウト問題を解決するための一般的なヒントをいくつかご紹介します。それでも効果がなければ、より具体的なサポートを求めてモータ制御チームに連絡してみます。 一般的に、タイムアウトとは、ボードがFreeMASTERコマンドに応答しないことを意味します。以下のことをお勧めします。 1. NXPから受け取ったオリジナルの未修正ソフトウェアを使用し、オリジナルのボードキットを使用することを確認してください。 2. 接続ポートとケーブルを確認してください。FreeMASTERで「プロジェクト」→「オプション」に進み、シリアルCOMポートを確認してください。システムに他にもポートがあって、間違ったものを選んだ場合もあります。 3. ツール/接続ウィザードを使用して、さまざまなCOMポートを検査します。 4. FreeMASTERを別のアプリケーションで使うようにしましょう。理想的には、ターゲットボードでFreeMASTERサンプルアプリケーションが利用可能であれば、そのアプリケーションのいずれかを利用してください。 5. 上級編：オシロスコープまたはロジックアナライザをシリアル通信ラインに接続して、RX信号とTX信号がアクティブかどうかを確認します。FMSTR_ProtocolDecoderにブレークポイントを設定して、コードがそこで停止するかどうかを確認してください。そうでなければ、コマンドはMCUにすら届きません。 よろしくお願いいたします。 ミハル