[FRDM-IMX93] MCUXpresso と Zephyr 4.3.0 こんにちは。トレーニング中の開発者です。VSCode と Zephyr 4.3.0 で MCUXpresso を操作しようとしています。FRDM-IMX93 の Zephyr リポジトリから「同期」または「hello world」の例をインポートしようとしましたが、ビルドしようとすると「エラー: キャッシュに CMAKE_PROJECT_NAME が見つかりませんでした」というメッセージが表示されます。私は、MIMXRT1060-EVKB と MIMXRT1160-EVK を同じセットアップで使用して、非常に簡単な作業をいくつか問題なく実行し、プロジェクトは正常にビルドされました。まだ Zephyr の基礎を学ぼうとしている最中なので、何か見逃しているものがあるかどうかはわかりません... Re: [FRDM-IMX93] MCUXpresso with Zephyr 4.3.0 こんにちは@jaseze01 正しいコンパイル ツールをインストールしましたか? このエラーは通常、CMake が適切に初期化されていないことを意味します。 よろしくお願いします。 ダニエル Re: [FRDM-IMX93] MCUXpresso with Zephyr 4.3.0 jaseze01_0-1763975113208.png こんにちは。Zephyr https://github.com/nxp-mcuxpresso/vscode-for-mcux/wiki/Zephyr-Lab-Installation-and-Preparationに従ってツールをインストールしました。ガイドライン。FRDM-IMX93 は比較的「新しい」組み込みであり、Zephyr v4.3.0 では MCUXpresso 経由でのみサポートされているため、ツールのバージョンに関係しているのではないかと考えています (現在のバージョンの写真を添付します)。他の開発キットを使用すると、問題なくプロジェクトをコンパイルおよび開発CAN。 Re: [FRDM-IMX93] MCUXpresso with Zephyr 4.3.0 こんにちは@Zhiming_Liu !インストールを更新し、Zephyr Developer のバージョン 4.3 になりました。しかし、問題はまだ残っています... ログを確認したところ、問題は Zephyr SDK に起因していると思われます。 Cmake エラー: /mnt/.../.../zephyr/zephyr/zephyr/cmake/compiler/gcc/target.cmake:11（メッセージ）： Cコンパイラ: /ホーム/.../Zephyr-sdk-0.17.4/aarch64-zephyr-elf/bin/aarch64-zephyr-elf-gcc が見つかりません - ツールチェーンのインストールを確認してください。 ただし、Zephyr-sdk-0.17.4 フォルダーには サブディレクトリはなく、代わりに があります。それはそれでしょうか? Re: [FRDM-IMX93] MCUXpresso with Zephyr 4.3.0 こんにちは@jaseze01 はい、 SDKs の完全なインストールにはaarch64-Zephyr-elfフォルダーが含まれているはずです。Zephyr-sdk-0.17.4 フォルダーを削除して再インストールしてみてください。 よろしくお願いします、 志明 Re: [FRDM-IMX93] MCUXpresso with Zephyr 4.3.0 こんにちは@jaseze01 ここに問題はありません。 Zhiming_Liu_1-1764037024168.png Zhiming_Liu_0-1764037007732.png v4.3 zephyr 開発ツールをインストールしてみてください。 Zhiming_Liu_2-1764037085009.png Zephyr をインストールするには、VScode MCUXpresso プラグインからインストールしてみてください。 Zhiming_Liu_3-1764037131307.png よろしくお願いします、 志明

