GCC10.2工具链安装失败 屏幕截图 2026-07-27 091847.png Re: GCC10.2工具链安装失败 你试过重启电脑再测试一次吗？

このシステムは、IMX8MPプラットフォーム、SGTL5000サウンドカード、およびLinuxカーネルバージョン5.4.70を使用しています。音声再生時に、カーネルに「アンダーラン」メッセージが表示され、サウンドカードのDMA（データ転送解析）機能が正常に動作しなくなります。 メインコントローラー：imx8mp カーネル: Linux 5.4.70 サウンドカード：SGTL5000 アプリケーション：mmapを使用してデータをDMAバッファに移動します。 障害の症状: アプリケーションが一定時間オーディオを再生すると、カーネルに次のエラーメッセージが表示されます: fsl-sai 30C3000.sai: isr:Transmit。「アンダーランが検出されました」というメッセージが画面に表示され、特定のカーネルファイル（./kernel/kernel-5.4.70/sound/soc/fsl/fsl_sai.c）に対応しています。 .......... if(flags & FSL_SAI_CSR_FEF) { dev_dbg(dev,"isr:送信アンダーランを検出しました\n"); /* 安全のためFIFOをリセット */ xcsr |= FSL_SAI_CSR_FR; } .......... 同時に、`cat /proc/interrupts | grep sdma` コマンドを使用してサウンドカードの DMA 割り込み数をチェックし、増加しないようにします。 現在のコード構成では、FIFOがアンダーランするとFIFOの状態が異常になり、それが原因でDMAが誤動作するというのは本当でしょうか？ IMX8MPの仕様を見ると、次のような説明があります。FCONT: IMX8MP PRMドキュメント14.4.2.7.3。FIFOエラー継続が有効になっている場合、FIFOはアンダーラン後もソフトウェアの介入なしにデータの送信を継続します。データが正しい順序で送信されるようにするため、送信機は、FIFO がアンダーランしたフレーム内の同じワード番号から処理を続行しますが、送信 FIFO に新しいデータが書き込まれた後にのみ続行します。 仕様書に記載されているこの構成によると、この状況でDMAがアンダーランした後でも、正常に動作し続けることができるのでしょうか？DMAがデータをFIFOに移動すれば、以前のDMAが誤動作してFIFOがアンダーランする代わりに、以前のサウンドを再生し続けることができるのでしょうか？ Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 こんにちは@zhuliushun 1. FCONTの理解は基本的に正しいが、FCONTは根本的な解決策ではない。 2. 根本的な原因は、TX FIFOの供給速度が消費速度よりも遅いことです。この点を確認して、原因を特定してください。 3. 次の2つのパッチのインストールを検討してください。 LKML: Shengjiu Wang: [PATCH] ASoC: fsl_sai: 「FIFO continue on error」FCONTビットを有効にする ASoC: fsl_sai: ISR 内の不要な FIFO リセットを削除 - Patchwork よろしくお願いします、 志明 Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 こんにちは@Zhiming_Liu はい、この問題の原因は、FIFOへのデータ充填速度がFIFOのデータ消費速度よりも遅いことです。そして、FIFOへのデータ充填はDMAに基づいています。 1. 現在のデバッグにより、FIFOが空になるとアンダーランが発生し、DMAも動作を停止するため、FIFOが補充されなくなることが明らかになりました。 2.投稿にある 2 つのパッチを適用した後、デバッグの結果、FIFO がまだアンダーランしており、DMA が機能していないことが判明しました。 fsl_sai.c の割り込みコールバック関数 fsl_sai_isr() では、xcsr と tcr4 の値が出力されます。詳細は以下を参照してください。 fsl-sai 30c30000.saiscsr :ステータス:0xd0170c01 fsl-sai 30c30000.sai isr: 送信インダランを検出しました、tcr4: 0x18010f3a 不具合が発生した際、前述の印刷処理によって画面が繰り返し更新された。 3. 2の知見に基づくと、tcr4のbit[28]は=1、 FCONTが有効です。 4. 私の問題について：オーディオファイルの再生がフリーズします（FIFOアンダーラン、DMAが動作しない、停止）。私が望む解決策は、FIFOアンダーランが発生した場合、ハードウェアデータを保持し、リセットせずに現在の状態を移動させ、DMAは正常に動作することです。バッファにデータが利用可能になったとき（アプリケーションがmmapを使用してデータを埋めたとき）、 DMA（FIFOからのDMA要求に基づく）はデータをFIFOに移動し、オーディオファイルの再生を継続できるようにします。これは実現可能でしょうか？

Legacy Software License Codewarrior 10.4.1 Hello, is there a way to use codewarrior 10.4.1 for legacy devices like Power Quicc III with a free license at this time 2026? Re: Legacy Software License Codewarrior 10.4.1 Hello, There is no free/Special Edition available for CodeWarrior for Power Architecture (the tool supporting PowerQUICC III, e.g., MPC85xx family). PowerQUICC III devices (MPC8540, MPC8548, MPC8560, MPC8572, etc.) are supported by CodeWarrior Development Studio for Power Architecture v10.x, which requires a paid license (Basic, Standard, or Professional suite). The paid options through NXP are: CW Development Suite – Basic – Lowest tier, includes Power Architecture (Eclipse, Windows & Linux hosts), but may have code/data size limitations. CW Development Suite – Professional – Full-featured, no size limitations, includes Classic and Eclipse IDEs, Linux and Windows. CW Development Suites for Networked Applications – Specifically targets PowerQUICC I/II/II Pro/III, QorIQ P/T-series, and Layerscape.   Regards

