Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
DES-N1842 - QorIQプロセッサおよびQorIQ LSシリーズ上のONLおよびONIE <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ホワイトボックススイッチは、その上で実行されるソフトウェアとは無関係に販売されるネットワークスイッチです。Open Network Linux(ONL)は、スイッチ上で動作する「ネットワークオペレーティングシステム」の基盤として使用されます。Open Network Install Environment(ONIE)は、ネットワーキング オペレーティング システムをスイッチにインストールするために使用されるソフトウェアを作成するために使用されます。このプレゼンテーションでは、NXPのQorIQ P2041およびQorIQ T2080プラットフォーム上のONL/ONIEへの関与と、LS2085のロードマップに焦点を当てています。このセッションでは、NXPのONL/ONIEおよびホワイトボックス市場へのアプローチについて詳しく説明します。 ビデオプレゼンテーションを見る <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ホワイトボックススイッチは、その上で実行されるソフトウェアとは無関係に販売されるネットワークスイッチです。Open Network Linux(ONL)は、スイッチ上で動作する「ネットワークオペレーティングシステム」の基盤として使用されます。Open Network Install Environment(ONIE)は、ネットワーキング オペレーティング システムをスイッチにインストールするために使用されるソフトウェアを作成するために使用されます。このプレゼンテーションでは、NXPのQorIQ P2041およびQorIQ T2080プラットフォーム上のONL/ONIEへの関与と、LS2085のロードマップに焦点を当てています。このセッションでは、NXPのONL/ONIEおよびホワイトボックス市場へのアプローチについて詳しく説明します。 ビデオプレゼンテーションを見る デザイン |ソフトウェア&サービス
記事全体を表示
SMI-N1805 NXP 功能安全产品组合 - 简介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 设计师有一个借助恩智浦功能安全微控制器产品组合,实现功能安全标准的简单方法。 在本次会议中,我们将介绍如何将安全功能应用到汽车和工业市场以及恩智浦为每一步提供的产品支持。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 设计师有一个借助恩智浦功能安全微控制器产品组合,实现功能安全标准的简单方法。 在本次会议中,我们将介绍如何将安全功能应用到汽车和工业市场以及恩智浦为每一步提供的产品支持。 观看视频演示 智能机械和工业自动化
記事全体を表示
Kinetis Bootloader 总结 Bootloader是一种面向用户应用程序的引导代码,可以在没有烧写器的情况下烧录用户程序,也可以用于在线更新程序。飞思卡尔提供了三种实现bootloader的方式,分别为: 1.预烧写在ROM中的bootloader     这种方式是MCU中内置了专用的ROM来存放bootloader,目前支持ROM型bootloader的Kinetis系列MCU包括KL03,KL17,KL27和KL43等。其中KL03和KL17的ROM bootloader包含SPI/UART/IIC三种接收方式,KL27和KL43还增加了USB的方式。 2.预烧写在FLASH中一次性bootloader     这种类型的bootloader在芯片出厂前预写在FLASH中,因此可以像ROM型bootloader一样直接使用。但与ROM型不同的是,上电后bootloader会从FLASH搬移到RAM 中运行,再将FLASH整片擦除并烧写用户程序,因此这种bootloader是一次性的。其优点是不需要片内ROM且方便量产烧写,缺点是无法支持以后的程序更新。目前支持预烧写在FLASH中一次性bootloader的Kinetis系列MCU包括K22、K24和KV3x等。 3.开放源码的bootloader     这种方式将FLASH空间分为两个部分,一部分用于存储bootloader代码;另一部分用于存储用户应用程序代码。这种方式的bootloader方便客户定制自己的代码。     目前飞思卡尔提供开放源代码的Kboot,支持UART/SPI/IIC/USB HID 几种接口方式,其网址链接为:     www.freescale.com/kboot     除了Kboot,还有以下独立版本的bootloader,包括:     1)AN2295(开发人员的串行引导加载程序)         文档下载地址为:http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN2295.pdf         代码下载地址为:http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2295SW.zip        另外FAE Yang Liang 对其进行了移植,目前已经支持FRDM-KE02,KE06,KL25,KL26,KL43,KL46, TWR-K60, KV4x, KV10.下载地址为:Kinetis/AN2295_Bootloader · GitHub     2)AN4767 (Kinetis E 系列上的UART Boot Loader 设计)         文档下载地址为:http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4767.pdf         基于AN2295,没有提供代码。     3)AN4775 (Kinetis E 系列上的IIC Boot Loader设计)         文档下载地址为:http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4775.pdf         代码下载地址为:http://cache.freescale.com/files/32bit/doc/app_note/AN4775SW.zip     4)AN4368 (USB 大容量存储设备主机引导加载程序)          文档下载地址为:http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4368.pdf          代码下载地址为:GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K60: This is usb msd Bootloader for K60 (For K60)                                        GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K64: This USB MSD bootloader for K64 (For K64)     5)AN4379  (Freescale USB大容量存储设备引导加载程序)          文档下载地址为:http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4379.pdf          代码下载地址为:http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4379SW.zip     6)AN4764   (USB Human Interface Device Boot Loader for ColdFire Plus, Kinetis K, and Kinetis L MCUs)          文档下载地址为:http://cache.freescale.com/files/32bit/doc/app_note/AN4764.pdf          代码下载见附件     7)AN4370   (用于 MCU 的 USB DFU 引导加载程序)         文档下载地址为:http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4370.pdf         代码下载地址为:http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4370SW.zip       8)AN4367   (用于 MCU 的 以太网引导加载程序)         文档下载地址为:http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4367.pdf?fromsite=zh-Hans         代码下载地址为:http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4367SW.zip         最新的代码请到FNET官网下载:http://fnet.sourceforge.net/    9)Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+         代码及文档下载地址为:https://community.freescale.com/docs/DOC-328168             回复:Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨文学 对 Kinetics 系列引导加载程序的总结做得很好。 我正在研究基于 K20d72m 的定制板,寻找从 PC 接收命令来校准板上的蓝牙芯片的解决方案。 您是否知道是否有一个演示引导加载程序同时支持 USB(虚拟 COM 连接到 PC)和 SPI 端口到外围芯片?我需要这样的裸机应用程序来进行电路板校准。 谢谢! 回族 Re: Kinetis Bootloader 总结 谢谢,我一直在更新AN2295,目前支持FRDM-KE02,KE06,KL25,KL26,KL43,KL46. TWR-K60, KV4x, KV10,可以从下面这个地址获取: Kinetis/AN2295_Bootloader · GitHub Re: Kinetis Bootloader 总结 点赞,总结的非常好! Re: Kinetis Bootloader 总结 谢谢分享,非常感谢! 希望能将KBoot如何通过命令行更新介绍的更详细些。 回复:Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI,Liang Yang, 如何将 KE02/KE06 uart 引导加载程序移植到 FRDM-KE04Z 演示板? 谢谢你? 回复:Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi hui, 我们没有可以满足您的要求的引导加载程序。您需要自己动手。 顺祝商祺! Wenxue 发自我的 iPhone 在 2015年4月11日,0:20,"Hui Shao" > 写道: <> <> Kinetis 引导加载程序总结 Hui Shao 的新评论<>查看本文档的所有评论<>
記事全体を表示
S32G_LLCE_to_PFE_Demo Building(Chinese Version) 本文说明在S32G2 RDB2板上实现LLCE to PFE Demo的搭建过程。本Demo目前包括:  CANtoEth:CAN0发送,用硬件回环到 CAN1接收,然后通过PFE_EMAC1, 再通过RGMII接口发出。  CANtoEth:CAN0发送,用硬件回环到 CAN1接收,然后通过PFE_EMAC1, 再通过SGMII接口发出。  EthtoCAN:PC通过PFE_EMAC1的 RGMII发出,接收到CAN1,再硬件 回环到CAN0  CANtoCAN Logging to Eth: CAN0发 送,用硬件回环到CAN1接收,然后 通过PFE_EMAC1,再通过SGMII接 口发出,同时LLCE内部硬件把CAN1 再发送到CAN15_TX,再用硬件回环 到CAN14_RX 软件版本为 RTD3.0.0+LLCE1.0.3+PFE0.9.6/0.9.5。 Automotive
記事全体を表示
MPC5746Cは周囲温度115℃でハングアップする(起動せず、UARTも動作しない)。 パート: MPC5746C(Power Architecture Z4、SDK:NXP MPC57xxプラットフォームSDK) 周囲温度115℃での恒温槽試験中、当社のMPC5746Cベースのボードは起動時に完全に反応しなくなり、UARTコンソール出力が全くなくなります。この現象は、その温度での起動試行のたびに発生します。冷却後、部品は完全に回復するようです。室温で再フラッシュ/再起動すると、永続的な損傷なく正常な動作に戻ります。 興味深いことに、基板が115°Cの状態でもPEMicro JTAGデバッグプローブを使ってフラッシュを再プログラム することは可能です 。これは、温度でバージョンストリングをフラッシングし、冷却後に新しいバージョンを読み返すことで確認済みです。したがって、デバッグプローブのフラッシュ経路は115°Cで動作します。アプリケーションのブートパスだけがハング/悪い状態になります。 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 問題の根本原因と解決方法を教えていただけませんか。 Re: MPC5746C hangs (no boot, no UART) at 115°C ambient こんにちは、 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 はい、それは問題ありません。 問題の根本原因と解決方法を教えていただけませんか。 これはカスタムボードであり、冷却後に問題が解消されることから、私は次のことを疑っています。 1. 時計の起動に関する問題(最も可能性が高い) 115℃の場合: 外部水晶発振器(FXOSC)の起動時間が長くなります。 発振器のゲインマージンが減少する。 負荷コンデンサの値は温度によって変化する。 プリント基板からの漏洩電流が増加します。 デバッグロジックは独自のインフラストラクチャを利用し、アプリケーションがmain(に到達する)に依存しないため、デバッガーは部品にアクセスできます。 FXOSCステータスビット CMUクロックモニタの障害 FIRCのみのブート実験 FIRCから完全に実行し、外部水晶発振器を一時的に無効にする JTAGのプログラミングが115°Cで動作し続けていることは、コアインフラストラクチャがまだ生きており、故障がフラッシュアレイ自体ではなくアプリケーションのブートパスの非常に早い段階で起きていることを示す最も強い手がかりです よろしくお願いいたします。 ピーター Re: MPC5746C hangs (no boot, no UART) at 115°C ambient @petervlna さん、貴重なご意見ありがとうございます。 これを受けて、同僚の@mnargundと私はさらに調査を進め、MPC5746Cを115℃で正常に起動させることに成功しました。以下に、調査結果の概要を示します。 根本原因: 事前初期化時にシステムをFIRC、FXOSC、PLLを起動するように設定し、その後システムクロックをFIRCからPLLに切り替えました。続いて、DRUN モードへのモード遷移をトリガーしました(システムはデフォルトで既に DRUN モードでしたが、マニュアルに記載されているように、新しい設定を有効にするには同じモードへの遷移が必要です)。そして、MC_ME_GS.MTRANS をポーリングして遷移が完了するのを待ちました。 しかし、MC_ME_GS.MTRANSがクリアされた後でも、コードはIVOR1例外でエラーを起こしました。これは、実行が続行された時点で遷移が完全に安定していなかったことを示している可能性があります。高温(115℃)では、室温よりも遷移に時間がかかるようで、次の命令が実行されたときにシステムが不安定な状態になる。 回避策の適用例: MC_ME_GSの後に明示的なソフトウェア遅延を挿入しました。MTRANSのポーリングを行い、その後の初期化を進めます。500ミリ秒の遅延を設けると、115℃の環境下でも起動は安定して成功する。100ミリ秒の遅延もテストしましたが、私たちの環境では問題なく動作しました。 初期化のこの段階で安全に挿入できる最大推奨ソフトウェア遅延はありますか? 125℃までの全動作温度範囲において、動作前にクロックの安定性を確実に確保するための推奨手順はありますか?
記事全体を表示
交换请求:通过 Hse_Ip_ServiceRequest 发送的 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK 返回 0xAA55A11E 您好,目前我正在尝试对 S32K314HMS 微控制器进行 A/B 交换。交换请求通过以下方式提出:   /* 重置作业状态变量 */       交换作业状态=交换作业待处理; /* 设置 HSE 请求的服务描述符 */ swapHseSrvDescriptor.srvId = HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK; /* 设置要发送到 HSE IP 层的请求参数 */       swapHseIpRequest.eReqType = HSE_IP_REQTYPE_ASYNC_POLL ;​​       swapHseIpRequest.u32Timeout = SWAP_TIMEOUT ;​​ swapHseIpRequest.pfCallback = SwapProcessMuChannelResponse; /* 向 HSE IP 层发送服务请求 */ 如果 (HSE_SRV_RSP_OK != Hse_Ip_ServiceRequest(SWAP_MU_INSTANCE, SWAP_MU_ADMIN_CHANNEL, &swapHseIpRequest, &swapHseSrvDescriptor))     {          结果= E_NOT_OK ;      } 然后会执行 swapHseIpRequest.pfCallback ( SwapProcessMuChannelResponse ) ,返回的 HseResponse 将是: static void SwapProcessMuChannelResponse ( uint8 u8MuInstance , uint8 u8MuChannel ,                                              hseSrvResponse_t HseResponse , void * pCallbackParam ) {    如果( HseResponse == HSE_SRV_RSP_OK )     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK ;    }    别的     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED ;       VStdLib_ConvertUint32ToUint8ArrayBigEndian (( uint32 ) HseResponse ,调试数据);    } } #define HSE_SRV_RSP_NOT_SUPPORTED (( hseSrvResponse_t ) 0xAA55A11EUL ) /**< @brief 不支持此操作或功能。 */ 这种情况偶尔会发生,有时交换会按预期进行。原因可能是什么?我可以在哪里找到 HSE 返回此返回代码的原因/情况? 此交换是在更新序列结束时触发的,在RESET/上电几分钟后(因此 HSE 已 100% 初始化)。 Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E 嗨@AlexI 这是一个非常简单的服务,没有任何参数。我唯一的解释就是这是数据缓存内存造成的。请确保将描述符放置在不可缓存的内存中。 通常情况下,所有用于与 HSE 通信的数据对象都必须强制存储在不可缓存的内存中,因为 HSE 无法访问缓存。 虽然这可能不是本案的原因,但是:如果使用 DTCM 内存,则必须使用后门地址。普通地址仅对拥有该内存的核心可见。其他总线主控器(其他核心、DMA、HSE 等)只能通过后门地址看到此内存。 lukaszadrapa_0-1783694396770.png 此致, Lukas Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E 感谢@lukaszadrapa 的回复。 我修改了实现方式,使swapHseSrvDescriptor 和swapHseIpRequest具有初始值,并在启动时由链接器初始化而不是在运行时初始化,现在可以正常工作了。
記事全体を表示
关于 S32K312 上 FlexCAN 增强型 RX FIFO + DMA 操作的说明需要澄清 你好 , 我们目前正在研究基于 S32K312 的 FlexCAN 增强型 RX FIFO 和 DMA, enhanced FIFOenhanced FIFO增强型先进先出   我们正在使用 rtd v 7.0.1,希望就我们遇到的几个问题和观察结果进行澄清。 1. MEX 配置验证 请您确认启用 DMA 的 FlexCAN 增强型 RX FIFO 的推荐 MEX 配置是什么?我们希望确保我们的配置符合预期的RTD使用模型。 2. 增强型接收 FIFO + DMA 数据丢失观察 根据 FlexCAN 勘误表中的建议,启用增强型 RX FIFO 时,以下消息缓冲区将不使用: MB0–MB7、MB10、MB12、MB20、MB22、MB30、MB32、MB40、MB50 和 MB60。 我们的配置如下: 增强型接收 FIFO 已启用 DMA已使能 水印配置为 10 个条目 DMA 将 FIFO 数据传输到软件缓冲区。 观察到的行为: CAN 消息已正确接收到增强型 RX FIFO 中。 DMA 可以成功传输数据,直到达到水印级别。 DMA完成中断被触发。 此后,在预期的下一个 FIFO 位置(从第 11 个 FIFO 条目开始)中未观察到传入的 CAN 消息。 观察到数据丢失和异常的先进先出(FIFO)行为。 请解释一下这种情况下的预期行为以及出现消息丢失的可能原因? 3. FlexCAN_Ip_RxFifo DMA 重配置 在调试 RTD 驱动程序时,我们观察到 FlexCAN_Ip_RxFifo API 似乎会重新配置 DMA 参数。 具体来说: 次要循环计数似乎已配置为 16 传输大小似乎为 4 字节 这导致总传输大小为 64 字节(或根据解释约为 68 字节),这似乎与参考手册中描述的增强型 RX FIFO 条目大小不符。 能否解释一下这个 API 的预期功能以及这些 DMA 设置背后的原理? 4. 增强型接收 FIFO 存储器观察 调试过程中还观察到,尽管 DMA 似乎将数据从 FIFO 传输到软件缓冲区: FIFO 内存区域仍然包含较旧的消息 ID。 内存浏览器似乎只显示第一个增强型 RX FIFO 元素。 先进先出位置似乎没有按预期更新。 附上屏幕截图供参考。 能否解释一下这是否是预期行为,以及在运行时调试期间应该如何解释增强型 RX FIFO 内存? 5. 结构尺寸不匹配 我们还观察到 RTD 结构与参考手册之间存在差异。 FlexCAN_Ip_MsgBuffType 在 RTD 中的大小:78 字节 根据参考手册,增强型 RX FIFO 元素大小为:80 字节 请问您能否解释一下: 为什么会出现这种尺寸差异? 是否需要考虑包装/对齐方面的问题? DMA 传输应该配置为 78 字节还是 80 字节? 预期用途案例 我们的要求是使用: 增强型接收 FIFO 基于DMA的接收 消息接收过程中不会出现 CPU 中断。 预期行为是: CAN 消息到达增强型 RX FIFO。 DMA 会自动将 FIFO 条目传输到软件缓冲区。 正常运行不需要软件轮询或接收中断处理。 有意避开增强型 RX FIFO 保留的消息缓冲区(MB0–MB7、MB10、MB12、MB20、MB22、MB30、MB32、MB40、MB50 和 MB60),而其余的消息缓冲区则用于传输。 申请它 请问您能否提供以下信息: 任何能够演示增强型 RX FIFO 与 DMA 操作的示例项目。 针对此用例推荐的RTD配置。 澄清 RTD 目前是否支持使用 DMA 进行连续增强型 RX FIFO 接收而无需软件重新激活。 任何实现增强型 RX FIFO + DMA 接收的裸机驱动程序示例。 感谢您的支持。 Re: Clarification Required on FlexCAN Enhanced RX FIFO + DMA Operation on S32K312 您好, 1. MEX 配置验证 A:看来您的 MEX 与您描述的设置不符。 - 水印设置为 1 - DMA传输配置并非必需,驱动程序会自动配置DMA,除非您想要自行设置DMA参数和传输方式。 2. 增强型接收 FIFO + DMA 数据丢失观察 A:DMA 完成中断后,所有接收到的消息都会被读取,并且分配的 DMA 通道将被禁用。 因此,如果不再调用 FlexCAN_Ip_RxFifo,RXFIFO 仍然会从条目 0 开始接收消息,但由于 DMA 没有再次启动,因此不会读取 RXFIFO。 3. FlexCAN_Ip_RxFifo DMA 重配置 A:什么是次要循环计数?驱动程序本身将次要循环大小(字节)设置为 80,以便从 RXFIFO 读取最多 64 字节的有效负载消息以及 IDHIT 和时间戳信息。 所以,我其实不太明白你的计算方法。或许可以分享一下你的代码 4. 增强型接收 FIFO 存储器观察 A:仅第一个增强型 RX FIFO 元素区域可见,表示增强型 FIFO 输出端口地址范围。调试期间不建议显示 RXFIFO 内存。为了使 FIFO 引擎正常运行,CPU 在 DMA 操作期间不应访问增强型 FIFO 输出端口地址范围,实际上显示此内存空间会导致对其进行读取。 5. 结构尺寸不匹配 A:FlexCAN_Ip_MsgBuffType 不能完全反映 RXFIFO 结构。传输结束时,驱动程序读取内部缓冲,并将相应的数据填充到用户缓冲区的相应字段中。 如上所述,DMA 应设置为每次 DMA 请求读取 80 字节。 驱动程序的编写方式是,在 DMA 完成并调用 FLEXCAN_EVENT_DMA_COMPLETE 事件后,需要重新激活 DMA(调用 FlexCAN_Ip_RxFifo)。 您可以参考下面的演示来增强 RXFIFO 和 DMA 的使用,但这是在 RTD400 中实现的。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-FlexCAN-Ip-TX-RX-EnhanceRXFIFO-DMA-test-S32DS3-5/ta-p/2015832 BR,彼得
記事全体を表示
The S32K144 chip has a clock configuration issue; the timing period changes after the clock is modified. I encountered the following problem during the development of S32K144: Ni__0-1782181934609.png The initialization timer's interrupt overflow period should be 1 second. The premise is that my clock configuration is 8MHz. Ni__1-1782182016343.png Ni__2-1782182026827.png However, after I changed the clock to a 20M clock... Ni__3-1782182078529.png Ni__4-1782182086180.png I discovered that my timer overflow period is no longer 1 second, but has become 400 milliseconds. However, my timer clock selection is still set to the 8MHz internal clock. PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* Clock src=1, 8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* Enable clock for FTM regs */ I'm not sure what configuration issue is causing this problem. Re: S32K144芯片的时钟配置问题,更改时钟后定时周期出现变化 Hi 建议看一下S32K1 RM的Table 27-9. Peripheral module clocking (continued),FTM具体选择哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1 Register (PCC_FTM1)的PCS位。 Table 27-9. Peripheral module clocking FTM.png 你用Processor Expert生成配置,又用baremetal方式直接操作寄存器。我不确定是否是因为调用了SDK里的API导致和你的baremetal程序冲突了。 建议debug情况下直接检查上述两个寄存器。 顺便提一句,baremetal直接操作寄存器的话建议参考S32K144_Project_FTM例程,如果想用ProcessorExpert 搭配SDK的API则建议参考ftm_periodic_interrupt_s32k144例程。 Best Regards, Robin
記事全体を表示
Brake Control Monitoring Course Using NXP FRDM-A-S32K3 Automotive Platforms Introduction Braking systems are among the most important safety-related functions in modern vehicles. Modern automotive electronic systems continuously monitor brake inputs and react in real time to ensure driver awareness and vehicle safety. This course introduces brake control and brake status monitoring concepts using NXP S32K3 automotive microcontrollers and Application Code Hub examples. Through practical demonstrations, participants will learn how embedded software acquires, processes, and reacts to brake-related signals using automotive-grade development platforms. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. The course is based on the following Application Code Hub demonstrations: Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 Both examples implement the same brake monitoring concept and can be executed on either FRDM-A-S32K312 or FRDM-A-S32K344, allowing teachers, students, and developers to choose the platform that best fits their hardware availability and learning objectives. The demonstrations simulate a braking event using a Force Click board connected through the FRDM K64 Click Shield. The Force Click acts as a brake pedal sensor and generates an analog signal proportional to the applied pressure. This signal is acquired through the MCU ADC peripheral, processed by the application, and used to drive a 4x4 RGB Click board that provides visual indication of the current braking condition. The examples illustrate how automotive brake monitoring systems can detect braking events and react in real time using embedded software running on the S32K3 platform. FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 Course Objectives After completing this course, participants will be able to: Understand the fundamentals of automotive brake monitoring systems Acquire analog signals using ADC peripherals Process brake-related inputs in real time Control visual indicators based on system status Understand ADC and FlexIO peripheral integration Develop applications using S32 Design Studio and RTD drivers Prototype automotive applications on FRDM-A-S32K312 and FRDM-A-S32K344 boards Hardware Platforms and Components Platform Selection One of the advantages of this course is the flexibility to use either the FRDM-A-S32K312 or the FRDM-A-S32K344 platform. Both examples demonstrate the same automotive brake monitoring functionality and learning concepts, enabling users to select the board available in their laboratory environment while following the same workflow and development methodology. FRDM K64 Click Shield Provides mikroBUS™ connectivity for Click boards and simplifies hardware expansion. Force Click Simulates the brake pedal input by generating an analog signal proportional to the applied pressure. The ADC peripheral continuously reads this signal to determine the brake status. 4x4 RGB Click Acts as the brake status indicator. Different LED patterns can be used to represent braking conditions and emergency braking events. The LEDs are controlled through the FlexIO peripheral. Brake Control Monitoring on FRDM-A-S32K312Brake Control Monitoring on FRDM-A-S32K312 Brake Control Monitoring on FRDM-A-S32K344Brake Control Monitoring on FRDM-A-S32K344 System Architecture The application follows a simple automotive workflow: The user applies pressure to the Force Click sensor. The ADC peripheral acquires the analog value. The application processes the braking signal. Brake status is evaluated against predefined thresholds. The 4x4 RGB Click LEDs are updated to indicate the current braking condition. This workflow illustrates how sensors, software processing, and output indicators interact in a real-time automotive embedded system. ramonadragulin_5-1782210701819.png Educational Value This course can be used as: Eat-Sleep-Code-Repeat University laboratory material Automotive embedded systems training S32K3 hands-on workshop content Introduction to automotive safety-related software Application Code Hub learning path Students gain practical experience with ADC acquisition, signal processing, real-time decision making, and peripheral control using real automotive hardware. Getting Started Open S32 Design Studio. Select Import Project from Application Code Hub. Search for the desired brake demo. Import the project. Build and flash the application. Assemble the hardware. Apply pressure on the Force Click sensor. Observe the brake status indication on the 4x4 RGB Click LEDs. Conclusion This course demonstrates how brake control and brake status monitoring systems can be prototyped on NXP S32K3 automotive platforms. By combining analog signal acquisition, real-time processing, and LED-based indication, the examples provide a practical introduction to automotive embedded software development and safety-oriented system design. Participants can choose either the FRDM-A-S32K312 or FRDM-A-S32K344 platform and follow the same learning path to understand the implementation of brake monitoring functionality on modern automotive microcontrollers. Result on FRDM-A-S32k312Result on FRDM-A-S32k312 Result on FRDM-A-S32K344Result on FRDM-A-S32K344 References https://mcuxpresso.nxp.com/appcodehub?search=dm-brake-control-s32k312 https://mcuxpresso.nxp.com/appcodehub?search=dm-brake-status-monitoring-frdm-a-s32k344
記事全体を表示
imx93 lpddr4x の JSL4BAG16 設定が不安定です こんにちは、専門家の皆様: JSL4BAG16 の lpddr4x 設定に関して問題があります。設定後、「機能」テストはパスしますが、「最適化->CA 最適化の Vref」で失敗することがあります。常に失敗するわけではなく、時々失敗します。 「vTSA -> CA eye」のテストを実行すると、合格と表示されますが、同時に「エラーログ」も表示されます。 「Vref DQ config」と「Vref CA config」の調整方法について質問があります。JSL4BAG16のVref値は「EVKで使用されているミクロン値」と異なりますが、範囲0または範囲1を設定する必要がありますか? 私の知る限り、Vref DQは「アイダイアグラム」テストの結果に基づいて設定されますが、「読み取りダイアグラム」と「書き込みダイアグラム」のどちらを使用すればよいのでしょうか? JSL4BAGのデータシートと、「CA eye」テストログおよびmexファイルを添付しました。     よろしくお願いします。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは、 LPDDR4Xは、 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-93-Memory-Compatibility-Guide/ta-p/1725656の一部です。 Vref DQ チューニングには、JSL4BAG16 のレンジ 1 (デフォルト) を使用し、読み取りではなく書き込みアイ ダイアグラムを使用してください。   Micron/EVKの設定を再利用しないでください。必ずJSL4BAG16に合わせてVrefを再調整してください。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは、オズワラグさん。 ご返信ありがとうございます。私は「i.MX config tool」でテストに合格し、「最適化」テスト結果でDQとCAの「Vref」を使用しました。 しかし、まだ2つの問題があります。 1.あるボードでは「CA Charts」が表示されず、「CA Eye」テストには誤差がありますが、合格と表示されます 2.lpddr4x_timing.cを更新した後すべての合格ボードで「i.MX config tool」によって生成されたものをシステムで「memtest」を実行すると、「Stuck Address」で失敗します。常にではありませんが、時々発生します。 よろしくお願いします。 Re: imx93 lpddr4x config for JSL4BAG16 unstable 私のFRDM-IMX93ボードにも同じチップが搭載されていますが、市販のイメージファイルでは正常に起動しません。どうすれば解決できますか? Re: imx93 lpddr4x config for JSL4BAG16 unstable いいえ、していません。弊社では、flex-installerが提供する市販のイメージファイルを使用して、市販のfrdm-imx93ボードを使用しています。 入門マニュアルには「i.Mx設定ツール」についての記載はありません。 手順はどうなりますか?マニュアルはありますか?また、使い始めるにあたって、どのような手順で部品を交換する必要がありますか? これはまた、すべてのFRDM-IMX93ボードに対して1つの標準イメージを使うことはできず、各ボードを確認するか、搭載DDRによって2〜3つのイメージバージョンを持つ必要があるということですか? ご注意ください。私たちは(共有の)お客様に対して既製の動作を期待しています。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは、SynchronicITさん。 「i.MX config tool」を使用してDDRテストに合格しましたか?まずそれを通過させてから、lpddr4x_timging.c を使用する必要があります。「i.MX設定ツール」によって生成されました。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは: NXP公式の「FRDM i.MX 93開発ボード」と公式リリースを使っているようですね。大丈夫でしょう。「DDRテスト」を行う必要はありません。私は「FRDMボード」を持っていません。NXPのボードの使い方に関するドキュメントを参照できるかもしれません。
記事全体を表示
i.MX8QM-MEK 上的 AAOS 15 中 CAN 接口的可用性和集成 您好,NXP支持团队, 我们目前正在评估 i.MX8QM-MEK 平台,用于构建汽车安卓系统 (AAOS) 概念验证,其中包括: 双触控显示屏 CAN通信接口 通过AAOS框架实现车辆信号可视化 我们已成功版本并刷写了 AAOS 15 (15.0.0_2.1.0)在 i.MX8QM 换成产品名,如“i.mx8-mek是……” 板上,目前正在进行 CAN 集成。   版本目标:mek_8q_car-nxp_stable-userdebug 我们的目标是从汽车网络接收 CAN 消息,并通过车辆 HAL (VHAL) 和车辆属性管理器框架将这些信号映射到 AAOS 车辆属性。 然而,我们面临以下问题: 目标系统上没有 CAN 接口(例如 can0)。 CAN 网络接口未出现在ifconfig -a或ip link show中。 我们想了解在 i.MX8QM-MEK 平台上将 CAN 信号集成到 AAOS 15 中的推荐方法。 根据我们的调查,我们了解到 CAN 收发器控制信号(例如 CAN01_EN 和 CAN01_STB_B)是通过连接到 M4 子系统的 I/O 扩展器,经由 M41_I2C0_1V8_SCL 和 M41_I2C0_1V8_SDA 接口进行控制的。 请问您能否帮忙澄清以下问题: AAOS 15 (15.0.0_2.1.0) 是否正式支持 CAN 功能?适用于 i.MX8QM-MEK? 要启用 CAN 接口,是否需要额外的设备树配置、内核配置、固件要求或 M4 固件依赖项? 在 Linux/Android 系统中,CAN 控制器可用之前,是否需要通过 M4 固件配置 I/O 扩展器? 是否有任何参考文档、应用笔记或示例实现可用于将 CAN 信号与 AAOS 中的 VHAL/Car Property Manager 内置? 请查看下方附件中的相关调试信息。 mek_8q:/ # ifconfig -a lo Link encap:本地环回 互联网地址:127.0.0.1 掩码:255.0.0.0 inet6 地址:::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 dummy0 链路封装:以太网硬件地址 da:0a:64:88:22:0b inet6 地址:fe80::d80a:64ff:fe88:220b/64 范围:链路 广播已启动 NOARP MTU:1500 指标:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:10 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:700 ifb0 链接 encap:以太网 HWaddr b2:9d:fa:9a:d4:6b 广播 NOARP MTU:1500 指标:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:32 接收字节数:0 发送字节数:0 ifb1 链路封装:以太网硬件地址 3e:8d:51:4e:e0:8b 广播 NOARP MTU:1500 指标:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:32 接收字节数:0 发送字节数:0 tunl0 链接封装:UNSPEC NOARP MTU:1480 公制:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 gre0 链接封装:UNSPEC NOARP MTU:1476 公制:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 gretap0 链路封装:以太网 硬件地址 00:00:00:00:00:00 广播组播 MTU:1462 度量:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 erspan0 链路封装:以太网 硬件地址 00:00:00:00:00:00 广播组播 MTU:1450 度量:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 ip_vti0 链路封装:UNSPEC NOARP MTU:1480 公制:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 ip6_vti0 链路封装:UNSPEC NOARP MTU:1364 公制:1 接收数据包:0 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 sit0 链路封装:IPv6-in-IPv4 NOARP MTU:1480 公制:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 ip6tnl0 链路封装:UNSPEC NOARP MTU:1452 公制:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 ip6gre0 链接封装:UNSPEC NOARP MTU:1448 公制:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 发送字节数:0 eth0 链路封装:以太网 硬件地址 00:04:9f:05:ed:db 驱动程序 fec 内部地址:10.16.102.48 广播地址:10.16.102.255 掩码:255.255.255.0 inet6 地址:fe80::260d:6a5f:7a04:afdd/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:301803 个,错误:0 个,丢弃:73390 个,溢出:0 个,帧:0 个 发送数据包:241 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节:52500562 发送字节:25613 mek_8q:/ # dmesg | grep i2c [ 0.062877] /bus@5b000000/usb@5b110000/usb@5b120000:修复了与 /bus@5a000000/i2c@5a800000/tcpc@51 的依赖循环 [ 0.063545] /bus@5b000000/usb@5b110000/usb@5b120000:修复了与 /bus@5a000000/i2c@5a800000/tcpc@51 的依赖循环 [ 0.075349] /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c:修复了与 /bus@56240000/ldb1-display-controller/lvds-channel@0 的依赖循环。 [ 0.075382] /bus@56240000/ldb1-display-controller/lvds-channel@0:修复了与 /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c 的依赖循环 [ 0.076099] /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c:修复了与 /bus@56240000/ldb1-display-controller/lvds-channel@0 的依赖循环。 [ 0.076180] /bus@56240000/ldb1-display-controller/lvds-channel@0:修复了与 /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c 的依赖循环 [ 0.076927] /bus@56220000/i2c@56226000/adv7535@3d:修复了与 /bus@56220000/dsi_host@56228000 的依赖循环 [ 0.076980] /bus@56220000/dsi_host@56228000:已修复与 /bus@56220000/i2c@56226000/adv7535@3d 的依赖循环 [ 0.077923] /bus@56220000/i2c@56226000/adv7535@3d:修复了与 /bus@56220000/dsi_host@56228000 的依赖循环 [ 0.078188] /bus@56220000/i2c@56226000/adv7535@3d:修复了与 /bus@56220000/dsi_host@56228000 的依赖循环 [ 0.078294] /bus@56220000/dsi_host@56228000:修复了与 /bus@56220000/i2c@56226000/adv7535@3d 的依赖循环 [ 0.079093] /bus@57220000/i2c@57226000/adv7535@3d:修复了与 /bus@57220000/dsi_host@57228000 的依赖循环 [ 0.079148] /bus@57220000/dsi_host@57228000:修复了与 /bus@57220000/i2c@57226000/adv7535@3d 的依赖循环 [ 0.080033] /bus@57220000/i2c@57226000/adv7535@3d:修复了与 /bus@57220000/dsi_host@57228000 的依赖循环 [ 0.080278] /bus@57220000/i2c@57226000/adv7535@3d:修复了与 /bus@57220000/dsi_host@57228000 的依赖循环 [ 0.080331] /bus@57220000/dsi_host@57228000:修复了与 /bus@57220000/i2c@57226000/adv7535@3d 的依赖循环 [ 0.080618] /bus@5a000000/i2c@5a800000/tcpc@51/connector:修复了与 /cbtl04gp 的依赖循环 [ 0.080674] /cbtl04gp:修复了与 /bus@5a000000/i2c@5a800000/tcpc@51/connector 的依赖循环 [ 4.329499] imx-lpi2c 5a800000.i2c:使用 PIO 模式 [ 4.335299] /bus@5b000000/usb@5b110000/usb@5b120000:修复了与 /bus@5a000000/i2c@5a800000/tcpc@51 的依赖循环 [ 4.346831] /bus@5a000000/i2c@5a800000/tcpc@51:修复了与 /bus@5b000000/usb@5b110000/usb@5b120000 的依赖循环 [ 4.358306] /bus@5a000000/i2c@5a800000/tcpc@51/connector:修复了与 /cbtl04gp 的依赖循环 [ 4.369504] i2c i2c-2: of_i2c: /bus@5a000000/i2c@5a800000/fxos8700@1e 上的模态别名失败 [ 4.378432] i2c i2c-2:创建 /bus@5a000000/i2c@5a800000/fxos8700@1e 的 I2C 设备失败 [ 4.387694] i2c i2c-2:LPI2C 适配器已注册 [ 4.393761] imx-lpi2c 5a810000.i2c:使用 PIO 模式 [ 4.399176] i2c i2c-3:使用引脚控制状态进行 GPIO 恢复 [ 4.415470] i2c i2c-3:使用通用 GPIO 进行恢复 [ 4.421623] i2c i2c-3:LPI2C 适配器已注册 [ 4.427928] imx-lpi2c 56247000.i2c:使用 PIO 模式 [ 4.433503] /bus@56240000/ldb1-display-controller/lvds-channel@0:修复了与 /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c 的依赖循环 [ 4.447437] /bus@56240000/i2c@56247000/lvds-to-hdmi-bridge@4c:修复了与 /bus@56240000/ldb1-display-controller/lvds-channel@0 的依赖循环。 [ 4.461316] i2c i2c-4:LPI2C 适配器已注册 [ 4.467791] imx-lpi2c 56226000.i2c:使用 PIO 模式 [ 4.473320] /bus@56220000/dsi_host@56228000:修复了与 /bus@56220000/i2c@56226000/adv7535@3d 的依赖循环 [ 4.484383] /bus@56220000/i2c@56226000/adv7535@3d:修复了与 /bus@56220000/dsi_host@56228000 的依赖循环 [ 4.495461] i2c i2c-5:LPI2C 适配器已注册 [ 4.501796] imx-lpi2c 57226000.i2c:使用 PIO 模式 [ 4.507337] /bus@57220000/dsi_host@57228000:修复了与 /bus@57220000/i2c@57226000/adv7535@3d 的依赖循环 [ 4.518372] /bus@57220000/i2c@57226000/adv7535@3d:修复了与 /bus@57220000/dsi_host@57228000 的依赖循环 [ 4.529441] i2c i2c-6:LPI2C 适配器已注册 [ 4.538112] i2c i2c-2:新增多路复用 i2c 总线 7 [ 4.543745] i2c i2c-2:新增多路复用 i2c 总线 8 [ 4.549248] i2c-mux-gpio i2cmux:5a800000.i2c 适配器上的 2 端口复用器 [ 4.586228] i2c i2c-2:未找到电源 VDD,使用虚拟稳压器 [ 4.593252] i2c i2c-2:未找到供电的 VDDIO,使用虚拟稳压器 [ 4.651657] st-accel-i2c 2-0019: 未找到电源 VDD,使用虚拟稳压器 [ 4.659540] st-accel-i2c 2-0019:未找到供电的 vddio,使用虚拟稳压器 [ 4.674354] st-accel-i2c 2-0019:使用驱动程序 st-accel-i2c 进行探测失败,错误代码为 -5 [ 4.684848] st-magn-i2c 8-001e:未找到电源 VDD,使用虚拟稳压器 [ 4.692677] st-magn-i2c 8-001e:未找到供电电压输入/输出 (VDIO),使用虚拟稳压器 [ 4.708084] st-magn-i2c 8-001e:未找到安装矩阵:使用标识... [ 4.720647] st-gyro-i2c 2-0069:未找到电源 VDD,使用虚拟稳压器 [ 4.728469] st-gyro-i2c 2-0069:未找到供电的 vddio,使用虚拟稳压器 [ 4.743163] st-gyro-i2c 2-0069:使用驱动程序 st-gyro-i2c 进行探测失败,错误代码为 -5 [ 4.861147] virtio_rpmsg_bus virtio1:创建通道 rpmsg-i2c-channel 地址 0x2 [ 4.876919] i2c-rpmsg virtio1.rpmsg-i2c-channel.-1.2: 新通道: 0x400 -> 0x2! [ 4.901196] imx_rpmsg_i2c i2c-rpbus-1: 成功添加 I2C 适配器 i2c-rpmsg-adapter [ 5.007981] /bus@5a000000/i2c@5a800000/tcpc@51:修复了与 /bus@5b000000/usb@5b110000/usb@5b120000 的依赖循环 [ 5.024985] /bus@5b000000/usb@5b110000/usb@5b120000:修复了与 /bus@5a000000/i2c@5a800000/tcpc@51 的依赖循环 [ 16.457456] imx-lpi2c 57247000.i2c:使用 PIO 模式 [ 16.463779] i2c i2c-9:LPI2C 适配器已注册 [ 16.470664] /bus@57240000/ldb2-display-controller/lvds-channel@0:修复了与 /bus@57240000/i2c@57247000/lvds-to-hdmi-bridge@4c 的循环依赖问题 [ 17.057471] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@0/c1 的依赖循环 [ 17.083749] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@1/c2 的循环依赖关系 [ 17.112012] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@2/c3 的依赖循环 [ 17.126760] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@3/c4 的依赖循环 [ 17.141567] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@3/camera@54:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.156682] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@2/camera@53:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.171754] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@1/camera@52:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.186407] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@0/camera@51:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.204964] imx-lpi2c 58226000.i2c:使用 PIO 模式 [ 17.211086] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@0/c1 的依赖循环 [ 17.225631] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@1/c2 的依赖循环 [ 17.240271] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@2/c3 的依赖循环 [ 17.254871] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@3/c4 的依赖循环 [ 17.269824] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@3/camera@54:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.284422] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@2/camera@53:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.299030] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@1/camera@52:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.314057] /bus@58000000/i2c@58226000/max9286_csi0@6a/i2c-mux/i2c@0/camera@51:修复了与 /bus@58000000/i2c@58226000/max9286a 的循环依赖问题 [ 17.328911] i2c i2c-10:LPI2C 适配器已注册 [ 17.349901] /bus@58000000/i2c@58226000/max9286_csi0@6a:修复了与 /bus@58000000/csi@58227000 的依赖循环 [ 17.361147] /bus@58000000/csi@58227000:修复了与 /bus@58000000/i2c@58226000/max9286_csi0@6a 的依赖循环 mek_8q:/ # mek_8q:/ # mek_8q:/ # dmesg | grep -我可以 [ 6.341664] init: 初始化程序无法将“ro.boot.boot_devices”设置为“bus@5b000000/5b010000.mmc”:只读属性已被设置 [ 6.650631] apexd-bootstrap:正在扫描 /odm/apex 目录,查找预安装的 Apex 文件 [ 6.665082] apexd-bootstrap:正在扫描 /vendor/apex 目录,查找预安装的 Apex 文件 [ 6.734597] apexd-bootstrap:正在扫描 /product/apex 目录,查找预安装的 Apex 文件 [ 7.762352] 可以:控制器区域网络核心 [ 7.767572] NET:已注册 PF_CAN 协议族 [ 7.778629] 可以:广播管理器协议 [ 7.789732] CAN 设备驱动程序接口 [ 7.798655] 可以:netlink 网关 - max_hops=1 [ 7.809873] 可以:原始协议 [ 8.206633] vdc: 线程池最大线程数为 0。无法缓存 binder,因为 linkToDeath 无法实现。服务名称:vold [ 8.306877] vdc: 线程池最大线程数为 0。无法缓存绑定器,因为无法实现 linkToDeath。服务名称:vold [ 9.537245] slcan:串行线路 CAN 接口驱动程序 [ 9.765447] vcan:虚拟 CAN 接口驱动程序 [ 9.871087] vdc:线程池最大线程数为 0。无法缓存绑定器,因为无法实现 linkToDeath。服务名称:vold [ 10.127065] apexd:线程池最大线程数为 0。无法缓存 binder,因为 linkToDeath 无法实现。服务名称:vold [ 10.140039] apexd:正在扫描 /odm/apex 目录,查找预安装的 Apex 文件 [ 10.165055] apexd:正在扫描 /vendor/apex 目录,查找预安装的 Apex 文件 [ 10.190899] 热报警已取消。GPU3D 时钟频率将恢复到 64/64 [ 12.094764] vdc: 线程池最大线程数为 0。无法缓存 binder,因为 linkToDeath 无法实现。服务名称:vold [ 12.980708] apexd-snapshotde: 线程池最大线程数为 0。无法缓存 binder,因为 linkToDeath 无法实现。服务名称:vold [ 14.174685] update_verifier: 线程池最大线程数为 0。无法缓存 binder,因为 linkToDeath 无法实现。服务名称:android.hat [ 27.936501] 平台 fec2_nvcc:延迟探测待处理:reg-fixed-voltage:无法获取 GPIO mek_8q:/ # ls /sys/总线/i2c/设备/ 1-0048 2-0020 2-0069 4-004c 7-001e i2c-1 i2c-3 i2c-6 i2c-9 10-006a 2-0044 3-001a 5-003d 8-001e i2c-10 i2c-4 i2c-7 2-0019 2-0051 4-0033 6-003d 9-004c i2c-2 i2c-5 i2c-8 Android i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: CAN Interface Availability and Integration in AAOS 15 on i.MX8QM-MEK 你好, 您需要将 FLEXCAN 添加到内核中,您可以参考 Android 用户指南第 9 章“通用内核映像 (GKI) 开发”。 https://www.nxp.com/docs/en/user-guide/UG10176.pdf 另外请注意,如果您想在 A 核心上使用它们,则需要在 SCFW 中将资源移动到该核心。 测试方面也是如此,您可以添加 canutils: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/All-Boards-FlexCAN/ta-p/1103092 此致敬礼/Saludos, 阿尔多。
記事全体を表示
Why model size is limited at 1 MB? I run model from sample tflm_cifar10 on MIMRT700 (NPU model). When building the program, I could see the model's size and correspond region size.  In many cases, the region size is 1 MB. As my understanding, the model's size is limited at 1 MB. Is that right? nnxxpp_0-1781495142659.png I did not understand this point. Here is information of MIMRT700 EVK. nnxxpp_2-1781495429888.png I don't know where model is saved on MIMRT700 EVK. And where is the 1 MB for region size? Is it actual limit of model size? Or we can increase model size by some methods. Do you have any comment for this problem? Because I try to deploy a larger model > 1 MB. I do wait for your response. Thank you. Re: Why model size is limited at 1 MB? @mayliu1  Thank you so much. Now I understood that we can increase the size of the model by setting region size. nnxxpp_0-1781514247437.png Or If I want to run larger model on external memory, I can follow this document https://docs.nxp.com/bundle/AN14700/page/topics/external_memory.html  Re: Why model size is limited at 1 MB? Hi @nnxxpp , Thank you so much for your interest in our products and for using our community. Q: I don't know where model is saved on MIMRT700 EVK. And where is the 1 MB for region size? Is it actual limit of model size? Or we can increase model size by some methods. Do you have any comment for this problem? Because I try to deploy a larger model > 1 MB. A: The 1 MB shown for modeldata is not a hardware limit of the RT700. It is only the default linker allocation used in the sample project. For larger models, this allocation can be adjusted in the project settings, and external XSPI flash can also be used if more storage is needed. For more detail information, you can refer to this AN14700. https://docs.nxp.com/bundle/AN14700/page/topics/introduction.html mayliu1_0-1781507645284.png So, the RT700 is not inherently limited to a 1 MB model. Larger NPU models are supported either by increasing the modeldata memory allocation or by placing the model in external XSPI flash with the appropriate conversion option.  Wish it helps you Best Regards May Liu Re: Why model size is limited at 1 MB? @mayliu1  I want to reopen this topic. Now i am trying to deploy larger model on RT700. The below image is captured when building the program with the small model. I see that there are 4 memory regions: - QSPI_flash: external memory - SRAM: I ask chatgpt and it is for data when running the program (like .data, .bss, stack, heap). Is that correct? - NCACHE_REGION: it is same ktensorArena (for inputs, intermediate outputs and output) -  modeldata: to save model weights I see in the memory configuration when I import SDK example. It means that SRAM, NCACHE_REGION and modeldata from SRAM (7.5 MB). NCACHE_REGION and modeldata should be located in  0x2000_0000 to 0x2058_0000 (5.5 MB) to get best perforemce (SRAM area that can be accessed by the NPU) But location of SRAM (named SRAM) is 0x20080000 (in the second image) ==> It is also in the range 0x2000_0000 to 0x2058_0000. And by default, it is set about 2.5 MB. It means that NCACHE_REGION + modeldata should be less than (5.5 - 2.5) = 3 MB. My model size is about 3.5 MB. Beside that I can locate my model on external memory (it results in larger inference time), how I can config memory to still locate my model (3.5 MB) on memory area that NPU can access? I am curious about whether we can shrink "SRAM" region (in the images 1, 2) or can I move it to another area of RAM (7.5 - 5.5 = 2 MB - the last region in the image 3)? And how I can estimate the size of "SRAM" region? In the below image, it is 15560 B. Sorry for my long questions. nnxxpp_0-1782205318606.png nnxxpp_1-1782205742121.png nnxxpp_2-1782206037185.png Re: Why model size is limited at 1 MB? @mayliu1  Good morning. Maybe you missed my new above questions.  Re: Why model size is limited at 1 MB? Hi @nnxxpp , Apologies for the delayed response. If you don’t mind, could you please create a new case for your new issue?  Thank you for your understanding and cooperation. Best Regards, May Re: Why model size is limited at 1 MB? @mayliu1  Yes, ok. Let me create new issue. Thank you. Re: Why model size is limited at 1 MB? @mayliu1  I have resolved my problem. We can locate SRAM outof 5.5 MB area for NPU. I locate modeldata and kTensorArena in area 5.5 MB and it worked. The inference time is good. But If you did not miss my questions, so I can finish soon my tasks. Thank you. Re: Why model size is limited at 1 MB? Yes. Have a nice day. Re: Why model size is limited at 1 MB? Glad to hear that your issue has been resolved. Apologies for the delayed response,   thank you for your understanding.
記事全体を表示
FRDM-IMX93 预制图像 大家好, 以下图片有何不同?我找不到更新日志文件。我需要将我的 FRDM-imx93 主板恢复为出厂设置。 谢谢! Screenshot from 2026-06-10 15-52-23.png Re: FRDM-IMX93 prebuilt images 您好 ,它们之间的变化微乎其微,我建议您使用 Linux 电路板支持包 版本,因为 FRDM 版本是我们在集成之前获得的初始软件支持。 https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX 此致, 阿尔多。
記事全体を表示
请问guider的table控件怎样在guider软件里调整每个单元格的宽度? 我在使用table控件时,在guider界面没找到调整每个单元格的宽度的按钮或输入框。请问应该怎样在设计时调整单元格宽度? Re: 请问guider的table控件怎样在guider软件里调整每个单元格的宽度? Hi @alen-liao  您好,您可以尝试修改这个参数。 Harry_Zhang_0-1781158999778.png BR Harry
記事全体を表示
IW611:无法设置 Linux 驱动程序 您好, 我正在尝试用 Linux 内核 4.19 启动 IW611。我使用的是 mwifiex 分支 if-6.12.49_2.20。 配置文件包含以下内容: SDIW612 = { cal_data_cfg=none hw_name=IW611 fw_name=nxp/sduart_nw61x_v1.bin drv_mode=0x1 auto_ds=2 pm_keep_power=1 cntry_txpwr=0 slew_rate=0 } 芯片被 MMC 总线驱动程序识别,nwifiex 驱动程序已加载。但当我尝试启动 mlan0 接口时,却出现了写入错误。谁能告诉我是什么地方配置错误或出错了? 下面是我的 dmesg 输出: [8.423408] wlan:正在加载 MWLAN 驱动程序 [8.427639] 未指定模块参数 cfg 文件 [8.632441] wlan:注册到总线驱动程序... [8.666463] vendor=0x0471 device=0x0205 class=0 function=1 [8.711324] Attach moal handle ops,卡接口类型:0x109 [8.764392] SDIW612:来自用户的初始化模块参数 [8.769688] cal_data_cfggs:SDIW612,配置块:0 [8.774488] cal_data_cfggg =无 [8.777622] hw_name=iw611 [8.780414] fw_name=nexp/sduart_nw61x_v1.bin [ 8.784838] drv_mode = 1 [ 8.787512] auto_ds = 2 [ 8.790109] pm_keep_power on [ 8.793152] cntry_txpwr = 0 [ 8.796102] slew_rate = 0 [ 8.798916] SDIO: sdio_blk_size=256 max_blk_count=65535 max_segs=64 max_seg_size=65536 [ 8.807287] rx_work=0 cpu_num=1 [ 8.810624] Enable moal_recv_amsdu_packet [ 9.101160] Attach mlan adapter operations.card_type is 0x109. [ 9.118472] wlan:启用 TX SG 模式 [ 9.122181] wlan: mpa_tx.buf_size=65280 [ 9.126231] wlan:启用 RX SG 模式 [ 9.129954] wlan: mpa_rx.buf_size=65280 [ 9.261877] 请求固件:nxp/sduart_nw61x_v1.bin [ 10.067400] Wlan:FW 下载结束,firmwarelen=913892 已下载 837692 [ 10.467947] WLAN FW 处于活动状态 [ 10.471106] on_time is 10463342042 [ 10.494983] VDLL 映像:len=76200 [ 10.498741] fw_cap_info=0x487cff03, dev_cap_mask=0xffffffff [ 10.504665] uuid: e139b70377da5b6fbc71c709b955b9a7 [ 10.509761] max_p2p_conn = 8, max_sta_conn = 16 [ 10.529596] IOCTL failed: 1b0efb8f id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] [ 10.544554] Register NXP 802.11 Adapter mlan0 [ 10.549385] wlan: version = SDIW612---18.99.2.p19.10-MM6X18540.p33-GPL-(FP92) [10.567328] 设置 REG 0x90002328:0x10d57 slew_rate=0 [10.576793] usbcore:注册了新的接口驱动程序 usbxxx [10.584854] wlan:注册到总线驱动程序完成 [10.589480] wlan:驱动程序已成功加载 这里我尝试启动 mlan0 [ 76.346952] cmd53 write error=-110 [ 76.353352] host_too_card, write iomem (1) failed: -1 [ 76.359014] write CFG reg failed [ 76.362560] cmd53 write error=-110 [ 76.366184] host_too_card, write iomem (2) 失败:-1 [ 76.371495] write CFG reg 失败 [ 76.374999] cmd53 write error=-110 [ 76.402254] host_too_card, write iomem (3) 失败:-1 [ 76.407537] write CFG reg 失败 [ 76.410971] Error: host_to_card failed: 0xFFFFFFFF [ 76.416043] DNLD_CMD: Host to Card Failed [ 76.420306] IOCTL failed: ef7a4e76 id=0x90000, sub_id=0x90001 action=1, status_code=0x80000006 [CMD_DNLD_FAIL] [ 76.430903] ------------Dump info----------- [ 76.435415] Command to card failure [ 76.439111] pending command id: 0x10 ioctl_buf= (null) [ 76.444634] pending command id: 0x28 ioctl_buf=a69aa9f8 [ 76.450155]没有待执行的扫描命令 [ 76.453847] CurCmd 空 [ 76.456521] mlan_processing =1 [ 76.459753] main_lock_flag =0 [ 76.462885] main_process_cnt =75 [ 76.466292] delay_task_flag =0 [ 76.469523] mlan_rx_processing =0 [ 76.473022] rx_pkts_queued=0 [ 76.476061] more_task_flag = 0 [ 76.479292] num_cmd_timeout = 0 [ 76.482607] last_cmd_index = 2 [ 76.485830] last_cmd_id = [ 76.485834] 0x27c [ 76.488698] 0x27c [ 76.490818] 0x243 [ 76.492938] 0xe4 [ 76.495058] 0x5b [ 76.497086] 0x242 [ 76.499123] 0x4d [ 76.501243] 0xd1 [ 76.503271] 0x10 [ 76.505299] 0x28 [ 76.510935] last_cmd_act = [ 76.510937] 0x0 [ 76.513885] 0x1 [ 76.515821] 0x0 [ 76.517757] 0xff [ 76.519704] 0x1 [ 76.521732] 0x1 [ 76.523668] 0x1 [ 76.525604] 0x0 [ 76.527540] 0x1 [ 76.529486] 0x213 [ 76.535109] last_cmd_resp_index = 2 [ 76.538799] last_cmd_resp_id = [ 76.538802] 0x827c [ 76.542117] 0x827c [ 76.544329] 0x8243 [ 76.546540] 0x805b [ 76.548761] 0x805b [ 76.550973] 0x8242 [ 76.553185] 0x804d [ 76.555396] 0x80d1 [ 76.557608] 0x8010 [ 76.559828] 0x8028 [ 76.565819] last_event_index = 1 [ 76.569233] last_event = [ 76.569236] 0x0 [ 76.571999] 0x81 [ 76.573936] 0x0 [ 76.575963] 0x0 [ 76.577907] 0x0 [ 76.579844] 0x0 [ 76.581780] 0x0 [ 76.583716] 0x0 [ 76.585652] 0x0 [ 76.587587] 0x0 [ 76.593035] num_data_h2c_failure = 0 [ 76.596809] num_cmd_h2c_failure = 1 [ 76.600500] num_data_c2h_failure = 0 [ 76.604275] num_cmdevt_c2h_failure = 0 [ 76.608241] num_int_read_failure = 0 [ 76.612015] last_int_status = 64 [ 76.615422] num_alloc_buffer_failure = 0 [ 76.619572] num_pkt_dropped = 0 [ 76.622888] num_noo_cmd_node = 0 [ 76.626202] num_event_deauth = 0 [ 76.629617] num_event_disassoc = 0 [ 76.633208] num_event_link_lost = 0 [ 76.636890] num_cmd_deauth = 0 [ 76.640121] num_cmd_assoc_success = 0 [ 76.643987] num_cmd_assoc_failure = 0 [ 76.647860] num_cons_assoc_failure = 0 [ 76.651818] cmd_resp_received=0 [ 76.655133] event_received=0 [ 76.658180] max_tx_buf_size=4096 [ 76.661587] tx_buf_size=3072 [ 76.664626] curr_tx_buf_size=3072 [ 76.668134] data_sent=0 cmd_sent=0 [ 76.671725] ps_mode=1 ps_state=0 [ 76.675133] wakeup_dev_req=0 wakeup_tries=0 wakeup_timeout=0 [ 76.681121] hs_configured=0 hs_activated=0 [ 76.685448] pps_uapsd_mode=0 sleep_pd=0 [ 76.689506] tx_lock_flag = 0 [ 76.692545] scan_processing = 0 [ 76.695859] scan_state = 0x0 [ 76.698907] bypass_pkt_count=0 [ 76.702132] mp_rd_bitmap=0x0 curr_rd_port=0x0 [ 76.706734] mp_wr_bitmap=0xffffff curr_wr_port=0x0 [ 76.711987] mp_data_port_mask = 0xffffff [ 76.716314] last_recv_rd_bitmap=0x0 mp_invalid_update=0 [ 76.721843] last_recv_wr_bitmap=0xffffffff last_mp_index=0 [ 76.727641] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.734364] 0x00 [ 76.734367] 0x00 [ 76.736395] 0x00 [ 76.738432] 0x00 [ 76.740460] 0x00 [ 76.742488] 0x00 [ 76.744516] 0x00 [ 76.746543] 0x00 [ 76.748580] 0x00 [ 76.750609] 0x00 [ 76.752637] 0x00 [ 76.754665] 0x00 [ 76.756692] 0x00 [ 76.758729] 0x00 [ 76.760757] 0x00 [ 76.762785] 0x00 [ 76.768417] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.775131] 0x00 [ 76.775133] 0x00 [ 76.777162] 0x00 [ 76.779199] 0x00 [ 76.781227] 0x00 [ 76.783255] 0x00 [ 76.785283] 0x00 [ 76.787311] 0x00 [ 76.789348] 0x00 [ 76.791376] 0x00 [ 76.793404] 0x00 [ 76.795437] 0x00 [ 76.797465] 0x00 [ 76.799502] 0x00 [ 76.801531] 0x00 [ 76.803559] 0x00 [ 76.809192] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.815906] 0x00 [ 76.815908] 0x00 [ 76.817944] 0x00 [ 76.819973] 0x00 [ 76.822001] 0x00 [ 76.824029] 0x00 [ 76.826057] 0x00 [ 76.828093] 0x00 [ 76.830121] 0x00 [ 76.832149] 0x00 [ 76.834177] 0x00 [ 76.836205] 0x00 [ 76.838241] 0x00 [ 76.840269] 0x00 [ 76.842297] 0x00 [ 76.844325] 0x00 [ 76.849957] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.856671] 0x00 [ 76.856673] 0x00 [ 76.858711] 0x00 [ 76.860739] 0x00 [ 76.862774] 0x00 [ 76.864803] 0x00 [ 76.866831] 0x00 [ 76.868868] 0x00 [ 76.870897] 0x00 [ 76.872925] 0x00 [ 76.874953] 0x00 [ 76.876981] 0x00 [ 76.879018] 0x00 [ 76.881046] 0x00 [ 76.883074] 0x00 [ 76.885102] 0x00 [ 76.890734] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.897448] 0x00 [ 76.897451] 0x00 [ 76.899488] 0x00 [ 76.901516] 0x00 [ 76.903544] 0x00 [ 76.905572] 0x00 [ 76.907599] 0x00 [ 76.909636] 0x00 [ 76.911665] 0x00 [ 76.913693] 0x00 [ 76.915721] 0x00 [ 76.917749] 0x00 [ 76.919785] 0x00 [ 76.921813] 0x00 [ 76.923841] 0x00 [ 76.925869] 0x00 [ 76.931501] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.938223] 0x00 [ 76.938226] 0x00 [ 76.940254] 0x00 [ 76.942282] 0x00 [ 76.944310] 0x00 [ 76.946337] 0x00 [ 76.948374] 0x00 [ 76.950402] 0x00 [ 76.952430] 0x00 [ 76.954457] 0x00 [ 76.956485] 0x00 [ 76.958521] 0x00 [ 76.960550] 0x00 [ 76.962578] 0x00 [ 76.964605] 0x00 [ 76.966633] 0x00 [ 76.972265] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.978987] 0x00 [ 76.978990] 0x00 [ 76.981018] 0x00 [ 76.983046] 0x00 [ 76.985074] 0x00 [ 76.987102] 0x00 [ 76.989138] 0x00 [ 76.991167] 0x00 [ 76.993195] 0x00 [ 76.995222] 0x00 [ 76.997250] 0x00 [ 76.999286] 0x00 [ 77.001315] 0x00 [ 77.003343] 0x00 [ 77.005371] 0x00 [ 77.007399] 0x00 [ 77.013031] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.019753] 0x00 [ 77.019756] 0x00 [ 77.021784] 0x00 [ 77.023812] 0x00 [ 77.025840] 0x00 [ 77.027876] 0x00 [ 77.029905] 0x00 [ 77.031940] 0x00 [ 77.033969] 0x00 [ 77.035997] 0x00 [ 77.038033] 0x00 [ 77.040062] 0x00 [ 77.042090] 0x00 [ 77.044118] 0x00 [ 77.046145] 0x00 [ 77.048182] 0x00 [ 77.053806] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.060529] 0x00 [ 77.060531] 0x00 [ 77.062560] 0x00 [ 77.064587] 0x00 [ 77.066615] 0x00 [ 77.068652] 0x00 [ 77.0x00 [ 77.072708] 0x00 [ 77.074736] 0x00 [ 77.076764] 0x00 [ 77.078801] 0x00 [ 77.080829] 0x00 [ 77.082857] 0x00 [ 77.084884] 0x00 [ 77.086912] 0x00 [ 77.088949] 0x00 [ 77.094572] mp_wr_bitmap:0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.101295] 0x00 [ 77.101297] 0x00 [ 77.103326] 0x00 [ 77.105354] 0x00 [ 77.107381] 0x00 [ 77.109418] 0x00 [ 77.111446] 0x00 [ 77.113474] 0x00 [ 77.115502] 0x00 [ 77.117529] 0x00 [ 77.119566] 0x00 [ 77.121595] 0x00 [ 77.123623] 0x00 [ 77.125650] 0x00 [ 77.127678] 0x00 [ 77.129715] 0x00 [ 77.135341] bss_index = 0, tx_pkts_queued = 0 tx_pause [ 77.140796] Host:chillair-r1234yf-00050 Timestamp:9c6953b9 [ 77.146691] Driver version = SDIW612---18.99.2.p19.10-MM6X18540.p33-GPL-(FP92) [ 77.154431] main_state = 3 [ 77.157287] ioctl_pending = 1 [ 77.160428] tx_pending = 0 [ 77.163285] wmm_tx_pending[0] = 0 [ 77.166783] wmm_tx_pending[1] = 0 [ 77.170291] wmm_tx_pending[2] = 0 [ 77.173790] wmm_tx_pending[3] = 0 [ 77.177288] rx_pending = 0 [ 77.180152] lock_count = 44 [ 77.183100] malloc_count = 49 [ 77.186231] mbufalloc_count = 0 [ 77.189554] hs_skip_count = 0 [ 77.192685] hs_force_count = 0 [ 77.195909] Media state ="Disconnected" [ 77.200059] carrier off [ 77.202641] tx queue 0: stopped [ 77.205956] tx queue 1: stopped [ 77.209279] tx queue 2: stopped [ 77.212595] tx 队列 3: stopped [ 77.215911] mlan0: num_tx_timeout = 0 [ 77.219799] -------- Dump info End--------- [ 77.237865] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready [ 77.270404] SDIO Func0 (0x0-0x9):ERR [ 77.274349] SDIO Func1 (0x10-0x17):ERR [ 77.278454] SDIO Func1: (0x8) ERR [ 77.282147] SDIO Func1 (0xe8-0xff):ERR [ 77.387444] SDIO Func1 (0xe8-0xff):ERR [ 77.391567] set pending clean [ 77.471612] SDIO Write ERR [ 77.474573] SDIO Write ERR [ 77.477436] ==== DEBUG MODE OUTPUT START: 77.469673 ==== [ 77.483111] SDIO Write ERR [ 77.485995] SDIO Write ERR [ 77.488871] ==== DEBUG MODE END ==== [ 77.492866] IOCTL 失败: a69aa9f8 id=0x20000, sub_id=0x20007 action=1, status_code=0x80000007 [CMD_CANCEL] (CMD_CANCEL) Re: IW611: Unable to setup Linux driver 你好@mlytvyn 您能试试 50MHz 的频率吗? 顺祝商祺! 肖恩 Re: IW611: Unable to setup Linux driver 我有 TI Sitara AM4376。 image.png image.png MMC 总线配置如下:   &mmc3 { status = "okay"; dmas = <&edma_xbar 30 0 1>, <&edma_xbar 31 0 2>; dma-names = "tx", "rx"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&mmc3_pins_default>; pinctrl-1 = <&mmc3_pins_sleep>; vmmc-supply = <&dcdc4>; bus-width = <4>; cap-sdio-irq; ti,non-removable; max-frequency = <25000000>; /* slow down to 25MHz for bring-up */ }; MMC 总线控制器设法检测到 Wi-Fi 芯片,内核加载了正确的驱动程序,驱动程序使用提供的固件 blob 闪存了芯片,并从芯片中获得了固件版本。对我来说,这不像是 SDIO 配置问题,而像是与驱动程序(或 FW)有关的问题。 第一个错误发生在这里 [ 10.529596] IOCTL 失败: 1b0efb8f id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] 司机在这个阶段要做什么? 顺祝商祺! 米哈伊洛 Re: IW611: Unable to setup Linux driver 你好@mlytvyn 您使用的是哪台主机? 驱动程序加载和固件下载没有问题。 sdio 通信报告错误。 顺祝商祺! 肖恩 Re: IW611: Unable to setup Linux driver 您好, 变化不大 mlytvyn_0-1780995812806.png 在这里,我启动了 mlan0,然后得到 mlytvyn_2-1780995954838.png mlytvyn_1-1780995851394.png 我遇到了同样的错误 IOCTL failed: 61e24fe7 id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] 失败 Re: IW611: Unable to setup Linux driver 你好@mlytvyn 能否告诉我们您使用的是哪种 iw612 模块?还是您正在使用 iw612evk?我注意到你的 sd 接口是 3.3V,你匹配了 sdio 功率级吗? 顺祝商祺! 肖恩 Re: IW611: Unable to setup Linux driver 我使用的是 Silex SX-SDMAX 表面贴装版(https://www.silextechnology.com/connectivity-solutions/embedded-wireless/sx-sdmax)。据我所知,VIO 和 VIO_SD 上的电压决定了信号电平。 
記事全体を表示
Cell Balancing not working again on MC33774A Hi everyone, I am working with the MC33774A to balance cell pins. First, I set balancing for cell 1 (3.7 V) with an under-voltage threshold UV0 = 3.6 V. When I read the BAL_CH_UV0_STAT0 register, the value is 0x0C00. This makes sense because cell 11 (3.4 V) and cell 12 (3.3 V) are below the threshold. Then, I changed the under-voltage setting to UV0 = 3.2 V (lower than 3.6 V) and activated cell balancing for cell 11 and cell 12, but it did not work. After referring to the MC33774A datasheet, I realized that in voltage-controlled mode there is a third input, which is the status of BAL_CH_UV0_STAT. So, I want to clear the bits of BAL_CH_UV0_STAT (from 0x0C00 to 0x0000) to allow the balancing process to run again. However, these bits are read-only, with a “read clears bit” behavior. I tried to read the entire BAL_CH_UV0_STAT0 register using the command: Bcc_774a_COM_ReadRegisters(BCC_CHAIN_ADDR, 1, MC33774_BAL_CH_UV0_STAT0_OFFSET, 1, Bms_TD);   But the returned value of BAL_CH_UV0_STAT0 is always 0x0C00. It seems that the bits are not being cleared.  Currently, I am facing an issue where I cannot clear the bits in the BAL_CH_UV0_STAT0 register, and I would appreciate any help. Re: Cell Balancing not working again on MC33774A HI  Please follow below step to set CB function under UV condition,seems you don't have correct steps setting for this CB function test.: 1: wake up and assign CID guoweisun_0-1780887697263.png Re: Cell Balancing not working again on MC33774A Hi guoweisun, thanks for your help. After reviewing the steps you provided, I think that I have set the CB function under UV condition correctly. But my issue is not with the configuration steps, but rather with clearing the values in the 'BAL_CH_UV0_STAT0' register. Anyway, thank you so much for your support. While going through the steps you mentioned, I rechecked the datasheet and was able to find a solution to my issue.
記事全体を表示
FRDM Device Trees for Education and Rapid Prototyping To simplify development on the NXP FRDM board family, new device trees have been created for the i.MX91, i.MX93, i.MX95, and i.MX8MP platforms. These device trees are intended to provide a more ready to use out of the box experience by preconfiguring the Raspberry Pi connector with the same peripheral mapping commonly expected on Raspberry Pi compatible hardware. With this approach, developers, students, and makers can use compatible expansion boards and HAT style accessories more easily, without needing to create or significantly modify additional device tree files. Instead of spending time on low level hardware description updates, users can start evaluating peripherals and building applications directly on top of the provided configurations. For convenience, this post includes a .zip package containing: The compiled device tree binaries (.dtb) The device tree source files (.dts) The kernel patch for the NXP Linux Kernel 6.18 required to integrate these changes All files are attached to this post, allowing users to easily reuse, modify, or integrate the device trees into their own projects. To configure a new device tree, compile it, and flash it onto the target, you can refer to the following guides: How to compile Linux Kernel Image and device tree using Yocto SDK Flash customized Linux Kernel Image and device tree using UUU Tool
記事全体を表示
Polaris12 SMUファームウェアの起動中にAMDGPUが失敗する チームの皆さん、こんにちは。 弊社ではNXP T1040RBDボードを使用していますが、amdgpuドライバのロード中にPolaris12 SMUファームウェアの起動時にエラーが発生します。 以下にログファイルとカーネル設定ファイル、dtbファイルを示します。 amdgpu: メッセージ100の送信に失敗しました。戻り値は0です。 amdgpu: SMUファームウェアの起動に失敗しました! amdgpu: SMUマイクロコードの読み込みに失敗しました。 amdgpu: ファームウェアのロードに失敗しました amdgpu: smuファームウェアの読み込みに失敗しました amdgpu 0001:01:00.0:amdgpu: amdgpu_device_ip_init が失敗しました amdgpu 0001:01:00.0:amdgpu: GPU初期化中に致命的なエラーが発生しました amdgpu 0001:01:00.0:amdgpu: amdgpu: デバイスの処理を完了します。 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 amdgpu: 0001:01:00.0 のプローブがエラー -22 で失敗しました Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは、 申し訳ありませんが、T1040 上の Polaris12 amdgpu 用の NXP ドライバ側の修正プログラムや既製のリポジトリは存在しません。そのため、動作させようとすると、お客様自身で SDKs カーネルを開発する必要があり、PCIe ウィンドウイングやエンディアンに関する重大なリスクを伴います。 よろしくお願いします。 Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは、 入手可能なドキュメントによると、T1040RDBはPCIeカードをホストできますが、AMD Polaris12 amdgpu 動作はサポートまたは検証されていません。この不具合は、既知のNXP PCIe起動修正ではなく、サポートされていないビッグエンディアンのPowerPCホストとの互換性の問題に起因する可能性が最も高いです。 よろしくお願いします。 Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは ドライバ側でこの問題を解決する方法はありますか? よろしくお願いいたします。 ガネーシャ
記事全体を表示
S32K3 LPSPI 部件问题 你好,Nxp 专家: 如果使用 GPIO 引脚手动控制 LPSPI 芯片选择 (CS),S32DS 配置工具中的 SpiCsPolarity 设置是否仍会对其产生影响?是否需要禁用工具中的 PCS(外设芯片选择)选择?另外,SpiHostRequest 参数的作用是什么? focusdoit_0-1779058033130.png Re: S32K3 LPSPI pcs question 你好@focusdoit 如果使用 GPIO 引脚手动控制 LPSPI 芯片选择 (CS),S32DS 配置工具中的 SpiCsPolarity 设置是否仍会对其产生影响? 不,它不应该影响行为。 如果使用 GPIO 作为芯片选择,则需要对其进行控制。SpiCsPolarity 参数适用于由 LPSPI 外设管理的硬件控制 CS,不适用于 GPIO 控制信号。 是否需要禁用工具中的 PCS(外设芯片选择)选择? 如果在 ConfigTools 中使用低级驱动器 (IP),则只需将所需引脚配置为 GPIO,而无需配置任何 PCS 引脚。 对于高级驱动器(MCAL),除了将引脚配置为 GPIO 外,还有一个名为 SpiCsSelection 的参数。该参数应设置为 CS_VIA_GPIO。在这种情况下,驱动程序将使用通知(由节点 SpiJobStartNotification 和 SpiJobEndNotification 定义),通过 GPIO 控制每个 SPI 作业的 CS 引脚。 另外,SpiHostRequest 参数的作用是什么? 在主模式下,此参数允许 LPSPI 模块仅在钳位主机请求输入时才开始新的 SPI 传输。如果 LPSPI 忙碌,主机请求输入将被忽略。 在从属模式下,当有数据可传输时,它会使 HREQ 输出引脚断言。 BR、VaneB
記事全体を表示
无法订购 OM13089 我想订购 LpcXpresso54114 板零件 OM14089。该板的网页显示它仍处于活跃状态,但所有供应商都没有库存,而且似乎无法直接从恩智浦订购。 这个板怎么了?LPC54114 有不同的首选开发板吗? LPC营销 Re: Unable to Order OM13089 你好@kk7xo、 谢谢您的帖子。 让我内部检查一下 OM13089 的状态。一旦有任何最新消息,我会尽快给您回复。 BR 西莱斯特 Re: Unable to Order OM13089 你好@kk7xo、 我确认 OM13089 没有过时,在我们的内部系统中,它仍处于激活状态。 但是由于运行率极低和成本限制,并且由于我们建议将所有新设计迁移到MCX平台,因此我们一直没有为该板补充库存。 这可能就是一些代理商在其网站上将其标记为 “过时” 的原因,尽管官方生命周期仍处于活动状态。 根据您当前的需求,我们建议迁移到 LPC54100 系列的 OM13077 板,或者使用可用的原理图文件自己构建电路板。很抱歉给您带来不便。 Celeste_Liu_0-1778665311592.png 祝您有美好的一天。 BR 西莱斯特
記事全体を表示