iMX8M Plus 设计文件到 Altium 元器件封装中 您好， 我已经将恩智浦提供的有关 8MPLUSLPD4-EVK 板的 Allegro 设计文件 转换为 Altium 设计文件。但是我想出了一个与元器件库有关的问题。如何将 *.brd 文件中的封装转换为 Altium *.pcb lib（PCB 元器件库文件 ）文件？ 顺祝商祺！ 阿山 Re: iMX8M Plus Design files to Altium Component footprints 您好， 这是 Altium PCB 设计文件。 Zhiming_Liu_0-1763604827987.png 致敬， Zhiming Re: iMX8M Plus Design files to Altium Component footprints 亲爱的志明 您的意思是我需要根据导入的.pcb文件创建pcblib文件吗？文件？ 您能指导我怎么做吗？ 顺祝商祺！ 阿山 Re: iMX8M Plus Design files to Altium Component footprints 以下是我从恩智浦提供的设计文件中导入的文件图像。我使用了 Altium 导入向导。我缺少的是.pcblib锉刀 Ashan7Kasper_0-1763532432661.png Ashan7Kasper_1-1763532458715.png Ashan7Kasper_2-1763532534812.png Re: iMX8M Plus Design files to Altium Component footprints 您好， ， 恩智浦提供的Allegro 设计文件 不包含库。您需要根据 *.pcb 文件创建库。 致敬， Zhiming Re: iMX8M Plus Design files to Altium Component footprints 亲爱的 Zhiming_Liu , 在设计文件中，我只有 LAY-46368_A1.brd、SCH-46368_A3.dsn、和 sch-46368_a3.opj 文件。设计文件中没有 .pcb提供的文件。你能告诉我如何获取特定设计的 pcb 元器件库文件吗？我正在使用Altium Designer工具，但这些Allegro文件无法正确转换为PCB元器件库文件。(它只能转换为 PCB 布局和 PCB 原理图） 最佳问候 Ashan Re: iMX8M Plus Design files to Altium Component footprints 你好， 您可以创建 .pcblib文件，创建一个新的库元器件，然后将元器件从 .pcb 复制到这个新的库元器件。 致敬， Zhiming

PN532 标签仿真 NFC 工具显示 NULL 所有数据 目前正在使用 PN532 (UM0701-02 ) 模块接口，通过基于 IRQ 状态模型的 SPI 通信与 STM32WL 微控制器连接。我将一步步解释我是如何处理状态机的 第 1 步： SPI 配置 - 时钟 2Mhz 和 8 位模式 第 2 步： 在启动 PN532 模块后，我发送了 SMA 配置，然后正在等待第一个 IRQ 的 ACK，之后我将等待第二个 IRQ 的 SMA 配置响应。我没有收到任何错误信息。请注意我使用的以下配置 pn532_packetbuffer[0] =pn532_command_samconfiguration； pn532_packetbuffer[1] = 0x01;// 正常模式； pn532_packetbuffer[2] = 0x14;// 超时 50ms * 20 = 1 秒 pn532_packetbuffer[3] = 0x01;// 使用 IRQ 引脚！ 步骤 3：收到 SMA 配置回复后， 。 我已经开始发送 TgTarget 启动命令。对于这条命令，我只收到 ACK，当电话接近模块时，我才收到回复。 uint8_tcommand[] ={ pn532_command_tginitastarget、 5,// 模式：仅 PICC，仅被动 0x04, 0x00, // SENS_RES 0x00, 0x00, 0x00,// NFCID1 0x20, // SEL_RES 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,// FeliCaParams 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,// NFCID3t 0,//一般字节的长度 0//历史字节的长度 }; 如果(uidPtr != 0) {//如果设置了 uid，则将 3 个字节复制到 nfcid1 memcpy命令 + 4, uidPtr、 3); }} 这条命令也得到了成功的回复。 因此，现在我有了手机 NFC 信息，如 NFC 支持类 注：到此为止，我得到了正确的 IRQ Assert、ACK 和命令回复。 第 4 步： 响应后，我将开始发送 TgGetTarget 命令（0x86）。第一次，比如当我将手机靠近 PN532 时，得到的响应为 0x87，错误代码为 0x13。像 RF 版本一样。之后，我尝试了两种方法来恢复通信。最初的方法是发送 Inrelease 命令 0x52、0x00，然后获取 IRQ，并得到 53 和 0x00 的响应。然后再次发送 TgTartget Command Initi 命令，就像再次执行步骤 3 一样。请注意，在这之后的一段时间里，我得到了对 0x86 的正确回复。 现在我还有一个问题，在我发送 Inrelease 或 TgTarget 命令后，NFC Tools Mobile 显示的所有数据，如序列号和其他信息都显示为零。并展示 felica 技术。但使用的是 ISO1884A A 类卡枚举。 现在我想知道为什么会出现这种情况。如果我遗漏了任何序列。请尽快为我们提供指导。我们正处于项目收尾阶段。 已经有人向我推荐了表格，但我没有得到答复 互联标签解决方案 接触式智能卡读卡器芯片 HITAG读卡器IC 面向读卡器系统的MIFARE SAM NFC 控制器解决方案 NFC 前端解决方案 NFC读卡器库 Re: PN532 Tag emulation NFC Tools showing NULL all the data 请问谁能对此问题提供支持

S32G274A SMMU 支持和配置 我们目前正在S32G274A平台上进行开发，需要澄清有关系统内存管理单元 (SMMU) 的问题。请帮助确认以下内容： 1.S32G274A 上的 SMMU 支持 S32G274A SoC 是否支持 SMMU 功能？ （我们知道它可能支持 SMMU v2，但需要确认。） 2.QNX SMMUMAN 兼容性 如果支持 SMMU，能否使用QNX SMMUMAN（SMMU 管理器）对其进行配置？ 是否有任何针对 SoC 的限制或约束（例如，仅通过 XRDC 支持）？ 3.内存地图和中断信息 SMMU 主寄存器的物理基地址 上下文故障的中断编号 全局故障的中断号 参考查询： 我们查看了 S32G2 参考手册（文件编号：S32G2RM，修订版 8，2024 年 2 月）和提供的 S32G2_Memory_Map.xlsx，但找不到任何与 SMMU 相关的条目。 相比之下，恩智浦 i.MX8 等其他 SoC 在其参考手册中包含了这些信息，但是 S32G2 似乎缺少这些信息，或者可能以不同的名称列出。 我们需要这些信息才能集成QNX SMMUMAN。 如果有任何与 S32G274A 上的 SMMU 相关的其他文档、应用笔记或 SDK 引用信息，请分享。 感谢您的支持。

Cortex-M7からのメッセージをS32G-VNP-RDB2ボードのUARTターミナルに「printf」するにはどうすればいいでしょうか？ こんにちは、NXPコミュニティの皆様 質問が２つあります。 1. Cortex-M7からUART端末にメッセージを「printf」するにはどうすればいいでしょうか（例：(uart 1、uart 0 は Linux コンソールに使用されます)?S32G2-VNP-RDB2 ボードですでにテスト済みの簡単な例を提供できますか? 以下は私の実験設定です。 ソフトウェア: S32 Design Studio IDE v3.5（パッケージ付き） S32G2 AUTOSAR 4.4 RTD 4.0.2_P04D2312 フリーRTOS 10.4.6 UOS 4.0.2D2307 S32G IPCF 4.10.0D2405 NXP Linux BSP42 Arm 32 ビット ベアメタル用 NXP GCC 9.2.0 (M7 コア用) NXP GCC 11.4.0 (A53 コア用) ボード: S32G2-VNP-RDB2 IPCF_FreeRTOS_S32G274A_M7_0 からサンプルプロジェクトを作成し、A53 と通信できるようにします。(このプロジェクトは、IPCF を使用したアプリケーションのスターターとして機能します) ここで、M7 から UART 端末にいくつかのメッセージを printf (出力) したいのですが、どうすればよいですか? 2. S32 デバッグ プローブを使用しているときに、デバッグ コンソールで 'printf' メッセージを確認するにはどうすればよいですか?M7プログラムをステップ実行、変数の監視などでデバッグできます。しかし、「設定->ターゲットプロセッサ」で「Newlibセミホスティング（-specs=rdimon.specs）」を選択しても何も起こりません。 Re: How can I 'printf' some messages from Cortex-M7 to uart terminal on S32G-VNP-RDB2 board こんにちは、 ZhiXiaoli お問い合わせいただきありがとうございます。 次の図のように、RTD で Uart のデモを使用してみてください。 Joey_z_0-1763721974865.png 参考になれば幸いです。 BR ジョーイ

Bootloader 软件的安全启动验证 大家好 1. 我们如何对引导加载程序软件本身进行安全启动验证？ 如果引导加载程序本身初始化了 CSEc，那么我们就已经在运行未经验证的代码了。 2. 如果引导加载程序区域被锁定为读/写/擦除保护并禁用了 JTAG，我们可以跳过引导加载程序的安全启动验证吗？ 它还能被篡改吗？ 我们还需要强制对 Bootloader SW 进行安全启动验证吗 谢谢。 Re: Secure Boot validation for Bootloader SW 你好@Kishore_14 1.这需要通过生产流程和适当的应对措施来管理。通常，应在安全的环境中对设备进行编程和配置，只有获得批准的人员才能访问等。 S32K1 设备不具有使此过程更加安全的功能，因此应由用户来安装适当的环境。例如，S32K3 在 ROM 密钥目录中拥有公钥，而私钥则完全归恩智浦所有，因此恩智浦可根据要求签署客户应用程序/数据。这是下一级保护。但 S32K1 上没有这样的东西。 2. 不存在 100% 安全的设备。每种保护都可以绕过。目标是尽可能地使网络安全突破变得困难，并使努力不合理，成本低廉。因此，我们的建议是实施所有级别的保护，包括安全启动。 问候， Lukas

S32K312 - a MCAL pointer variable point to a self-defined variable Hi， I am using s32k312 and MCAL version is 5.0.0, the startup and linker files is based on MCAL package. I defined a bool variable named LibDiagCom_Initialized, and I found in the LiveWatch and memory it was changed unexpectedly. I set a data breakpoint and found a struct variable with a pointer was changing the memory.  So is this pointer a wilder pointer? Re: S32K312 - a MCAL pointer variable point to a self-defined variable Hi@yumi From the screenshot you provided, I don't see any relationship between "LibDiagCom_Initialized" and "Lpspi_Ip_axStateStructure". Is there a problem? My understanding of a "dangling pointer"（野指针） is usually that it points to an unknown, random location. I don't see that problem here. Re: S32K312 - a MCAL pointer variable point to a self-defined variable Hi Selent, From the Live Watch, you can see the location of 'LibDiagCom_Initialized' is 0x2040 37df, and the pointer RxBuffer in Lpspi_Ip_axStateStructure point to 0x204037DC.  I set a data breakpoint for LibDiagCom_Initialized, the scenery is LibDiagCom_Initialized value is changed by the RxBuffer at the data breakpoint， as shows in another picture. So my question is: Shouldn't the RxBuffer in Lpspi_Ip_axStateStructure point to somewhere at initialization? If not, is it a dangling pointer?  Re: S32K312 - a MCAL pointer variable point to a self-defined variable Hi@yumi In the image you provided, I did not see that the value of "LibDiagCom_Initialized" had changed. You'd better provide me with your test routine, because I still don't understand it. I don't see any problems in the images you provided.

安卓音频编解码器 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我正在尝试让音频在安卓系统内运行。我的板基于 QSB，但使用不同的音频硬件（TI 的 TLV320AIC23B）。Linux 和 Android 源代码均已修改，新驱动程序在 Linux 中加载无故障，Android 也能识别。当我播放 .wav但是，在使用飞思卡尔专有库解码数据的 Android 系统中播放压缩音频时，音质很差。在检查 SSC 总线上的 i2s 信号后，我发现很多音频帧都不包含数据，都是低位。这种情况每隔 10 毫秒左右出现一次，每次 2 或 3 毫秒左右......是否有人在使用飞思卡尔的编解码器库和不同的 ALSA 驱动程序时遇到过类似问题？或者谁能解释如何在没有飞思卡尔专有音频编解码器的情况下版本飞思卡尔安卓系统？ 另一方面，我已经让安卓系统和飞思卡尔编解码器库与 Maxim 的 Max9850 音频 DAC 配合使用，我很乐意为新手指点迷津。 Android Re: Android Audio Codecs 嗨，您可以查看本指南，了解如何在 Android 和 Linux 平台上调用音频 https://siliconsignals.io/audio-codec-bring-up-simplified-your-guide-to-android-linux-bsp-development/ Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，马克、 你的回复是 Bang-on.我们没有注册 iim 设备。即使在梦中，我们也没有想到音频代码和IIM设备之间可能存在某种关系。 我不知道该如何感谢你。我们与飞思卡尔技术支持部门联系了几个月，但一直没有得到解决方案。 非常感谢& 。 普拉尚特 马克-奥利弗-韦斯特堡说： 问题解决了吗？ 至少在我们的案例中，问题是由于"/dev/mxc_iim" 和"/dev/mxc_mem" 这两个文件的权限错误造成的。根据飞思卡尔的支持，至少有一些编解码器会访问这些数据，以验证它们是否确实在 i.MX-SoC 上运行，如果检测失败，还会故意注入噪声。这些文件的权限必须设置为 0664，而且相应的内核驱动程序必须正常启动和运行。 Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 问题解决了吗？ 至少在我们的案例中，问题是由于"/dev/mxc_iim" 和"/dev/mxc_mem" 这两个文件的权限错误造成的。根据飞思卡尔的支持，至少有一些编解码器会访问这些数据，以验证它们是否确实在 i.MX-SoC 上运行，如果检测失败，还会故意注入噪声。这些文件的权限必须设置为 0664，而且相应的内核驱动程序必须正常启动和运行。 Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们正在使用基于 i.MX53 的定制板和飞思卡尔的 SGTL5000 音频编解码器（与飞思卡尔的 QSB 设置类似），但也面临着类似的问题：使用安卓媒体播放器播放 WAV 文件（单声道、立体声、不同的采样率）可以正常运行，没有任何问题。使用安卓的媒体播放器播放 MP3 或 OGG 文件会产生大量噪音，但原始音频数据仍可识别。 作为尝试，我们删除了飞思卡尔的 MP3 编解码器，但保留了飞思卡尔的所有其他编解码器。在这种情况下，Android 似乎使用自己的 SW 编解码器来播放 MP3，而且效果很好，没有任何噪音或失真。在此实验配置中，视频仍由飞思卡尔编解码器处理，但 MP3 音频流仍无法正常工作，并显示出相同的音频问题。不过，视频编解码器本身（H.263、H.264/AVC 和 MPEG2）似乎工作正常。 在我们的案例中，这些音频问题不仅发生在飞思卡尔的 MP3 编解码器上，也发生在 OGG 和 AAC 编解码器上。这些编解码器是否也存在类似问题？ 我们已经尝试过飞思卡尔安卓版本 R10.3、R10.3.1 中的编解码器，在我们的系统上，R10.3.2 和 R10.4 以及所有版本似乎都出现了同样的问题。 此致， 马克 Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，内特、 事实上，我们也面临着同样的问题。我们有一款基于 i.MX53 处理器的定制板。我们正在使用飞思卡尔的 SW 音频编解码器。我们已经在opencore中加入了黑客来在多个阶段TAP解码器的输出。当我们播放 MP3 单声道文件时，输出帧大小为 1152 字节。在所有帧中，最后 576 字节为零。如果是 Mp3 立体声，则文件帧大小为 2304 字节。再一次，在所有帧中，我们看到最后 576 字节 0。立体手机壳与您的手机壳类似（10 毫秒数据后 3 毫秒为零）。 飞思卡尔说，这些音频编解码器是使用ARM/Neon进行软件优化的。您说您能用 Maxim 的 Max9850 音频 DAC 正常运行这些编解码器，是什么意思？音频 DAC 如何影响音频解码器的输出？ 也许我们遗漏了什么。您能给我们一些指导吗？如蒙答复，我们将不胜感激。 先行致谢。 此致 普拉尚特 Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔音频编解码器针对飞思卡尔板编解码器进行了优化，因此我认为它不是一个适合您的情况的编解码器。 看看板描述符文件（在 设备/ 下）我知道有一个变量表示预建的真/假。 我不确定视频编解码器是否有一个变量，音频是否有另一个变量。但这可能是你更改 Makefile 所需要的线索。 Re: Android Audio Codecs <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 内特，通话时音频也能正常工作吗？我已经使用外部编解码器安装了 SABRE 板，它可以播放音频文件，但是当我接到 VoIP 电话时，两个方向都没有音频。是否需要在驱动程序中设置一些特殊的东西才能使编解码器在语音通话中运行？ 谢谢！ Scott

リアルタイム・クロック(RTC)チップって？(日本語ブログ) リアルタイム・クロック(RTC)チップって？ この記事では，NXPで最も消費電流が小さく時間精度が高いRTCモジュール製品を中心に，RTCとは何をするものなのか，またどのようなシステムで外付けRTCが必要になるのかを解説． 外付けRTCを使えば ①低消費電力化により電池寿命を伸ばし，②正確な時刻管理を可能にし，③システムの信頼性を向上させ，④追加機能を用いてセキュリティの向上 などのメリットがあります． 記事の最後にはすぐにRTCを試せる評価環境(基板+ソフトウェア)も紹介します． カレンダーと時計カレンダーと時計 図1：RTC = 時計とカレンダーをシステムに組み込むためのもの 時計 + カレンダー 多くの家電やガジェットでは時計を表示する機能がついています．これらの機器内に組み込まれた時計は，単に現在の日時を表示するだけでなく，電源のオン/オフを自動で行うタイマーや，デバッグやシステム管理を行うためのログの記録を行うなど様々な目的に使われます． このような時計機能はリアルタイム・クロック(以下RTC)と呼ばれるマイコンやプロセッサ内蔵の回路，または外付けのRTCチップによって実現されます． RTCは自身の水晶発振器で発生させたクロックを使って時を刻み続けます．そしてそのクロックをカウンタで計数することにより，現在の時刻や日付を知ることができるようになります[図2]． スクリーンショット 2025-02-27 13.11.35.png 図2：RTCの内部．水晶振動子，発振器，カウンタ，インターフェース RTCはマイコンやプロセッサに内蔵されている 多くのマイコンやプロセッサには，そのチップ内にRTC回路が入っています [図3]． これらマイコンやプロセッサに電源さえ供給されていれば，たとえそのチップがスリープやパワーダウン・モードなどの非稼働状態にあっても，RTCによって現在の時間と日付を示す値(カウンタ値)に更新し続けます． このような機能によって，設定した日時に正確にシステムを起動したり，あるいは電源がオフの間での起こったイベントをRTC回路内に正確に時間を記録しておくなどの機能が実現できます． スクリーンショット 2025-02-27 13.19.31.png 図3：マイコンに内蔵されたRTC (MCXN94x/MCXN54xの例) RTCを動作させ続けるには：消費電力 たとえば電源をオン/オフするタイマー機能を実現するならば，設定した時刻になると電源スイッチを操作する機能を持たせなければなりません．このために時間の情報だけは機器内で刻み続けている必要があり，RTCだけは電源が切れない仕組みが必要です． 主電源を切っていてもRTCを動作させるためには，バッテリー/電池からRTCだけには常に電気を供給する必要があります．もし機器内に電池を持っていないならRTC用にコイン電池やスーパーキャパシタなどによるバックアップ電源を用意します [図4]． このようにRTCは常に電池を消費する存在であるため，低消費電流であることが重要になります． PCF2131-ARD-ANGLE1.png 図4：RTC評価基板の例．PCF2131/PCA2131 Arduino® Shield評価基板にはバックアップ用コイン電池が搭載されている 時刻の再同期：時刻精度 RTCを動かし始める時には現在時刻の設定をしてやらなくてはなりません．この初期設定により，RTCは正しい現在日時を維持してくれるようになります．初期設定を行わなければ，RTCがリセットされた時のデフォルト日時からの経過時間が更新され続けることになります． 現在日時の設定は，ユーザに手動操作(ボタン操作など)で合わせてもらったり，自動でネットワーク経由でNTPサーバに同期したり，あるいはGPSと同期するなどの方法が採られます． 初期設定のあとは，たとえ主電源がオフになってもRTCへの給電が止まらなければ，自身が持つクロックによって時間の更新を維持し続けます．このクロックの精度が時間の精度となります．クロックの精度はいくつかの要因で決まります．水晶振動子(発振子)の精度，発振回路のマッチング，さらに温度が主な要因です． もしその機器の主電源が頻繁にオンになり，その都度，時刻の再同期が行えるなら高い精度は要求されないでしょう．しかし長く主電源がオフであり続けたり，GPSや時刻サーバへのアクセス手段を持たないシステムのような用途の場合には，システムに必要とされる仕様に合わせた精度のRTCが必要になります． 外付けRTCを使うメリット 構築しようとしているシステムが，マイコンやプロセッサ内蔵のRTCで充分に機能するなら，わざわざRTCチップを外付けする必要はありません． しかし電池寿命をできるだけ伸ばしたり，正確な時間の維持が要求される場合には外付けRTCが必要になります [図5]． スクリーンショット 2025-02-27 13.33.26.png図5：外付けRTCを使用したシステム．RTC以外は電源をオフにして，電力消費を抑えることができる   外付けRTCを使う主なメリットは次の4点．これらについて見ていきます． メリット１：電池寿命を伸ばす(システム全体の低消費電力化) メリット２：正確な時刻管理 メリット３：信頼性の向上 メリット４：追加機能 メリット１：電池寿命を伸ばす (システム全体の低消費電力化) マイコン/プロセッサ内蔵のRTCでは マイコンやプロセッサはその主たる機能，制御や計算の能力のために設計が最適化されています．この最適化は消費電力の面でも行われており，処理を効率的に行えるようになっています． またこれらのチップには「スリープ」や「パワーダウン」と呼ばれるモードが用意され，処理が必要ない時に必要な機能だけを維持して電流消費を下げる工夫もされています． たとえば，NXPの最新マイコン：MCXシリーズでは内蔵RTCの動作だけを維持する「ディープ・パワーダウン」を持っています．各チップによってこの時の消費電流は異なります．汎用マイコンとして使いやすいMCX-Aシリーズでは数百ナノ・アンペア，より処理能力の高いMCX-Nシリーズではマイクロ・アンペア単位の電流が消費されます．これらの例の電流値は「かなり低く抑えられている」と言えますが，さらに低消費電力化が求められるケースでは外付けRTCが必要になります． 外付けRTCでは 一方，RTCチップの消費電流は製品によりさまざまですが，たとえば最も低消費電流のPCF2131では65nAとなっています． 前述のマイコン/プロセッサのパワーダウンモード時との消費電流の比較を図6に示します．この差がバッテリの長寿命化に貢献します．  ※ 長寿命化が必要ないとしても，より小さい電池により、省スペース、小型化、コストダウンが可能になります． スクリーンショット 2025-02-27 13.53.20.png 図6：RTC動作を維持するための電流の比 (当社比) メリット2：正確な時刻管理 RTCの時刻管理は32.768kHzの発振器をベースにしています．この発振周波数のズレが精度の悪化につながります．この精度を悪化させる主な要因は，水晶振動子や発振回路のばらつきで，さらに温度も影響します． マイコン/プロセッサ内蔵のRTCでは マイコン/プロセッサ内蔵のRTCに使われる発振周波数の精度は，通常±100ppm〜程度です．この±100ppmは32.768kHzの周波数がどれだけずれるかを示しており，これが直接「時計の進み/遅れ」となります．ちなみにこの±100ppmを月差に直すと ±100 * 10 -6 [精度]  * 60 [秒] * 60 [分]  * 24 [時間] * 31 [日]  = ±259.2 [秒] つまり1ヶ月で4分もの進み/遅れが発生し得ることになります． 頻繁に主電源がオンになり，時刻の再同期がその都度行えるシステムでなければ，このような大きなずれが生じてしまいます． 外付けRTCでは 外付けRTCは要求される精度により水晶振動子内蔵のモジュール型や温度補償回路内蔵などの品種から選択いただけます．NXPの最も高い精度を持つRTCは，水晶振動子内蔵のモジュール型で温度補償回路を内蔵しているPCF2131で，-40℃から+85℃の動作温度範囲全域で±3ppm (typ) の精度(月差±7.8秒)を保証しています [図7][図8]． RTCチップ単体の製品の場合，精度は使用する外付けの水晶振動子に依存します．NXPのRTC製品では，ソフトウェアからクロック周波数の微調整が可能です． スクリーンショット 2025-02-27 13.56.21.png 図7：RTCモジュール：PCF2131，PCA2131の内部構造   スクリーンショット 2025-02-27 14.04.15.png 図8：RTCモジュール：PCF2131の温度補正．水晶振動子単体の発振周波数特性は温度に対して放物線を描く   メリット3：信頼性の向上 外付けRTCに，システムの電源とは別にバックアップ用の電源(コイン電池など)を持たせておけば，システムのリセットや電源障害からも時刻情報を保護できます．これによりシステムの信頼性が向上します． メリット4：追加機能 外付けRTCでは追加機能を持っている品種があります．RTCがバックアップ電源で動作している間，イベント発生を記録しておくためのタイムスタンプ機能(PCF2131，PCF85263Aなど)を持つものがあります．これは主電源オフ時における機器筐体の開閉などを記録しておくことで，フィールド・サービスでの応用や，セキュリティ機能強化などが可能になります． クロック出力もオプションで用意されている機能です．32.768kHzを分周したクロックを出力できる製品があります．この機能を持つ製品の多くが32.768kHzから1Hzの周波数(分周比)を設定できます． 割込もオプション機能のひとつ．秒や分ごとの定期的な割込や，設定したアラーム，さらにタイムスタンプのイベントの発生で割込を発生できるものがあります．これらの機能を利用して必要に応じてシステムをウェイクアップさせるような機能を実現できます． 外付けRTCの種類 NXPでは外付けRTCにさまざまな品種を揃えています．最適なRTCはNXPの製品セレクタ・ページで探せます．ここでは選択肢のうちモジュールか単体チップか，インターフェースの種別，さらに車載用途のような視点からの特徴を解説します． 水晶振動子内蔵モジュール型 (高精度，低電力) RTC製品の中でも最も高精度，低消費電力の製品が，水晶振動子内蔵型モジュール製品のPCF2131と，同機能を持つ車載グレード品のPCA2131です． どちらの製品も-40℃から+85℃の動作温度範囲で±3ppm (typ) ，車載対応品では温度範囲が拡張されており，85℃から105℃の範囲で±8ppm (typ) の精度を保証．消費電流は車載非対応のPCF2131では電源3.3V時に65nA (typ) の，車載対応品のPCA2131では106nA (typ) になっています． 水晶振動子が外付けの製品では最も基本的な機能だけを持ったPCF85063TPから，さまざまな追加機能を持つ製品が展開されています [図9]． スクリーンショット 2025-02-27 15.02.44.png 図9：PCF85063TPの内部レジスタ：最も基本的な機能だけに限定されているため，レジスタは11バイト分しかない．このうち制御や状態をモニタするためのレジスタが4バイト，残り7バイトで年月日，曜日，時分秒の情報を提供 接続方法 (I²C，SPI) マイコンやプロセッサとの間はI²CかSPIのシリアルバスで接続します．製品によってI²CとSPIの切り替えができるものと，品番によってどどちらかに固定されたものがあります． どちらの場合もマイコン/プロセッサからはレジスタを介して制御・日時の情報の読み出しが行われます．さらにシリアルバスに加えて割込信号出力が用意されているものもあり，これらは製品によって1本，または2本の割込出力が使えます． 車載対応(AEC-Q100対応) NXPのRTCには民生グレード品に加えて，AEC-Q100に対応した車載対応品が用意されています．これらの対応品は製品セレクタ・ページで見つけることができます． スクリーンショット 2025-02-27 15.14.01.png 図10：RTC製品セレクタ・ページ  試してみよう！    boards4.jpg 図11：RTC対応，Arduino®シールド型評価基板：PCF2131-ARD, PCF85063TP-ARD, PCF85063AT-ARD and PCF85263ATL-ARD   NXPではRTCをはじめ，各製品をすぐに試せる評価基板も多数提供しています．RTC用ではArduino®シールド型の基板を提供．さまざまなNXPのマイコン評価基板と組み合わせて評価が可能です． またオープンソースで，Arduino® UNOシリーズなどに対応したArduino®サンプル・スケッチ/クラス・ドライバが配布されています．さらに各種マイコンに対応したMicroPythonコードも使うことができます． RTC対応のArduino®シールド型評価基板の詳細は，この記事下部に添付されているArduinoシールド紹介資料-20250227.pdfを参照ください． スクリーンショット 2025-02-27 15.56.04.png 図12：「Arduinoシールド紹介資料-20250227.pdf」第4ページ 参考資料 NXPリアルタイム・クロック製品ポータル Arduino®シールド・ソリューション NXP システム・マネジメントI2C, I3C, SPIセレクタ・ガイド NXPコミュニティ・ブログ：I²Cバスの概要 (日本語ブログ) NXPコミュニティ・ブログ：SPIバスの概要 (日本語ブログ) 変更履歴： 2025-03-03：初版 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） リアルタイムクロック(RTC)には数多くのチップがあるどころか，マイコンやプロセッサにもその機能が内蔵されています． この記事では，「そもそもRTCとは何なのか？」から，「内蔵RTCを使わずに外付けRTCチップを使うメリットは何なのか？」さらに「それらをどのように選択すれば良いのか？」を解説します． Interface introduction 日本語ブログ

什么是“电源”？——入门指南——第三部分：电压追踪器（日语博客） 这次，我们将讲解电压跟踪器。 电压跟踪器是一个不常听到的术语。 Voltage = 电压，tracker = 跟随的东西，所以如果按字面意思理解，它的意思是“跟随电压的东西”。 事实上，电压跟踪器是一种输出电压几乎等于输入电压的装置，如图1所示。当输入电压变化时，输出电压也会相应变化。正是这种特性使其被称为电压跟踪器，因为它“输出的电压与输入电压相匹配（跟随）”。 blog3-1.png 图 1 电压跟踪器行为 那么，在哪些情况下会使用电压跟踪器呢？ 第一个电源用于在稳压器输出电流不足时补充其输出电流的不足。 例如，如果你有一个能够输出 100mA 的线性稳压器，但你需要 150mA 来为你的电路供电，你可以从电压跟踪器获得额外的 50mA（参见图 2）。 blog3-2.png 图 2 添加电压跟踪器 从这个角度来看，你可能会认为用线性稳压器代替电压跟踪器就能解决问题，虽然这在某些方面是正确的，但这也带来了一个问题。 例如，如图3所示，即使原有的100mA线性稳压器的输出电压发生波动，新增线性稳压器的输出电压也不会改变。在这种情况下，电路输入电压存在差异，这可能导致电路故障。而使用电压跟踪器后，则不存在这种差异，因此电路的工作状态如同仅由单个稳压器输出一样。 blog3-3.png 图 3 添加线性稳压器   如图 4 所示，第二个电源用作参考电源的附加电源，用于在使用 AD（模数）转换器进行比率测量时。在比率测量中，参考电压和传感器电源必须使用相同的电压，因此通常使用电压跟踪器。 blog3-4.png   图 4 比率测量图像 虽然这与电源的讲解有点偏离主题，但我下次会专门讲解比例测量。 最后，下表显示了电压跟踪器和线性稳压器之间的区别，它们的机制类似。 物品 线性稳压器 电压跟踪器 输入和输出关系 输入电流和输出电流几乎相同。 输入电压 > 输出电压。 输入电压和输出电压几乎相同。 噪音 低的。 低的。 所需零件数量 很少。 很少。 以往的文章可从NXP“电源”摘要页面（日语博客）访问，请查看。 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） 如果您想知道“什么是电源？”，本页总结了您需要了解的第一件事。 在第三部分中，我们将解释电压跟踪器。 （阅读时间：5分钟） 采购和市场营销中心 日本博客

「電源」とは？- 最初の一歩 – 第二回 スイッチング・レギュレータ（日本語ブログ） 今回は、スイッチング・レギュレータについて説明します。 スイッチングとは、スイッチをON、OFFすることです。 スイッチング・レギュレータは、スイッチング素子と呼ばれるものを、ON、OFFさせながら、意図した電圧を生成するものです。図１のように、ONとOFFの区間を変化させて、電圧をならすと、出力の電圧が変わります。これが、入力電圧から低い出力電圧を生成する（降圧と呼びます）レギュレータの動作となります。 blog2-1.png  図１　ON/OFF区間とならした電圧の関係 スイッチング素子には、FET（Field Effect Transistor）と呼ばれるもの、電圧をなだらかにする部分には、コイルとコンデンサで構成されたフィルタと呼ばれるものを使います。これらの詳細は、別の機会に説明しますね。 では、スイッチング・レギュレータの振る舞いを見てみましょう。 リニア・レギュレータのときと同じく、入力と出力に着目して見ると、図２のようになります。図２は、降圧のときの図ですが、大事なところは、入力電力と出力電力が、ほぼ等しいことです。図では、電圧（V:ボルト）×電流（A:アンペア）の面積が、ほぼ等しい、ということになります。 blog2-2.png 図２　スイッチング・レギュレータの振る舞い つまり、スイッチング・レギュレータは、同じ電力の中で、電圧と電流の比率を変える装置といえます。 ここで、「ほぼ等しい」と言ったのは、スイッチング・レギュレータを動作させる電力を、入力電力から、少し持ってくるためです。 ですので、効率=出力電力÷入力電力は、高い値（だいたい80%以上）になります。 リニア・レギュレータでは、熱に消えていた分が、とても小さくなりますので、大きな電力を扱う場合、スイッチング・レギュレータのほうが、電力を有効に活用できます。 また、「同じ電力の中で、電圧と電流の比率を変える装置」と考えた場合、入力電圧より、高い出力電圧を生成することもできます（昇圧と呼びます）。 このように、スイッチング・レギュレータは、昇圧と降圧を自在にでき、電力を有効活用できる電源、と言えます。一方、出力電圧を作るためにフィルタが必要で、リニア・レギュレータに比べると、動作が複雑で、動作に必要な部品点数が多い、という欠点もあります。 また、リニア・レギュレータのときにも書きましたが、「スイッチング」動作によって、大きなノイズを発生する、という欠点もあります。 このようなことから、一般的にスイッチング・レギュレータは、比較的大きな電力が必要で、ノイズの影響が比較的少ないところで使われます。 ただ最近は、ノイズを抑えたり、部品点数を減らしたりする技術が進んできて、以前ではあまり使われなかった、センサーや音楽系の用途にも使われてきています。 最後にリニア・レギュレータとスイッチング・レギュレータの比較を表にまとめます。 項目 リニア・レギュレータ スイッチング・レギュレータ 入力と出力の関係 入力電流と出力電流が、ほぼ同じ。 入力電圧＞出力電圧。 入力電力と出力電力が、ほぼ同じ。 効率 入力電圧と出力電圧の差が大きいほど悪化。 高い（高効率）。 発熱 大きい。 小さい。 ノイズ 低い。 高い。 必要部品数 少ない。 多い。 第三回は、ボルテージ・トラッカについて説明します。 過去の記事は、「NXP「電源」まとめページ (日本語ブログ)」 からアクセスできますので、ぜひ見てみてください。 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 「電源ってなに？」、という人に、最初に知っておいてほしいことを、まとめたページです。 第二回として　スイッチング・レギュレータについて、説明しています。 (読了：5分) PMIC 日本語ブログ

解決に失敗しました: Lcom/google/firebase/analytics/FirebaseAnalytics 親愛なるチームの皆様、 Taplinxを使ってアプリケーションを開発しています。そして、次のエラーが発生しました: FATAL EXCEPTION: main Process: com.xxx.xxxxx, PID: 6289 java.lang.NoClassDefFoundError: Failed resolution of: Lcom/google/firebase/analytics/FirebaseAnalytics; at com.nxp.nfclib.analytics.AnalyticsTracker.getReader(:61) at com.nxp.nfclib.analytics.AnalyticsTracker.Base64(:122) at com.nxp.nfclib.analytics.AnalyticsTracker.sendEvent(:107) at com.nxp.nfclib.ʽ.CardType(:649) at com.nxp.nfclib.ʽ.Base64(:60) at com.nxp.nfclib.ʽ$ˊ.getReader(:785) at com.nxp.nfclib.ʽ$ˊ.onPostExecute(:663) at android.os.AsyncTask.finish(AsyncTask.java:771) at android.os.AsyncTask.-$$Nest$mfinish(Unknown Source:0) at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:257) at android.os.Looper.loop(Looper.java:368) at android.app.ActivityThread.main(ActivityThread.java:8839) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049) Caused by: java.lang.ClassNotFoundException: com.google.firebase.analytics.FirebaseAnalytics at com.nxp.nfclib.analytics.AnalyticsTracker.getReader(:61) at com.nxp.nfclib.analytics.AnalyticsTracker.Base64(:122) at com.nxp.nfclib.analytics.AnalyticsTracker.sendEvent(:107) at com.nxp.nfclib.ʽ.CardType(:649) at com.nxp.nfclib.ʽ.Base64(:60) at com.nxp.nfclib.ʽ$ˊ.getReader(:785) at com.nxp.nfclib.ʽ$ˊ.onPostExecute(:663) at android.os.AsyncTask.finish(AsyncTask.java:771) at android.os.AsyncTask.-$$Nest$mfinish(Unknown Source:0) at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:257) at android.os.Looper.loop(Looper.java:368) at android.app.ActivityThread.main(ActivityThread.java:8839) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049) これは初期化後数秒で発生し、 libInstance.isActivityRegistered() == true; 数秒後、カードの意図が実行される前に、上記の致命的なエラーが発生してクラッシュします。 アプリケーションはオンラインで配布されず、ユーザーの所在地は中国本土であるため、アプリケーションに Firebase を含める必要はありません。これを回避する方法はありますか?このエラーに関して何か提案をいただけますか? ありがとうございます。ご返信をお待ちしております。 敬具、 ビリトン コード・サンプル オフライン版 Re: Failed resolution of: Lcom/google/firebase/analytics/FirebaseAnalytics はい、Firebaseがなくても動作しますが、ライブラリを含める必要があります。 com.google.firebase:firebase-core 実行時にlogcatでこれらのエラーが表示される場合がありますが、無害です。 Gralin_0-1752658621980.png Re: Failed resolution of: Lcom/google/firebase/analytics/FirebaseAnalytics お世話になります。 Firebase の使用を避けることは可能ですが、残念ながら、これらの実装は開発チームが行う必要があります。大変申し訳ございませんが、TapLinx は一部の実装で Firebase に依存しているため、これらの依存関係の削除は、クリーンな Android プロジェクトから開始し、Google および Firebase モジュールのインポートをすべて削除して手動で行う必要があります。 大変申し訳ございませんが、これらの変更を実行するためのガイドはございません。 Re: Failed resolution of: Lcom/google/firebase/analytics/FirebaseAnalytics 簡単な更新ですが、クイックスタートに Firebase のライブラリを含める要件を見つけました。次に、次の点についてまだ提案が必要です。インターネット制限のため、Firebase にアクセスせずにプロジェクトに Firebase を含めると、マターになりますか?