圧力センサの導入RDK358BMU推奨。 RD-K358BMU RDK358BMU評価ボードの作成に取り組んでおり、圧力センサの導入計画を進めています。 以下の情報をご協力いただけますか? 1.RDK358BMUで使用する際の推奨される圧力センサーの部品番号は何ですか? 2. NXPのリファレンスデザインで使用または検証された特定の圧力センサーはありますか? 3. センサーインターフェース、接続情報、起動に必要なソフトウェア設定も共有していただけますか? BMUとの圧力センサ統合に関するドキュメントやアプリケーションノートも教えていただけると助かります。 Re: Pressure sensor recommendation for RDK358BMU pressure sensor bring-up. こんにちは、 @shweta_jagadale さん。 1. & 2.RDK358BMUは高集積バッテリー圧力モニターセンサーNBP8-9xを使用しています。 3. 圧力センサーの接続やプログラミングについては、圧力センサーのデータシートを参照してください。 RD-K358BMUユーザーガイドには圧力センサーホースポートも説明されています。 最後に、RD-K358(S32K358)に必要なソフトウェア関連のすべては、当社の自動車ソフトウェアパッケージマネージャーからご覧いただけます。 また、ホストMCU用のアプリケーションソフトウェアがNBP8 – KE15Z FreeMASTERデモに接続されています。 よろしくお願いします、 ジュリアン

FRDM-A-S32K344 板载仿真器如何支持 comsis-dap 或 jlink？ 恩智浦半导体推出了FRDM-A-S32K344通用开发板。然而，板载模拟器不支持 comsis-dap 和 jlink，这严重阻碍了它在 Zephyr 固件烧录、调试和 VSCode 开发等一般应用程序中的使用。未来是否有这方面的支持计划？

关于 MRF300AN 27MHz 参考设计中 C16 电容额定值的问题 您好，NXP支持团队， 我目前正在审查 MRF300AN 27MHz 参考设计，对输出端的电容 C16 有一个疑问。 根据我手头的物料清单（例如，来自 Farnell 的数据手册），C16 被指定为 39,000 pF (39 nF) / 50V 的贴片电容（ATC 零件号 200B393KT50XT） 。鉴于 MRF300AN 的工作漏极电压为 50V，且输出级需处理高射频功率（高达 300W 以上），我担心在此位置使用 50V 额定值的电容可能不足以保证长期可靠运行。 我的问题是： 物料清单中 C16 的额定电压为 50V 是否正确，还是可能是笔误？ 在这个电路中，C16 的具体作用是什么？它是输出匹配网络的一部分、直流阻隔电容，还是旁路/去耦电容？ 如果它确实是射频输出路径中的直流阻隔或匹配电容，那么使用更高电压额定值（例如 100V 或更高）的电容来处理电压瞬变和驻波岂不是更合适？ 非常感谢您能就此事作出澄清。感谢您的时间和支持。 顺祝商祺！ Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会！ 300W 并不能直接决定电容上的电压应力。 电容的额定电压必须与该电容两端的实际射频电压进行比较，而不是与放大器的输出功率进行比较。 C16 不一定能看到完整的射频输出电压。 根据参考设计物料清单，C16 属于电源去耦/射频旁路网络，而不是直接跨接在 50 Ω 输出连接器上。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 亲爱的 RafaR， 感谢您详尽且有帮助的回复。我非常感谢您抽出时间解释电容的电压应力问题。 我想承认您说得完全正确——C16 两端的电压没有射频输出电压那么高，因为电压应力取决于元器件两端的实际射频电压，而不是放大器的输出功率。我完全同意这一点。 不过，关于 C16，我想澄清一点。仔细检查我手头的 PCB 布局后，假设所有走线都布线在顶层，那么 C16 看起来确实是位于 RF 输出之前的直流阻隔电容器。我知道这可能与您文档中的物料清单名称有所不同，但根据我目前可以访问的布局文件，这是我观察到的情况。 目前我下载的资料仅包括 PCB 布局文件和一份简要概述文档——我无法访问完整的原理图、包含元器件功能的详细物料清单或完整的参考设计用户指南。 能否提供该参考设计的更详细文档，例如： 完整示意图 包含元器件功能描述的完整物料清单 参考设计用户手册或应用说明 如果您能提供任何其他资料，我将不胜感激。如果分享这些文件有任何限制，也请告知我，以便我可以通过正规渠道申请获取。 再次感谢您的指导，期待您的回复。 此致， 风雨绮 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会！ 遗憾的是，NXP提供的该设计文档包中不包含原理图。由于大多数射频设计对电路板布局都很敏感，因此这是我们的常规做法。因此，布局视图加上物料清单比单纯的原理图能提供更具可重复性的结果。如果需要，您可以自己使用布局图和物料清单绘制原理图。 遗憾的是，我们没有 27MHz 频段的 MRF300 参考设计。 我们推荐的文档位于我们官方网站的“设计资源”部分： RafaR_0-1784737806340.png 但是，这种设计已经实施了好几年，所以我可以向您保证，我们提供的文档中列出的物料清单是正确的。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 由此给您带来的不便，我们深表歉意。 祝你今天过得愉快，一切顺利。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 亲爱的 RafaR， 非常感谢您之前的回复以及分享的设计资源。我已经按照您的建议审查了布局和物料清单，现在正准备制作自己的原型。在继续之前，我想就元器件选择和可能的修改提出几个具体问题： 电容器替换——物料清单中列出的一些 ATC 电容器在我所在的地区很难找到。我正在考虑使用 Vishay RF 电容，其关键规格类似，例如 39 pF、C0G/NP0 介质和相同的额定电压。根据您的经验，如果其他参数（如 ESR、Q 值和自谐振频率）相当，那么这种替换是否安全？还有其他我应该特别注意的隐藏特征吗？ C10 的值变化 – 在我的 ADS 模拟中，我发现用 200 pF 电容替换 C10 可以明显提高效率。您会建议在实际电路板上进行此项更改吗？如果是这样，在这样做之前我应该评估一下是否存在任何稳定性或散热方面的问题吗？ 调试方法——由于没有提供原理图，我计划使用布局图和物料清单作为主要参考。我假设我对电路理解上的细微偏差可以通过对原型进行实际调整和测量来解决。您认为这种做法是否合理？或者您预见到是否存在任何重大风险？ 我非常感谢您抽出时间给予指导。如果以上任何问题需要进一步澄清，请随时告诉我。 祝您今天过得愉快，并致以最诚挚的问候！ 风雨绮 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会！ 电容替换 遗憾的是，NXP 没有推荐的替代品，而且我也没有机会尝试 BOOM 中列出的元器件以外的元器件，因此我们无法保证它们的功能。 但是，根据我的研究，只有当您之前提到的参数相同时，这些替换方案才可行。如果可能的话，我还会考虑封装几何形状和散热情况。 C10 值变化 如果你已经运行过模拟并且看到了改进，那就继续吧。 调试方法 当然，我认为这是一个很好的方法；通常情况下，小错误可以通过对布局进行一些小的修改来修复，所以我认为这样做没有任何风险。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。

