cst は古い OpenSSL を使用して無効な RSA-PSS 署名を作成する OpenSSL 3.1未満でcstを使用する場合、PSS署名で使用されるソルトが長すぎます。i.MX91のようなプロセッサはソルトの長さがダイジェストと同じであることを期待していますが、OpenSSL 3.1以前はデフォルトでソルトをできるだけ大きくするのが一般的でした。 しかし、新しいバージョンのOpenSSLであっても、デフォルト設定を使用するのは良くありません。なぜなら、署名検証時に短いソルトを受け入れてしまうからです。 解決策は、EVP_PKEY_CTX_set_rsa_pss_saltlen 関数を呼び出し、2 番目のパラメータを RSA_PSS_SALTLEN_DIGEST に設定することです。 なお、OpenSSL 3.0は先月からサポート終了となっています。 Security Re: cst creates invalid RSA-PSS signatures with old OpenSSL こんにちは、 ご連絡いただきありがとうございます。適切なチームに報告いたします。 よろしくお願いいたします。 アルド。

ARA2-M2-16G-GT ARA2-M2-16G-GTボードのユーザーマニュアルでは、ピン40はI2C_SDA、ピン42はI2C_SCLされています。 FRDM-IMX8MPLUSの回路図では、ピン40はI2C_SCL、ピン42はI2C_SDAです。 正しいピン配置は何ですか？ よろしくお願いします。 ボード設計 Re: ARA2-M2-16G-GT こんにちは、 両デバイスの回路図によると、ピン42はI2C_SDA、ピン40はI2C_SCLです。 よろしくお願いいたします。

ADC Conversion time issue Hello NXP Support, I am working with an S32K312 MCU using S32 Design Studio and RTD drivers, and I am trying to understand the actual conversion timing of the SAR ADC for a single-channel normal conversion. My setup is: MCU: S32K312 Core clock: 120 MHz ADC functional clock: 120 MHz ADC mode: Normal conversion Number of channels: 1 Pre-sampling: Disabled Sampling time: 33 ADC clock cycles Conversion time used in my calculation: 48 ADC clock cycles Hardware averaging: Disabled for this test End-of-chain notification/interrupt enabled The relevant code is: int main(void) { Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); IntCtrl_Ip_Init(&IntCtrlConfig_0); IntCtrl_Ip_EnableIrq(ADC0_IRQn); Siul2_Port_Ip_Init( NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals ); volatile Adc_Sar_Ip_StatusType status = ADC_SAR_IP_STATUS_ERROR; status = Adc_Sar_Ip_Init(0, &AdcHwUnit_0); status = Adc_Sar_Ip_DoCalibration(0); Adc_Sar_Ip_EnableNotifications( 0, ADC_SAR_IP_NOTIF_FLAG_NORMAL_ENDCHAIN ); Siul2_Dio_Ip_TogglePins(PTA_L_HALF, 1U << 1U); Adc_Sar_Ip_StartConversion( 0, ADC_SAR_IP_CONV_CHAIN_NORMAL ); while (1) { __asm__("nop"); } } void Adc_EndOfNormalChain_Callback(void) { Siul2_Dio_Ip_TogglePins(PTA_L_HALF, 1U << 1U); } I measure the time between the two GPIO transitions using a logic analyzer. Based on the ADC timing alone, I calculated it, which gives approximately 700ns. However, the measured GPIO pulse width is approximately 4us. I would like to understand the following: What is the correct formula for a single normal conversion when pre-sampling and hardware averaging are disabled? Does the ADC calibration performed by Adc_Sar_Ip_DoCalibration() affect the timing of every subsequent ADC conversion, or does it only calculate/store calibration values during initialization? Do gain correction, offset correction, internal capacitor charging, settling time, or any internal ADC processing add additional cycles to every conversion? What is the exact conversion-time formula for the S32K312 SAR ADC for one channel in normal conversion mode? Does the measured time between: Adc_Sar_Ip_StartConversion() and Adc_EndOfNormalChain_Callback() include significant RTD software overhead, interrupt latency, ISR processing, or callback overhead? Is there a recommended method to measure only the ADC hardware conversion time, excluding RTD and interrupt overhead? If possible, could you provide the expected ADC timing in clock cycles for this configuration? My main objective is to determine whether the approximately 4 µs measurement is caused mainly by ADC hardware timing or by RTD/interrupt/software overhead. Any help related to this ADC conversion is appreciated!! Thank you.  Re: ADC Conversion time issue Hi, The ADC conversion-time equation is provided directly in S32K3 Reference Manual, section 60.3.18 "Conversion time". For your configuration (single channel, pre-sampling disabled, hardware averaging disabled), the conversion time can be calculated using that formula and the configured ADC clock. A few additional notes: 1. Adc_Sar_Ip_DoCalibration() does not affect the timing of subsequent conversions. Calibration is executed during initialization and the calibration values are then used by the ADC hardware. 2. The measured ~4 µs is not ADC conversion time only. Your measurement spans: Adc_Sar_Ip_StartConversion() ADC sampling and conversion ADC interrupt generation NVIC interrupt latency RTD ISR processing Callback dispatch GPIO toggle operations Therefore, the measured pulse width includes both ADC hardware time and software overhead. It is expected to be noticeably larger than the conversion time calculated from the RM formula alone. 3. To measure the ADC hardware conversion time more accurately, we can recommend below Toggle the first GPIO immediately after Adc_Sar_Ip_StartConversion() returns. This removes most of the start-API execution time from the measured pulse. In the ADC interrupt handler, toggle GPIO as early as possible, before calling the configured notification callback. This separates interrupt entry from callback-dispatch overhead. For the lowest GPIO software overhead, temporarily use a direct SIUL2 GPIO register write instead of Siul2_Dio_Ip_TogglePins(). Alternatively, poll the ADC end-of-chain status flag and toggle the GPIO immediately when the hardware flag becomes set. This excludes NVIC and callback overhead, although polling-loop and GPIO-write latency remain. So, based on the information provided, the ~4 µs measurement is most likely dominated by the complete software/interrupt path rather than the ADC conversion itself. BR, Petr

