I2C read and write using s32k144 MBD toolbox Hello, I am using s32k144 to read and write data from an external EEPROM. I will attach the model below. I am able to write the data but the read returns 255+NACK as output. Am i missing something here Sriram_0-1737789999186.pngSriram_0-1737789999186.png Sriram_1-1737790013461.pngSriram_1-1737790013461.png Is there a way to specify the register address of the EEPROM in the I2Cmaster block Sriram_2-1737790096449.pngSriram_2-1737790096449.png Can you guys help me out with this issue. Thanks Re: I2C read and write using s32k144 MBD toolbox Hi, I am also facing the same issue with I2C communication using the S32K144 as the master and the ST M24C04 EEPROM as the slave. Since you are using the same microcontroller and EEPROM, I wanted to check whether you were able to find a solution. If you have resolved this issue, could you please share the solution or let me know what fixed it? Thank you in advance for your help. Re: I2C read and write using s32k144 MBD toolbox I m using M24C02-DRE EEPROM

S32 Design Studio Installation Issue I am facing issues in S32 Design Studio (V3.6.4) Installation. The installation's progress bar finishes immediately once I start the installation, but I could not see any installed application. Please guide me on resolving this issue. The system specs are Windows 11, 16GB RAM, 1TB SSD. Note this system is under our Company's IT policies. Re: S32 Design Studio Installation Issue Please find below the requested log files. We tried to do the installation twice, but it was not successful. Re: S32 Design Studio Installation Issue Hi @ashutoshsahu  Could you please share the installation log file (.log)? It should be located under: C:\NXP\S32DS.3.6.4\_S32 Design Studio for S32 Platform 3.6.4_installation\Logs BR, VaneB Re: S32 Design Studio Installation Issue Hi @ashutoshsahu  I have reviewed the installation logs and identified an important error that occurred when the installer attempted to run powershell -ExecutionPolicy Bypass -File parallel.ps1: "This program is blocked by group policy. For more information, contact your system administrator." Based on this error, it may be worth checking with your IT team to verify that there are no security policies, Group Policy restrictions, firewall rules, or proxy settings that could be preventing the PowerShell script from running correctly. 

「スマートエネルギー」太陽光発電に関する意見 今日はスマートエナジーという会社の訪問販売員が何人か来て、太陽光パネルについて話したがっていました。太陽光発電に興味はあるのですが、初期投資をする資金がありません。そこで、初期費用ゼロで利用できる政府資金による制度があると聞きました。 もちろん、私は非常に懐疑的です。彼らと取引したことのある方からのご意見をぜひお聞かせください。 Re: Opinions on "Smart Energy" solar こんにちは、 時には「前払い0ドル」という提案は、実際には第三者の会社が屋根にパネルを無料で設置してくれることもありますが、その会社がシステムの所有者です。クリーンエネルギーの株式を取得することはできず、その代わりに、発電された電力を購入する長期契約（多くの場合20年から25年）に縛られることになる。これらは後で家を売るのを複雑にすることがあります。 よろしくお願いします