レガシーソフトウェアライセンス Codewarrior 10.4.1 こんにちは、 2026年現在、Power Quicc IIIのような旧型デバイスで、無料ライセンスを使ってCodeWarrior 10.4.1を使用する方法はありますか？ Re: Legacy Software License Codewarrior 10.4.1 こんにちは、 PowerQUICC IIIをサポートするツール(例:MPC85xxファミリー)のためのCodeWarrior for Power Architectureには無料または特別版はありません。 PowerQUICC IIIデバイス(MPC8540、MPC8548、MPC8560、MPC8572など)は CodeWarrior Development Studio for Power Architecture v10.xでサポートされており、 有料ライセンス (Basic、Standard、またはProfessionalスイート)が必要です。 NXPを通じて利用できる有料オプションは以下のとおりです。 CW開発スイート – Basic – 最下位クラスで、Power Architecture(Eclipse、Windows、Linuxホスト)を含みますが、コードやデータサイズの制限がある場合があります。 CW開発スイート – プロフェッショナル – フル機能でサイズ制限なし、ClassicおよびEclipse IDEs、LinuxおよびWindowsを含みます。 ネットワークアプリケーション向けCW開発スイート – 特にPowerQUICC I/II/II Pro/III、QorIQ P/Tシリーズ、Layerscapeを対象としています。   よろしくお願いします。

Pressure sensor recommendation for RDK358BMU pressure sensor bring-up. RD-K358BMU  I am working on the RDK358BMU evaluation board and am planning the pressure sensor bring-up. Could you please help with the following information: 1. What is the recommended pressure sensor part number for use with the RDK358BMU? 2. Is there a specific pressure sensor used or validated in the NXP reference design? 3. Could you also share the sensor interface, connection details, and any software configuration required for bring-up? Any reference documentation or application notes related to pressure sensor integration with the BMU would also be appreciated. Re: Pressure sensor recommendation for RDK358BMU pressure sensor bring-up. Hi @shweta_jagadale, 1. & 2. RDK358BMU uses the Highly Integrated Battery Pressure Monitor Sensor NBP8-9x.  3. You can refer to pressure sensor datasheet for more information about connection and programming of the pressure sensor.  The RD-K358BMU User Guide also describes the pressure sensor hose port. Lastly, you can find all of the related SW needed for the RD-K358 (S32K358) from our Automotive Software Package Manager. There is also the Application Software for the Host MCU connected to the NBP8 – KE15Z FreeMASTER demo. Best regards, Julián 

