From Silicon to Supply Chain: How NXP's MCX Portfolio Is Built for Resilience In today's market, MCU selection is no longer based solely on product features like performance or power consumption. Supply assurance, manufacturing flexibility, and long-term availability have become critical design requirements and often lead the selection conversation. Developers need confidence that the device will be available and supported throughout their products’ lifecycle. Supply resiliency is no longer just an operations topic, it's a key design consideration. NXP’s manufacturing and supply strategy for the MCX portfolio is designed with resiliency in mind. Recent investments in manufacturing capacity, combined with the opening of VSMC's new Singapore facility, reinforce NXP's commitment to helping customers plan with greater confidence and address supply chain risk. The MCX portfolio is supported by a diversified manufacturing strategy intended to improve supply flexibility, geographic diversification, and long-term availability. A New Era of Manufacturing Resilience The opening of VSMC’s new Singapore facility marks an important step in NXP’s long-term manufacturing strategy and highlights the value of its joint ownership in the venture, helping expand manufacturing capacity and enhance supply resilience. For MCX customers, this aligns directly with NXP's long-term strategy of expanding manufacturing options and supporting greater geographic diversification over time. NXP's supply architecture leverages multiple manufacturing partners and strategically distributed operations to create a more robust supply chain designed to support evolving customer demand and strengthen long-term supply flexibility. MCX is backed by a comprehensive resiliency strategy centered on three key pillars: Predictable Lead Times NXP maintains a consistent targeted lead time of approximately 16-weeks for MCX devices, helping customers improve production planning and reduce uncertainty during product launches and volume ramp-ups. Diversified Front-End Manufacturing MCX is supported by a diversified front-end manufacturing strategy, including a long-term second-source roadmap incorporating VSMC in Singapore. This geographic diversification provides additional manufacturing flexibility and strengthens long-term supply resilience. Flexible Back-End Operations Multiple assembly and test locations across geographic regions provide customers with sourcing flexibility and support continued capacity expansion. NXP’s back-end strategy includes assembly and test operations across multiple regions, with China and non-China pathways available for select MCX products and package options. More Than Availability: Long-Term Customer Confidence Supply resiliency is not simply about addressing today's demand. It is about enabling product developers to make long-term platform decisions with confidence. The MCX family combines: Consistent lead time target of 16 weeks Geographic manufacturing diversification Multi-source manufacturing strategies Broad package support Long-term product longevity commitments Together, these capabilities help reduce risk while giving customers confidence that the MCU platform selected today can help customers evaluate MCX for long-term product and platform plans. MCX: Supply Strength You Can Build On While many manufacturers continue to face extended lead times across portions of their MCU portfolios, NXP has invested aggressively in capacity expansion and supply chain diversification. These investments are designed to provide customers with a dependable path to production while supporting future growth and innovation. The opening of VSMC’s Singapore facility represents an important step in building a more geographically diversified semiconductor manufacturing ecosystem. Alongside NXP’s broader investments in manufacturing flexibility and expanded sourcing options, it supports the long-term strategy behind the MCX portfolio. Whether developers are building a new industrial controller, updating an existing platform or planning the next generation of connected products, MCX brings together scalable performance, a broad development ecosystem and a manufacturing strategy designed to support long-term product plans. Build your next design with MCX. Celebrate the VSMC grand opening with 50% off one eligible FRDM-MCX board on nxp.com through October 31, 2026. Use coupon code AMKSFYKZ. Limit one eligible board per customer. Terms and conditions apply. Supply resilience is now a critical factor in MCU selection. Discover how NXP’s MCX portfolio combines predictable lead times, diversified manufacturing, long-term product longevity, and strategic investments like VSMC’s new Singapore facility to help developers build with confidence and reduce supply chain risk. Board Design MCX C15 MCX C16 MCXA MCXC MCXN

VRC_CTRL Clarification Hello NXP Support, I would like to ask some questions on S32K3's VRC_CTRL (PTE13). (1) RM mentions VRC_CTRL is direct signal, could you please check the understanding/question in the following table (red font)? ALTx OBE IBE VRC_CTRL Question GPIO Disabled Disabled Enabled VRC_CTRL will take effect, right? GPIO Disabled Enabled Enabled VRC_CTRL will still take effect, right? GPIO Enabled Not Care Enabled Who will take effect? (2) If we configure PTE13 as GPIO + OBE Enabled + Output Level Low, will the VRC_CTRL negative feedback mechanism be broken because VRC_CTRL is treated as error signal and now maybe GPIO and VRC_CTRL are driving the pin at the same time? (3) In NXP MCAL, as long as I configure PTE13 as PG_VRC_CTRL_OUT, OBE will be automatically set by function Port_Ipw_SetOnlyOutputMode(), is it an issue of MCAL? (4) How to test VRC_CTRL feedback mechanism , what waveform is expected during which condition? (5) Why is MSCR141 documented as "Not Supported" in RM? Thanks. BR

