S32K311 HSEファームウェアのフラッシュアルゴリズムとライフサイクルアンロックの照会（P&E Cyclone FXを使用） 現在、S32K311 MCUを使ったプロジェクトを進めています。お客様はHseLib_HseFwInstall_Driver.hexとapp.hexを提供しており、私たちはP&E Cyclone FXプログラマーを使用しています。NXPの専門家に、新しいMCUのアルゴリズム選択の確認をお願いしたいと思います。 1. HseLib_HseFwInstall_Driver.hexを新しいMCU(nxp_s32k311-1x32x212k_hse_enabled.arpまたはnxp_s32k311-1x32x212k_hse_disabled.arp)にフラッシュする際、どのアルゴリズムを使うべきか? 2. HSEドライバーの書き込み後にどのアルゴリズムを選択するべきか? 3. HSEドライバーが正常にインストールされているかどうかはどうやって確認できますか? 4. MCUのライフサイクルがロックされているなら、どうやって解除できるのか? 事前に感謝いたします。 Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) ハイ 名前の HseLib_HseFwInstall_Driverから、中国の お客様のようで、中国FAEが提供する HSE_Lib デモを参照しています。 A1. nxp_s32k311-1x32x212k_hse_disabled.arp A2.お客様が設置したHSEのFWが、そのものがFULL_MEMか、AB_SWAPかをお客様に確認することをお勧めします。 FULL_MEMをインストールする場合は、nxp_s32k311_1x32x212k_hse_enabled.arpを選択してください。 AB_SWAPをインストールする場合は、nxp_s32k311_1x32x168k_ab_swap.arpを選択してください。 A3. 0x4039C028 の HSE GPR レジスタを確認してください。ビット「0」は、HSEファームウェアがインストールされているかどうかを示します。 A4。LifeCycleがどの段階まで進んでいるのか、私にはよく分かりません。デ バッグアクセスについて質問されているなら、Rev12の「82.11 Debug across device LifeCycles」を参照S32K3XXRMことをお勧めします。 信頼:認証が成功した場合(正しい認証情報でチャレンジ/レスポンスハンドシェイク) 関連項目: ...\s32k3_hse_lib_rtd400hf01_20260427\Doc\S32K3_SecureDebug_UserGuide.pdf この書類は中国のFAEまたはお客様のところから入手する必要があります。 NXP オートモーティブ S32K311-SECUREDEBUGがサポートされています! NXP:PEmicroツールを使ったS32K3xxセキュアデバッグサポートの有効化 よろしくお願いいたします ロビン Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) 私はP&E Cyclone FXに詳しくないので、 S32K3 HSEのファームウェアインストールに関する議論を参照することをお勧めします。 0x4039C028=0xC1、ビット1=1は、HSE FWが正常に動作していることを示します。 Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) こんにちは、ロビンさん。 ご協力ありがとうございます。 さらに、以下の図に示すプログラミング手順に従って、HSEイメージを設定しました（外部電源とプログラマーリレーを使用）。 フラッシュ後、アドレスでMCUから実際に読み取られるデータは以下の通りです。 ADDRESS content.PNGアドレスコンテンツ.PNG 何か問題がないか、もう一度確認してもらえますか?ありがとう。

PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) Hi everyone, I am currently integrating the PCA2131 Automotive RTC into a Battery Management System (BMS) and experiencing an inconsistent issue with the periodic interrupt generation. Issue Description: We are trying to generate an interrupt at a defined interval (e.g., every X minutes). The core problem is that the behavior is highly erratic: Sometimes, the interrupt triggers exactly as expected. Sometimes, the counter appears to run approximately 4x faster than it should. Sometimes, the interrupt is missed entirely. Because this issue occurs randomly, we are struggling to isolate the root cause. Testing & Observations: Hardware: We have tested 3–4 different RTC samples, and this abnormal behavior has been observed across multiple units. Clock Configurations: We evaluated the default 32.768 kHz clock, as well as the 16 kHz and 8 kHz configurations. Interrupt Intervals: Tested with 1-minute, 2-minute, and 5-minute intervals. Result: The timing instability persists across these variations. Request: For reference, I have attached our schematic and the captured waveforms. Could you please review the attachments and help us understand what could be causing this? We would appreciate any insight into specific register configurations, known errata, or noise/hardware conditions that could lead to this intermittent timing instability. Thanks in advance for your support. rtc Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) Hello! Could you please check the following points? The MSF flag (bit 7 of Control_2, address 01h) must be explicitly cleared after every interrupt.  Always write 0 to MSF (bit 7 of Control_2) in your ISR. Use the AND-write method described in Section 7.11.5 of the datasheet (write 0 to clear, 1 to leave unchanged) If both MI (bit 1) and SI (bit 0) of Control_1 are set, the result is an interrupt once per second not once per minute. Set only MI = 1, SI = 0 in Control_1 for a periodic minute interrupt. Read back the register to confirm. Please let me know the result. Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) Hello, The writes that disable the alarm comparators by setting AEN_x = 1 are commented out, please uncomment all five lines. These writes must execute before re-arming the next alarm. In the alarm trigger screenshot, the raw register value ctrl2.w = 18 (0x12 = 0001 0010 binary) correctly shows: Bit 4 = 1 → AF (Alarm Flag) is SET Bit 1 = 1 → AIE (Alarm Interrupt Enable) is SET However, the struct field ctrl2.b.af is displayed as 0 in the debugger. This means your C bitfield struct definition for Control_2 does not correctly map the af field to bit 4. If any part of the firmware branches on ctrl2.b.af instead of the hardware interrupt line or RTC_ALarm_Flag software variable, it will fail to detect the alarm and miss interrupts entirely  explaining the missed interrupt symptom. Please verify and correct the bitfield definition of your Control_2 register struct. The af field must be declared at bit position 4. Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) I Checked as you suggested me. For that I take screenshot of CTRL_REG_1 and CTRL_REG_2 when alarm trigger and after alarm clear. Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) Hello ErikaC, Thanks for the review. I have uncommented the five lines for AEN_x as requested. I verified the bitfield definition, and it is correct. In the 'alarm trigger' image, the ctrl2.b.af bit successfully sets to 1. In the 'alarm clear' image, it resets to 0. The bitfield is behaving exactly as expected. Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) Waiting for your reply or can we take this discussion over the mail. My email id: - [email protected]

