[RTD600 MCAL] S32K3X4EVB-T172 RTC API Wake-up This example project will show user how to use and configure the basic functionalities of WKPU + GPT RTC API.  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-T172 (SCH-53148 REV B2) or S32K344MINI-EVB * MCU: S32K344 * IDE: S32DS3.5 & S32DS3.6 * SDK release: RTD 6.0.0 * Debugger: PE Micro * Target: internal_FLASH  ------------------------------------------------------------------------------ This example routine configures the WKPU & RTC units for wake-up. The RTC is present in always ON domain, hence available in RUN mode as well as in STANDBY mode. The chip contains one instance of RTC (Real Time Clock) timer and API (Autonomous Periodic Interrupt) timer, where both can perform 32-bit comparisons. Both RTC and API timers can generate interrupts as well as wake-up from low power modes. The following figure highlights the path for RTC API wake-up. Please refer to Chapter 69.3.2 API functional description from the S32K3XX reference manual (Rev. 12) for further information. The routine waits for SW5 to be pressed, then: Turns off the green LED Switches CORE_CLK to Option C - Boot Standby mode (CORE_CLK @ 24 MHz). Initializes the ICU driver. Configures RTC_API channel (WKPU0) Initializes GPT module. Starts timer and sets RTC_API_TIME. Enters standby. After the period defined, RTC API generates an interruption and MCU wakes up. After wake-up, MCU resets and polls for SW5 to be pressed again. The RTC API value can be changed with RTC_API_TIME definition. This example is provided as is with no guarantees and no support.

RT685: SDK 25.12 no HASHCRYPT acceleration Hello, We recently updated to SDK 25.12 and noticed that our TLS decryption rate has been cut in half. mbedTLS v3.x is no longer accelerated using the fsl_hashcrypt hardware features. Here is the callstack of calling mbedtls_ssl_read using the previous SDK 25.09. As you can see, HASHCRYPT_AES_EncryptEcb is eventually used. hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> Here is the callstack of SDK 25.12 with MBEDTLS_USE_PSA_CRYPTO defined. In this version, mbedtls_internal_aes_encrypt is all C code with no HW acceleration. mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> And here is the callstack of SDK 25.12 withoutMBEDTLS_USE_PSA_CRYPTO defined. In this version,  mbedtls_internal_aes_encrypt is all C code with no HW acceleration and PSA is not involved. mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Are there plans to restore RT685 HASHCRYPT hardware acceleration to mbedTLS? It seems certain PSA Crypto drivers are not implemented. Thank you. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, I reproduced the issue on the EVK. I modified two samples by adding a loop of 200 iterations of mbedtls_gcm_self_test and timed the overall execution using the RTC clock. evkmimxrt685_mbedtls_selftest_cm33 from SDK 25.09 executed the tests in 1087ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 executed the test in 8990ms with this callstack: mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES defined executed the test in 8744ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 The gist of the modifications to the examples is the following: BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... where test_rtc_get_msecs returns the current RTC time using subsecond accuracy. As you can see, there is an ~8x slow down for encrypting GCM/AES with the new SDK. I can attach the modified examples if you'd like. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, We have looked over the migration guide. However, we don't see how mbedTLS 2.x or mbedTLS 3.x without PSA would be hardware accelerated in this version of the SDK. Since aes_alt.c was removed and HASHCRYPT functionality is only supported by the PSA drivers. Everything works in our app with SDK 25.12, and we would definitely like to use TLS 1.3 for our connections, but we would suffer a large performance loss as it is. We will continue to look into this. I will modify one of the examples to see if I can reproduce the performance loss. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Thanks for your patience with this question. I just received the response from the internal team, please see below. From the call stack I can see you are using legacy mbedtls_xxx crypto API. Indeed, it is not HW accelerated. MbedTLS3.x introduced new API for Crypto, and it is PSA. mbedtls/docs/psa-transition.md at v3.6.5 · Mbed-TLS/mbedtls · GitHub and it is accelerated. Legacy crypto API is further removed in MbedTLS4.x. I checked our psa_crypto_examples in SDK for RT600 and HASHCRYPT HW acceleration is enabled by default by having the PSA_CRYPTO_DRIVER_HASHCRYPT defined which enables crypto driver wrappers to offload crypto computation to HW. On the other hand, MbedTLS3.x+ is more complex and aligned with PSA API specification so it may happen that some use-cases are indeed producing lower performance. In case of TLS I would expect rather asymmetric cryptography (CASPER HW IP) to be bottleneck of performance, since this IP can support only bignum acceleration and it is not well compatible with PSA API that expect HW IP to implement whole algorithm. We did our best to accelerate at least some ECC operations (sign, verify) but it may happen that other operation like keygen during ECDHE key exchange may be worse. Now it would be good if you can use the PSA API for performance measurement and confirm that PSA_CRYPTO_DRIVER_HASHCRYPT is defined and call stack uses it. FYI: Hashcrypt did not offer AES-GCM acceleration natively, so it is better to benchmark AES-CBC or AES-CTR to see real gain of HW IP. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Migrating from mbedTLS 2.x (without PSA) to mbedTLS 3.x (with PSA) is bound to have performance drops, considering that: "The PSA Driver Interface has only been partially implemented. As a result, the deliverables for writing a driver and the method for integrating a driver with Mbed TLS will vary depending on the operation being accelerated." (https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) At the moment, the best I can recommend is to follow the guidelines on how to properly migrate from 2.x to 3.x: Migrating from Mbed TLS 2.x to Mbed TLS 3.0 — MCUXpresso SDK Documentation As well as the guide to properly transition to the PSA API: Transitioning to the PSA API — MCUXpresso SDK Documentation I apologize for the inconvenience. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Did you make any changes after updating the SDK? Do you also see this behavior with the SDK's example code? Are you using the standalone IDE or the VS Code extension? BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration I defined MBEDTLS_PSA_ACCEL_KEY_TYPE_AES in our mbedTLS configuration file and now it's calling through to HASHCRYPT, but our mbedtls_ssl_read read rate is even slower now. I wonder if there are other missing defines or the PSA layer is adding extra overhead.   Rates downloading 4KB packets from WiFi via a TLS socket: SDK 25.09: 205KB/sec (mbedTLS 2.x without PSA and with ksdk port files) SDK 25.12: 138KB/sec (without MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) SDK 25.12: 125KB/sec (with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) Here's the new callstack using MBEDTLS_PSA_ACCEL_KEY_TYPE_AES: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @EdwinHz, We're using MCUXpresso IDE. No extra changes after updating the SDK: When we update the SDK, we re-run the "SDK Management" -> "Refresh SDK components" to get new and updated files. Then we compare the .cproject configuration to one of the samples that has similar features enabled (e.g. evkmimxrt685_wifi_wpa_supplicant_cm33) PSA_CRYPTO_DRIVER_CASPER=1 PSA_CRYPTO_DRIVER_HASHCRYPT=1 CONFIG_WPA_SUPP_CRYPTO_MBEDTLS_PSA=1 etc... We're using the default mcux_mbedtls_config.h as the main mbedTLS configuration header and our own user configuration file that is nearly identical to wpa_supp_mbedtls_config.h from the evkmimxrt685_wifi_wpa_supplicant_cm33 example. I will try the mbedtls3x_examples to see how they behave. Perhaps we're missing some defines. As I was stepping through the code, I noticed that perhaps MBEDTLS_BLOCK_CIPHER_C needs to be defined so that the gcm operation can be accelerated. It looks like the header mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h is responsible for this but doesn't end up defining that macro for some reason. Re: RT685: SDK 25.12 no HASHCRYPT acceleration For others' benefit... It appears that mbedtls_xor from mbedTLS 3.x is looping over data 4-bytes at a time and calling mbedtls_get_unaligned_uint32 and mbedtls_put_unaligned_uint32 which both use memcpy for a single uint32. I recognize that the authors of mbedTLS are trying to improve performance by calculating blocks of XOR 4-bytes at a time (with a remainder loop), but the full calls to memcpy are actually making the code slower. After some investigation into the disassembly, it turns out that our project was being compiled with -fno-builtin, preventing small memcpys from getting inlined by the compiler. Removing that option restored much of the performance loss of HASHCRYPT hardware not being used for AES-GCM operations. So, the example I posted went from executing in 8600ms down to 2100ms. Not quite at the level of mbedTLS 2.x + ksdk alt (at 1087ms). But the restored performance is good enough. -Amilcar

PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hi, We are using an ATH12K Wi‑Fi module on an i.MX95‑based system, connected via the PCIe2 instance. On a kernel based on linux-imx lf‑6.12.y this setup fails, whereas with a kernel based on lf‑6.6.y it works as expected. The kernel driver successfully requests and receives 16 MSI interrupts. However, it subsequently fails to bring up the Wi‑Fi module: [ 5.888139] ath12k_pci 0001:01:00.0: Adding to iommu group 5 [ 5.888506] ath12k_pci 0001:01:00.0: BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0: enabling device (0000 -> 0002) [ 5.889315] ath12k_pci 0001:01:00.0: MSI vectors: 16 [ 5.889334] ath12k_pci 0001:01:00.0: Hardware name: wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0: fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0: failed to receive control response completion, polling.. [ 8.675241] ath12k_pci 0001:01:00.0: Service connect timeout [ 8.681002] ath12k_pci 0001:01:00.0: failed to connect to HTT: -110 [ 8.692180] ath12k_pci 0001:01:00.0: failed to start core: -110 There was a related discussion on the kernel mailing list [1] with a different PCIe device, but it has not yet led to a working configuration for our system. What would be the best way to proceed? Thank you for your support. Max [1] https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hello, The i,MX95 is in early stage and some configuration are not in design. However your i.MX95 with ATH12K via PCIe2 failing on lf-6.12.y but working on lf-6.6.y suggests a regression or driver interaction change in newer kernel's PCIe or Wi-Fi stack, likely involving PCIe power management (ASPM), MSI mapping, or specific PCIe endpoint quirks for the ATH12K, often resolved by kernel patches or disabling ASPM in boot args for newer kernels; check dmesg for PCIe errors, compare devicetree, and look for related commits in NXP/Linux kernel mailing lists.  Here's a breakdown of potential causes and troubleshooting steps: 1. Check Kernel Logs ( dmesg ) Look for PCIe Errors: Search for "PCI", "MSI", "ATH12K", "Error", "Firmware", or "Timeout" messages in dmesg on the failing lf-6.12.y kernel. Firmware Loading: Verify the ath12k firmware is loaded correctly and if there are any errors during initialization.  2. PCIe Power Management (ASPM) Common Issue: Newer kernels often enable Active State Power Management (ASPM) by default, which can cause issues with PCIe devices like the ATH12K on embedded systems, especially older firmware/hardware. Try Disabling ASPM: Add pcie_aspm=off to your kernel boot arguments (e.g., in U-Boot or GRUB) and test again.  3. Devicetree/DTB Differences Compare DTBs: Generate and compare the Device Tree Blobs (DTBs) used with both kernels ( .dtb files). Look for changes in the PCIe node for pci2 , especially related to interrupts, power domains, or compatibility properties.  4. Kernel Driver/Firmware Regressions Specific Commits: The ATH12K driver ( ath12k ), mac80211 , or core PCIe/ARM code in lf-6.12.y might have introduced a change breaking your setup. Search Mailing Lists: Check the Linux Kernel Mailing Lists (LKML) and NXP's lists for related patches or discussions around ath12k , i.MX95 , and newer kernels (6.12+).  5. MSI Handling Interrupt Remapping: While you receive interrupts, the way they are handled (MSI-X vs. MSI, interrupt remapping) might have subtle changes. Check Interrupts in proc/interrupts : See if the interrupt distribution or count differs between kernels.  6. Firmware Blobs Firmware Version: Ensure you are using the correct firmware for the ATH12K, compatible with the newer kernel's driver. Sometimes newer drivers require newer firmware.  In summary, start with dmesg and try disabling ASPM; these are the most frequent culprits for PCIe Wi-Fi failures in newer kernels on embedded platforms   Regards Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors While the suggestions were good pointers to debug the issue I couldn't find the solution, i.e. not all MSI IRQ vectors triggered the IRQ routines in the driver. I ended up working around the issue by changing the ath12k driver to only request one MSI IRQ. Note that current Linux master does not have the issue. Regards Max

One Time Programable (OTP) Memory Legacy 8-bit MCUs Understanding EPROM Erasure and Package Types If a microcontroller (MCU) does not have a quartz window, its EPROM cannot be erased and effectively functions as OTPROM (One-Time Programmable ROM). This is because the quartz window is essential for allowing ultraviolet (UV) light to erase the EPROM contents. How to Identify Erasable EPROMs You can determine whether an EPROM is erasable by checking the part number and package type: If the package has a windowed ceramic dual in-line package the EPROM can be erase. For example, on the HC05 family you can see this window being mentioned on the order numbers of the datasheet

如何为 QorlQ 下载 QCVS？ 尊敬的经理， 我正在使用 T2080 QorlQ CPU 并想要创建 RCW 文件。 我知道可以使用 QCVS 或 CodeWarrior Develpment Studio 制作 RCW 文件。 我安装了 CodeWarrior ver 10.5.1，但找不到 QCVS。 问题。 1.请告诉我如何下载QCVS？ （我使用的是 Windows 10，64 位） 2.如何使用Codewarrior制作RCW？ 此致 大津 回复：如何为 QorlQ 下载 QCVS？ 请重新安装 PA 10.5.1 的 CodeWarrior，然后在其上安装 QCVS。 请在新的工作区中打开 CodeWarrior，然后安装 QCVS。 如果您的问题仍然存在，请在新线程中解决。 回复：如何为 QorlQ 下载 QCVS？ 感谢您的回复。 回复：如何为 QorlQ 下载 QCVS？ 请从以下链接下载 QCVS for PA 4.5 安装文件。 https://support.nxp.com/s/case/500Tg00000FpCkuIAF/community-how-can-i-download-qcvs-for-qorlq?language=en_US 请先安装适用于 PA 10.5.1 的 CodeWarrior，然后打开 CodeWarrior IDE 并从帮助->安装新软件->添加->存档安装适用于 PA 4.5 的 QCVS。 请从文件->新建->QorIQ 配置项目创建一个 QCVS PBL 项目，然后双击组件下的“PBL:PBL”编辑属性面板，从项目->生成处理器专家代码生成二进制文件并在项目中的 Generated_Code 下获取 PBL.bin。 Re: How can I download QCVS for QorlQ? 依萍您好， 我和楼主的情况一样，请问您能把文件分享给我吗？你发的链接好像打不开，至少对我来说是这样。 此致， 瞎扯

MIMXRT1170-EVKBでJ-Linkを使用する 注：類似のEVKについては、以下を参照してください。 MIMXRT1060-EVKBまたはMIMXRT1040-EVKでJ-Linkを使用します MIMXRT1060-EVK または MIMXRT1064-EVK で J-Link を使用する MIMXRT1160-EVK または MIMXRT1170-EVK で J-Link を使用する この記事では、この EVK で J-Link デバッグプローブを使用する方法の詳細を説明します。  2つの方法があります：オンボードの MCU-Link デバッグプローブを Segger J-Link ファームウェアで更新する方法と、外部の J-Link デバッグプローブを EVK に接続する方法です。  他のデバッグプローブは必要ないので、オンボードデバッグ回路を使用すると便利です。  この記事では、J-Link を使用する2つの手順を詳しく説明します。 MIMXRT1170-EVKB jumper locationsMIMXRT1170-EVKB ジャンパの位置 外部J-Linkデバッグ・プローブを使用する セガーはいくつかの J-Linkプローブ オプションを提供しています。これらのプローブのいずれかをこれらのEVKで使用するには、EVKを次の設定で構成してください。 JP5 にジャンパを取り付け、SWD 信号をオンボードデバッグ回路から切り離してください。  このジャンパはデフォルトでは開いています。 EVK の電源を入れるには、デフォルトのオプションとして、電源をバレルジャック J43 に接続し、電源スイッチ SW5 をオン位置（3-6）に設定します。EVK が適切に電源供給されると、SW5 の隣にある緑色の LED D16 が点灯します。 J-Linkプローブを、J1、20ピン、2列0.1インチ・ヘッダーに接続します。 J-Link ファームウェアで更新してオンボード MCU-Link を使用 ドライバおよびファームウェア更新ツール用のMCU-Link インストーラをインストール EVKからUSBケーブルをすべて取り外します EVK の電源を入れるには、デフォルトのオプションとして、電源をバレルジャック J43 に接続し、電源スイッチ SW5 をオン位置（3-6）に設定します。EVK が適切に電源供給されると、SW5 の隣にある緑色の LED D16 が点灯します。 JP3 にジャンパを取り付け、ISP モードを MCU-Link に強制する USB ケーブルを J86 に、また MCU-Link デバッガに接続 MCU-Link ソフトウェアパッケージのインストール先のスクリプトディレクトリに移動し、program_JLINK.cmd（Windowsの場合）またはprogram_JLINK（Linux/MacOSの場合）のスクリプトをダブルクリックして実行します。画面上の指示に従います。Windowsでは、このスクリプトは通常C:\nxp\MCU-LINK_installer_3.122\scripts\program_JLINK.cmdにインストールされます。 J86 の USB ケーブルを取り外します JP3 のジャンパを取り外します USB ケーブルを J86 に接続し直します。  これで MCU-Link デバッガは JLink として起動するはずです。 ジャンパ JP5 を取り外し、MCU-Link デバッガの SWD 信号を接続します。このジャンパはデフォルトでは開いています。