imx6ull->ADC こんにちは、 私はi.MX6ULLベースのカスタムSOMモジュールを使用しています。私たちの要件として、 i.MX プロセッサ用のConfig Toolsを使ってピンを設定しています。Config Toolsで、 Create a Standalone Projectを選択し、次にi.MX 6ULL → (6Y2...05)を選択しました。 私たちの要件は、Config Toolsを使用してピンを設定し、生成された.dtsiファイルを取得し、同じファイルを使用してイメージを構築することです。しかし、これは当初はうまくいかなかった。 UARTに関しては、対応するデバイスノードを追加し、そのステータスを「OK」に設定する必要があると理解しました。同様に、生成された.dtsiファイルにも小さな修正が必要でした。ファイル。 .dtsiファイルを添付しました。Config Toolsによって生成されたファイル。ぜひご覧ください。そのファイルで、imx6ull-boardの行をコメントアウトしたところ、設定が正常に動作するようになりました。 UARTの設定が終わったので、次はADCの設定に移りました。Config ToolsでADCの設定を確認したところ、 ADCが同じGPIOピンを使用していることに気づきました。しかし、1つのGPIOピンをGPIOとして、もう1つのGPIOピンをADCとして設定した場合、生成されるIOMUX構成は同じように見えることがわかりました。なぜそうなっているのでしょうか?これは想定される動作でしょうか？ i.MX6ULLカスタムSOMでADCの設定やテストの正しい方法を教えていただけますか? また、当初の要件は、Config Toolsを使用してピンを設定し、生成された設定ファイルを使用して、イメージをビルドしてフラッシュすることでした。このアプローチが弊社のカスタムボードにも適用できるかどうか、あるいは生成された.dtsiファイルに追加の変更が必要かどうかを確認したいと思います。ファイル。 dtsファイルと.dtsiファイルを添付しました。参考のために、設定ツールで生成されたファイルを添付します。 これは実際にはどういう意味ですか？ Re: imx6ull->ADC こんにちは@Et_MM これはi.MX6ULL用設定ツールのバグのようです。 どのGPIOをADCとして使用したいのか、また他のGPIO機能にはどのGPIOを使用するのかを明確にしてください。 正しい&adc1ノードと正しいピンマックスを生成するお手伝いができます。 よろしくお願いいたします。 サラス。 Re: imx6ull->ADC GPIO01_IO01、GPIO01_IO02 GPIO自体、GPIO01_IO03,GPIO01_IO04 ADCとして欲しいです。 DTSIファイルを調べたところ、ADC1はADC1だけのようです。adc2は利用できません。もし私の理解が間違っていたら、訂正してください。 また、設定したADCとGPIOピンが動作しているかどうか、どのようにテスト・検証すればよいかも教えてください。どうやってそれを検証すればいいですか? 既に、私たちが使用しているdtsファイルとdtsiファイルを共有しました。もうご覧になっていることを願っています。上記で言及されているADCの設定は間違っているのでしょうか？ Re: imx6ull->ADC こんにちは@Et_MM お元気でお過ごしのことと思います。 はい、ADC1が唯一利用可能なものです。 あなたのユースケースでは、以下のデバイスツリーをご利用ください: &adc1 { num-channels = <10>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_adc1>; status = "okay"; }; &iomuxc { pinctrl_adc1: adc1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x3000 MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x3000 >; }; }; それならGPIO1_IO03とGPIO1_IO04だけをADCチャネルとして使います。 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage3_raw 75 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage4_raw 0 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat name 2198000.adc よろしくお願いいたします。 サラス。 Re: imx6ull->ADC ご返信ありがとうございます。 GPIO01_IO01、GPIO01_IO02をGPIとして設定したい場合。構成はどうなるのか、それについても教えていただけませんか? Re: imx6ull->ADC こんにちは！ 以下の内容を&iomuxの中に簡単に追加できます: pinctrl_hog: hoggrp { fsl,pins = < MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0x10b0 MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0x10b0 >; }; 他の周辺機器によって既に占有されていないことを確認してください。 よろしくお願いいたします。 サラス。 Re: imx6ull->ADC こんにちは。ご返信ありがとうございます。試してみます。 あなたが教えてくれた設定で ADC を試しましたが、そのコマンドを実行すると、これが私の出力です: root@imx6ul7d:/sys/bus/iio/devices/iio:device0# cat in_voltage1_raw 78 root@imx6ul7d:/sys/bus/iio/devices/iio:device0# cat in_voltage4_raw 74 でも、このピンがうまくいっているか確認するために、他にテストする方法はありますか?

优惠券无效 FRDM-MCXN236 还有其他人遇到免费板优惠券代码无法使用的问题吗？ NXP 正在宣传赠送一块免费电路板供用户入门，但结账时优惠券代码显示无效，即使该产品显然有库存。这是系统故障吗？还有其他人遇到这个问题吗？ 开发板 FRDM培训

关于 HSE FW 2.40.0 和 2.55.0 中 GCM IV 长度支撑的问题 你好， 我有一个关于 S32K358 上 HSE 的 GCM 操作的问题。 在 HSE 服务 API 参考手册的 AEAD 服务描述中，HSE FW 2.40.0 和 2.55.0 都对 GCM 进行了如下规定： GCM: 1 <= ivLength <= 2^32-1。建议大小为 12 字节或更大。 但是，HSE FW 2.40.0 手册包含以下附加说明，而 HSE FW 2.55.0 手册中没有此说明： 在 GCM 操作中，建议使用正好 12 字节的 IV 值。对于任何非 12 字节的 IV 大小，GCM 加密操作生成的认证标签可能不正确。在 GCM 解密操作中，身份验证检查可能会失败。 在此，我想澄清以下几点： 1. 当 IV 长度不是 12 字节时，HSE FW 2.40.0 中 GCM 操作能否正常使用？ 2. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 在 GCM 操作方面是否存在行为差异？ 3. 当使用 12 字节以外的 IV 长度时，HSE FW 2.40.0 和 2.55.0 的 GCM 操作可靠性是否存在差异？ 在我们的测试中，即使 IV 长度不是 12 字节，GCM 加密和解密也能成功执行，并且认证结果也正确。 因此，我想确认 HSE FW 2.40.0 是否完全支持使用 12 字节以外的 IV 长度，以及在这种情况下与使用 HSE FW 2.55.0 相比是否存在任何功能差异。 谢谢你的解释。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 嗨@wodudwo 从技术上讲，ivLength 可以配置为不同的长度；但是，不建议这样做，因为不能保证其行为可靠。正如您正确指出的那样，文档中说明，对于 GCM 解密操作，当使用 12 字节以外的 IV 长度时，身份验证检查可能会失败。 虽然使用不同长度的静脉输液管进行的测试可能通过了，但这并不能保证手术一定会成功。换句话说，某个测试用例的成功结果不应被解释为表明该配置完全受支持或在所有情况下都能稳定运行。 此外，如果您查看这两个固件版本的发行说明，您会发现限制列表包含相同的建议：使用正好为 12 字节的 IV 值。 虽然从 HSE 固件 2.55.0 版本开始，HSE 服务 API 参考手册中已删除该注释，但限制本身仍然存在。 BR，VaneB Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 嗨@wodudwo 如 HSE 服务 API 参考手册中所述，建议的 IV 长度在1<= ivLength <= 2∧32-1 的范围内，建议为 12 字节或更大。 参考实现可在 hse_crypto.c 文件中找到。（ S32K3 通用 HSE 演示示例）和 hse_sessionkeys_example.c（HSE 演示应用程序）。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 您好，谢谢您的澄清。 关于使用 12 字节以外的 IV，我还有一个问题。 我理解，当使用非 12 字节的 IV 时，身份验证标签的生成/验证可能不可靠。 在这种情况下，无论认证标签如何，加密/解密操作本身是否可以被认为是可靠的？ 例如，如果使用 16 字节的 IV 进行 GCM 加密，即使认证标签可能不可靠，能否保证生成的密文正确且一致？ 换句话说，这种限制是专门针对身份验证标签的生成/验证，还是使用 12 字节以外的 IV 也会影响实际加密/解密操作的可靠性/正确性？ 谢谢！ Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 您好，感谢您的回复。 但是，我想澄清一下我之前的问题中没有提到的一点。 如果 GCM 使用非 12 字节的 IV，例如 16 字节的 IV： 1. 加密操作生成的密文是否能保证正确可靠？ 2. 解密操作恢复的明文是否能保证正确可靠？ 我理解，对于非 12 字节的 IV，身份验证标签的生成/验证可能不可靠。 我的问题是，这种限制是否也适用于实际的加密/解密结果（密文/明文），还是这种限制仅与认证标签有关。 您能否具体解释一下这一点？