Methods to update NBU firmware on KW47 and MCX W72 This post provides guidance on how to update the NBU firmware on MCX W72 and KW47 devices through several methods: Bootloader Host Application (blhost), Secure Provisioning Tool, LinkServer. The Narrow Band Unit (NBU) is a dedicated compute subsystem for the Narrowband Radio, present in select NXP wireless microcontrollers. It is comprised of an Arm® Cortex®-M33 and associated peripherals that, in conjunction with the Bluetooth Unit, support the Bluetooth LE protocol. Running at 96 MHz alongside a 2.4 GHz transceiver, the NBU operates independently from the main application core, offloading all radio processing from the primary CPU and freeing it for application tasks. While the NBU allows for flexibility for evolving requirements, firmware to implement radio protocols is intended to be developed and delivered by NXP. Note: It is important that the NBU firmware version matches the SDK version of the application. After downloading the SDK and before running any wireless examples, update the NBU firmware using the binaries provided in the SDK folder. The NBU binary file is located in the SDK folder. Go to the SDK root folder and open the path: path_to_SDK\mcuxsdk\middleware\wireless\ble_controller\bin Prerequisites To follow this guide, the following environment is required: Software Setup Bootloader Host Application (blhost). Download here. MCUXpresso Secure Provisioning Tool. Download here. LinkServer for Microcontrollers. Download here. Hardware Setup Development boards associated with the MCX W72 or KW47 microcontroller families may be used. The ISP button varies by board and is referred to as ISP_button  throughout this guide: Development board ISP_button FRDM-MCXW72 SW3 MCXW72-LOC SW4 KW47-EVK SW4 KW47-LOC SW4 To set the board to the Bootloader ISP mode, press and hold the ISP_button , connect the development board via the MCU-Link connector to the PC, then release ISP_button . Bootloader Host Application (blhost) Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. Verify the COM port assigned to the board by opening Device Manager in Windows and searching for Ports (COM & LPT). Identify and note the corresponding COM port number. Open a command prompt and change the directory to the location of the blhost.exe file: (BLHost_root_location)\blhost_2.6.7\bin\win Verify communication by running the following command, making sure to replace COMX with the COM port assigned to your device: blhost.exe -p COMX get-property 1 Update the NBU firmware image. First, erase the NBU memory: blhost.exe -p COMX flash-erase-all 2 Write the new firmware image using the following command. The write-memory command uses 0x48800000 as the start address, which corresponds to the NBU memory base. Provide the full path to the binary file, or alternatively, copy the .bin file into the same directory as blhost.exe to simplify the command: blhost.exe -p COMX write-memory 0x48800000 .bin sofiaurueta_0-1784588034793.png MCUXpresso Secure Provisioning Tool Create a workspace for the device. To use the keys same as the development board, select the processor relevant to the FRDM/EVK board. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. To verify communication, click the UART tab, refresh the Port field selection and select the assigned COM Port identified. Click Test connection and confirm that the result displays OK. In the toolbar, select the boot type as Plain unsigned or Plain with CRC. In the Build Image view, load the binary file in Source executable image, enter the start address as  0x48800000  (which corresponds to the NBU memory base), and click Build image. SECTool_1.jpg Navigate to the Write Image view, select Use built image, and click Write image. SECTool_2.jpg A success message appears when the NBU firmware loading is complete. LinkFlash Tool For this method, a LinkServer debug probe must be available on the board. The steps on how to install the CMSIS-DAP/SEGGER J-link firmware are available here. Navigate to the main LinkServer folder in your computer and execute the  LinkFlash.exe  file. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. In the LinkFlash tool, after the device is connected, click the Refresh button to update and set the probe target of the board. Go to the Program tab, click Browse, select the NBU firmware file, and enter the start address  0x48800000 . Ensure to check the boxes Mass erase before programming and Reset target after programming. To load the NBU firmware, click Program. LinkFlashTool.jpg

T1042 LAW 与 CCSR 内存映射对比 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我试图理解 LAW& CCSR 的概念，以及 LAW 和 CCSR 内存映射之间的区别，但在阅读 T1040 RM 后，我无法澄清自己的观点。例如，T1040 RM 中的表 2-3（LAWs 内存映射）显示 IFC 映射到地址 0x80000000，而表 2-5（CCSR 内存映射）显示 IFC 位于 0xFF124000。 有人能澄清一下司机实际使用哪些地址（LAW 或 CCSR）来访问设备吗。 QorIQ T1 设备 Re: T1042 LAW vs CCSR Memory Maps 这是一个非常有趣的问题，你所指出的区别一开始肯定会让人感到困惑。根据我的了解，驱动程序在与硬件模块交互时通常依赖CCSR视图，而LAWs则在更高层次上描述这些区域是如何转换的。我在查阅蒙哥马利郡法院 时发现了一些有用的背景资料，其中解释了不同的映射如何可以共存，以实现不同的访问目的。将 LAW 视为翻译规则，而将 CCSR 视为实际使用的寄存器访问视图，可能会有所帮助。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这些是各自的 FCM（闪存控制机器）控制器使用的基地址。例如 与非 使用 SRAM 作为缓冲区，使用 0xFF800000 你可以达到这个缓冲区。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 感谢亚历山大-雅科夫列夫。从理论上讲，我已经理解了其中的区别，但是以下 T1042D4RDB 板的设备树片段中提到的是，IFC 控制器（本地总线）是 @ 0xFFE124000（CCSR 内存映射）。而地址映射属性 “ranges” 提到了来自 LAW 地址空间的父地址（在 u-boot 的定律中，地址 0xfe8000000、0xfff800000、0xfffdf0000 设置为 或非、与非 和 cpld。文件) localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; 我希望你能理解我的困惑所在。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本地访问窗口（LAW）用于配置处理器地址空间如何映射到目标接口--DDR 控制器、IFC 控制器、PCI-E 等。 CCSR 空间是处理器内部内存映射寄存器映射到地址空间的空间。 表 2-3 将 IFC 显示为 " 目标 "-可通过此窗口访问连接到 IFC 控制器的目标设备。 表 2-5 列出了与 IFC 相关的内存映射寄存器，即用于配置 IFC 控制器的寄存器。 祝您愉快！ Alexander TIC ----------------------------------------------------------------------------------------------------------------------- 注：如果本帖回答了您的问题，请点击正确答案按钮。Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps T1042 LAW 和 CCSR 内存映射之间的区别很有意思，尤其是在研究内存区域的组织和访问方式时。清晰的地址范围文档可以大大简化技术比较。我还发现，查阅结构化的格林维尔县记录可以很好地说明组织化的信息如何支持高效的研究。总而言之，对于任何从事内存映射概念研究的人来说，这都是一个很有帮助的主题。

MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremetal S Hi,I am using the FLASH_ECC_Error_Injection_MPC5744P demo project from SDK 2.1 to test FLASH ECC fault handling. In the bare-metal SDK example:After calling Generate_noncorrectable_FLASH_ECC_error, the core properly traps the fault and enters Machine_check_handler (IVOR1 Handler) as expected. After porting the identical ECC injection logic to my RTOS-based project:No machine check exception occurs, and the code never jumps into Machine_check_handler. I have already completed the following porting & configuration steps: Fully ported and defined IVOR1_Handler in the startup .s assembly file, consistent with the bare-metal demo; Full FCCU alarm interrupt configuration is implemented, but no FCCU alarm interrupt is triggered either when injecting the uncorrectable FLASH ECC error. I have 3 core questions to troubleshoot this issue: What mandatory hardware/register configurations are required to enable entry to the Machine Check Handler (IVOR1) for FLASH uncorrectable ECC errors? Are there special considerations or constraints when running ECC fault injection and machine check exception handling under an RTOS? Could you provide a step-by-step debug/troubleshooting workflow to locate the root cause of this missing machine check exception? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet I don't know mentioned example, I suppose it is ported version on my appnote I did with using of GHS compiler. https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip If RTOS affects the bahavior, then it is needed to investigate what is does with MSR register. Pay attention to chapter 5. Also you may check section 8 to understand ECC handling. Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet HI, I found during testing: In my project, the IVOR1_Vector handler cannot be triggered when compiling with -O1 optimization level. The exception works normally under -O0. However, the reference demo project works correctly with -O1 using the same optimization setting. I would appreciate it if you could share some suggestions to help me locate the root cause.

MPC5744P IVOR1 机器检查处理程序在 RTOS 和裸机上未触发不可纠正的 FLASH ECC 错误 您好，我正在使用 SDK 2.1 中的FLASH_ECC_Error_Injection_MPC5744P演示项目来测试 FLASH ECC 故障处理。 在裸机 SDK 示例中：调用 Generate_noncorrectable_FLASH_ECC_error 后，内核正确地捕获了故障，并按预期进入了 Machine_check_handler（IVOR1 Handler）。 将相同的 ECC 注入逻辑移植到我的基于 RTOS 的项目中后：没有发生机器检查异常，代码也从未跳转到 Machine_check_handler。 我已经完成了以下移植和配置步骤： 已在启动文件中完全移植并定义了 IVOR1_Handler。与裸机演示一致的汇编文件； 已实现完整的 FCCU 报警中断配置，但注入不可纠正的 FLASH ECC 错误时，也不会触发 FCCU 报警中断。 为了解决这个问题，我有三个核心问题： 要使机器检查处理程序 (IVOR1) 能够处理 FLASH 不可纠正的 ECC 错误，需要哪些强制性的硬件/寄存器配置？ 在实时操作系统 (RTOS) 下运行 ECC 故障注入和机器检查异常处理时，是否存在特殊考虑或限制？ 能否提供一份分步调试/故障排除工作流程，以查找此机器检查异常缺失的根本原因？ Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 我不了解提到的例子，我猜它是我在应用笔记中使用 GHS 编译器编写的移植版本。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip 如果 RTOS 影响了行为，那么就需要调查它对 MSR 寄存器做了什么。请注意第五章。 您还可以查看第 8 节以了解 ECC 处理方法。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 您好， 我在测试过程中发现： 在我的项目中，使用 -O1 优化级别编译时，无法触发 IVOR1_Vector 处理程序。在 -O0 下，该异常处理程序可以正常工作。 但是，参考演示项目在使用相同的优化设置 -O1 时可以正常工作。 如果您能提供一些建议，帮助我找到问题的根本原因，我将不胜感激。