更改时钟设置后 gpio 无法工作 在 s32k324 上，当我们将时钟设置从 160Mhz PLL 更改为 48Mhz FIRC 时，GPIO 不再工作。gpio，而不是任何特定引脚） 我们使用 RTD MCAL API Mcu_InitClock()，更改时钟设置。   但在我们将 PLL 更改为 FIRC 后，我们发现如果读取 GPIO 引脚，即使 HW 为低电平，它们也总是返回高电平。   您有什么建议吗？ Re: gpio not works after change clock settings 我们发现必须调用 Mcu_Init()。 Re: gpio not works after change clock settings 你好 有一个热电阻示例Mcu_Example_S32K344，可通过Mcu_InitClockAPI 切换时钟设置。你测试过吗？ 您是否在时钟工具中启用了 SIUL2 的时钟？ Mcu_InitClock ClockConfig.png 如果还是不行，请给我发送一个简化的测试项目。 祝好， Robin ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题并参考已关闭的主题。 -------------------------------------------------------------------------------

阻塞 i2c 模块问题 早上好、 我正在实施一个大型项目。我每隔几毫秒就运行多个中断。不幸的是，我意识到它与 i2c 模块有冲突，因为我正在使用 i2c_masterTransferBlocking 函数对其进行轮询。这样，它就阻止了我的多次中断。因此，我决定在中断中也使用 i2c 模块。遗憾的是，我不知道如何才能最好地通过中断执行传输，而不需要等待一段时间来完成传输。附件是我目前正在做的一个经过简化的项目，以便我了解如何以最佳方式进行 i2c 传输并在显示屏上打印。 您能就此给我一些建议吗？ 预先感谢 。 Re: Blocking i2c module problem 你好@Transidico， 为了更好地帮助您，您能否说明是否需要终止 I2C 传输才能显示消息？ 如果是这样的话，您的应用程序似乎本身就是阻塞的，因为它需要另一个进程完成后才能继续。鉴于这种依赖性，你们目前实施的方法似乎是最合适的解决方案。 希望对你有所帮助。 BR Habib Re: Blocking i2c module problem 对不起，有什么答案吗？