Request to extend expiring license for S32 Design Studio for ARM v2.2 S32 Design Studio for ARM ActivationId: 2FBC-9F2F-AF20-37D9 Evaluation Days: 27 Feature Version: 2.2 Feature Status: Evaluation (27 days) Re: Request to extend expiring license for S32 Design Studio for ARM v2.2 Hi,  your S32DS license has been extended.  Re: Request to extend expiring license for S32 Design Studio for ARM v2.2 Yes, just checked and the license got extended. Thank you very much for your assistance!

スマートカードリーダーの便利な活用法は？ 私のThinkPad T15にはスマートカードリーダーが搭載されているのに、1年間もそのことに気づかなかった。 何か面白い使い道はあるの？職場ではメールの暗号化にそれらを使用していますが、それは個人的な用途にはあまり適していません。きっと何か面白い使い道があるはずだ。 スマート・カード

MCUXpresso IDE v24.12 [版本 148] [2025-01-10] 不支持调试配置“变量”。 大家好， 我正在使用 MCUXpresso IDE v24.12.148 和 SEGGER J-Link 调试器。我的项目RSR1138_OSRAM_CONFIGURABLE有两个版本配置： 版本和版本 。 我的目标是创建一个单一的调试配置，使其能够根据当前激活的版本配置自动指向正确的.axf文件。目前，我有两个独立的调试配置，分别指向一个固定的路径（ Debug\...axf或版本\...axf ），我希望将它们合并为一个。 我注意到在“调试配置”->“主”选项卡中，“C/C++应用程序”字段旁边有一个“变量...”按钮。在可用变量中，我找到了active_core_build_dir ，其描述为： “给定项目的活动核心版本配置的版本目录” 。 基于此，我对“C/C++ 应用程序”字段进行了如下修改： 文字 ${active_core_build_dir}/RSR1138_OSRAM_CONFIGURABLE.axf 我还将“启动前（如果需要）版本”->“版本配置” 设置 为“使用活动” 。 但是，当我用上市，不用发布此调试配置时，出现以下错误： 文字 'Launching RSR1138_OSRAM_CONFIGURABLE JLink Debug' has encountered a problem. Program file does not exist \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found 变量${active_core_build_dir}在“C/C++ 应用程序”字段中似乎没有正确展开，导致路径格式错误。 我的问题： 是否可以在调试配置的“C/C++ 应用程序”字段中使用${active_core_build_dir}或类似变量来创建动态路径？ 如果可以，正确的语法或配置是什么？ 如果不行，那么实现一个能够 根据当前版本配置 自动选择正确 .axf 文件的单一调试配置的推荐方法是什么 ？ 我附上了两张截图： 其中一张图显示了插入变量后的调试配置以及由此产生的错误。 其中一张图显示了“选择变量”对话框，以及可用变量的列表。 感谢您的支持。 此致， 保罗·贝尔纳斯科尼 错误

RT1160 Spread Spectrum crashing... Looking for help here, I've looked over all other forum posts, and followed everything I could find, but still getting crashes when trying to enable Spread Spectrum on a RT1160 MCU. As you can see from the screenshots, I've moved fsl_clock.o to RAM as well as *flexspi.o to RAM. You can see, using Segger Ozone, exactly where the crash occurs, along with the generated exception and exception register settings. Any idea what's wrong here?

