J-Link 调试器无法连接到自定义 S32K144 目标板 大家好 我在将 SEGGER J-Link 调试器连接到基于恩智浦 S32K144 MCU 的定制板时遇到了问题，如果有任何指导，我将不胜感激。 设置详情： MCU：恩智浦 S32K144 板：定制设计的 PCB 调试接口：SWD 调试器：SEGGER J-Link (jlink pro & jlink ce) IDE/工具链：(S32 Design Studio) 主机操作系统：(Windows) 错误消息附带供你参考 Re: J-Link debugger not connecting to custom S32K144 target board 嗨，@srinivasaraomannem、 我知道您在 CONNECT 命令中选择了 SWD，但由于连接尝试失败，调试器自动退回到 JTAG，同样也失败了。 这种行为强烈表明是硬件层面的问题。 请在您的板上验证以下内容： 完整的 SWD/JTAG 信号链，包括引脚布线、连续性和信号完整性 RESET_b 电路 S32K144 的所有相关电源轨。 如果你愿意，我可以查看你的板的示意图。 您可以通过支持票据私下共享原理图，我会对其进行详细检查。 https://support.nxp.com/s/?language=en_US 此致， 丹尼尔

S32K344 的主要产品目录 你好，我正在基本安全启动中进行加密测试。附上 main.c文件 此时 rsp = HSE_ECC_ComputeSecretAndSetAes(peerPubKey); if (rsp != HSE_SRV_RSP_OK) while (1)； 进入 while (1)，因为 rsp 有错误代码0x55A5A399 也许问题出在我如何格式化关键目录上 Re: Key Catalogs in S32K344 你好@silvia_zandoli2 我在你的代码中看不到 HSE_ECC_ComputeSecretAndSetAes 函数。而 HSE 框架中并没有这种功能。 此致， Lukas Re: Key Catalogs in S32K344 你好，这个函数是我自己定义的。 我报告了定义。函数代码见附件。谢谢 HSE_ECC_ComputeSecretAndSetAes函数负责协调安全密钥交换协议。它首先将外部对等公开密钥导入 HSE 安全存储器。随后，它会触发信号 ECDH（椭圆曲线 Diffie-Hellman）算法，使用设备的内部私钥计算共享密钥。最后，它从该密钥中提取出可用的 128 位 AES 会话密钥，并将其锁定在 HSE 内，以确保数据加密和解密的安全性。

S32K312，VKMS，指定 Csm_KeyElementGet 的输出参数 你好，CRT 小组： 原始票据是VKMS-HSE-Specify-the-output-parameters of-Csm-KeyElementGet 顾客延锋 项目大众汽车项目 我们的客户延锋在其项目中使用了 VKMS HSE FW + S32K312。 在大众汽车公司进行的 VKMS 功能测试中，有一项测试结果与理论值不符。根据当地团队和客户的初步评估，问题似乎与 Csm_KeyElementGet() 的输出参数有关。   在 RTD 400P21 的 VKMS 演示中也出现了类似的现象，如下图所示。         客户目前的问题是   执行 Csm_KeyElementGet(CsmConf_CsmKey_CsmKey_0xF0010002, 0xF0010002U, Vkms_au8Response, &Vkms_u32ResponseLength ); 获得训练计数器后，为什么 Vkms_u32ResponseLength 的返回值 = 3？   根据客户的描述，理论上这个返回值应该如下： 如果需要一个密钥的元数据：5 如果需要所有密钥的元数据：1+ * 6 您能帮忙检查一下吗？ 顺祝商祺！ 郑林 板：S32K312 元器件：HSE 固件 元器件：网络安全 优先级：中等 SW 变体：定制 类型问题 Re: S32K312, VKMS, Specify the output parameters of Csm_KeyElementGet Hi Cuong、 请参见以下信息： - S32K3 RTD 版本： RTD 4.0.0 P21 - 平台： S32K312 - HSE FW 版本： 9.2.26.0 - 加密配置文件： 如票据中所述，使用 RTD 的 VKMS 演示项目进行测试 - CsmKey_0xF0010002 中存储了什么？ 理论值是多少？ 如票中所述，使用 VKMS 演示项目 RTD 进行测试，CTM 希望明确 RTD 演示的结果。 顺祝商祺！ 郑林 Re: S32K312, VKMS, Specify the output parameters of Csm_KeyElementGet 您好@ZhengLin ，能否详细说明客户环境信息： - S32K3 RTD 版本 - HSE FW 版本 - 加密配置文件 - CsmKey_0xF0010002 中存储了什么，预期 理论值是多少 ？ Re: S32K312, VKMS, Specify the output parameters of Csm_KeyElementGet Hi Cuong、 这个案件有什么新进展吗？ 顺祝商祺！ 郑林 Re: S32K312, VKMS, Specify the output parameters of Csm_KeyElementGet Hi Cuong、 客户从奥迪提供的文件中获得了以下理论信息，这些信息无法与我们共享，但如果需要，我们可以安排与客户在线会面。 顺祝商祺！ 郑林

S32Z270 – リセット時のRTU0クロック周波数 こんにちは、皆さん。 私は NXP S32Z270 を使用していますが、リセット時の RTU0 クロック周波数を確認し、Lauterbach デバッガーとの接続時に発生する MC_CGM アクセスの問題を明確にしたいと思います。 時計に関する質問 アプリケーション レベルのクロック初期化が実行される前に、リセット直後に RTU0 がどのクロック ソースと周波数で実行されているかを確認してください。RCONは0x30481804です MC_CGM アクセスの問題 次のような動作を観察しています。 TRACE32 経由で RTU0 に接続する場合: RTU0.MC_CGMを読み取れません RTU1.MC_CGMを読み取ることができます RTU1に接続すると: CANでRTU0.MC_CGMを読み取ることができます RTU1.MC_CGMを読み取れません これは直感に反するように思えます。RTU0 はコネクテッドの場合、常に独自の MC_CGM ブロックにアクセスできるはずです。RTU0 が RTU0.MC_CGM にアクセスするのを防ぐことができるクロック、リセット、または保護メカニズムはありますか? よろしくお願いいたします！ Re: S32Z270 – RTU0 clock frequency at reset こんにちは@danieljcoliveira 、 お問い合わせいただきありがとうございます。より良いコミュニケーションのためには、一度に 1 つの質問に集中するほうがよいでしょう。リセット時のクロック周波数、およびリセット時のあらゆる構成に関するマターについては、リファレンス・マニュアルに添付されている Excel シート S32Z2_boot_settings.xlsx を確認してください。 文書を確認して、必要な情報が見つかった場合はお知らせください。 よろしくお願いします。 Re: S32Z270 – RTU0 clock frequency at reset ファイルを見ると、私の構成では RTU0 周波数は 48MHz であると推測されます。 理由: S32Z2_boot_settings.xlsx ファイルを見ると、重要な依存関係の1つが NO_PLL_BOOT_ENABLE 設定であることがわかります。前述の通り、私の RCON 設定は 0x30481804 なので、NO_PLL_BOOT_ENABLE=0 となります。 ソースPLL FIRC 参照クロック （MHz） VCO （MHz） フィ0 ファイ1 ファイ2 ファイ3 ファイ4 ファイ5 ファイ6 DFS0 DFS1 DFS2 DFS3 DFS4 DFS5 コア 51 2400 0 N.A. N.A. N.A. N.A. N.A. N.A. 0 400 0 0 400 0 そのため、BootROM クロッキングの PLL DFS 周波数テーブルに従うと、PHI0 および DFS0 出力は 0 となり、FIRC クロックが RTU0 の唯一のクロック ソースになります。この分析は正しいですか@alejandro_e ?これは投稿を作成する前の私の最初の直感でしたが、依存関係が欠けている可能性があると疑っていました。 Re: S32Z270 – RTU0 clock frequency at reset こんにちは@danieljcoliveira 、 はい、その通りです。FIRC はすべてのコアの想定クロック ソースです。ページ上部の注記にもそのことが記載されています。 「BootROM は、FIRC をクロック ソースとしてコア PLL とペリフェラル PLL をロックします...」 「モジュール クロッキング状態」シートでは次のようになります。 モジュール リセット解除時のデフォルトのクロック状態 BootROM実行中 BootROMパス制御 備考 HSE FW - セキュアブートの場合 (BOOT_SEQ=1) アプリケーション - 非セキュアブートの場合 (BOOT_SEQ=0) R52-RTU-0/SMU-M33 ディセーブルされる イネーブルされない イネーブルされない FIRC アプリケーションコアは常にFIRCクロックで有効です FIRC の許容範囲については、「BootROM Clocking」シートの上部にある完全な注意事項を確認してください。 MC_CGM 読み取り時の問題について。以下の情報をご提供ください。 私たちの例の 1 つを実行して MC_CGM を読み取ろうとしましたか?それとも自分のアプリケーションだけで試しましたか? CANで読み取りを行う際に使用している具体的な手順を説明していただけますか?どのようなエラー/問題が発生しているのでしょうか? よろしくお願いします。

s32k312 hse ab-swap 再起動方法? こんにちは、NXPの専門家さん。 1.私は hse バージョン 1.13.0、2.40.0 で s32k312 を使用しています。 2.OTA機能を実装しています。OTA が終了したら、hse を呼び出して AB を交換し、再起動して新しいアプリを実行する必要があります。 私の問題は、デモを書いて、「 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK 」サービスを呼び出すことです。パラメータを指定せずに、「IP_MC_ME」周辺機器を使用して MCU を再起動すると、1 回しか機能せず、その後は MCU が実行できなくなります。おそらく、何らかのハードウェア障害が原因です。 その後、リセットピンで再起動しても問題ありません。 私の再起動コードは次のとおりです: ネタバレ （ハイライトして読む）     IP_MC_ME -> MODE_CONF = MC_ME_MODE_CONF_FUNC_RST ( 1 );     IP_MC_ME -> MODE_UPD = MC_ME_MODE_UPD_MODE_UPD ( 1 );     IP_MC_ME -> CTL_KEY = MC_ME_CTL_KEY_KEY ( 0x5AF0 );     IP_MC_ME -> CTL_KEY = MC_ME_CTL_KEY_KEY ( 0xA50F ); IP_MC_ME->MODE_CONF = MC_ME_MODE_CONF_FUNC_RST(1); IP_MC_ME->MODE_UPD = MC_ME_MODE_UPD_MODE_UPD(1); IP_MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY(0x5AF0); IP_MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY(0xA50F); この再起動コードは大丈夫ですか、それとも他の方法で MCU を再起動して AB スワップ機能を作成し、新しいアプリを実行する必要がありますか? ありがとうございます。 Re: s32k312 hse ab-swap reboot method? 原則的には正しいですが、次のデモ例を確認してください。詳細な手順をCANします。 まず、すべての手順を詳しく説明するデモ プロジェクトを含むセキュア ブート アプリケーション ノートを提供します。以下からCANをダウンロードできます。 https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-auto-general-purpose-mcus/s32k3-microcontrollers-for-automotive-general-purpose:S32K3 アプリケーションノートはここにあります: ドキュメント -> セキュア ファイル -> セキュア ブート アプリケーション ノート v0.1.1.0（AN744511） 関連するデモ プロジェクトはここからダウンロードCAN。 設計リソース -> ソフトウェア -> セキュア ファイル -> SecureBootAppNoteDemo (SW745310)