LS1046AのTA_PROG_SFPピンは常に1.8V電源にコネクテッド。 こんにちは、 LS1046Aを使用しています。 チェックリストから、「セキュア ブート プログラミング中は 1.8 V のみを供給する必要があります」ということがわかりました。通常の動作では、このピンは抵抗器を介してプルダウンする必要があります。' しかし、何らかの理由で、LS1046A の TA_PROG_SFP ピンは、私たちのデザインでは常に 1.8V 電源にコネクテッドされています。このデザインにはどのようなリスクがあるのでしょうか? ご回答をお待ちしています。 Re: The TA_PROG_SFP pin of the LS1046A is always connected to a 1.8V power supply こんにちは@KunChen この投稿があなたに届いていることを願っています。 どういたしまして。お役に立てて嬉しいです。 他に何かお手伝いCANことがございましたら、お気軽にご連絡ください。 すてきな一日を！。 よろしくお願いいたします。 ヘクター・ビジャルルS Re: The TA_PROG_SFP pin of the LS1046A is always connected to a 1.8V power supply こんにちは、ヘクター。 ご返信よろしくお願いします。 Re: The TA_PROG_SFP pin of the LS1046A is always connected to a 1.8V power supply こんにちは@KunChen この投稿があなたに届いていることを願っています。 ご質問に関して、 この動作の結果、ヒューズが切れ、以前と同じ情報が上書きされ、再度プログラムできなくなります。 セキュリティ ヒューズ プロセッサ QorIQ LS1046A、LS1026A データ シート、Rev. 4、06/2020 のセクション 4 の次の情報を参照してください。 SFP ヒューズをプログラムするには、ユーザーは電源シーケンスごとに TA_PROG_SFP ピンに 1.8 V を供給する必要があります。TA_PROG_SFPはヒューズの持続時間中のみ電源を供給してください。 プログラミング サイクル。デバイスごとに 6 回のヒューズ プログラミング サイクルの制限があります。その他すべて TA_PROG_SFP は GND にコネクテッドする必要があります。シーケンス要件 TA_PROG_SFP の上昇と下降を図 9 に示します。デバイスの信頼性を確保するために、 ヒューズプログラミングは推奨ヒューズプログラミング範囲内で実行する必要があります 表4の温度範囲。 すてきな一日を！ BR、 ヘクター・ビジャルル

