Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
i.MX6ULL 中断频繁触发(21f4000.serial) 大家好,系统运行时发现卡顿,通过排查发现有一个中断计数异常,这个外设是rs485。在前一天晚上是3亿多次, 67: 334823120 GPC 30 Level 21f4000.serial 第二天变得更多。 我们只有一个进程在使用这个串口收发数据,正常的业务不会这么频繁的发送数据 异常的波形如下 正常波形 当拔掉rs485与外设的通信线后,中断计数增加变为正常,后续重新进行我们设备的业务,中断计数每秒增加几万次。最终是通过重启使用uart的进程恢复的。我们有三台同时运行的设备,只有这一台会这样,并且是突然出现的。正常运行的数据如下图所示 我们想知道为什么会出现这种情况,谢谢! i.MX6UL Re: i.MX6ULL 中断频繁触发(21f4000.serial) 你好@JosephAtNXP、 非常感谢你们在这个问题上的支持。我想提供一个更新:在我们重新启动使用 UART4 的进程后,设备就恢复了正常运行。从那以后,我们一直在监测,问题没有再出现。 就上下文而言,这条 RS485 总线上有两个从属设备。当时,我们检查了来自从属设备的日志,但没有发现任何明显的异常。实际上,我们已经调整了进程的日志级别,以捕获异常状态下的原始数据包,但是在作为该过程的一部分重新启动 UART4 进程后,问题得到了解决,不幸的是我们无法捕获有问题的数据包。 此致 Re: i.MX6ULL 中断频繁触发(21f4000.serial) 你好@xisuisan222、 这种孤立的行为似乎是物理问题,线路必须有一个代理,如电缆,另一端,硬件故障。 将所有元件通电后,您发现有什么不同吗? 此致
記事全体を表示
S32K clock mechanism & configuration First let us see the clock tree: Core clock up to 112M, Bus clock up to 56M, Flash clock up to 28M. Clock can been from: System OSC、Slow IRC 、Fast IRC and System PLL 1. OSC SCG_SOSCCFG 2. PLL configuration formula: SPLL_CLK = (VCO_CLK)/2 VCO_CLK = SOSC_CLK/(PREDIV + 1) *(MULT + 16)  3. SCG_SPLLCSR void SystemClockInit(void) { SCG->SOSCCFG = 0x3C; SCG->SOSCCSR |= 1<<0; /* SOSCEN=1 enable SOSC clock */ /*wait clock active*/ while((SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK) == 0); SCG->SPLLCSR &= ~(0x1<<0) ; /* SPLLEN=0: disable PLL*/ SCG->SPLLCFG &= ~(0x7<<8); /* PREDIV=0: 1 */ SCG->SPLLCFG |= 0xCU<<16; /* MULT=12: 28   PLL VCO = 8/1*(12+16) = 224M */ SCG->SPLLCSR |= 0x1<<0; /* SPLLEN=1: enable PLL */ /* wait PLL active*/ while((SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK) == 0); SCG->RCCR |= SCG_RCCR_DIVCORE(0); /* DIVCORE=0: 1, CORE/SYS_CLK  112MHz */ SCG->RCCR |= SCG_RCCR_DIVBUS(1); /* DIVBUS=1: 2, BUS_CLK  56MHz */ SCG->RCCR |= SCG_RCCR_DIVSLOW(3); /* DIVSLOW=2: 4   FLASH_CLK  is 28MHz */ SCG->RCCR &= 0xFEFFFFFF; /* Initially set to SIRC so that LSB could be set as '0' */ SCG->RCCR |= SCG_RCCR_SCS(6); /* SCS=6: system clock System PLL */ }
記事全体を表示
电池管理系统的重要指标:SOC、SOH、SOP(日本博客) 重要的电池指标 在当今日益电气化的社会中,锂离子电池在电动汽车和储能系统中扮演着核心角色。然而,电池性能并非始终如一,而是会受到多种因素的影响,例如环境条件、老化程度和制造差异。因此,需要电池管理系统( BMS )来持续监控和控制电池状态。 电池管理系统(BMS)是电池的核心部件,它负责最大限度地提高电池的安全性、性能和使用寿命,并基于多个指标进行决策和控制。本文将解释BMS处理的三个关键指标:荷电状态(SOC) 、健康状态(SOH)和运行状态(SOP) ,以及它们的定义、概念和各自的作用。 有关 BMS 的基本信息,请参阅我们之前的文章(什么是电池管理系统 (BMS)? )。 SOC:目前电量如何? SOC(充电状态)是衡量电池当前充电量的指标。SOC 的计算公式如下, %が満充電、0%表示电池完全放电的状态。 SOC = 剩余 电量 / 满电电量 × 100 这里,Q 剩余 电量是当前的电量,Q 满电电量 是充满电时的电量。 在表示排放深度(即排放程度)时,有时会使用DOD(排放深度)作为指标,它是通过从 100% 中减去 SOC 来计算的。 SOC(荷电状态)对于控制电池以防止过充和过放至关重要,同时也有助于优化能量效率。如果SOC精度较低,则存在因过充和过放而导致电池性能下降的风险,因此需要精心设计,并为判断阈值留出较大的裕量。 由于这与续航里程和充电容量直接相关,因此可以说 SOC 是用户体验方面一个非常重要的指标。 SOH:电池状况有多糟糕? SOH(健康状态)是一个指示电池劣化程度的指标。在计算新电池时,用 100 减去 SOH 得到的值%とし、使用や経年によって徐々に低下します。100%有时被称为SOD(劣化状态) 。 SOH 的计算方法如下,它是电池购买时完全充电容量与新电池完全充电容量的百分比。 SOH = Q 满电荷 / Q 初始满电荷 × 100 这里,Q full charge指的是当前充满电时的容量(也称有效容量),Q initial full charge 指的是新电池充满电时的容量(也称额定容量)。Q full charge 与 SOC 计算中使用的 Qfull charge 相同。 电池健康状态 (SOH) 用于预测电池寿命、确定更换时间,并作为保修范围的依据。随着 SOH 的降低,输出功率和容量也会下降,因此从保持性能的角度来看,SOH 是一个重要的指标。 尤其是在汽车应用中,定期监测至关重要,因为电池健康状态 (SOH) 的下降会直接影响续航里程和加速性能。此外,在电动汽车电池的再利用中,SOH 也是判断电池是否可以再次使用以及用于何种用途的重要指标。 标准操作程序:最大瞬时功率输出是多少? SOP(功率状态)是指电池在任何给定时刻可以安全输入和输出的功率大小。它有时也表示为SOF(功能状态) 。 在电动汽车中,SOP(峰值功率)代表加速性能和应对突发负载变化的能力,也是快速充电时最大功率的指标。SOP值越高,充电速度越快,加速性能越强,从而带来更强劲的驾驶体验。 额定工作功率 (SOP) 受温度和电池老化等因素影响。例如,当温度过高或过低时,出于安全考虑,必须降低充放电功率,这意味着 SOP 会降低。此外,如果电池老化且内阻增大,即使输入电压相同,电流也会减小,而内阻增大又会导致发热,从而产生协同效应,进一步降低 SOP。 无论哪种情况,如果对标准操作程序 (SOP) 没有准确理解,您将被迫按照标准操作程序 (SOP) 预留余量进行设计,这将导致性能下降。 因此,准确理解标准操作规程对于确保电池安全并最大限度地发挥其性能至关重要。 关联指标及楼宇管理系统的作用 与电池管理系统(BMS)相关的三个指标的解释可以概括如下: SOC:电池当前可用容量的指标。 SOH:表示电池劣化程度的指标,以当前电池容量与新电池容量的比值表示。 SOP:表示当前电池能够安全提供的最大输入/输出功率的指标。 这些指标并非单独使用,而是共同构成电池管理系统 (BMS) 的基础。即使每个指标都表现良好,仍可能出现以下问题: 即使 SOC 很高,如果 SOH 很低,充满电后的容量也很小,电池不能长时间使用。 即使 SOC 和 SOH 很高,如果 SOP 很低,丰富的电池容量也无法有效利用。 即使 SOP 很高,如果 SOC 很低,电池也会很快耗尽。 BMS 实时监控和控制这些指标,其中 CMU(电池监控单元)获取电池电压和温度,BMU(电池管理单元)对整体状况进行综合评估,BJB(电池接线盒)在执行安全控制的同时监控电流和总电压。 恩智浦的电池管理系统解决方案可同时提升性能和安全性。 NXP 的BMA7118和MC33777产品对提高 BMS 中关键指标的准确性和确保安全性做出了重大贡献。 BMA7118是一款 CMU IC,可对多达 18 节锂离子电池进行高精度监测。其 ±0.8mV 的电压测量精度和出色的温度补偿功能提高了 SOC 和 SOH 估算的准确性。此外,其电池均衡功能和低功耗设计可提高电池利用率。 MC33777是一款用于 BJB 的监控 IC,能够高速监控电流、电压和温度,从而实时获取确定 SOP 所需的必要信息。通过集成关键功能,MC33777 有望减少高达 80% 的元件数量。此外,其无需 MCU 干预即可运行的事件检测功能,能够对异常情况做出即时响应,从而确保高安全性。 有关 MC33777 的更多信息,请参阅我们的新闻简报。 MC33777MC33777 以上两款产品均能提供文档和生产级软件驱动程序,以支持功能安全。结合使用这两款产品,可实现从电芯到电池组的集成式电池管理,从而为下一代电动汽车和储能系统提供最佳的电池管理系统 (BMS) 配置。 如果您想提高 SOC、SOH 和 SOP 的准确性和可靠性,NXP 的 BMS 解决方案是最佳选择。 =========================== 更改历史记录 2025/09/11:博客文章 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接询问负责人。) 下面解释了电池管理系统(BMS)的三个重要指标。 重要的电池指标 SOC:目前电量如何? SOH:电池状况有多糟糕? 标准操作程序:最大瞬时功率输出是多少? 关联指标及楼宇管理系统的作用 恩智浦的电池管理系统解决方案可同时提升性能和安全性。 我们希望您了解需要管理的指标以及楼宇管理系统的重要性。 (阅读时间:10分钟) 日本博客
記事全体を表示
什么是实时时钟(RTC)芯片?(日文博客) 什么是实时时钟(RTC)芯片? 在本文中,我们将解释 RTC 的作用以及哪些类型的系统需要外部 RTC ,重点介绍 NXP 的RTC 模块产品,该产品具有最低的电流消耗和最高的计时精度。 使用外部 RTC 有以下优点:1)由于功耗较低,电池寿命更长;2)时间管理更精确;3)系统可靠性更高;4)通过附加功能提高安全性。 在文章的最后,我们还将介绍一个评估环境 (电路板+软件), 让您可以立即试用RTC 。 カレンダーと時計日历和时钟 图 1:RTC = 时钟和日历集成到系统中 时钟 + 日历 许多家用电器和小工具都具备显示时钟的功能。这些设备内置的时钟不仅用于显示当前日期和时间,还用于多种用途,例如作为定时器自动开关机,以及记录日志以进行调试和系统管理。 这种时钟功能是通过称为实时时钟( RTC ) 的电路实现的,该电路可以内置于微控制器或处理器中,也可以通过外部 RTC 芯片实现。 RTC 使用其自身晶体振荡器产生的时钟来计时。通过计数器对该时钟进行计数,即可得出当前时间和日期[图 2]。 图2:实时时钟 (RTC) 内部结构。晶体、振荡器、计数器和接口 实时时钟(RTC)内置于微控制器和处理器中。 许多微控制器和处理器在其芯片中内置了 RTC 电路[图 3]。 只要这些微控制器或处理器获得电源,即使芯片处于睡眠或断电等非活动状态,RTC 也会继续更新指示当前时间和日期的值(计数器值) 。 这些功能使系统能够在设定的日期和时间准确启动,或者准确记录 RTC 电路断电期间发生的事件的时间。 图 3:内置于微控制器中的 RTC(例如: MCXN94x/MCXN54x ) 保持 RTC 运行:功耗 例如,要实现定时开关电源的功能,设备必须能够在设定的时间操作电源开关。因此,设备内部必须持续记录时间信息,并且必须有机制确保实时时钟(RTC)不会断电。 为了使实时时钟 (RTC)在主电源关闭时也能运行,必须始终由电池供电。如果设备没有电池,则应为 RTC 提供备用电源,例如纽扣电池或超级电容器[图 4]。 由于实时时钟 (RTC) 会不断消耗电池电量,因此降低电流消耗非常重要。 图 4:RTC 评估板示例。PCF2131/PCA2131 Arduino ® Shield 评估板包含一个内置纽扣电池作为备用电源。 时间重新同步:时间精度 启动实时时钟 (RTC) 时,必须设置当前时间。此初始设置可确保 RTC 保持正确的当前日期和时间。如果不进行初始设置,RTC 将继续更新自其重置时的默认日期和时间以来经过的时间。 当前日期和时间可以由用户手动设置(通过按按钮等),也可以通过网络与 NTP 服务器自动同步,或者与 GPS同步。 初始设置完成后,即使主电源关闭,只要实时时钟 (RTC) 继续通电,它就会使用自身的时钟持续更新时间。该时钟的精度决定了时间的精度。时钟精度受多种因素影响,主要因素包括晶体振荡器的精度、振荡器电路的匹配度以及温度。 如果设备频繁开机且每次都能重新同步时间,则可能不需要高精度。但是,如果设备长时间关机,或者系统无法访问 GPS 或时间服务器,则需要一个精度满足系统要求的实时时钟 (RTC) 。 使用外部实时时钟的优势 如果您正在构建的系统使用微控制器或处理器内置的 RTC 就能正常工作,则无需使用外部 RTC芯片。 但是,如果您需要最大限度地延长电池寿命或保持准确的时间,则需要外部 RTC [图 5]。 图 5:使用外部实时时钟的系统。除实时时钟外,其他所有设备的电源均可关闭,以降低功耗。   使用外部实时时钟有四个主要优点。让我们一起来看看。 优势一:延长电池寿命(降低整个系统的功耗) 优势二:精准的时间管理 优势三:可靠性提高 优势 4:附加功能 优势一:延长电池寿命(降低整个系统的功耗) 对于内置于微控制器/处理器中的实时时钟 微控制器和处理器的设计和优化都针对其主要功能:控制和计算能力。这种优化也包括功耗优化,从而提高处理效率。 这些芯片还具有“睡眠”和“关机”模式,旨在通过仅在不需要处理时保持必要的功能来降低电流消耗。 例如,恩智浦半导体最新的MCX系列微控制器具有“深度掉电”功能,此时仅保持内置实时时钟(RTC)运行。此时的电流消耗因芯片型号而异。易于使用的通用微控制器MCX-A系列功耗仅为几百纳安,而处理能力更强的MCX-N系列则功耗为微安级。这些例子中的电流值可以说“相当低”,但如果需要更低的功耗,则需要使用外部RTC。 使用外部实时时钟 另一方面,RTC 芯片的电流消耗因产品而异,例如,电流消耗最低的PCF2131的电流消耗为65nA 。 图 6 显示了上述微控制器/处理器在当前功耗和掉电模式下的对比。这种差异有助于延长电池寿命。 即使不需要更长的使用寿命,较小的电池也能节省空间,使设备更小,并降低成本。 图 6:维持 RTC 运行所需的流动比率(与我公司相比) 优势二:精准的时间管理 实时时钟 (RTC) 的计时基于 32.768kHz 的振荡器。振荡器频率的偏差会导致精度下降。造成精度下降的主要因素是晶体振荡器和振荡器电路的变化,以及温度的变化。 对于内置于微控制器/处理器中的实时时钟 微控制器/处理器内置的实时时钟 (RTC) 所使用的振荡频率精度通常约为 ±100 ppm。这 ±100 ppm 表示 32.768 kHz 频率的偏差量,直接对应于“时钟提前/延迟”。顺便一提,如果将这 ±100 ppm 转换为月差,则为: ±100 * 10 -6 [精度] * 60 [秒] * 60 [分钟] * 24 [小时] * 31 [天] = ±259.2 [秒] 这意味着一个月内可能会有最多四分钟的增减。 除非系统经常开启并且每次都能重新同步时间,否则可能会出现如此大的差异。 使用外部实时时钟 根据所需的精度,外部实时时钟 (RTC) 可从多种型号中选择,包括内置晶体振荡器的模块化型号和内置温度补偿电路的型号。恩智浦 (NXP) 最精确的 RTC 是PCF2131 ,它是一款内置晶体振荡器和内置温度补偿电路的模块化型号,在 -40°C 至 +85°C 的整个工作温度范围内,可保证 ±3 ppm (典型值) (月误差 ±7.8 秒)的精度 [图 7] [图 8]。 对于仅使用实时时钟芯片的产品,精度取决于所使用的外部晶体振荡器。恩智浦的实时时钟产品允许您通过软件微调时钟频率。 图 7:RTC 模块内部结构:PCF2131、PCA2131   图 8:PCF2131 RTC 模块的温度补偿。单晶单元的振荡频率特性随温度呈抛物线变化。   优势三:可靠性提高 如果外部实时时钟具有与系统电源分开的备用电源(例如纽扣电池),则可以保护时间信息免受系统复位和断电的影响,从而提高系统可靠性。 优势 4:附加功能 一些外部实时时钟 (RTC) 具有附加功能。例如,PCF2131 和 PCF85263A 等型号具有时间戳功能,可在 RTC 使用备用电源运行时记录事件。这使得 RTC 能够在主电源关闭时记录诸如设备外壳的打开和关闭等事件,从而方便现场维修和增强安全功能。 时钟输出也是一项可选功能。某些产品可以输出分频至 32.768 kHz 的时钟信号。许多具备此功能的产品允许用户将频率(分频比)设置在 32.768 kHz 到 1 Hz 之间。 中断也是一项可选功能。您可以选择每秒或每分钟生成周期性中断、设置警报,甚至为事件添加时间戳。利用这些功能,您可以创建根据需要唤醒系统的函数。 外部RTC类型 恩智浦提供种类丰富的外部实时时钟 (RTC)。您可以在恩智浦产品选择器页面找到理想的 RTC。该页面详细介绍了各种选项,包括模块或分立芯片、接口类型以及适用于汽车应用的功能。 晶体振荡器内置模块型(高精度、低功耗) 在 RTC 产品中,精度最高、功耗最低的产品是PC F 2131 (一款内置石英振荡器的模块产品)和PC A 2131 (一款具有相同功能的汽车级产品)。 两款产品的工作温度范围均为-40°C至+85°C,精度为±3ppm (典型值) ;而车规级版本具有更宽的温度范围,在85°C至105°C范围内保证精度为±8ppm (典型值) 。非车规级PCF2131在3.3V电源下功耗为65nA (典型值) ,而车规级PCA2131功耗为106nA (典型值) 。 在带有外部晶体振荡器的产品中,有PCF85063TP ,它只有最基本的功能,但也有一些产品具有各种附加功能[图 9]。 图 9:PCF85063TP 内部寄存器:由于其功能仅限于最基本功能,因此寄存器大小仅为 11 字节。其中,4 字节用于控制和状态监控,其余 7 字节提供日期、星期、小时、分钟和秒等信息。 连接方式(I²C、SPI) 微控制器和处理器之间的连接可通过I²C或SPI串行总线实现。部分产品允许用户在 I²C 和 SPI 之间切换,而其他产品则根据型号固定在其中一种模式。 无论哪种情况,微控制器/处理器都通过寄存器读取控制信息和日期/时间信息。除了串行总线之外,一些设备还具有中断信号输出,根据产品的不同,可以使用一个或两个中断输出。 汽车级兼容(符合AEC-Q100标准) 恩智浦半导体提供消费级实时时钟 (RTC) 以及通过AEC-Q100认证的车规级版本。您可以在我们的产品选择页面找到这些版本。 图 10: RTC 产品选择器页面 我们来试试吧! 图 11:支持 RTC 的 Arduino ®扩展板评估板:PCF2131-ARD、PCF85063TP-ARD、PCF85063AT-ARD 和 PCF85263ATL-ARD   恩智浦提供多种评估板,包括实时时钟(RTC)评估板,方便您立即试用每款产品。对于实时时钟,我们提供一款Arduino ®扩展板,可与各种恩智浦微控制器评估板配合使用进行评估。 此外,我们还分发了与 Arduino ® UNO 系列及其他设备兼容的开源 Arduino ®示例程序/类驱动程序。同时,我们也提供与各种微控制器兼容的 MicroPython 代码。 有关 RTC 兼容的 Arduino ®扩展板评估板的详细信息, 请参阅 本文底部附件中的 Arduino Shield Introduction Document-20250227.pdf 。 图 12:“ Arduino Shield Introduction Material-20250227.pdf ” 第 4 页 参考资料 NXP实时时钟产品门户 Arduino ® Shield 解决方案 NXP系统管理I2C、I3C、SPI选型指南 NXP社区博客:I²C总线概述 NXP社区博客:SPI总线概述 更新日志: 2025年3月3日:第一版 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便,我们深表歉意。如有任何疑问,请参阅“ NXP技术问题-如何联系我们(日语博客) ”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接询问负责人。) 不仅市面上有很多实时时钟 (RTC) 芯片可供选择,而且微控制器和处理器也内置了该功能。 在本文中,我们将解释从“什么是RTC?”到“使用外部RTC芯片而不是内部RTC有什么好处?”以及“应该如何选择它们?”等所有内容。 界面 介绍 日本博客
記事全体を表示
飞思卡尔常用脱机烧写工具 1. CycloneMAX,    支持 Kinetis, ColdFire V2/V3/V4, Power MPC5xx/8xx, Qorivva MPC5xxx, DSC, MAC7xxx    PE Micro, http://www.pemicro.com/ 2. Flasher ARM     支持ARM公司全系列内核,包括传统的ARM7, ARM9和ARM11,已经新的Cortex-A, Cortex-M和Cortex-R系列,可以给目标板供电.    Segger, SEGGER - The Embedded Experts - Flasher ARM 3. Flasher Portable    支持ARM公司全系列内核,包括传统的ARM7, ARM9和ARM11,已经新的Cortex-A, Cortex-M和Cortex-R系列,电池供电,便携式烧写器.    Segger, SEGGER - The Embedded Experts-Flaser Portable 4. SmartPRO    支持 Kinetis, S12, S12X, ColdFireV2.    周立功,http://www.zlgmcu.com/ 5. MCP-104    支持飞思卡尔ARM based Microcontroller Kinetis.    祥佑科技(Micetek), http://www.micetek.com 6. 西尔特编程器,http://www.xeltek.com 7. 河洛编程器,http://www.hilosystems.com.tw Kinetis Hardware Support
記事全体を表示
[RTD600 MCAL & IP] S32K3X4EVB - T172 FlexCAN 示例(中断/轮询) 这篇文章介绍了S32K3X4EVB-T172 评估板的两个互补的 FlexCAN 通信示例,展示了低级 IP 层和AUTOSAR MCAL 层的实现。这些示例是在正常/用户模式下配置元器件的基本例程,因为 RTD示例配置为环回模式。 要测试 CAN 通信,必须使用另一块开发板或 CAN 分析仪。 由于使用 S32K3X4EVB-T172 的 B2 修订版来测试该项目,因此将 TJA1043 收发器安装在板上并用于测试示例。 ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-T172 * MCU: S32K344 * Compiler: S32DS 3.6.2 * SDK release: RTD 6.0.0 * Debugger: PE Micro * Target: internal_FLASH ------------------------------------------------------------------------------ 示例 1:FlexCAN IP 层 (LLD) 该项目使用 IP 级驱动程序演示了基本的 FlexCAN 设置。它配置标准的 CAN 报文;通过轮询进行传输,使用中断进行接收。 如果使用TJA1153 收发器,则必须在项目顶部取消注释宏TJA1153 ,并通过自定义配置序列对其进行初始化。如果未使用且宏已被注释,则进行正常的收发器初始化(仅CAN0_EN_PIN & CAN0_STB_PIN设置为高电平)。 Rx 过滤器口罩类型是个人的,设置为接收 STD ID 123h。 Tx MB 设置为 STD ID 001h。 FlexCAN 比特率使用 MPC5xxx/S32Kxx/LPCxxxx 计算 :CAN / CAN FD 位定时计算。FlexCAN 比特率设置为500kbps, 采样点为 81.25% FPE_CLK: 24MHz 同步间隔:1 提案序号: 4 第 1 阶段:8 第二阶段:3 预分频器:3 RJW: 3 示例 2:FlexCAN MCAL 层 (HLD) 该项目可配置 Can_43_FLEXCAN 和 CanIf 模块进行 CAN 通信。传输通过轮询完成,而接收则通过中断进行配置。 Tx MB 设置为 STD ID 123h。 接受掩码设置为 0x0(接受所有 ID)。 CAN 报文通过Can_43_FLEXCAN_Write() 发送,通过 CanIf_RxIndication() 回调接收。CanIf_bRxFlag设置完成后,系统会发回一条 ACK 报文。 绿色LED 每收到 10 条信息就会切换一次。 FlexCAN 比特率使用 MPC5xxx/S32Kxx/LPCxxxx 计算 :CAN / CAN FD 位定时计算。FlexCAN 比特率设置为500kbps, 采样点为 81.25% FPE_CLK: 24MHz 同步间隔:1 提案序号: 4 第 1 阶段:8 第二阶段:3 预分频器:3 RJW: 3 如果使用TJA1153收发器,则必须使用 宏TJA1153_EVB_TRCV。否则,使用TJA1043_EVB_TRCV进行标准收发器初始化(CAN0_STB& CAN0_EN 引脚设置为高电平)。 这些示例 按原样提供 ,不提供任何保证,也不提供任何支持。这些基本例程 仅供参考。
記事全体を表示
PN7160 PN7220 Android 15 移植到 i.MX8MN EVK 简介 我们有一份官方的PN7160/PN7220 Android 15移植指南(PN7160/PN7220 – Android 15 移植指南)。但这些补丁仅适用于Android 15 AOSP r1(android-15.0.0_r1)。如果用户想移植到较新版本的AOSP,在源代码编译过程中会出现很多错误。本文件供客户参考,以便逐一解决错误。 注意:所有修改仅供参考。它们不是恩智浦官方针对 AOSP 新版本移植提供的补丁。因此,这些修改可能并非最佳解决方案。请客户根据自身需求修改 AOSP 源代码。这不是用于生产。客户仍需在移植后进行全面测试。 硬件板: i.MX8MN EVK (i.MX 8M Nano评估套件 | NXP 半导体) PN7160 EVK (OM27160 | PN7160 即插即用 NFC 控制器开发套件 | NXP 半导体) i.MX8MN EVK 与 PN7160 OM29110ARD-B 之间的连接 i.MX8M Nano EVK 引脚 PN7160 引脚 3.3v J1003-1 VDD(3.3v) J1-4 5V J1003-2 VBAT(5V) J1-5  I2C3 SDA J1003-3 SDA J2-2 I2C3 SCL J1003-5 SCL J2-1 GPIO3_22 J1003-37 IRQ J2-10 GPIO3_21 J1003-38 请求 J4-2 GND J1003-39 GND J1-6 GPIO3_20 J1003-40 VEN J4-1 为 i.MX8MN EVK 构建 Android 我使用的 i.MX Android BSP 是 Android 15.0.0_2.0.0 (L6.12.20_2.0.0 BSP),可从此处下载:用于 i.MX 应用处理器的 Android 操作系统 | NXP 半导体 1. 下载"文档"和"安装源代码包"。 2. 首先按照 Android 用户指南的步骤为 i.MX8MN EVK 构建 Android BSP。 根据 android_build/.repo/manifests/aosp-android-15.0.0_2.0.0.xml,您将看到 AOSP 版本是 android-15.0.0_r32。 移植参考文件: PN7160/PN7220 – Android 15 移植指南 在 i.MX8M Nano 开发板上将 PN7160 移植至 Android 14 现在,我们开始移植: 1. 内核驱动程序 为了与 PN7220 或 PN7160 建立连接,Android 协议栈使用 nxpnfc 内核驱动。您可以从下面的 GitHub 链接下载驱动程序: nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev ·NXP-NFC-Infra/nfcandroid_platform_d... 命令是: git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev 驱动程序适用于 Kernel 6.6 和 6.12。因此,请下载适合您移植的正确版本。例如,i.MX Android BSP Android 15.0.0_2.0.0 中的 Kernel 版本为 6.12。因此,我将使用针对 6.12 的驱动程序进行移植。 在移植过程中,请确保 Makefile 和 Kconfig 文件中的 PATH 设置正确。 例如在我的移植中: . ├── Kconfig ├── Makefile └── pn7160 ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig ├── Makefile ├── spi_drv.c └── spi_drv.h 为了简化一切,我们将只添加对 I2C 的支持,而不添加对 SPI 的支持。 用以下代码替换 drivers/nfc/pn7160/Makefile 的默认代码(便于理解) nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o drivers/nfc/Kconfig 的内容。如下添加 PN7160: source "drivers/nfc/pn7160/Kconfig" source "drivers/nfc/fdp/Kconfig" source "drivers/nfc/pn544/Kconfig" source "drivers/nfc/pn533/Kconfig" source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" endmenu drivers/nfc/Makefile 的内容。添加 PN7160,如下所示: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7160/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o 2. 将 “nxpnfc” 添加到 i.MX8MN EVK 设备树文件中。 &i2c3 { clock-frequency = <100000>; pinctrl-names = "default", "gpio"; pinctrl-0 = <&pinctrl_i2c3>; pinctrl-1 = <&pinctrl_i2c3_gpio>; scl-gpios = <&gpio5 18 GPIO_ACTIVE_HIGH>; sda-gpios = <&gpio5 19 GPIO_ACTIVE_HIGH>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio3 22 0>; nxp,nxpnfc-ven = <&gpio3 20 0>; nxp,nxpnfc-fw-dwnld = <&gpio3 21 0>; }; The GPIO settings in the IOMUXC: &iomuxc { pinctrl_nfc: nfcgrp { fsl,pins = < MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20 0X19 // VEN MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21 0X19 // FW-DWNLD MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22 0X19 // IRQ >; }; 3. 修改 imx8mn_gki.fragment 文件: android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx8mn_gki.fragment 将 "CONFIG_NXP_NFC_I2C=m" 添加到 imx8mn_gki.fragment 4. 在 Android 系统中,将这些设置添加到对应的板级配置文件中 - 转到 android_build/device/nxp/imx8m/evk_8mn/ - 修改 BoardConfig.mk。 # selinux permissive + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx8m/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc + include vendor/nxp/nfc/BoardConfigNfc.mk - 将 “nxpnfc_i2c.ko” 添加到 ShareBoardConfig.mk 中。请确保路径和文件名正确。 $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/pps/pps_core.ko \ $(KERNEL_OUT)/drivers/ptp/ptp.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/fec.ko + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko endif $(KERNEL_OUT)/drivers/trusty/trusty-core.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-log.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-ipc.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-virtio.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko else BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/input/touchscreen/goodix_ts.ko \ $(KERNEL_OUT)/drivers/input/touchscreen/synaptics_dsx/synaptics_dsx_i2c.ko Endif - 将以下内容添加到 Compatibility_matrix.xml netutils-wrapper 1.0 android.hardware.emvco 1 IEmvco default - 将以下内容添加到 device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc 2.0 INxpNfc default android.hardware.emvco 1 IEmvco default - 将以下内容添加到 evk_8mn.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx -在 init.rc 中添加 nxpnfc_i2c # Grant permission for fetching available_pages info of statsd chown system system /proc/pagetypeinfo chmod 0440 /proc/pagetypeinfo exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep on post-fs-data && property:vendor.skip.charger_not_need=0 setprop vold.post_fs_data_done 1 - 将 nxpnfc 添加到 ueventd.nxp.rc /sys/devices/virtual/thermal/thermal_zone* trip_point_0_hyst 0660 system system /sys/devices/virtual/thermal/thermal_zone* trip_point_1_hyst 0660 system system /dev/dmabuf_imx 0664 system system /sys/class/backlight/* brightness 0660 system system /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc # for libcamera /dev/media* 0660 system camera /dev/v4l-subdev* 0660 system camera 5.应用恩智浦 AOSP 补丁 由于官方 NXP NFC 补丁仅适用于 AOSP android-15.0.0_r1,而 android-15.0.0_r1 与 android-15.0.0_r32 之间存在较大差异。因此,在应用补丁之前,我先将 android-15.0.0_r1 的 NFC 文件夹复制过去,替换 android-15.0.0_r32 中的 NFC 文件夹。 首先,从 github 下载 AOSP android-15.0.0_r1。 $ mkdir android-15.0.0_r1 $ cd android-15.0.0_r1 $ repo init -u https://android.googlesource.com/platform/manifest -b android-15.0.0_r1 $ repo sync 然后,从 android-15.0.0_r32 中删除以下文件夹。然后从 android-15.0.0_r1 复制以下 NFC 文件夹,替换 android-15.0.0_r32 中的对应文件夹。 packages/apps/Nfc 框架/基础/NFC frameworks/base/nfc-extras system/nfc 例如: $ rm -rf android_build/packages/apps/Nfc $ cp -ra android-15.0.0_r1/packages/apps/Nfc android_build/packages/apps/ 我写了一个脚本来从 GitHub 下载补丁。客户可以将以下脚本放在与 android_build 相同的目录中。 AOSP_adaptation.sh # nxp_nci_hal_nfc git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_nfc.git" cd nxp_nci_hal_nfc git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/packages/apps/Nfc/ cd .. # nxp_nci_hal_libnfc-nci git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_libnfc-nci.git" cd nxp_nci_hal_libnfc-nci git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/system/nfc/ cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_15_comm_infra_dev mkdir ../android_build/vendor/nxp/frameworks cp -rf * ../android_build/vendor/nxp/frameworks cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_15_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_15_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_15_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/Nfc/ cp -rf load_unload/ ../../android_build/hardware/nxp/nfc/ cp -rf SelfTestAidl/ ../../android_build/hardware/nxp/nfc/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_15_comm_infra_dev cp -rf nfc_tda/ ../android_build/system/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/Nfc/ cd .. Apply_patches.sh cd android_build/build/bazel/ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_bazel.patch cd ../release patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_release.patch cd ../../external/libchrome patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_external_libchrome.patch cd ../../frameworks/base patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_base.patch cd ../../system/logging patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch 因此,先运行 AOSP_adaptation.sh,然后再运行 Apply_patches.sh。 6. 将更改放入 hardware/interfaces/compatibility_matrices 不同 Android 版本的兼容性矩阵不同。 文件: android_build/hardware/interfaces/compatibility_matrices/compatibility_matrix.202404.xml android.hardware.audio.effect 1-2 IFactory default + + nxp.hardware.imx_dek_extractor + 1 + + IDek_Extractor + default + + + + vendor.nxp.nxpnfc + 2.0 + + INxpNfc + default + + + + vendor.nxp.emvco + 1 + + INxpEmvco + default + + android.hardware.audio.sounddose 1-3 7. 更改设备特定的 .mk 对于 pn7160,NXP_NFC_HW 应等于 pn7160。 对于 pn7220,NXP_NFC_HW 应等于 pn7220_i2cs。 文件 : android_build/vendor/nxp/nfc/device-nfc.mk ##### ##### NXP NFC Device Configuration makefile ###### NXP_NFC_HOST := $(TARGET_PRODUCT) ifndef TARGET_NXP_NFC_HW NXP_NFC_HW := pn7160 else NXP_NFC_HW := $(TARGET_NXP_NFC_HW) endif NXP_NFC_PLATFORM := pn54x NXP_VENDOR_DIR := nxp NXP_I2CM_S := $(TARGET_NXP_I2C_M_S) 文件:android_build/vendor/nxp/emvco/device-emvco.mk NXP_VENDOR_DIR := nxp NXP_NFC_HW := $(TARGET_NXP_NFC_HW) ifeq ($(strip $(TARGET_NXP_NFC_HW)),) NXP_NFC_HW := pn7160 endif # Nfc service has dependency with EMVCo JAR PRODUCT_PACKAGES += \ com.nxp.emvco 8. 现在,你可以开始构建 Android BSP。 对于 i.MX8MN EVK, $ source build/envsetup.sh $ lunch evk_8mn-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt 在构建 BSP 时,可能会出现许多错误。我在下方列出了一些错误及参考解决方案,供客户参考。 错误 参考解决方案 报错与 nfc_aconfig_flags 相关。 packages/apps/Nfc/flags/Android.bp aconfig_declarations { // name: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig", package: "com.android.nfc.flags", container: "system", srcs: ["nfc_flags.aconfig"], } java_aconfig_library { // name: "nfc_aconfig_flags_lib", // aconfig_declarations: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig-java", aconfig_declarations: "com.android.nfc.flags-aconfig", min_sdk_version: "33", apex_available: [ "//apex_available:platform", "com.android.nfcservices", ], } java_library { name: "nfc_flags_lib", sdk_version: "system_current", min_sdk_version: "33", srcs: [ "lib/**/*.java", ], static_libs: [ "com.android.nfc.flags-aconfig-java", ], 报错与 android.hardware.nfc-V2-ndk 相关 文件: hardware/interfaces/nfc/aidl/vts/functional/Android.bp 更改 android.hardware.nfc-V2-ndk到 android.hardware.nfc-V1-ndk platform_testing/build/tasks/tests/native_test_list.mk:错误:continuous_native_tests:模块“libnfc-nci-jni-tests”的未知已安装文件 删除 'libnfc-nci-jni-tests' native_test_list.mk 错误:packages/apps/Nfc/tests/instrumentation/Android.bp:6:1:模块 "NfcNciInstrumentationTests" 变体 "android_common":无法直接依赖 java_sdk_library "android.test.runner";尝试依赖于 "android.test.runner.stubs"、"android.test.runner.stubs.system"、"android.test.runner.stubs.test"、或 "android.test.runner.impl"。 错误信息中已经给出了提示。 将 "android.test.runner" 改为 "android.test.runner.stubs"、"android.test.runner.stubs.system"、"android.test.runner.stubs.test"、或 "android.test.runner.impl" 错误:vendor/nxp/frameworks/nfc/Android.bp:12:1:模块 "com.nxp.nfc"不同版本 "android_common":依赖于 //frameworks/base/nfc:framework-nfc.impl,但该模块对当前模块不可见 你可能需要将 "//vendor/nxp/frameworks/nfc" 添加到其可见性列表中 文件:frameworks/base/nfc/Android.bp permitted_packages: [ "android.nfc", "com.android.nfc", ], impl_library_visibility: [ "//frameworks/base:__subpackages__", "//cts/hostsidetests/multidevices/nfc:__subpackages__", "//cts/tests/tests/nfc", "//vendor:__subpackages__", "//packages/apps/Nfc:__subpackages__", ], packages/apps/Nfc/nci/src/com/android/nfc/dhimpl/NativeT4tNfceeManager.java:20: error: duplicate class: com.android.nfc.dhimpl.NativeT4tNfceeManager 编辑文件 packages/apps/Nfc/nci/src/com/android/nfc/dhimpl/NativeT4tNfceeManager.java 然后注释掉重复的类。 android/R.java:12483:错误:无法解析字段 FLAG_NFC_ASSOCIATED_ROLE_SERVICES     @android.annotation.FlaggedApi(android.nfc.Flags.FLAG_NFC_ASSOCIATED_ROLE_SERVICES) 编辑 frameworks/base/nfc/java/android/nfc/flags.aconfig 添加下面的旗帜。 flag { name: "nfc_associated_role_services" is_exported: true namespace: "nfc" description: "Share wallet role routing priority with associated services" bug: "366243361" } 失败: platform_testing/build/tasks/tests/native_test_list.mk:错误:continuous_native_tests:模块 'libnfc-nci-tests' 的未知版本文件 从 native_test_list.mk 中删除 libnfc-nci-tests。 prebuilts/clang/host/linux-x86/clang-r536225/include/c++/v1/string:780:43: 错误:隐式实例化未定义模板 'std::char_traits ' 780 | static_assert((is_same<_CharT, typename traits_type::char_type>::value),       |                                           ^ packages/apps/Nfc/nci/jni/NativeNfcTda.cpp:32:35: 注意:在此处请求实例化模板类 'std::basic_string '    32 | static std::basic_string sRxTdaDataBuff;       |                                   ^ 编辑 packages/apps/Nfc/nci/jni/NativeNfcTda.cpp using android::base::StringPrintf; extern bool nfc_debug_enabled; SyncEvent sCtLibSyncEvt; //static std::basic_string sRxTdaDataBuff; static std::basic_string sRxTdaDataBuff; packages/apps/Nfc/nci/jni/NativeT4tNfcee.cpp:493:21:错误:没有与调用 'append' 匹配的成员函数   493 |       sRxDataBuffer.append(data.p_data,data.len);       |       ~~~~~~~~~~~~~~^~~~~~ 编辑packages/apps/Nfc/nci/jni/NativeT4tNfcee.cpp void NativeT4tNfcee::t4tReadComplete(tNFA_STATUS status, tNFA_RX_DATA data) { mT4tOpStatus = status; if (status == NFA_STATUS_OK) { if (data.len > 0) { sRxDataBuffer.insert(sRxDataBuffer.end(), data.p_data, data.p_data + data.len); LOG(DEBUG) << StringPrintf("%s: Read Data len new: %d ", __func__, data.len); } } SyncEventGuard g(mT4tNfcEeRWCEvent); mT4tNfcEeRWCEvent.notifyOne(); } frameworks/base/core/java/android/provider/Settings.java:2351:错误:无法解析字段FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS @FlaggedApi(android.nfc.Flags.FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS) 文件:frameworks/base/nfc/java/android/nfc/flags.aconfig 将以下内容添加到 flags.aconfig: flag { name: "nfc_action_manage_services_settings" is_exported: true namespace: "nfc" description: "Add Settings.ACTION_MANAGE_OTHER_NFC_SERVICES_SETTINGS" bug: "358129872" } 表格中未列出某些错误,因为错误信息中通常会包含相应的修正提示。客户可以根据提示操作,并结合自身需求修改源代码。 有时,客户可以比较 r1 和 r32 的源代码。这是 AOSP 的源代码 android-15.0.0_r32 和 android-15.0.0_r1。 9. 将图像下载到 i.MX8MN EVK 板 - 在 8MN EVK 板上切换到下载模式 - 首先从 Android BSP 网页下载 Android 15 BSP i.MX8MN EVK 演示镜像。因为演示图像包中已经包含了 UUU 脚本和必要的图像文件。 - 从这里下载 UUU:版本 · nxp-imx/mfgtools - 将 UUU 可执行文件放入演示镜像文件夹中。uuu_imx_android_flash.bat 脚本也在同一文件夹中。 - 构建成功后,将图像复制到演示图像文件夹中。这些图像位于 android_build/out/target/product/evk_8mn/ 目录下。 - 运行 UUU 脚本将图像下载到 EVK 板。 参考资料: 运行 Yocto Linux + PN7160 的 i.MX6ULL EVK 在 i.MX8M Nano 开发板上将 PN7160 移植至 Android 14 i.MX 应用处理器的 Android 操作系统 | NXP 半导体 PN7160/PN7220 – Android 15 移植指南 即插即用 NFC 前端集成固件 | NXP 半导体
記事全体を表示
Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Background 1. Generating a PKI tree, and include a subordinate SGK key 2. Generating an SRK Table and SRK Hash 3. Retrieve the chip information 4. Update the configuration files and generate message 5. Signing the message 6. Change lifecycle to PFR by the first method 6.1 Regenerate flash.bin with message_signed.bin 6.2 Regenerate flash-signed.bin 7. Change lifecycle to PFR by the second method 7.1 Add command in uboot-imx 7.2 Boot the board and input command Background The chip fuse has been programmed and closed(Security configuration enabled) following the process described in mx8_mx8x_secure_boot.txt in  mx8_mx8x_secure_boot.txt\guides\ahab\imx\doc - uboot-imx - i.MX U-Boot  There are two ways to change the lifecycle to Partial Field Return (PFR) by the method of a signed message. One is to generate flash.bin with message_signed.bin, another is to write a new command in uboot, then manually add message-signed.bin in uboot. The latter can change the message content more conveniently. Please note that these details/scripts are currently for NXP Internal reference. Please don’t share with customers. Based on the above, the steps for partial field return are like below:    1. Generating a PKI tree, and include a subordinate SGK key   2. Generating an SRK Table and SRK Hash $ cd ../crts/ $ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 -c SRK1_sha384_secp384r1_v3_ca_crt.pem,SRK2_sha384_secp384r1_v3_ca_crt.pem,SRK3_sha384_secp384r1_v3_ca_crt.pem,SRK4_sha384_secp384r1_v3_ca_crt.pem     The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further steps.   3. Retrieve the chip information On the iMX8/8X device, boot the device and on the SCU terminal type and run the command “seco info”. The following output will be seen on the SCU terminal. Save this info as it is needed later on.   4. Update the configuration files and generate message Modify the message_header.json {"container": {"message": {"permission": "0x10", "cert version": "0", "UID": "0C13380E82895B2C", "flags": "0", "monotonic counter": "0x0"}, "header": {"fuse version": "0", "SW version": "0", "version": "0"}}} Modify the message_content.json, from below chart, to change to partial return , the lifecycle needs to change to 0x20 {"Id": "0xa0", "lifecycle": "0x20", "nb words": "1"}   Then generate the message by the following command-line.   $python gen-msg-json.py message_header.json message_content.json -o message.bin   5. Signing the message Like below, modify the permission to Fuse1: SCU Version. Life Cycle, that is 0x10.     [Header] Target = AHAB Version = 1.0 [Install SRK] # SRK table generated by srktool File = "../crts/SRK_1_2_3_4_table.bin" # Public key certificate in PEM format Source = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # Index of the public key certificate within the SRK table (0 .. 3) Source index = 0 # Type of SRK set (NXP or OEM) Source set = OEM # bitmask of the revoked SRKs Revocations = 0x0   # ******* OPTIONAL COMMAND ***** [Install Certificate] # Public key certificate in PEM format File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" # bitmask of the permissions Permissions = 0x10 # ****************************** [Authenticate Data] # Binary to be signed generated by mkimage File = "message.bin" # Offsets = Container header  Signature block (printed out by mkimage) Offsets   = 0x0             0x48   And run the command: ../linux64/bin/cst -i message.csf -o message_signed.bin and can get message_signed.bin   6. Change lifecycle to PFR by the first method The first method is to regenerate signed flash.bin with message_signed.bin.   6.1 Regenerate flash.bin with message_signed.bin $cp the message_signed.bin to imx-mkimage/iMX8QX/ Go to the imx_mkimage repo and edit the rule flash_msg_block in ./iMX8QX/scripts/misc.mak.   -./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk test_block.bin field 0x83000000 -out flash.bin +./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk message_signed.bin field 0x83000000 -out flash.bin Then run: $ make SOC=iMX8QX flash_msg_block It will generate a new flash.bin, because the board is on OEM close state, so you need to regenerate flash-signed.bin again.   6.2 Regenerate flash-signed.bin Create the csf_boot_image_csf.csf ,like below: [Header] Target = AHAB Version = 1.0 [Install SRK] # SRK table generated by srktool File = "../crts/SRK_1_2_3_4_table.bin" # Public key certificate in PEM format Source = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # Index of the public key certificate within the SRK table (0 .. 3) Source index = 0 # Type of SRK set (NXP or OEM) Source set = OEM # bitmask of the revoked SRKs Revocations = 0x0 # ******* OPTIONAL COMMAND ***** #[Install Certificate] #Public key certificate in PEM format #File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" #bitmask of the permissions #Permissions = 0x10 # ****************************** [Authenticate Data] # Binary to be signed generated by mkimage File = "flash.bin" # Offsets = Container header  Signature block (printed out by mkimage) Offsets   = 0x400             0x590 And run the command: ../linux64/bin/cst -i csf_boot_image_csf.csf -o flash_signed.bin and can get flash_signed.bin   Finally, flash-signed.bin will generate, and dd to sd card. The lifecycle will expect to become 0x100.   7. Change lifecycle to PFR by the second method The second method is to write a new command in uboot, then add message-signed.bin in uboot manually by the command.   7.1  Add command in uboot-imx $ git am 0002-add_ahab_return_lifecycle_disable_cache.patch $ source $ unset LDFLAGS $ make -j8 Regenerate the u-boot.bin. $ cp u-boot.bin  $ cd imx-mkimage/ $ make SOC=iMX8QX flash $ cp iMX8QX/flash.bin The has the csf description file for flash-signed.bin $ cd $ ../linux64/bin/cst -i csf_boot_image.txt -o flash-signed.bin $ sudo dd if=flash-signed.bin of=/dev/sdX bs=1k seek=32 ; sync Then generate the flash-signed.bin used this new u-boot.bin.Copy message-signed.bin generated in the fifth step to sdcard. 7.2 Boot the board and input command Power up the board, and stop the uboot. $ fatload mmc 1:1 0x80280000 message_signed.bin $ ahab_status $ ahab_return_lifecycle 0x80280000 $ ahab_status Note that the address is consistent with the address that you input in the first step. Then you can input $seco info in SCU serial port, and see the lifecycle will expect to become 0x100.   Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @Tia_Lan  Can you provide the Lauterbach script to dump SECO log to Ankit? Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  It is not possible as customer performs return LC to OEM Field Return from Linux kernel sysfs driver and then power cycles device. Below are the logs customer observed when they checked ahab_status after performing return LC to OEM Field Return # dd if=signed_msg_512.bin of=/sys/kernel/seco/field_return bs=816 [ 548.708086] imx_scu_call_rpc(...) failed with error -13! [ 548.708097] imx_sc_seco_return_lifecycle(...) failed with error -13 1+0 records in 0+0 records out 0 bytes (0B) copied, 0.066212 seconds, 0B/s # cat /sys/kernel/seco/ahab_status Lifecycle: 0x0080, OEM closed UID_H: 0x1A10B00E UID_L: 0x8292379B Monotonic counter: 0x0000 SECO event[0] = 0x00A0AB29 CMD = AHAB_FIELD_RETURN_REQ (0xA0) IND = Unknown Indicator (0xAB) Found 1 SECO events SECO events found - authenticity check failed! -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Can customer run ahab_dump in uboot after they see error? We can see SECO log. Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  Customer did "signed message way". They prepared and signed "Return Lifecycle Update" message using their CST tool. On Target, through Linux console, feed "signed message" to their sysfs driver. And sysfs driver invoke SCU API : sc_seco_return_lifecycle (having  SECO_FUNC_RETURN_LIFECYCLE) function. They have not used signed image way(thus signed message is part of the boot image). -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Did they use signed message way or signed image way(thus signed message is part of the boot image)? Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  Yes, I am doing well. Hope everything OK from your side too. Customer has performed below steps: Step-1: On "i.MX8QXP B0" device having OEM Open (NXP Closed) state, first tested returning the LC to OEM Field Return execution using "signed Return Lifecycle Update message" and received the SECO event 0x00A0FA29 (AHAB_BAD_KEY_HASH_IND). This confirm that signed message is ready to use on "OEM Closed" device. Step-2: Burned the OEM SRK Hash fuses. Step-3: Flashed and booted using signed images; confirmed that no SECO events occurred during the boot process. This confirm device is in secure boot. Step-4: Advanced the LC to "OEM Closed" using their sysfs driver. Step-5: Power-cycle the board and attempted to return the LC to OEM Field Return; received SECO event 0x00A0AB29. This event indicates that the "FUSE is write/read locked". Step-6: Power-cycle the board and it was in OEM Field Return state. Do you see any issues with the above steps or have any suggestions? Please note that, we just received an update from customer that they did all the above mentiond steps on another board & seen ""FUSE is write/read locked"" error. And "Despite this, after performing power-cycle on the board, the LC successfully changed to "OEM Field Return" -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Long time no see. Hope you are doing good. I don't think it is expected. But you say the LC is changed. Somethings you might can help me check. Find all LC related fuses(I remember it is not only one), and see if customer program any bits on the same words before. I will check with STEC in next Wendsday call. please give me a reminder on Wendsday. Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang , We received a customer query regarding the return lifecycle transition to "OEM Field Return" from "OEM Closed" for "i.MX8QXP" device. The customer has implemented a sysfs driver in Linux kernel to invoke SECO APIs. Using this driver, they are able to transition the lifecycle from "NXP Closed (OEM Open)" to "OEM Closed" successfully. However, when they attempt to return the lifecycle state to "OEM Field Return", they encounter an issue and wanted some clarification. After invoking SECO API (SC_SECO_FUNC_RETURN_LIFECYCLE), they receive the following SECO event: SECO event[0] = 0x00A0AB29. This event indicates that the "FUSE is write/read locked". Despite this, after performing power-cycle on the board, the lifecycle appears to be successfully changed to "OEM Field Return". Is this behavior expected?
記事全体を表示
Building UUU custom built-in script Hello everyone, In this document I'll explain on how to build the UUU (Universal Update Utility) using windows 10 PC. This may be useful in case of adding custom commands to run during the flash using built-in scripts, be it for debugging, fuse blowing, etc. First we need to download and install Visual Studio community, for this guide I'll use community 2019, version it is available here: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16 For workloads select Universal Windows Platform development.   When installing, make sure to select and install the Git for windows complement, at the top select Individual components, this will display a new list, scroll down to code tools and you will find Git for windows, check this box In case Visual Studio is already installed, you may open the installer again and chose modify, this will let you install the complement as well. After the installation is complete we may run the git commands on the power shell. Now open the windows power shell and type the following commands: git clone https://github.com/NXPmicro/mfgtools.git // clones the MFGTool (UUU) source code from the github cd mfgtools // enters the mfgtools folder we just cloned git submodule init // creates the local configuration file for the submodules git submodule update // set the submodules to the commit specified by the main repository. At this point we can edit the built in scripts to add our custom commands, for this guide I'll add the printenv uboot command at the end of the flashing process. For this I'll enter the folder mfgtools/uuu, and edit emmc_burn_all.lst with any text editor, i.e. Notepad ++, add the command FB: ucmd printenv.   Save and close the editor, it is possible to add most uboot commands like for example the fuse commands to burn eFuses. Then we can now build the tool, opening msvc/uuu-static-link.sln with Visual studio, select solution uuu-static-link.sln   And finally build the solution: The executable (uuu.exe) would be at the following path: mfgtools\msvc\x64\Debug   Finally we run the built in script we modified and check the results. Find attached both the powershell and uboot logs, I tested this using an i.MX8MN with L5.4.47_2.2.0, running the following command: ./uuu.exe -v -b emmc_all imx-boot-imx8mnevk-sd.bin-flash_evk imx-image-full-imx8mnevk.wic Hope this may found useful for anyone trying to achieve something similar. i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX6 All Windows
記事全体を表示
AP Software Label Definition This table is intended as a reference to add clarity for selecting the correct label for your case. It is not regularly update and may not reflect all currently available products. Label Full Name Products Covered SAFETY_SW Safety Software Safety Software Framework (SAF) SCST (Structural Core Self-Test) SbSW (Safety by Software) FSS_FW Foundation Subsystem Firmware F-SS HPC_BSP LINUX_BSP PFE PFE Linux PFE MCAL PFE QNX QNX Security Layer High Performance Compute/Board Support Package PFE Software (with GMAC for Linux) CAR-V Networking QNX Crypto (QNX Security Layer) HPC OSAL (OS Abstraction Layer) Linux BSP Conti SOM Linux BSP GOLD_VIP GREEN_VIP GRAY_VIP Vehicle Integration Platform Platform integration Common VIP VIP Electrification and Dynamics VIP VNP TSN_STACK Time Sensitive Networking Stack TSN Stack AVB_STACK Audio Video Bridging Stack AVB Stack (ETH) GPTP_STACK Generic Precision Time Protocol Stack gPTP Stack TCPIP_STACK Transmission Control Protocol Internet Protocol Stack TCPIP Stack SDHC_STACK Secure Digital High Capacity Stack SDHC Stack USB_STACK Universal Serial Bus Stack USB Stack LIN_STACK Local Interconnect Network Stack LIN Stack AMMCLib Automotive Math and Motor Control Library AMMCLib ETPU Enhanced Timer Processor Unit eTPU COOLFLUX Cool Flux CoolFlux GTM Generic Timer Module GTM RTOS RealTimeHypervisor Real-Time Operating System L4RE AUTOSAR OS/NXP RTOS FreeRTOS POSIX OS IPCF EL2 Monitor RTD Real-Time Drivers Real Time Drivers/MCAL LLCE Low Latency Communication Engine LLCE IPCF Inter-Platform Communication Framework IPCF HSE_FW SECURITY_CRYPTO High Security HSE Crypto Driver S32DS S32 Design Studio S32 Design Studio IDE S32 Debugger S32 Flash Programmer S32 Trace S32_FLASH_TOOL S32 Flash Tool S32 Flash Tool S32 Flash SDK S32_CONFIG_TOOL S32 Configuration Tools S32 Config Tool PINS Tool CLOCKS Tool PERIPHERALS Tool IVT Tool EENV Tool QSPI Tool DDR Config Tool MBDT Model Based Design Tools Model-Based Design Toolbox MBDT for RADAR MBDT for VISION AUTOSAR SW-C ISELED Intelligent Smart Embedded LED Intelligent Smart Embedded LED AWS_IOT_CORE EB TRESOS LICENSES EB Tresos License topics (NO tool usage topics) AA SW - External Device SBC, PMIC, CAN TRCV, LIN TRCV, SWITCH, PHY AA SW - External Device AMMCLib AVB_STACK AWS_IOT_CORE COOLFLUX EB TRESOS LICENSES ETPU FSS_FW GOLD_VIP GPTP_STACK GRAY_VIP GREEN_VIP GTM HPC_BSP HSE_FW IPCF ISELED LIN_STACK Linux BSP LLCE MBDT PFE PFE Linux PFE MCAL PFE QNX
記事全体を表示
示例 S32K144 FlexCAN TX/RX/Error ISR 测试 S32DS2.2 本演示应用程序的目的是向您展示如何使用配置为灵活数据速率的FlexCAN模块,通过S32 SDK API进行操作。 - 在第一部分,应用程序将设置板载时钟、引脚及其他系统功能,例如SBC(如果该板将此模块用作CAN收发器)。 - 然后,它将配置FlexCAN模块的功能,例如FD、比特率和消息缓冲区 - 应用程序将等待在配置的消息缓冲区中接收帧,或等待按下两个按钮中的一个以触发事件,该事件将触发向接收方发送帧。 - 按下板1的SW3按钮将触发CAN传输,导致板2上的红色LED灯闪烁。 - 按下板1的SW2按钮将触发CAN传输,导致板2上的绿色LED灯闪烁。 - 此演示应用程序需要两块板,一块配置为主板,另一块配置为从板(请参阅应用程序代码中的MASTER/SLAVE定义) ,或使用CAN工具连接单块板。 - 事件和错误回调已安装,callback_test变量指示事件进入: bit0 .. 接收完成 bit1 .. 发送完成 bit2 .. 错误中断标志设置 bit3 .. 总线关闭中断标志设置 - 要进入总线关闭状态,只需将CANH与GND短接,并使用SW1或SW2发送消息,FlexCAN进入总线关闭状态(错误事件),蓝色LED亮起。 此外,TX MB 也已中止。移除短路连接,然后正常发送消息,蓝色LED熄灭。 ------------------------------------------------------------------------------ * 测试硬件:S32K144EVB-Q100 * MCU:FS32K1441 0N57U * 编译器:S32DS.ARM.2.2 * SDK 版本:S32SDK_S32K1xx_RTM_3.0.3 * 调试器:Lauterbach、OpenSDA * 目标:internal_FLASH
記事全体を表示
KW45/MCXW71 将时钟外设从 FRO6M 更改为其他时钟源 在现代嵌入式系统中,精确且可靠的时钟信号对于数字外设的正确运行至关重要。恩智浦的 KW45 和 MCXW71 等微控制器依赖内部振荡器为 UART、SPI、定时器和 ADC 等外设提供时序参考。其中一种振荡器是 6 MHz 自由运行振荡器(FRO6M),它通常被用作默认时钟源。 本文提供了以下内容的全面指南: 选择和配置备用时钟源 选择替代时钟源 KW45/MCXW71 微控制器提供了多种替代方案,包括 192 MHz 自由运行振荡器(FRO192)、RF_OSC 和外部晶体振荡器。每种方案都有其自身优势:FRO192 稳定且可用,而外部振荡器则能提供长期精度。时钟源的选择应基于外设的时序要求、功耗限制以及当前工作模式下时钟的可用性。 重新配置外设时钟源 使用 SDK 的时钟管理 API,在 KW45 上重新配置外设的时钟源非常简单。CLOCK_SetIpSrc() 函数允许开发人员为特定外设分配新的时钟源。 示例:将 UART 时钟源从 FRO6M 更改为其他时钟源。 UART外设连接到FRO6M uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ; CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); 例如,要将 UART 从 FRO6M 切换到 FRO-192M,可以使用以下代码: //Replace kCLOCK_Lpuart1 for your peripheral for clicking CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); 同样,在上述示例中,我们必须将 uint32_t uartClkSrcFreq 变量设置为与 FRO192M 相对应的正确频率值,因为 FRO192M 被用作时钟源,但同样的逻辑也适用于该外设的任何其他时钟源。 模块的其他时钟更改可按以下示例操作: //Change clock source for LPIT 0 module from 6M FRO to other clocksources /* Iniital source for the LPIT module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro6M); /* Set the new source for the LPIT 0 module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Lpit0, 15U); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro6M); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Tpm0, 3U); //Change clock source for Luart 1 module from 6M FRO to other clocksources CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); /* Set the source for the Lpuart 1 module */ CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); uartClkSrcFreq = CLOCK_GetIpFreq(kCLOCK_Lpuart1); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); 更改时钟源后,重新初始化外设非常重要,以确保波特率、预分频器或采样间隔等时序参数被正确重新计算。这一步骤确保外设在新时钟配置下可靠运行。 以上是一些更改部分外设时钟源的示例,但同样的逻辑可应用于任何其他模块或外设,这些示例取自 SDK 2.16.00,用以说明如何将配置了时钟源的模块切换到另一个时钟源。
記事全体を表示
S32G_M7_STBYFULLBOOT_A53STR this doc and project explain how to integrate S32G M stby demo and Linux STR demo to one demo to achieve the fast boot, chinese version: 本文说明如何在S32G2 RDB2板上搭建 一个M7 MCAL Standby Fullboot GPIO resume Demo加A53 Suspend to RAM的Demo,主要的 应用场景是电动汽车的快速启动。 G3与更新版本BSP的支持情况与此类 似,不再另外说明,客户可以自行参考开发。 请注意本文为培训和辅助文档,本文不是 官方文档的替代,请一切以官方文档为准。 目录 1 参考资料说明与声明 .................................................. 2 2 STBY+STR的硬件注意点 .......................................... 3 3 修改M7 MCAL Standby Demo代码 ............................ 5 3.1 Clock相关修改 ........................................................ 5 3.2 MCU相关修改 ......................................................... 5 3.3 UART Clock相关修改 ............................................. 7 3.4 Port相关修改 .......................................................... 7 3.5 I2C相关修改 ........................................................... 7 3.6 实现M核进入STDY状态等待功能 ........................... 8 3.7 Main函数的修改 ..................................................... 8 4 修改Bootloader工程来支持同时Boot M/A核Demo ... 10 4.1 I2C Clock相关修改 ............................................... 10 4.2 Port相关修改 ........................................................ 11 4.3 其它修改 ............................................................... 12 5 修改A53 Linux代码 .................................................. 13 6 Demo 运行测试 ........................................................ 13 6.1 硬件连接 ............................................................... 13 6.2 镜像烧写 ............................................................... 13 6.3 Demo运行 ............................................................ 14 7 工程发布包............................................................... 15 8 未来开发建议 ........................................................... 17 8.1 M/A核同步机制 ..................................................... 17 8.2 功能安全与信息安全 ............................................. 17 9 遗留问题 .................................................................. 17 9.1 IPCF STR支持 ...................................................... 18 9.2 PFE Slave STR支持 ............................................. 18 注意以下说明与声明: 说明: 汽车网关有快速启动要求,而电动车因为驻车时有更大的电池提供待机电源,所以希望是使 用Linux 的suspend to ram 的功能来实现Linux 的快速启动,而在S32G 上则需要考虑将M 核的 Standby 功能 与A 核的STR 功能 结合起来,目前可用的资源包括:  从BSP32 起支持ATF,可以支持Linux 端的STR 功能,文档《S32G_Linux_STR_V1-*.pdf》 (John.Li)说明linux STR 的原理和与M7 Standby Demo 结合时所需要的修改。  NXP 的M7 内部standby demo,可以支持M 核端的standby 功能,支持full boot 和standby ram boot。文档《S32G_Standby_Demo_V4-*.pdf》(John.Li)有详细说明,本文使用MCAL full boot+GPIO resume Demo。  本Demo 与本文主要说明如何将这两个Demo 结合起来,形成一个整体的Demo。  由于需要Boot M 核加A 核,所以也需要Bootloader 工程的支持,文档 《S32G_Bootloader_V1-*.pdf》(John.Li)说明了如何创建一个MCAL sample 加Linux 的 Bootloader 工程。 声明: 请注意:  M7 standby demo 本来为NXP 内部Demo,不保证运行质量。而Linux 本身也是reference software。  Linux STR 本身会引入比较复杂的电源管理切换,也会引起系统级的不稳定性。  本文所说的方法也是实验性质,不保证运行质量。 所以客户应该谨慎决定其产品功能并自行保证其产品质量,本文及本Demo 仅为Demo 性质。 This article explains how to build a demo of M7 MCAL Standby Fullboot GPIO resume Demo plus A53 Suspend to RAM on the S32G2 RDB2 board. The main application scenario is the quick start of electric vehicles. The support situation of G3 and the newer version of BSP is similar to this, no further explanation is given, customers can refer to it for development by themselves.  Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials and statement 2 2    STBY+STR hardware checkpoints. 3 3    Modified M7 MCAL Standby Demo codes. 5 3.1  Clock modification. 5 3.2  MCU related modification. 6 3.3  UART Clock related modificaiton. 7 3.4  Port related modification. 8 3.5  I2C related modification. 8 3.6  Enable the waiting function of M core entering STDY. 9 3.7  Main function modification. 9 4    Modify the Bootloader project to support simultaneous M/A core demo  11 4.1  I2C Clock related modification. 11 4.2  Port related modifcaiton. 11 4.3  Others modificaiton. 13 5    Modify A53 Linux codes. 14 6    Demo running and testing. 14 6.1  Hardware link. 14 6.2  Image burning. 14 6.3  Demo running. 15 7    Project release package. 16 8    Suggestion for the future development 17 8.1  M/A core sync mechanism.. 17 8.2  Function safety and Information security. 17 9    Remaining issues. 18 9.1  IPCF STR support 18 9.2  PFE Slave STR support 18 as need refer: S32G_Linux STR This doc explain S32G Linux STR details and modify to integrate with M stdy demo https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Linux-STR/ta-p/1652680 S32G Standby Demo the project build a new Mcal standby demo and explain its details https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-M-kernel-Standby-demo-and-how-to-porting-to-Mcal/ta-p/1556313 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838 Automotive Re: S32G_M7_STBYFULLBOOT_A53STR Update my issue state: Modify as following, use EB to build can success but boot failed. No console output. - bootloader >> MCU >> MCU >> General >> Config Variant => VariantPreCompile - Bootloader >> SysDal >> SysDal >> General >> SysDalGeneral 的 Enable MCU from sysdal = unchecked Hi John, Did you meet the build error?  Thanks. Re: S32G_M7_STBYFULLBOOT_A53STR Hi John, We want to open ivt tool but met some troubles: Does it look like software version mismatch? Another trouble is build failed: May I lose some steps? Thanks. Allen
記事全体を表示
工信部(中国)加强了 FRDM-KW38 和 KW36 的认证 中国的认证要求(工信部 [2002]353 号)显然计划(2022 年 12 月底)进一步加强(工信部 2021 年 1 月 27 日发布: 《关于 2400MHz、5100MHz 和 5800MHz 频段无线电管理有关事项的通知》)。 需要对 KW38 和 KW36 进行修改寄存器,以便以可接受的裕度满足新的中国要求: PA_RAMP_SEL值必须设置为0x02h (2us),而不是 0x01h (1us 默认值) 修改 SW:nxp_xcvr_common_config.c 中的 XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL( 2 ) 所有详细信息均在附件中。 注意:此 SW 修改仅适用于中国国家。 BLE软件 千瓦 KW35 | 36
記事全体を表示
示例 S32K144 FlexCAN Pretended Networking STOP 模式测试 S32DS.ARM.2.2 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** 详细说明: 本示例展示了如何使用 FlexCAN 0 的虚拟网络模式, 使 FlexCAN 模块能从 STOP 模式唤醒 MCU。  已启用超时唤醒和匹配事件唤醒功能。  此外,引脚中断也可用于退出 STOP 模式。  具体来说,按下 SW3 按钮后,MCU 将进入 STOP 模式。  当发生以下任一情况时,MCU 将退出 STOP 模式:  - 8 秒内无 CAN 消息传入(CAN PN 超时事件)  - 收到标准 ID 为 0x554 或 0x555 的消息(CAN PN 匹配事件)  - 按下 SW2 按钮(PTC12 中断)  - 在运行模式下,蓝色 LED 会进行调光,且不同唤醒事件对应的调光速率不同  ------------------------------------------------------------------------------  测试硬件:S32K144 EVB-Q100  MCU:FS32K144UAVLL 0N57U  Fsys:160MHz  调试器:Lauterbach, OpenSDA  目标:internal_FLASH ******************************************************************************** 概述
記事全体を表示
进入i.MX 8/8X系列部分场回馈生命周期的步骤 背景信息 1. 生成一个 PKI 树,并包含一个下级 SGK 密钥 2. 生成 SRK 表和 SRK 哈希 3. 获取芯片信息 4. 更新配置文件并生成消息 5. 对消息进行签名 6. 通过第一种方法将生命周期更改为PFR 6.1 使用 message_signed.bin 重新生成 flash.bin 6.2 重新生成 flash-signed.bin 7. 通过第二种方法将生命周期更改为PFR 7.1 在 uboot-imx 中添加命令 7.2 启动板并输入命令 背景信息 根据mx8_mx8x_secure_boot.txt中描述的过程,芯片熔丝已编程并关闭(启用网络安全配置) 在mx8_mx8x_secure_boot.txt\guides\ahab\imx\doc - uboot-imx - i.MX U-Boot 有两种方法可以通过签名消息的方法将生命周期更改为部分字段返回(PFR)。一种方法是使用message_signed.bin生成flash.bin,另一种方法是在uboot中编写新命令,然后手动将message_signed.bin添加到uboot中。后者可以更方便地更改消息内容。 请注意,这些细节/脚本目前仅供NXP内部参考。请不要和顾客分享。 基于上述,部分字段返回的步骤如下:   1. 生成一个PKI树,并包含一个下属SGK密钥   2. 生成 SRK 表和 SRK 哈希 $ cd ../crts/ $ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 -c SRK1_sha384_secp384r1_v3_ca_crt.pem,SRK2_sha384_secp384r1_v3_ca_crt.pem,SRK3_sha384_secp384r1_v3_ca_crt.pem,SRK4_sha384_secp384r1_v3_ca_crt.pem     SRK_1_2_3_4_table.bin和SRK_1_2_3_4_fuse.bin文件还可用于后续步骤。   3. 获取芯片信息 在iMX8/8X设备上,启动设备并在SCU终端输入并运行命令“seco info”。下列输出将显示在SCU终端上。保存此信息,以备后用。   4. 更新配置文件并生成消息 修改 message_header.json {"container": {"message": {"permission": "0x10", "cert version": "0", "UID": "0C13380E82895B2C", "flags": "0", "monotonic counter": "0x0"}, "header": {"fuse version": "0", "SW version": "0", "version": "0"}}} 从下图中修改message_content.json,要改为部分返回,生命周期需要改为0x20 {"Id": "0xa0", "lifecycle": "0x20", "nb words": "1"}   然后通过以下命令行生成消息。   $python gen-msg-json.py message_header.json message_content.json -o message.bin   5. 对消息进行签名 如下所示,将权限修改为 Fuse1:SCU 版本。生命周期,即 0x10。     [标题] 目标 = AHAB 版本 = 1.0 [安装SRK] # srktool生成SRK表格 文件 = "../crts/SRK_1_2_3_4_table.bin" # PEM格式的公钥证书 来源 = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # SRK表中公钥证书的索引(0 .. 3) 源索引 = 0 # SRK集类型(NXP或OEM) 源集 = OEM # 撤销SRK的位掩码 撤销 = 0x0   # ******* 可选命令 ***** [安装证书] # PEM格式的公钥证书 File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" # 权限的位掩码权限 = 0x10# ******************************[验证数据]# mkimage生成的待签名二进制文件文件 = "message.bin"# 偏移量 = 容器标题 签名块(由mkimage打印) 偏移量   = 0x0             0x48   然后执行命令: ../linux64/bin/cst -i message.csf -o message_signed.bin 并且可以获取message_signed.bin   6. 通过第一种方法将生命周期更改为PFR 第一种方法是使用 message_signed.bin 重新生成已签名的 flash.bin。   6.1 使用 message_signed.bin 重新生成 flash.bin $cp message_signed.bin到imx-mkimage/iMX8QX/ 转到imx_mkimage仓库并编辑./iMX8QX/scripts/misc.mak中的flash_msg_block规则。   -./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk test_block.bin field 0x83000000 -out flash.bin +./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk message_signed.bin field 0x83000000 -out flash.bin 然后运行: $ make SOC=iMX8QX flash_msg_block 它将生成新的flash.bin,因为板处于OEM关闭状态,所以需要重新生成flash-signed.bin。   6.2 重新生成 flash-signed.bin 创建 csf_boot_image_csf.csf 文件,如下所示: [标题] 目标 = AHAB 版本 = 1.0 [安装SRK] # srktool生成SRK表格 文件 = "../crts/SRK_1_2_3_4_table.bin" # PEM格式的公钥证书 来源 = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # SRK表中公钥证书的索引(0 .. 3) 源索引 = 0 # SRK集合类型(NXP或OEM) 源集合 = OEM # 已撤销SRK的位掩码 撤销 = 0x0 # ******* 可选命令 ***** #[安装证书] # PEM格式的公钥证书 # 文件 = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem"# 权限的位掩码 # 权限 = 0x10 # ****************************** [认证数据] # mkimage生成的待签名二进制文件 文件 = "flash.bin" # 偏移量 = 容器标题 签名块(由mkimage打印) 偏移量   = 0x400             0x590 然后运行命令: ../linux64/bin/cst -i csf_boot_image_csf.csf -o flash_signed.bin 即可获得flash_signed.bin   最后,将生成flash-signed.bin文件,并使用dd命令将其写入SD卡。生命周期预计将变为0x100。   7. 通过第二种方法将生命周期更改为PFR 第二种方法是在uboot中写一个新命令,然后通过该命令在uboot中手动添加message-signed.bin。   7.1 在uboot-imx中添加命令。 $ git am 0002-add_ahab_return_lifecycle_disable_cache.patch $ source $ unset LDFLAGS $ make -j8 重新生成u-boot.bin。 $ cp u-boot.bin  $ cd imx-mkimage/ $ make SOC=iMX8QX flash $ cp iMX8QX/flash.bin 包含flash-signed.bin的CSF描述文件 $ cd $ ../linux64/bin/cst -i csf_boot_image.txt -o flash-signed.bin $ sudo dd if=flash-signed.bin of=/dev/sdX bs=1k seek=32 ; sync 然后使用这个新的u-boot.bin生成flash-signed.bin。将第五步生成的message-signed.bin复制到SD卡。 7.2 启动板并输入命令 给板上电,并停止uboot。 $ fatload mmc 1:1 0x80280000 message_signed.bin $ ahab_status $ ahab_return_lifecycle 0x80280000 $ ahab_status 请注意,该地址与您在第一步中输入的地址一致。 然后您可以在SCU串口输入$seco info,看看生命周期预期会变成0x100。   Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@Tia_Lan 您能提供 Lauterbach 脚本将 SECO 日志转储到 Ankit 吗? 顺祝商祺! 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 这是不可能的,因为客户从 Linux 内核 sysfs 驱动程序将 LC 返回 OEM 现场操作,然后重启设备电源。 以下是客户在执行 OEM Field Return 返回 LC 后检查 ahab_status 时观察到的日志 # dd if=signed_msg_512.bin of=/sys/kernel/seco/field_return bs=816 [ 548.708086] imx_scu_call_rpc(...) 失败,错误 -13! [ 548.708097] imx_sc_seco_return_lifecycle(...) 失败,错误 -13 0+0 中的 1+0 条记录复制了 0 字节 (0B),0.066212 秒,0B/s # cat /sys/kernel/seco/ahab_status 生命周期:0x0080,OEM 已关闭 UID_H: 0x1A10B00E UID_L: 0x8292379B 单调性计数器:0x0000 SECO event[0] = 0x00A0AB29 CMD = AHAB_FIELD_RETURN_REQ (0xA0) IND = 未知指示符 (0xAB) 发现 1 SECO 活动 发现 SECO 事件 - 真实性检查失败! -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨,安基特、 客户看到错误后,能否在 uboot 中运行 ahab_dump?我们可以查看 SECO 日志。 顺祝商祺! 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 客户以"的方式签署了" 。 他们使用 CST 工具编写并签署了"Return Lifecycle Update" 信息。 在目标上,通过 Linux 控制台将"签名信息" 发送到其 sysfs 驱动程序。而 sysfs 驱动程序会调用 SCU API: sc_seco_return_lifecycle(具有 SECO_FUNC_RETURN_LIFECYCLE)函数。 他们没有使用签名映像方式(因此签名消息是启动映像的一部分)。 -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨,安基特、 他们使用的是签名消息方式还是签名映像方式(因此签名消息是启动映像的一部分)? 顺祝商祺! 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 是的,我做得很好。希望你那边也一切顺利。 客户已执行以下步骤: 第 1 步:在处于 OEM 开放(恩智浦关闭)状态的 " i.mx8QXP B0 " 设备上,首先测试了使用 " 签名的退货生命周期更新消息 " 将 LC 返回 OEM 现场退货 执行状态,并收到了 SECO 事件 0x 00a0fa29(AHAB_BAD_KEY_HAS_IND)。这确认签名消息已准备就绪,可以在 " OEM Closed " 设备上使用。 第 2 步:烧毁 OEM SRK 哈希熔丝。 步骤3:使用签名镜像刷新并启动;确认启动过程中未发生 SECO 事件。此确认设备处于安全启动状态。 第 4 步:使用其 sysfs 驱动程序将 LC 高级到" OEMClosed" 。 第 5 步:重启板并尝试将 LC 返回 OEM 现场退货;收到了 SECO 事件 0x00A0AB29。此事件表示 "熔丝已被写入/读取锁定"。 第 6 步:重新启动板,它处于 OEM 现场返回状态。 您认为上述步骤有问题吗? 请注意,我们刚刚收到买家的最新消息,称他们在另一块板上完成了上述所有步骤 & 看到 " " 熔丝 被写入/读取锁定 " " 错误。而且 " 尽管如此,在板上进行电源循环后,LC 成功更改为 " OEM Field Return " -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨,安基特、 好久不见。希望你一切都好。 我不认为这是意料之中的事。但你说 LC 已经改变了。你能帮我检查一下吗? 找到所有与 LC 相关的熔丝(我记得它不只一个),看看客户之前是否对同一个单词进行了编程。 我将在下周末的电话中向 STEC 询问。请在周末提醒我。 顺祝商祺! 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang、 我们收到了客户关于从 " OEM 已 关闭 " 向 " i.mx8QXP " 设备的退货生命周期过渡到 " OEM Field Return " 的询问 。 客户在 Linux 内核中实施了一个 sysfs 驱动程序,以调用SECO API。使用该驱动程序,他们能够将生命周期从 "NXP Closed (OEM Open)"成功过渡到"OEM Closed"。 但是,当他们尝试将生命周期状态返回到"OEM Field Return" 时,他们遇到了一个问题,希望得到一些澄清。 调用 SECO API(SC_SECO_FUNC_RETURN_LIFECYCLE)后,它们会收到以下 SECO 事件:SECO event[0] =0x00A0AB29。此事件表示 "熔丝已被写入/读取锁定"。 尽管如此,在板上执行电源循环后,生命周期似乎成功更改为 " OEM Field Return "。 这种行为是预料之中的吗?
記事全体を表示
HDMI Audio Setting 1. Set up HDMI 2. Test raw audio 3. Make HDMI audio the default output 4. Encoded audio 1. Set up HDMI Set up your kernel to use HDMI adding the following code to bootargs on u-boot: video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 2. Test raw audio In order to test only raw audio, use the following command: aplay -D hw:1,0 Kaleidoscope.wav 3. Make HDMI audio the default output In order to configure audio output over HDMI, please, replace content of file ~/.asoundrc to the following one pcm.dmix_48000{      type dmix      ipc_key 5678293      ipc_key_add_uid yes      slave{           pcm "hw:1,0"           period_time 0           period_size 2048           buffer_size 24576           format S16_LE           rate 48000      } } pcm.!dsnoop_44100{      type dsnoop      ipc_key 5778293      ipc_key_add_uid yes      slave{           pcm "hw:0,0"           period_time 0           period_size 2048           buffer_size 24576           format S16_LE           rate 44100      } } pcm.!dsnoop_48000{      type dsnoop      ipc_key 5778293      ipc_key_add_uid yes      slave{           pcm "hw:1,0"           period_time 0           period_size 2048           buffer_size 24576           format S16_LE           rate 48000      } } pcm.asymed{      type asym      playback.pcm "dmix_48000"      capture.pcm "dsnoop_44100" } pcm.dsp0{      type plug      slave.pcm "asymed" } pcm.!default{      type plug      route_policy "average"      slave.pcm "asymed" } ctl.mixer0{      type hw      card 0 } This will configure alsa to use sound card hw:1,0. Please, pay attention to use the proper audio card name for your device. In order to see available sound cards on board: root@imx53qsb:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx3stack [imx-3stack], device 0: SGTL5000 SGTL5000-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 card 1: imx3stackspdif [imx-3stack-spdif], device 0: IMX SPDIF mxc spdif-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 For detail on how to create asound.conf, please see alsa-lib configuration introduction. 4. Encoded audio For encoded (i.e. AC3, DTS) audio, you can use, for example, ac3dec, an utility provided by alsa-tools with the following command line: ac3dec -D hw:1,0 -C test.ac3 This would work for both HDMI audio and SPDIF audio. Double check your hardware and/or schematic in order to know which one to use. i.MX53 Multimedia Re: HDMI Audio Setting Dear Daiane Angolini, I created a new ticket through SR. Please check the below case from SR. [Case:00198948] How to configure the HDMI Audio as 24bit in i.MX6Q / Linux 3.14.52 Best Regards, Eric. Re: HDMI Audio Setting Could you, please, create a new ticket? Otherwise it might get off the radar Re: HDMI Audio Setting Dear Daiane Angolini, I want to know how to configure the HDMI Audio as 24bit in i.MX6Q / Linux 3.14.52. Please let me know how to do that. It's very helpful to me if you tell me how to confirm that in i.MX6Q Evaluation board. Actually I could confirm the below contents in the some documents. - HDMI Audio 24bit is supported in the i.MX6Q Reaference Manual   . Table 33-6. Data Arrangement in System Memory for L-PCM (24 bits) in Chapter 33   . - HDMI Audio 24bit is NOT supported in the i.MX6 Linux Reference Manual for Linux 3.14.52   . Chapter 15 On-Chip High Definition Multimedia Interface (HDMI) Driver   . Best Regards, Eric. Re: HDMI Audio Setting look for some pulseaudio conf file. Create a bbappend on your meta layer in order to add this by default on your image. (sorry, i don't know pulseaudio ) Re: HDMI Audio Setting i think the pulseaduio detect the output of audio, sometime is HDMI and sometime is the other, so i need to specify the HDMI as the default output, how to do ? Re: HDMI Audio Setting it looks like bad, i also stat up the daemon like what i said in mail list, i restart again with command "pulseaudio -D", the output of audio is not from HDMI except the "card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 []" it's really strange, help... Re: HDMI Audio Setting Well, I think you make it work (by your comment on meta-freescale) Re: HDMI Audio Setting Hi,      There is not the command "pacmd", just "pactl". BTW, i use the YOCTO project of FSL community to build all, what is my next step about for your ask ? Re: HDMI Audio Setting ohhhhhhhhhhhh you´re right! the way to configure pulseaudio is different.... From my old emails, I got this command line: pacmd set-default-sink 1 Could you, please, give it a try and let us know the results? Re: HDMI Audio Setting good, it really works if i use the native app to play audio in IMX6QSD but there is no audio output from HDMI with the pulse audio server. the output of audio just is from the "wm8962audio" as bellow in my IMX6QSD, any advices about this ? i want to use pulse audio server to output in HDMI interface. root@imx6qsabresd:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 []   Subdevices: 0/1   Subdevice #0: subdevice #0 Re: HDMI Audio Setting Hello, Very beautiful guide, how to set default SPDIF audio card on Android ? Thanks
記事全体を表示
基于 Layerscape 平台上 OpenCV 神经网络框架的 EIQ 软件应用程序 NXP 为 QorIQ Layerscape 应用处理器创建了 eIQ 机器学习软件,这是一套 ML 工具,允许在 QorIQ Layerscape 系列设备上开发和部署 ML 应用程序。 OpenCV 是一个开源计算机视觉库。它为神经网络推理(DNN模块)和标准机器学习算法(ML模块)提供了统一的解决方案。它包含许多计算机视觉功能,可以更轻松地在短时间内构建复杂的机器学习应用程序,而无需依赖其他库。 本文档介绍了基于 OpenCV DNN 框架开发的 YOLO 对象检测、图像分割、图像着色、图像分类、人体姿势估计和文本检测应用程序。
記事全体を表示
移植CMSIS-DSP库到CodeWarrior的步骤以及Kinetis FPU单元应用的对比 在电机控制,Audio等很多应用中,我们经常会用到一些常见的正余弦,矩阵变换,FFT等一些DSP函数,提到DSP库,通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准,包括针对内核操作的CMSIS-CORE API,针对DSP应用的CMSIS-DSP Library,针对RTOS的CMSIS-RTOS API,与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中,又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能,CMSIS-DSP部分提供了超过60多种功能的DSP算法库,尤其是随着Cortex-M4中集成了FPU硬件单元,CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持,然而在CodeWarrior中没有直接支持CMSIS,需要用户移植到自己的CW工程中,所以就需要使用者了解CMSIS的结构,手动添加库文件和头文件,并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元,有些不支持,在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中,FPU浮点运算单元也是一个可选的部件,只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能,如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元,整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片,编译器也设置了相应的 FPU 功能开启/关闭的选项,在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能,在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能,而芯片未开启 FPU 单元,程序运行到浮点语句时就会出现异常。相反,如果编译器未使能 FPU 功能,芯片即使开启了 FPU单元,程序还是会按照未使能 FPU 的代码进行处理。在本例程中,为对比分析是否采用FPU的编译指令差别以及在板的执行效率,选用Kinetis K70FN1M为实验对象。 硬件平台:TWR-K70F120M核心板      软件环境:CodeWarrior v10.5        CMSIS版本 :V3.2 一. 准备工作: 下载CMSIS的库,当前最新的版本为V3.2,解压后名称为CMSIS-SP-00300-r3p2-00rel1,其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中,真正用到的文件包括CMSIS\Include中CM4相关的头文件,CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点),以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元,移植CMSIS的DSP库到CW的步骤;      Step 1:    新建一个Baremental的工程,选择器件器件MK70FN1M0(支持硬件FPU);     Step 2:    选择Floating Point浮点运算实现的类型,即指定编译器将C代码编译成汇编代码时使用的规则; 在Floating Point四个选项含义如下: Software选项:表示不使用FPU硬件,而是使用GCC的整数算术运算来模拟浮点运算; Handware(-mfloat –abi=hard) 选项:表示使用FPU硬件来进行浮点运算,函数的参数直接传递到FPU的寄存器(s0-d0)中; Handware(-mfloat –abi=softfp)选项:表示使用FPU硬件来进行浮点运算,但是函数的参数传递到整数寄存器(r0-r3)中,然后再传递到FPU中; Handware(-mfloat –abi=softfp –fshort -double)选项:其配置项同上,只不过使能了fshort  double功能,并且此处的double数据的宽度等同于float; 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章,在本例程中使用的是软浮点,所以选择Software项。需要注意的是:此配置选项仅出现支持FPU硬件单元的芯片工程中,如MK60FN1M0, MK60FX512等,否则默认没有此选项,默认为软件浮点。 Step 3:    点击“Next”进入下图,选择使用Processor Expert,点击“Finish“完成工程的建立; Step 4:    进入当前工程的文件夹,新建文件夹CMSIS,从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外,拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中; Step 5:    回到CodeWarrior主界面选择新建的工程文件,F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件,包括M0+/M3/M4的一些头文件;在Lib文件中是已经编译好的库文件,ARM文件夹是使用在KEIL IDE中的库文件,G++文件夹是使用在IAR中的库文件,而由于当前CW工程使用的GCC的编译器,所以GCC文件夹才是CW需要的,因此,为缩减工程大小可以删除ARM和G++文件夹;     Step 6:    打开工程属性框,选择Target Processor的Float ABI为No FPU; Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4; Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件,路径为:工程目录\CMSIS\Include; Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU,所以选择libarm_cortexM4l_math.a,此处需要特别注意,否则编译会报错; Step 10: 在ProcessorExpert.c文件中添加代码; #include #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug,在  sinOutput = arm_sin_f32(radians);处设置断点,可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常,其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V,仅在 FPU 功能被使能时使用),完成一个正弦计算; 至此,完成了不使用K70的FPU浮点运算单元,移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元,移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元,移植CMSIS的DSP库到Codewarrior的方法有两种:一种是按照上面软浮点的方式Step By Step的建立工程,步骤和上面二的步骤基本一致,主要的两个区别在于:(1). Step 2要选择Handware(-mfloat –abi=hard) 选项,(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便,本教程采用第二种方案,完成在Codewarrior中调用CMSIS的DSP库,通过K70的FPU浮点运算单元执行浮点运算,即硬浮点。 Step 1:    打开工程属性对话框,选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard); Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义:_VFPV4; Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则,把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"; Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU,所以选择libarm_cortexM4lf_math.a,此处需要特别注意,否则编译会报错; Step 5:    完成以上配置后,编译工程并下载调试(此处建议编译之前先Clean一下整个工程),同样,在  sinOutput = arm_sin_f32(radians);处设置断点,可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常,其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V,仅在 FPU功能被使能时使用),并且在Register观察窗口中也多了个FPU寄存器列表,感兴趣的读者可以对比一下和前面实验汇编出代码的差异,此处不再赘述; 至此,分别完成了使用和不适用K70的FPU浮点运算单元情况下, CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数,在项目中直接调用即可。下一步, Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是,前文中讲到使用FPU单元需要两步设置:(1). 在编译器中开启相应的 FPU 功能选项;(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤,然而第二个步骤呢?仔细查看_arm_atart.c文件,可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程,如下图,是一个条件编译函数,这也就解释了为什么在上面Step 2中定义了_VFPV4,其本质也就是使能芯片的FPU单元,其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif Kinetis K Series MCUs
記事全体を表示
IMX8MP MIPI DSI to eDP bridge board support 1. HW Environment:     IMX8mp-evk board.     ITE6151 mipi dsi to eDP bridge board. 2. SW Environment:     IMX YOCTO 5.4.24-2.1.0 release. 3. Patch operation:     a. git clone https://source.codeaurora.org/external/imx/linux-imx.git     b. git checkout -b  imx_5.4.24_2.1.0 origin/imx_5.4.24_2.1.0     c. patch -p1 < ../ite6151_mipi2edp_linux_5.4.24_20200921.patch 4. Tested on imx8mp-evk board with DP monitor on 1080p mode: 5. Attached doc list:     IT6151 demo board user guide v1.0.pdf ------  ite6151 bridge board HW guide     it6151_qfn48_v20_20190905-01_end.pdf  ------  ite6151 bridge board SCH     imx8mp_ite6151_mipi2edp_linux_5.4.24_20200921.patch ------  Linux kernel driver patch     Image + imx8mp-evk-it6151.dtb  ------  test image and dtb i.MX 8M | i.MX 8M Mini | i.MX 8M Nano
記事全体を表示