In the design of GUIder v1.8.0, there is an inconsistency between the interface design, the simulator display and the actual control display position of the microcontroller In the design found to appear in the middle of the large font simulator display effect will be adjusted downward, microcontroller display will be adjusted upward using the font is their own imported bansnschrift, in fact, the text controls are the existence of positional deviation   Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 Any results, please? I've been having this problem a lot.I don't know what to do with it. Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 hi, @Harry_Zhang I have uploaded the file to the attachment as you provided. The details of the problem and where I think the problem occurs are mentioned in the previous reply: problem reproduction and causes. If you have a solution, please kindly contact me! Looking forward to your reply! Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 Hello @Harry_Zhang How should I share my project with you Actually I have almost pinpointed where the problem is The inconsistency between the effect on the microcontroller and the simulator is my problem The inconsistency between the simulator and the interface design is due to the problem with the baseline offset in the generated font file, which is different from that of the interface design but I don't know how to correct the situation from my side If you can, could you please provide me with an email address, I will copy the project for you to reproduce and add some notes. I look forward to your reply! How to reproduce it: Add the border of the label and make the font as big as possible, so that you can see the y-axis offset of the font in the label box. Possible reasons for this problem: The font position offsets during interface design are different from the emulator font offsets and may appear in this font file Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 Hi @陈宇  Can you share your project? I want to reproduce this issue. BR Harry Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 I use the official built-in Song test and this problem also occurs, the white places are where I use the container to mark the positional relationship between the controls Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 I found that this happens when I use my own added font file ttf This does not happen when I use the official built-in font files: plain English and numeric The problem is localized to the font file that I added in? But I added the official ttf file, and I don't know how to solve the problem of inconsistency between the design effect, the simulator effect and the actual display effect of the microcontroller. If you have a solution for this problem, please provide it to me. Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 Hi @xiaohuihui We'll address this in a future version. If you need a large font size, it is recommended to adjust the offset according to the actual screen display to ensure that the final screen can be displayed properly. BR Harry. Re: 在GUIder v1.8.0设计中，出现界面设计、模拟器显示和单片机实际控件显示位置不一致的问题 There is no solution at the moment I don't know if there is an official update I'm currently looking at the actual effect to adjust the position of the controls

为什么 FS26 启动后会显示错误消息 " WUEVENT = BATTERY FAIL "？ 我正在使用 S32K3X4EVB-T172 进行开发。 我注意到，启动后，如果我尝试读取 WUEVENT，会出现电池故障错误消息。 这似乎与 VSUPOV_I、VSUPUV6_I 和 VSUPUVH_I 有关，但这些错误标记没有发生错误。 然后，我使用 ADC 读取 VSUP 电压，结果约为 11.925V，而我的输入电压为 12V。 如何防止 WUEVENT 发送"BATTERY FAIL" 消息？ Re: Why does the FS26 display the error message "WUEVENT = BATTERY FAIL" after booting? 在我的代码中，我写了 IF WUEVENT == 15 / BATTERY FAIL，然后将其写入 WU_CLR，以清除错误。这是因为如果我每次启动时都执行 WU_CLR，我将看不到其他唤醒通知，比如 GPIO1_I、GPIO2_I 等。 不过，我不确定这种用法是否正确。 Re: Why does the FS26 display the error message "WUEVENT = BATTERY FAIL" after booting? 你好，艾伦、 每次 POR 或 VSUP 丢失时都会报告 BATTERY FAIL。设备开机后，请写入 WU_CLR 位以清除唤醒源。如果在设备唤醒后不清除，这些位将始终存在。 BRs, Tomas

支持请求 - 上拉开机引脚后输出短路问题 你好，约瑟夫、 我的一项设计遇到了问题，希望您能给予指导。 我们按照要求拉高了POWER_ON 引脚，但在拉高之后，我们发现输出引脚似乎被短路（或表现为短路）。我们无法了解这种行为的根本原因。 请您帮助我们理解： 为什么拉高 POWER_ON 引脚后输出会短路？ 该引脚是否需要特定的配置步骤或硬件条件？ 有任何建议的诊断或检查方法来隔离问题吗？ 如有需要，我可以提供原理图片段或测量截图。 提前感谢您的支持。 Shivani e. Re: Request for Support – Output Shorting Issue After Pulling Up Power-On Pin 你好@Shivani_Elavena 请提供您在应用中使用的恩智浦部件编号，以便能正确转接到产品团队。 提前谢谢您。 顺祝商祺！ Re: Request for Support – Output Shorting Issue After Pulling Up Power-On Pin 你好，维罗妮卡、 感谢您的支持。 我们在应用中使用的恩智浦部件编号是PF5020。 请将此查询转给相应的产品团队。 提前谢谢您。 致以最诚挚的问候， Shivani e. Re: Request for Support – Output Shorting Issue After Pulling Up Power-On Pin 你好，希瓦妮 请分享您的示意图，包括电压等级和部件值。问题是否可以重复出现？你在多少个板上看到了这个问题？如果更换新的 PF5020，情况是否一样？ 致以最崇高的敬意 约瑟夫

闪存程序目标内存地址 闪存编程器需要指定目标内存地址，以便定位其闪存算法。该地址通常为零，用于将闪存算法定位在存储器的起始位置或小的 SRAM 存储空间或某些处理器中。对于 PPC 目标机，异常向量（IVOR）表通常位于同一低内存区域（如脚本 xx_init_SRAM.tcl）。当指定目标内存地址为零时，闪存算法如何避免与异常向量重叠？ 我正在对连接到 T1024 处理器的 IFC 的或非设备进行闪存编程。我偶尔会在 jtag 日志中收到 "core not responding"（核心无响应）错误，闪存编程器也会出现 "无法读取内存地址... "的故障。我使用的是简单的 SRAM 连接，T1024 的 CPC 容量为 256k。我想弄明白为什么总是出现这些错误。我目前怀疑闪存程序算法会干扰处理器设置并导致异常或其他情况，但我需要更多信息。在闪存编程尝试中，错误发生率约为 50% 。 感谢您的帮助或指点。 谢谢！ Re: Flash program target memory address 请关注 AN4948。 用于 CodeWarrior Power 架构的闪存编程器 谢谢！ Re: Flash program target memory address 嗨，感谢您的回复。我熟悉闪存编程器的设置过程。上述文件没有回答我的问题。如果闪存算法和 PPC 异常向量都锚定在地址 0，它们在编程过程中如何互不干扰？谢谢 Re: Flash program target memory address 您是否更改了 AN4948, 3.1、 图 3.目标任务详细信息, 目标 RAM->地址？ 谢谢！

[S32K311][MultiPartition] : S32K311 の MultiPartition セットアップで SPI 初期化が失敗する こんにちは、チームの皆さん リアは次のことを尋ねています。 ------------------------------------------------------------------------------------- シングルコア ECU (S32K311) にマルチパーティショニングを実装していますが、SPI ドライバの初期化中に問題が発生しました。 観察： SPI ドライバは、OsIf_timer.c から OsIf_GetPartitionID() を呼び出して現在のパーティション ID を取得し、それを SpiID として使用します。ただし、両方が同じ ECUC パーティション用に構成されているにもかかわらず、この ID は SpiCorePartitionUse の値と一致しません。この不一致のため、ドライバは DET エラーをトリガーし、ペリフェラルの初期化に失敗します。 デバッグ中に発見されたこと: 関数 OsIf_apxMultiPartitionPredefinedConfig は、SPI ドライバが予期しない値を返します。これが不一致の原因となっているようです。 初期分析では、この問題は Vector DaVinci/Tresos ツールからの構成生成に関連している可能性があることが示唆されています。 インパクト SPI 初期化はマルチパーティション モードでは完了できず、通信機能がブロックされます。 ------------------------------------------------------------------------------------- BR ステファノ RTD Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 OsIf_apxMultiPartitionPredefinedConfig について言及されている SO、ASR OS を使用していると想定します。 では、この場合、関数 GetApplicationID() からどのような値が返されるのでしょうか? EcuC、Os、Spi、BaseNXP を含む構成を送ってください。 次の構造の出力が生成されました: どのような SW パッケージを使用していますか? よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 Nhi_Nguyenさん 添付ファイルが十分かどうかお知らせください。 BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 関数 SPI_Init() の次のパラメータの読み取りを手伝ってください。 - スピイド？ - Spi_Init() 関数にどのような構成を渡しましたか? このようになります： よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 Nhi_Nguyenさん リアは答えた。 Spi_Init(&Spi_Config_EcucPartition_C0_B); これは Init 関数で渡されたもので、SPI_ID はパーティション ID API から読み取られますが、OS アプリケーション ID に正しくリンクされていません。 BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 これは彼らのアプリケーション内の OS です: Spi_Config_EcucPartition_C0_B を Spi_Init() に渡したので、SPI_ID は次の値にする必要があります。 このCASE、Det エラーが発生しないようにするには、u32AppId を 1 にする必要があります。ただし、関数 OS_GetApplicationID() は RTD ではなく RTOS に属しているため、誰かが取得できるように RTOS にタグを付けてください。 よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 Nhi_Nguyenさん 以下はリアの返答です: このCASE、SPI ID と OS アプリケーションが一致しません。ASIL の場合、1 を返す必要があると考えられますが、0 を返すことで構成の不一致が発生します。以下のスナップショットを確認してください。 ご希望であれば、短いミーティングを行って詳細をご説明することもCANです。 BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 RTOS がどのように動作するのか、または RTOS の関数 GetCurrentApplicationID() から値がどのように返されるのか分かりません。ただし、u32AppID = 0 を現在の状態に保ち、Det エラーを回避したい場合は、以下のようにCANできます。 生成されるファイルは次のようになります。 つまり、u32AppId = 0 の場合、SpiID = 0 となります。 u32AppId = 1、SpiID = 1; SPI では、生成されるファイルは次のようになります。 これは、Spi_Config_EcucPartition_C0_QM->u32SpiCorePartitionUse = 1; を意味します。 Spi_Config_EcucPartition_C0_B->u32SpiCorePartitionUse = 0; 別のCASEでは、u32AppID を別の値に変更したいので、@StefanoGattazzo さん、RTOS タグを追加して、RTD タグを削除してください。RTOS の誰かがCAN手伝ってくれます。 よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 Nhi_Nguyenさん もし誰か知っている人がいたら、直接尋ねてもCANですが、今は緊急です。 BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 RTD を削除してください。RTOS タグを追加したことを確認しました。このチームの誰かが回答します。 よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 Nhi_Nguyenさん 誰にCANで聞けばいいですか？ BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 申し訳ありませんが、これについてはアイデアがありません。 よろしくお願いいたします。 ニ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、チームの皆さん リアはこう書いています。 いいえ、NXP OS ではなくベクター OS を使用しています。OsIf 参照は Base コンポーネントからのものです。 現在、LPSPI2 を QM アプリケーション専用にし、残りの LPSPI モジュールを ASIL B アプリケーション用として SPI ドライバを分割する POC に取り組んでいます。 RTD ユーザー マニュアルによれば、パーティションごとに 2 つの個別の Spi_Init() 呼び出しを呼び出す必要があります。SO、最初に ASIL B OS アプリケーションから Spi_Init() 関数を呼び出し、次に QM OS アプリケーションからそれぞれに正しい構成ポインターを渡して呼び出します。 Spi_Init()関数ではSpi_GetID()が呼び出され、それがGetCurrentApplicationID()を呼び出していることがわかります（下のスクリーンショット）。 以下は、Os によって生成された列挙型です。ASIL B OS アプリケーションが GetCurrentApplicationID() を呼び出すと 0 を返します。QM OS アプリケーションが GetCurrentApplicationID() を呼び出すと 1 を返します。 OsIf_GetPartitionID では、Os によって返された値を使用して、配列 OsIf_apxMultiPartitionPredefinedConfig で構成されているパーティション番号を取得します。 OsIf_apxMultiPartitionPredefinedConfigの値は以下のとおりです。 QM アプリケーションが Spi_Init() を呼び出すと、Spi_GetID() は 1 の値を返します (GetCurrentApplicationID() は 1 を返し、OsIf_apxMultiPartitionPredefinedConfig のインデックス 1 も 1 です)。 しかし、生成された SPI 構成には期待された値がないため、Det にエラーが報告されます。 Spi_Config および OsIf_apxMultiPartitionPredefinedConfig の MCAL によって生成される値に影響を与えるものは何ですか? BR ステファノ Re: [S32K311][MultiPartition] : SPI initialization fails in MultiPartition setup on S32K311 こんにちは、 @StefanoGattazzo さん、 添付のプロジェクトから取得した Spi、Ecu、Os の構成は次のとおりです。 EcuC はパーティション ID を定義するために使用されます。たとえば、その構成では、QM はパーティション 0、C0_B はパーティション 1、システムはパーティション 2 です。 Spi、Os は、EcuC からパーティション ID を取得するパーティションを選択します。例えば： SPI: C0_B はパーティション 1、C0_M はパーティション 0 です。 OS: 構造体 OsIf_apxMultiPartitionPredefinedConfig も EcuC のパーティション ID を参照します。たとえば、次の構成になります。 アプリケーション 0 - システム - パーティション 2; アプリケーション 1 - C0_B - パーティション 1; アプリケーション2 - C0_M - パーティション0; SO、C0_B を Spi_Init() に渡す場合、これはパーティション 1 を Spi_Init() に渡すことを意味し、OsIf_apxMultiPartitionPredefinedConfig[x] = 1; または x = 1; (x = GetCurrentApplicationID();) となります。 SO、彼らが最新の返信で示した写真を見てみましょう。 Spi では、C0_B はパーティション 1 です。 C0_M はパーティション 2 です。 つまり、EcuC では、インデックス 0 はシステム パーティション、インデックス 1 は C0_B パーティション、インデックス 2 は構成に適合しない C0_M パーティションがここに接続されています。 とにかく、上記の Os、Spi、EcuC の定義に基づいて、パーティション構成を調整し、Det エラーを回避できます。 よろしくお願いいたします。 ニ