关于支持锁步模式的 Cortex-A53 SoC 的咨询 尊敬的恩智浦技术支持人员： 我们目前正在寻找符合以下要求的SoC： Arm Cortex-A53处理器 支持 Cortex-A53 内核/集群之间的同步操作 适用于非汽车应用，例如工业应用 一款目前可供购买的评估/开发板 一份参考手册或其他官方文档，解释如何启用/配置锁定步进模式。 我们最初考虑过 S32G2，但由于 S32G 系列主要面向汽车/车辆应用，我们想知道 NXP 是否有其他 SoC 符合上述要求。 例如，我们也在关注采用 Cortex-A53 的 i.MX 8M Mini / i.MX 8M Plus。然而，根据现有文档，我们尚无法确认它们是否支持 Cortex-A53 锁步操作。 请问您能否推荐一些符合这些要求的恩智浦SoC和评估板？ 尤其感谢您能提供以下信息： SoC部件号 目前可供购买的评估板 参考手册中描述 Cortex-A53 锁步功能的章节/页码 是否有任何文档或示例说明如何启用/配置锁定模式 感谢您的支持。 Re: Inquiry about Cortex-A53 SoC supporting lockstep mode 你好，Toan 感谢您的回复和提供的信息。 对于您需要的 Cortex-A53 硬件上的 Lockstep 功能，目前只有 S32G 产品实现了此功能。 关于 Cortex-M/R 的 Lockstep 功能，您可以关注 S32K/S32Z/E 等产品，但这些产品也主要用于汽车应用。 BR 乔伊 Re: Inquiry about Cortex-A53 SoC supporting lockstep mode 嗨，乔伊， 谢谢你的解释！ 关于您的问题，我们目前正处于根据我们的需求收集和调查技术信息的初始阶段，因此详细的项目背景尚未完全确定。不过，我可以分享一些关于我们发展方向的关键见解： 应用场景：我们正在探索通用工业/嵌入式系统的解决方案，而不是纯粹的汽车应用。虽然 S32G 是一个功能强大的平台，但它对汽车领域的强烈关注促使我们寻找更通用的处理器/MCU，以适应更广泛的非汽车产品。 锁定要求：是的，我们对锁定功能的兴趣源于我们系统设计中对高可靠性、故障检测和功能安全/检查机制的需求，以确保整体稳定性。 由于我们正在积极寻找替代方案，您能否推荐一些其他支持硬件锁步但更适合通用工业应用而非汽车应用的通用平台（MCU/SoC）？ 再次感谢您的支持！ 顺祝商祺！ 托安 Re: Inquiry about Cortex-A53 SoC supporting lockstep mode 你好， Toan 感谢您的支持！ 是的，S32G 支持锁步功能，主要用于汽车领域。一些客户也将其应用于航空航天和其他领域。 您能提供更多信息吗？ 1. 您的项目应用场景是什么？ 2. 为什么需要同步进行？是为了符合功能安全标准吗？ BR 乔伊

S32K311 HSE固件刷写算法及生命周期解锁查询（使用P&E Cyclone FX） 我们目前正在进行一个使用 S32K311 MCU 的项目。客户提供了 HseLib_HseFwInstall_Driver.hex 和 app.hex，我们使用的是 P&E Cyclone FX 编程器。我们想请恩智浦半导体的专家帮忙确认一款全新MCU的算法选择： 1. 将 HseLib_HseFwInstall_Driver.hex 烧录到全新的 MCU（nxp_s32k311-1x32x212k_hse_enabled.arp 或 nxp_s32k311-1x32x212k_hse_disabled.arp）时，应该使用哪种算法？ 2. HSE驱动程序刷写完成后应该选择哪种算法？ 3. 如何确认 HSE 驱动程序是否成功安装？ 4. 如果MCU的生命周期被锁定，如何才能解锁？ 提前谢谢您。 Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) HI 根据名称HseLib _HseFwInstall_Driver 来看，它似乎是一家中国客户，并引用了中国 FAE 提供的HSE_Lib演示。 A1. nxp_s32k311-1x32x212k_hse_disabled.arp A2.我建议您询问客户他们安装的 HSE 固件是 FULL_MEM 还是 AB_SWAP。 如果您要安装 FULL_MEM，请选择 nxp_s32k311_1x32x212k_hse_enabled.arp。 如果您要安装 AB_SWAP，请选择 nxp_s32k311_1x32x168k_ab_swap.arp。 A3. 检查 HSE GPR 寄存器，地址为 0x4039C028。位“0”表示是否已安装 HSE 固件。 A4。我不确定生命周期已经发展到哪个阶段了。如果您询问有关调试访问的问题，我建议您参考 S32K3XXRM Rev12 中的“ 82.11 跨设备生命周期的调试”。 可信：成功认证后（使用正确的凭据进行质询/响应握手）即可进行调试。 参见： ...\s32k3_hse_lib_rtd400hf01_20260427\Doc\ S32K3_SecureDebug_UserGuide.pdf此文档需要从中国 FAE 或您的客户处获取。 支持 NXP Automotive S32K311-SECUREDEBUG！ 恩智浦：使用 PEmicro 工具实现 S32K3xx 安全调试支持 此致敬礼， Robin Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) 我不熟悉 P&E Cyclone FX，所以我建议参考S32K3 HSE 固件安装问题中的讨论。 0x4039C028=0xC1，Bit1=1，表示 HSE 固件运行正常。 Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) 你好，罗宾， 感谢您的帮助。 此外，我按照下图所示的编程顺序设置了 HSE 镜像（使用外部电源 + 编程继电器）。 刷写固件后，从MCU读取到的地址处的实际数据如下。 ADDRESS content.PNG地址内容.PNG 请您帮我再确认一下有没有什么问题？谢谢。