EIQ Connector eIQ AAF Connector In this post, I want to share a quick walkthrough of eIQ AAF Connector, a REST-based server that enables LLM and VLM inference on NXP i.MX platforms using the Ara240 DNPU. The connector provides a simple HTTP interface for client applications to send prompts and receive streaming token responses from models running locally on Ara240. It is also the communication layer used by applications such as LLM Edge Studio and VLM Edge Studio.   Key Features REST API server for Ara240-accelerated model inference Chat Completions-style HTTP endpoint Streaming token responses Support for text LLMs and Qwen2.5-VL models Model configuration through server_config.json Optional tool calling and guided generation support for compatible text models Optional semantic prompt caching for text models OpenAPI documentation available through the /docs endpoint   How It Works The eIQ AAF Connector runs on the i.MX host and exposes a REST API. Client applications send prompts to the connector, which communicates with the Ara240 Runtime SDK and the loaded model.dvm running on the Ara240 DNPU. The response is returned as generated tokens, with support for streaming output.   Basic Setup Activate the connector's virtual environment: source /usr/share/eiq/aaf-connector/venv/bin/activate Run the connector: connector By default, the server starts on: 127.0.0.1:8000 To allow access from another device, start it with: connector --host 0.0.0.0   Configuration The connector uses a JSON configuration file named server_config.json to define server settings and available models. This includes model paths, tokenizer paths, model type, prompt size, tool calling support, and whether the model should be loaded at startup. { "log_level": "INFO", "model_config_path": "/usr/share/llm/{}/", "model_tokenizer_path": "/usr/share/llm/{}/tokenizer", "available_models": [ { "name": "qwen2_5-7b", "description": "Qwen2.5 7B instance", "type": "text", "tool_calling": "native", "max_prompt_size": 2047, "enabled": true } ] }   Sending a Test Request Once the server is running, a basic request can be sent to the chat completions endpoint: curl -H 'Content-Type: application/json' \ -d '{ "model": "Qwen2.5-7B-Instruct", "messages": [ { "role": "user", "content": "Who are you?" } ] }' \ -X POST 0.0.0.0:8000/v1/chat/completions The API can also be tested from the OpenAPI UI at: http://0.0.0.0:8000/docs   Walkthrough Video In the attached video, I show how to start the eIQ AAF Connector, verify the server is running, configure a model, and send a sample request to the /v1/chat/completions endpoint. (function() { var wrapper = document.getElementById('lia-vid-6405412604112w960h540r179'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)   Summary The eIQ AAF Connector provides the REST API layer for running edge AI models on NXP i.MX platforms with Ara240 DNPU acceleration. It allows applications to send prompts, receive generated responses, and integrate local LLM or VLM inference into demos, prototypes, and edge AI workflows.   Link eIQ AAF Connector repository   ARA2-M2-16G-GT ARA240 Hands-On Training

KW45 知识中心 KW45 的三核架构集成了一个 96 MHz CM33 应用核心、专用 CM3 无线模块内核和一个隔离的 EdgeLock 安全区域。基于闪存的无线模块内核具有专用 SRAM，可提供高度可配置和可升级的软件实施无线模块，从而将主内核上的资源释放给客户应用空间。 符合低功耗蓝牙 5.3 标准的无线模块最多可同时支持 24 个安全连接。EdgeLock 安全区域的隔离执行环境提供了一套加密加速器、密钥存储操作和安全生命周期管理，最大限度地减少了主要内核安全责任。 KW45 MCU 还集成了 FlexCAN，有助于无缝集成到汽车的车载或工业 CAN 通信网络中。FlexCAN 模块可以支持 CAN 的灵活数据传输速率 (CAN FD)，以实现更高带宽和更低延迟。 KW45 方框图 KW45 架构框图 文件 参考手册 Datasheet Errata Secure Reference 手册** 认证 SESIP 认证 SESIP ST PSA认证 RED 认证 欧盟符合性声明 (EVK) 欧盟符合性声明（LOC） 日本 MIC KW45-LOC _TELEC-20250221请参见下方附件 蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview 评估板 KW45 KW45-EVK KW45-EVK 原理图 KW45-EVK设计文件 KW45-EVK 用户手册 KW45-LOC 用户手册 KW45-EVK快速入门 应用笔记 软件、硬件和外设： AN14122 ：如何在 KW45 上使用 RTC本应用笔记介绍了如何在 BLE 演示中配置和使用 RTC 外围设备 AN14141：在 KW45 低功耗蓝牙连接堆栈中启用看门狗定时器模块 。本应用笔记描述了在连接堆栈演示中实现 WDOG 定时器的过程。 AN13855：将 OTAP 客户端服务集成到 KW45/K32W1 蓝牙 LE 外围设备中 本应用笔记提供了将空中编程客户端服务集成到 BLE 外围设备的步骤和过程。 AN13584：Kinetis KW45 和 K32W1 负载拉动报告 本应用笔记描述了负载拉动特性的测量方法及相关结果。 AN13860：使用 OTAP 工具为 KW45/K32W1 创建固件更新镜像 本应用笔记提供了通过 OTAP 工具在 KW45 开发板上创建并升级镜像的步骤。 AN14077：将 KW45 (1MB) 迁移至 KW45 (512kB) 的步骤  本应用笔记描述了从 1MB 闪存迁移至 512kB 闪存所需的初始步骤。 电源管理： AN13230：Kinetis KW45 和 K32W1 蓝牙低功耗 (BLE) 功耗分析  本应用笔记提供了关于 KW45 无线微控制器 (MCU) 的功耗信息，包括硬件设计及优化以实现低功耗运行。 AN13831：KW45/K32W1 电源管理硬件  本应用笔记描述了在 KW45/K32W1 微控制器中用于电源管理的不同模块的使用方法。 射频： AN13687：K32W1 802.15.4 应用连接性测试 本应用笔记介绍了如何使用连接性测试工具来测试 K32W1 802.15.4 的射频性能。 AN13728：KW45 射频系统评估报告（适用于蓝牙低功耗和 IEEE 802.15.4 应用）本应用笔记提供了 KW45 开发板在蓝牙低功耗（2FSK 调制）和 IEEE 802.15.4（OQPSK 调制）应用中的射频评估测试结果。还描述了可以用于执行测试的设置和工具。  AN14098: KW45-LOC 射频测试报告  本应用笔记提供了KW45B41Z定位板的基本射频测试结果。  AN13228：用于 BLE 应用的 KW45-EVK 射频系统评估报告 本应用笔记提供了 KW45B41Z-EVK 在 BLE 应用中使用二进制频移键控调制的射频评估测试结果。 AN13229：KW45-EVK 与射频系统共存的评估报告（适用于 BLE 应用）本应用笔记提供了 KW45B41Z-EVK 在 BLE 应用（2FSK 调制）中的射频评估测试结果 AN13512：Kinetis 无线产品系列 BLE 与 Wi-Fi 共存应用  本应用笔记介绍了 K32W1/4X 低功耗产品系列对 Wi-Fi 信号的抗干扰能力，并提供了改善与 Wi-Fi 共存的方法  安全性： AN13859：KW45/K32W1 系统内编程工具  本应用笔记提供了在 ISP 模式下启动 KW45/K32W1 微控制器并建立各种串行连接以与微控制器通信的步骤。 AN1403：在批量生产中通过串行线调试（SWD）为KW45闪存编程以应用和无线固件 。本应用笔记详细介绍了在批量生产中通过SWD编写、烧录和设置所有必要参数的步骤。  AN13883: 通过 SPSDK 使用 ISP 更新 KW45 无线电固件  本应用笔记提供了在 ISP 模式下启动 KW45/K32W1 MCU 并使用安全二进制文件更新无线电固件的步骤。 AN14109：使用SEC工具实现KW45和K32W148安全启动 本应用笔记提供了使用 SEC GUI 工具，通过签名镜像和安全二进制文件实现 KW45/K32W1 MCU 安全启动的步骤。 AN13838：KW45 和 K32W148 安全启动使用 SPSDK 命令行工具本应用笔记提供了使用 SPSDK 命令行工具，通过签名镜像和安全二进制文件实现 KW45/K32W1 MCU 安全启动的步骤。 AN13931：KW45 和 K32W148 的生命周期管理 本应用笔记提供了使用 SEC GUI 和 SPSDK 命令行工具来转换 KW45/K32W1 MCU 的过渡生命周期的步骤。 AN14174：KW45/K32W148 使用 NPX 进行闪存加密本应用笔记提供了在 KW45/K32W1 微控制器上启用实时加密的步骤。 AN14158：KW45/K32W148 上的调试认证本应用笔记介绍了如何进行调试认证，以便在现场安全地调试应用程序。  AN14544：EdgeLock 2GO 服务适用于 MPU 和 MCU 本应用笔记介绍了 NXP 设备的 EL2GO 服务。该服务允许在不受信任的环境中为设备进行信任配置。 支持 如果您对 KW45 有任何疑问，请在我们的无线 MCU 社区中留下您的问题！此处 有用链接 参考设计 - NXP 社区 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区：该社区提供了如何使用信号频率分析仪的步骤 首次正确构建 PCB 的最佳方式是使用 KW45（汽车）或 K32W1/MCXW71（物联网/工业）... 社区：在此社区中，您可以找到使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接，所有链接均涉及无线电性能、低功耗和无线电认证 (CE/FCC/ICC) 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式：本文分为两部分： 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序设置发射机/接收机测试命令：本文提供了相关步骤，展示用户如何向设备发送串行命令。 Bluetooth LE HCI 黑盒快速入门指南：本文介绍了一个简单流程，能让用户通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具： 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序（汽车或物联网）的功耗，并评估您解决方案的电池寿命。 KW45/K32W1 32MHz 和 32kHz 振荡裕度：本文提供了电路中振荡裕度的正确配置。 基于 KW45 的 CS 1 对多演示NXP - 信道探测   培训 BLE Introduction  射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备： 本文提供了有助于项目开发的设备链接  开发工具  SDK 构建器： MCUXpresso SDK 提供开源驱动程序、中间件和参考示例应用程序，以加快软件开发。 SDK GitHub：SDK 开源驱动程序、中间件和参考示例在 GitHub 上。 NXP MCUXpresso： MCUXpresso 集成开发环境 (IDE) 提供了高级编辑、编译和调试功能，并增加了 MCU 专用的调试功能。支持与所有通用 Arm Cortex-M 的连接。  NXP SPSDK：是一个统一、可靠且易于使用的Python SDK库，适用于 NXP MCU 产品组合，为客户快速制作原型到生产部署提供坚实的基础。 NXP SEC工具： MCUXpresso安全配置工具是一款基于 GUI 的应用程序，用于简化在 NCP MCU 设备上生成和配置可启动的可执行文件。 NXP OTAP Tool： 是一款帮助用户对 NXP 开发板执行空中固件更新的应用程序。 配置工具： MCUXpresso 配置工具是一套集成的配置工具套件，这些工具允许开发人员快速构建自定义 SDK，并利用引脚、时钟和外设生成初始化 C 代码或自定义板支持的寄存器值。 无线 MCU 的 SDK 示例： 这些无线示例包含许多常见的蓝牙配置。 **对于安全文件，必须请求额外的访问权限。  动手实践培训 产品：K32W1 协议：802.15.4 协议：BLE -> 连接性 协议：蓝牙 协议：Matter 协议：Thread 协议：Zigbee