IMX95 - EMMC部品のお問い合わせ こんにちは、 デザインを更新するために、128GB EMMC 5.1 パーツを探しています。iMX95で検証された部品番号を提案してください よろしくお願いいたします。 インドラジット Re: IMX95 - EMMC PART ENQUIRY こんにちは 、 ご返信ありがとうございます。 提案された部品（MTFC128GAZAQJP-AAT）は古い世代の部品のようです。 この EMMC MTFC128GBCAQTC-AAT 部品が IMX95 で使用できることをCAN確認できますか? Re: IMX95 - EMMC PART ENQUIRY こんにちは、 お問い合わせいただきありがとうございます！Micron MTFC128GAZAQJP-AAT (128GB eMMC 5.1 NAND フラッシュ メモリ) と NXP i.MX95 プロセッサとの互換性を検証しました。はい、このチップは i.MX95 と完全に互換性があり、デザインのアップグレードに直接使用できます。eMMC 5.1 HS400 モードをサポートし、容量とインターフェースは i.MX95 メモリ コントローラの要件と一致しています。以下は、詳細な分析と推奨事項です (NXP 公式互換性ガイドと Micron データシート、2025 年 11 月のデータに基づきます)。 互換性の概要 i.MX95 DDR/eMMC コントローラの仕様: eMMC 5.1 インターフェース (HS400 モード、最大読み取り/書き込み速度 400 MB/秒) をサポートします。 データ バス幅: x8/x16/x32、マルチチップ並列接続をサポート、合計容量は最大 512 GB。 速度サポート：eMMC 5.1（JEDEC JESD84-B51規格）、CL 17-17-17とタイミング互換。 電源: 3.3V ホスト / 1.8V/3.3Vインターフェース、低電力モード。 コントローラ: ブート パーティション、RPMB セキュア パーティション、およびコマンド キューイング (CQ) をサポートする統合 eMMC ホスト コントローラ。 MTFC128GAZAQJP-AAT 仕様: 容量: 128GB (1TB NAND、x8 構成、シングルチップ)。 速度: eMMC 5.1 HS400 (400 MB/秒)、CQ およびパーティションマネジメントをサポート。 パッケージ: FBGA-153 (11.5 x 13 mm)、電圧 3.3V/1.8V、動作温度範囲は-25°C～+85°C（商用グレード）。 その他: ONFI 4.2 準拠、ECC 内蔵 (8 ビット/512B)、RoHS 準拠。 互換性確認: バス幅: i.MX95 は x8 eMMC をサポートし、ブリッジなしで MTFC128GAZAQJP-AAT の x8 構成に直接一致します。 容量とランク: 128GB シングルチップは、i.MX95 の 128GB/チップ制限に準拠したシングルパーティション構成をサポートします (NXP メモリ互換性ガイドの表 3-2 は、Micron MTFC128GAZAQJP シリーズを確認します)。 速度/タイミング: HS400 モードは i.MX95 のサポート範囲 (最大 400 MB/秒) 内に完全に収まり、タイミング パラメータ (tCK = 0.625 ns) はコントローラのデフォルト設定に準拠します。 検証元: NXP i.MX95 メモリ互換性ガイド (Rev.1.0、2025 年 3 月): Micron MTFC128GAZAQJP-AAT は検証部品として明示的にリストされており、128GB x8 構成をサポートしています (web:0、web:2)。 Micron データシート: i.MX シリーズ ホスト コントローラとの eMMC 5.1 標準の互換性を確認します (web:1、web:3)。 NXP コミュニティ投稿: ユーザーは、同様の MTFC128GAZAQJP-AAT を i.MX95 EVK で正常に実行し、ブート テストに合格しました (web:4、web:6)。 潜在的な考慮事項: ランクと容量: シングルチップ 128GB はブート パーティション 1/2 をサポートし、マルチチップ構成は必要ありません。総容量が 128GB を超える場合、2 つのチップを並列にコネクテッドできます (i.MX95 は最大 4 つのチップをサポートします)。 電源/熱マネジメント: VDD = 3.3V、VDDQ = 1.8V であることを確認し、10 µF のデカップリング コンデンサを追加します。x8 構成の消費電力は約 1 W/チップです。EVK 検証では熱の問題は見られませんでした。 ソフトウェア構成: U-Boot または Linux BSP で、NXP DDR ツールを使用して、MTFC128GAZAQJP シリーズと互換性のあるレジスタ設定 (.h ファイル) を生成します。 在庫状況: この部品はまだ生産中です (EOL ではありません)。DigiKey には 500 個以上の在庫があり、単価は 32.50 USD です (1000 個で 26.80 USD)。 推奨される次のステップ テストの推奨事項: テスト用にメモリを i.MX95 EVK ボードに交換します (NXP の無料ツール サポート)。NXP は、必要に応じて無料の DDR 検証サービスを提供します (community.nxp.com)。 Re: IMX95 - EMMC PART ENQUIRY CANを使えますよ。 Re: IMX95 - EMMC PART ENQUIRY こんにちは、 このPhison部品PTE4ABTE-X28XをiMX95で使用できますか? Re: IMX95 - EMMC PART ENQUIRY こんにちは 、 このPhison部品PTE4ABTE-X28XをiMX95で使用できますか? Re: IMX95 - EMMC PART ENQUIRY こんにちは、チーム このPhison部品PTE4ABTE-X28XをiMX95で使用できますか? 弊社の問い合わせをご確認の上、ご確認ください。 Re: IMX95 - EMMC PART ENQUIRY こんにちは、チーム このISSI部品IS22TF128G-JCLA2をiMX95で使用できますか？ Re: IMX95 - EMMC PART ENQUIRY Kingston製の128GB容量でIMX95に対応したeMMCパーツは他にありますか？ IMX95はFA40G0EMCPDKBFIとFA80G0EMCPDKBFIもサポートしていますか？ 128GBメモリサイズでサポートされているeMMCの詳細が記載されたドキュメントへのリンクも共有してください。 Re: IMX95 - EMMC PART ENQUIRY **NXP i.MX95対応のKingston製128GB eMMC製品推奨** NXP i.MX95（i.MX 9シリーズ）は、**eMMC 5.1**インターフェース（HS400モードまで）をサポートしています。キングストンの産業用／標準eMMC製品は、JEDEC eMMC 5.1規格に完全に準拠しており、優れた互換性を保証します。 ### 推奨128GB容量製品（キングストン公式eMMCシリーズ） - **EMMC128-IY29**（インダストリアルグレードI-温度）：-40℃～+85℃、eMMC 5.1 HS400、3D TLC、11.5×13×0.8mmFBGA-153パッケージ。自動車、産業機器、および過酷な環境下での用途に適しています。 - **EMMC128-TY29**（標準商用グレード）：温度範囲は通常0℃～+70℃（または同等）、eMMC 5.1 HS400、3D TLCも搭載。 これらは、Kingstonの現行の主力製品である128GB eMMCモデルで、i.MXシリーズをベースにした多数のSOM/開発ボードに採用されています。 **互換性基準**: - KingstonはNXPの長年のパートナーであり、同社のeMMC製品はNXPのi.MXプラットフォーム（i.MX 951/i.MX95シリーズ、i.MX93xなどを含む）との互換性において実績があります。 - 公式のi.MX95仕様では、3つのSD 3.0 / SDIO 3.0 / **eMMC 5.1**インターフェースが明示的にサポートされています。 - NXPコミュニティは、同様の128GB eMMC 5.1チップ（Micronの同等製品など）がi.MX95と直接互換性があることも確認済みです。キングストンの製品仕様は一貫性があり、直接参照できます。 **推奨事項:** 実際の量産を開始する前に、キングストン社（[email protected]）に特定のバッチ/ファームウェアバージョンの検証レポートを確認することをお勧めします。またはNXP FAE、特にHS400モードと電圧マッチング（通常1.8V/3.3V）に関して。 ### IMX95はFA40G0EMCPDKBFIとFA80G0EMCPDKBFIをサポートしていますか？ はい、一般的にサポートされています。 - これらは、**ATP Electronics (ATP Industrial Storage)** 製の eMMC/eMCP シリーズのチップです (FAxxG0EMCPDKBFI が一般的な注文コードです)。 - i.MX95のeMMCコントローラは、標準的な**JEDEC eMMC 5.1**規格に準拠しています。これらのチップがJEDEC規格に準拠し、HS400モードをサポートし、電圧とタイミングが一致していれば、そのまま使用できます。 - ATPは、自動車/産業分野で広く使用されている製品を提供する、プロフェッショナルな産業グレードのストレージメーカーです。同社の製品は、i.MX95などのプロセッサ（MicronやKingstonの実績あるチップと同様）との互換性に優れています。 **重要な注意事項**: - i.MX95のブートモードに対応するためには、特定のチップのeMMCバージョン（5.1かどうか）、NANDタイプ、およびファームウェアのサポート状況を確認する必要があります。 - ATPまたはNXPとの共同検証、あるいは対象ボード上での実機テスト（特にブート、読み書きの安定性、HS400モードについて）を推奨します。 ### 推奨互換性詳細ドキュメントリンク 1. **キングストン公式「組み込みストレージメモリチップセット互換性ガイド」**（最も直接的な推奨事項） → [ https://media.kingston.com/pdfs/emmc/embedded-storage-memory-chipset_us.pdf](https://media.kingston.com/pdfs/emmc/embedded-storage-memory-chipset_us.pdf ) この資料には、NXPのi.MXシリーズ全体（i.MX95/i.MX951を含む）とKingstonのeMMC/eMCPとの互換性表が含まれており、非常に便利です。 2. **NXP i.MX95 公式データシート**（インターフェース仕様確認済み） → [IMX95CEC.pdf]( https://www.nxp.com/docs/en/data-sheet/IMX95CEC.pdf )（または最新バージョン） 第4章「メモリインターフェース」では、eMMC 5.1のサポートに関する詳細が明確に記載されています。 3. **NXPコミュニティ i.MX95 eMMC選定に関するディスカッション**（実例） → [ https://community.nxp.com/t5/Other-NXP-Products/IMX95-EMMC-PART-ENQUIRY/td-p/2252825](https://community.nxp.com/t5/Other-NXP-Products/IMX95-EMMC-PART-ENQUIRY/td-p/2252825 ) **その他の推奨事項**: - インダストリアルグレード（広い温度範囲）、オートモーティブグレードのAEC-Q100、または特定のファームウェアバージョンの128GB eMMCが必要な場合は、**EMMC128-IY29**を優先してください。 その他のモデルや最新の検証レポートについては、下記までお問い合わせください。 - キングチップテック