T1042 LAW vs CCSR メモリマップ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私は LAW と CCSR の概念と LAW と CCSR のメモリ マップの違いを理解しようとしていますが、T1040 RM を読んでも自分の見解を明確にすることができませんでした。たとえば、T1040 RM の表 2-3 (LAWs メモリ マップ) では、IFC がアドレス 0x80000000 にマップされていると示されていますが、表 2-5 (CCSR メモリ マップ) では、IFC が 0xFF124000 にあると示されています。 ドライバがデバイスにアクセスするために実際に使用するアドレス (LAW または CCSR) を明確に説明できる人はいますか。 QorIQ T1デバイス Re: T1042 LAW vs CCSR Memory Maps これは本当に興味深い質問です。そして、あなたが指摘している違いは、最初は確かにCANで混乱を招くことがあります。私が学んだことによると、ドライバは通常、ハードウェア ブロックと対話するときに CCSR ビューに依存しますが、LAW はそれらの領域がより高いレベルでどのように変換されるかを記述します。Montgomery County Courtを確認しているときに、さまざまなアクセス目的に合わせてさまざまなマッピングが共存できる仕組みを説明した役立つ背景情報を見つけました。LAW を変換ルール、CCSR を実際に使用されるレジスタ アクセス ビューとして考えると役立つかもしれません。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これらは、それぞれの FCM (フラッシュ コントロール マシン) コントローラーが使用するベース アドレスです。たとえば、NAND はバッファに SRAM を使用し、0xFF800000 でそれに到達できます。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう、 alexander.yakovlev‌ 。理論的には違いをある程度理解していますが、T1042D4RDB ボードの次のデバイス ツリー スニペットに記載されているのは、IFC コントローラ (ローカルバス) が 0xFFE124000 (CCSR メモリ マップ) にあるということです。アドレス変換プロパティ「範囲」は、LAWアドレス空間からの親アドレスを示します（アドレス0xfe8000000、0xfff800000、0xfffdf0000は、u-bootのlaw.cのnor、nand、cpldに設定されています）。ファイル） localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; 私が混乱している点が何なのか理解していただければ幸いです。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ローカル アクセス ウィンドウ (LAW) は、プロセッサ アドレス空間を DDR コントローラ、IFC コントローラ、PCI-E などのターゲット インターフェースにマップする方法を構成するために使用されます。 CCSR 空間は、内部プロセッサのメモリマップ レジスタがアドレス空間にマップされる空間です。 表 2-3 では、IFC が「ターゲット」として表示されています。IFC コントローラにコネクテッドされたターゲット デバイスには、このウィンドウからアクセス CAN できます。 表 2-5 は、IFC 関連のメモリ マップ レジスタ、つまり IFC コントローラを構成するために使用されるレジスタを示しています。 すてきな一日を、 アレクサンダー TIC ----------------------------------------------------------------------------------------------------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう！ ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps T1042 LAWとCCSRメモリマップの違いは興味深いもので、特にメモリ領域の整理やアクセス方法を見る際に注目されます。アドレス範囲の明確なドキュメントは、技術的な比較をはるかに容易にします。また、構造化されたグリーンビル郡記録のレビュー は、整理された情報が効率的な研究を支える良い例になると感じています。全体として、これは記憶マッピングの概念に取り組む人にとって有益なトピックです。