IMX9352的A55 debug口是否可以改为uart2 在开发IMX93过程发现，硬件是使用uart2作为a55的debug，目前在官方的imx93板子上进行修改，发现不行，需要具体怎么修改或是能不能修改a55的debug口呢？       在默认sdk中，imx93 a55 debug口为uart1，需要把55 debug口修改为uart2。   目前使用原厂的i.mx93开发板，尝试在6.6.23-2.0.0版本的sdk中进行修改，修改的补丁文件为0001-a55-debug-uart2.patch。   目前只对uboot源码进行修改。修改之后烧写新的uboot，uart1不输出，uart2输出乱码：   chenyuansen_2-1723603269601.png   uart1不输出log，可以理解，因为把a55的debug口改为uart2了。 uart2输出乱码，默认uboot源码里配置的串口波特率为115200波特率，这个并未进行改动。   还请确认一下，a55 debug口能不能改为uart2？ 修改补丁是否遗漏其他修改？ Re: IMX9352的A55 debug口是否可以改为uart2 可以了，问题解决了，非常感谢您的支持 Re: IMX9352的A55 debug口是否可以改为uart2 同步修改了optee-os与atf的源码，把debug口也修改为uart2就可以了（编译atf时我使能了opteed） Re: IMX9352的A55 debug口是否可以改为uart2 Hi 忘记ATF也改了： Zhiming_Liu_0-1727251403838.png Best Regards Zhiming Re: IMX9352的A55 debug口是否可以改为uart2 打了提供的这个补丁后，uart2是可以正常输出了，但是程序卡在spl阶段，不会跳到uboot阶段 打补丁：git apply use_uart2_as_console.diff。   chenyuansen_2-1727251021595.png chenyuansen_3-1727251026662.png   Re: IMX9352的A55 debug口是否可以改为uart2 Hi @chenyuansen  保留设备树的修改，去除board/freescale/imx93_evk/imx93_evk.c中的pad设置，我这边可以了。 Zhiming_Liu_0-1727234180469.png 顺便把dtsi里的clock补全 Zhiming_Liu_0-1727234416183.png Best Regards Zhiming Re: IMX9352的A55 debug口是否可以改为uart2 就算不修改，第三个串口也可以输出，应为第三个串口是uart1，默认为a55的debug口，第四个是uart2，默认是m33的debug口 Re: IMX9352的A55 debug口是否可以改为uart2 Hi @chenyuansen  我这边只修改SPL里的uart，可以在Type-C的第三个串口显示log。 Zhiming_Liu_0-1727144505943.png 拨码设置 Image (5).jpg Best Regards Zhiming Re: IMX9352的A55 debug口是否可以改为uart2 是用官方的板子进行测试，没进行硬件修改，使用type-c连接原厂板子的debug口 Re: IMX9352的A55 debug口是否可以改为uart2 Hi @chenyuansen  你们硬件上有改动吗，比如把UART2接出来？还是直接插上type-c的串口线？ Best Regards Zhiming Re: IMX9352的A55 debug口是否可以改为uart2 这个地方也已经有修改了的 chenyuansen_0-1727058701693.png Re: IMX9352的A55 debug口是否可以改为uart2 Hi @chenyuansen  串口需要修改，请参考board/freescale/imx93_evk/imx93_evk.c Zhiming_Liu_0-1726820341121.png Best Regards Zhiming Re: IMX9352的A55 debug口是否可以改为uart2 抱歉，现在才看到回复，附件为补丁包 Re: IMX9352的A55 debug口是否可以改为uart2 Hi 请把0001-a55-debug-uart2.patch这个文件发过来。 Best Regards Zhiming