适用于 Mcuxpresso 的 MIMXRT1010 SDK 您好， 我一直使用 mcuxpresso ide（版本 25.6）和 SDK_2.x_FRDM-K64F，利用连接到 FRDM-K64F 评估套件上的 nrf24l01 芯片，在 2.4 GHz 频段上构建网络。我想在网络中添加几套MIMXRT1010评估套件。我正在尝试安装 SDK_2_11_0_EVK-MIMXRT1010-AGM01.zip，以便使用同一个 IDE 在 RT1010s 上构建系统。它似乎已经下载并安装，但却被默默忽略了。系统提示该软件已存在，但在“已安装的SDK”面板中只有FRDM-K64F。我已经仔细地重新编译了SDK，确保包含了mcuxpresso IDE，并且我是在Linux系统上进行开发。 我是否可能受到了某种未知病毒的攻击？ 非常感谢您的帮助。 干杯 奈杰尔 Re: MIMXRT1010 SDK for Mcuxpresso 嗨@ve3id ， 以下是一些需要测试的项目，以确保 SDK 已正确重新安装： 在“已安装的 SDK”面板中，单击“打开 SDK 处理首选项页面”： 你应该会看到类似这样的内容： 请在所有列出的 SDK 搜索根路径中搜索“SDK_2_11_0_EVK-MIMXRT1010-AGM01.zip”，然后手动将其删除。 如果您尚未修改工作区的 SDK 位置路径，则应该看到已选择“通用 'mcuxpresso' 文件夹”选项，并且仅显示 'mcuxpresso\02\SDKPackages' 搜索根目录，因为这是默认位置。 删除后，点击重新加载按钮刷新 SDK 列表： 然后再次尝试将 SDK zip 文件拖放到“已安装的 SDK”文件夹中。如果过一段时间仍未出现，请尝试再次重新加载 SDK 列表。 BR， 埃德温。 Re: MIMXRT1010 SDK for Mcuxpresso 谢谢回复。我完全按照你说的做了，/home/nigel/mcuxpresso/02/SDKPackages# 目录是唯一显示的目录，我删除了里面的 zip 文件并重新拖入，它再次出现，但之后却没有出现在已安装 SDK 面板中。我试了两次，但刷新后仍然没有出现在已安装的SDK面板中。 Re: MIMXRT1010 SDK for Mcuxpresso 我还尝试了从“可用SDK”面板中“下载并安装SDK”选项。我选择了 MIMXR1011 处理器，它将此文件下载到 /02/SDKPakcages 目录 com.nxp.mcuxpresso.sdk.sdk_2.x_mimxrt1011xxxxx_p2site_26.9.0.20191125144617176723704789806225.zi，但它没有在面板中显示为已安装。 Re: MIMXRT1010 SDK for Mcuxpresso 问题解决了！ 我尝试直接在 ~/mcuexpresso/02/SDKPackages 目录中手动解压缩，但失败了，因为它想要覆盖 cmsis 编译器，而我不想这样做。于是我在现有的 SDKPackages 目录下创建了一个名为 MIMX 的目录，并将其解压到该目录中，瞧，它就出现在我的“已安装 SDK”面板中了。我可以用 MIMXRT1011 微处理器启动一个新项目，看来我现在可以开始了。 谢谢你帮我指明了正确的方向！ 干杯 奈杰尔