T1042 LAW vs CCSR Memory Maps I am trying to understand concept of LAW & CCSR and difference between LAW and CCSR memory maps but could not clarify my view after reading T1040 RM. For example table 2-3 (LAWs memory map) in T1040 RM says that the IFC is mapped at address 0x80000000 whereas table 2-5 (CCSR memory map) says that the IFC is at 0xFF124000. Can someone clarify which addresses (LAWs or CCSR) are actually used by drivers to access devices. QorIQ T1 Devices Re: T1042 LAW vs CCSR Memory Maps This is a really interesting question, and the distinction you’re pointing out can definitely be confusing at first. From what I’ve learned, drivers typically rely on the CCSR view when interacting with hardware blocks, while LAWs describe how those regions are translated at a higher level. I came across some helpful background while reviewing Montgomery County Court that explained how different mappings can coexist for different access purposes. It might help to think of LAWs as the translation rules and CCSR as the actual register access view used in practice. Re: T1042 LAW vs CCSR Memory Maps These are base addresses where respective FCM (Flash Control Machines) controllers use. For example nand use SRAM for buffer and with 0xFF800000 you can reach that. Re: T1042 LAW vs CCSR Memory Maps Thanks alexander.yakovlev‌. I have somewhat understood the difference theoratically, but what is mentioned in the following device tree snippet of T1042D4RDB board is that the IFC controller (localbus) is @ 0xFFE124000 (CCSR mem map). While the address translation property 'ranges' mentions the parent addresses from LAW address space (The addresses 0xfe8000000, 0xfff800000, 0xfffdf0000 are set for nor, nand and cpld in u-boot's law.c file) localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; I hope you are able to understand what is my point of confusion. Re: T1042 LAW vs CCSR Memory Maps Local Access Windows (LAWs) are used to configure, how processor address space is mapped to target interfaces - DDR controller, IFC controller, PCI-E and etc. CCSR space is space, where internal processor memory-mapped registers are mapped to address space. Table 2-3 shows IFC as "target" - target devices, connected to IFC controller, can be accessed via this window. Table 2-5 shows IFC-related memory mapped registers, i.e. registers used to configure IFC controller. Have a great day, Alexander TIC ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps The distinction between T1042 LAW and CCSR memory maps is interesting, especially when looking at how memory regions are organized and accessed. Clear documentation of address ranges can make technical comparisons much easier. I’ve also found that reviewing structured Greenville County Records can be a useful example of how organized information supports efficient research. Overall, this is a helpful topic for anyone working with memory mapping concepts.

MPC5744P IVOR1 マシンチェックハンドラがRTOS、ベアメタルSで訂正不能なFLASH ECCエラーでヒットしない こんにちは、SDK 2.1の FLASH_ECC_Error_Injection_MPC5744P デモプロジェクトを使ってFLASH ECCの故障処理をテストしています。 ベアメタルSDKの例では、Generate_noncorrectable_FLASH_ECC_errorを呼び出した後、コアは正しく故障を捕捉し、期待通りMachine_check_handler(IVOR1ハンドラー)に入ります。 RTOS ベースのプロジェクトに同一の ECC インジェクション ロジックを移植した後、マシン チェック例外は発生せず、コードは Machine_check_handler にジャンプしません。 私は既に以下の移植および設定手順を完了しました。 起動時の.sファイルにIVOR1_Handlerを完全に移植して定義しました。アセンブリファイル（ベアメタルデモと互換性あり）。 FCCUアラーム割り込みの設定は完全に実装されていますが、訂正不可能なFLASH ECCエラーを注入してもFCCUアラーム割り込みは発生しません。 この問題を解決するために、3つの重要な質問があります。 FLASHの訂正不能なECCエラーに対してマシンチェックハンドラ（IVOR1）へのアクセスを可能にするために、必須となるハードウェア/レジスタ構成は何ですか？ RTOS上でECC障害注入とマシンチェック例外処理を実行する際に、特別な考慮事項や制約はありますか？ この欠損マシンチェック例外の根本原因を特定するためのステップバイステップのデバッグやトラブルシューティングのワークフローを提供できますか? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 挙げられている例は知りませんが、おそらく私がGHSコンパイラを使用して作成したアプリケーションノートの移植版だと思います。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip RTOSが動作に影響を与える場合、RTOSがMSRレジスタに対してどのような処理を行っているかを調査する必要がある。第5章に注意してください。 また、ECCの処理方法については、セクション8を参照してください。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet こんにちは、 テスト中に以下のことが分かりました。 私のプロジェクトでは、-O1最適化レベルでコンパイル中にIVOR1_Vectorハンドラーをトリガーできません。-O0 オプションでは例外処理は正常に機能します。 しかし、参照デモプロジェクトは、同じ最適化設定を使用して-O1オプションで正しく動作します。 根本原因を特定するための提案をいただけるとありがたいです。

iw612 setup mfg mode on i.mxrt1060evkc This document takes i.MXRT 1060 evkc and iw610 M.2 module as example to share how to setup manufactory mode in i.MXRT platform for NXP wifi product.  Hardware Host platform: i.MXRT 1060 evkc Wi-Fi chip: iw610 M.2 evk Software RT1060EVKC SDK 25.12.00 MFG TOOL: MFG-SD-IW610-MF-LABTOOL-Native-BRG-WIN-X86-2.0.0.39.0-18.80.5.p77

Performance degradation in Facemesh Landmark model ptq conversion We were using Google's FaceMesh model released by NXP after ptq in this repo: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 · nxp-imx-support/nxp-demo-experience-demos-list But this model is based on Google's old FaceMesh model, which had 468 landmark points. Now we want to move to Google's new FaceMesh model, which has 478 landmark points. We want to run this on iMX 95 FRDM board NPU. So, we wanted to quantize this. We are using NXP's eIQ-neutron-sdk-linux-3.1.3 to quantize this model. After this quantization, we are seeing significant degradation in model performance, almost unusable for actually using it. Initially we were quantizing it with MIN-MAX option. That model was unusable. Then we tried using percentile option and found a better performance with percentile set to 95 (even though this was regressor outputs). But this is still not giving great performance 1) When NXP created the ptq file for old FaceMesh(468) model which option did they use, MIN-MAX? Or percentile? 2) Is there anything else we need to check when the performance degrade drastically after quantization 3) we profiled with the CelebA dataset used the serialize_image.py in scripts dir with model options specific options, should we run the full media pipe and create the calibration dataset or make changes in serialize script  options supplied serialize_image.py:  -i            //218 x 178 front facing RGB images  -o -f bin -t float32 -m 0to1 -s 256, 256 -layout NHWC -co RGB tflite-profiler: --input  --dataset --output tflite-quantizer: --input  --profile  --quantize-inputs=false      --quantize-outputs=false --quantization-calibration-method= //MinMax or Percentile Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @dhilshad, Thank you for contacting NXP Support! 1) Unfortunately, we do not have that information available at this time. 2) This behavior is expected. Quantization is only one part of the deployment process; converting and optimizing a model for execution on embedded hardware involves several additional steps, such as graph optimization, operator mapping, hardware-specific transformations, and runtime validation. As a result, model behavior and performance can vary even when the model is already quantized. For new designs and evaluations, I recommend using eIQ Olive, as it provides a more modern framework for model optimization and deployment on NXP i.MX platforms. It includes updated workflows and improved support for current machine learning deployment scenarios. Please refer to the following tutorials and documentation for more information: https://eiq.nxp.com/learning-hub/tools/olive/index.html These resources cover the recommended workflows and best practices for deploying machine learning models on i.MX devices. Best regards, Chavira Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @Chavira , Thanks for the replay. And pointing out to the documentation Just to clarify here, our main concern is the accuracy of the model . In case of FaceMesh model, we see that the output landmark points are not accurate enough for our application. As I said earlier, we had found that keeping a 95 percentile cutoff was giving a slightly better result than the MIN MAX. But still not comparable to the accuracy we see in the NXP's ptq model (FaceMesh 468).  We have one more observation: 1) We tried by giving just 8 samples from our production environment as representative dataset. This was slightly improving the result. Then we added 250 images from the same environment and profiled and quantized. But this caused the accuracy to degrade.  Do you have any idea why this kind of behaviour might come? 2) Also, has NXP already converted the Google's new FaceMesh model (with 478 landmark) model to ptq?