LS1046A 定制板：PBL SD_CLK 从 195 kHz 降至 24 kHz，然后空闲；HRESET_B 卡在低电平。 你好， 这是对之前帖子的后续讨论（June 不在办公室）： https://community.nxp.com/t5/QorIQ/LS1046A-custom-board-cold-boot-fails-from-eMMC-SD-and-QSPI/mp/2416533 摘要 从 SD 卡进行本地冷启动时，HRESET_B 为低电平，导致启动停滞。使用调试器辅助启动（CodeWarrior rcw.apply()）可以到达 U-Boot，使用相同的 RCW、PBI 和卡。在本地停顿期间，PBL 以大约 195 kHz 的频率启动 SD_CLK 并发送命令帧。DAT0 从不切换。然后时钟停止，短暂地以大约 24 kHz 的频率重新启动，总线进入空闲状态。我们希望得到帮助，以便根据 RM 表 4-8“RCW 州时间”来解释这一点。 设置（板 2，无 RESET 返工） LS1046AXE8T1A Rev 1.0 (SVR 0x87070010)。没有CPLD；STM32 BMC负责电源时序和RESET。 cfg_rcw_src=0x40（SW8 = 0010 0000，SW5 极 1 关闭）。 主要参考，引用：100 MHz 差分。时钟选择带 IFC_WE_B (cfg_eng_use0)。DDR参考，引用：差分。 SD 卡：同一张卡可以将 LS1046ARDB 启动到 U-Boot。 EVDD = 3.3 V。SD/eMMC 多路复用器设置为 SD 卡槽。RCW EVDD_VSEL = 0b10。 RCW：PLL 比率从硬编码的 0x9F 示例复制而来（平台 400 MHz，CPU 1300 MHz，PLL2 1000 MHz / FMan 500 MHz，DDR 1600 MT/s），两个 SerDes 均已禁用： 0810000d 0a000000 00000000 00000000 00000000 00f00012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001102 00000096 00000001 PBI：与前面线程中的流相同，以 08610040 6d8bdebf (END/CRC) 结尾。 RESET电路： PORESET_B 由一个开漏 MOSFET 驱动，并带有一个 10 kΩ 的上拉电阻，上拉电压至 1.8 V。 TRST_B 是单独控制的，并在 PORESET_B 之后 1 毫秒释放。 HRESET_B 具有 4.7 kΩ 的上拉电阻。 原生冷启动观察（未连接调试器） 时间均为近似值。t = 0 是 ASLEEP 的下降沿，与单独捕获中的 PORESET_B 的上升沿重合。 ≈ +0.5 毫秒： SD_CLK 起始频率为 192–200 kHz（按我们的计算约为 100 MHz/512）。CMD处于空闲状态。 ≈ +3.2 毫秒： CMD 帧开始。帧形状看起来像 CMD0 (40 00 00 00 00 95)，但我们还没有解码它。 ≈ +9.6 毫秒： SD_CLK 停止约 1 毫秒。 ≈ +10.6 毫秒： CMD 和 DAT0 上出现一些转换，但没有时钟信号。 ≈ +10.7 至 +11.2 毫秒： SD_CLK 以 24.39 kHz（约 100 MHz/4096）运行约 16 个周期，没有 CMD 帧。 ≈ +11.0 毫秒： ASLEEP 变为高电平。 之后：在接下来的 250 毫秒时间内，CLK、CMD 或 DAT0 均无活动。HRESET_B 保持低电平。 在 PORESET_B 释放之前，HRESET_B 为低电平，释放之后也保持低电平。 插入卡后，RESET_REQ_B 保持高电平。如果没有卡，RESET_REQ_B 将变为低电平。 停滞期间的CCS访问 ccs::config_chain {ls1043a dap sap2} 已被接受。ccs::display_mem 2 0x01ee0000 4 0 1 返回“扫描超时”。 调试器辅助启动（有效） set_source(0x40) 和 set_data({13: 0x00004504})（与卡片上的值相同），然后 apply()。RCWSR 随后将卡片进行匹配。U-Boot 报告 CPU 1300，平台 400，DDR 1600，FMan 500 MHz。SD初始化和FIP加载成功。 问题 根据表 4-8“RCW 状态时序”，当 SYSCLK 为 100 MHz 时，我们应该看到哪些 SD_CLK 频率和转换？“~195 kHz → 停止 → ~24 kHz 突发 → 空闲”是指 PBL 在卡片识别期间超时、重置 eSDHC 还是达到更晚的状态？ PBL 发出哪些 SD 命令序列（CMD0/CMD8/ACMD41 …），重试次数和超时次数是多少？如果卡片没有响应，是否应该断言 RESET_REQ_B，以及断言后需要等待多长时间？ 当 HRESET_B 为低电平时，SAP2 上是否预期会出现“扫描超时”？如果是这样，在这种状态下，哪些可通过 JTAG 访问的状态可以显示 PBL 的进展情况？ 缓慢的 PORESET_B 上升沿（规范 ≤ 1 SYSCLK）是否会导致这种行为？ 硬编码 0x9F，无卡：PORESET_B 释放后 HRESET_B 没有变为高电平。我们应该如何解读这句话？ Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW 你好， 波形表明该设备从未完成 RCW/PLL 转换。目前尚未进入正常的 PBI/eSDHC 运行阶段。 1. 预期 SD_CLK 频率为 100 MHz，SYSCLK 频率为 100 MHz 对于 RCW 载荷： SD_CLK = SYSCLK / 512 100 MHz / 512 = 195.3125 kHz RCW 加载和 PLL 锁定后： HRESET_B 应该取消断言。 平台时钟切换。 SD_CLK = platform clock / 80 。 在 400 MHz 平台时钟下，这大约是5 MHz 。NXP 将此转变描述为 PLL 锁定和 RCW 加载完成的标志。 因此： ~195 kHz → stop → ~24 kHz burst → idle     并不代表有记录的后期状态转变。24 kHz 值约为 100 MHz / 4096 ；将其视为 RESET/默认分频器或重启产物，而不是 PBL 达到 PBI 负载的证据。单凭时钟无法区分 SD 卡识别超时和 eSDHC RESET。 2. SD 命令、重试和 RESET_REQ_B 预期的SD识别流程大致如下： CMD0 CMD8 CMD55 + ACMD41 repeated until the card is ready CMD2 CMD3 CMD7 then block reads for RCW/PBI data     CMD1 通常是 eMMC 初始化命令，而不是 SD 卡的等效命令。 NXP 提供的技术支持材料中没有明确规定 LS1043A ROM 的重试次数和每个命令的超时时间；不应从波形中推断这些数值。NXP 文档则描述了终端行为：如果选定的 SD 源不可用，SoC 不会回退到其他源；它会断言 RESET_REQ_B 并停止运行。 因此，如果该卡完全不存在，则最终应该断言 RESET_REQ_B 。目前还没有明确的“在 N 毫秒后断言”值作为通过/失败的限制。如果 HRESET_B 保持低电平而 RESET_REQ_B 保持高电平，则该设备可能仍处于终端 PBL 错误路径之前，或者电路板可能屏蔽/干扰了 RESET_REQ_B 。 3. SAP2“扫描超时” 是的，当 HRESET_B 仍然处于钳位状态时，这是预期行为。相同的复位签名 PORESET_B 释放、 HRESET_B 低、 RESET_REQ_B 高，并且处理器无法通过调试路径访问——与提前复位/启动条件相关联。 在 SAP2 可用之前，没有可靠的 CCSR 注册表来报告 PBL 进度。使用： PORESET_B hreset_b RESET_REQ_B 睡着了 CLK_OUT （如果已配置） 一旦通过使用 RCW 覆盖/安全 RCW 或隔离 RESET_REQ_B 建立调试访问权限，请检查： RSTCR RSTRQSR RSTRQPBLSR RSTRQMR NXP 特别建议在可以访问 RESET_REQ_B 时使用这些RESET寄存器。 4. PORESET_B 缓慢上升 是的。缓慢或形状不佳的 PORESET_B 释放可能会违反RESET初始化时序，并导致不正确的跳线、时钟或 PLL 采样。对于 100 MHz 的 SYSCLK，一个 SYSCLK 的持续时间限制约为10 ns 。直接在 LS1043A 引脚上验证实际电压交叉点和上升时间，而不仅仅是在复位发生器输出端。 还要验证 RESET_REQ_B 是否反馈到 PORESET_B ；NXP 建议在启动期间使用隔离选项，否则启动失败可能会造成复位循环，从而阻止 JTAG 访问。 5. 0x9F 测试的含义 0x9F 是硬编码的 RCW/调试鉴别器。只要时钟和 RESET 序列有效，就应该可以消除对从 SD 卡读取 RCW 的依赖。因此，如果未安装 SD 卡的情况下 HRESET_B 仍然不会上升，则故障可能发生在 SD 卡识别之前： 系统时钟/差分时钟选择或质量 PLL锁定 RCW表带解码 RESET电气定时 RESET 反馈或 JTAG/TRST 状态 换句话说，0x9F 的结果否定了“缺少卡片”是主要原因这一假设。首先证明 HRESET_B 在 0x9F 和干净的 RESET/时钟设置下上升；然后返回 SD RCW 加载。 此致 Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW 你好， 我们正在调查您所说的——证明HRESET_B会随着 0x9F 的出现而上升。目前我们观察到的情况与 SD 卡相同，即 HRESET_B 为低电平，ASLEEP 先变为低电平，然后又变为高电平。我们也尝试了 SD 卡、EMMC 以及 QSPI，都观察到了相同的冷启动卡顿以及相同的 HRESET_B 和 ASLEEP 行为。以下是我们在卡顿期间连接 CCS 控制台时得到的输出——有什么办法可以找出定制板的故障所在吗？ CCS console logCCS 控制台日志 谢谢