EVK 无法运行到主代码，调试模式下出现堆栈溢出 我首先使用 RT685 EVK 板。我导入了SDK示例代码，代码构建成功。我使用 SEGGER J-Link 探针进行调试，程序闪存没有问题。但代码如下： 在地址“0x1c04a”处中断，没有可用的调试信息，或者在程序代码之外。 0001c04a: bn 0x1c04a 我不知道为什么？我在调试中暂停这个，堆栈使用情况显示为溢出。现在我无法采取下一步行动。谁能帮助我？非常感谢。 i.MX-RT600 回复： EVK cannot run to main code and stack overflow handed in debug mode 現在已經可以正常工作了, 原來是我下載了SDK_2_16_000_MIMXRT685-AUD-EVK.zip, 但是我的開發板是RT685-EVK, 我重新下載SDK_2_16_000_EVK-MIMXRT685.zip已可以正常工作, 謝謝NXP的支持與協助. ,

過熱時のi.MX8MPの自動パワーオン動作 私は congatec SMARC モジュールと imx8mp プロセッサを使用しています。 要件を明確にするために、次のことを行います。 SMARCモジュールの温度センサーが105°Cに達すると、システムの電源がオフになります。 現在、システムの再起動には手動で電源を入れ直す必要があります。 この動作を変更して、温度がトリガーしきい値を下回ったときにシステムの電源が自動的にオンになるようにしたいと思います。 この動作がSCFW(システムコントローラーファームウェア)で変更できることを示唆する参考文献が見つかりました。ただし、SCFW ファームウェアは i.MX8MP プロセッサには使用されません。 i.MX8MPのブート シーケンスは次のとおりです。 BootROM → SPL → BL31 (ATF - ARM Trusted Firmware) → OP-TEE (オプション) → BL33 (U-Boot) → Linux カーネル。 私たちの理解に基づくと、この行動に対処する可能性のある分野は次のとおりです。 a) BL31(ATF)の改造。 SNVS(Secure Non-Volatile Storage)内の設定の調整。 b) SMARC モジュールに存在する PMIC PCA9450Cを設定して、自動電源オンを有効にします。 PMIC コンフィギュレーションが正しいパスである場合は、自動電源オンの CONFIGURATION PCA9450C に関するドキュメントまたは詳細を提供できますか。 それとも、もっと良い解決策はありますか? 評価ボード Re: i.MX8MP の過熱時の自動電源投入動作 結局、ウェイクアップアラームを設定し、シャットダウンの直前にそれを設定するサービスを追加しました。したがって、システムがトリガーされたり、電源がオフになったりするたびに、アラームがトリガーされます。何もないよりはましです。 エコー +120 > /sys/class/rtc/rtc1/wakealarm   Re: i.MX8MP の過熱時の自動電源投入動作 親愛なるMarco_Savo、 BL31を変更することはオプションではありません。 2番目のオプションは、電源オンシーケンスを開始するためにPMIC_ON_REQをアサートする必要があるため、自動電源オンがないため、不可能です。 FPGA を使用して、PMIC_ON_REQ 信号をアサートできます。