SE052F の Se05x_API_SessionOpen の失敗 (Raspberry Pi I2C 通信の問題) こんにちは、チーム Plug & Trust Nano パッケージ を使用して I2C 経由で SE052F と通信しようとしているときに問題が発生しています。 AN14277 アプリケーション ノートに従って、SCP03 キーを次のように構成しました。 ENCキー: 3ae441c747e32ebc16b3bb2d843c6dd8 MACキー: 6c18f3d08fee1cb96a3c8de5d3538aaa ただし、Se05x_API_SessionOpen は常に失敗します。 システム情報 プラットフォーム: Raspberry Pi パッケージ: Plug and Trust Nano Package v1.5.4 使用した例: ex_se05x_GetInfo ログの詳細: ./ex_se05x_GetInfo Se05x Getinfo の例! Plug and Trust ナノパッケージ - バージョン: 1.5.4 I2C ドライバは、単純な i2c レベルのコマンドをサポートします。 APDU送信> :00 a4 04 00 0b d2 76 00 00 85 30 4a 43 4f 90 03 00 データの書き込みに失敗しました (nrWritten=-1)。 Se05x_API_SessionOpen 失敗Se05x_API_SessionOpen でエラーが発生しました SE05x Getinfo の例が失敗しました。 Raspberry Pi での I2C 検出の詳細: flexxon@raspberrypi:~/SE050/NEW-NANO/se052f/nano-package/examples/se05x_GetInfo/Linux/build $ i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 ABCDEF 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- ありがとうございます スレシュクマール R SE050 Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん テスト結果ログは以下をご覧ください。さらなる分析のために追加情報が必要な場合はお知らせください。 flexxon@raspberrypi:~/SD/simw-top_build/raspbian_native_se050_t1oi2c/bin $ ./se05x_GetInfo 有効化ピンのエクスポートに失敗しました: 無効な引数です GPIO値ファイルを開けませんでした: そのようなファイルまたはディレクトリはありません GPIO のアンエクスポートに失敗しました: 無効な引数です アプリ:INFO:./se05x_GetInfo を実行中 アプリ:INFO:選択を上書きする場合は、ENV=EX_SSS_BOOT_SSS_PORT を使用するか、コマンドライン引数を渡します。 アプリ:情報:PlugAndTrust_v04.07.01_20250519 アプリ:INFO:デフォルトの PlatfSCP03 キーを使用しています。ENV=EX_SSS_BOOT_SCP03_PATH を使用してファイルからキーを使用することができます。 sss :INFO :atr (長さ=35) 01 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 00 01 00 00 00 00 64 13 88 0A 00 65 53 45 30 35 31 00 00 00 scp:WARN:nxEnsure:'status == kStatus_SSS_Success' が失敗しました。行:148 関数:nxScp03_AuthenticateChannel sss :エラー:SCP03セキュアチャネルを設定できませんでした アプリ:エラー:sss_session_open に失敗しました アプリ:エラー:ex_sss_session_open 失敗 アプリ:エラー:!エラー!ret != 0。 flexxon@raspberrypi:~/SD/simw-top_build/raspbian_native_se050_t1oi2c/bin $ ./se05x_Minimal 有効化ピンのエクスポートに失敗しました: 無効な引数です GPIO値ファイルを開けませんでした: そのようなファイルまたはディレクトリはありません GPIO のアンエクスポートに失敗しました: 無効な引数です アプリ:INFO:./se05x_Minimalを実行中 アプリ:INFO:選択を上書きする場合は、ENV=EX_SSS_BOOT_SSS_PORT を使用するか、コマンドライン引数を渡します。 アプリ:情報:PlugAndTrust_v04.07.01_20250519 アプリ:INFO:デフォルトの PlatfSCP03 キーを使用しています。ENV=EX_SSS_BOOT_SCP03_PATH を使用してファイルからキーをCAN sss :INFO :atr (長さ=35) 01 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 00 01 00 00 00 00 64 13 88 0A 00 65 53 45 30 35 31 00 00 00 sss :INFO :アプレットの新しいバージョンが見つかりました sss :INFO :0x30100 用にコンパイルされました。新しい0x70216を取得しました scp:WARN:nxEnsure:'status == kStatus_SSS_Success' が失敗しました。行:148 関数:nxScp03_AuthenticateChannel sss :エラー:SCP03セキュアチャネルを設定できませんでした アプリ:エラー:sss_session_open に失敗しました アプリ:エラー:ex_sss_session_open 失敗 アプリ:エラー:!エラー!ret != 0。 ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 本当に以下のオプションで MW を再構築しましたか? PTMW_ SE05X_ バージョン = 03_XX PTMW_SE05X_Auth = プラットフォームSCP03 ログから、いくつかの競合が見つかりました: sss :INFO :0x70200 用にコンパイルされました。新しい 0x70216 を取得しました sss :警告:通信チャネルはプレーンです。 ご説明をよろしくお願いいたします。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 情報ありがとうございます！テストで使用された platformSCP キーは SE052F 用ではないようです。SE-PLUG-TRUST-MW_04.07.01/simw-top/doc/appendix/platfscp.html のガイドに従ってキーを設定してください。 お役に立てれば幸いです。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 Raspberry Piでテストしているとのことですが、MWのフルバージョンでもテストしましたか？ 動作しましたか？ご説明をよろしくお願いいたします。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん 迅速なご返信をありがとうございます。 simw_top ビルド中に次の構成を使用しましたが、se05x_GetInfo は正常に実行されますが、se05x_Minimal は失敗します。ログは以下に示されています。 PTMW_アプレット = SE05X_C PTMW_ FIPS = なし PTMW_ SE05X_ バージョン = 03_XX PTMW_SE05X_Auth = プラットフォームSCP03 PTMW_ SCP = SCP03_SSS SSSFTR_ SE05X_ RSA = 無効/有効 ./se05x_GetInfo 有効化ピンのエクスポートに失敗しました: 無効な引数です GPIO値ファイルを開けませんでした: そのようなファイルまたはディレクトリはありません GPIO のアンエクスポートに失敗しました: 無効な引数です アプリ:INFO:./se05x_GetInfo を実行中 アプリ:INFO:選択を上書きする場合は、ENV=EX_SSS_BOOT_SSS_PORT を使用するか、コマンドライン引数を渡します。 アプリ:情報:PlugAndTrust_v04.07.01_20250519 sss :INFO :atr (長さ=35) 01 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 00 01 00 00 00 00 64 13 88 0A 00 65 53 45 30 35 31 00 00 00 アプリ:警告:#################################################### ## App :INFO :uid (Len=18) 04 00 50 01 39 97 7A C3 BF 57 52 04 26 1F 32 0A 1D 90 App :INFO :Running ./se05x_GetInfo App :INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments. sss :INFO :atr (Len=35) 01 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 00 01 00 00 00 00 64 13 88 0A 00 65 53 45 30 35 31 00 00 00 sss :INFO :Newer version of Applet Found sss :INFO :Compiled for 0x70200. Got newer 0x70216 sss :WARN :Communication channel is Plain. sss :WARN :!!!Not recommended for production use.!!! App :WARN :## ######################################################### ## App :INFO :Applet Major = 7 App :INFO :Applet Minor = 2 App :INFO :Applet patch = 22 App :INFO :AppletConfig = 26F2 App :INFO :With ECDSA_ECDH_ECDHE App :INFO :WithOut EDDSA App :INFO :WithOut DH_MONT App :INFO :With HMAC App :INFO :With RSA_PLAIN App :INFO :With RSA_CRT App :INFO :With AES App :INFO :WithOut DES App :INFO :With PBKDF App :INFO :With TLS App :INFO :WithOut MIFARE App :INFO :With I2CM App :INFO :Internal = FFFF App :WARN :## ##################################################################### ## App :INFO :Tag value - proprietary data 0xFE = 0xFE App :INFO :Length of following data 0x45 = 0x4F App :INFO :Tag card identification data (Len=2) DF 28 App :INFO :Length of card identification data = 0x4C App :INFO :Tag configuration ID (Must be 0x01) = 0x01 App :INFO :Configuration ID (Len=12) 00 05 B5 01 1B 7D B8 1B 89 99 D0 5D App :INFO :OEF ID (Len=2) B5 01 App :INFO :Tag patch ID (Must be 0x02) = 0x02 App :INFO :Patch ID (Len=8) 00 00 00 00 00 00 00 00 App :INFO :Tag platform build ID1 (Must be 0x03) = 0x03 App :INFO :Platform build ID (Len=24) 4A 33 52 36 30 30 30 33 37 33 31 38 31 32 30 30 6D 20 B6 19 7D 63 5E 7C App :INFO :JCOP Platform ID = J3R6000373181200 App :INFO :Tag FIPS mode (Must be 0x05) = 0x05 App :INFO :FIPS mode var = 0x01 App :INFO :Tag pre-perso state (Must be 0x07) = 0x07 App :INFO :Bit mask of pre-perso state var = 0x00 App :INFO :Tag ROM ID (Must be 0x08) = 0x08 App :INFO :ROM ID (Len=8) B3 37 5F E9 B5 50 8B C4 App :INFO :Tag JCOP OS Core ID (Must be 0x0A) = 0x0A App :INFO :JCOP OS Core (Len=8) 55 60 6F D4 BE EC F3 CD App :INFO :Status Word (SW) (Len=2) 90 00 App :INFO :se05x_GetInfoPlainApplet Example Success !!!... App :WARN :## ############################################################### アプリ:INFO:cplc_data.IC_fabricator (Len=2) 47 90 アプリ:INFO:cplc_data.IC_type1 (Len=2) D6 00 アプリ:INFO:cplc_data.Operating_system_identifier (Len=2) 47 00 アプリ:INFO:cplc_data.Operating_system_release_date (Len=2) 00 00 アプリ:INFO:cplc_data.Operating_system_release_level (Len=2) 00 00 アプリ:INFO:cplc_data.IC_fabrication_date (Len=2) 41 02 アプリ:INFO:cplc_data.IC_Serial_number (Len=4) 38 51 87 21 アプリ:INFO:cplc_data.IC_Batch_identifier (Len=2) 02 67 アプリ:INFO:cplc_data.IC_module_fabricator (Len=2) 00 00 アプリ:INFO:cplc_data.IC_module_packaging_date (Len=2) 00 00 アプリ:INFO:cplc_data.ICC_manufacturer (Len=2) 00 00 アプリ:INFO:cplc_data.IC_embedding_date (Len=2) 00 00 アプリ:INFO:cplc_data.IC_OS_initializer (Len=2) 19 26 アプリ:INFO:cplc_data.IC_OS_initialization_date (Len=2) 1階 38 アプリ:INFO:cplc_data.IC_OS_initialization_equipment (Len=4) 35 31 38 37 アプリ:INFO:cplc_data.IC_personalizer (Len=2) 00 00 アプリ:INFO:cplc_data.IC_personalization_date (Len=2) 00 00 アプリ:INFO:cplc_data.IC_personalization_equipment_ID (Len=4) 00 00 00 00 アプリ :INFO :cplc_data.SW (Len=2) 90 00 アプリ:INFO:ex_sss 終了 GPIO値ファイルを開けませんでした: そのようなファイルまたはディレクトリはありません GPIO のアンエクスポートに失敗しました: 無効な引数です GPIO のアンエクスポートに失敗しました: 無効な引数です flexxon@raspberrypi:~/SD/simw-top_build/raspbian_native_se050_t1oi2c/bin $ ./se05x_Minimal 有効化ピンのエクスポートに失敗しました: 無効な引数です GPIO値ファイルを開けませんでした: そのようなファイルまたはディレクトリはありません GPIO のアンエクスポートに失敗しました: 無効な引数です アプリ:INFO:./se05x_Minimalを実行中 アプリ:INFO:選択を上書きする場合は、ENV=EX_SSS_BOOT_SSS_PORT を使用するか、コマンドライン引数を渡します。 アプリ:情報:PlugAndTrust_v04.07.01_20250519 sss :INFO :atr (長さ=35) 01 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 00 01 00 00 00 00 64 13 88 0A 00 65 53 45 30 35 31 00 00 00 sss :INFO :アプレットの新しいバージョンが見つかりました sss :INFO :0x70200 用にコンパイルされました。新しい0x70216を取得しました sss :警告:通信チャネルはプレーンです。 sss :警告:!!!本番環境での使用は推奨されません。!!! sss :WARN :nxEnsure:'ret == SM_OK' が失敗しました。行:7839 関数:sss_se05x_TXn sss :WARN :APDUトランザクションエラー:条件が満たされていません (0x6985) アプリ:エラー:Se05x_API_GetFreeMemory 失敗 アプリ:INFO:mem=0 アプリ:エラー:se05x_Minimal 例が失敗しました!!!... アプリ:INFO:ex_sss 終了 アプリ:エラー:ex_sss_entry 失敗 アプリ:エラー:!エラー! ret != 0。 ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん 更新ありがとうございます。はい、正しい PlatformSCP キーを設定した後、MW は正常に動作するようになりました。しかし、私は異常なことに気づきました。Plug & Trust Nano パッケージのサンプルも、以前は失敗していたにもかかわらず、現在はコードを変更せずに動作するようになりました。彼らがどうして突然働き始めたのか理解できません。この動作の原因を明確にしていただけますか? flexxon@raspberrypi:~/SE050/NEW-NANO/se052f/nano-package/examples/se05x_crypto/Linux/build $ ./ex_se05x_crypto Se05x 暗号の例! Plug and Trust ナノパッケージ - バージョン: 1.5.4 I2C ドライバは、単純な i2c レベルのコマンドをサポートします。 SE05x へのセキュア チャネルを確立します。 scp03セッションを作成しました バージョンを取得 ==> アプレットバージョン7.2.22 ex_get_version、合格 ex_generate_nist256_key、合格 ex_set_get_nist256_key、合格 ex_nist256_sign_verify、合格 ex_generate_nist384_key、合格 ex_set_get_nist384_key、合格 ex_nist384_sign_verify、合格 ex_set_certificate、合格 ex_ecdh、合格 ex_aes_ECB_NOPAD、合格 ex_aes_CBC_NOPAD、合格 ex_aes_CTR、合格 ex_nist256_sign_policy、合格 ex_read_attst_object、合格 i2c デバイス 3 を閉じます。 SE05x 暗号例成功! ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん 提案されたとおりに RST ピンを VCC に接続してセットアップをテストしましたが、問題は依然として解決しません。さらに、最初にミドルウェア サンプルを実行すると、ミドルウェアと Nano パッケージの両方が正しく機能することがわかりました。ただし、SE052F ボードの電源を切断して再接続すると、Nano パッケージは再び動作しなくなります。 ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 SE05xをラズベリーボードにどのように接続しましたか?ワイヤで接続する場合は、リセット時の SE ホールドを回避するために、RST ピンを VCC に直接接続できる可能性があります。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん 2 つの新しい SE052F ボードをテストしています。最初のボードでは、Plug & Play Nanoパッケージのサンプルは最初は失敗しましたが、Middlewareサンプルをplain_scp.txtで一度実行した後、ミドルウェアと Nano の両方のサンプルが正常に動作するようになりました。 しかし、2 番目の新しいボードに切り替えて Nano パッケージをテストすると、失敗します。その後、最初のボードに戻すと、Nano パッケージも再び失敗します。Nano パッケージを動作させるには、毎回 plain_scp.txt を使用してミドルウェア サンプルを実行する必要があるようです。 異なる SE052F ボード間で切り替えたときに、Plug & Play Nano サンプルの動作が一貫していない理由を明確にしていただけますか?Nano パッケージを実行する前に、各ボードに対して何らかの構成または再初期化が必要ですか? ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 この問題をここで再現することがCANでき、現在MWチームに確認中です。進展があればお知らせします。 ご辛抱いただきありがとうございます！ よろしくお願いいたします。 カン Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 申し訳ありませんが、休暇のため、今のところ MW チームからの返答はありませんが、迅速な解決策として、以下のようにタイマー間隔を長くすることができます。 ソースファイルはnano-package-master/lib/platform/linux/にあります。 お役に立てれば幸いです。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Li 更新ありがとうございます。 この問題に関して MW チームから進捗状況や最新情報があるかどうかを確認しています。 何か情報がありましたらお知らせください。 ありがとう、 スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Liさん 提案されたとおり、タイマー間隔を増やしましたが、それでも同じ動作が発生します。 この問題に関して MW チームから何か最新情報はありますか? ありがとうございます スレシュクマール R Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@krsuresh 、 代わりに、より大きな値を試しましたか?MW はこれを計画に組み入れていますが、修正は次のリリースになると思います。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) @Kan_Liこれを利用できるようになることが期待できる、定期的に行われる予定リリースを知っていますか? たとえば、四半期ごと、またはQ1とQ3ごとでしょうか? それがすぐに起こることでない場合は、開発活動に影響を与えないようなオフサイクルリリースの可能性があるかどうかを知る必要があります。 それ以外の場合は、SE050 (今後のプロトタイプ ビルド用) の使用に戻るなどの他のオプションを検討し、SE052 への移行に何が必要かを理解する必要がありそうです。 Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Kan_Li はい、SE052 評価ボードを使用してパッケージで提供されるサポートされているすべてのコード/関数を実行できる限り、2 月末まで有効です。もちろん、このパッケージが早く利用可能になればなるほど、私たちにとっては良いことです。 最後に、新しいパッケージが利用可能になったときに通知を受けるための良い方法は何でしょうか?ここで電子メール通知を受信できない理由がわかりません。また、NXP Web サイトを毎日更新して更新を確認するつもりもありません。 Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Ben-FLX 、 メインパッケージのリリースと合わせて、2026年2月末にリリースを計画しています。貴社のスケジュールと合致していますか？ よろしくお願いいたします。 カン Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Ben-FLX 、 ご説明ありがとうございます！この件についてはMWチームにお知らせします。通知については、以下に示すように、github の notify 関数を使用できると思います。 いずれにせよ、いつでもここで私に連絡を取ることができます。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) @Kan_Liちょっと疑問なのですが、計画されているコードリリースについて何か更新やニュースはありますか?順調に進んでいますか？ Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Ben-FLX 、 MWチームに確認したところ、修正は3月31日までに公開される予定です。しかし、他の優先事項があるため、遅れが生じています。ご不便をおかけして申し訳ございません。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) @Kan_Li 新しい展望の最新情報をありがとうございます。3 月末になっても実現しない単なる幻影ではなく、この新しい見通しについて NXP の確約を得ることはできるでしょうか? このニュースをそのまま受け入れ、SE052 に関して前進できないことを知る以外に、この不快な後味を表明する他の手段を私は知りません。 おそらく、他のベンダーを真剣に検討する必要があるでしょう... Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) こんにちは@Ben-FLX 、 GitHub nano-Pkg は更新されましたが、まだリリースではありません。これはプレリリースであり、評価目的で git clone するだけで済みます。リリース プロセスは、暫定的に 2026 年 3 月 31 日に予定されているメイン パッケージのリリースとともに完了します。 お役に立てれば幸いです。 すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 --------------------------------------------------------------------------------- Re: Failure in Se05x_API_SessionOpen on SE052F (Raspberry Pi I2C Communication Issue) @Kan_Li MWはさらに遅れると想定しています Last update was 6 months ago based on 31/3/2026 10.16am (+8GMT timestamp)最終更新は6か月前、2026年3月31日午前10時16分（+8GMTタイムスタンプ）に基づいています。