LS1046Aカスタムボード：PBL SD_CLKが195kHzから24kHzに低下し、その後アイドル状態になる。HRESET_BがLOWのままになる。 こんにちは、 これは先ほどのThread(6月は不在)に続くものです。 https://community.nxp.com/t5/QorIQ/LS1046A-custom-board-cold-boot-fails-from-eMMC-SD-and-QSPI/m-p/2416533 概要 SDカードからのネイティブコールドブートは、HRESET_BがLOWになると停止します。デバッガ支援ブート（CodeWarrior rcw.apply()）は、同じRCW、PBI、およびカードを使用してU-Bootに到達します。ネイティブストール中、PBLは約195kHzでSD_CLKを開始し、コマンドフレームを送信します。DAT0はトグルしません。その後、クロックは停止し、約24kHzで短時間再始動し、バスはアイドル状態になる。これをRM表4-8「RCW州のタイミング」に照らし合わせて解釈するにあたり、ご協力をお願いいたします。 セットアップ（ボード2、リセット作業なし） LS1046AXE8T1A Rev 1.0 (SVR 0x87070010)CPLDは使用せず、STM32 BMCが電源シーケンスとリセットを行います。 cfg_rcw_src=0x40 (SW8 = 0010 0000、SW5 極 1 OFF)。 主要基準：100MHz差動。時計選択ストラップ IFC_WE_B (cfg_eng_use0)。DDR参照：差分。 SDカード：同じカードでLS1046ARDBをU-Bootで起動できます。 EVDD = 3.3 V。SD/eMMCマルチプレクサはSDスロットに設定されています。RCW EVDD_VSEL = 0b10。 RCW:ハードコードされた0x9F例からコピーされたPLL比率(プラットフォーム400MHz、CPU1300MHz、PLL2 1000MHz / FMan 500MHz、DDR 1600MT/s)、両方のSerDesは無効化されています: 0810000d 0a000000 00000000 00000000 00000000 00f00012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001102 00000096 00000001 PBI:前のThreadのストリームと同じで、08610040 6d8bdebf(END/CRC)で終わります。 リセット回路： PORESET_Bは、1.8Vへの10kΩプルアップ抵抗を備えたオープンドレインMOSFETによって駆動される。 TRST_Bは個別に制御され、PORESET_Bの1ms後に解放されます。 HRESET_Bには4.7kΩのプルアップ抵抗があります。 ネイティブのコールドブート観測(デバッガ接続なし) 時間は目安です。t = 0 は ASLEEP の立ち下がりエッジであり、これは別のキャプチャで PORESET_B の立ち上がりと一致しました。 ≈ +0.5 ms: SD_CLK は 192〜200 kHz (我々の計算では約 100 MHz/512) で開始します。CMDはアイドル状態です。 ≈ +3.2 ms: CMD フレームが開始されます。フレームの形状はCMD0（40 00 00 00 00 95）のように見えますが、まだデコードしていません。 ≈ +9.6 ms: SD_CLK は約 1 ms 停止します。 ≈ +10.6 ms:クロックなしで CMD と DAT0 にいくつかの遷移が現れます。 ≈ +10.7 ～ +11.2 ms: SD_CLK は約 16 サイクルにわたって 24.39 kHz (約 100 MHz/4096) で動作し、CMD フレームはありません。 ≈ +11.0 ms: ASLEEP が HIGH になります。 その後：残りの250ミリ秒の間、CLK、CMD、DAT0の活動は発生しない。HRESET_BはLOWのままです。 HRESET_BはPORESET_Bが解放される前はLOWであり、解放後もLOWのままです。 カードが挿入されている間、RESET_REQ_BはHIGHのままです。カードがない場合、RESET_REQ_BはLOWになります。 失速中のCCSアクセス CCS::config_chain {ls1043a DAP SAP2} が受け入れられます。ccs::display_mem 2 0x01ee0000 4 0 1 は「スキャンタイムアウト」を返します。 デバッガー支援ブート（動作確認済み） set_source(0x40)とset_data({13: 0x00004504})（カード上の値と同じ）を実行してからapply()を実行します。RCWSRはカードと照合します。U-BootはCPU 1300、プラットフォーム400、DDR 1600、FMan 500 MHzを報告しています。SDの初期化とFIPのロードに成功しました。 質問 表4-8「RCWステートタイミング」によると、100MHzのSYSCLKではどのようなSD_CLK周波数と遷移が見られるでしょうか？「~195 kHz → 停止→ ~24 kHz バースト→アイドル」は、カード識別中にPBLがタイムアウトされた、eSDHCがリセットされた、あるいは後期の状態に到達したことを意味しているのでしょうか? PBLはどのSDコマンドシーケンス（CMD0/CMD8/ACMD41…）を発行し、その際の再試行回数とタイムアウト回数はどのくらいですか？カードが応答しない場合、RESET_REQ_Bはアサートすべきでしょうか？また、どのくらいの時間後にアサートすべきでしょうか？ HRESET_BがLOWの場合、SAP2で「スキャンタイムアウト」が発生するのは想定内ですか？もしそうなら、この状態でPBLの進捗を示せるJTAGアクセシブルな状態は何でしょうか? ゆっくりとしたPORESET_B上昇(仕様≤1 SYSCLK)がこの挙動を引き起こす可能性はありますか? カードなしでハードコードされた0x9F: PORESET_B解放後、HRESET_BがHIGHになりませんでした。これはどのように解釈すべきでしょうか？ Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW こんにちは、 波形は、デバイスがRCW/PLL遷移を完了しなかったことを示している。まだ通常のPBI/eSDHC動作段階には至っていません。 1. 100 MHz SYSCLK での SD_CLK の想定値 RCWの積載について： SD_CLK = SYSCLK / 512 100 MHz / 512 = 195.3125 kHz RCWロードとPLLロック後： HRESET_B 解除されるべきである。 プラットフォームの時計がスイッチします。 SD_CLK = プラットフォーム clock / 80 . 400 MHzのプラットフォームクロックの場合、これは約 5 MHzに相当します。NXPはこの遷移を、PLLロックとRCWロードが完了したことを示す兆候であると説明しています。 そのため、 ~195 kHz → stop → ~24 kHz burst → idle     これは、文書化された後期の状態遷移を表していません。24 kHz の値は、約 100 MHz / 4096 です。これはリセット/デフォルト分周器または再起動のアーティファクトとして扱い、PBL が PBI のロードに達したことの証明とはみなさないでください。クロックだけではSD識別タイムアウトとeSDHCのリセットを区別できません。 2. SDコマンド、再試行、およびRESET_REQ_B 予想されるSD識別の流れは大まかに以下の通りです: CMD0 CMD8 CMD55 + ACMD41 repeated until the card is ready CMD2 CMD3 CMD7 then block reads for RCW/PBI data     CMD1 は通常、eMMCの初期化コマンドであり、SDカードの初期化コマンドではありません。 正確なLS1043A ROMリトライ数やコマンドごとのタイムアウトは、NXPのサポート資料には記載されていません。これらは波形から推測すべきではありません。NXPのドキュメントでは端末の挙動が説明されています。選択したSDソースが利用できない場合、SoCは他のソースにフォールバックしません。 RESET_REQ_B を主張して停止します。 したがって、カードが完全に存在しない場合、 RESET_REQ_B 最終的にアサートされるはずです。合否判定の基準値として使用できる、「正確にNミリ秒後にアサートする」という固定値は文書化されていません。 HRESET_B ローのままで、かつこれがハイのままである場合、デバイスはまだターミナルPBLエラーパスの手前にあるか、ボードが RESET_REQ_B をマスク/干渉している可能性があります。 3. SAP2「スキャンタイムアウト」 はい、 HRESET_B がまだ有効になっている間は、これは想定される動作です。同じリセット署名— PORESET_B が解放され、 HRESET_B 低、 RESET_REQ_B 高、デバッグパス経由でプロセッサにアクセスできない—は早期リセット/起動条件に関連付けられています。 SAP2が利用可能になるまでは、PBLの進捗状況を報告する信頼できるCCSRレジスターは存在しない。使用： ポアセットB hreset_b RESET_REQ_B 眠っている CLK_OUT （設定されている場合） RCWオーバーライド/safe-RCWまたは RESET_REQ_B の隔離によってデバッグアクセスが確立されたら、以下を検査します。 RSTCR RSTRQSR RSTRQPBLSR RSTRQMR NXPはアクセス可能な場合にこれらのリセットレジスタ RESET_REQ_B 特に推奨しています。 4. PORESET_Bの上昇が遅い はい。遅いまたは形状の悪い PORESET_B リリースはリセット初期化タイミングに違反し、誤ったストラップ、クロック、PLL サンプリングの原因となることがあります。100 MHz の SYSCLK の場合、1 つの SYSCLK の公称制限は約10 nsです。リセットジェネレータ出力だけでなく、LS1043Aのピンで実際の電圧変動と立ち上がり時間を直接確認してください。 また、 RESET_REQ_B が PORESET_B にフィードバックしていないかも確認してください。NXPはブートアップ時に分離オプションを推奨しています。なぜなら、起動失敗がリセットループを起こしてJTAGアクセスを妨げる可能性があるからです。 5. 0x9Fテストの意味 0x9F はハードコードされたRCW/デバッグ識別子です。有効なクロックとリセットシーケンスがあれば、SDカードからRCWを読み取る必要性がなくなるはずです。したがって、カード HRESET_B 装着されていなくてもまだ起こらない場合は、 故障はSDカード識別よりも前から起こっている可能性が高いです。 SYSCLK/差動クロックの選択または品質 PLLロック RCWストラップの解読 電気的なタイミングをリセットします フィードバックまたはJTAG/TRST状態のリセット つまり、0x9Fという結果は、「カードの欠落」が主な原因であるという説に反論するものである。まず、 HRESET_B 0x9Fで立ち上がり、リセット/クロック設定が正常であることを確認してください。その後、SD RCWのロードに戻ります。 よろしくお願いします。 Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW こんにちは、 あなたの言ったことを調査しています。HRESET_Bが 0x9Fで上昇することを証明してください。現時点ではSDカードと同じ挙動が観察されており、HRESET_Bが低く、先に低く、その後高く戻る現象が見られます。また、SD、EMMC、QSPIでも同じコールドブートストール、HRESET_B・スリープの挙動が見られます。下の写真はストール中に接続したCCSコンソールですが、カスタムボードの故障箇所を調べるために何かできることはありますか? CCS console logCCSコンソールログ よろしくお願い申し上げます。