CI/CD 最佳实践 以前也有过几个类似的帖子，但答案都有点过时了，而且我的问题也略有不同，所以也许值得再问一次。我有两个问题： 1。每隔一段时间，在 S32DS (v 3.6.2) 中进行版本时，操作系统是 Windows 11），版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件，执行 "更新代码"（尽管实际上不应该更新任何内容）并重建后，问题就解决了。我的问题是：为什么会出现这种情况？这种情况似乎是随机发生的，所以我无法提供任何 "重现步骤"，但这种情况经常发生，如果你至少没有意识到这一点，我会很惊讶。我看到其他一些人也在论坛上提到这个问题。 2。我们正在努力将要编程到闪存的整个代码库（而仅限于我们的应用程序代码）放入 git 中，并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议？特别是，由于 RTD、C 标准库等都在项目之外，而且 IDE 安装了很多连接，因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链？ Re: Best practices for CI/CD 谢谢@petervlna提供的提示。关于 CI/CD 管道，我还有一个问题： 如何在 Linux 环境中安装独立于 IDE 的版本工具链？ Re: Best practices for CI/CD 你好 1。每隔一段时间，在 S32DS (v 3.6.2) 中进行版本时，操作系统是 Windows 11），版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件，执行 "更新代码"（尽管实际上不应该更新任何内容）并重建后，问题就解决了。我的问题是：为什么会出现这种情况？这种情况似乎是随机发生的，所以我无法提供任何 "重现步骤"，但这种情况经常发生，如果你至少没有意识到这一点，我会很惊讶。我看到其他一些人也在论坛上提到了这个问题。 这个问题在 S32DS 等基于 Eclipse 的集成开发环境中比较常见。以下是最可能的原因： 索引/路径解析故障 S32DS 依赖 Eclipse 的 CDT 索引器和项目元数据来解析包含路径。有时，索引器或内部版本配置会不同步，尤其是在更改.mex 或环境变量之后。重新打开 .mex文件和重新生成代码会强制集成开发环境刷新路径并重建索引。 临时工作区损坏 集成开发环境在工作区中存储了大量状态。如果工作区缓存变得不一致（例如，在版本中断或 IDE 崩溃之后），则在刷新之前可能无法识别包含路径。 Windows 文件系统定时 在 Windows 上，防病毒或文件锁定会在并行版本步骤中延迟对头文件的访问，从而导致间歇性故障。 2。我们正在努力将要编程到闪存的整个代码库（而仅限于我们的应用程序代码）放入 git 中，并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议？特别是，由于 RTD、C 标准库等都在项目之外，而且 IDE 安装了很多连接，因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链？ 处理 RTD 和外部 SDK 版本控制或工件库： 将 RTD 和 SDK 代码包存储在 Git（如果允许）或 Nexus/Artifactory 等工件存储库中。 环境变量： 在 CI/CD 管道中定义 RTD_PATH 和 SDK_PATH 等变量。 在 Makefile 或版本脚本中使用这些变量，而不是硬编码路径。 导出项目以进行无头版本 在 S32DS 中，将项目导出为 Makefile 项目（项目 → 生成 Makefile）。 这样，您就可以得到一个可以在集成开发环境之外使用的 Makefile。 或者，使用 s32ds.exe --build 进行基于 Windows 的无头版本，但对于 Linux CI/CD，首选 Makefile。 避免集成开发环境依赖性 不要依赖 .mex在 CI/CD 中再生。 确保在 Makefile 或 CMake 配置中捕获所有包含路径和编译器标志。 我不知道除了一般性建议之外还有没有其他建议。 顺祝商祺！ Peter Re: Best practices for CI/CD 你好@petervlna 谢谢您的建议。我需要更多这方面的信息。在 S32 Design studio 页面上，我看到了整个集成开发环境的下载选项，似乎工具链已作为集成开发环境安装的一部分安装。我没有看到工具链作为单独的下载提供。 我确实看到，在 Windows11（我目前使用的操作系统）上，工具链安装在 C:\NXP\S32DS.3.6.2\S32DS\build_tools 你的意思是 1.在 Linux 桌面上安装 Linux 版本的集成开发环境 2.将已安装的工具链从本机复制到无头 CI/CD 服务器 3.按照上述步骤操作 请予以澄清。 Re: Best practices for CI/CD 你好 如何在 Linux 环境中安装独立于 IDE 的版本工具链？ 遗憾的是，我不了解 Linux 环境，所以只能提供一般性的帮助： 官方步骤摘要： 从 S32DS 下载页面下载适用于 ARM 的恩智浦 GCC 工具链（Linux 版本）。 将压缩包解压缩到 /opt/armgcc 等目录。 将工具链 bin 目录添加到 PATH。 在 Linux 系统上安装编译工具（make、cmake）。 使用从 S32DS 导出的 Makefile 进行无头版本。 我建议有关 Linux 的问题另起一个主题。 顺祝商祺！ Peter Re: Best practices for CI/CD 你好、 你可以从恩智浦页面下载独立组网 \(SA\) gcc 例如这个 https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 或任何其他版本 https://www.nxp.com/search?keyword=gcc% 2520 &start=0 Re: Best practices for CI/CD 你好@petervlna @jiri_kral 很抱歉延迟回复已关闭的单子，但我终于有机会解决这个问题了。 彼得的建议对我来说非常合理；但是，我在 S32 IDE（v3.6.6）中找不到 “项目 → 生成 Makefile” 选项。我可以尝试复制生成的生成文件，但是它有一些不太好的地方： 1.这不是一个独立的 makefile，它依赖于其他 .mk文件也会生成。 2。生成文件是按版本目标生成的（与 .cproject 不同）文件），这使得它有点笨重。理想情况下，我想要的是一个Makefile，其中版本目标是 “制作” 的参数。 我有点惊讶其他人以前没有问过这个问题，或者你没有关于这个问题的 “操作方法” 文档；鉴于该处理器非常受欢迎并且对功能安全至关重要，我本以为在 CI/CD Linux 环境中进行版本会很常见。