KW45 noinit 柱塞部分 您好，nxp 专家： 我想在 kw45 中隔离一部分 RAM，用于存储一些标志。但是，当前，当我尝试将 0xa5a5a5a5 写入地址 0x020000000 然后进行软复位时，RESET后从地址 0x020000000 读取的值为 0。你能否帮我弄清楚如何确保软复位后读取的值与RESET前读取的值相同？ KW45 Re: KW45 noinit ram section 你好，@Christine_Li： 不过，我又注意到启动文件 startup_KW45B41Z83 .S 中的这部分代码 --它不是清除了 0x2001_A000 至 0x2001_C000的内存范围 吗？ .ram_init_stcm5: ldr r0, =0x2001a000 ldr r1, =0x2001c000 .loop5: /* Initialize stcm5 */ stmia r0!, {r2 - r5} cmp r0, r1 bcc.n .loop5 Re: KW45 noinit ram section 你好，@jiajun_cheng 最后 8 KB RAM (0x2001_A000) 来自独立的电源开关功能域，可在所有电源模式下保持数据保留。 详情请参阅 KW45 参考手册 如果您对此案有任何其他关切，请告诉我。 否则，请毫不犹豫地将我的回答标记为解决方案，这样我们就可以结案了。 顺祝商祺！ Christine。 Re: KW45 noinit ram section 你好，@jiajun_cheng 在这个案子上我还能为你做什么？ 顺祝商祺！ Christine。

关于 MPC5777C DCF_UTEST_REE_TMPSNS 配置后 PMC_SELF_TEST 失败的查询 我正在使用 MPC5777C 芯片配置 UTEST 的 PMC 温度传感器 RESET 事件启用控制 DCF。我将 LDPLS 位设置为 1 以在 PMC_REE_TD 寄存器中加载 DCF 客户端数据，我将 TEMPSNS0 和 TEMPSNS2 都设置为 0 以禁用由温度传感器引起的 RESET 事件。 -> DCF 配置如下：dcf_utest_ree_tmpsns: ldpls(1), tmpsns2(0), tmpsns0(0) 在此状态下向 MPC5777C 供电时，PMC_SELF_TEST_UM_VD_REG 的 ST_RESULT 显示单片机自检失败。在配置 DCF 之前，结果总是 PASS，但在配置之后，记录为 Failed。这种行为因我们生产的板而异。 例如，在板 1 上，它总是在配置 DCF 之后失败，而在板 2 上，它总是在配置 DCF 之后通过（两个板始终在 DCF 配置之前通过）。 我的问题是 1.我想了解我配置的 DCF 中的 LDPLS、TEMPSNS0 和 TEMPSNS2 设置如何影响 PMC 自检操作和结果。具体而言，当温度传感器 RESET 事件被禁用时，自检有时会失败甚至通过，这是否正常？ 2。如果我已经配置了 DCF，那么在启动顺序之后在应用程序区域重新配置 PMC 设置，然后再次执行自检是否正确？ 我一直都很感谢你善意而有益的回复。