FreeMaster 无法集成 GUI Guider。 各位 FreeMASTER 网页上指出 GUI Giider 支持在 FreeMASTER 中创建小部件，但目前可用的 FreeMASTER 版本为 2.01，并且视频中也提到了这一点： https://community.nxp.com/t5/MCUXpresso-Training-Hub/FreeMASTER-Gui-Guider-integration/ta-p/1924225 请说明如何将 GUI Guider 集成到 FreeMASTER 中，但是 GUI Guider 2.01 中既没有“FreeMASTER 服务器链接”，也没有任何关于 FreeMASTER 配置的参考资料。此外，FREEMaster 不支持 NODE Red（仅轻量版支持）。所以，在FreeMaster中无法创建美观的小部件。 这样说对吗？ 看待 保罗 FreeMASTER 中是否可以使用 GUI Guider？如果可以，该如何操作？你能帮我找到相关的视频/应用说明吗？ 谢谢 保罗 Re: Impossible to integrate GUI Guider in FreeMaster 各位 根据 NXP 内部的工单系统显示，Gui Guider 2.01 无法集成到 FreeMaster 中，只有下一个版本才能集成。目前我们必须使用 GUI Guider 2.01 v1.10。 此致 Paolo

智能卡读卡器有哪些好用途？ 我的 Thinkpad T15 笔记本电脑配备了智能卡读卡器，而我竟然一年后才知道。 它有什么很棒的用途吗？在工作中，我们用它们来加密邮件，但这并不是用于私人用途的。我相信它肯定有很多好玩的用途。 Smart Card

Impossible to integrate GUI Guider in FreeMaster Dear All In the FreeMASTER web page it is indicated that GUI Giider supports Widget creation in FreeMAster, but the available FreeMaster Version 2.01 and also the video: https://community.nxp.com/t5/MCUXpresso-Training-Hub/FreeMASTER-Gui-Guider-integration/ta-p/1924225 Indicate how to integrate GUI Guider in FreeMASTER, however there is no  "link to FreMASTER server" nor any reference to FreeMASTER Configuration in GUI Guider 2.01. Furthermore NODE Red is not supported by FREEMaster (it is by the light version only). So there is no way to create nice widget in FreeMaster Is it correct ? Regard  Paolo Is it possible to use GUI Guider in FreeMASTER, and how ? Can you point me to the right video/app note ? Thanks  Paolo Re: Impossible to integrate GUI Guider in FreeMaster Dear All From internal NXP ticketing system it results that Gui Guider 2.01 can not integrated in FreeMaster, only the next Version will be. At the moment we must use Gui Guider 2.01 v1.10 Regards Paolo