s32k3 eMIOS IMPモード こんにちは、 現在、s32k3 マイクロの eMIOS IPM モードを使用して入力信号周波数を読み取ろうとしています。ステータス レジスタが測定値をキャプチャしたことを通知するまで待機した後、最初に A レジスタを読み取り、次に B レジスタを読み取り、両方のケース (通常のケースとオーバーフローのケース) の周期計算を実行します。ただし、計算では信号の周期ではなく、「High 時間」または「Low 時間」のいずれかが得られます。IPM モードでは、周期ではなく、高/低デューティ サイクルが提供されるようです。これを理解するための考えはありますか?制御レジスタが正しいモードを使用していることを確認しました。 よろしくお願いします。 Re: s32k3 eMIOS IMP Mode @VaneBこんにちは、 私も同様の問題に直面しています。周波数を測定するために EMIOS をどのように構成すればよいかなどの構成を共有していただけますか。 Re: s32k3 eMIOS IMP Mode こんにちは@jfranklin 可能であれば、設定を共有していただけますか? Re: s32k3 eMIOS IMP Mode こんにちは。これは当社独自のソフトウェアです。私たちの目標は、提供されている GUI を使用しないことです。基本的には、周波数入力の周期を読み取ろうとしているだけです。IPM モードでは立ち上がりエッジのみ、または立ち下がりエッジのみで更新されるはずですが、立ち上がりと立ち下がりの両方で更新されているようです。 Re: s32k3 eMIOS IMP Mode こんにちは@jfranklin RTD コントローラまたはカスタム ソフトウェアを使用していますか?あなたのアプリケーションについてさらに詳しい情報を教えていただけますか？ BR、ヴェインB

RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hello, Do you have any reference designs, application notes, or example projects demonstrating the use of a camera module outputting YUV422 (8-bit) with the i.MX RT1170 MIPI-CSI interface? I have reviewed the RT1170 errata (https://www.nxp.com/docs/en/errata/IMXRT1170ACE.pdf) and understand that YUV422 10-bit formats are not supported, but I have not been able to find any published examples or confirmation specifically showing YUV422 8-bit operation. Any guidance, known-working configurations, or example camera modules would be greatly appreciated.  Re: RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hi @mtreloar , Thanks for your interest in NXP MIMXRT series! RT1170 MIPI-CSI supports YUV422 (YUYV 8-bit) format. You can refer to this sample project in the SDK: Best regards, Gavin

PN7642 RF 设计导入使用技巧和窍门 先决条件： PN7642 设计导入建议   1// 阻抗调谐 PN76系列天线设计指南 目标阻抗是根据目标应用来选择的。如果需要全功率（如 POS 终端）。建议目标阻抗为15-17 Ω 。 对于使用ULPCD的低功率应用，通常偏好较高阻抗，30-50 Ω（对称调谐）。   2// 动态功率控制 PN7642 - 使用 DPC 进行基本射频功率限制   3// H场检查 存在规定的极限值，尤其是读取器辐射的最大 H 场。超过这些限制可能会导致 NFC 卡或 NFC 标签损坏。 可以借助测试设备测量 H 场，例如： ISO 10373-6测试PICC EMVCo 3.0 测试 PICC 仅供参考，客户可使用如下所示的“智能”场强度探头：     4// 高频衰减器值 请开启 RF 场，并确保 DPC 已在上一步设置并启用 请读取 CLIF_RXCTRL_STATUS 寄存器，并查看 HF_ATT_VAL，如下所示。 满功率下“无载”状态的值应约为 35-45dec。 如果该值超出此范围，客户需调整 Rx 电阻以达到目标值。 5// 接收器设置 使用 NXP 提供的默认设置，检查“功率”范围和通信范围。 功率范围 -> NFC 标签仍能生成响应信号，但 NFC 读卡器无法接收到它的距离。 通信范围 -> NFC 标签仍能与 NFC 读卡器通信的距离 理想情况下，功率范围 ≈ 通信范围 此外，NFC 读卡器不应产生任何错误通信，例如 “HAL COLLISION ERROR”。 接收机的优化可以通过以下方式进行： 进入 DPC 校准 进入 “ARC” 菜单，选择“禁用”ARC 算法。 这将强制IC使用以下寄存器/EEPROM中的RX设置 SIGPRO_RM_TECH_REG DGRM_RSSI_REG   5.1// SIGPRO_RM_TECH_REG（RM_MF_GAIN 参数） 该参数主要用于定义输入放大器的增益。 选择 SIGPRO_RM_TECH_REG 将“操作”切换至 EEPROM，并选择所需的技术。 将 RM_MF_GAIN 增加至 0x021（具体数值视设置而定）。     5.2// DGRM_RSSI_REG（DGRM_SIGNAL_DETECT_TH_OVR_VAL 参数） 该参数定义了内部逻辑开始解码输入信号的阈值。 如果阈值过低或非常接近噪声底，系统可能会将噪声检测为NFC通信。 因此，阈值 + 裕量 > 噪声底限 最佳做法是执行“信号检测阈值”分析。此操作可借助 NFC Cockpit 实现（详见 PN7642 设计导入建议） 因此，用户可以根据插入的"边界值"，获得"噪声"的平均值，并建议的"DGRM_SIGNAL_DETECT_TH_OVR_VAL"门限。 标记 (m) + 噪声平均值 (μ) = 阈值 6+16=23 然后，将该数值按如下方式写入 “DGRM_RSSI_REG” EEPROM。   6// ULPCD 设置 默认值通常是很好的起点。在第一阶段，用户需要注意 RSSI 阈值和 ULPCD VDDPA。 ULPCD VDDPA 的选择应确保高频衰减器值不为0x00！ULPCD 中高频衰减器的典型值约为0x05-0x0B。   6.1// RSSI阈值评估 为了正确选择 RSSI 阈值，建议执行 ULPCD 校准，例如 20 次，并检查设备的 RSSI 信号的“抖动”情况。 如果您发现 RSSI 值出现抖动，例如如上所示抖动5 个单位。这种情况下的绝对最小阈值为6 。一般来说， 2个单位的裕量就足够了。因此，在这种情况下，最佳阈值为7 。

MX95 on DT8MCustomBoard MIPI-DSI out Hi, I have a MX95 on DT8MCustomBoard and custom LVDS connected in dual channel mode to LVDS connectors on board. Display is working nicely and all the other peripherals. Now I want to get an external HDMI display connected and thought I would use MIPI-HDMI converter on DT8MCustomBoards's J11 (MIPI-CSI) connector. Then I would just route video from in to midi_dsi and it would eventually be routed out of J11 connecter on onwards to the MIPI-HDMI bridge. Bridge is adv7535 based thus readily supported by the kernel. However, I'm seeing following in kernel logs: root@imx95-var-dart:~# dmesg|grep mipi [ 0.482259] platform 4ad30000.csi: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@42530000/ov5640_mipi0@3c [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so clearly there is an issue in display_pixel_link <-> mipi_dsi connection. Has anyone here succesfully demonstrated MIPI-DSI on MX95 + DT8MCustomBoard v3.0 combo? I'd like to see device tree samples as the ones provided in kernel tree are not directly meant for DT8MCustomBoard but to some other EVK. How should I map dpu ports to further in chain if they need customization, any fixed clocks to set etc. So are there some pins to pull down, up or anything? As DSI is muxed with CSI then does CSI need explicit disabling or is it enough to enable mipi_dsi in device tree? Thanks for any pointers and cheers from Finland. Re: MX95 on DT8MCustomBoard MIPI-DSI out Based on our analysis of the kernel code there are exactly two output ports on i.MX 95 and if dual channel LVDS is used, in a mode where even and off pixel rows are routed to different channels, then LVDS reserves both of the ports and MIPI-DSI cannot possibly work. However, datasheets state that i.MX 95 can handle up to three independent displays. What does this mean? Based on our tests we can run one single channel LVDS and MIPI-DSI which makes up two displays or we can run one dual channel LVDS only which kind of makes two displays. So what is the configuration where i.MX 95 can have three independent displays? What ports and connectors should be used? Does dual channel LVDS count as two displays already? Re: MX95 on DT8MCustomBoard MIPI-DSI out Ok, it is now evident (based on the kernel source code) that i.MX 95 SoC has two, and only two, independent output ports in its display processing unit. Dual channel LVDS needs both of these leaving MIPI path disconnected. This means that dual channel LVDS + MIPI-HDMI is not possible on i.MX 95. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, an update. I've managed to get MIPI-DSI working so video is routed on MIDI-DSI bus, out from J11 connector on DT8MCustomBoard, over to ADV7535 bridge and in to external HDMI display. However, I'm not able to enable internal LVDS display at the same time with MIPI-DSI. If I enable LVDS display, the ldb node in device tree, it seems to hijack video stream so that it displays on LVDS but not on external display. When this happens I get errors in kernel log stating that imx95-mipi-dsi could not get valid input. I can get either internal LVDS enabled or external HDMI over MIPI-DSI but not both at the same time. This must be something with the device tree but the endpoints I'm using are the ones provided in kernel tree. Device. tree I'm using is imx95 + adv7535 additions with mipi and hdmi nodes. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, Did you try to use only MIPI-DSI out? It can handle up to 3 simultaneous displays: 1x 350 MHz MIPI-DSI (4-lane, 2.5 Gbps/lane) supporting 4kp30 or 3840 x 1440p60. Up to 1080p60 LVDS Tx (2x 4-lane or 1x 8-lane). 16 kByte of SRAM, but it is available for other SoC usage when not using for 2D blitter purposes. Best regards. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, and thanks for the quick reply. It seems that just enabling mipi_dsi in device tree leads to [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so I was wondering is it possible to enable MIPI-DSI functionality and at the same time run LVDS in dual channel mode? mipi_dsi inputs are connected exactly as in device tree samples. What we have here is a custom LVDS panel that needs dual channel (lvds-0 and lvds-1) input and at the same time we want to have external display on MIPI-DSI. So LVDS panel would show desktop 1 and MIPI-DSI, via adv7535 converter, would show desktop 2. Or is it so that MX95 is only capable of one channel LVDS if MIPI-DSI is used at the same time? I've looked all the possible .dts samples in the kernel tree, read documentation and it is not clear to me is dual channel LVDS and MIPI-DSI possible at the same time. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, You can use our EVK as reference: linux-imx/arch/arm64/boot/dts/freescale/imx95-19x19-evk-adv7535.dtso at dfaf2136deb2af2e60b994421281ba42f1c087e0 · nxp-imx/linux-imx Best regards.

S32 Design Studio での S32K344 SDK のインストール 「S32 Design Studio に S32K344 SDK をインストールしましたが、S32DS アプリケーション プロジェクトを作成するときに SDK を選択できません。なぜ？" Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 @DirkEtzler さんは正しいです。 例えばS3K3 RTD 7.0.0 は、NXP GCC 10.2.0 20200723 を使用して開発およびテストされています (SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf の第 2.7 章に記載されているとおり)。したがって、GCC10.2を使用する必要があります。 よろしくお願いいたします、 パベル Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 どのようなツールチェーンを使用していますか?「NXP GCC 10.2 for Arm 32-bit Bare Metal」を選択した場合、SDK が表示されます (下記参照)。ツール チェーンとして「NXP GCC 11.4 for Arm 32 ビット ベア メタル」を選択した場合、SDK は表示されません。

S32K5 RTD configuration does not allow to set initial value in some pins Hello, Some pins as the ones listed below don't allow to set the initial value when being configured. Is there a reason for that? Regards RTD Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi @nxp52415, As I said, with pins that you selected, they are not supported this function. So, the "the initial value" is not necessary for these pins. Default, RTD driver disabled "the initial value" on "pins were not supported RCVR", and these pins will be generated "the initial value" as 0. Even when driver allow user configures RCVR for these pins, then it doesn't have any effection because it has not support RCVR. Best regards, Dan Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi Dan, I was talking about the initial value and not the RCVR. Can you explain why the initial value cannot be set in these pins? Regards  Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi @nxp52415, This is the information about "Receiver Select" bit in S32K5 RM: You can find the pins support the RCVR in the "IO Signal Table" sheet in the S32K56x_IOMUX.xlsx (attached file in S32K5RM). And based on this files, pins that you showed as not support RCVR. Best regards, Dan

S32K 示例 S32K1xx S32K144 示例 S32K144 CMP 轮询 S32DS2.0 示例 S32K144 验证后门访问密钥 S32DS1.3 示例 S32K144 FlexCAN0 RXFIFO DMA nonSDK S32DS13 示例 S32K144 PDB ADC 触发 DMA ISR S32DS 示例 S32K144 Flash RW simple S32DS 示例 S32K144 DMA 内存复制测试 S32DS S32K144 EEEPROM 使用示例 示例 S32K144 EEEPROM 使用 - 无 SDK 示例 S32K144 RTC VLPS 示例 S32K144 WDOG RCM 中断 示例 S32K144 SRAM ECC 注入  S32K144 RAM 保留示例 S32DS.R1 示例 S32K144 I2C主设备 MPL3115A2 S32DSR1_v3 示例S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  示例 S32K144_printf_implementation - S32DS_1.0 示例 S32K144 在 FreeRTOS 下使用 UART printf/scanf - S32DS 示例 使用 LPIT 定时器实现可配置周期函数调用的 S32K144 SDK 示例 S32K144 .noinit章节用法 示例 S32K144 PDB ADC DMA S32DS.ARM.2018.R1 示例 S32K144 RAM 自检简单 S32DS 2018.R1 示例 S32K144 位置无关代码  示例 S32K144 FlexCAN 虚拟网络停止模式测试 S32DS.ARM.2.2 示例 S32K144 LPIT DMA LPSPI 示例 S32K144 FlexCAN TX/RX/Error ISR 测试 S32DS2.2 示例 S32K144 FlexIO 空闲检测 S32DS2.2 S32K146 示例 S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2 S32K148 示例 S32K148 PDB0-PDB1 环 S32DS3.4 RTM4.0.3 示例 S32K148 PDB0-PDB1 环 DMA S32DS3.4 RTM4.0.3 示例 S32K148 GPIO 中断 S32K116 示例 S32K116 WDOG 快速测试 示例 S32K116 LPUART LIN 从机 TXRX ISR S32DS.ARM.2.2 示例 S32K116 FlexCAN PN 停止 S32DS.ARM.2.2 示例 S32K116 FlexCAN VLPR 测试 S32DS.ARM.2.2 S32K118 示例 S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3xx S32K344 示例 S32K344 PIT BTCU ADC DMA DS3.4 RTD100   示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO 测试 S32DS3.4 RTD200   示例 Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4RTD300   示例 S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500    

Build failed while compiling chromium-ozone-wayland Hello, I am trying to compile chromium-ozone-wayland on Yocto for IMX8MP board, but the compilation fails with the error: | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_configure | ERROR at //.gn:150:5: Assignment had no effect. | build_dotfile_settings.exec_script_allowlist + | ^--------------------------------------------- | You set the variable "exec_script_allowlist" here and it was unused before it went | out of scope. | WARNING: exit code 1 from a shell command. ERROR: Task (/home/admin/Dharmik/IMX8M-Plus/sources/meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_138.0.7204.157.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 2814 tasks of which 2800 didn't need to be rerun and 1 failed. I have added CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" in conf/local.conf Below is my yocto configuration, Build Configuration: BB_VERSION = "2.16.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-poky-linux" MACHINE = "imx8mp-lpddr4-evk" DISTRO = "fsl-imx-wayland" DISTRO_VERSION = "6.18-whinlatter" TUNE_FEATURES = "aarch64 armv8a crc crypto"  Thanks, Dharmik Re: Build failed while compiling chromium-ozone-wayland I've seen this error in the past Chromium versions, and what worked for me in that build situation was a change in this file: \tmp\work\armv8a-mx8-poky-linux\chromium-ozone-wayland\117.0.5938.132\chromium-117.0.5938.132\media\gpu\sandbox\BUILD.gn if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux && ozone_platform_x11 && !is_castos) { # For DRI_DRIVER_DIR. configs += [ "//build/config/linux/dri" ] } Adding "&& ozone_platform_x11 " to the platform list at the bottom of this files fixed the issue. Could you check whether Chromium v138 has already ozone_platform_x11 added? Best regards, Diana Re: Build failed while compiling chromium-ozone-wayland After adding PREFERRED_VERSION_gn-native = "0+git" changes I am getting below error, | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_configure | ERROR at //build/config/linux/dri/BUILD.gn:11:20: Script returned non-zero exit code. | dri_driver_dir = exec_script(pkg_config_script, | ^---------- | Current dir: /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/out/Release/ | Command: python3 /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/build/config/linux/pkg-config.py --dridriverdir dri | Returned 1 and printed out: | | Error from pkg-config. | | stderr: | | Package dri was not found in the pkg-config search path. | Perhaps you should add the directory containing `dri.pc' | to the PKG_CONFIG_PATH environment variable | No package 'dri' found | | See //media/gpu/sandbox/BUILD.gn:31:18: which caused the file to be included. | configs += [ "//build/config/linux/dri" ] | ^------------------------- | WARNING: exit code 1 from a shell command. Thanks, Dharmik Re: Build failed while compiling chromium-ozone-wayland Hi Dharmik, Can you try adding to local.conf one more thing besides chromium package?  PREFERRED_VERSION_gn-native = "0+git" Let me know if the issue still persists. Best regards, Diana

S32K144 CSEc 安全启动-设备处于安全状态，无法解除安全保护 硬件 ：S32K144 开发板 IDE ：S32 设计工作室 编程 ：直接通过 S32DS 问题描述： 我通过以下步骤成功在 S32K144 上实现了 cSec 安全启动： 配置密钥 -安装 MASTER_ECU_KEY 和 BOOT_MAC_KEY 闪存区域中的闪存应用程序 - 通过 S32DS 使用 Debug_FLASH 配置 设置安全启动 -通过 S32DS 使用 DEBUG_RAM 配置来存储 BOOT_MAC 重置后 -安全启动工作正常 应用程序工作 - 通过 LED 指示灯确认，BOK=1 问题： 在测试否定情况（失败情景）时： 尝试在闪存区域刷新不同的应用程序 → " 设备是安全的。擦除到不安全？"出现对话框 点击"是" 删除 → 同一对话框不断重复出现 尝试恢复出厂设置 → 还是同样的错误 无法闪存任何新应用程序 问题 点击"Yes" 是否应该自动执行批量删除？ 为什么对话框总是重复出现？ 如何仅使用 S32DS 正确解除设备的安全？正确的程序是什么？ 可以在 S32DS 中使用大量擦除命令吗？ 如果是，具体程序是什么？ 设备永久锁定了吗？或者有通过 S32DS 恢复的方法吗？ 当前状态： 设备似乎处于安全状态。无法使用 S32DS 闪存任何应用程序。需要逐步恢复程序才能解除设备的安全。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 答： 使用 来自 an5401SW 的 s32k144_csec_secure_boot_boot_boot_mac_mac_mac_mac_mac_mac_manual 示例，我们在 BOOT_DEFINE () 函数中将串行安全启动配置为 启动模式。如果启动模式 1 对应 于严格的顺序启动模式 ，这将解释我们遇到的永久 RESET 行为。 " /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE(128*1024*8,1)； " 你检查过RESET信号了吗？它是在开机后版本吗？ 答：是的，我已经检查了 RESET 信号。开机后 RESET 信号保持活动状态（RESET LED 保持亮起），表明设备仍处于 RESET 状态 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 答： 尝试刷新 an5401_s32K144_csec_resetting_flash_to_flash_to_factory_State 时 ，我收到 " 设备是安全的。擦除到不安全？" 对话框。即使在单击 " 是 " 之后，同样的对话框仍会重复出现 S32DS 有 " 通过全芯片擦除进行紧急 Kinetis 设备恢复 " 选项。我们应该用它来恢复设备吗？ 注： 我们没有设置闪存和擦除的调试器。我们使用 S32DS 进行闪存和调试。因此，需要在大规模擦除方面得到帮助。   Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好@Kishore_14 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 你检查过RESET信号了吗？它是在开机后版本吗？ 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 此致， Lukas Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 当 Boot Flavor 参数设置为 0 时，将配置严格的顺序启动模式： 但是，如果你保留原来的顺序启动，那就没有意义了： /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE (128*1024*8, 1); 即使顺序启动失败，也绝对不会导致永久RESET。您是用示波器检查信号，还是只观察 LED 指示灯？RESET信号不是在切换吗？ 如果永久断言重置信号，恐怕就无法恢复。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 直接观察，LED 并非切换，而是常亮。 如果是顺序启动模式，刷新应用程序时设备持续处于 RESET 状态的可能性有多大？ 当示例中的所有 Flashconfig 设置如下所示时，设备将如何获得安全保护： /* 闪存配置 */ .section.FlashConfig,"a" .long0xFFFFFFFF /* 8 字节后门比较密钥 */ .long 0xFFFFFFFF /* */ .long0xFFFFFFFF /* 4 字节程序闪存保护字节 */ .long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = 无担保) */ 由于无法使用直接调试器闪存，我能否尝试使用 Kinetis 选项进行大量擦除？ 注意：我们还在另一块板上也观察到了这种情况，并发布在下面的链接中： 错误：设备是安全的。擦除到不安全-恩智浦社区 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 切换 RESET 引脚可能非常快，以至于肉眼可能看不见。所以我才问你是否用示波器试过。 我只能看到永久RESET的两个原因： 1.严格的顺序启动模式失败。 2。硬件问题-通常电压不足，因此电压监测器不允许启动设备... 无法通过（错误的）应用程序强制设备永久RESET。这只能通过某种自毁方式来实现，例如将GPIO设置为短路或类似的方式。 消息 " 设备是安全的。" 。大多数情况下，这通常意味着调试器无法建立连接。在这种情况下，即使设备处于安全状态，也无法对其进行解除保护，因为启用的 CSec 模块会阻止大规模擦除操作。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好， 切换 RESET 引脚可能太快了以至于肉眼可能看不见。所以我才问你是否用示波器试过。 你检查过RESET信号了吗？它是在开机后版本吗？ 答：我们观察到 RESET 引脚正在切换。 这是否意味着先前闪存的应用程序在任何 SW /WDG RESET 中都卡住了？ 能否通过 SWD 调试器闪烁恢复？     Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 遗憾的是，我们没有用于闪存的 JLink 或 PE Micro。 我们使用 S32DS OpenSDA 进行调试。 下面是 AN12130 中提到的 在启动程序分区命令 (PGMPART) 时，请务必将 CSEc 键的大小分配为不同于零的值。 - 编程 CSEc 键，至少是 MASTER_ECU_KEY。 - 通过发出 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除密钥。CMD_DBG_AUTH 命令将擦除 数据 IFR，从而擦除分区代码并允许再次进行大规模擦除。 如果任何 CSec 密钥受到 “写保护”，则上述步骤将不起作用，因此无法用上市大规模擦除。 问题：当我们闪存不同的应用程序时，第一次尝试就闪存成功了。 由于没有遵循上述顺序，下次 RESET 时，新应用程序可能会进入连续 RESET 状态吗？这样做对吗？ Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您有读取 MDM-AP 的 Segger J-Link 探头或劳特巴赫调试器吗？遗憾的是，Pemicro 无法做到这一点。 在极少数情况下，设备可以被锁定。请查看此主题： https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227 要确认这一点，有必要阅读 MDM-AP。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure OpenSDA 也来自 Pemicro。 通常情况下，即使启用了 CSEc，即使某些键受写保护等，也可以通过 OpenSDA 对新应用程序进行编程。这是因为它是逐块擦除闪存，而不是通过大规模擦除。我的意思是，AN12130 谈到了这样的问题： 因此，当编程过程中出现问题时（意外RESET或类似的情况），这些都是相当大的问题。 遗憾的是，确认这种状态的唯一方法是读取提及的 MDM_AP 寄存器。然后我们可以说出设备是否被永久锁定。但 OpenSDA 无法读取寄存器。 此致， Lukas