スタンバイ モードから機能をリセットした後のウェイクアップ ソースの認識。 こんにちは、NXPさん 私はスリープウェイクアップアプリケーションに取り組んでいます。スタンバイウェイクアップ用のウェイクアップスリープ構成を構成しました。 私の質問は、スタンバイ ウェイクアップから機能をリセットした後、ウェイクアップ ソースをどのように知ることができるかということです。 Re: Wakeup Source Recognition after function reset from standby mode. こんにちは@aryandis 、 ウェイクアップ後、WISR/WISR_64 レジスタを読み取って、ウェイクアップの原因となったソースを特定CAN。スタンバイ終了後も値はそのまま保持されるため、スタンバイ RAM に保存したり、高速スタンバイ終了を使用したりする必要はありません。 Mcu_GetResetReason() は、前回のリセットがスタンバイ終了だったか、その他のリセット (HW、SW、WDG など) だったかを返しますが、ウェイクアップ ソース用の API はありません。 レジスタを読み取る場合は、メイン ルーチンがレジスタを保存する前にクリアしないようにし、立ち下がりエッジを使用する場合はパッド保持を有効にする必要があることに注意してください (このコミュニティ投稿を参照してください: Solved: WISR_64 no correct after wakeup from fast standby mode on S32K312 - NXPコミュニティ )。 コミュニティからの低電力の例をCAN参照できます。 S32K3 パワーマネージメント AN とデモ - NXPコミュニティ [RTD400 & 500 MCAL & IP] S32K3 パワーマネージメント AN とデモ - NXPコミュニティ MCAL レイヤーは、ウェイクアップ ソースを報告する EcuM モジュールも提供しますが、RTD パッケージは EcuM のスタブ ファイルのみを提供します。これらは参照用として使用することを目的としており、アプリケーションのニーズに応じて変更/置換できます。 よろしくお願いします、 ジュリアン Re: Wakeup Source Recognition after function reset from standby mode. 私は Autosar スタックを使用しているため、ウェイクアップ ソース ID が必要です。 機能リセット後にスタンバイ ドメインに保存するために WISR/WISR_64 値を構成するにはどうすればよいですか? CANどのように設定すればよいか教えていただけますか。 Re: Wakeup Source Recognition after function reset from standby mode. こんにちは@aryandis 、 はい、これはWkpu_Ip_GetInputState() を呼び出し、対応する WKPU チャネルが設定されている場合は TRUE を返し、フラグをクリアします。 ウェイクアップ (スタンバイ終了) 後、NVIC レジスタはデフォルトにリセットされます (すべてのペリフェラル割り込みが無効になります) が、WKPU レジスタの値と以前の状態は保持されます。したがって、ウェイクアップ後にプラットフォーム関数を呼び出してウェイクアップの割り込みを有効にすると（WKPU_IRQn に NVIC_ ISER を構成する）、プログラムはウェイクアップ割り込み関数にジャンプし、どのウェイクアップ ソースが発生したかを判別できます。 ウェイクアップ後の実行モードでウェイクアップの割り込みを有効にするプラットフォーム関数を呼び出さない場合は、Wkpu_Ip_GetInputState() 関数を呼び出してウェイクアップ ソースを判別できます。 ウェイクアップ後に直接レジスタを読み取るCAN。 よろしくお願いします、 ジュリアン Re: Wakeup Source Recognition after function reset from standby mode. はい、質問が1つあります。  EcuMモジュールを有効にし、EcuM_CheckWakeup()内でIcu_Checkwakeup()を呼び出しました。しかし、ICUウェイクアップイベント情報が発生してもEcuM_CheckWakeup()をトリガーできないという問題があります。（チャネル状態がRUNNINGであるため、EcuM_CheckWakeup()を呼び出すことができないためです。） EcuM_CheckWakeup() をどのようにトリガーすればよいですか? ISR と同じウェイクアップ ピンを作成して、EcuM_CheckWakeup()->Icu_CheckWakeup() を呼び出してビット ステータスを WAKEUP_STATE に設定し、EcuM_SerWakeupEvent() を呼び出すことはできますか? ISR として CAN 場合、どうすれば CAN できますか? Re: Wakeup Source Recognition after function reset from standby mode. こんにちは@aryandis 、 申し訳ありませんが、おっしゃる通りです。Icu_Init() 関数を呼び出すと、プラットフォーム 関数を呼び出す前に割り込みフラグがクリアされ、現在のモードが ICU_NORMAL_MODE に変更されます。SO、それ以前に Icu_Init() を呼び出すことはできません。これはドライバの制限のようです。社内チームにフィードバックをお願いします。 また、Icu_GetInputState() 関数内では、Icu_Init() 関数によって初期化する必要があるグローバル変数を使用します。このような状況では、Wkpu_Ip_GetInputState() 関数を呼び出して WISR または WISR_64 のステータスを確認してクリアするか、直接読み取ることができると思います。 よろしくお願いします、 ジュリアン Re: Wakeup Source Recognition after function reset from standby mode. 同じ問題をデバッグしたところ、ウォーム リセットのスタンバイ ウェイクアップ後の Icu_Init の開始時に ICU_NORMAL_MODE が設定されているため、ICU_CurrentMode が原因で EcuM_Checkwakeup が呼び出されなかったことがわかりました。 ウェイクアップ後に EcuM_Cehckwakeup が呼び出されるSOするにはどうすればいいですか? Re: Wakeup Source Recognition after function reset from standby mode. こんにちは、Julian_AragonM さん。スタンバイウェイクアップ後に Icu_Init() で現在のモードを ICU_NORMAL_MODE に変更することに関して、チームに一度連絡していただけますか。これを回避するにはどうすればよいですか? Re: Wakeup Source Recognition after function reset from standby mode. ウェイクアップ ソースは動作しており、ウェイクアップ後に Icu_ReportEvent が来ますが、Icu_CuurentMode 変数が原因で、Icu_Init() から ICU_NORMAL_MODE に初期化され、EcuM_CheckWakeup が呼び出されません。 EcuM_CheckWakeup は Icu_ReportwakeupAndOverFlow ICU ドライバから呼び出されています。 Icu_ReportwakeupAndOverFlow には、変数 Icu_CuurentMode から ICU_MODE_SLEEP マクロまでの条件チェックがあります。 Re: Wakeup Source Recognition after function reset from standby mode. こんにちは、 @aryandis さん。 Icu NORMAL モードでは、ウェイクアップ ソースの処理が妨げられることはありません。Icu が EcuM チェック ウェイクアップを妨げているコード部分を共有していただけますか?ICU モードに関係なく、Icu_CheckWakeup() が呼び出されることは CAN です。 社内チームからも返答がありました。 1.ご存知のとおり、Icu モジュールは、MCAL レイヤーでウェイクアップ ソースを直接チェックできる機能を提供していません。Icu はウェイクアップ ソース情報を EcuM モジュールに転送し、このモジュールはウェイクアップ ソースをチェックします。RTD ドライバでは、EcuM はスタブ モジュールであり、参照として使用することを目的としており、アプリケーションのニーズに応じて変更/置換できます。 ECU 状態マネージャの仕様は次のとおりです。 2. Icu 構成で、ユーザーが「IcuWkpuStandbyWakeSupport」を有効にすると、Icu_Init() は WISR フラグをクリアしません。 プロジェクトで、Wkpu_Ip レイヤーのウェイクアップ ソースを確認するには、以下のコードを参照します。 Icu_Init() 関数の前に Platform_Init(NULL_PTR); を呼び出すと、何らかの理由で WISR フラグが消去されることがわかりました。SO、この関数を Icu_Init() 関数の後に呼び出しました。 よろしくお願いします、 ジュリアン Re: Wakeup Source Recognition after function reset from standby mode. はい、正解です。そして、 Icu_CheckWakeup () は、マッピングした EcuM_CheckWakeup から呼び出されます。また、EcuM_CheckWakeup は、RTD の Icu_ReportWakeupAndOverflow API から呼び出され、SLEEP_MODE をチェックする条件を持ちます。SLEEP_MODE なしで EcuM_CheckWakeup がどのようにトリガーされるか。 それとも、ISR から EcuM_Checkwakeup を呼び出す必要がありますか? これはRTD 3.0.0のスナップショットです Re: Wakeup Source Recognition after function reset from standby mode. こんにちは@aryandis 、 Icu_CheckWakeup () は、ウェイクアップ後に (通常は EcuM によって) 呼び出され、ICU がソースを検証し、それが有効かどうかを EcuM に通知できるようにするためのパブリック AUTOSAR ICU API です。ドライバがSLEEPモードにあるかどうかには依存しません。 Icu_ReportWakeupAndOverflow () は RTD 内部および非 AUTOSAR であり、割り込みコンテキストからすぐにウェイクアップ (およびオーバーフロー) を報告するロジックをバンドルします。   ウェイクアップ後に、Icu_Init() を NORMAL に設定し (IcuWkpuStandbyWakeupSupport = true で WKPU フラグが保持されることを確認)、マップされた EcuM ウェイクアップ ソースを使用して Icu_CheckWakeup() を呼び出すことをお勧めします。これは、Icu_CurrentMode が NORMAL であっても機能します。   よろしくお願いします、 ジュリアン Re: Wakeup Source Recognition after function reset from standby mode. こんにちは@aryandis 、 私の見解では、選択肢は 2 つあります。 1.スタンバイ終了後、EcuM ステート マシンが RUN に移行する前に、 EcuM_Checkwakeup () を呼び出します。これにより、スタンバイ中にウェイクアップ ソースが処理されます。ウェイクアップ ソースが有効な場合、ECU は RUN 状態に戻ります。 これは、ECU 状態マネージャの仕様に記載されています。 2. ISR コンテキストを介してこれを呼び出すと、ウェイクアップ ソースが直ちに処理されます。 よろしくお願いします、 ジュリアン

屏幕分辨率的高度能不能设置100以下的？ 我的屏幕是256x64，然后64就没办法设置，要设置成100，还有其他的小屏幕就不好用这个软件开发 Re: 屏幕分辨率的高度能不能设置100以下的？ 使用esp32，屏幕是led点阵屏，hub75接口的。为什么要限制分辨率呢，现在因为分辨率问题没把法使用改软件 Re: 屏幕分辨率的高度能不能设置100以下的？ 我也有同样问题，用76*284的屏幕，软件只能100~2500的分辨率 Re: 屏幕分辨率的高度能不能设置100以下的？ Hi @zhujianfeng  您可以详细描述一下您的问题么？你用什么芯片，用什么屏幕？ BR Harry Re: 屏幕分辨率的高度能不能设置100以下的？ 然后64就没办法设置 回复： 屏幕分辨率的高度能不能设置100以下的？ 可以在xxx.guiguider文件中修改后再用guider打开

