Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
WillyFog_Milestone_2 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このマイルストーンでは、新しく実装された機能は次のもので構成されます。 - ログイン/ログアウト機能の追加 - 管理者ユーザーが新しいユーザーを追加できるようにする - ユーザーごとにデバイスを分離し、デバイスごとにコマンドを分離する - ソニーのプロトコルを使用するデバイスへのIR学習機能の追加 - デバイスが学習モードのときにLEDを点灯させる (マイビデオで視聴) Linux Embedded Challenge 2017 (英語)
查看全文
快速物联网原型开发套件_Connects China <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解如何将物联网构想转化为概念验证,就像 1-2-3 一样简单,实现互联、安全、小型化的物联网终端节点。快速物联网套件集成了 30 多个有源组件(11 个 NXP 部件)以及驱动程序、中间件、示例应用程序,并具有基于 GUI 编程的创新 Web IDE,以及移动应用程序和物联网云服务。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解如何将物联网构想转化为概念验证,就像 1-2-3 一样简单,实现互联、安全、小型化的物联网终端节点。快速物联网套件集成了 30 多个有源组件(11 个 NXP 部件)以及驱动程序、中间件、示例应用程序,并具有基于 GUI 编程的创新 Web IDE,以及移动应用程序和物联网云服务。
查看全文
i.MX RTイネーブルメントおよびリファレンスソリューション <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> i.MX RT製品は、今年の市場で最も人気のあるクロスオーバーMCU製品です。MCU製品として位置づける i.MX RTは、従来のArm MCUエコシステムを確実に再利用できます。また、本セッションでは、i.MX RTシリーズとそのターゲット市場アプリケーションの概要を説明し、既存のハードウェア/ソフトウェア/ツール/ドキュメンテーションの全体像を共有します。最後に、i.MX RTの一般的なリファレンスソリューションを紹介し、NXPがお客様をサポートして迅速なプロジェクト開発を支援する内容をよりよく理解します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> i.MX RT製品は、今年の市場で最も人気のあるクロスオーバーMCU製品です。MCU製品として位置づける i.MX RTは、従来のArm MCUエコシステムを確実に再利用できます。また、本セッションでは、i.MX RTシリーズとそのターゲット市場アプリケーションの概要を説明し、既存のハードウェア/ソフトウェア/ツール/ドキュメンテーションの全体像を共有します。最後に、i.MX RTの一般的なリファレンスソリューションを紹介し、NXPがお客様をサポートして迅速なプロジェクト開発を支援する内容をよりよく理解します。
查看全文
AMF-AUT-T2347 - 恩智浦 IVI 平台 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> IVI 市场的复杂性急剧增加,而经过几代产品的更新换代,TTM 已从 5 年缩短至 2-3 年。整个生态系统正在从封闭系统模式转向开放系统模式,从专有/闭源转向标准接口/开源组件。NXP 致力于为您提供支持,以适应这一新现实,并帮助您充分利用 NXP 在 IVI 解决方案中通常拥有的大量 BOM。通过 IVI 平台,NXP 为快速产品开发提供了坚实而完整的基础,集成了产品化和优化的 BSP 和中间件组件,并提供开箱即用的安全性。在一小时的演示中了解更多信息,包括平台功能、交付机制、路线图和可用性。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> IVI 市场的复杂性急剧增加,而经过几代产品的更新换代,TTM 已从 5 年缩短至 2-3 年。整个生态系统正在从封闭系统模式转向开放系统模式,从专有/闭源转向标准接口/开源组件。NXP 致力于为您提供支持,以适应这一新现实,并帮助您充分利用 NXP 在 IVI 解决方案中通常拥有的大量 BOM。通过 IVI 平台,NXP 为快速产品开发提供了坚实而完整的基础,集成了产品化和优化的 BSP 和中间件组件,并提供开箱即用的安全性。在一小时的演示中了解更多信息,包括平台功能、交付机制、路线图和可用性。
查看全文
USB Type-C の概要 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> USB Type-CおよびUSB-Power Deliveryとは何ですか?なぜ家電製品やモバイルコンピューティング製品がこの新しいType-Cコネクタを採用しているのですか?このコネクタを使用する利点と欠点は何ですか?USB Type-CとPowerDeliveryの未来はどうなるのでしょうか。このセクションでは、NXP(SIP)がこの新しいテクノロジーとエコシステムについて大まかに紹介します。このセクションは、市場とエコシステム主導の議論であり、技術的に激しい議論ではありません。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> USB Type-CおよびUSB-Power Deliveryとは何ですか?なぜ家電製品やモバイルコンピューティング製品がこの新しいType-Cコネクタを採用しているのですか?このコネクタを使用する利点と欠点は何ですか?USB Type-CとPowerDeliveryの未来はどうなるのでしょうか。このセクションでは、NXP(SIP)がこの新しいテクノロジーとエコシステムについて大まかに紹介します。このセクションは、市場とエコシステム主導の議論であり、技術的に激しい議論ではありません。
查看全文
DFUSec 编程 API <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 提供一个简单的编程 API,允许针对不同类型的存储器(例如 NOR 或 NAND FLASH 或基于 EEPROM 的存储器)定制开发编程算法。通过将编程算法和不同的程序映像与 DFUSec 工具混合作为不同的步骤,单个编程序列可以通过 USB 在单个 DFUSec 编程周期中对所有非易失性存储器和存储器区域进行编程!本节讲解创建新编程算法的过程。 编程算法创建过程 编程算法是在目标硬件上运行的可执行程序,并使用 LPC18xx/43xx 的 DFU 启动功能通过 DFUSec 下载到电路板。每个编程算法都有独特的代码来处理它将要编程的内存。 要创建一个新的编程算法需要以下步骤: 下载 DFUSec 编程 API 示例(此处)。这提供了调用编程 API 的 DFU 流代码、几个参考驱动程序(模拟 IRAM、内部 FLASH、SPI FLASH)和几个用于构建可执行编程算法映像的项目。这些示例需要下面附加的 LPC18xx CMSIS 库。尽管示例在 LPC18xx CMSIS 源树中构建,但生成的二进制文件应该在具有常见外围设备的 LPC43xx 设备上执行(因为它使用 M3 指令集)。 使用支持的 API 函数为新内存类型编写新的驱动程序 使用 DFU 流代码编译驱动程序,以获得二进制形式的可执行编程算法 使用 DFUSec RAW/HDR 模式选项卡,生成带有标头的二进制文件 编程 API 函数 dfusec_programming_api.h 头文件包含必须为 DFU 流代码驱动程序开发的函数原型和共享数据结构。该驱动程序需要一个全局函数来初始化非易失性存储器接口和设备,并准备定义非易失性设备内存区域和回调函数的数据结构。该结构提供了五个附加函数(通过间接调用),分别用于处理区域擦除、完全擦除、编程、验证和地址检查。并非所有这些函数都需要执行某些操作。 编程 API - algo_flash_init() 函数 需要提供的第一个函数是 algo_flash_init() 函数。此函数由 DFU 流处理器调用,用于初始化非易失性存储设备,返回 DFU 流缓冲区的指针和大小,并返回 FLASH 配置结构和回调函数。该函数的原型如下: /* 初始化设备编程能力 */ DFUPROG_REGION_T *algo_flash_init(void **buffer,int32_t *buffer_size); style="color:rgb(100, 100, 100);font-family:Arial, sans-serif;font-size:12px" 缓冲区大小必须是 64 字节的倍数(DFU 最大数据包大小) typedef struct { int32_t num_regions; /* 设备上的程序区域数量 */ /* 缓冲区应为 32 位对齐 */ 无效*缓冲区; /* 必须至少为 64 字节或 DFU 最大数据包大小,并且必须 是最大数据包大小的一个因子(1x、2x、3x 等)*/ uint32_t缓冲区大小; const PROGALGOS_T *pprogalgos; const DFUPROG_REGZONE_T *pregions; /* 地址和区域大小数组 */ } DFUPROG_REGION_T; /* 函数指针类型和函数数组 */ typedef int32_t (* progalgo_flash_erase_region) (uint32_t,uint32_t); typedef int32_t (*progalgo_flash_erase_all) (void); typedef int32_t (* progalgo_flash_write) (uint32_t,uint32_t); typedef int32_t (* progalgo_flash_verify) (uint32_t,uint32_t,uint32_t); typedef int32_t (* progalgo_verify_range) (uint32_t,uint32_t); typedef struct { progalgo_flash_erase_region 擦除区域; progalgo_flash_erase_all 擦除所有; progalgo_flash_write 写入; progalgo_flash_verify 验证; progalgo_verify_range vrange; } PROGALGOS_T; 共享 DFU Streamer 编程信息结构 /* 从 DFUSec 收到的特定步骤的编程信息 */ #定义DFUPROG_VALIDVAL 0xDB001843 typedef struct { int32_t stepnum; /* 步数,0 - 9 */ uint32_t imagesize; /* 图像大小(以字节为单位)*/ uint32_t address; /* 开始图像编程或开始擦除的地址 */ int32_t regionsize; /* 'eraseregion' 擦除区域的大小 */ int32_t erasregion; /* 擦除区域标志,如果为 !0,则擦除区域 */ int32_t erasfulldevice; /* 如果为 !0,则擦除整个设备 */ int32_t 参数;/* 可选参数值 */ uint32_tvalidatetag;/*必须是DFUPROG_VALIDVAL的值*/ } DFUSEC_PROGINFO_T; 外部 DFUSEC_PROGINFO_T dfusec_proginfo; 构建编程算法 当前可用于构建编程算法的预配置项目仅适用于 Keil uVision4 工具链。要使用您的驱动程序构建项目,请打开一个预配置的项目,并用新的驱动程序替换 DFUSec_programming_algorithm 组下的文件。单击“build”以编译并链接图像。构建周期的最终结果将是一个带有 .bin 的二进制图像扩大。 在编程算法中添加 UART 日志输出支持 LPC18xx/43xx DFUSec编程API工具 构建日期:2012年7月19日:15:03:24 初始化 USB 接口 初始化DFU 连接 USB 步数 = 0 图像大小 = 4724 地址 = 10080000 区域大小 = 00004000 擦除区域 = 0 擦除设备 = 0 验证标签 = db001843 程序周期完成 将标头附加到编程算法二进制文件 准备与 DFUSec 工具一起使用的编程算法的最后一步是将启动头附加到上一步生成的二进制文件中。DFUSec 工具无法直接启动二进制文件,需要此标头。 要生成标题,请运行 DFUSec 工具并单击 HDR/RAW 模式选项卡。对于二进制框,选择.bin要为其创建标题的文件。 然后点击“生成带头的二进制文件”按钮,生成一个新文件。将在与 .bin 相同的目录中创建一个新文件.hdr 文件扩大。 这个 .hdr文件是您的编程算法文件,应与 DFUSec 的程序模式选项卡中的 Algo 框一起使用。
查看全文
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℃までの全動作温度範囲において、動作前にクロックの安定性を確実に確保するための推奨手順はありますか?
查看全文
S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error Dear 1. The original project was developed based on S32DS3.5 + RTD5.0.0, Build OK & Run OK 2. Development requires basic RTD 6.0.0. Development environment: S32DS 3.6.2 + RTD 6.0.0 + TCPIP_STACK_3.0.0 + FreeRTOS_11.1.0_6.0.0 3. RTD5.0.0 and RTD6.0.0 have significant differences, so projects based on the original RTD5.0.0 cannot be used. Instead, refer to the example code provided in the forum ( Example: S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 ). 4. Modify the corresponding PIN according to your hardware platform as follows:          Ryan_xjl_0-1782662850043.png 5. Debugging the example code revealed that some initialization steps failed, as follows:    Ryan_xjl_1-1782662939895.png 6. If the corresponding code is masked, the program can run, but the PHY address cannot be found. The attached file contains a debug example. I'm not sure if the reference example provided on the forum has been modified, or if I only modified the PIN definition, or if there's some other configuration error. Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error Hi, Petrs Hello, you are absolutely right. I am indeed using my own hardware platform. During RTD 5.0.0 debugging, I was able to ping successfully using the example code provided on the official website. When using RTD 6.0.0 in person, I followed the same approach, mainly changing the PIN and discovering the code.The program failed to run. The attached file is based on my own hardware RTD 5.0.0 (S32DS3.5 + RTD 5.0.0 + TCPIP_STACK_2.0.0) and can ping. The example code is OK, but I'm not sure if the clock configuration is incorrect. Could you please provide some assistance? Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error Hi, It seems you only changed the MDIO/MDC pins compared to the community example you referred to. Does this mean you are using your own custom-designed board? I tested your project on the S32K388EVB-Q289, and the MCU initialization completed successfully. The PHY address was not detected because the MDIO/MDC signals are connected to different pins on the EVB. After changing the MDIO/MDC pins to PTD16/PTD17, the PHY address was correctly obtained. BR, Petr
查看全文
如何使用ADC0测量MCU的内部温度和电压 NXP支持团队的各位成员大家好。 我目前正在使用 S32K314、RTD 7.0.0 和 FreeRTOS 开发一个项目。我尝试使用 MCAL 的 ADC 模块测量连接到 MCU 的外部设备的电压、MCU 的内部温度(TEMPSENSE)、MCU 的内部电压(ANAMUX)以及带隙电压。查看测量结果,外部设备的电压和带隙电压似乎测量正确,但 MCU 的内部温度和内部电压值与预期不符。 预期值: MCU内部电压(VDD_HV_A): 8192(2.5V,14 位分辨率) 实际测量值: 约 6800–7100 (2.07–2.13V,14 位分辨率) MCU电源电压为5.0V。ADC硬件单元设置为ADC0,ADC测量目标配置如下: Ch8:MCU内部温度(TEMPSENSE) Ch9:MCU内部电压(ANAMUX) 第十章:带隙 ADC Setting00.png ADC Setting01.png ADC Setting02.png MCU输入电压 = 5.0V ADC Setting03.png ADC Setting04.png ADC初始化代码: void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADC数据采集(所有周期性任务) void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } } 我认为可以使用 `Adc_ReadGroup` 更新 ADC0 组的 ADC 值,但需要使用 `Adc_TempSenseGetTemp` 和 `Adc_TempSenseCalculateTemp` 来检查 MCU 的内部温度。如果我遗漏了任何设置,请告知。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 森伦特先生,您好! 感谢您的快速回复。 我已经审阅了您提供的示例代码,并且相信我已经将其融入到我的代码中。 我把您提供的表格理解为提供给 ADC 模块的每个时钟的寄存器设置表。但是,我无法确定它们对应于 MCAL 中的哪个 ADC 设置。 由于我无法提供源代码,因此我附上了一张ADC设置的图片。请告诉我应该更改哪些设置。 如果您还需要其他设置界面,请告诉我。 1_ADC_ConfigTimeSupport.png AdcHwUnit> 2_ADC Config_AdcHwUnit.png 3_ADC General.png 4_ADC0 HwConfiguration.png 6_ADC AutosarExt.png Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 嗨@辉彦 我没有从您提供的信息中看到完整的ADC配置,所以请您仔细检查ADC时钟是否符合数据手册的要求。 如果可以的话,你可以把你的测试项目分享给我,我会帮你检查一下。 Senlent_0-1782458295032.png 对了,可以看看下面链接里的演示: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 森伦特先生,您好! 谢谢你的建议。 根据您的建议,我更改了设置,如下所示,将 TEMPSENSE 采样时间设置为 1.2 微秒。 ADC Setting10.png 160MHz = 0.00625微秒 1.2微秒/0.00625微秒= 192 ADC Setting11.png 我在 FreeRTOS 中创建了一个周期为 1 秒的任务,每秒获取一次 MCU 电压 (VDD_HV_A) 和 MCU 温度 (TEMPSENSE) 的 ADC 值(收集 30 秒的数据)。 ADC Setting13.png 对于 MCU 电压,我使用了带隙电压,并使用以下补偿公式将其转换为 mV。 (带隙电压几乎没有波动,测得的值约为 3975(约 1.2 V)。) Adc校正 = (1200(mV) * Adc_VCC_HV_A) / Adc_带隙 MCU电压= Adc校正 * 2(2为VDD_HV_A的分压比) ADC Setting12.png 此外, McuTemp数据来自 `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)`。 即使考虑到 +/- 5.0% 的 ADC 转换误差,我认为这种变化也太大了。有什么建议的解决方案吗?   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 嗨@辉彦 从你提供的配置截图和代码来看,我没有发现任何明显的错误。但是需要注意的是,温度传感器的采样时间必须大于 1.2µs;否则,会影响采样精度。因此,我建议您在测试前仔细核对采样时间。 Senlent_0-1782377529947.png Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 ADC_Config>AdcHwUnit 的图像被压缩,导致分辨率降低,因此我重新上传了它。 <#1> 2_ADC Config_AdcHwUnit_1.png <#2> 2_ADC Config_AdcHwUnit_2.png <#3> 2_ADC Config_AdcHwUnit_3.png Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 嗨@辉彦 您可以直接读取温度通道的原始数据,观察是否存在波动。如果波动较大,您可以继续尝试增加采样时间。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 森伦特先生,您好! 我对表 317 中的信息作了如下解释。 当 fmc = 160 MHz 时: ・将校准预分频器设置为4 ・将普通ADC转换的预分频器设置为2 ・将“ADC 高速”设置为“禁用” 7_ADCConfig_AdcHwUnit.png 应用这些设置后获得的数据如下表所示。 虽然平均值降低了波动,但我感觉 MCU 内部温度的波动仍然相当显著。 8_ADCConfig_AdcHwUnit.png 下表显示了从 ADC 值转换为 °C 的 MCU 温度数据。 (为了将ADC值转换为摄氏度,我将ADC值除以16。) 9_ADCConfig_AdcHwUnit.png 16 个点平均值出现 2.55 度的变化是极其大的。我知道MCU温度会根据处理负载而波动,但是温度瞬间变化这么大正常吗? 测量MCU内部温度时,取平均值是否是正确的方法? Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 森伦特先生,您好! 感谢您附上文档。由于我目前正在测量通道 32-63,我知道这对应于采样持续时间 1。 感谢您的及时回复。问题已解决。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 森伦特先生,您好! 谢谢你的回复。 如下图所示,在我增加采样持续时间 1/持续时间 2 的值后,这些值趋于稳定。我以为默认设置是采样持续时间 0,但是如何才能在采样持续时间 0、1 和 2 之间切换呢? 10_ADCConfig_AdcHwUnit.png (根据预分频设置,由于 ADC 时钟频率为 80 MHz,因此 1.2 μs 对应的持续时间为 96。)
查看全文
关于 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,彼得
查看全文
[S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Hi everyone, I am seeking advice regarding an issue where the HSE Firmware initialization fails to complete on an S32K324 custom board. 1. Development Environment MCU: S32K324 (Custom Board) HSE FW: s32k3x4_hse_fw_1.5.0_2.55.0_pb250130.bin.pink Debugger: S32DS + T32 (Trace32) 2. Progress and Status Registers Successfully programmed the HSE FW Usage Flag in the UTEST region (0x1B000000). Downloaded the Pink Image binary into flash memory. After performing a Power-On Reset (POR), the status registers are as follows: 0x4039C028 (HSE GPR): 0x01 (Installation confirmed) 0x4038C107 (HSE_STATUS_INIT_OK): 0x00 (Halted during boot) 3. Questions I would like to ask the experts the following: What is the very first thing I should check? Since the installation succeeded but initialization failed, are there any specific registers (e.g., Fault status) I should dump or hardware signals to inspect to pinpoint the exact cause? Can the Custom Board environment affect the initialization failure? Since I am using a custom board, I suspect hardware differences (e.g., initial XTAL frequency) or the early clock (PLL) configuration code of the main core (M7) might be interfering with the HSE boot sequence. If this is a known issue, could you guide me on the recommended boot sequence (e.g., polling the INIT_OK flag before any clock setup) or potential solutions? Any clues would be a great help. Thank you in advance for your support! Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Hi there, Thank you so much for the clear guidance. First, I proceeded with the firmware installation using the demo app, and then dumped the MU and HSE GPR register values while in the system.up state. Please let me know if any of these register addresses are incorrect. The results are as follows: 1. MU0 Registers (Base Address: 0x4038C000) 화면 캡처 2026-06-25 094427.png 화면 캡처 2026-06-25 095601.png 화면 캡처 2026-06-25 095727.png   화면 캡처 2026-06-25 095747.png   2. HSE GPR Registers (Base Address: 0x4039C000) 화면 캡처 2026-06-25 094944.png   Could you please review these values? I would highly appreciate your expert opinion on whether these indicate a specific error cause, such as a clock configuration conflict or a firmware authentication failure. Thank you again for your time and support! Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Could you provide following information? MU registers, FSR, GSR, etc: HSE GPR3: Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Thanks. But I would need to see this screenshot when HSE core is in WFI state, not directly after reset.
查看全文
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のボードの使い方に関するドキュメントを参照できるかもしれません。
查看全文
LA9310 LLCP 外部接口信号描述和交流时序表 尝试将 ADRV9002 与 LA9310 连接。需要LA9310 LLCP外部接口信号描述和交流时序表, LA9310 材料提供的细节不足以绘制地图: LLCP车道数 精确的序列字格式 I/Q 位排序 ADC/DAC 采样是原始数据流还是封装的交易 或者 我们可以绕过或关闭ADC和DAC的电源吗? 或者 如何配置与 ADRV9002 兼容的 SSI LVDS 接口的 LA9310? Re: LA9310 LLCP external interface signal description and AC timing table, 你好, 不, 现有的 LA9310 文档 没有 提供 足够的 信息 , 无法 将 ADRV9002 SSI/LVDS 直接 映射 到 LA9310 LLCP 接口 。LA9310 文档 定义 了 LLCP 引脚、 链路 样式、 事务 类型 和 电气 /时序 特性 , 并且 还 表明 内部 ADC / DAC 可以 置于 低 电源 模式 。但 我 找不到 指定 LLCP 详细 信息 的 文档 , 满足 ADRV9002 互操作性 设计 所需 的 级别 , 每个 超过 单个 data+strobe 对 方向 通道数 、 I/Q 流 的 精确 端到端 串行 采样 字 格式 、 LLCP 引脚 上 明确的 I/Q 位 顺序 , 或者 任何 关于 LLCP 与 SSI 兼容的 声明。 此致 Re: LA9310 LLCP external interface signal description and AC timing table, 谢谢, 此外,如果您能推荐任何适用于 240 至 360MHz 频率的兼容零中频或近零中频射频集成电路 (RFIC),那就更好了。我正在研究 LMS7002,但如果没有 TSP,它的用途就大大减少了。或者,如果您建议不使用 TSP,那么我可以使用 LA9310 吗? 使用 LMS7002 内部 TSP 通常可以获得: 数字升频/降频 插值/抽取滤波 智商矫正 直流偏移校正 一些增益控制功能 数字频率偏移 数字波形整形 或 我发现,如果像上面提到的那样,其他功能也可以集成到 LA9310 中,那么 CMX998 可以实现 BPSK/QPSK/8PSK,适用于 5KHz 和 25KHz 等低带宽信道,收发数据速率仅为 2.4 KB/s 至 64KB/s。
查看全文
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.
查看全文
S32G274A 实现SHA256+RSA2048算法 NXPサポートチームの皆様、こんにちは。 現在、S32G274Aプラットフォーム上でHSEの評価を行っており、推奨される実装方法についてご助言いただければ幸いです。 現在の環境: * デバイス: S32G274A * コア:Cortex-M7 * IDE: S32 Design Studio 3.6 * HSEパッケージ: HSE_DEMOAPP_S32G2XX_0_1_0_16 * HSEファームウェア:HSE_FW_S32G2XX_0_1_0_16 現在の進捗状況: * 私はAN14070(「S32G2のCortex-M7コアでHSEデモアプリケーションを実行する方法」)に従っています。 * HSEデモプロジェクトは正常にインポートおよびコンパイルできます。 * ただし、IVTビューを開く際に、S32DSは例外を報告し、IVTビューを作成できません。 com.nxp.swtools.ivt.views.IVTView (必要であれば、エラーログ全体を提供できます。) プロジェクトの目的: 現在、当社のブートローダーはソフトウェアベースのセキュアブートを実装しています。 1. アプリケーションイメージのSHA-256を計算します。 2. フラッシュメモリに保存されている公開鍵を使用して、RSA-2048署名を検証します。 3. 検証が成功した場合のみ、アプリケーションを起動します。 この実装をCortex-M7上のHSEベースのサービスに移行したいと考えています。 質問: 1. AN14070は、S32DS 3.6を搭載したS32G274AのHSE評価における推奨される出発点として、依然として有効ですか? 2. IVT Viewは、以下のようなHSEサービスの評価に必須ですか? * SHA-256 * AES * RSA署名検証 それとも、ブロブイメージの生成とHSEファームウェアのインストールにのみ必要なのでしょうか? 3. HSEファームウェアのインストール後、以下の内容を示す参考例はありますか? * HSEによるSHA-256計算 * HSEによるRSA-2048署名検証 * HSEキーカタログへの公開鍵のインポート 4. Cortex-M7上でソフトウェアベースのセキュアブート実装をHSEサービスに移行する方法を示すアプリケーションノート、トレーニング・マテリアル、またはデモプロジェクトはありますか? 5. アプリケーションにジャンプする前にSHA-256 + RSA2048検証を実行するブートローダーの場合、HSEを使用した推奨移行パスは何ですか? 何かご助言、参考となるプロジェクト、または推奨ドキュメントがあれば大変ありがたいです。 よろしくお願いいたします。 Re: S32G274A 实现SHA256+RSA2048算法 私は3を照合します。次の図に示すIVTViewには、DCD、HSE、アプリケーションブートローダー、ブートの各ブロックが表示されます。 BLOB イメージの生成に関連する構成と自動位置合わせ 我的 S32 Design Studio for S32 Platform 3.6.0打不开IVTビューエラー:ビューを作成できませんでした:com.nxp.swtools.ivt.views.IVTView java.lang.Exception at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:115) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:101) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:304) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(ネイティブ方法) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.方法.invoke(方法.java:568) org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:976) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:938) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:138) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:385) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:311) で発生 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 お問い合わせいただきありがとうございます。 AN14070はCortex-M7の評価における有効な出発点であり続けるが、HSEデモアプリパッケージおよびHSEファームウェアのリファレンスドキュメントと併用することを推奨する。テスト中に発生したエラーの詳細情報を私と共有していただけますか? S32Gへのセキュアブートの適用については、以下の内容を参考にしてください。 S32G_Secure_bootの中国語/英語バージョン。 現時点では、お客様のご要望に直接合致する特定の文書はございません。確認のお手伝いをするために、内部チャネルをご案内します。結果が出たらご連絡します。 BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 ご返信よろしくお願いします。 この問題はS32DSのバージョンに関連しているはずです。HSE_DEMOAPP_S32G2XX_0_1_0_16_ReadMe.pdf を参照してください。推奨バージョンのご利用をお試しください。 Joey_z_0-1781602323864.png BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 ブロブの作成と書き込みは完了しましたが、シリアルポートに印刷情報が表示されず、Trace32でも読み込めません。どこからトラブルシューティングを始めればよいでしょうか?できるだけ早く確認していただけると助かります。 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 1. AN14070に基づいて、ブロブが作成され、フラッシュされます。その後、QSPI経由でブートしてHSEファームウェアをロードし、M7_0を起動します。QSPIブート後、Trace32を使用してM7_0に接続し、SRAMの内容を確認して、アプリケーションが正しいアドレスにロードされているかどうかを確認できます。 2. アプリケーションが正常に起動した後でのみ、HSE デモの .elf ファイルをロードしてください。次に、プロセスの次のステップであるSRAMへの移行に進みます。 BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 あなたの回答は私の期待を裏切ります。以下に示すように、現在は正常に情報を印刷できます。 HSE FW バージョン: 0.1.0_1.0.9 HSE FW 画像: ピンク HSE FWが稼働開始しました!状態: HSE_STATUS_RNG_INIT_OK HSE_STATUS_INIT_OK HSE_STATUS_CUST_SUPER_USER プログラムはここで停止し、先に進めませんでした。`DEBUG_LOOP(gZero);` をコメントアウトしたところ、`HSE_Config();` で停止していることがわかりました。/* プライマリイメージのバックアップ */ ASSERT(FLASH_OP_OK == Flash_WriteData_FromFlash(IVT.pSysImage_bck,コード`ITV.pSysImage, MAX_SYS_IMG_SIZE)`がここで停止します。`HSE_Aes_Example`などの後続コードも実行に失敗します。 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 お客様からのご質問は弊社のサポートシステムにて受け付けております。ご依頼内容には複数の問題が含まれており、社内の専門家が既にサポートと回答を開始しております。 BR ジョーイ
查看全文