IMX93 - Boot Cortex-M33 with Barebox Dear support team, We are designing our custom board with an IMX9332C. We chose not to use U-Boot as our bootloader, but Barebox instead, so sadly we cannot benefit from the work already done in uboot-imx. Our boot chain is as follows: TF-A → Barebox → Linux. Versions: imx-atf lf-6.18.20-2.0.0, Barebox 2025.09.0 (custom board port), Linux 6.18.13. We want to use the Cortex-M33 auxiliary core for our real-time-constrained features. The idea is to compile bare-metal code with the SDK, then load the resulting binary via the remoteproc framework from Linux. I wrote and compiled a very simple C program that blinks an IO. When I load it with remoteproc, the framework reports that it has been loaded, but it does absolutely nothing. Whenever I stop it, it crashes. My first guess was that the core wasn't correctly configured, so I dug into how u-boot prepares the M33 on NXP's FRDM reference board. I found that the M33 core has to be "prepared": its RAM must be zeroized, the watchdog configured, the TCM set up, etc. I ported some of these operations into my low-level initialization code in Barebox, but now when I load the code with remoteproc, it resets instantly. At this point, I looked at the SRSR register to find the root cause of the reset, and the M33_REQ bit is set. Looking at the documentation, this means a reset was requested by the Cortex-M33 itself. I currently have no idea why this reset request is emitted; it isn't triggered anywhere in my own code. Here are my questions: Is there any documentation on the full requirements for "preparing" the M33? What are the possible sources of a CM33_REQUEST reset ? Where could this come from? Thank you. Re: IMX93 - Boot Cortex-M33 with Barebox Hello @jlablanche  I hope you are doing very well.     Unfortunately, we do not support the Barebox Bootloader in our platforms.   But you can take as started point the chapter 4.7.4.1.4  i.MX 93 and  i.MX 93W from the i.MX Linux User's Guide:   image.pngimage.png   Here you can take a look to the prepare_mcore.       Regarding to the CM33_REQUEST in SRSR.   This can be because of the WDOG1 timeout.   If your Barebox init code enabled WDOG1 but your bare-metal firmware does not service it in time, the watchdog expires and asserts SYSRESETREQ.       Best regards, Salas.

IMX93 - 使用 Barebox 启动 Cortex-M33 尊敬的技术支持团队： 我们正在设计一款采用 IMX9332C 的定制电路板。 我们选择不使用 U-Boot 作为引导加载程序，而是使用 Barebox，因此很遗憾，我们无法受益于 uboot-imx 中已经完成的工作。我们的启动链如下：TF-A → Barebox → Linux。 版本：imx-atf lf-6.18.20-2.0.0Barebox 2025.09.0（自定义板端口），Linux 6.18.13。 我们希望使用 Cortex-M33 辅助内核来实现对实时性要求较高的功能。其思路是使用 SDK 编译裸机代码，然后通过 remoteproc 框架从 Linux 加载生成的二进制文件。 我编写并编译了一个非常简单的 C 程序，它可以使 I/O 闪烁。当我使用 remoteproc 加载它时，框架报告说它已经加载，但它却什么也没做。每次我停止它，它就会崩溃。 我首先猜测是核心配置不正确，所以我深入研究了 u-boot 如何在 NXP 的 FRDM 参考板上准备 M33。我发现 M33 内核必须进行“准备”：其 RAM 必须清零，看门狗必须配置，TCM 必须设置等等。我将其中一些操作移植到了 Barebox 的底层初始化代码中，但现在当我使用 remoteproc 加载代码时，它会立即重置。 此时，我查看了 SRSR 寄存器以找出 RESET 的根本原因，发现 M33_REQ 位已设置。 查看文档可知，这意味着 Cortex-M33 本身请求了重置。 我目前完全不知道为什么会发出这个RESET请求；它并没有在我的代码中被触发。 我的问题如下： 是否有关于“准备”M33的全部要求的文档？ CM33_REQUEST RESET 的可能原因有哪些？这究竟是从哪里来的？ 谢谢。 Re: IMX93 - Boot Cortex-M33 with Barebox 你好@jlablanche 希望你一切都好。     遗憾的是，我们的平台不支持 Barebox Bootloader。   但 你 能 拿 作为 开始 观点 这 章 4.7.4.1.4 i.MX 93 和i.MX 93W 从 这 i.MX Linux 用户指南：   image.pngimage.png   您可以在这里查看…… prepare_mcore 。       关于 SRSR 中的 CM33_REQUEST。   这可能是由于 WDOG1 超时导致的。   如果您的 Barebox 初始化代码启用了 WDOG1，但您的裸机固件没有及时处理它，则看门狗超时并发出 SYSRESETREQ 指令。       顺祝商祺！ 萨拉斯。

Inquiry about Cortex-A53 SoC supporting lockstep mode Dear NXP technical supporter, We are currently looking for a SoC with the following requirements: Arm Cortex-A53 processor Support for lockstep operation between Cortex-A53 cores / cluster Intended for non-automotive applications, such as industrial applications An evaluation/development board that is currently available for purchase A Reference Manual or other official documentation that explains how to enable/configure the lockstep mode We initially considered the S32G2, but since the S32G family is primarily positioned for automotive/vehicle applications, we would like to know whether NXP has any other SoCs that meet the above requirements. For example, we are also looking at the i.MX 8M Mini / i.MX 8M Plus, which use Cortex-A53. However, we have not been able to confirm whether they support Cortex-A53 lockstep operation from the available documentation. Could you please recommend any suitable NXP SoC(s) and evaluation board(s) that meet these requirements? In particular, we would appreciate it if you could provide: The SoC part number The evaluation board currently available for purchase The section/page in the Reference Manual describing the Cortex-A53 lockstep function Any documentation or example showing how to enable/configure lockstep mode Thank you for your support. Re: Inquiry about Cortex-A53 SoC supporting lockstep mode Hi,Toan Thank you for your reply and information. For the Lockstep feature on the Cortex-A53 hardware that you require, currently only the S32G product have achieved this capability. Regarding the Lockstep function of Cortex-M/R, you can focus on products such as S32K/S32Z/E, but these are also mainly for automotive applications. BR Joey Re: Inquiry about Cortex-A53 SoC supporting lockstep mode Hi Joey, Thank you for the clarification! Regarding your questions, we are currently in the initial phase of gathering and surveying technical information based on our requirements, so the detailed project context is not fully defined yet. However, I can share a few key insights on our direction: Application Scenario: We are exploring solutions for general industrial/embedded systems rather than purely automotive applications. While S32G is a powerful platform, its strong automotive focus makes us look for a more general-purpose processor/MCU that fits a broader scope of non-automotive products. Lockstep Requirement: Yes, our interest in the lockstep feature stems from the need for high reliability, fault detection, and safety/checking mechanisms in our system design to ensure overall stability. Since we are actively looking for alternatives, could you recommend any other general-purpose platforms (MCUs/SoCs) that support hardware Lockstep but are better suited for general industrial applications rather than automotive? Thanks again for your support! Best regards, Toan Re: Inquiry about Cortex-A53 SoC supporting lockstep mode Hi,Toan Thank you for your support! Yes, the S32G supports lockstep function, which is mainly used in the automotive. Some customers have also applied it in aerospace and other fields. Could you share more information with me? 1.What is the application scenario of your project? 2.Why is lockstep necessary? Is it to meet safety standards? BR Joey