I²C 总线概述（日本博客） 0. 目录 目录 什么是I²C？ 1.1 历史和规格 1.2 控制器/目标 物理/电气特性 2.1 信号线数量：SDA、SCL 2.2 开漏输出（线与门） 2.3 时钟频率 2.4 连接拓扑 协议 3.1 必需功能和可选功能 3.2 数据传输单元 3.3 公交车状态：换乘的开始和结束 3.4 交易结构 3.5 写入和读取事务 参考资料 1. 什么是 I²C？ 1.1 历史和规格 I²C （I²C）总线是一种串行总线规范，由荷兰飞利浦公司（现为恩智浦半导体公司）于 1982 年开发和发布。 I²C 是“集成电路间电路” （Inter Integrated Circuit ）的缩写，写作“IIC”，其中重叠的“I”是平方的。 当年开发这条总线的时代，电视和无线电电路尚在使用可变电阻和可变电容器，通过线圈芯的螺丝进行调整和设置。I²C取代了这些，并开始被用作总线，以通过设备中内置的控制器和工厂计算机来控制各项功能并实现其自动化。 为此，原始时钟频率设置为 100 kHz，并且没有预料到会有大量的数据传输。 上世纪 80 年代末我加入飞利浦时，实验室配备了闭路电视（计算机控制电视）和其他设备来演示这一概念。 当前的I²C 规范由恩智浦半导体公司（NXP Semiconductors）管理，该公司原为飞利浦半导体部门。该规范以《 I²C 总线规范及用户手册》 （文档编号 UM10204 ）的形式发布，最新版本为 Rev.7。日文版Rev.5 也以《 I²C 总线规范及用户手册》的形式发布。Rev.5 和 Rev.7 的区别在于：图 41 和图 42 的修改、表 5 的新增内容、主/从模式改为控制器/目标模式（与 I3C 类似），以及在第 9 章中新增了“I3C 概述”（详情请参见 Rev.1 中的表 1：修订历史）。由于这些差异不影响 I²C 规范的主要内容，因此日文版可作为参考。 1.2 控制器/目标 I²C 通信始终以主从关系进行。用于指代这些角色的术语分别是控制器和目标[图 1]。 图 1：控制器和目标 该规范允许多个控制器存在于一条 I²C 总线上。 旧规范中使用了“主/从”术语，但现在已改为“控制器/目标”。 2. 物理/电气特性 2.1 信号线数量：SDA、SCL I²C 是一种双线串行总线，一根线用于传输时钟信号，一根线用于传输数据信号。由于数据与时钟信号同步交换，因此它被归类为“同步串行接口”。 数据通信可以双向进行，但由于它通过单条数据线传输，因此无法同时进行，必须交替切换。正因如此，这种通信方式被称为半双工，而不是全双工，后者允许同时进行发送和接收。 时钟信号线和数据信号线分别称为SCL（串行时钟线）和SDA（串行数据线） 。 数据以比特为单位进行传输或接收，并与时钟周期同步。 2.2 开漏输出（线与门） I²C 的一个显著特点是使用一种称为“开漏”的方法来产生信号。 在许多通信应用中，使用一种称为推挽的方法来输出数字信号。推挽是一种当输出高电平信号时，在信号线上输出（推）特定电压，而输出低电平信号时，将信号线拉至地线（拉）的方法[图 2-a]。 开漏输出与“上拉”输出类似，都是输出低电平，但当输出高电平时，电路会进入高阻抗状态。在这种状态下，连接到信号线的上拉电阻可以确保获得指定的电压[图2-b]。 图 2-a：推挽输出 图 2-b：开漏输出 那么，为什么要采用这种输出方法呢？ 这是因为 I²C 允许多个设备同时输出到同一信号线。当多个设备处于输出状态时，即使只有一个设备输出低电平，信号也会变为低电平。 这种连接方式，即当所有设备输出高电平时信号为高电平，否则为低电平，称为“线与”[图 3]。 图 3：已接线并连接   I²C 具有名为“时钟拉伸”和“多控制器”的可选功能。这些功能允许连接到同一总线的多个设备同时输出，并使用开漏连接来管理它们的状态。 I²C 高电平电压在规范中没有明确定义。上拉电阻所连接的电源电压 (VDD) 因器件而异。通信时，必须使用连接器件之间通用的电压。在许多情况下，VDD 使用 5V 或 3.3V 等电压，但在 SoC 芯片和其他电压越来越低的器件中，有时会使用 1V 或更低的电压。I²C输入信号电压在 0.3VDD 或更低时设置为低电平，在 0.7VDD 或更高时设置为高电平，因此，当连接电压不同的 I²C 总线时，必须使用“信号电压转换器（ VLT ：电压电平转换器）”。要转换此信号电压，需要选择一个与 I²C 兼容的器件，并考虑到 I²C 信号是双向开漏信号。 使用 I²C 时，还必须考虑信号的模拟特性。这是指由于漏极开路而导致信号输出发生变化所需的时间。从高电平到低电平的下降时间很快，但从低电平到高的上升时间则可能很慢，具体取决于总线的状态。具体来说，随着连接设备数量的增加或信号线长度的增加，上升时间会变慢。这是因为信号线的电容增大了[图 4]。 每种模式都限制了允许的电容值，这决定了 I²C 时钟速度的上限。 图 4：电容和信号上升时间   2.3 时钟频率 I²C 根据可使用的最大时钟频率定义了“模式”[表 1]。 最基本的模式称为标准模式（ Sm ），工作频率低于 100kHz 。 其次是上限为 400kHz 的快速模式( Fm )。大多数控制器和目标设备都支持 Sm 和 Fm 模式。 还有快速模式增强版（ Fm+ ），其时钟速度可以低于 1MHz ，适用于数据速率高的应用。 此外，还有一种最高速度可达3.4MHz的高速模式（ HS 模式或Hs ）。这种高速模式有其特定的协议，用于切换到该速度进行通信，并且需要桥接器才能与其他模式混合通信。目前配备支持此模式控制器的设备并不多。 针对特殊应用，还规定了一种超高速模式。该模式的时钟频率上限为 5MHz，并且通信方向限制为从控制器到目标设备的单向通信，因此与其他模式不兼容。 当使用“I²C”而未提及模式时，通常指的是最常见的标准模式或快速模式，本博客也将基于这些模式。 模式 缩写 最大时钟频率 评论 标准模式 小 100kHz 最受欢迎的模式 一般来说，I²C 指的是最高兼容 400kHz 频率的 Fm 接口。 快速模式 调频 400kHz 第一模式+ FM+ 1MHz 规格参数包括更高的速度、电流消耗和母线容量 许多微控制器中都安装了具有这种功能的控制器。 高速模式 赫斯 3.4MHz 收养案例并不多。 兼容SM和FM。通过协议切换到HS模式。 在总线上混合使用 Sm 和 Fm 设备时需要桥接器。 超快模式 UFm 5MHz 只写加速模式 需配合专用控制器和目标设备使用。与其他 I²C 模式不兼容。 表1：各模式的频率和特征   2.4 连接拓扑 任何连接到 I²C 的设备都连接到两条信号线：SCL 和 SDA 。 这种连接方式称为“多点连接”。每个设备都通过两根导线“悬挂”连接[图5]。可连接的设备数量受“总线容量”的限制。信号线越长，连接的设备越多，总线容量就越大。 通信发生在“控制器”和“目标”之间。所有通信均由控制器发起。 在 I²C 中，控制器和目标之间每次传输都是一对一进行的。虽然可以有意地让多个目标拥有相同的地址，但从控制器的角度来看，只能“与一个地址通信”[图 6]。 控制器通过目标地址指定要通信的设备，并指示数据传输方向。 控制器控制所有传输（开始和结束、指定通信目标和传输方向以及向 SCL 输出时钟）。 也可以在同一条 I²C 总线上连接多个控制器。这可以通过使用名为“多控制器”的可选 I²C 功能来实现。 在这种配置下，一旦一个控制器完成数据传输，另一个控制器即可进行通信。此外，还建立了总线仲裁机制，以应对多个控制器同时开始传输数据的情况。 在多控制器配置中，所有连接的控制器都必须支持这种仲裁机制。 然而，采用多控制器配置的系统并不多见。虽然许多微控制器和其他设备内置的 I²C 控制器支持多控制器，但大多数简单的系统都使用单个控制器。 在本文中，我们将只考虑单个控制器的情况，以便解释 I²C 的基本原理。 图 5 ：多点连接   图 6：与单个目标地址的通信 3. 协议 3.1 必需功能和可选功能 该协议决定了数据传输方式。 I²C协议包含必需功能和可选功能。上一节提到的多控制器就是一个可选功能。如前所述，本文将不讨论可选功能，而只解释必需功能。 I²C 的必要功能和可选功能总结在[表 2]中。 表 2：I²C 功能。必需/可选（摘自 I²C 规范（日文版：rev5.0）） I²C 通信通常具有以下结构： 沟通开始 数据传输 沟通结束 作为此原理的应用，也可以在不先结束上一次通信的情况下开始下一次通信（重复开始）。 数据传输部分可以传输 1 字节到多个字节的数据。 传输开始后的第一个字节总是从控制器传输到目标，并指定目标地址和后续数据传输的方向（发送或接收） 。 I²C 规范对第二个字节之后可以传输的字节数没有施加任何特殊限制[图 7]。 在与同一目标通信时，如果需要在发送和接收数据之间切换；或者在与不同目标通信时，需要重新开始通信，并再次指定目标地址和传输方向。 图 7：I²C 通信的基本结构 3.2 数据传输单元 通信的基本单位是 9 位，其中 8 位是数据，后跟 1 位。数据为 8 位，最高有效位 (MSB) 在前。最后一位是确认位，它以与发送数据相反的方向返回，用于确认每次通信。在 I²C 中，数据传输始终以 9 位为单位进行 [图 8]。 数据以每个时钟周期发送或接收一位。 数据变化与时钟同步。SDA 只能在 SCL 为低电平时改变状态（从低电平变为高电平或从高电平变为低电平），并且在 SCL 为高电平时保持低电平或高电平[图 9]。 图 8：每次 8 位数据传输都会返回一个 1 位确认信息。   图 9：SCL 低时 SDA 信号的变化 3.3 公交车状态：换乘的开始和结束 通信的开始和结束分别由开始条件和停止条件通知，它们标志着传输的结束。 如前所述，“只有当 SCL 为低时才允许 SDA 更改”，但此启动/停止条件是一个例外。 当 SCL 为高电平时，如果 SDA 从高电平变为低电平，则为启动条件。类似地，当 SCL 为高电平时，如果 SCL 从低电平变为高电平，则为停止条件[图 10]。 图 10：启动和停止条件 在启动条件发出后，正在进行转账的状态称为“忙碌”；在停止条件发出后，没有正在进行转账的状态称为“空闲”。启动条件在空闲状态下发起。 控制器输出启动/停止条件和 SCL。 起始条件之后的 9 位传输用于指定目标地址和传输方向。 然后数据通过一次或多次连续的 9 位传输进行传输。 除了开始条件和停止条件之外，还定义了“重复开始条件”来分隔数据传输。 启动条件是公交车处于自由状态，但必须先满足停止条件，公交车才能进入自由状态。 如果控制器执行连续传输，则可以省略此停止条件。重复启动条件会直接启动下一次传输，而无需经过自由状态（图 11）。 图 11：重复起始条件   当在前一次传输中生成启动条件而未生成停止条件时，就会出现重复启动条件。重复启动条件在功能上与普通启动条件相同。除非另有明确说明，否则下文中的启动条件均指重复启动条件。 在多控制器环境中，提供重复启动条件是为了允许一个控制器在保持总线所有权的同时，连续执行多次传输操作。这是因为一旦总线空闲，另一个控制器就可以立即启动传输操作。通过保持总线繁忙状态而不使用停止条件，控制器可以维持总线的所有权。 从现在开始，为了方便起见，我们将把从（重复）开始条件到停止条件，或者从（重复）开始条件到下一个重复开始条件的单元称为“事务”。 3.4 交易结构 事务（图 12）总是以起始条件开始。起始条件之后，控制器发送的数据指定目标地址和传输方向。 图 12：基本 I2C 传输示例及波形（写入事务示例）   目标地址是7 位信息，用于指定要与之通信的设备。通信将与匹配此地址的设备进行（I²C 规范将“10 位寻址”定义为一个选项，但由于大多数情况下使用 7 位寻址，因此我们不再赘述）。 在7位地址之后，会发送一个指定传输方向（读/写）的位。如果该位为“0”，则表示从控制器到目标的写传输；如果该位为“1”，则表示从目标到控制器的读传输。 目标地址第七位之后的第九位加上一个读/写位是确认位。该位是目标端返回的低电平信号。 如果控制器输出的目标地址所指定的设备存在，则目标设备会向 SDA 输出低电平作为确认位。此时，控制器输出高电平，因此如果目标设备不存在，SDA 将保持高电平。换句话说，如果目标设备存在，则确认位为低电平；如果目标设备不存在，则确认位为高电平。当此确认位为低电平时，称为ACK （确认）；当其为高电平时，称为NACK （不确认）。 输出目标地址和传输方向，如果返回 ACK，则数据传输继续进行。如果目标地址不存在且返回 NACK，则事务到此结束（控制器发出停止条件或重复启动条件）。 如果数据传输方向为写，则接下来的 8 位数据从控制器传输到目标设备，然后目标设备向控制器发送 1 位确认位。 如果是读取传输，控制器会将 SDA 保持高电平，并与 SCL 同步读取目标输出的 8 位数据。此读取传输始终包含一个确认位。控制器会将附加在读取传输数据上的确认位输出。如果读取传输继续进行，则返回 ACK；如果传输要中止，则返回 NACK。 ACK/NACK 对 I²C 通信至关重要。这是因为 ACK 机制允许通信在持续检查对方状态的同时进行。当收到 NACK 时，通信即告终止。 根据 I²C 规范，NACK 发生的条件如下： 目标地址指定的设备在总线上不存在。 目标设备当前正在执行一些处理操作，不处于可以与控制器通信的状态，因此无法发送或接收数据。 目标设备无法理解传输过程中接收到的数据或命令。 传输过程中，目标设备无法接收更多数据字节。 在读取传输过程中，当控制器通知目标设备传输完成时 3.5 写入和读取事务 在单次事务中，数据传输方向是恒定的。因此，如果您向目标设备写入数据，然后再从中读取数据，则会发生连续的事务。 例如，当指定目标设备的寄存器号并从中读取数据时，可以先执行写入传输，然后再执行读取传输。 在这种类型的传输中，某些目标设备需要重复的启动条件来分隔事务，而另一些设备在重复启动条件的情况下可能无法按预期运行。这取决于目标设备的具体规格，因此您必须谨慎操作。 4. 参考资料 I2C 总线规范和用户手册（版本 5.0）日文版） I2C 总线规范和用户手册（版本 7.0）英文版） NXP社区博客：I²C硬件调试 NXP社区博客：I3C：下一代串行总线 NXP社区博客：SPI总线概述 Interface 2024 年 3 月刊（CQ Publishing） ：专题文章“从零开始的串行通信 [使用 Pico 进行 UART/I2C/SPI 通信]” 晶体管技术特刊第 161 期“测量、测量、测量电路与技术汇编”附录：“2 线串行接口 I²C 的详细说明”——以上杂志文章摘自该文章。 首次登场： 《晶体管技术》，2014年10月刊（CQ出版社），“基础知识：双线串行接口I²C的详细说明”，第152-176页 Interface Magazine，2024 年 3 月刊（CQ Publishing），“从零开始构建 I²C 和 SPI ②...I²C 通信标准”，第 55-61 页 ← 上述文章的更新和重新组织版本。 在这篇博文中，我摘录、补充并修改了解释通信规范的部分。 变更历史记录： 2025年2月3日：第一版 2025-02-04:“4.在“参考资料”部分添加了博文“I²C 硬件调试”。 2025 年 3 月 5 日：第 2.2 节 开漏输出（有线和嵌入式）更正了参考图号。 2025-11-30：更正了一处拼写错误。 2026-04-03：更正了原始条目。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） I²C 总线用于微控制器/处理器与外围设备之间的通信。 虽然这种串行总线应用非常广泛，但我还是想借此机会简要介绍一下它的起源。 通信标准 界面 日本博客