iMXRT10xx SDK MCUBoot 版本 您好， 我正在使用带有 MCUXpresso SDK 24.12.00 的 imxRT1021 MCU 和 McuBoot 作为 SDK 的中间件元器件。 有办法知道 SDK 包含哪个 MCUBoot 版本吗？ 我在代码中进行了搜索，但没有为 MCUBoot 定义任何版本... 谢谢您！ Re: iMXRT10xx SDK MCUBoot version 你好！ 刚刚在 SDK 文档中找到了 McuBoot 版本说明：应该是 2.0.0 MCUboot 版本说明 — MCUXpresso SDK 文档 afacotti_0-1752854285861.png

OpenSSL 无法正确处理 refpem 密钥，nxp 方案正常工作 大家好， 我正在尝试集成 SE050 以便在 node.js 网络服务器中使用。我成功编译了包括 OpenSSL 提供商在内的中间件，还让 sscli 正常工作。 我使用 ssscli 创建了一个密钥对，将其注入 SE 并创建了一个 refpem 密钥。我还修改了系统的 openssl.cnf 文件，使其与 simwtop/demos/linux/common/openssl30_sss_se050.cnf 文件中的一致。 但是，与服务器的任何 TLS 连接都会在握手中失败，因为 OpenSSL 使用对密钥槽的参考作为实际私钥，而不是调用 SE050 提供商。 我还尝试让它与 OpenSSL CLI（即 openssl s_server）配合使用。我可以使用 nxp: 方案获得连接，但不能使用 refpem 密钥文件。 以下命令会导致错误： openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem 错误： SSL3 alert read:fatal:decrypt error SSL_accept:error in error ERROR 20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so 20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 shutting down SSL 不过，如果我使用 nxp 网址方案，就能成功连接到服务器。 openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem 但是，我无法在 node.js 代码中指定 nxp: 0x6789ABCD 密钥参考，但必须使用 refpem 文件。有办法做到这一点吗？ 我还尝试通过在配置文件中指定一个 propquery，让 OpenSSL 优先使用 SE050 提供程序，而不是默认提供程序。但目前还没有收获。 # Relevant parts from openssl.cnf [openssl_init] providers = provider_sect alg_section = evp_properties [provider_sect] default = default_sect nxp_prov = nxp_prov_sec [default_sect] activate = 1 [nxp_prov_sec] identity = nxp_prov module = /usr/local/lib/libsssProvider.so activate = 1 [evp_properties] default_properties = ?provider=nxp_prov 如能得到任何帮助，将不胜感激！ SE050 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 我忘了说，我使用的 Node 版本是 20.12.2。 ，20.x 之后的版本可能没有这个问题，但我目前无法验证。 经过进一步调查，发现客户端解密问题是由于提供程序加载顺序不正确造成的。 不过，这个版本的 Node 在处理随机数生成方面存在问题。 问题与 Node 如何初始化提供程序有关。 node.cc 文件包含一个修复程序（在源代码中带有注释），但它不适用于 libsssProvider.so。 我在此分享一系列变通方法，以防有人遇到类似情况。 首先，我要说的是，这些都与 libsssProvider 有关，主要目的是不更改 Node 或 OpenSSL，因此显然可以采用其他更简洁的解决方案。 我不能分享代码，希望下面的信息足够清楚。 可用选项： 1.在 CMakeLists.txt 文件中，设置 SSS_PROV_DISABLE_SE05X_RNG 变量。 这就完全禁止了 SE05X 的随机使用。 这并不理想，但如果你没有任何特殊需要，它还是可行的。 2.在 sssProvider_main.c 中文件，更改 srands 结构的算法，使提供的名称不是已知名称之一（尤其不是默认名称）。 3. 与第 2 点类似，但在这种情况下，名称可选择由环境变量提供（srands 显然不能是常量）。这样，只有在 Node 应用程序中才能避免使用 SE05X 随机发生器，而将其用于其他用途。 有了这些选项， refpems 可以正常工作。 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 我遇到了与@tksec 完全相同的问题。 如果使用 OpenSSL cli 工具，一切正常，我可以通过 libsssProvider.so 使用 SE052 模块中的密钥建立 TLS 连接。 关于 Node.js、我确认 libsssProvider 已加载，但握手总是失败，错误如下： SSL3 alert write:fatal:decrypt error SSL_connect:error in error 20109DB6FFFF0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584： @Kan_Li所建议的通过 id 调用键似乎并不奏效： - 如果我在 options.key 中提供 refpem 文件的路径，服务器就能顺利启动并监听连接，但正如报告所述，握手失败。 - 如果我在 options.key 中提供 urk 密钥路径（nxp: ），应用程序就会崩溃。 -如果我在 options.key 中提供密钥参考 (nxp: ) 应用程序会崩溃 那么，能否请@Kan_Li分享一段可以成功初始化服务器的 Node.js 代码，假设如上所述，这应该可以正常工作？ 谢谢！ Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 嗨 @tksec， 你找到在 node.js 中使用密钥参考的合适方法了吗？ 我也有类似的问题。我正在使用带有 OpenSSL 3.0.14 的 se05x-openssl-provider (v01.00.03) 来生成密钥对，但我无法按照 openssl 提供商 Github 仓库自述文件中的描述使用文件格式为 " 的 " 参考密钥。 其他两个版本（带有参考密钥的标签（示例-恩智浦：" 参考密钥文件路径 "）和带有密钥 ID 的 标签（示例-nxp: 0x12345678）运行良好。 自述文件内容如下：" 注意：使用此方法时，必须先加载 sss 提供程序。这将确保 sss 提供商可以解码引用密钥中存在的密钥 ID 信息 。 " 遗憾的是，我不知道如何做到这一点。通过在 openssl.cnf 文件中添加提供程序来加载提供程序对我来说不起作用。如果我想使用文件格式的参考密钥，我仍然会遇到解密错误。 在此先表示感谢。 致以最诚挚的问候 托马斯 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 感谢您提供的信息！您使用 refpem 文件的用例是什么？签署&验证？我可以尝试在这里重现这个问题。 顺祝商祺！ 坎 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@Kan_Li、 是的，我使用了 ssscli 工具。我运行的是 MW v4.05.00。我在另一个系统上用 OpenSSL 创建了原始密钥。使用 ssscli set 命令将其加载到 SE 中，并使用 ssscli refpem 命令创建 refpem。在使用 s_client、s_server、rsa 等 openssl 命令时，可以成功使用和解析该密钥。也可以使用 OSSL_STORE API（openssl 命令的内部功能）将其转换为 EVP_PKEY，但使用 PEM_read_bio_PrivateKey 无法解析，而 NXP 引擎（在 EmbSe_LoadPrivKey 中）和 node.js 都使用 PEM_read_bio_PrivateKey。 谢谢您！ Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 您是如何为 RSA 密钥生成 refpem 的？您现在使用的是哪个版本的 MW？请予以澄清。 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 ------------------------------------------------------------------------------- Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@Kan_Li 谢谢你说明 refpem 密钥只能用于 openssl 引擎。特别是 node.js 的问题在于，它们会直接对提供的任何密钥字符串调用 PEM_read_bio_PrivateKey 函数，而当密钥字符串不是 PEM 字符串或文件路径而是 uri 时，该函数显然会失效。目前还没有对 OpenSSL 提供商的直接支持。 我改回使用 OpenSSL 引擎，结果也遇到了类似的问题。使用 EC 密钥时工作正常，而使用 RSA 密钥时，在解析 PEM 文件时再次出现错误：1E08010C:DECODER routines::unsupported from OpenSSL。我调试了代码，可以将错误追溯到 PEM_read_bio_PrivateKey 函数，该函数在引擎代码中的 EmbSe_LoadPrivKey 中调用。 您知道在 OpenSSL 引擎中处理 RSA refpem 密钥的问题吗？如何解决这个问题？在我看来，RSA 的 refpem 比 EC 密钥的侵入性更强，这可能是个问题？ Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working 你好@tksec、 refpem 密钥文件仅适用于 openssl 引擎，但由于您使用的是带有提供程序的 openssl 3.xx，因此请使用"nxp:key_id" 代替。你可以将"se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh" 与"se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh" 进行比较，检查两者的区别。 我还想知道你对此是否有任何网络安全问题，实际上从我的选择来看，它只是大多数脚本应该接受的字符串，为什么不能在 node.js 代码中指定 nxp: 0x6789ABCD 密钥参考？请澄清。 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------