How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 NXPサポートチームの皆様、こんにちは。  現在、S32K314、RTD 7.0.0、およびFreeRTOSを使用したプロジェクトに取り組んでいます。MCALのADCモジュールを使用して、MCUに接続された外部デバイスの電圧、MCUの内部温度（TEMPSENSE）、MCUの内部電圧（ANAMUX）、およびバンドギャップ電圧の測定を実装しようとしています。測定結果を見ると、外部デバイスの電圧とバンドギャップ電圧は正しく測定されているようですが、MCUの内部温度と内部電圧の値は予想と異なっています。 期待値： MCU内部電圧（VDD_HV_A）： 8192（2.5V、14ビット分解能） 実測値： 約6800～7100（2.07～2.13V、14ビット分解能） MCUの電源電圧は5.0Vです。ADCハードウェアユニットはADC0に設定され、ADC測定対象は以下のように構成されます。  Ch8：MCU内部温度（TEMPSENSE）  Ch9：MCU内部電圧（ANAMUX）  第10章：バンドギャップ  MCU入力電圧 = 5.0V ADC初期化コード： void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADCデータ取得（すべての周期的なタスク） void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } }  ADC0グループのADC値は`Adc_ReadGroup`を使用して更新できると思いますが、MCUの内部温度については`Adc_TempSenseGetTemp`と`Adc_TempSenseCalculateTemp`を使用する必要があると思います。もし私が見落としている設定があれば教えてください。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 迅速なご対応ありがとうございます。 ご提供いただいたサンプルコードは既に確認済みで、私のコードに組み込んだと考えています。 ご提供いただいた表は、ADCブロックに供給される各クロックに対するレジスタ設定の表であると解釈しました。しかし、それらがMCALのどのADC設定に対応しているのかを特定することはできませんでした。 ソースコードを提供できないため、ADC設定の画像を添付します。どの設定を変更すればよいか教えてください。 他に何か必要な設定画面があれば、お知らせください。 AdcHwUnit> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 提供された情報にはADCの完全な構成が見当たらなかったので、ADCクロックがデータシートの要件に合っているか再確認してください。 可能であれば、テストプロジェクトを共有していただければ、私が確認します。 ちなみに、下記のリンクからデモをご覧ください。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 アドバイスありがとうございます。 ご助言に従い、TEMPSENSEのサンプリング時間を1.2マイクロ秒に設定するように、以下のように設定を変更しました。 160MHz = 0.00625マイクロ秒 1.2マイクロ秒/0.00625マイクロ秒= 192 FreeRTOSで1秒サイクルのタスクを作成し、MCU電圧(VDD_HV_A)とMCU温度(TEMPSENSE)のADC値を毎秒取得しました(30秒分のデータ収集)。 MCU電圧についてはバンドギャップ電圧を使い、以下の補償式でmVに変換しました。 （バンドギャップ電圧はほとんど変動せず、約3975（約1.2V）の値が得られた。） Adc補正 = (1200(mV) * Adc_VCC_HV_A) / Adc_バンドギャップ Mcu電圧 = アドコレーション × 2(2は電圧分割比VDD_HV_A) さらに、 McuTempデータは `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)` から取得されます。 ADC変換誤差が±5.0%であることを考慮しても、このばらつきは大きすぎると思います。何か解決策の提案はありますか？   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 ご提供いただいた設定画面のスクリーンショットとコードを見る限り、明らかなエラーは見当たりません。ただし、温度センサのサンプリング時間は1.2μsを超えなければならないことに注意が必要です。そうでなければ、サンプリングの精度に影響します。したがって、テストを行う前にサンプリング時間を再度確認することをお勧めします。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 ADC_Config>AdcHwUnitの画像が圧縮されて解像度が低下したため、再アップロードします。 <#1> <#2> <#3> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 温度チャネルから生データを直接読み取って、変動があるかどうかを観察できます。変動が大きい場合は、サンプリング時間を延ばし続けるCAN。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ご返信ありがとうございます。 下図に示すように、サンプリング期間1/期間2の値を増加させた後、値は安定しました。デフォルト設定はサンプリング持続時間0だと思っていましたが、サンプリング持続時間0、1、2の切り替えはどうすればいいのでしょうか? （プリスケール設定に基づくと、ADCクロックは80MHzなので、1.2μsに相当する期間は96となる。） Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ドキュメントを添付してくださりありがとうございます。現在チャネル32から63を測定しているので、これはサンプリング持続時間1に対応していると理解しています。 迅速なご対応ありがとうございます。問題は解決しました。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 私は表317の情報を以下のように解釈しました。 fmc = 160 MHz の場合: ・キャリブレーション用のプリスケーラを4に設定する ・通常のADC変換のプリスケーラを2に設定する ・「ADC高速」を無効に設定する これらの設定を適用して得られたデータは、以下の表に示されています。 平均化することでばらつきは減りましたが、MCU内部温度の変動は依然としてかなり大きいと感じます。 以下の表は、ADC値から°Cに変換したMCU温度データを示しています。 （ADC値を摂氏に変換するために、ADC値を16で割りました。） 16点平均で2.55度の変動は極めて大きい。MCUの温度はプロセッシング負荷によって変動することは理解していますが、これほど瞬時に大きく変わるのは普通のことですか? MCUの内部温度を測定する際に、平均を取るのが正しいアプローチでしょうか?