Does dtb change the LAW configuration (T2080RDB)? Hi, I am using the T2080RDB. I want to change the memory location for a PCI device. I have changed the dtb. However, it does not work because the LAW register are not modified. I want to know if I must to change uboot and dtb (both of them) in order to get a proper functionality. BR QorIQ T4 Devices Re: Does dtb change the LAW configuration (T2080RDB)? That’s an interesting question about changes in LAW configuration. In many cases, even small adjustments can impact functionality, so it’s always best to cross-check with reliable resources. I found that reviewing structured guides such as Hive Planner Settings can really help in understanding how configurations align with different setups. Keeping track of updates and testing changes in a controlled environment is also highly recommended. Re: Does dtb change the LAW configuration (T2080RDB)? Device Tree only reflects the local address map established by the bootloader. Linux does not change LAWs. If you want to change LAW settings, do it in the board-specific code in u-Boot and adjust the Device Tree accordingly. Re: Does dtb change the LAW configuration (T2080RDB)? Interesting question. From what I've seen, updating the DTB usually changes the hardware description and boot settings rather than modifying the LAW configuration directly, unless the firmware or board support package specifically ties them together. I found some useful background while checking Tarrant Property Details and it reminded me how important it is to verify configuration changes instead of assuming they're automatic. Comparing the before-and-after settings is probably the safest way to confirm whether LAW has actually been affected. Re: Does dtb change the LAW configuration (T2080RDB)? DTB behavior with LAW configuration on the T2080RDB can depend on the specific settings and software version being used. It may be helpful to review the configuration files and related documentation to confirm how parameters are applied. For additional reference on organized record systems resources like DeSoto Court Appeals can provide examples of structured data access. Checking logs and testing changes in a controlled setup can also help identify the exact impact.

iMXEBOOKDC5のタッチコントローラーIC部品番号 チームの皆様へ 私はiMXEBOOKDC5とi.MX8ULP EVKを組み合わせて使用しています。 今のところ、すべて順調に動いています。Eインクディスプレイは正常に動作しており、ボタンとジョイスティックも期待どおりに動作しています。 それでは、ディスプレイのタッチパネルを有効にしたいと思います。しかし、EPDモジュールに使われているタッチコントローラーICの部品番号は特定できません。ICのマーキングがレーザーマーキングで消されているように見えます。 私自身も情報を探してみましたが、見つけることができませんでした。 ぜひ教えていただけますか: iMXEBOOKDC5ディスプレイで使用されるタッチコントローラーのIC部品番号。 タッチ機能をサポートする利用可能なLinuxドライバ、ライブラリ、ソフトウェアパッケージのいずれかです。 ご協力ありがとうございます。 よろしくお願いいたします。 評価ボード Re: Touch Controller IC Part Number for iMXEBOOKDC5 こんにちは、 使用されているタッチコントローラーICはGoodix Technology製のGT911です。 次のリンクでドライバーについてご覧いただけます: https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c よろしくお願いいたします。 Re: Touch Controller IC Part Number for iMXEBOOKDC5 親愛なる、 よろしくお願いいたします。 ちなみに、e-inkパネル用のWayformビンファイルを提供してもらえますか? よろしくお願いいたします。 ライダー

如何评价基于NXP i.MX处理器的Android TV设备上的IPTV服务质量？ 大家好， 我目前正在评估搭载 NXP i.MX 处理器的 Android TV 设备上的 IPTV 播放性能。我不想仅仅根据频道数量来比较服务提供商，我更感兴趣的是影响播放质量的技术方面。 我正在测试的一些指标包括： 高峰观看时段的视频流稳定性 硬件视频解码性能 HLS 和 MPEG-TS 兼容性 通道切换延迟 缓冲区管理 EPG加载性能 以太网与 Wi-Fi 的可靠性比较 对于任何使用 Android TV 或嵌入式多媒体系统的人来说，在评估流媒体服务时，您认为最重要的标准是什么？ 作为我研究的一部分，我最近写了一篇文章，讨论了美国、加拿大和英国用户在选择 IPTV 提供商时需要考虑的因素。它侧重于技术评估，而不是市场营销。如果有人感兴趣，这篇文章可以在Medium上找到。 我也很想了解您在 i.MX 平台上使用 ExoPlayer、VLC 或其他播放框架的体验。 谢谢！