IMX93 - Boot Cortex-M33 ベアボックス搭載 サポートチームの皆様へ、 当社では、IMX9332Cを搭載したカスタム基板を設計しています。 私たちはU-Bootをブートローダーとして使わず、代わりにBareboxを選んだため、残念ながらuboot-imxで既に行われた作業の恩恵を受けることができません。私たちのブートチェーンは以下の通りです:TF-A → Barebox → Linux。 バージョン: imx-atf lf-6.18.20-2.0.0、ベアボックス 2025.09.0(カスタムボードポート)、Linux 6.18.13。 リアルタイム制約機能にはCortex-M33の補助コアを使いたいと考えています。アイデアは、SDKでベアメタルコードをコンパイルし、Linuxのremoteprocフレームワークを通じて得られたバイナリを読み込むことです。 私は入出力デバイスを点滅させる非常にシンプルなC言語プログラムを作成し、コンパイルしました。remoteprocを使って読み込むと、フレームワークは読み込まれたと報告するのですが、実際には何も起こりません。停止しようとすると必ずクラッシュします。 最初はコアの設定が正しくなかったのではないかと思い、NXPのFRDMリファレンスボードでU-bootがM33をどう準備しているかを調べました。M33コアは「準備」する必要があることがわかりました。つまり、RAMをゼロにし、ウォッチドッグを設定し、TCMをセットアップするなどです。これらの操作の一部をBareboxの低レベル初期化コードに移植しましたが、remoteprocでコードをロードすると、すぐにリセットされてしまいます。 この時点で、リセットの根本原因を突き止めるためにSRSRレジスタを確認したところ、M33_REQビットが設定されていました。 ドキュメントを見ると、これはCortex-M33自体からリセットが要請されたことを意味します。 なぜこのリセットリクエストが出るのか、今のところ全く分かりません。自分のコードのどこにもトリガーされていません。 私の質問は以下のとおりです。 M33の「準備」に関する完全な要件に関するドキュメントはありますか? CM33_REQUESTリセットの可能な原因は何でしょうか?これはどこから来たのでしょうか? ありがとう。 Re: IMX93 - Boot Cortex-M33 with Barebox こんにちは、 @jlablancheさん お元気でお過ごしのことと思います。     残念ながら、当プラットフォームではBareboxブートローダーをサポートしていません。   しかし あなたは 取れ ない as started point the chapter 4.7.4.1.4 i.MX 93 および i.MX 93W from the i.MX Linuxユーザーガイド:   image.pngimage.png   ここで、 prepare_mcoreをご覧ください。       SRSRにおけるCM33_REQUESTに関して。   これはWDOG1のタイムアウトが原因かもしれません。   Barebox の初期化コードで WDOG1 が有効になっているにもかかわらず、ベアメタル ファームウェアが時間内にそれを処理しない場合、ウォッチドッグは期限切れになり、SYSRESETREQ がアサートされます。       よろしくお願いいたします。 サラス。

PCA2131 RTC：断続的な周期割り込み（欠落または4倍の速度で動作） こんにちは、皆さん 現在、 PCA2131 オートモーティブ RTC をバッテリー管理システム(BMS)に統合しているところで、周期的な中断発生に不安定な問題が発生しています。 問題の説明：定義された間隔（例：X分ごと）で割り込みを発生させようとしています。根本的な問題は、その動作が非常に不安定であることだ。 場合によっては、割り込みが期待どおりに発生する。 時々 、カウンターが本来の速度の約4倍の速さで動作しているように見えることがあります。 場合によっては、割り込みが完全に無視されることがあります。 この問題はランダムに発生するため、根本原因の特定に苦慮しています。 テストと観察結果： ハードウェア： 3～4種類の異なるRTCサンプルをテストしましたが、この異常な動作は複数のユニットで確認されています。 クロック構成：デフォルトの32.768kHzクロックに加え、16kHzおよび8kHzの構成についても評価しました。 割り込み間隔： 1分、2分、5分の間隔でテストしました。 結果：タイミングの不安定性は、これらのバリエーション全体にわたって持続する。 依頼：参考までに、回路図と取得した波形を添付しました。 添付ファイルを確認して、何が原因なのか理解する手助けをしていただけますか?この断続的なタイミング不安定性の原因となる特定のレジスタ構成、既知のエラッタ、ノイズやハードウェアの状態についてのご意見をいただけるとありがたいです。 サポートありがとうございます。 RTC Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) こんにちは！ 以下の点を確認していただけますか? MSFフラグ（Control_2のビット7、アドレス01h）は、割り込みが発生するたびに明示的にクリアする必要があります。 ISR内では、必ずMSF（Control_2の7番目のビット）に0を書き込みます。データシートの7.11.5節に記載されているAND書き込みメソッド(0を書き込むとクリア、1を書き残す)を使います。 Control_1のMI（ビット1）とSI（ビット0）の両方が設定されている場合、結果として割り込みは1分に1回ではなく、1秒に1回発生します。 定期的な1分間隔の割り込みを行うには、Control_1でMI = 1、SI = 0のみを設定してください。確認のため、登録簿を読み返してください。 結果を教えてください。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) ご指示いただいた通りに確認しました。そのため、アラームが作動した時とアラームが解除された後に、CTRL_REG_1とCTRL_REG_2のスクリーンショットを撮ります。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) こんにちは、 AEN_x = 1に設定してアラームコンパレータを無効化する書き込みはコメントアウトされます。5行すべてコメントを解除してください。これらの書き込みは、次の警報を再作動させる前に実行されなければなりません。 アラームトリガーのスクリーンショットでは、生のレジスタ値 ctrl2.w= 18 (0x12 = 0001 0010 バイナリ) は正しく以下を表示します: ビット4 = 1 → AF(アラームフラグ)がセットされる ビット1 = 1 → AIE（アラーム割り込みイネーブル）がセットされます しかし、構造体フィールド ctrl2.b.af はデバッガで 0 と表示されます。つまり、Control_2のCビットフィールド構造体定義では、AFフィールドをビット4に正しくマッピングしていないということです。もしファームウェアのどこかがハードウェア割り込みラインRTC_ALarm_Flagやソフトウェア変数の代わりに ctrl2.b.af に分岐すると、アラームを検出できず、割り込みを見逃すことが完全に説明されます。これが割り込みの欠如症状の説明になります。 Control_2レジスタ構造体のビットフィールド定義を確認し、修正してください。afフィールドはビット位置4で宣言しなければなりません。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) こんにちは、 ErikaC さん、 レビューありがとうございます。 ご要望どおり、AEN_xに関する5行のコメントを解除しました。 ビットフィールドの定義を確認しましたが、正しいです。「アラームトリガー」画像では、ctrl2.b.af ビットが正常に 1 に設定されます。「アラーム解除」画像では、0にリセットされます。ビットフィールドは期待どおりに動作しています。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 返信を待っていますか、それともこの話は郵送で進めましょうか? 私のメールアドレス：- [email protected]

