Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K3xx 数据表表 10:LVR_VDD_HV_A 条件列中的“RPM”是什么意思? 在 S32K3xx 数据手册的表 10“电源监控”中,LVR_VDD_HV_A 行 (断言阈值)出现两次,最小值/典型值/最大值相同(2.77 / 2.85 / 2.93 V): - LVR_VDD_HV_A,断言阈值(在 FPM 中) - LVR_VDD_HV_A,断言阈值(以 RPM 为单位) S32K3xx 参考手册其他部分对“FPM”的定义是“全功率模式”。 (运行模式)。然而,我找不到“RPM”的任何定义。 数据表或参考手册(5394页),包括: 缩写/词汇表部分列出了它。 请问您能否澄清一下: 1.在这个语境中,“RPM”代表什么? 2. FPM 和 LVR_VDD_HV_A 阈值是否相同? 如表格所示,转速是多少? 谢谢! Re: S32K3xx Data Sheet Table 10: What does "RPM" mean in the LVR_VDD_HV_A condition column 您好, 表 10 中的“RPM”代表低功耗模式。它指的是第二个物理冗余的 LVR 监测电路,当设备处于待机(低功耗)模式时,该电路仍保持激活状态。相比之下,FPM(全功率模式/运行模式)监测在正常运行模式工作期间运行。这两个监视器是设备功能安全架构的一部分,用于确保无论当前电源状态如何,VDD_HV_A 电源都能持续受到监控。 关于你的第二个问题,FPM 和 RPM 条目的最小值/典型值/最大值阈值 (2.77 / 2.85 / 2.93 V) 相同,这是正确的。VDD_HV_A 的最低供电要求在运行模式和待机模式下保持不变,因此两个监控器共享相同的触发阈值。 BR,彼得
View full article
S32K3xxデータシート表10:LVR_VDD_HV_A条件列の「RPM」は何を意味しますか? S32K3xxデータシートの表10「電源監視」のLVR_VDD_HV_A行 (アサートしきい値)が、同一の最小値/標準値/最大値(2.77 / 2.85 / 2.93 V)で2回出現します。 - LVR_VDD_HV_A、しきい値のアサート(FPM内) - LVR_VDD_HV_A、アサートしきい値(RPM内) 「FPM」はS32K3xxリファレンスマニュアルの他の箇所で「フルパワーモード」として定義されています (ランモード)」しかし、どこにも「RPM」の定義は見つかりませんでした データシートまたはリファレンス・マニュアル(5394ページ)のいずれかで、含まれていません。 略語/用語集のセクションでリストアップしています。 もう少し詳しく教えていただけますか: 1.この文脈における「RPM」とは何のことですか? 2. LVR_VDD_HV_A しきい値は FPM と 表が示唆するように、RPMですか? よろしくお願いします。 Re: S32K3xx Data Sheet Table 10: What does "RPM" mean in the LVR_VDD_HV_A condition column こんにちは、 表10の「RPM」は、低出力モードを表します。これは、デバイスがスタンバイ(低電力)モードのときにアクティブ状態を維持する、物理的に冗長な2つ目のLVRモニター回路を指します。一方、FPM(フルパワーモード/ランモード)モニターは、通常のランモード動作中に動作します。両方のモニターは、現在の電源状態に関わらずVDD_HV_A電源が継続的に監視されることを保証するため、デバイスのセーフティアーキテクチャの一部として存在します。 2つ目のご質問についてですが、FPMとRPMの両方のエントリで最小値/標準値/最大値のしきい値(2.77 / 2.85 / 2.93 V)が同一であることは正しいです。VDD_HV_Aの最低供給要件は実行モードとスタンバイモードで変わらず、両方のモニターは同じトリップ閾値を共有します。 BR、ペトル
View full article
i.MX9 ELE 的已知问题 根据 2025 年的讨论,i.MX 9 存在一个问题,即安全世界和非安全世界同时使用其 MU 与 ELE 通信。讨论中提到,计划在 2025 年第三季度修复该问题。这个修复程序发布了吗?该修复是在 ELE 固件中实现的,还是需要修改 Cortex A55 代码?如果该修复程序已在 ELE 固件中实现,那么哪个固件版本是第一个包含该修复程序的? 根据i.MX Linux 发行说明 (RN00210),电压变化会导致已知的 ELE 问题。这个问题会造成什么影响?即使发送了 ELE_VOLT_CHANGE_START_REQ 请求,电压故障检测器也会触发吗?电压变化会对随机数生成器产生影响吗?RN00210 仅针对 i.MX 93 提到了该问题。与 i.MX 91 非常相似的机型是否也受到影响? 背景:我们需要从 OP-TEE 内部可靠地访问 ELE,但我们不能指望 Linux 能够正常运行。 安全
View full article
Known issues with i.MX9 ELE According to this discussion from 2025 there was an issue on i.MX 9 when both the secure and non-secure world were using their MUs at the same time to communicate with the ELE. In the discussion it was said that a fix was planned for Q3 2025. Has this fix been released? Is the fix implemented in the ELE firmware or did it need modifications to the Cortex A55 code? If it was implemented in the ELE firmware, which firmware version was the first one to contain the fix? According to the i.MX Linux Release Notes (RN00210) there is a known ELE problem with voltage changes. What is the impact of this problem? Will the voltage glitch detector trigger even if ELE_VOLT_CHANGE_START_REQ was sent? Or will the voltage change impact the random number generator? RN00210 mentions the problem only for i.MX 93. Is the very similar i.MX 91 affected as well? Background: We need reliable access to the ELE from within OP-TEE and can't trust Linux to behave nicely. Security
View full article
i.MX9 ELEの既知の問題 2025年のこの議論によると、i.MX 9では、セキュアワールドと非セキュアワールドの両方が同時にMUを使用してELEと通信していた際に問題が発生したとのことです。議論の中で、2025年Q3に修正が計画されていると言われました。この修正プログラムは既にリリースされていますか?修正はELEファームウェアに実装されているのか、それともCortex A55コードの修正が必要だったのでしょうか?ELEファームウェアに実装された場合、その修正が最初に含まれたファームウェアバージョンはどれですか? i.MX Linuxリリースノート(RN00210)によると、電圧変化に関する既知のELE問題があります。この問題の影響は何ですか?ELE_VOLT_CHANGE_START_REQが送信された場合でも、電圧グリッチ検出器は作動しますか?あるいは、電圧の変化は乱数発生器に影響を与えるだろうか?RN00210では、i.MX 93のみに問題が記載されています。非常によく似たi.MX 91も影響を受けているのでしょうか? 背景:OP-TEE内部からELEへの信頼性の高いアクセスが必要で、Linuxがうまく振る舞うとは信頼できません。 Security
View full article
S32K3xx Data Sheet Table 10: What does "RPM" mean in the LVR_VDD_HV_A condition column? In the S32K3xx Data Sheet, Table 10 "Supply Monitoring", the LVR_VDD_HV_A row (assert threshold) appears twice with identical Min/Typ/Max values (2.77 / 2.85 / 2.93 V): - LVR_VDD_HV_A, assert threshold (in FPM) - LVR_VDD_HV_A, assert threshold (in RPM) "FPM" is defined elsewhere in the S32K3xx Reference Manual as "Full-power mode (Run mode)". However, I could not find any definition of "RPM" anywhere in either the Data Sheet or the Reference Manual (5394 pages), including no abbreviation/glossary section that lists it. Could you please clarify: 1. What does "RPM" stand for in this context? 2. Is it correct that the LVR_VDD_HV_A threshold is identical between FPM and RPM, as the table implies? Thank you. Re: S32K3xx Data Sheet Table 10: What does "RPM" mean in the LVR_VDD_HV_A condition column Hi, "RPM" in Table 10 stands for Reduced Power Mode. It refers to a second, physically redundant LVR monitor circuit that remains active when the device is in Standby (low-power) mode. In contrast, the FPM (Full Power Mode / Run mode) monitor operates during normal Run mode operation. Both monitors exist as part of the device's safety architecture to ensure the VDD_HV_A supply is continuously supervised regardless of the current power state. Regarding your second question, the identical Min/Typ/Max threshold values (2.77 / 2.85 / 2.93 V) for both the FPM and RPM entries are correct. The minimum supply requirement for VDD_HV_A does not change between Run and Standby modes, so both monitors share the same trip threshold.  BR, Petr
View full article
Video: How to Spin a Motor Starting from an Example (function() { var wrapper = document.getElementById('lia-vid-6405736766112w960h540r439'); 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) Getting Started
View full article
How To Import ELE Key To RT1180 Based On AN14861SW Table of Contents  Document Objective and Overall Flow  Software and Hardware Environment Preparation  Program SRKH on the RT1180 Board  Import the AN14861SW Project  Obtain the NXP Manufacturing Public Key from ELE  Generate Signed Content and the TLV Blob  Replace the C Arrays in the Demo Project  Build, Run, and Analyze the Success Log  1. Document Objective and Overall Flow  This document describes how to complete the OEM Key Import flow using the EdgeLock Enclave (ELE) on the i.MX RT1180. The flow is mainly used to securely import OEM-generated or OEM-owned key material into the device key store through the secure import mechanism supported by ELE, and then verify the imported key by performing AES encryption and decryption.  The overall flow can be summarized as follows:  Install the tool environment        ↓  Program and verify SRKH        ↓  Import the AN14861SW demo project        ↓  Export the NXP Manufacturing Public Key from ELE        ↓  Generate a local ECC key pair for ECDH key agreement        ↓  Generate the KEY_EXCHANGE_REQ Signed Message        ↓  Generate the OEM Import Key TLV Blob        ↓  Replace the generated C arrays in the demo project        ↓  Run the demo and perform Key Agreement and OEM Key Import  Note: The commands in this document primarily use Windows/PowerShell and the SPSDK CLI. When running them on Linux, adjust path separators and shell syntax as required.  2. Software and Hardware Environment Preparation  2.1 Hardware Platform  The following hardware is recommended:  i.MX RT1180 EVK or a custom RT1180 board  USB debug cable or an onboard debug interface  Serial terminal software, such as Tera Term, PuTTY, MobaXterm, or VS Code Serial Monitor  A boot configuration environment that has passed basic startup verification  2.2 Install SPT 26.06  It is recommended to install the latest SPT release. The version used in this document is:  SPT 26.06  SPT stands for Secure Provisioning Tool. It is used to generate SRK/SRKH data, configure signed images, program fuses, and configure secure boot.  After installation, confirm the following:  SPT starts normally.  The target RT1180 board can be detected.  Fuse read operations work correctly on the target board.  The selected connection interface matches the board boot mode.  2.3 Install the Latest SPSDK  It is recommended to install SPSDK in a Python virtual environment to avoid conflicts with Python packages already installed on the system.  python -m venv .venv  .\.venv\Scripts\activate  pip install -U pip  pip install -U spsdk  Verify the installation:  spsdk --version  nxpcrypto --help  nxpimage --help  If a command is not recognized, check the following:  The virtual environment is active in the current PowerShell session.  The Python Scripts directory is included in PATH.  SPSDK is installed in the Python environment currently in use.  3. Program SRKH on the RT1180 Board  This step establishes the OEM Root of Trust. Before programming, make sure that the SRK table and SRKH are the final versions intended for use, because fuse programming or locking is normally irreversible.  3.1 Generate and Program SRKH Using SPT  The relevant configuration screenshots are shown below:  Figure 1 - SPT SRKH configuration  Figure 2 - SRKH programming confirmation  Figure 3 - SRKH fuse operation  Recommended checkpoints:  Confirm that the SRK table was generated from the correct OEM signing key.  Confirm that SRKH matches the SRK table used by the current project.  Save the configuration record before programming the fuses.  Perform readback verification after programming the fuses.  If Secure Boot will be enabled later, confirm that the SRKH locking policy meets the project manufacturing requirements.  Risk notice: SRKH is a core element of the secure boot chain of trust. Programming or locking must be confirmed by the project security owner in advance.    4. Import the AN14861SW Project  Use MCUXpresso IDE to import the AN14861SW project.  Recommended steps:  Open MCUXpresso IDE.  Select File → Import.  Select Existing Projects into Workspace.  Browse to the AN14861SW project directory.  Confirm that the project builds successfully.  Verify the Debug Probe, serial port, and boot configuration for the target board.  It is recommended to keep the original project unchanged at first and complete one baseline build and run. This confirms that the demo environment itself is functional.  5. Obtain the NXP Manufacturing Public Key from ELE  5.1 Enable the NXP Production Key Export Path in the Demo  AN14861 requires reading the NXP Manufacturing Public Key from ELE. This key is subsequently used as the peer public key for ECDH key agreement and is required to generate the Signed Message and TLV Blob materials.  The relevant flow screenshots are shown below:  Figure 4 - Enable key export in the project  Figure 5 - Exported NXP Manufacturing Public Key  After running the demo, a HEX string similar to the following is obtained:  744a536d9078795b037db78f8738dbab5ae7dbab76660eb7067a06f386791687  f6988017e90c73a889f5b6dd9abb3b5c1bb9c1cffdca34c6ba64600244e8a314  The string must be converted to a binary file and then converted to a PEM-format public key.  5.2 Convert the HEX String to a Binary File Using PowerShell  Create the following script:  create_key.ps1  Script content:  $hex = "744a536d9078795b037db78f8738dbab5ae7dbab76660eb7067a06f386791687f6988017e90c73a889f5b6dd9abb3b5c1bb9c1cffdca34c6ba64600244e8a314"    [byte[]]$bytes = for ($i = 0; $i -lt $hex.Length; $i += 2) {      [Convert]::ToByte($hex.Substring($i, 2), 16)  }    [System.IO.File]::WriteAllBytes("key.bin", $bytes)  Write-Host "Created key.bin successfully."  Write-Host "File size:" (Get-Item ".\key.bin").Length "bytes"  Run the script:  .\create_key.ps1  Expected output:  Created key.bin successfully.  File size: 80 bytes  The test result is shown below:  Figure 6 - PowerShell generated key.bin  If script execution is restricted by the PowerShell execution policy, temporarily allow execution in the current session:  Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass  5.3 Convert key.bin to a PEM-Format Public Key  Run:  nxpcrypto key convert -e PEM -i key.bin -o nxp_prod.pub  Generated file:  nxp_prod.pub  Use the following command to inspect the PEM content:  openssl pkey -pubin -in nxp_prod.pub -text -noout  6. Generate Signed Content and the TLV Blob  This chapter corresponds to Section 7.4 of AN14861 and covers the following tasks:  Generate a local ECC key pair.  Export the ECC public key as raw binary.  Calculate the SHA-256 digest of the ECC public key.  Obtain and edit the Signed Message configuration template.  Generate signed_message.bin.  Generate the OEM Import Key TLV Blob.  Convert the binary files into C arrays for use in the demo.  6.1 Generate a Local ECC Key Pair  This key pair is used to perform ECDH key agreement with the NXP Manufacturing Public Key inside ELE.  nxpcrypto key generate -k secp256r1 --force -o app_ecc256.pem  Expected generated files:  app_ecc256.pem  app_ecc256.pub  Notes:  secp256r1 selects the NIST P-256 curve.  The private key, app_ecc256.pem, must be stored securely.  The public key, app_ecc256.pub, will be converted to RAW format and embedded in the demo project.  6.2 Convert the ECC Public Key to RAW Binary  nxpcrypto key convert -e RAW -i app_ecc256.pub -o ecc256_pub_key.bin  Then convert it to a C array:  nxpimage utils convert bin2carr -i ecc256_pub_key.bin -e little -c 8 -n ecc256_pub_key -o app_ecc256_pub.c  Parameter description:  -i ecc256_pub_key.bin: input RAW binary public key.  -e little: output in little-endian format.  -c 8: output eight bytes per line.  -n ecc256_pub_key: generated C array name.  -o app_ecc256_pub.c: output C source file.  6.3 Calculate the SHA-256 Digest of the ECC Public Key  nxpcrypto digest -h sha256 -i ecc256_pub_key.bin  Example output:  SHA256(ecc256_pub_key.bin)= b3a20b5679c5ddd77d6bd1a3eb0ff6ea7ab32ac6883d597db30dfcb64d5f8164  This digest must later be entered in the Signed Message configuration file to identify the local ECC public key participating in the key exchange.  6.4 Obtain the KEY_EXCHANGE_REQ Signed Message Template  nxpimage signed-msg get-template -f rt118x -m KEY_EXCHANGE_REQ -o signed_msg_config.yaml --force  6.5 Edit signed_msg_config.yaml  Edit the template file:  signed_msg_config.yaml  Verify the following items carefully:  The family is rt118x.  The message type is KEY_EXCHANGE_REQ.  The correct NXP Manufacturing Public Key is used.  The ECC public key digest is correct.  The output file path is consistent with subsequent commands.  The working directory is located where SPT/SPSDK expects it.  A reference sample is provided in the attachment.  6.6 Generate the Signed Message Binary  After entering the SPT workspace, run:  nxpimage signed-msg export -c signed_msg_config.yaml -w ecdh_derived_key  The result is shown below:  Figure 7 - Export signed message  Expected generated file:  signed_message.bin  ECDH-derived-key intermediate files are also generated in the working directory.  6.7 Convert signed_message.bin to a C Array  nxpimage utils convert bin2carr -i signed_message.bin -e little -c 8 -n signed_msg_bin -o signed_message.c  The test result is shown below:  Figure 8 - Convert signed message to a C array  Generated file:  signed_message.c  It contains:  const uint8_t signed_msg_bin[] = {      ...  };  6.8 Obtain the Key Import TLV Blob Template  nxpimage signed-msg tlv get-template -f rt118x -o oem_import_key.yaml --force  The result is shown below:  Figure 9 - Get TLV template  6.9 Edit oem_import_key.yaml  Configure the following items according to the target key to be imported:  Key type  Key length  Key usage  Key policy  Blob ID  Storage location  Key group  TLV output file name  Keep the configuration consistent with the parsing logic in the demo project. Otherwise, TLV generation may succeed while the ELE Import step fails. A reference sample is provided in the attachment.  6.10 Generate the TLV Blob  nxpimage signed-msg tlv export -c oem_import_key.yaml  The result is shown below:  Figure 10 - Export TLV blob  Expected generated file:  tlv.bin  6.11 Convert tlv.bin to a C Array  nxpimage utils convert bin2carr -i tlv.bin -e little -c 8 -n oem_tlv_blob -o oem_tlv_blob.c  The result is shown below:  Figure 11 - Convert TLV blob to a C array  Generated file:  oem_tlv_blob.c  It contains:  const uint8_t oem_tlv_blob[] = {      ...  };  7. Replace the C Arrays in the Demo Project  Replace the generated C arrays in the ele_crypto_hsm.c file of the demo project.  The arrays to replace are:  ecc256_pub_key[]  signed_msg_bin[]  oem_tlv_blob[]  The relevant screenshots are shown below:  Figure 12 - Replace the ecc256_pub_key array  Figure 13 - Replace the signed_msg_bin array  Figure 14 - Replace the oem_tlv_blob array  Recommended procedure:  Back up the original ele_crypto_hsm.c file.  Use the contents of the generated .c files to replace the corresponding arrays. Do not change the array names.  8. Build, Run, and Analyze the Success Log  8.1 Disable the NXP Product Key Export Code Path  After replacing the arrays, disable the code path used to export the product key, and then rebuild the demo.  The relevant screenshot is shown below:  Figure 15 - Disable the product key export path  8.2 Rebuild the Project  In MCUXpresso IDE, run:  Clean Project  Build Project  Debug / Run  8.3 Key Success Log Messages  The successful demo log is lengthy. Focus on the following key messages:  EdgeLock FW loaded and authenticated successfully.  EdgeLock RNG Start success.  EdgeLock services initialized successfully.  Open session successfully.  Open service and create Key Store successfully.  ele perform key agreement successfully. Derived key ID: 0x3fffffff  Import key successfully. User key ID: 0x3ffffffe  OEM_IMPORT_MK_SK deleted successfully.  AES-ECB decrypted data match the original plain text - success.  End of Example with SUCCESS!!  These messages indicate the following:  ELE firmware was loaded and authenticated successfully.  The RNG service started successfully.  ELE services were initialized successfully.  The session, Key Store, NVM, and Key Management services opened successfully.  ECDH key agreement succeeded.  OEM key import succeeded.  The temporary key pair was deleted successfully.  AES-ECB encryption and decryption verified that the imported key is usable.  8.4 Detailed Runtime Log  Original successful log summary:  EdgeLock Enclave Sub-System oem provsioning example:  ****************** Load EdgeLock FW ***********************  EdgeLock FW loaded and authenticated successfully.  ****************** Start RNG ******************************  EdgeLock RNG Start success.  EdgeLock RNG ready to use.  ****************** Initialize EdgeLock services ***********  EdgeLock services initialized successfully.  ****************** Load EdgeLock NVM Mgr ******************  EdgeLock NVM manager registered.  ****************** Open EdgeLock session ******************  Open session successfully. Session ID: 0xbe962305  ****************** Create Key Store ***********************  Open service and create Key Store successfully. Key Store ID: 0xbe962e85  ****************** Open NVM Storage service ***************  Open NVM Storage service successfully. Handle ID: 0xbe96294d  ****************** Key Management Open ********************  Open Key management service successfully. Key Handle ID: 0xbe96293d  ele perform key agreement successfully. Derived key ID: 0x3fffffff  Write sd, blob_id_msb = 4, 45, 12345678  Write sd, blob_id_msb = 3, 0, 12345678  Write sd, blob_id_msb = 0, 0, 0  Import key successfully. User key ID: 0x3ffffffe  OEM_IMPORT_MK_SK deleted successfully. Key Pair ID: 0x3fffffff  ****************** Close Key Management Service ***********  Close Key Management Service successfully.  ****************** Close Key Store ************************  Close Key Store successfully.  Close NVM storage session successfully.  ****************** Close EdgeLock session *****************  Close session successfully.  ...  ****************** Cipher AES ECB *************************  Output returned by AES-ECB encryption.  ****************** Decrypt Cipher AES-ECB *****************  Read sd, blob_id msb = 0x4, lsb: 0x45, ext: 0x12345678  AES-ECB decrypted data match the original plain text - success.  ...  End of Example with SUCCESS!!  OEM Key Import, Signed Message, and TLV Blob Generation Flow  Based on the i.MX RT1180 EdgeLock Enclave 
View full article
SPI NAND boot on i.MX8ULP
View full article
Proposed alternative for LPC4088 Hi, We have been using LPC4088FBD208 in our designs and the product is already deployed in the field. The NXP official page shows the longevity date of December 2028.Can you recommend any suitable MCU that is pin compatible and requires minimal software change.   Re: Proposed alternative for LPC4088 Hello, If you are looking for a further longevity than 2028; The MCX family is the supported recommendation as its new and have support from at least 2039 and on, Also there is an LPC option using the same package. Here is a list for  potential upgrades from LPC4088FBD208 to MCX family and a LPC option. MCX E24: -Arm Cortex M4F @112 MHz -Flash 1MB up to 2MB -SRAM Up to 256KB -EEPROM emulated by FlexRAM 4KB -Package LQFP (64/100/144) Options MCX N947 Cortex‑M33 @150 MHz -Up to 2MB Flash -Up to 512 KB RAM -Ethernet (10/100 MAC) -USB FS & HS -CAN FD x2 -Package ( VFBGA184 / HLQFP100 / HDQFP172) LPC540XX Family of Microcontrollers (MCUs) The [LPC5401xJ] have Cortex M4 at 180 MHz and LQFP208 package, same as LPC4088. Remains in Longevity Program from at least 2029 and On. -Arm Cortex-M4 processor, running at a frequency of up to 180 MHz. -Up to 360 KB total SRAM -On-chip memory Up to 4 MB of on-chip Quad SPI Serial Flash -USB FS & HS -Ethernet AVB -CAN and CAN FD -LCD All could involve a minimum software migration to use MCUXpresso IDE or Visual Studio Code-MCUXpresso Extension. Best Regards, Luis Re: Proposed alternative for LPC4088 For a direct drop-in replacement with minimal software changes, the best option is the LPC4078FBD208 from NXP's same LPC407x/408x product family. It shares the exact same 208-pin LQFP footprint and ARM Cortex-M4 core, allowing you to reuse your existing board layout and codebase with little to no modification, provided your design does not heavily rely on features unique to the LPC4088 (such as the SPIFI flash interface). Alternatively, the LPC1788FBD208 matches the 208-pin package but uses an older Cortex-M3 core, meaning the LPC4078 is your closest and easiest drop-in upgrade path.
View full article
No source available for "(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[1]).threa After debugging the program, the message "No source available for '(gdb[23].proc[42000].threadGroup[i1], gdb[23].proc[42000].OSthread[1]).thread[1].frame[0]' " popped up.The "RESUME" button is gray. The software I am using is S32 Design Studio for ARM Version 2018.R1. Could you please tell me how to solve this problem? Thank you. S32K144EVB Re: No source available for "(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[ Hi, The message typically indicates that the debugger stopped in a fault handler or at an invalid address where no source code is available. Please try a clean rebuild, power-cycle the board, and restart the debug session. Also verify that the correct *.elf file is selected in the GDB PEMicro debug configuration. Additionally, please test whether the issue can be reproduced with a standard NXP S32K144 example project. This will help determine if the problem is application-specific. Please also check which update level of S32 Design Studio for ARM 2018.R1 you currently have installed. If you are not using Update 11 (or newer), we recommend applying the update, as it contains fixes and SDK updates for S32K1xx devices. BR, Petr
View full article
How to escalate a problem with AT&T? Facing an AT&T problem that keeps going unresolved? AT&T Escalation Support Team Re: How to escalate a problem with AT&T? Hi Suhani, Thank you for reaching out, but it looks like this post may have been submitted to the wrong community. This forum is dedicated to NXP's MPC5xxx microcontrollers and related technical topics. For AT&T support or escalation, I'd recommend contacting them directly: AT&T Business Support: https://www.att.com/support/ AT&T Escalation line: available through your account portal or by calling AT&T customer care I'll be closing this case on our end. Hope you get your issue resolved soon! Best regards, Peter
View full article
S32K5支持的各项外设参数 我想知道S32K5支持哪些外设,以及分别有几路? Re: S32K5支持的各项外设参数 你好@TAlice , 目前所有可用的信息都已在 K5 的产品页面上提供: S32K5 汽车通用 MCU | NXP 半导体 。 S32K5正式发布后,具体的周边设备信息将会公布。如需了解更多详情,请联系您的 NXP 代理商或指定销售人员。 此致, 朱利安
View full article
S32K5は様々な周辺パラメータをサポートしています S32K5がサポートする周辺機器の種類と、各周辺機器が持つポート数を知りたいです。 Re: S32K5支持的各项外设参数 こんにちは、 @TAlice さん、 現在利用可能なすべての情報はK5の製品ページに記載されています:S32K5 車載汎用MCU | NXP Semiconductors。 S32K5が一般公開されると、特定のペリフェラル情報が利用可能になります。詳細が必要な場合は、NXPの代理店または担当営業までお問い合わせください。 よろしくお願いします、 ジュリアン
View full article
AT&Tで問題をエスカレートさせるにはどうすればよいですか? 解決されていないAT&Tの問題に直面していますか?AT&Tエスカレーションサポートチーム Re: How to escalate a problem with AT&T? こんにちは、スハニさん。 ご連絡ありがとうございます。しかし、この投稿は間違ったコミュニティに投稿されたようです。このフォーラムは、NXPのMPC5xxxマイクロコントローラおよび関連する技術的トピックに特化しています。 AT&Tのサポートやエスカレーションについては、直接連絡することをお勧めします: AT&Tビジネスサポート: https://www.att.com/support/ AT&Tエスカレーションライン:アカウントポータルまたはAT&Tカスタマーケアにお電話いただくことで利用可能です この事件はこちらで解決します。問題が早く解決することを願っています! よろしくお願いします、 ピーター
View full article
LPC4088 的替代方案 您好, 我们在设计中一直使用 LPC4088FBD208,该产品已在现场部署。NXP 官方页面显示该产品的生命周期截止日期为 2028 年 12 月。请问您能否推荐一款引脚兼容且只需进行少量软件更改的合适 MCU? Re: Proposed alternative for LPC4088 你好, 如果您希望产品寿命超过 2028 年,MCX 系列是值得推荐的选择,因为它是新产品,并且至少从 2039 年起都得到支持。此外,还有一个使用相同软件包的 LPC 选项。 以下是 LPC4088FBD208 到 MCX 系列的潜在升级选项以及 LPC 选项列表。 MCX E24: -Arm Cortex M4F @112 MHz -闪存容量 1MB 至 2MB -SRAM 最大可达 256KB -由 FlexRAM 4KB 模拟的 EEPROM -封装 LQFP (64/100/144) 选项 MCX N947 Cortex-M33 @150MHz -最高可达 2MB 闪存 -最高可达 512 KB 内存 -以太网(10/100 MAC) -USB FS && HS -CAN FD x2 -封装(VFBGA184 / HLQFP100 / HDQFP172) LPC540XX系列微控制器(MCU) [LPC5401xJ] 采用 180 MHz 的 Cortex M4 处理器和 LQFP208 封装,与 LPC4088 相同。 从2029年起至少继续参与长寿计划。 -Arm Cortex-M4 处理器,运行频率高达 180 MHz。 - 最大支持 360 KB 总 SRAM 片上存储器:高达 4 MB 的片上四通道SPI 串行闪存 -USB FS && HS -以太网AVB -CAN 和 CAN FD 液晶显示器 所有这些都可能涉及最少的软件迁移,以使用 MCUXpresso IDE 或 Visual Studio Code-MCUXpresso 扩展。 此致敬礼,路易斯 Re: Proposed alternative for LPC4088 对于需要直接替换且软件更改最少的产品,最佳选择是 NXP 同一 LPC407x/408x 产品系列中的 LPC4078FBD208。它采用完全相同的 208 引脚 LQFP 封装和 ARM Cortex-M4 内核,因此您可以重复使用现有的电路板布局和代码库,几乎无需修改,前提是您的设计不严重依赖 LPC4088 特有的功能(例如 SPIFI 闪存接口)。或者,LPC1788FBD208 也采用 208 引脚封装,但使用的是较旧的 Cortex-M3 内核,这意味着 LPC4078 是您最接近且最简单的直接升级途径。
View full article
没有可用的源 "(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[1]).threa 调试程序后,出现消息“没有可用的源文件 '(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[1]).thread[1].frame[0]'“继续”按钮呈灰色,并弹出窗口。我使用的软件是 S32 Design Studio for ARM 版本 2018.R1。请问如何解决这个问题?谢谢。S32K144EVB Re: No source available for "(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[ 您好, 该消息通常表示调试器在故障处理程序中停止,或者在无效地址处停止,而该地址没有可用的源代码。请尝试重新编译,重启电路板,然后重新启动调试会话。同时确认在 GDB PEMicro 调试配置中选择了正确的 *.elf 文件。 此外,请测试是否可以使用标准的 NXP S32K144 示例项目重现该问题。这将有助于确定问题是否特定应用。 请同时检查您当前安装的 S32 Design Studio for ARM 2018.R1 的更新级别。如果您未使用更新 11(或更高版本),我们建议您应用此更新,因为它包含针对 S32K1xx 设备的修复程序和 SDK 更新。 BR,彼得
View full article
LX2080A Linux Development Support – Yocto and Buildroot Hello, I am working with the NXP LX2080A platform and want to develop an embedded Linux system. I would like to know what Linux development support NXP provides for LX2080A. Is Yocto officially supported? If yes, where can I find the NXP Yocto BSP/layers? Is Buildroot officially supported for LX2080A? Is there any NXP BSP/SDK recommended for Linux development? Please share the relevant documentation, source repositories, or guides. Thank you. Re: LX2080A Linux Development Support – Yocto and Buildroot Please refer to https://www.nxp.com/webapp/Download?colCode=LX2160ARDBGSG, page 11. By changing SW3[1:3] from 111 to 110, the board will boot as an LX2080A platform. Any RCW, ATF, or other software modifications required will depend on your specific hardware design and may differ from the reference LX2160ARDB implementation. Thanks. Re: LX2080A Linux Development Support – Yocto and Buildroot Hello, Thank you for the information. I would like to clarify one point regarding the LX2080A. If we use the LX2160A-RDB software and reference configuration for Linux enablement on the LX2080A, are any changes required in the RCW (Reset Configuration Word) or ATF (TF-A) configuration to support the LX2080A? Specifically, can the RCW and ATF configuration used for the LX2160A-RDB be used for the LX2080A, or do they need to be modified for the LX2080A? Thanks. Re: LX2080A Linux Development Support – Yocto and Buildroot The LX2080A belongs to the LX2 family, and Linux software support is common across the LX2 family. The LX2160A-RDB is typically used as the reference hardware platform for software enablement. For Linux development, Layerscape Yocto BSP (LDP Yocto) is supported. The source code and layers are available from: https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar Please refer to: UG10374 and UG10381. NXP's official Linux enablement is based on the Layerscape LDP / Yocto releases. We do not provide a dedicated Buildroot BSP release for LX2080A. The Layerscape LDP page provides the latest software releases, documentation, and supported device information below: https://www.nxp.com/design/design-center/software/embedded-software/cross-platform-embedded/layerscape-linux-distribution-poc:LAYERSCAPE-SDK Thanks
View full article
LPC4088の代替案 こんにちは、 私たちは設計に LPC4088FBD208 を使用しており、製品はすでに現場で展開されています。NXPの公式ページには2028年12月の耐用年が表示されています。ピン互換でソフトウェア変更が最小限で済む適切なMCUをおすすめできますか? Re: Proposed alternative for LPC4088 こんにちは、 2028年以降の耐久性を求めるなら、MCXファミリは新しく推奨されており、少なくとも2039年以降からサポートされています。また、同じパッケージを使ったLPCオプションもあります。 こちらはLPC4088FBD208からMCXファミリへのアップグレード候補リストとLPCオプションです。 MCX E24: - アーム・コルテックス M4F @112 MHz -フラッシュメモリ1MBから最大2MB -SRAM 最大256KB - FlexRAM 4KBでエミュレートされたEEPROM - パッケージLQFP(64/100/144)オプション MCX N947 Cortex-M33 @150MHz 最大2MBのフラッシュメモリ -最大512KBのRAM -イーサネット(10/100 MAC) -USB FS & HS -CAN FD x2 -パッケージ(VFBGA184 / HLQFP100 / HDQFP172) LPC540XX マイクロコントローラファミリ(MCU) [LPC5401xJ]はCortex M4を180MHzで搭載し、LPC4088と同じLQFP208パッケージです。 少なくとも2029年以降は長寿プログラムに留まる。 - Arm Cortex-M4プロセッサで、最大180 MHzの周波数で動作します。 -最大360KBのSRAM -オンチップメモリ 最大4MBのオンチップQuad SPIシリアルフラッシュ -USB FS & HS -イーサネットAVB -CAN and CAN FD -LCD いずれも、MCUXpresso IDEまたはVisual Studio Code-MCUXpresso拡張機能を使用するための最低限のソフトウェア移行が必要でした。 敬具、ルイス Re: Proposed alternative for LPC4088 最小限のソフトウェア変更で直接交換できるなら、NXPと同じLPC407x/408x製品ファミリーのLPC4078FBD208が最良の選択肢です。同じ208ピンのLQFPフットプリントとArm Cortex-M4コアを共有しており、**デザイン**がLPC4088固有の機能(例えばSPIFIフラッシュインターフェース)に大きく依存しない限り、ほとんど変更なしで既存のボードレイアウトやコードベースを再利用できます。あるいは、LPC1788FBD208は208ピンパッケージと同じですが、古いCortex-M3コアを使用しているため、LPC4078が最も近くて簡単にアップグレードできるルートです。
View full article
"(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[1]).thread のソースがありません プログラムのデバッグ後、「'(gdb[23].proc[42000].threadGroup[i1]、'のソースが利用できません」というメッセージが表示されました。gdb[23].proc[42000]。OSthread[1]).thread[1].frame[0]'「」がポップアップしました。「再開」ボタンは灰色です。私が使っているソフトウェアは、ARMバージョン2018.R1用のS32 Design Studioです。この問題をどう解決すればいいのか教えていただけますか?ありがとう。S32K144EVB Re: No source available for "(gdb[23].proc[42000].threadGroup[i1],gdb[23].proc[42000].OSthread[ こんにちは、 このメッセージは通常、デバッガーが障害ハンドラー内で停止したか、ソースコードが利用できない無効なアドレスで停止したことを示しています。クリーンビルドを試み、ボードの電源を入れ直し、デバッグセッションを再開してください。また、GDB PEMicroのデバッグ構成で正しい*.elfファイルが選択されていることを確認してください。 さらに、標準的なNXP S32K144例プロジェクトで問題を再現可能かどうかもテストしてください。これにより、問題がアプリケーション固有のものかどうかを判断できます。 また、現在インストールしているARM 2018.R1のS32 Design Studioのアップデートレベルも確認してください。アップデート11(またはそれ以降)を使用していない場合は、S32K1xxデバイス向けの修正やSDKアップデートが含まれているため、このアップデートの適用をお勧めします。 BR、ペトル
View full article