PN7462AU FreeRTOS：无法从 heap_3 切换到 heap_4，系统卡死 + 堆内存使用情况可见性 大家好，我正在使用搭载 FreeRTOS 的 PN7462AU 平台，SDK 示例已配置为使用 heap_3.c。我目前遇到了内存溢出问题，想更深入地了解堆的配置。 由于 heap_3 使用标准库中的 malloc()/free()，因此无法使用 xPortGetFreeHeapSize() 等函数以及堆统计信息。为了了解堆的使用情况，并可能增加可用堆空间，我尝试通过禁用 heap_3.c 来切换到 heap_4.c并启用 heap_4.c。然而，进行此项更改后，应用程序在启动时会卡住。 我有以下几个问题： 在 PN7462AU 上将 heap_3 切换为 heap_4 是否安全且值得推荐？ 如何确定 heap_3 当前可用的内存量？ 由于 heap_3 不支持 xportgetFreeHeapSize ()，因此推荐使用哪些方法来监测堆使用情况和检测内存耗尽？ 从 heap_3 迁移到 heap_4 时，还需要进行哪些额外的配置更改（例如 configTOTAL_HEAP_SIZE、链接器脚本更改、内存区域等）？ 如果能提供关于 PN7462AU 和 FreeRTOS 的具体指导或示例，将不胜感激。 谢谢 核心与内存 Re: PN7462AU FreeRTOS: Unable to switch from heap_3 to heap_4, system stuck + heap usage visibility 你好@uday_gowda ， NFC读取器库提供了示例，展示了如何使用 PN7462 实现 FreeRTOS，这可能会有所帮助。另外，我建议参阅AN11784 ，它提供了有关将 RTOS 与 PN7462 集成的指导，您可以参考该文档。 MCUXpresso IDE 还包含多个用于 FreeRTOS 应用程序的调试功能。特别是，“堆使用情况视图”可以帮到你。更多详情请参阅MCUXpresso IDE 25.06 FreeRTOS 调试指南第 3.6 章。 最后，请注意PN7462只有12k的SRAM。 BR 哈比卜