S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) We currently have a project using the S32K311 MCU. The customer has provided HseLib_HseFwInstall_Driver.hex and app.hex, and we are using a P&E Cyclone FX programmer. We would like to ask the NXP experts to help confirm the algorithm selection for a brand-new MCU: 1. Which algorithm should be used when flashing the HseLib_HseFwInstall_Driver.hex onto a brand-new MCU(nxp_s32k311-1x32x212k_hse_enabled.arp or nxp_s32k311-1x32x212k_hse_disabled.arp)? 2. Which algorithm should be selected after the HSE driver is flashed? 3. How can we confirm if the HSE driver is successfully installed? 4. If the MCU's lifecycle is locked, how can it be unlocked? Thank you in advance. Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) Hi Based on the name HseLib_HseFwInstall_Driver, it appears to be a Chinese customer and references the HSE_Lib demo provided by China FAE. A1. nxp_s32k311-1x32x212k_hse_disabled.arp A2. I suggest you ask the customer whether the HSE FW they installed is FULL_MEM or AB_SWAP. If you are installing FULL_MEM, select nxp_s32k311_1x32x212k_hse_enabled.arp. If you are installing AB_SWAP, select nxp_s32k311_1x32x168k_ab_swap.arp. A3. Check HSE GPR register at 0x4039C028. Bit '0' says if HSE firmware is installed or not. A4. I'm not sure which stage LifeCycle has advanced to. If you're asking about debug access, I suggest you refer to "82.11 Debug across device LifeCycles" in S32K3XXRM Rev12.  Trusted: Debug is possible after successful authentication (Challenge/Response handshake with correct credentials) See also: ...\s32k3_hse_lib_rtd400hf01_20260427\Doc\S32K3_SecureDebug_UserGuide.pdf This document needs to be obtained from China FAE or your customer. NXP Automotive S32K311-SECUREDEBUG is supported! NXP: Using PEmicro Tools to Enable S32K3xx Secure Debug Support Best Regards, Robin Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) I'm not familiar with P&E Cyclone FX, so I suggest referring to the discussion in the S32K3 HSE firmware installation issues. 0x4039C028=0xC1, Bit1=1, indicates that the HSE FW is running normally. Re: S32K311 HSE Firmware Flashing Algorithm and Lifecycle Unlock Inquiry (Using P&E Cyclone FX) Hello Robin, Thank you for your help. Additionally, I followed the programming sequence in the diagram below to set up the HSE image (using external power supply + programmer relay). After flashing, the actual data read from the MCU at the address is as follows.  ADDRESS content.PNGADDRESS content.PNG  Could you please help me double-check if there's anything wrong?  Thanks.

PCA2131 RTC：间歇性周期性中断（丢失或运行速度快4倍） 大家好， 我目前正在将PCA2131 汽车实时时钟集成到电池管理系统 (BMS) 中，但遇到了周期性中断生成不稳定的问题。 问题描述：我们尝试按规定的时间间隔（例如，每 X 分钟）生成中断。核心问题在于这种行为极不稳定： 有时，中断会按预期触发信号。 有时，计数器似乎运行速度比正常速度快大约 4 倍。 有时，中断会被完全忽略。 由于这个问题是随机发生的，我们很难找出根本原因。 测试与观察： 硬件：我们测试了 3-4 个不同的 RTC 样品，并在多个单元中观察到了这种异常行为。 时钟配置：我们评估了默认的 32.768 kHz 时钟，以及 16 kHz 和 8 kHz 配置。 中断间隔：分别以 1 分钟、2 分钟和 5 分钟的间隔进行测试。 结果：在这些变化中，时间不稳定性依然存在。 请求：我已附上原理图和捕获的波形图供您参考。 请您查看附件，并帮助我们了解可能是什么原因导致这种情况？我们非常希望了解具体的寄存器配置、已知的错误或可能导致这种间歇性时序不稳定的噪声/硬件条件。 感谢您的支持。 RTC Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 您好！ 请您核对以下几点？ 每次中断后，必须显式清除 MSF 标志（Control_2 的第 7 位，地址 01h）。 在你的中断服务例程 (ISR) 中，始终向 MSF（Control_2 的第 7 位）写入 0。使用数据手册第 7.11.5 节中描述的 AND 写入方法（写入 0 清除，写入 1 保持不变）。 如果 Control_1 的 MI（位 1）和 SI（位 0）都设置了，则结果是每秒发生一次中断，而不是每分钟发生一次中断。 仅将 Control_1 中的 MI = 1、SI = 0 设置为周期性分钟中断。查阅登记簿以确认。 请告知结果。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 你好， 通过设置 AEN_x = 1 来禁用警报比较器的写入操作已被注释掉，请取消注释所有五行。这些写入操作必须在重新启动下一个警报之前执行。 在报警触发截图中，原始寄存器值 ctrl2.w= 18（0x12 = 0001 0010 二进制）正确显示： 位 4 = 1 → AF（报警标志）被设置 位 1 = 1 → AIE（报警中断使能）已设置 但是，在调试器中，结构体字段 ctrl2.b.af 显示为 0。这意味着您为 Control_2 定义的 C 位域结构体没有正确地将 af 字段映射到第 4 位。如果固件的任何部分在 ctrl2.b.af 而不是硬件中断线或 RTC_ALarm_Flag 软件变量上进行分支，则它将无法检测到警报并完全丢失中断，从而解释了丢失中断的症状。 请检查并更正 Control_2 寄存器结构的位域定义。af 字段必须在第 4 位位置声明。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 我按照你的建议检查过了。为此，我在报警触发时和报警清除后分别截取 CTRL_REG_1 和 CTRL_REG_2 的屏幕截图。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 你好ErikaC ， 感谢您的评价。 我已经按要求取消了 AEN_x 的五行代码的注释。 我已验证位域定义，它是正确的。在“报警触发”图像中，ctrl2.b.af 位成功设置为 1。在“警报清除”图像中，它重置为 0。位域的行为完全符合预期。 Re: PCA2131 RTC: Intermittent periodic interrupts (Missed or running 4x faster) 期待您的回复，或者我们能否通过邮件讨论？ 我的邮箱地址：[email protected]