MCUXpresso IDE v24.12 [ビルド148] [2025-01-10] はDebug Confguration「変数」をサポートしません こんにちは、みんな、 私はMCUXpresso IDE v24.12.148とSEGGER J-Linkデバッガを使用しています。私のプロジェクトRSR1138_OSRAM_CONFIGURABLE には、Debug と Releaseの 2つのビルド構成があります 。 私の目標は、 アクティブなビルド構成に基づいて 適切な .axf ファイルを自動的に指定する 単一のデバッグ構成を 作成することです。現在、それぞれ固定パス (Debug\...axf または Release\...axf) を指す 2 つのデバッグ構成がありますが 、これらを 1 つに統合したいと考えています。 Debug Configurations -> Main タブの「C/C++ Application」フィールドの隣に 「Variables...」 というボタンがあること に気づ きました 。「」ボタンです。利用可能な変数の中には active_core_build_dir があり 、その説明は「 指定されたプロジェクトのアクティブCore Build構成のビルドディレクトリ」 です 。 これを踏まえて、「C/C++アプリケーション」フィールドを次のように修正しました。 文章 ${active_core_build_dir}/RSR1138_OSRAM_CONFIGURABLE.axf また、 「起動前にビルド（必要な場合）」→「ビルド構成」を 「アクティブを使用」 に 設定しました 。 しかし、このデバッグ構成を起動すると、次のエラーが発生します。 文章 'Launching RSR1138_OSRAM_CONFIGURABLE JLink Debug' has encountered a problem. Program file does not exist \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found 「 C/C++ Application」フィールドで 変数${active_core_build_dir} が正しく展開 されておらず、誤ったパスができているようです。 私の質問： ${active_core_build_dir}デバッグ構成の「C/C++ Application」フィールドで や類似の変数を使って動的パスを作成する ことは 可能でしょうか ? はいの場合、それを機能させるための正しい構文または設定は何ですか？ そうでない場合、 アクティブなビルド構成に基づいて 適切な .axf ファイルを自動的に選択する単一のデバッグ構成を実現するための推奨される方法は何ですか ？ スクリーンショットを2枚添付しました。 1つ目は、変数を挿入したデバッグ構成と、それによって発生したエラーを示すものです。 使用可能な変数の一覧が表示された「変数の選択」ダイアログを表示した画像。 再開まで今しばらくお待ちください。 よろしくお願いします、 パオロ・ベルナスコニ エラー

imx6ull->ADC 您好， 我正在使用基于 i.MX6ULL 的自定义 SOM 模块。根据我们的需求，我们使用i.MX 处理器配置工具来配置引脚。在配置工具中，我选择了“创建独立组网 \\(SA\\) 项目”，然后选择了i.MX 6ULL → (6Y2...05)。 我们的要求是使用配置工具配置引脚，获取生成的.dtsi 文件，并使用同一个文件来版本镜像。然而，这种方法一开始并不奏效。 对于UART ，我了解到我们需要添加相应的设备节点并将其状态设置为正常。同样，生成的 .dtsi 文件也需要进行一些小的修改。文件。 我已附上 .dtsi 文件。由配置工具生成的文件。请看一下。在该文件中，当我注释掉 imx6ull-board 行后，配置就开始正常工作了。 完成 UART 配置后，我开始进行ADC配置。当我在配置工具中检查 ADC 配置时，我注意到ADC似乎使用了同一个GPIO引脚。但是，我发现当我将一个 GPIO 引脚配置为 GPIO，将另一个 GPIO 引脚配置为 ADC 时，生成的 IOMUX 配置看起来是一样的。为什么会这样？这是预期行为吗？ 请问您能否帮我了解一下在我们的i.MX6ULL 定制 SOM上配置和测试 ADC 的正确方法？ 此外，我们最初的要求是使用配置工具配置引脚，获取生成的配置文件，并直接使用该配置文件来构建和烧录镜像。我想确认一下，这种方法是否适用于我们的定制板，或者是否需要在生成的 .dtsi 文件中进行其他修改。文件。 我已附上 .dts 和 .dtsi 文件。该文件由配置工具生成，供您参考。 这句话到底是什么意思？ Re: imx6ull->ADC 你好@Et_MM 这似乎是 i.MX6ULL 配置工具的一个 bug。 请明确您希望哪个GPIO用作ADC，以及哪个GPIO用于其他功能。 我可以帮助你生成正确的 &adc1 节点和正确的引脚复用。 顺祝商祺！ 萨拉斯。 Re: imx6ull->ADC 你好@Et_MM 希望你一切都好。 是的，目前只有ADC1可用。 请根据您的使用场景，将以下内容添加到您的设备树中： &adc1 { num-channels = <10>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_adc1>; status = "okay"; }; &iomuxc { pinctrl_adc1: adc1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x3000 MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x3000 >; }; }; 这将仅使用 GPIO1_IO03 和 GPIO1_IO04 作为 ADC 通道。 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage3_raw 75 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage4_raw 0 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat name 2198000.adc 顺祝商祺！ 萨拉斯。 Re: imx6ull->ADC 我希望将GPIO01_IO01、GPIO01_IO02用作GPIO本身，将GPIO01_IO03、GPIO01_IO04用作ADC 。 当我搜索 dtsi 文件时，发现我们只有一个 adc，即 adc1。adc2 不可用。如果我说错了，请指正。 另外，请指导我如何测试和验证我们配置的ADC和GPIO引脚是否正常工作。我该如何测试呢？ 我已经分享了我们正在使用的dts和dtsi文件。希望你已经看到了。其中提到的ADC配置是否有误？ Re: imx6ull->ADC 您好！ 您只需在 &iomux 中添加以下内容： pinctrl_hog: hoggrp { fsl,pins = < MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0x10b0 MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0x10b0 >; }; 务必确认该头衔没有被其他外围势力认领。 顺祝商祺！ 萨拉斯。 Re: imx6ull->ADC 谢谢你的回复。 如果我想将GPIO01_IO01、GPIO01_IO02配置为GPI。配置方面需要如何设置？能否也请您帮我一下？ Re: imx6ull->ADC 您好，谢谢您的回复，我会尝试一下。 我已按照您提供的配置测试了ADC ，运行这些命令后，我的输出如下： root@imx6ul7d:/sys/总线/iio/设备/iio:设备0# cat in_voltage1_raw 78 root@imx6ul7d:/sys/总线/iio/设备/iio:设备0# cat in_voltage4_raw 74 还有其他方法可以测试这些引脚，以便我确认它们是否正常工作吗？