Secondary failed allocate mbuff from DPDK Pool hi All, Using : LX2160  LSDK 2108 main  MC firmware version: 10.32.0 DPDK Version : dpdk_19_11_tags_LSDK20.04-isc-09 Primary ( DPDK ) Process : Create a mbuff Pool using [ rte_pktmbuf_pool_create("dlmempool", ] Secondary ( DPDK ) Process : fails to allocate mbuff using API [ rte_pktmbuf_alloc(mempool) ] In Secondary i can see mempool is correct. I can see mbuff available is full. The failure happens for 1st mbuff allocation using  rte_pktmbuf_alloc. Any solution for this. Thanks. Re: Secondary failed allocate mbuff from DPDK Pool thanks i will try these options and update you by tomorrow Re: Secondary failed allocate mbuff from DPDK Pool Hello, The secondary process must map hugepages at the same virtual address as the primary. If ASLR is active, the secondary will resolve the mempool pointer to a different virtual address, causing the first allocation to fail. echo 0 > /proc/sys/kernel/randomize_va_space   Run this before launching either the primary or secondary process. 2. Provision Sufficient DPMCP Objects Create as many DPMCP objects as the total number of processes (primary + secondary). For 1 primary + 1 secondary, you need at least 2 DMPCPs: export DPMCP_COUNT=3 # for 1 Primary + 2 Secondary (always provision +1 as buffer) ./dynamic_dpl.sh dpmac.X 3. Provision Sufficient DPIO Objects Each process needs its own DPIO portals. The formula is: (Total Processes) × (cores per process + 1 extra per process) For example, 1 primary (2 cores) + 1 secondary (2 cores) = at minimum 9 DPIOs. export DPIO_COUNT=20 # set generously 4. Correctly Blacklist/Whitelist Devices in the Secondary The secondary process must NOT re-initialize I/O devices (dpni, dpbp, dpcon, dpseci). Only dpio and dpmcp should be initialized by the secondary. Pass the correct blacklist flags: # Secondary process example — blacklist all dpni/dpbp/dpcon, allow only dpio + dpmcp ./your_secondary_app --proc-type=secondary \ -b fslmc:dpni.X \ -b fslmc:dpbp.X \ -b fslmc:dpcon.X \ -- [app args]   Or alternatively, explicitly whitelist only the dpio and dpmcp objects assigned to the secondary: ./your_secondary_app --proc-type=secondary \ -w fslmc:dpio.Y \ -w fslmc:dpmcp.Z \ -- [app args] 5. Use --proc-type=secondary EAL Argument Ensure the secondary is launched with the correct EAL flag: ./your_secondary_app -c -n 1 --proc-type=secondary ...   Or use --proc-type=auto to let DPDK auto-detect. 6. Verify the Mempool Lookup in Secondary In the secondary, do not call rte_pktmbuf_pool_create again. Instead, look up the existing pool created by the primary: // In secondary process: struct rte_mempool *mempool = rte_mempool_lookup("dlmempool"); if (mempool == NULL) { // Error: pool not found — ASLR or hugepage mapping issue } struct rte_mbuf *m = rte_pktmbuf_alloc(mempool);     If rte_mempool_lookup returns a valid non-NULL pointer but rte_pktmbuf_alloc still returns NULL, the issue is almost certainly the DPIO portal not being initialized for the secondary's thread/core.   Regards Re: Secondary failed allocate mbuff from DPDK Pool thanks @Bio_TICFSL for the quick solution

关于“智能能源”太阳能的观点 今天有几个来自 Smart Energy 的推销员上门推销太阳能电池板。我对太阳能很感兴趣，但没有足够的资金进行前期投资，他们提到有一个政府资助的计划，无需预付任何费用。 我自然非常怀疑。很想听听和他们打过交道的人的意见。 Re: Opinions on "Smart Energy" solar 你好， 有时，“0 美元预付款”的推销实际上意味着第三方公司免费将太阳能电池板安装在你的屋顶上，但系统的所有权归他们所有。你无法获得清洁能源权益，反而会被锁定在一份长期合同（通常是 20 到 25 年）中，购买他们生产的电力。这些都可能使日后卖房变得复杂。 此致

NXP S32k118 I2C 仿真 你好， 我正在评估一种方法，即在不使用 I2C 多路复用器的情况下，从 S32K118 (Q48) 主设备同时驱动 10 个地址相同的 I2C 从设备。 我的计划是使用硬件定时器生成时钟来模拟 10 个并行的 I2C 总线，并结合 DMA 传输来同时更新同一端口上的 10 个 GPIO 引脚。 能否帮忙确认一下 S32K118 的 DMA 和定时器外设是否支持以这种方式触发端口范围的 GPIO 更新？这种架构是否存在我需要注意的硬件限制或特殊情况？ 顺祝商祺！ Re: NXP S32k118 I2C emulation 嗨@Luke_John ， 是的，这种架构从根本上来说是支持的。 请参阅 S32K1xx 系列参考手册，修订版 14： 第 13.3.1 节 GPIO 寄存器描述。 如您所见，所有 GPIO 端口均可通过 32 位寄存器访问。 第 17.4.1 节 “使用 GPIO 端口驱动或采样波形 通过配置 DMA 将数据传输到一个或多个 GPIO 端口，可以使用存储在片上存储器中的表格数据创建复杂的波形。反之，利用DMA定期从一个或多个GPIO端口传输数据，可以对复杂的波形进行采样，并将结果以表格形式存储在片上存储器中。 DMA 传输可以通过定时器经由 DMAMUX、TRGMUX 触发。 必须将交叉开关编程为轮询仲裁（将 MCM_CPCR[CBRR] 配置为“1”），才能实现无缝 DMA 传输。 此致， 丹尼尔

从 DPDK 池分配 mbuff 失败 大家好， 使用：LX2160 LSDK 2108 主程序 MC固件版本：10.32.0 DPDK 版本：dpdk_19_11_tags_LSDK20.04-isc-09 主进程 (DPDK)：使用 [ rte_pktmbuf_pool_create("dlmempool", ] 创建 mbuff 池 辅助（DPDK）进程：使用 API [ rte_pktmbuf_alloc(mempool) ] 分配 mbuff 失败 在辅助内存池中，我可以看到内存池是正确的。我看到mbuff可用空间已满。第一次使用 rte_pktmbuf_alloc 进行 mbuff 分配时发生失败。 有什么解决办法吗？谢谢。 Re: Secondary failed allocate mbuff from DPDK Pool 谢谢，我会尝试这些方法，明天再向您汇报。 Re: Secondary failed allocate mbuff from DPDK Pool 你好， 辅助进程必须将大页映射到与主进程相同的虚拟地址。如果 ASLR 处于活动状态，则辅助内存池指针将解析到不同的虚拟地址，导致第一次内存分配失败。 echo 0 > /proc/sys/kernel/randomize_va_space   在启动主进程或辅助进程之前运行此程序。 2. 配置充足的DPMCP对象 创建与进程总数（主进程 + 辅助进程）相同的 DPMCP 对象数量。对于 1 个主要处方药 + 1 个次要处方药，您至少需要 2 个 DMPCP： export DPMCP_COUNT=3 # for 1 Primary + 2 Secondary (always provision +1 as buffer) ./dynamic_dpl.sh dpmac.X 3. 配置足够的DPIO对象 每个流程都需要自己的 DPIO 门户。公式为： （总进程数）×（每个进程的核心数 + 每个进程额外 1 个核心） 例如，1 个主处理器（2 个核心）+ 1 个辅助处理器（2 个核心）= 至少 9 个 DPIO。 export DPIO_COUNT=20 # set generously 4. 在辅助设备中正确设置黑名单/白名单设备 辅助进程不得重新初始化 I/O 设备（dpni、dpbp、dpcon、dpseci）。只有 dpio 和 dpmcp 应该由辅助节点初始化。传递正确的黑名单标志： # Secondary process example — blacklist all dpni/dpbp/dpcon, allow only dpio + dpmcp ./your_secondary_app --proc-type=secondary \ -b fslmc:dpni.X \ -b fslmc:dpbp.X \ -b fslmc:dpcon.X \ -- [app args]   或者，也可以明确地将分配给辅助节点的 dpio 和 dpmcp 对象列入白名单： ./your_secondary_app --proc-type=secondary \ -w fslmc:dpio.Y \ -w fslmc:dpmcp.Z \ -- [app args] 5. 使用 --proc-type=secondary EAL 参数 确保备用服务器使用正确的 EAL 标志启动： ./your_secondary_app -c -n 1 --proc-type=secondary ...   或者使用 --proc-type=auto 让 DPDK 自动检测。 6. 验证辅助内存池查找 在辅助节点中，不要再次调用 rte_pktmbuf_pool_create 。相反，查找主节点创建的现有池： // In secondary process: struct rte_mempool *mempool = rte_mempool_lookup("dlmempool"); if (mempool == NULL) { // Error: pool not found — ASLR or hugepage mapping issue } struct rte_mbuf *m = rte_pktmbuf_alloc(mempool);     如果 rte_mempool_lookup 返回一个有效的非 NULL 指针，但 rte_pktmbuf_alloc 仍然返回 NULL，则问题几乎肯定是辅助线程/核心的 DPIO 门户没有被初始化。   此致 Re: Secondary failed allocate mbuff from DPDK Pool 感谢@Bio_TICFSL的快速解决方案

S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Board: S32K311-EVB Module: FlexCAN0 Tool: Vector CANoe connected via J8 connector Debug probe:  J-Link  I am implementing the CAN protocol on the S32K311-EVB using FlexCAN0. Loopback mode test (working): I first implemented and tested FlexCAN0 in internal loopback mode. This worked successfully — messages transmitted were correctly received back through my "void CanIf_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr )"  handling function, confirming that my basic FlexCAN0 configuration (clock setup, bit timing, message buffer initialization) is functioning correctly. External communication test (not working): I then moved to testing external CAN communication: Configure PTA6 and PTA7 pin in pin configuration. Connected Vector CANoe to the board via the J8 connector. In CANoe configuration, I unchecked "CAN Loopback Mode." Attach 12 V Adapter  Started CANoe transmission — CANoe shows it is sending CAN frames. However, on the S32K311 side, nothing is received — CanIf_RxIndication(the same function that worked correctly in loopback mode) is never called/triggered. For debugging i use segger RTT viewer using JTAG Configuration Sami2098_0-1789478804307.pngSami2098_0-1789478804307.pngSami2098_0-1789478804307.png Sami2098_1-1789478831337.pngSami2098_1-1789478831337.pngSami2098_1-1789478831337.png Sami2098_2-1789478911944.pngSami2098_2-1789478911944.pngSami2098_2-1789478911944.png Sami2098_3-1789478932611.pngSami2098_3-1789478932611.pngSami2098_3-1789478932611.png  Best regards.   Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Hello @Sami2098, Could you share RTD version you are currently using? There are some examples in our community you can use as reference:  Re: CAN Example for S32K311 - NXP Community Example S32K312 CAN Transmit & Receive Using Polling mode DS3.5 RTD300 [RTD600 MCAL & IP] S32K3X4EVB-T172 FlexCAN Example Interrupt/Polling FlexCAN configuration overall looks OK. Can you confirm PTA6/7 are configured as input and output, respectively, and you are indeed calling Siul2_Port_Ip_Init() API to initialize Port? Julin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.png Since you are using S32K1XEVB, transceiver used is FS23, and when the FS23 is in Debug mode, the CAN transceiver is set to Active mode by default, thus there is no need to set CAN_MODE = 0b1x. I would also suggest checking that the bitrate and sampling point configured is the same between S32K311<->CANoe. Lastly, if you have a logic analyzer or an oscilloscope, could you share the CANTXD, CANRXD, CANH and CANL signals? Best regards, Julián Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Hi Julián_AragónM Thanks for looking into this. I found the root cause — it was actually a CANoe channel bus configuration issue on my end, not a problem with the S32K311 CAN driver configuration. After correcting the CANoe Vector configuration, reception is working fine now. Follow-up question: I'm currently running at 500 kbps, and I understand that if I switch to a different baud rate (e.g., 125 kbps), several dependent parameters need to be recalculated — such as the Prescaler, Propagation Segment, Phase Segment 1, Phase Segment 2, and Resync Jump Width — to maintain correct bit timing and sample point relative to the CAN peripheral clock. Could someone point me to a reference/guide document that explains: How these bit timing parameters (Prescaler, Prop Seg, PS1, PS2, SJW) relate to and are derived for different target baud rates. Recommended sample point ranges for different baud rates in an automotive/industrial context. Any official NXP application note or reference specific to the S32K3xx FlexCAN MCAL (AUTOSAR) configuration tool for bit timing calculation. I'm using the MCAL layer in AUTOSAR mode (S32 Configuration Tool for Can driver configuration), so a guide aligned with this configuration flow (rather than register-level FlexCAN programming alone) would be especially helpful. Thanks in advance for your guidance. Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Hello @Sami2098, 1. The chapter 73.3.10.8 (Protocol timing) from S32K3XX Reference Manual Rev. 12 explains bit timing configuration, and its various parameters. 2. This really depends on your application and configuration; however, nominal bitrates include 125 kbps, 250 kbps, and 500 kbps. 3. You can refer to our FlexCAN bit timing calculation sheet. You can also refer to the S32K3XX FlexCAN with RTD Training sildes. Best regards, Julián

S32DS for ARM 2018.R1 デバッグ問題 ARM 2018.R1用のS32DSでチップのデバッグ時に問題が発生しS32K146、以下の通りです: 送信後にGDBバージョンを特定できませんでした:D:\S32DS\eclipse\./Cross_Tools/gcc-arm-none-eabi-4_9/bin/arm-none-eabi-gdb --version、応答: しかし、Jlinkはチップの編集や消去、プログラムが可能です。私はARM 2018.R1のS32DSでデバッグしていません。助けてください。ありがとうございます! Re: S32DS for ARM 2018.R1 debug Problem Hi@lyz あなたの質問の意味がよく分かりませんでした。エラーのスクリーンショットを投稿してもらえますか?

i.P-384秘密鍵/ブラックブロブの利用ケースにおけるMX8DXL CAAMカバーの制限 こんにちは、NXPチームの皆様、 私たちは、i.MX8DXL CAAMにおけるECDSA P-384ブラックキー/ブロブのサポートを評価しています。 観察された結果 P-256 外部から提供された平文のP-256秘密鍵から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（CAAM生成の黒鍵） ECDSA秘密鍵をKEY_COLOR_BLACKとして生成する COVER操作なしで秘密鍵からブラックブロブを生成する 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（外部平文秘密鍵） 外部から提供された平文のP-384秘密鍵（48バイト）から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 追加の観察 NXPのパッチに以下のコメントがあることに気づきました。 https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEYコマンドは32バイトに制限されているようなので、ロードを使うべきです * コマンドは最大64バイトまで読み込み可能です。 * * TODO: KEYコマンドは、より大きなキーをロードできるようにする必要があることを示しています * 32バイトより小さいが、実際には機能しない * * TODO: LOAD コマンドは最大 96 までロードできるはずです * バイトキーは実際には機能せず、64バイトに制限されています */ 我々も同様の挙動を観察した。 KEYコマンドの代わりにLOADコマンドを使用することで、48バイトのP-384秘密鍵を含む、32バイトを超える鍵を扱うことができます。 しかし、これは上記の問題を解決するものではありません。鍵は覆ってブロブに保存できますが、復元された黒鍵はECDSA署名や検証に成功裏に使用できません。   私たちの質問： CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？ COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか? 観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？ 外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか? 何かアドバイスをいただければ幸いです。 ありがとうございます。よろしくお願いいたします。 ホジャメス。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 補足事項：   私たちの懸念はECDSAのユースケースに限られません。   COVERを介して外部のP-384秘密鍵をインポートすることがECDSAの標準ワークフローではないとしても、COVER操作自体の制限事項を理解しておきたいと考えています。   当社のアプリケーションでは、COVER操作はECDSA秘密鍵だけでなく、一般的な機密データの保護にも利用されることがあります。したがって、32バイトを超えるペイロードサイズのサポートは重要な考慮事項です。 我々のテストに基づくと、LOADコマンドの回避策を用いることで、32バイトを超えるペイロードを処理できることがわかった。約80バイト以下のペイロードは正常に動作するようですが、それより大きいサイズでは動作が不安定になります。これらの観察結果が、実際のCAAMの制限を反映しているのか、それとも実装上の問題を反映しているのかを理解したいと考えています。 また、ECDSAのユースケースとは独立して、COVER操作自体に文書化されたサイズ制限があるかどうかもNXPは明確にしていただけますか?   よろしくお願いします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case このCAAM機能をテストするための環境を構築する必要があります。結果が出次第、ご連絡いたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case こんにちは、イーピンワンさん ご返信ありがとうございます。 >>この部分で、どのようなCAAMエラーが発生していましたか？ >>エラーコードを教えてもらえますか? ECDSA関連のすべての操作には、以下のコードパッチを使用しています。 " https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch " 署名検証のために caam_ecdsa_verify() を呼び出すとき、 'ECDSA_VERIFY_FAIL (0)' を返します。 このエラーは「P-384 (external plaintext private key)」の場合のみ発生します。 >> アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストしていますか? 私たちの成功例については、はい、似ています。 しかし、失敗したケース『P-384(外部平文秘密鍵)』については、 少し違います。鍵は外部から来ています。 よろしくお願いいたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 「プレーンテキストキー → カバー → 黒キーの塊」 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 この部分で、どのようなCAAMエラーが発生していましたか？エラーコードを教えてもらえますか?アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストされていますか?ありがとう。 KEYコマンドの制限については、現在も調査中です。

S32DS for ARM 2018.R1 调试问题 使用 S32DS for ARM 2018.R1 调试 S32K146 芯片时出现问题，具体如下： 发送以下命令后无法确定 GDB 版本：D:\S32DS\eclipse\../Cross_Tools/gcc-arm-none-eabi-4_9/bin/arm-none-eabi-gdb --version，响应如下： 但是，Jlink 可以连接、擦除和编程芯片。我现在无法使用 S32DS for ARM 2018.R1 进行调试，请帮帮我，谢谢！ Re: S32DS for ARM 2018.R1 debug Problem 嗨@lyz 我不太明白你的问题。能否提供一下错误截图？

SC18IM704 不工作 大家好 我使用 STM32F407 与 SC18IM704 芯片进行 UART 通信。STM32 的 UART 外设成功地向 tx 发送了数据，但是 rx 上没有来自 SC18IM704 的反馈。主板开机时。UART 波特率为 9600 位/秒。 该电路板的示意图如图所示。 3046B74B-E9DE-4e11-8E23-9134E0817F20.png3046B74B-E9DE-4e11-8E23-9134E0817F20.png3046B74B-E9DE-4e11-8E23-9134E0817F20.png 我使用 SC18IM704 的读取版本功能 ID 命令，如图所示 SDS1204X_HD_JPG_1.jpgSDS1204X_HD_JPG_1.jpgSDS1204X_HD_JPG_1.jpg 没有 SC18IM704 的数据反馈 I2C UART Re: SC18IM704 does not work 你好、 根据 SC18IM704 数据表，开机后，SC18IM704 会向主机发送两个字节。开机后你会收到这两个字节吗？ JozefKozon_0-1779954086888.pngJozefKozon_0-1779954086888.pngJozefKozon_0-1779954086888.png 如果您没有收到这两个字节，请检查 RESET 引脚是否为高电平。请移除 TX 和 RX 线路上的 10k 上拉电阻。只有 RX 引脚需要上拉电阻，并且只有当您想保持 SC18IM704 处于深度省电模式时才需要上拉电阻。否则，TX 和 RX 线路上不应使用上拉电阻。 致以最崇高的敬意 约瑟夫 Re: SC18IM704 does not work 你好 谢谢您的确认。请移除 R106 电阻，断开 TX 引脚与 MCU 的连接。为了确保 TX 引脚处于浮空状态（不被 MCU 保持在高位）。然后打开 SC18IM704 的电源，用示波器测量 SC18IM704 上的 TX 引脚，查找 " OK "，两个字节 0x4F 和 0x4B。 如果你仍然看不到 " OK " 请使用 RESET 引脚进行重置。 1.用示波器观察 TX 2。按住 RESET LOW (GND) 约 10 ms 3.版本到 HIGH 4.查看是否出现"OK"   致以最崇高的敬意 约瑟夫 Re: SC18IM704 does not work 你好，约瑟夫： 我检查 SC18IM704 的 RESET 引脚是否为高电平 (3.3V)在 SC18IM704 上电后用示波器测量。我没有通过示波器找到两个字节（'OK'）。我去掉了 TX 和 RX 线路上的 10k 上拉电阻。我使用四个 SC18IM704 芯片，情况也是一样。 我不知道如何解决这个问题，请帮帮我。 Re: SC18IM704 does not work 您好，我也遇到了类似的问题，我已经移除了 Rx 和 Tx 电阻，但仍然显示不正常。 接下来常见的故障排除步骤有哪些？或者是否有推荐的设计方案可以参考？ Re: SC18IM704 does not work 我也遇到了同样的问题。 几年前我用 SC18IM704 制作了一块电路板，它工作正常。 然而，最近当我再次组装同样的电路板时，却遇到了完全无法工作的板。具体来说，向复位引脚发送复位信号没有得到任何确认（OK）。此外，向RX引脚发送命令没有任何响应——版本信息和I2C命令都无法正常工作。 由于我手头正好有一批旧货，我就试着换上去，结果运行正常。 某些批次的集成电路本身似乎存在重大问题。请在本帖中分享有问题的地块。 -工作 18IM704 355.101ZXD23 13 18IM704 355.101ZXD23 25 18IM704 355.103 ZXD22 32 不工作 18IM704 265.102ZXD21 35

SC18IM704は動作しません やあみんな！ 私はSC18IM704チップとのUART通信にSTM32F407を使用しました。STM32のUARTペリフェラルはtxに正常にデータを送信しましたが、ボードの電源投入時にrxのSC18IM704からフィードバックがありませんでした。UARTのボーレートは9600ビット/秒です。 基板の概略図を図に示す。 3046B74B-E9DE-4e11-8E23-9134E0817F20.png3046B74B-E9DE-4e11-8E23-9134E0817F20.png3046B74B-E9DE-4e11-8E23-9134E0817F20.png 図に示すように、SC18IM704のRead version function IDコマンドを使用します。 SDS1204X_HD_JPG_1.jpgSDS1204X_HD_JPG_1.jpgSDS1204X_HD_JPG_1.jpg SC18IM704に関するデータフィードバックは提供されていません。 I2C UART Re: SC18IM704 does not work こんにちは、 SC18IM704のデータシートによると、SC18IM704は電源投入後、ホストに2バイトを送信します。電源投入後、これらの2バイトを受信しますか？ JozefKozon_0-1779954086888.pngJozefKozon_0-1779954086888.pngJozefKozon_0-1779954086888.png これらの2バイトを受信していない場合は、RESETピンがハイになっているかどうかを確認してください。TXラインとRXラインにある10kΩのプルアップ抵抗を取り外してください。RXピンのみにプルアップ抵抗が必要であり、SC18IM704をディープパワーダウンモードに維持したい場合に限ります。それ以外の場合は、TXラインとRXラインにプルアップ抵抗を接続してはいけません。 敬具、 ヨゼフ Re: SC18IM704 does not work こんにちは、 ご確認いただきありがとうございます。TXピンをMCUから切り離すには、R106抵抗を取り外してください。TXピンがフローティング状態（MCUによってハイレベルに保持されていない状態）であることを確認してください。次に、SC18IM704の電源を入れ、オシロスコープを使用してSC18IM704のTXピンを測定し、「OK」、つまり2バイトの0x4Fと0x4Bを探します。 それでも「OK」が表示されない場合は、RESETピンを使用してリセットを実行してください。 1. オシロスコープでTXを観察する 2. RESET LOW (GND) を約10ミリ秒間保持します。 3. HIGHにリリース 4. 「OK」が表示されるか確認してください。   敬具、 ヨゼフ Re: SC18IM704 does not work こんにちは、ヨゼフさん。 SC18IM704のRESETピンがハイ（3.3V）であることを確認しました。SC18IM704の電源を入れた後、オシロスコープで測定しました。オシロスコープで2バイト（'OK'）を見つけることができませんでした。TXラインとRXラインの10kΩプルアップ抵抗を取り外しました。私はSC18IM704チップを4個使用していますが、状況は同じです。この問題の解決方法がわかりません。助けてください。 Re: SC18IM704 does not work こんにちは、私も同様の問題に直面しています。Rx と Tx の抵抗器を取り外しましたが、それでもまだ正常と表示されません。 次によく考えられるトラブルシューティングのステップや、検討できるおすすめの**デザイン**はありますか? Re: SC18IM704 does not work 私も同じ問題に直面しています。 数年前にSC18IM704を使って基板を製作しましたが、正常に動作しました。 しかし、最近同じ基板を再度組み立てたところ、全く動作しないという問題が発生しました。具体的には、リセットピンにリセット信号を送っても、応答（OK）は返ってきません。さらに、RXピンにコマンドを送信しても応答がなく、バージョン情報もI2Cコマンドも機能しない。 手元に古いロットがあったので、それを入れ替えてみたところ、正常に動作しました。 特定のロットにおいて、IC自体に重大な問題があるようです。このThreadで問題のあるロットもぜひ共有してください。 -仕事 18IM704 355.101 ZXD23 13 18IM704 355.101 ZXD23 25 18IM704 355.103 ZXD22 32 - 機能しない 18IM704 265.102 ZXD21 35

i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Hi NXP team, We are evaluating ECDSA P-384 black key/blob support on i.MX8DXL CAAM. Observed results P-256 Starting from an externally provided plaintext P-256 private key: Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: PASS P-384 (CAAM-generated black key) Generate ECDSA private key as KEY_COLOR_BLACK Generate black blob from private key without COVER operation Restore black key from black blob ECDSA sign/verify Result: PASS P-384 (external plaintext private key) Starting from an externally provided plaintext P-384 private key (48 bytes): Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: FAIL Additional observation We noticed the following comments in the NXP patch: https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEY commands seems limited to 32 bytes, so we should use the load * command instead which can load up to 64 bytes. * * TODO: The KEY command indicate it should be able to load key bigger * than 32bytes but it doesn't work in practice * * TODO: The LOAD command indicate it should be able to load up to 96 * byte keys it doesn't work in practice and is limited to 64 bytes */ We observed similar behavior. Using the LOAD command instead of the KEY command allows us to handle keys larger than 32 bytes, including a 48-byte P-384 private key. However, this does not resolve the issue above. Although the key can be covered and stored in a blob, the restored black key cannot be used successfully for ECDSA sign/verify.   Our questions: Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes? Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case? Is the observed behavior expected due to a CAAM hardware limitation? Is there a recommended CAAM method to import an externally generated P-384 plaintext private key and use it as a black key for ECDSA operations? Any guidance would be appreciated. Thanks and best regards, hojames. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Additional note:   Our concern is not limited to the ECDSA use case.   Even if importing an external P-384 private key through COVER is not a supported ECDSA workflow, we would still like to understand the limitations of the COVER operation itself.   In our application, the COVER operation may also be used to protect general sensitive data, not only ECDSA private keys. Therefore, support for payload sizes larger than 32 bytes is an important consideration. Based on our testing, using the LOAD-command workaround allows handling payloads larger than 32 bytes. Payloads below approximately 80 bytes appear to work, while larger sizes show inconsistent behavior. We would like to understand whether these observations reflect an actual CAAM limitation or an implementation issue. Could NXP also clarify whether there are any documented size limitations for the COVER operation itself, independent of the ECDSA use case?   Thank you. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case We need to set up the environment to test this CAAM function. We will update you once We have some results. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Hi yipingwang, Thanks for the reply. >>For this part, what CAAM error did you observed? >>Could you provide the error code? We are using below code patch for all ECDSA related operations: "https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch" when calling caam_ecdsa_verify() for signature verification, it returns 'ECDSA_VERIFY_FAIL (0)'. The error occurs only with the case 'P-384 (external plaintext private key)'. >> The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation? For our succeed cases, yes, they are similar. But for our failed case 'P-384 (external plaintext private key)', it is a bit different: the key is from external. Best regards, Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case "Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: FAIL" For this part, what CAAM error did you observed? Could you provide the error code? The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation? Thank you.  For the KEY command limitation, it is still under investigation. 

T1042NXE BSDLファイル こんにちは、このコンポーネントのBSDLファイルを探しています。 T1042NXE7PQB BGA780 ファイルを送ってもらえますか? よろしくお願いします。 Re: T1042NXE BSDL file こんにちは、 コンポーネントT1042NXE7PQBの BSDL ファイルは、 T1040/T1042 結合 BSDL ファイル(ファイル名: T1040_and_T1042_1.1.bsdl ) に含まれています。この単一のファイルはT1040とT1042の両方のプロセッサに適しています。 ダウンロード方法 このファイルはNXPの製品ページの「 Design Resources → Design Files → モデル」で直接入手可能です: T1040/42用BSDLファイル — ダウンロード（アカウント登録が必要です） ファイルコード: T1040-T1042-BSDL 改訂版：R1A（2019年2月20日） サイズ：110.13 KB よろしくお願いします。

HSE FWの真正性を確認する方法 今、NXPエンジニアが提供した「HseLib_HseFwInstall」ソフトウェアを使ってHSE FWをインストールしました。 お客様から質問があります:HSE FW自体に署名がないと考えているため、HSE FWの真正性をどのように確認すればよいか。 屏幕截图 2026-09-17 182416.png 画面截图 2026-09-17 182416.png 改ざんされやすいと。 HSEのFWの真正性を証明するためのセキュリティ制度があると教えてくれる人はいますか? Re: How to confirm HSE FW authenticity おそらく新しいチケットを作成することも可能です: https://www.nxp.com/support/support:SUPPORTHOME HSE文書は安全なファイルなので、すでに手続きを済ませている場合は以下の手順に従う必要があります。 https://www.nxp.com/docs/en/user-guide/nxp-secure-access-rights-registration.pdf プレゼンテーションを共有できるかもしれません。 Re: How to confirm HSE FW authenticity この質問に答えてくださりありがとうございます。これらの内容に関する参考文献をどうやって見つければよいか教えていただけますか?In まだこれらの内容には気づいていません。 Re: How to confirm HSE FW authenticity こんにちは、 HSE FWは確かに保護されており、単なる署名なしバイナリではありません。 ファームウェアイメージは、配布前にNXPによって暗号化および署名されます。 NXPは製造時にHSEサブシステムに ROM鍵 を事前プログラムします(ハードウェアの信頼の基点)。これらの鍵は外部からは決してアクセスできません。 インストール中、オンチップのセキュアBAFは、イメージをフラッシュメモリに書き込む前に、これらのROMキーを使用してイメージを認証します。改ざんされた画像は拒否されます。 結論として、NXPの秘密署名鍵がなければ、改変されたHSEファームウェアをインストールすることは不可能です。その信頼はシリコンに根ざしている。

S32DSライセンスの有効期限が切れます こんにちは、 S32DS を開くと次のメッセージが表示されます。   Arm用Design Studio アクティベーションID: 8AEC-51FD-AB5B-6A4D 評価日数: 9 機能バージョン: 2.2 機能のステータス: 評価 (9 日間) ライセンスを延長するには何をする必要がありますか? よろしくお願いいたします。 サンドラ Re: S32DS license expiring こんにちは、 ライセンスを延長するよう管理者に通知しました。 よろしくお願いいたします。 ピーター Re: S32DS license expiring こんにちは、 ライセンスは 2030 年まで延長されました。 よろしくお願いいたします。 ピーター Re: S32DS license expiring こんにちは、 画像の問題でS32DSをアクティベートできませんでした。この問題を解決する方法を教えていただけますか？ HelenLi_0-1778831877838.pngHelenLi_0-1778831877838.pngHelenLi_0-1778831877838.pngHelenLi_0-1778831877838.png Re: S32DS license expiring 助けて! 私のS32DS IDEライセンスがもうすぐ期限切れです。使用期間を延長するのを手伝ってもらえますか?ありがとう ！ ライセンス番号：1A99 90A8 2F06 339B Re: S32DS license expiring こんにちは： アクティベーションID: 04E9-8F5A-8B1F-F9C8 ライセンスの有効期間を延長する必要がある。 Re: S32DS license expiring こんにちは! 私のS32DS IDEライセンスがもうすぐ期限切れです。使用期間を延長するのを手伝ってもらえますか?ありがとう ！ ライセンス番号：EA09-8465-A8E8-F07B Re: S32DS license expiring こんにちは、ピーターさん。 私のS32DS v3.5のライセンスが期限切れになりました。2030年9月16日まで延長する手助けをしてもらえますか? フルフィルメントID:113445398 マシンID:A5883F5CCBF60C6BECC55C5A0CC9D1C68DA192AD 起動コード:A060-A074-B014-D67C ライセンスページには「このライセンスの返却は許可されません」と表示され、延長ボタンはありません。 スクリーンショットを添付しました。 ありがとう！

T1042NXE BSDL 文件 您好，我正在寻找该组件的BSDL文件： T1042NXE7PQB BGA780 你能把文件发给我吗？ 谢谢！ Re: T1042NXE BSDL file 你好， 您的元器件T1042NXE7PQB的 BSDL 文件包含在T1040/T1042 组合 BSDL 文件（文件名： T1040_and_T1042_1.1.bsdl ）中。这个文件同时适用于 T1040 和 T1042 处理器。 如何下载 该文件可直接在 NXP 产品页面的“设计资源”→“设计文件”→“模型”下找到： T1040/42 的 BSDL 文件 — 下载（需要账号） 文件代码： T1040-T1042-BSDL 修订版：R1A（2019年2月20日） 大小：110.13 KB 此致

LPUART1 TX FIFO 失败 大家好， 我正在使用 S32K311 和一个自定义的裸机驱动程序，用于两个配置完全相同的 LPUART 实例（115200 8N1，启用 TX/RX FIFO，相同的初始化序列）。LPUART0 在启用 TX 和 RX FIFO 的情况下都能完美工作。LPUART1 不具备以下功能： TX：对 DATA 进行一次写入（或当 FIFO[TXFE]=1 时进行一次推送）会导致同一个字节在 TX 引脚上物理传输 3 次。这不是垃圾/噪音——这是我写出的确切字节，连续重复了 3 次。使用示波器/逻辑分析仪在 TX 引脚 (GPIO71) 上进行了验证。 RX：在此实例上启用 RX FIFO 时，接收行为也不正常（没有可用数据返回），这与 LPUART0 不同。 我已经排除/确认了以下几点： 波特率/时钟正确：我没有看到损坏或错位的字符，只有正确的字节值重复了 3 次，这表明并非过采样/波特率 (OSR/SBR) 计算错误。 时钟门控在两个实例中均已启用：以相同的方式（相同的分区，顺序请求 ID）为 LPUART0 和 LPUART1 启用了 MC_ME 外设时钟请求，并且具有相同代码路径的 LPUART0 工作正常。 通过反复试验找到的解决方法： 禁用 LPUART1 上的 TX FIFO (FIFO[TXFE]=0) 可以解决发送问题（每次写入一个帧，使用 STAT[TDRE] 而不是 WATER[TXCOUNT] 进行流量控制）。 要使 LPUART1 上的 RX 正常工作，必须启用 RX FIFO (FIFO[RXFE]=1)。 因此，LPUART1 上唯一有效的配置是：TX FIFO 禁用，RX FIFO 启用——这与 LPUART0 正好相反（LPUART0 中两个 FIFO 都启用可以正常工作），并且显然会降低 TX 吞吐量/突发能力。 问题： 是否存在与 TX FIFO 导致帧重复相关的 S32K311 LPUART1 实例（或特定的 LPUART 实例限制）的已知勘误？ 除了 FIFO[TXFE]、WATER、BAUD[TDMAE] 之外，该设备上的 LPUART1 和 LPUART0 是否还有其他需要特殊处理的寄存器/位？ 是否有人观察到，在特定的 LPUART 实例上，而不是所有实例上，存在“启用 TX FIFO 时，字节传输 3 次”的相同行为？ 任何关于勘误表、芯片修订说明或已知解决方法的线索都将不胜感激。 Re: LPUART1 TX FIFO Failed 嗨@ijm1 ， 我曾观察到，当时钟域频率之间的比率与任何支持的时钟选项都不匹配时，硬件模块会出现不可预测的行为。系统时钟必须始终按照 RM 中列出的有效时钟选项之一进行配置。 关键要求是时钟之间的比率必须完全按照定义保持不变。 如RM表151（针对S32K312、S32K311和S32K310）所述： “……所选的任何时钟频率都必须符合系统时钟配置中所示的相同时钟分频比。” 请您先核实一下好吗？ 问候， 丹尼尔

如何确认 HSE FW 的真伪 现在，我使用了NXP工程师提供的“HseLib_HseFwInstall”软件来安装HSE固件。 我们的客户提出了一个问题：如何确认 HSE 固件的真伪，因为他认为 HSE 固件本身没有任何签名。这很容易。 屏幕截图 2026-09-17 182416.png屏幕截图2026-09-17 182416.png被篡改。 谁能告诉我 HSE FW 是否有网络安全措施来确认 HSE FW 的真实性？ Re: How to confirm HSE FW authenticity 或许您可以创建一个新的工单： https://www.nxp.com/support/support:SUPPORTHOME HSE 文件属于安全文件，因此除非您之前已经操作过，否则需要遵循以下步骤： https://www.nxp.com/docs/en/user-guide/nxp-secure-access-rights-registration.pdf 我们可以一起做一些演示。 Re: How to confirm HSE FW authenticity 感谢您回答这个问题。请问我该如何找到关于这些内容的参考资料？我在《RM758222-HSE-B 固件参考手册 - V2.2》中还没有注意到这些内容。 Re: How to confirm HSE FW authenticity 您好， HSE固件确实受到保护——它不是普通的未签名二进制文件。 固件镜像在分发前由 NXP 进行加密和签名。 NXP 在制造过程中将ROM 密钥预先编程到 HSE 子系统中（硬件信任根）。这些密钥永远无法从外部获取。 安装过程中，片上安全 BAF会使用这些 ROM 密钥来验证映像，然后再将其写入闪存。篡改过的图片会被拒绝。 结论是：如果没有 NXP 的私钥，就不可能安装修改过的 HSE 固件。信任源于硅谷。