FreeRTOSの使用に関する質問 こんにちは。現在S32DS 3.6.6を使用しており、使用しているRTDは以下のとおりです。 YangLuYao_0-1787190833199.pngYangLuYao_0-1787190833199.png FreeRTOSミドルウェアを使いたいのですが、コンポーネントリストに見当たりません。 YangLuYao_1-1787190897886.pngYangLuYao_1-1787190897886.png パッケージマネージャーに該当するパッケージが見つかりませんでした。 YangLuYao_2-1787190945484.pngYangLuYao_2-1787190945484.png どうすれば追加できますか？バージョンに問題があるのでしょうか？私のチップはFS32K116LAT0MLFTです。ご回答をお待ちしております。よろしくお願いいたします。 Re: 关于使用FreeRTOS的问题 ありがとうございます。ご指示通りにインストールできました。ありがとうございました！ Re: 关于使用FreeRTOS的问题 こんにちは 请点击 S32K1 リファレンスソフトウェア - > オートモーティブ SW - S32K1 - FreeRTOS - > SW32K1xx FreeRTOS 11.1.0バージョン 0.8.0 CD1 ダウンロードSW32K1xx_FreeRTOS_11.1.0_0.8.0_CD1_D2603_DesignStudio_updatesite.zip よろしくお願いいたします ロビン