什么是电池管理系统（BMS）？（日文博客） 电动汽车普及的原因是什么？ 近年来，全球汽车行业正迅速向电动汽车转型。这不仅是一项技术创新，更是一项由多种因素复杂相互作用驱动的重大社会变革，其中包括： 环境因素：为应对全球变暖，需要减少二氧化碳排放。 电动汽车作为一种可持续的交通工具，因其在运行过程中不排放废气而备受关注。 政策支持：欧洲、中国和其他国家正在努力禁止销售汽油动力汽车。 此外，政府还出台了补贴等政策来促进电动汽车的购买，从而加速了电动汽车的普及。 技术进步：电池性能的提高正在改善电动汽车的续航里程和充电时间。 价格等障碍已经降低，使其成为普通消费者的现实选择。 在此背景下，如何安全管理电池并充分利用其便利性（这对电动汽车至关重要）的技术变得越来越重要。 什么是电池？ 电池决定了电动汽车的性能、安全性和使用寿命。 电动汽车电池通常由数十到数百个相互连接的电池单元组成。 电池单元的化学结构多种多样，但每个单元的电压通常约为 3V。 出于组装方便等原因，有时会将多个电池单元捆绑在一起形成一个模块，称为电池模块。 电池组是一种将电池模块、BMS（如下所述）、电缆等部件封装在一个外壳中的设备。 电动汽车电池的总电压范围从几百伏到有时超过 1000 伏不等。 什么是电池管理系统（BMS）？它的作用是保护电池。 电池管理系统 (BMS)是一种用于安全高效地使用电池的管理系统。 电池管理系统 (BMS) 是一个持续监控电池状态并检测和控制异常情况的装置，从而防止事故发生，维护安全，并最大限度地提高性能。 鉴于上述原因，对于电动汽车等使用的可充电高压电池，始终需要电池管理系统 (BMS)。 电动汽车等车辆使用的高压电池的电池管理系统 (BMS) 通常由多个模块组成，每个模块对电池都起着至关重要的作用。 在这里，我们将介绍恩智浦设想的三种典型组件。 CMU（细胞监测单元） CMU 是连接到电池模块上的一个单元，用于测量每个电池单元的电压和温度。 从安全角度来看，实时准确掌握每个电池单元的状态至关重要。该系统具有以下功能： 防止过充和过放 细胞平衡以实现所有细胞的有效利用 早期发现异常细胞 CMU 提供准确的数据，以提高电池的整体稳定性和使用寿命。 CMU 也称为电池管理单元、BCC（电池单元控制器）。 BJB（电池接线盒） BJB 是一种测量整个电池组电流和电压的装置，具有保护功能，可在发生异常情况时物理切断电流。 它包含高压继电器、熔断器、电流传感器等元件，具有以下功能： 过电流和短路检测 安全充电和放电控制 发生异常情况时可靠地中断电流 万一出现问题，BJB 可保护电池、整车以及最终车内人员的安全，从而确保安全。 BJB的另一个名称：电池组监控器（仅用于监控功能） 电池管理单元 (BMU) BMU 是控制整个 BMS 并为其做出决策的中央单元。 它整合来自CMU和BJB的数据，并根据上位机的指令分析和控制电池状态。它具有以下功能： 荷电状态 (SOC) 估算 健康状况 (SOH) 评估 与其他单元（例如车辆ECU和充电器）的通信 电池管理单元 (BMU) 及其控制是决定电动汽车行驶效率和安全性的重要因素。 恩智浦的电池管理系统解决方案 随着电动汽车的发展，电池管理系统（BMS）也需要高精度、高可靠性和高安全性。 恩智浦提供符合这些要求的实用BMS参考设计。 基于ETPL的800V电池管理系统（BMS）参考设计 *ETPL：电传输协议链路 功能安全设计符合 ASIL D 标准 可扩展配置，支持高达 800V 的电压 提供的软件驱动程序 以下文件概述了恩智浦在电气化领域所做的努力。 我们希望您能浏览并了解更多关于我们产品及其功能的信息。 恩智浦的电气化解决方案  这些材料对于计划设计电池管理系统的工程师来说是非常有用的解决方案。 =========================== 更改历史记录 2025年8月28日：博客文章 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） ​ 以下是电池管理系统（BMS）的概述。 电动汽车普及的原因是什么？ 什么是电池？ 什么是电池管理系统（BMS）？它的作用是保护电池。 恩智浦的电池管理系统解决方案 如果未来与BMS有业务往来的人能够读到这篇文章，我会很高兴。 （阅读时间：5分钟） 介绍 日本博客

TJA1103 硬件时间戳问题 我正在使用一台 MR-CANHUBK334，其中集成了一个 gPTP 堆栈，配置为从 TJA1103 的硬件时间戳模块获取时间戳。该节点被配置为 Gran Master。我的问题是，有时在入口/出口环形缓冲区上获取的时间戳与 PHY 用作时间戳参考的 LTC 计时器不一致。具体来说，每次收到信息时，从顶部缓冲区读取的时间有时会倒退，然后从那一刻起继续计数，但 LTC 始终是正确的。 这种情况是任意发生的，没有任何固定模式。有其他人遇到过这个问题吗？ Re: TJA1103 HW timestamp issue 你好@FabioDb、 你的问题非常具体。 如果 LTC 保持稳定和正确，但从 FIFO 或环形缓冲器获取的时间戳偶尔会向后跳，则问题可能不在 LTC 本身，而在时间戳获取或解释路径。 您能否分享您所做的所有 TJA1103 注册表设置（与 PPS 有关）？ 我已将您的问题转给应用团队作进一步调查。如果有任何进展，我会及时通知你们。 同时，请查看一般提示： 同时记录接收帧时的时间戳和 LTC 值。这将有助于确定不一致的原因是先进先出损坏、错位还是软件解释。 检查链路状态是否更改或 PHY RESET。如果 PHY 经历短暂的 RESET 或链路重新协商，则时间戳 FIFO 可能包含过时或无效的条目。 验证驱动程序或 HAL 中的时间戳读取逻辑。确保正确的字节序处理、位移，并且只有在完全锁存时间戳后才读取。 监测 FIFO 溢出或欠载情况。如果时间戳 FIFO 的耗尽速度不够快，旧条目可能会被覆盖或错位。 确认来自 S32K344 的 PPS_SYNC 信号稳定，并与 PHY 中的 LTC 更新周期正确对齐。任何抖动或错位都可能导致时间戳不一致。 确保 gPTP 协议栈正确处理时间戳偏移，不会根据对 PHY 行为的假设应用错误的修正。 顺祝商祺！ 帕维尔

imx8mp OpenGL 无显示 有没有办法让 OpenGL 在无头模式下运行（不连接显示器）？ 我正在使用基于 fsl-xwayland 映像的 imx8mp。我知道 PGU 等设备在我的设备树中配置正确，因为连接后就能正常显示。如果我尝试像这样运行一个简单的 gstreamer 管道： gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12,width=1920,height=1080 ! queue ! glupload ! glcolorconvert ! gldownload ! video/x-raw,format=RGB ! queue ! fakesink 我收到以下错误信息 Got context from element 'gldownloadelement0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0"; ERROR: from element /GstPipeline:pipeline0/GstGLUploadElement:gluploadelement0: Failed to perform a wayland roundtrip 我的系统安装为通过 SSH 使用 remote-x 服务器，但即便如此，我也一无所获。 有没有什么 XDG 变量可以设置？ 图形与显示 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux 多媒体 Yocto Project Re: imx8mp OpenGL without display 所以，我要回答我自己的问题，供其他来这里的人参考： 我可以通过以下方法让 GPU 工作并执行 gstreamer glupload/glshader 等命令： - 为虚拟显示器加载 VKMS 内核模块 - 在 westom.ini 中设置 renderer=gl 并禁用"g2d" 。 经过这些设置后，WESTON 启动了，我也有了 opngl 命令。 有趣的是，我验证了 OpenCL 在 weston 离线时也能正常工作。遗憾的是，与普通矩阵相比，OpenCV 中使用 UMat 和 T-API 的性能并没有提高。它似乎确实比简单的逐元素乘法快得多，例如在 C 中，所以这可能要归因于 OpenCV 中的 Arm-neon 加速。 Re: imx8mp OpenGL without display 谢谢 ugurkur，但这似乎没什么用。 如果我检查 `echo $XDG_RUNTIME_DIR` ，会得到"/run/user/0" ，所以看起来没问题。 根据我的清单，我有你提到的所有代码包。但我仍然无法让 OpenGL 正常工作。 Re: imx8mp OpenGL without display 你好，我在 i.MX8M 板上遇到了同样的问题。对我有用的是将 weston、weston-init 和 weston-xwayland 代码包添加到我的 Yocto 图像中，这完全解决了显示错误。此外，我还使用以下命令设置了 XDG_RUNTIME_DIR 环境变量： export XDG_RUNTIME_DIR=/run/user/$( id -u) 希望这也能帮助您解决问题！ Re: imx8mp OpenGL without display 那么，它们能教给我们什么吗？您还有什么其他想法，可能是什么原因导致了这个问题？ Re: imx8mp OpenGL without display 这不是错误，你的系统应该在无显示的情况下运行。 此致 Re: imx8mp OpenGL without display 我得到以下信息 WARNING: erroneous pipeline: could not link videotestsrc0 to xvimagesink0, neither element can handle caps video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080 我是否漏掉了内核配置？ Re: imx8mp OpenGL without display 你好 请再试一次： $ DISPLAY=:0 gst-用上市，不用发布-1.0videotestsrc ！video/x-raw(memory:NVMM),width=1920,height=1080, 'video/x-raw,width=1920,height=1080 ！xvimagesink sync=0 此致