cst 使用旧版 OpenSSL 生成无效的 RSA-PSS 签名。 当使用 cst 和 OpenSSL < 3.1 时，PSS 签名中使用的 salt 过长。像 i.MX91 这样的处理器期望 salt 的长度与 digest 的长度相同，但在 OpenSSL 3.1 之前，默认做法是让 salt 尽可能长。 但即使是较新的 OpenSSL 版本，使用默认设置也不好，因为它在签名验证期间会接受较短的盐值。 解决方法是调用 EVP_PKEY_CTX_set_rsa_pss_saltlen，并将第二个参数设置为 RSA_PSS_SALTLEN_DIGEST。 请注意，OpenSSL 3.0 已于上个月停止维护。 安全 Re: cst creates invalid RSA-PSS signatures with old OpenSSL 你好， 感谢您的反馈，我会将此事报告给相关团队。 致以最诚挚的问候/Salduos， 阿尔多。

一个让我感到惊喜的流媒体服务 这些年来我尝试过好几种流媒体服务，但要找到一个始终保持稳定的服务比想象中要难得多。 最近我试用了NexusIPTV ，整体体验让我非常满意。流媒体播放质量很好，频道加载速度很快，而且在我测试过的所有设备上都能流畅运行。 对于 美国、英国和加拿大 的人们来说 ，或许值得将这项服务添加到比较列表中。 我在这里详细描述了我的经历： 👉 我的完整经历

A Streaming Service That Surprised Me I’ve tried several streaming services over the years, and finding one that remains consistent can be harder than expected. Recently, I spent some time testing NexusIPTV and was positively surprised by the overall experience. The streaming quality was good, channels loaded quickly, and the service worked well across the devices I tested. For people in the USA, UK, and Canada, it may be worth adding to the list of services to compare. I wrote more about my experience here: 👉 My full experience

MIMXRT1010 SDK for Mcuxpresso こんにちは、 私はmcuxpresso ide(V25.6)と、SDK_2.x_FRDM-K64Fを使って、FRDM-K64F評価キットにnrf24l01を接続して2.4 GHzのネットワークを構築しています。MIMXRT1010評価キットを2つネットワークに追加したい。RT1010sで同じIDEを使ってシステムを構築するためにSDK_2_11_0_EVK-MIMXRT1010-AGM01.zipをインストールしようとしています。ダウンロードとインストールは完了したように見えるが、その後は何も通知されずに放置される。すでに存在しているというメッセージはありますが、「インストール済みSDKs」パネルにあるのはFRDM-K64Fだけです。私はdmaxpresso IDEを含めているか慎重にSDKを再構築し、Linux上で開発しています。 未知のバグに攻撃されている可能性はありますか？ どんなご協力でもありがたいです。 乾杯 ナイジェル Re: MIMXRT1010 SDK for Mcuxpresso こんにちは、 @ve3id さん。 SDKが正しく再インストールされていることを確認するために、いくつかテストすべきポイントをご紹介します。 インストール済みSDKsパネルで「Open SDK handling preferences」ページをクリックしてください: 次のような画面が表示されるはずです。 そこに掲載されているすべてのSDK検索ルートで「SDK_2_11_0_EVK-MIMXRT1010-AGM01.zip」を検索し、手動で削除してください。 もしワークスペースのSDKの位置パスを変更していなければ、「Common 'mcuxpresso' folder」が選択されているのが確認でき、デフォルトの位置は'mcuxpresso\02\SDKPackages'の検索ルートだけが表示されるはずです。 削除後は、リロードボタンをクリックしてSDKsリストを更新してください: その後、SDKのzipファイルをもう一度ドラッグ&ドロップしてインストール済みSDKsに切り替えてみてください。しばらくしても表示されない場合は、再度SDKリストを再読み込みしてみてください。 BR、 エドウィン。 Re: MIMXRT1010 SDK for Mcuxpresso 問題解決！ ~/mcuexpresso/02/SDKPackages ディレクトリ内で手動で解凍しようとしましたが、cmsis コンパイラを上書きしようとしたため失敗しました。上書きは望んでいませんでした。そこで既存のSDKPackagesディレクトリの下にMIMXディレクトリを作成し、そこに解凍したところ、すぐに「インストール済みSDKs」パネルに現れました。MIMXRT1011 MPで新しいプロジェクトを始められるので、今は問題なさそうです。 正しい方向へ導いてくださり、ありがとうございました！ 乾杯 ナイジェル Re: MIMXRT1010 SDK for Mcuxpresso ご返信ありがとうございます。あなたが言った通りに試しましたが、/home/nigel/mcuxpresso/02/SDKPackages#ディレクトリだけが表示されていました。そこに入っていたzipファイルを削除して再度ドラッグしましたが、再び表示されましたが、インストールされたSDKパネルには表示されませんでした。2回試しましたが、更新してもインストールされたSDKsパネルに表示されません。 Re: MIMXRT1010 SDK for Mcuxpresso また、「利用可能なSDKs」パネル内の「SDKsのダウンロードとインストール」オプションも試しました。MIMXR1011プロセッサを選択し、このファイルを/02/SDKPakcagesディレクトリにダウンロードしました com.nxp.mcuxpresso.sdk.sdk_2.x_mimxrt1011xxxxx_p2site_26.9.0.20191125144617176723704789806225.zi ですが、パネルにはインストール済みとして表示されません。