MPC5777C MPUはコア間のタイミング干渉を増加させる可能性があるか？ こんにちは、 MPC5777CでMPUを使うことでメモリアクセス時間が長くなるかどうか知りたいです。具体的には、両方のコアが同時にMPUを通過するアクセスを行う場合にMPUで競合が発生するかどうか知りたいです(例:CPU0がPRAMC_0アクセスを同時に行い、CPU1によるEBIアクセスも同時に行い、両方ともMPU_0)。 ありがとうございます リカルド Re: MPC5777C MPU potentially increasing inter-core timing interferences? こんにちは、 MPUは2つのコア間に追加の競合やレイテンシを生じさせません。MPUは各スレーブポートのアクセスを組み合わせロジックを用いて独立かつ並列に評価します。MPUモジュール内でスレーブポート間で共有リソースやシリアライズは存在しません。 あなたの具体的な例(CPU0がスレーブポート1経由でPRAMC_0にアクセスしMPU_0 CPU1が、CPU1がスレーブポート0 MPU_0経由でEBIにアクセスする場合、両方のスレーブポートが同時にサービスされ、MPU側からの干渉はありません。 実際のインターコアタイミング干渉の原因はXBAR(クロスバースイッチ)であり、2つのマスターが同時に同じXBARスレーブポートをターゲットにした場合にアクセスを仲裁します。PRAMC_0とEBIは異なるXBARスレーブポート（それぞれポート2とポート1）であるため、ご提示のシナリオではXBARレベルでの競合は発生しません。 よろしくお願いいたします。 ピーター Re: MPC5777C MPU potentially increasing inter-core timing interferences? 下記の資料がお役に立てば幸いです。ところで、なぜタイミングの内容を知りたいのですか？アプリケーション関連のものはありますか? AN12080:クロックモニターユニット(CMU)– アプリケーションノート AN12176: MPC5777Cクロックカリキュレータガイド – アプリケーションノート

MPC5777C MPU 是否有可能增加核心间时序干扰？ 你好， 我想知道在 MPC5777C 中使用 MPU 是否会增加内存访问时间。具体来说，我想知道当两个核心同时执行通过 MPU 的访问时（例如，CPU0 对 PRAMC_0 的访问与 CPU1 对 EBI 的访问同时进行——两者都会经过 MPU_0）。 谢谢！ 里卡多 Re: MPC5777C MPU potentially increasing inter-core timing interferences? 你好， MPU不会在两个核心之间引入任何额外的争用或延迟。MPU 使用组合逻辑独立且并行地评估其每个从端口上的访问——MPU 模块内部的从端口之间没有共享资源或序列化。 在您提供的具体示例中（CPU0 通过 MPU_0 从端口 1 访问 PRAMC_0，CPU1 通过 MPU_0 从端口 0 访问 EBI），两个从端口同时提供服务，MPU 端不会进行任何干扰。 核心间时序干扰的真正来源是 XBAR（交叉开关），当两个主设备同时访问同一个 XBAR 从设备端口时，XBAR 会仲裁访问权限。由于 PRAMC_0 和 EBI 是不同的 XBAR 从端口（分别是端口 2 和端口 1），因此您的示例场景也不会在 XBAR 级别引起争用。 顺祝商祺！ Peter Re: MPC5777C MPU potentially increasing inter-core timing interferences? 希望以下文档对您有所帮助。顺便问一下，你为什么想知道时间安排？有任何相关的申请吗？ AN12080：时钟监测单元 (CMU) – 应用笔记 AN12176：MPC5777C 时钟计算器指南 – 应用笔记

MPC5777C MPU potentially increasing inter-core timing interferences? Hello, I would like to know if using of the MPU in the MPC5777C may increase memory access times. Specifically, I would like to know if there is any contention on MPU when both cores perform simultaneous accesses that pass through the MPU (e.g. CPU0 making a PRAMC_0 access simultaneously with an EBI access by CPU1 - both would pass through MPU_0). Thanks, Ricardo Re: MPC5777C MPU potentially increasing inter-core timing interferences? Hello, The MPU does not introduce any additional contention or latency between the two cores. The MPU evaluates accesses on each of its slave ports independently and in parallel using combinational logic — there is no shared resource or serialization inside the MPU module between its slave ports. In your specific example (CPU0 accessing PRAMC_0 via MPU_0 slave port 1, and CPU1 accessing EBI via MPU_0 slave port 0), both slave ports are served simultaneously with no interference from the MPU side. The actual source of inter-core timing interference is the XBAR (crossbar switch), which arbitrates access when two masters target the same XBAR slave port at the same time. Since PRAMC_0 and EBI are different XBAR slave ports (port 2 and port 1 respectively), your example scenario causes no contention at the XBAR level either. Best regards, Peter Re: MPC5777C MPU potentially increasing inter-core timing interferences? Hope the document below may help. BTW, why do you want to know the timing content? Any application related? AN12080: The Clock Monitor Unit (CMU) – Application Note AN12176: MPC5777C Clock Calculator Guide – Application Note

Questions about using FreeRTOS Hello, I am currently using S32DS 3.6.6, and the RTDs I am using are as follows. YangLuYao_0-1787190833199.pngYangLuYao_0-1787190833199.png I want to use FreeRTOS middleware, but I can't find it in the components list. YangLuYao_1-1787190897886.pngYangLuYao_1-1787190897886.png Then the relevant package was not found in the package manager. YangLuYao_2-1787190945484.pngYangLuYao_2-1787190945484.png How do I add it? Is it a version issue? My chip is FS32K116LAT0MLFT. Looking forward to your reply, thank you! Re: 关于使用FreeRTOS的问题 Thank you, I successfully installed it following your instructions. Thank you! Re: 关于使用FreeRTOS的问题 Hi  请点击 S32K1 Reference Software -> Automotive SW - S32K1 - FreeRTOS - > SW32K1xx FreeRTOS 11.1.0 version 0.8.0 CD1 下载SW32K1xx_FreeRTOS_11.1.0_0.8.0_CD1_D2603_DesignStudio_updatesite.zip Best Regards, Robin

关于使用FreeRTOS的问题 你好，我现在使用的是S32DS3.6.6，使用的RTD是下面这些 YangLuYao_0-1787190833199.pngYangLuYao_0-1787190833199.png 我想使用FreeRTOS中间件，但是我在组件里面没搜到 YangLuYao_1-1787190897886.pngYangLuYao_1-1787190897886.png 然后在扩展包管理器中也没找到相关的包 YangLuYao_2-1787190945484.pngYangLuYao_2-1787190945484.png 请问 要怎么添加呢，是版本的问题吗，我使用的芯片是FS32K116LAT0MLFT，期待回复，感谢~~ Re: 关于使用FreeRTOS的问题 谢谢，按照你的提示，我安装成功了，谢谢~~~ Re: 关于使用FreeRTOS的问题 你好 请点击S32K1参考软件-> 汽车软件 - S32K1 - FreeRTOS - > SW32K1xx FreeRTOS 11.1.0版本 0.8.0 CD1 下载SW32K1xx_FreeRTOS_11.1.0_0.8.0_CD1_D2603_DesignStudio_updatesite.zip 此致敬礼， Robin

PN7150: intermittent DISCOVERY_FAILED (0x60 07) and zeroed NDEF data with FeliCa Lite‑S (RC‑S966) Hello, I am using the PN7150 reader IC and observing unstable behavior with FeliCa Lite‑S (RC‑S966) tags. Even when the tag is placed directly on the antenna, I see repeating cycles of: Correct UID frames Correct NDEF frames Zeroed NDEF frames Empty NDEF frames 0x60 07 (DISCOVERY_FAILED) notifications Example CAN log: UID (C040041): 01 2E 54 F7 C3 59 42 3E (always stable) NDEF (C060041): Sometimes correct: D1 01 09 54 02 65 6E 48 / 65 6C 6C 6F 21 Sometimes zeroed: 00 00 00 00 00 00 00 00 / 00 00 00 00 00 Sometimes empty (DLC=0) When the tag is slightly farther away (still within normal NFC range), PN7150 frequently reports 0x60 07 and restarts discovery. My questions are Is it expected that PN7150 reports 0x60 07 when Lite‑S temporarily disables Polling or when RF field is slightly weak? Can Polling Disable cause PN7150 to return zeroed or empty NDEF data? Is there a recommended way to handle Lite‑S Polling Disable behavior in PN7150 firmware? e.g., skip presence check, delay discovery restart, retry strategy Are there any PN7150 application notes specifically addressing FeliCa Lite‑S behavior? A glance over canAnalyzer3 Mini is like this: "No";"Time (abs)";"State";"ID (hex)";"DLC";"Data (hex)";"ASCII" "3.261";"34505.380";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.262";"34505.381";" E ";" C040041";"2";"00 F1";".." "3.263";"34506.401";" E ";" C060041";"0";"";"" "3.264";"34506.645";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.265";"34506.646";" E ";" C040041";"2";"00 F1";".." "3.266";"34506.894";" E ";" C060041";"0";"";"" "3.267";"34507.143";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.268";"34507.143";" E ";" C040041";"2";"00 F1";".." "3.269";"34507.389";" E ";" C060041";"0";"";"" "3.270";"34507.930";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.271";"34507.931";" E ";" C040041";"2";"00 F1";".." "3.272";"34508.979";" E ";" C060041";"8";"00 00 00 00 00 00 00 00";"........" "3.273";"34508.980";" E ";" C060041";"5";"00 00 00 00 00";"....." "3.274";"34509.222";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.275";"34509.222";" E ";" C040041";"2";"00 F1";".." "3.276";"34509.467";" E ";" C060041";"8";"00 00 00 00 00 00 00 00";"........" "3.277";"34509.468";" E ";" C060041";"5";"00 00 00 00 00";"....." "3.278";"34509.713";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.279";"34509.714";" E ";" C040041";"2";"00 F1";".." "3.280";"34509.959";" E ";" C060041";"8";"00 00 00 00 00 00 00 00";"........" "3.281";"34509.960";" E ";" C060041";"5";"00 00 00 00 00";"....." "3.282";"34510.495";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.283";"34510.496";" E ";" C040041";"2";"00 F1";".." "3.284";"34511.516";" E ";" C060041";"0";"";"" "3.285";"34511.759";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.286";"34511.760";" E ";" C040041";"2";"00 F1";".." "3.287";"34512.005";" E ";" C060041";"0";"";"" "3.288";"34512.251";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.289";"34512.252";" E ";" C040041";"2";"00 F1";".." "3.290";"34512.497";" E ";" C060041";"0";"";"" "3.291";"34512.739";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.292";"34512.739";" E ";" C040041";"2";"00 F1";".." "3.293";"34512.985";" E ";" C060041";"8";"D1 01 09 54 02 65 6E 48";"...T.enH" "3.294";"34512.986";" E ";" C060041";"5";"65 6C 6C 6F 21";"ello!" "3.295";"34513.231";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.296";"34513.232";" E ";" C040041";"2";"00 F1";".." "3.297";"34513.477";" E ";" C060041";"8";"D1 01 09 54 02 65 6E 48";"...T.enH" "3.298";"34513.478";" E ";" C060041";"5";"65 6C 6C 6F 21";"ello!" "3.299";"34513.724";" E ";" C040041";"8";"01 2E 54 F7 C3 59 42 3E";"..T..YB>" "3.300";"34513.724";" E ";" C040041";"2";"00 F1";".."

IMX-LVDS-HDMIについて 技術サポートチームの皆様へ、 弊社では、医療機器のモニタリングシステムへの導入に向けて、貴社のIMX-LVDS-HDMIの評価を行っています。 私たちの医療機器はLVDSインターフェースを備えたLCDパネルを使用しています。LVDS信号をタップしてHDMIに変換し、元の表示動作に影響を与えずに別のPCやモニターで監視できるようにしたいと考えています。 弊社が使用している液晶パネルは以下のとおりです。 ディスプレイ： TDT25060AA00 解像度： 1024×768（XGA） LVDS: 1ポートLVDS これらのパラメータは、添付のディスプレイデータシートから取得したものです。 コンバータを購入・テストする前に、御社の基板が技術的にこのアプリケーションに適しているかどうかを確認したいと思います。 以下の点を確認いただけますか? LVDS入力互換性 あなたのコンバータはシングルチャネル/1ポートのLVDS、1024×768、8ビットRGBをサポートしていますか? ピクセルクロック周波数 当社のディスプレイは、LVDSピクセルクロックを52〜71 MHz(典型的に65 MHz)と指定しています。この全周波数帯域はあなたのLVDSレシーバでサポートされているのでしょうか? LVDSタイミング コンバーターは以下の典型的なタイミングを正しく受信できますか? Hアクティブ: 1024ピクセル 合計：1344個の時計 アクティブV：768行 V 合計: 806 行 リフレッシュレート：約60Hz スペクトラム拡大クロック(SSC) LVDS受信機は拡 散スペクトラムクロック(SSC) 付きのLVDSピクセルクロックに対応し ています か? もしそうなら、サポートされているSSC変調の深さと周波数帯域を教えていただけますか? 推奨構成 もしこのコンバーターが当サイトのディスプレイに対応しているなら、以下の推奨設定や設定を教えていただけますか: 1024×768 1ポートLVDS VESA 8ビットRGB このコンバーターが、元の表示信号を変えずに、他のPCで監視するための1024×768 LVDS表示信号を安定かつ信頼性の高いHDMI表示で提供できるかどうかを確認したいと考えています。 データシートは参考資料として添付されています。 技術的サポートを事前にありがとうございます。基板の購入とテストを進める前に、互換性の確認をいただければ幸いです。 よろしくお願いします、 Re: Regarding IMX-LVDS-HDMI こんにちは、おはようございます。 迅速なご回答ありがとうございます。つまり、前面のミニSASコネクタをボードに適したものに交換すれば、HDMIを使ってPCのLVDS信号を監視できるということですか? ありがとうございます Re: Regarding IMX-LVDS-HDMI こんにちは、 このアダプターカードは、LVDSコネクタ側にミニSASコネクタを使用しているため、i.MX 基板用のLVDSからHDMIへの接続用に設計されているので、お使いのボードに互換性があるか必ず確認してください。 他の機能については、コンバーターとして使われている実際のチップを見てみましょう。 https://www.ite.com.tw/en/product/cate1/IT6263 よろしくお願いいたします。 アルド。 Re: Regarding IMX-LVDS-HDMI こんにちは、 プラグアンドプレイアダプターほど簡単ではありません。使用されるチップはミニSASコネクタのバスの一部であるI2Cで設定される必要があり、デバイスツリーにも定義されなければなりません。 これは一般的なLVDSからHDMIへの変換器ではないので、実際に使われているチップを共有したので、どう動作するかご覧いただけます。 よろしくお願いいたします。 アルド。

Obtain JCOP4 development tools and documentation We are starting development of a custom Java Card applet for an NXP JCOP4 smart card. Our existing cards are listed as: NXP S32 Debug Entry Authenticator JCOP4 Applet Version 01.04.01 We are looking for the development tools and documentation needed to build, load, install, and test our own Java Card applet on the JCOP4 platform. Specifically, we are looking for access to: JCOP Tools JCShell JCOP4 platform export files Java Card development libraries Sample applet projects CAP file build, load, install, and delete instructions GlobalPlatform Card Manager information Confirmation of the supported Java Card and GlobalPlatform versions We found NXP's training material for Common JCOP Tools, which references the JCOP Tools Eclipse plug-in and JCShell: https://www.nxp.com/design/design-center/training/TIP-SECURE-ELEMENT-COMMON-JCOP-TOOLS-PART-1 Could you please advise: How can we obtain the JCOP Tools/JCShell package for JCOP4 development? Is an NDA or other approval required? Where can we obtain the corresponding JCOP4 development libraries, platform files, and documentation? If these resources are no longer provided directly by NXP, what is the recommended way to obtain them? Re: Obtain JCOP4 development tools and documentation Hello @sameer_chawla, Hope you are doing well. Please accept my apologies, this is not the proper support path for any topic related to JCOP devices. As resources supporting JCOP are highly restricted, unfortunately, I do not have access to the information due to security levels. For further support on this part, could you please contact your local Distributor? I really apologize for the inconveniences this might cause you. Regards, Eduardo.