HSE FW 2.40.0および2.55.0におけるGCM IV長サポートに関する質問 こんにちは、 S32K358のHSEにおけるGCMの動作について質問があります。 HSEサービスAPIリファレンスマニュアルのAEADサービス説明において、HSE FW 2.40.0および2.55.0の両方でGCMについて以下の事項が明記されています。 GCM: 1 <= ivLength <= 2^32-1。推奨サイズは12バイト以上です。 しかし、HSE FW 2.40.0のマニュアルには、HSE FW 2.55.0のマニュアルには記載されていない以下の注記が追加されています。 GCM操作においては、IV値として正確に12バイトを使用することを推奨します。12バイトを超える任意のIVサイズに対して、GCM暗号化操作によって生成される認証タグが正しくない場合があります。GCM復号操作では、認証チェックが失敗することがあります。 この点に関して、以下の点を明確にしたいと思います。 1. IV長が12バイトでない場合、HSE FW 2.40.0でGCM操作を通常使用できますか? 2. 12バイト以外のIV長を使用した場合、HSE FW 2.40.0と2.55.0の間でGCM操作に挙動的な違いはありますか? 3. IV長が12バイト以外の場合、HSE FW 2.40.0と2.55.0の間でGCM動作の信頼性に違いはありますか？ 私たちのテストでは、IV長が12バイトでなくてもGCM暗号化と復号が成功し、認証結果も正確でした。 したがって、HSE FW 2.40.0で12バイト以外のIV長の使用が完全にサポートされているかどうか、またこの場合のHSE FW 2.55.0使用と機能的に違いがあるのかを確認したいと思います。 ご説明いただきありがとうございます。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 技術的には、ivLengthは異なる長さで設定可能ですが、しかし、その動作が信頼性を保証するわけではないため推奨されません。ご指摘の通り、ドキュメントにはGCM復号操作では、12バイト以外のIV長を使うと認証チェックが失敗する可能性があると記載されています。 異なる長さの点滴チューブを使用したテストに合格したとしても、手術が必ず成功するとは限りません。言い換えれば、特定のテストケースで成功した結果が、その構成が完全にサポートされている、あるいはすべてのシナリオで一貫して動作するという指標と解釈すべきではありません。 さらに、両方のファームウェアバージョンのリリースノートを確認すると、制限事項のリストに同じ推奨事項が記載されていることがわかります。それは、IV値を正確に12バイトにすることです。 この注記はHSE FW 2.55.0からHSEサービスAPIリファレンスマニュアルから削除されましたが、制限自体は変更されていません。 BR、VaneB Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは。ご説明ありがとうございます。 12バイト以外のIV（初期化ベクトル）の使用に関して、もう一つ質問があります。 非12バイトのIVを使う場合、認証タグの生成や検証が信頼性に欠ける可能性があることは理解しています。 この場合、認証タグに関係なく暗号化/復号操作自体は信頼できると見なせるのでしょうか? 例えば、GCM暗号化に16バイトのIVが使われた場合、認証タグが信頼性がなくても、結果として得られる暗号文は正確かつ一貫性が保証されるのでしょうか? つまり、制限は認証タグの生成・検証に特有なのか、それとも12バイト以外のIVを使うことで、実際の暗号化・復号操作の信頼性や正確性にも影響が出るのでしょうか? よろしくお願いします。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 HSEサービスAPIリファレンスマニュアルに記載されているように、推奨されるIV長は 1<= iv∧ の範囲内であり、推奨12バイト以上が推奨されます。 リファレンス実装はhse_crypto.cで入手できます。( S32K3汎用HSEデモ例)およびhse_sessionkeys_example.c(HSEデモアプリ)。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、ご返信ありがとうございます。 しかし、前回の質問で触れられなかった点について、一点だけ明確にしておきたいと思います。 GCMに12バイト以外のIV（例えば16バイトのIV）が使用される場合： 1. 暗号化操作によって生成された暗号文は、正確かつ信頼できることが保証されていますか？ 2. 復号操作によって復元された平文は、正確かつ信頼できるものであることが保証されていますか？ 12バイトのIVでない認証タグの生成や検証が信頼性が低いことは理解しています。 私の質問は、この制限が実際の暗号化・復号結果(暗号文/平文)にも適用されるのか、それとも認証タグだけに限られるのかということです。 この点について具体的に説明していただけますか?

MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variables" Hello everyone, I am using MCUXpresso IDE v24.12.148 with a SEGGER J-Link debugger. My project, RSR1138_OSRAM_CONFIGURABLE, has two build configurations: Debug and Release. My goal is to have a single Debug Configuration that automatically points to the correct .axf file based on the active build configuration. Currently, I have two separate Debug Configurations, each pointing to a fixed path (Debug\...axf or Release\...axf), and I want to merge them into one. I noticed that in the Debug Configurations -> Main tab, next to the "C/C++ Application" field, there is a "Variables..." button. Among the available variables, I found active_core_build_dir, whose description is: "The build directory for the active Core Build configuration for the given project". Based on this, I modified the "C/C++ Application" field as follows: text ${active_core_build_dir}/RSR1138_OSRAM_CONFIGURABLE.axf I also set the "Build (if required) before launching" -> Build Configuration to "Use Active". However, when I launch this Debug Configuration, I get the following error: text 'Launching RSR1138_OSRAM_CONFIGURABLE JLink Debug' has encountered a problem. Program file does not exist \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found \RSR1138_OSRAM_CONFIGURABLE.axf not found It seems that the variable ${active_core_build_dir} is not being expanded correctly in the "C/C++ Application" field, resulting in a malformed path. My questions: Is it possible to use ${active_core_build_dir} or a similar variable in the "C/C++ Application" field of a Debug Configuration to create a dynamic path? If yes, what is the correct syntax or configuration to make it work? If not, what is the recommended way to achieve a single Debug Configuration that automatically selects the correct .axf file based on the active build configuration? I have attached two screenshots: One showing the Debug Configuration with the variable inserted and the resulting error. One showing the "Select Variable" dialog with the list of available variables. Thank you for your support. Best regards, Paolo Bernasconi Error

クーポンは無効です FRDM-MCXN236 無料ボードのクーポンコードで問題が発生している方はいらっしゃいますか？ NXPは無料ボードを宣伝していますが、製品の在庫があるのにチェックアウト時にクーポンコードが無効と表示されます。これはシステム上の不具合でしょうか？他にも同じ問題が発生している方はいらっしゃいますか？ 公開板 FRDM培训

RT1160 扩频器崩溃了…… 我正在寻求帮助，我已经查看了所有其他论坛帖子，并按照我能找到的所有方法操作，但在尝试在 RT1160 MCU 上启用扩频时仍然会崩溃。 从截图中可以看到，我已经移动了 fsl_clock.o到 RAM 以及 *flexspi.o写入内存。 使用 Segger Ozone，您可以准确地看到崩溃发生的位置，以及生成的异常和异常寄存器设置。 知道这里出了什么问题吗？