Showing a short looping product video on a GUI Guider screen (i.MX RT) I would like to show a short looping product demo clip (about 10 seconds) on the idle screen of a GUI Guider project running on an i.MX RT board. The clips are short marketing videos made with an AI video tool such as Nereo (https://www.nereo.io/), so the source is a normal H.264 MP4. Questions: Is converting the MP4 to an image sequence and using an animated image widget the recommended approach in GUI Guider, or is there a better supported path (for example an MJPEG/AVI player)? What frame rate and resolution are realistic on i.MX RT1170 / RT1060 without affecting touch responsiveness? Any guidance on storing the frames in external flash versus SD card for this use case? Thanks for any pointers to examples or app notes. Re: Showing a short looping product video on a GUI Guider screen (i.MX RT) Hi @nereostudio, 1. That would be the recommended approach for an application like this one, yes. 2. The expected FPS and resolution will depend on many variables, including display interface bandwidth and color depth, chosen MCU core and frequency, whether accelerators are being used on the graphics pipeline, number of extra widgets displayed and widget complexity, etc. That said, the RT1170 would clearly perform better than the RT1060, so if you intend to maintain steady 30fps, I suggest going for the RT1170. Additionally, there are many ways of ensuring performance if you are not reaching the desired spec, which are described on the following section of the User Guide: Performance optimization — GUI Guider Documentation 3. GUI Guider by default converts images to .c files that are built alongside the rest of the GUI into a single binary file to be stored in flash, so there is not much to worry about here.

在 GUI 引导屏幕上显示循环播放的简短产品视频 (i.MX RT) 我想在运行于 i.MX RT 板上的 GUI Guider 项目的空闲屏幕上显示一个简短的循环产品演示片段（大约 10 秒）。这些短片是使用 Nereo（ https://www.nereo.io/ ）等人工智能视频工具制作的简短营销视频。所以源文件是普通的 H.264 MP4。 问题： 在 GUI Guider 中，将 MP4 转换为图像序列并使用动画图像控件是推荐的方法吗？还是有更好的支持方法（例如 MJPEG/AVI 播放器）？ 在不影响触控响应的前提下，i.MX RT1170 / RT1060 的帧速率和分辨率分别是多少？ 对于这种使用场景，关于将帧存储在外部闪存卡还是 SD 卡上有什么建议吗？ 感谢您提供的任何示例或应用说明。 Re: Showing a short looping product video on a GUI Guider screen (i.MX RT) 嗨@nereostudio ， 1.是的，对于这类应用来说，这的确是推荐的方法。 2. 预期帧率和分辨率取决于许多变量，包括显示界面带宽和颜色深度、所选MCU内核和频率、图形管线是否使用加速器、显示的额外控件数量和控件复杂性等。也就是说，RT1170 的性能显然比 RT1060 更好，所以如果你打算保持稳定的 30fps，我建议选择 RT1170。此外，如果您未能达到预期的性能指标，还有许多方法可以确保性能提升，这些方法在用户指南的以下章节中有详细介绍：性能优化 — GUI 指导文档 3. GUI 指南默认将图像转换为 .c 格式。这些文件与 GUI 的其他部分一起构建成一个单独的二进制文件，并存储在闪存中，因此这里没有什么可担心的。

MIMXRT1010 SDK for Mcuxpresso Hi, I have been using mcuxpresso ide (V25.6) with SDK_2.x_FRDM-K64F to build a network on 2.4 GHz using the nrf24l01 attached to FRDM-K64F eval kits.  I want to add a couple of MIMXRT1010 eval kits to the network.  I am trying to install SDK_2_11_0_EVK-MIMXRT1010-AGM01.zip to use the same IDE to build a system on the RT1010s.  It appears to download and install but silently gets ignored. There is a message saying that it already exists, but the only one in the 'installed SDKs' panel is the FRDM-K64F.  I have re-built the SDK carefully checking that I have included the mcuxpresso IDE and am developing on linux.   Is it possible that I am being stomped by an unknown bug? Any help appreciated. cheers Nigel Re: MIMXRT1010 SDK for Mcuxpresso Hi @ve3id, Here are a few things to test to make sure that the SDK is re-installed properly: On the Installed SDKs panel, click on the "Open SDK handling preferences page": You should see something like this: Please search for the 'SDK_2_11_0_EVK-MIMXRT1010-AGM01.zip' on all of the SDK search root paths that are listed there and delete it manually. If you haven't modified the SDK location paths for your workspace, you should see the option "Common 'mcuxpresso' folder" selected, and only the 'mcuxpresso\02\SDKPackages' search root, as this one is the default location. Once deleted, refresh the SDK list by clicking on the reload button: Then try drag and dropping the SDK zip file to the Installed SDKs once more. If it doesn't appear after a while, try reloading the SDK list once again. BR, Edwin. Re: MIMXRT1010 SDK for Mcuxpresso Problem solved! I tried unzipping it manually inside the ~/mcuexpresso/02/SDKPackages directory directly and it failed because it wanted to over-write cmsis compiler, which I didn't want it to do. So I created an MIMX directory underneath the existing SDKPackages directory unzipped it there, and hey presto it appears in my 'installed  SDK' panel.  I can start a new project with the MIMXRT1011 mpu, so it looks like I am good to go now. thanks for your help in pointing me the right way! cheers Nigel Re: MIMXRT1010 SDK for Mcuxpresso I also tried the 'download and install SDKs option from inside the 'available SDKs' panel.  I selected the MIMXR1011 processor and it downloaded this file into the /02/SDKPakcages directory com.nxp.mcuxpresso.sdk.sdk_2.x_mimxrt1011xxxxx_p2site_26.9.0.20191125144617176723704789806225.zi but it does not show in the panel as installed. Re: MIMXRT1010 SDK for Mcuxpresso Thanks for the reply. I tried exactly what you said, the /home/nigel/mcuxpresso/02/SDKPackages# directory was the only one shown, I deleted the zip file in there and dragged it again, it appeared again but then did not appear in the installed SDKs panel.  I did it twice, but still doesn't appear in the installed sdks panel after a refresh. 

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 Re: VRC_CTRL Clarification Hello Pavel, Thanks a lot for your detailed answer. VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator. What will happen if VRC_CTRL is enabled and OBE is also enabled at the same time? Maybe a intermediate level will be present on PTE13? Where can I find some diagram to describe the combined driving path from both direct signal and SIUL2 output-multiplexing? The following is my measurement. You can see when VRC_CTRL is enable, GPIO output can have some impact to the PTE13. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. How to trigger the load change, is it by switching the frequency of the core?   MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function. I didn't quite understand here, at least GPIO141 can be used when VRC_CTRL is disabled, why does RM just mention MSCR141 is not supported? Actually I can access MSCR141 from debugger, and I can switch the settings there.  Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected. Sorry, I didn't get your point here. Actually this is the main reason I asked this question, following code will be generated when I configure PTE13 PinMode as PG_VRC_CTRL_OUT in MCAL Port module. #define SIUL2_0_PORT141_PG_VRC_CTRL_OUT (PORT_ONLY_OUTPUT_MODE) Port_Ipw_SetOnlyOutputMode() will be called and “OBE” bit will set in this function.​ I think it maybe a MCAL bug, PG_VRC_CTRL_OUT mode enables OBE by mistake. Could you please help to check? Do you think that configuring it to GPIO + PORT_PIN_HIGH_Z + PORT_PIN_LEVEL_NOTCHANGE can be a workaround, in this case, MSCR141 of PTE13 can be guaranteed to be 0 (OBE = 0)? Best regards Kumamon Re: VRC_CTRL Clarification Hello @kumamon , I think the main misunderstanding is that VRC_CTRL is being treated as a regular SIUL2/GPIO output. VRC_CTRL is a direct output of the PMC last-mile regulator. When the external ballast-transistor supply option is used, the PMC monitors the V15 domain and adjusts VRC_CTRL, which is connected to the base of the external NPN transistor. This forms a closed analog feedback loop. Therefore, VRC_CTRL is not controlled through the normal GPIO output data registers. For this reason, the GPIO ALTx, IBE and OBE combinations in the table are not applicable to the VRC_CTRL function: IBE only controls the digital input buffer and has no role in the V15 regulator feedback loop. VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator. The last-mile regulator is controlled by the PMC, including the PMC_CONFIG[LMBCTLEN] field and the initialization sequence documented in the device-specific PMC chapter. VRC_CTRL is an analog control signal rather than a digital status output. Consequently, there is no single fixed waveform that applies to all designs. Its voltage depends on the external transistor, V15 load, supply voltage, external capacitance and operating mode. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. The expected result is that V15 remains within its specified operating range while VRC_CTRL adjusts the external transistor as required. MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function. Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected. Please also note that the reset behavior is derivative-specific. For example, the S32K3x8 (and S32K356) PMC has a device-specific CONFIG reset value of 0x00000083, so the last-mile regulator configuration is enabled after reset. This must not be generalized from older S32K3 derivatives where LMBCTLEN may need to be enabled explicitly. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks for the answer. The generic Port driver enables OBE when an output mode is requested. Do you know which setting other than PG_VRC_CTRL_OUT in the following figure introduces the "output mode"? Sorry, but I still feel MCAL Port maps the PG_VRC_CTRL_OUT to output mode by mistake. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. How to trigger the load change, is it by switching the frequency of the core?   Thanks. BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , Thank you for the measurements. They confirm that setting MSCR141[OBE] = 1 enables the digital output driver and allows the GPIO level to influence the VRC_CTRL node. Enabling the GPIO output driver while the PMC last-mile regulator is active is not a supported configuration and can disturb V15 regulation. This does not necessarily indicate an MCAL driver defect. PTE13/VRC_CTRL is a special-purpose pin that requires application-specific handling. The generic Port driver enables OBE when an output mode is requested, but it cannot determine whether the PMC regulator and the external ballast-transistor circuit are being used. Your proposed workaround is appropriate, provided that the resulting configuration leaves MSCR141[OBE] = 0: Use PORT_PIN_HIGH_Z. Use PORT_PIN_LEVEL_NOTCHANGED. Verify MSCR141[OBE] after Port_Init(). Do not subsequently configure PTE13 as a digital output while VRC_CTRL is active. The essential requirement is to keep the digital output buffer disabled. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks. The configuration shown in your screenshot appears to be correct. But the question is that the generated code will enable OBE bit, which is not expected. changing the CPU workload while keeping the clock configuration unchanged is generally easier to interpret than changing the core frequency. Could you please explain a bit on how to change CPU workload? Thanks. BR/Kumamon. Re: VRC_CTRL Clarification Hello Pavel, Thanks. Please note that MSCR141 is documented as not supported for this special-purpose direct signal. According to the following diagram, PTE13 is not necessarily VRC_CTRL, it can be any of other functions. I feel It is conflicting to the statement "MSCR141 is not supported". Could you please provide the exact MCAL/RTD version and the relevant generated configuration and initialization code that sets OBE? Also provide exact version of used S32K3 MCU. RTD Version: Configuration: Generated: Note: Sorry, I made a mistake in previous discussion. OBE is not set by Port_Ipw_SetOnlyOutputMode(), it shall be set in Siul2_Port_Ip_PinInit(). MCU: S32K322 Thanks. BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , The configuration shown in your screenshot appears to be correct. Regarding the load-change measurement, this was only an optional suggestion for evaluating the regulator response. It is not required to verify the VRC_CTRL configuration. If such a test is desired, changing the CPU workload while keeping the clock configuration unchanged is generally easier to interpret than changing the core frequency. Best regards, Pavel Re: VRC_CTRL Clarification Hello @kumamon , I now understand your concern. Your configuration selects: Pin Direction = PORT_PIN_HIGH_Z Pin Level Value = PORT_PIN_LEVEL_NOTCHANGED Pin Mode = PG_VRC_CTRL_OUT Therefore, the digital output buffer is not expected to be enabled. If the generated code nevertheless sets OBE = 1, this behavior should be investigated in the MCAL Port configuration. Please note that MSCR141 is documented as not supported for this special-purpose direct signal. PTE13/VRC_CTRL is controlled by the PMC and should not require a normal SIUL2 output-buffer configuration. Accessing or modifying MSCR141 manually is therefore not a supported application method. Could you please provide the exact MCAL/RTD version and the relevant generated configuration and initialization code that sets OBE? Also provide exact version of used S32K3 MCU. Regarding the CPU workload, this was only an optional suggestion for observing the regulator response and is not required to verify the VRC_CTRL configuration. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks a lot for detailed explanation. The best way seems to be excluding PTE13 from MCAL port configuration completely. Our use-case is a little special: - In bootloader, most of the pins are configured as input (IBE = 1).   // and we do not want to change bootloader now. - in application, in order to make PTE13 perfectly untouched, I configure it to GPIO + HIGH_Z, so IBE can be cleared then. Question (Please forgive my verbosity): - According to previous discussion, "IBE = 1" will not impact VRC_CTRL function, right? I can keep IBE = 1? - If I configure PTE13 to GPIO + HIGH_Z to achieve perfect untouched state in application, it is also OK, right? Thanks BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , I performed a detailed investigation. Here are the results: The Port configuration data and the resulting behavior are consistent between S32K3 RTD 4.0.0 and RTD 7.0.1. S32K3 Reference Manual: The statement that MSCR141 is not supported requires a clearer device-specific explanation. MSCR141 is not supported on S32K388 and S32K389, where PTE13 and the VRC_CTRL pin function are not defined. Configuration when PTE13 is used as VRC_CTRL: If PTE13 is used as the VRC_CTRL output of the PMC last-mile regulator, the pin does not need to be configured in the MCAL Port module. Configuration when PTE13 is used as GPIO or another peripheral function: In this case, the PMC VRC_CTRL function must not be active. This is particularly important for derivatives where the last-mile regulator is enabled after reset. The application must first configure the PMC supply appropriately before assigning PTE13 to a regular SIUL2 function. The two use cases should therefore be treated as mutually exclusive: VRC_CTRL use: Configure the PMC last-mile regulator. Leave PTE13 untouched by the MCAL Port module. GPIO or peripheral use: Disable or do not use the PMC last-mile regulator. Configure PTE13 through the MCAL Port module. Your measurements are consistent with this distinction. If the PMC VRC_CTRL function and the SIUL2 digital output buffer are active at the same time, the digital output path can influence the VRC_CTRL node and disturb the V15 regulation. This simultaneous configuration should therefore be avoided. Best regards, Pavel Re: VRC_CTRL Clarification Hello @kumamon , Thank you for clarifying your use case. Yes, IBE = 1 can remain enabled. Yes, you can configure PTE13 to GPIO + HIGH_Z. Just do not select PG_VRC_CTRL_OUT in the MCAL Port configuration. RTD classifies this mode as PORT_ONLY_OUTPUT_MODE, independently of the selected PortPinDirection and consequently enables the output buffer. Selecting PORT_PIN_HIGH_Z does not override this behavior for PG_VRC_CTRL_OUT. Best regards, Pavel Re: VRC_CTRL Clarification Hello @Pavel, Thank you for your effective, and detailed support. It is clear to me now, I will close this ticket. BR/Kumanon

优惠券无效 FRDM-MCXN236 还有其他人遇到免费板优惠券代码无法使用的问题吗？ NXP 正在宣传赠送一块免费电路板供用户入门，但结账时优惠券代码显示无效，即使该产品显然有库存。这是系统故障吗？还有其他人遇到这个问题吗？ 开发板 FRDM培训 Re: Coupon not valid FRDM-MCXN236 很遗憾，我们的市场营销团队通知我们，此优惠券已达到使用上限，不会再延长有效期。 优惠券将在未来几天内失效。由此给您带来的不便，我们深表歉意，并感谢您的理解。

スマートカードリーダーの便利な活用法は？ 私のThinkPad T15にはスマートカードリーダーが搭載されているのに、1年間もそのことに気づかなかった。 何か面白い使い道はあるの？職場ではメールの暗号化にそれらを使用していますが、それは個人的な用途にはあまり適していません。きっと何か面白い使い道があるはずだ。 スマート・カード Re: Good uses for Smartcard Reader? お世話になります。 こちらはカスタマーサポートのファビアンです。 すでにご覧の通り、スマートカードリーダーは幅広い用途に対応しており、認証やアクセス制御はその中でも最も一般的なものです。ただし、リーダー自体はISO/IEC 7816-4規格に準拠した通信のみを提供する点にご注意ください。完全なソリューションを開発しスマートカードを運用するには、Lenovoの適切なミドルウェアやイネーブルメントソフトウェア、そして資格を持つカードプロバイダーのスマートカードが必要です。 追加のガイダンスについては、推奨ベンダーやソリューションプロバイダーについてはパートナー一覧をご参照ください。

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 文件的单一调试配置的推荐方法是什么 ？ 我附上了两张截图： 其中一张图显示了插入变量后的调试配置以及由此产生的错误。 其中一张图显示了“选择变量”对话框，以及可用变量的列表。 感谢您的支持。 此致， 保罗·贝尔纳斯科尼 错误 Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl 嗨@pberna67 ， 你看到的是该 IDE 的一个已知限制。该问题以及可能对您有效的解决方法已在此处描述： ${project_loc}在调试配置设置中无法展开 - NXP 社区 BR， 埃德温。 Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl 亲爱的埃德温 抱歉，您提供的链接并没有给出明确的解决方案。 我正在使用 MCUXpresso IDE v24.12 [版本 148] [2025-01-10] 。最新版本的MCUXpresso是否存在同样的IDE问题？ 此致 Paolo Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl 亲爱的埃德温 抱歉，您提供的链接并没有给出明确的解决方案。 此致 Paolo

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? Re: RT1160 Spread Spectrum crashing... Hi @application_ninja, Although you've moved fsl_clock.o to RAM, the function SDK_DelayAtLeastUs() is located on fsl_common_arm.o, which is still flash resident. At least, all of the call chain that performs the change for the clock should be located on the internal RAM. This is why on AN12879 (How to Enable Spread Spectrum for RT Family) all of the code was loaded either on ITCM or DTCM. Re: RT1160 Spread Spectrum crashing... Thank you for the response, however moving fsl_common_arm.o still causes the device to crash. This time however it does get past "SDK_DelayAtLeastUs", but the crash is a very hard one and the debugger does not stop to note where the crash occurs. The program is quite large and I cannot run it all from ITCM / DTCM.

智能卡读卡器有哪些好用途？ 我的 Thinkpad T15 笔记本电脑配备了智能卡读卡器，而我竟然一年后才知道。 它有什么很棒的用途吗？在工作中，我们用它们来加密邮件，但这并不是用于私人用途的。我相信它肯定有很多好玩的用途。 Smart Card Re: Good uses for Smartcard Reader? 您好，先生， 我是客服部的 Fabian。 您可能已经看到，智能卡读卡器支持多种应用，其中身份验证和访问控制是最常见的应用之一。但是请注意，该读卡器本身仅提供符合 ISO/IEC 7816-4 标准的通信。要开发完整的解决方案并运行智能卡，您需要联想提供的相应中间件或启用软件，以及来自合格卡提供商的智能卡。 如需更多指导，请参阅我们的合作伙伴目录，了解推荐的供应商和解决方案提供商。

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つ目は、変数を挿入したデバッグ構成と、それによって発生したエラーを示すものです。 使用可能な変数の一覧が表示された「変数の選択」ダイアログを表示した画像。 再開まで今しばらくお待ちください。 よろしくお願いします、 パオロ・ベルナスコニ エラー Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl こんにちは、@pberna67 さん。 あなたが見ているのはIDEの既知の制限です。問題と、あなたに合うであろう回避策はこちらに説明されています: ${project_loc}はDebug Configurations設定で展開しません - NXPコミュニティ BR、 エドウィン。 Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl エドウィン様 申し訳ありませんが、ご指摘のリンク先には明確な解決策は示されていません。 私はMCUXpresso IDE v24.12[ビルド148][2025-01-10]を使っています。最新バージョンのMCUXpressoも同じIDEの問題を抱えていますか? よろしくお願いします。 パオロ Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl エドウィン様 申し訳ありませんが、ご指摘のリンク先には明確な解決策は示されていません。 よろしくお願いします。 パオロ

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 Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl Hi @pberna67, What you are seeing is a known limitation for the IDE. The issue, as well as a workaround that would likely work for you, is described here: ${project_loc} doesn't expand in Debug Configurations settings - NXP Community BR, Edwin. Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl Dear Edwin Sorry but the link at which you are referring to doesn't not indicate a clear solution.  I'm using MCUXpresso IDE v24.12 [Build 148] [2025-01-10]. Has the latest version of MCUXpresso the same IDE problem ? Regards Paolo Re: MCUXpresso IDE v24.12 [Build 148] [2025-01-10] doesn't suppoert Debug Confguration "Variabl Dear Edwin Sorry but the link at which you are referring to doesn't not indicate a clear solution.  Regards Paolo