I tried using EBtresos in AUTOSAR, but it failed to activate. Hello, I tried to use EBtresos in AUTOSAR, but failed to activate it. Activation code: 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) The specified quantity exceeds the maximum allowed quantity (0). Connection to FlexNet Operations Server failed. Therefore, I need another activation code to use EBtresos. Thanks! Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 Hi Sorry for the inconvenience we bring you! I have already reported this issue to the internal team, and I will let you know as soon as I receive their reply.   Best Regards, Robin Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 Thank you for your patience. The internal team has updated the activation code on the webpage. Please click the link below to find the latest activation code: S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool -> EB tresos Studio 29.0.0 

Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Hi, I am currently evaluating the RDBESS774A3EVB Cell Monitoring Unit (CMU) board (which features the MC33774A Battery Cell Controllers) connected to a 50-cell battery pack setup. Recently, an accidental misconnection occurred during our testing. We mistakenly swapped the cell connector sets between J1_1 (upper set) and J1_3 (lower set). The following behaviors were observed during the incident: Initial Event: Immediately upon swapping the connectors, a heavy short circuit occurred at Cell 36, causing an external wire/trace to burn out and break. Subsequent Action: After discovering the mistake, we reconnected the battery packs to the same board using the correct connector positions. Secondary Behavior: As soon as the correct connection was established, multiple balancing resistors (R_balance) on the board began to overheat and burn out. Based on this scenario, we would highly appreciate your engineering insights regarding the following questions: Q1: Did the initial connector swap between J1_1 and J1_3 cause catastrophic internal damage to the MC33774A ICs or related circuitry during the first event? Q2: Is it correct to assume that the multiple balancing resistors burning out during the second (correct) connection was a direct consequence of internal damage inside the MC33774A ICs (e.g., internal FET breakdown or gate drivers stuck in an ON-state) caused by the first incident? Q3: If we replace the damaged MC33774A ICs and all the burned balancing resistors, can the RDBESS774A3EVB board be restored to a fully functional and safe working condition? Are there any other critical companion components (such as ESD/Zener protection diodes or isolation circuit elements) that we should inspect or replace alongside the main ICs? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Hi @guoweisun, We did not connect the entire 50-cell pack into a single connector. Instead, our 50-cell system is divided into three separate segments with three distinct cell connectors. 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Do you mean you mistake to add the 50*3.6V voltage between C17 to ground in the MC33774 first part? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Hi  @guoweisun, To ensure complete hardware safety and prevent any potential wiring issues, we have designed a intermediate "CSU BRIDGE BOARD" to route our 50S battery pack to the RDBESS774A3EVB (featuring three MC33774A AFEs in a daisy chain). Could you please review our attached schematics (CSUBridge_Connector.png and CSUBridge_Block Diagram.png) and verify if our pin mapping and connection strategy are correct?   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Seems no more issue be found but pay attention on the GDN1 GND2 GND3 positions. Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Thank you for your ongoing support. First, we would like to clarify the AFE stacking order in our actual hardware setup to ensure we are aligned: AFE1 (J1_1) is designated for the High-Voltage stage (Cells 37–50). AFE3 (J1_3) is designated for the Low-Voltage stage (Cells 1–18). We have attached the image which document our recent findings and the critical issue we are currently facing. We would appreciate your explicit answers to our previous questions regarding the first incident, as well as a new issue with a new board: [Part 1: Retrospective Questions on the First Board] Q1: Did the initial connector swap between J1_1 and J1_3 cause catastrophic internal damage to the MC33774A ICs or related circuitry during that first event? Q2: Is it correct to assume that the multiple balancing resistors burning out during the second (corrected) connection was a direct consequence of internal damage inside the MC33774A ICs (e.g., internal FET breakdown or gate drivers stuck in an ON-state) caused by the first incident? Q3: If we replace the damaged MC33774A ICs and all the burned balancing resistors, can the RDBESS774A3EVB board be restored to a fully functional and safe working condition? Are there any other critical companion components (such as ESD/Zener protection diodes or isolation circuit elements) that we should inspect or replace alongside the main ICs? [Part 2: NEW ISSUE with a New Board] Following the correct stacking order mentioned above (High-Voltage to AFE1/J1_1, Low-Voltage to AFE3/J1_3), we attempted to test our system using a completely new RDBESS774A3EVB board. However, as soon as it was connected, smoke occurred immediately, and the balancing IC (MC33774A) on the High-Voltage segment (Cells 37–50 / AFE1) was damaged once again. Given that the connection was mapped exactly as intended (High-to-High, Low-to-Low), could you please help us analyze why the new board failed instantly at the AFE1 stage? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) Hi @guoweisun , We are currently encountering a severe issue where the balancing IC is getting damaged during the sequential connection of multiple battery cell groups. Following the local NXP technical advice regarding the unused channels on our Group 1 section (which monitors 14 cells), we have terminated the unused pins as follows directly at the balancing IC input: Connected CB15-18 shorted to CB14 Connected CT15-18 shorted to CT14 Here are the details of our test procedures and the corresponding outcomes: Test 1: Single Group Connection (Group 1 Only) Procedure: We connected only Group 1, which corresponds to the highest potential segment: Cell 37 to Cell 50 (Total of 14 cells, total voltage approx. 50V). Result: The board functioned normally. We were able to accurately read the voltages of all cells. The measured voltage of VBAT_1 relative to GND_1 was stable at approximately 50V. No anomalies were observed. Test 2: Full 3-Group Connection (Sequential Power-Up) Procedure: We connected all 3 cell groups simultaneously but followed a strict bottom-to-top insertion sequence, starting from Group 3 (bottom cells) up to Group 1 (top cells). Result: Upon completion of the connection, smoke and a visible burn occurred near resistor R1_1 (10 ohm). We immediately cut off the power supply to prevent further damage and inspected the board. Post-Mortem & Damage Analysis: VBAT_1 to GND_1 Short Circuit: Electrical testing revealed a dead short between VBAT_1 and GND_1. Since this power line feeds directly into the balancing IC, we suspected internal silicon failure. Resistor R1_1: The 10 ohm resistor was found to be blown open (open-circuit). CT & CB Pins: Inspected both CT and CB pins; there was no physical or electrical damage detected on these pins. Balancing Resistors: Inspected all external cell-balancing resistors; all remain intact and undamaged. IC Root Cause Verification: We desoldered the balancing IC from the PCB to isolate the issue. Testing the unmounted IC confirmed a permanent internal short circuit between the VBAT and GND pins. Questions for NXP Support: Given that the configuration works flawlessly when Group 1 is powered up individually, what could trigger an internal VBAT-to-GND breakdown inside the balancing IC when all three groups are plugged in sequentially (from bottom to top)? Could the termination method of shorting the unused pins (CB15-18 to CB14, and CT15-18 to CT14) induce unexpected transient states or latch-up conditions during multi-chip daisy-chain hot-plugging? What specific hot-plug protection, TVS adjustments, or power-up sequencing constraints do we need to implement to mitigate this failure mode? Please help us analyze and recommend ways to resolve this issue

在 Autosar 程序中调用 OsIf_GetCounter 会导致 E_OS_CALLEVEL 错误 大家好， 我们在基于 AUTOSAR 的程序中使用NXP S32K588 ，搭配ETAS OS和EB MCAL 。 多个 MCAL 元器件提供超时机制，超时方法可以配置为以下两种方式之一： OSIF_COUNTER_SYSTEM OSIF_COUNTER_DUMMY 当超时方法配置为OSIF_COUNTER_SYSTEM时，受影响的驱动程序会在其初始化序列期间尝试通过 OsIf_GetCounter() 访问 OSIF 计数器。 由于这些驱动程序初始化函数是从EcuM_Init()调用的，因此 AUTOSAR 操作系统会通过以下方式报告错误： ErrorHook => E_OS_CALLEVEL 我们理解，这是因为 AUTOSAR OS 计数器 API 只允许从有效的操作系统上下文（例如Tasks或ISR）中访问，而 EcuM_Init() 在操作系统调度程序启动之前执行。 请问处理这种情况的推荐方法是什么？具体来说： 在操作系统初始化之前，对于 MCAL 超时处理是否有推荐的配置？ 对于通过 EcuM_Init() 初始化的驱动程序，是否应该使用 OSIF_COUNTER_DUMMY？ 是否有针对 ETAS OS、EB MCAL 或 NXP 的特定指南/变通方法，以便在预操作系统阶段安全地启用超时功能？ Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL 您好， 谢谢，我会问问SW/RTD团队是否还有其他反馈意见。 BR，彼得 Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL 你好， 你的分析似乎是正确的。如果在操作系统启动之前，从 EcuM_Init() 初始化配置了 OSIF_COUNTER_SYSTEM 的驱动程序，则根据 AUTOSAR 操作系统的实现，对 OsIf_GetCounter() 的调用可能会导致 E_OS_CALLEVEL。 对于在操作系统启动前阶段初始化的模块，常见的解决方法是避免使用基于操作系统的计时服务，而改用 OSIF_COUNTER_DUMMY（或其他非操作系统计时源）。 具体建议可能还取决于 ETAS OS 的实现方式以及所使用的 MCAL/RTD 版本。能否请您提供 S32DS 和 RTD（或 MCAL）版本以便我们进一步核实？ BR，彼得 Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL 您好， 以下是RTD团队的反馈…… BR，彼得 此超时配置（OSIF_COUNTER_SYSTEM / OSIF_COUNTER_DUMMY）是 NXP 厂商特有的，并非由 AUTOSAR 标准本身定义。 E_OS_CALLEVEL 错误的根本原因是 OSIF_COUNTER_SYSTEM 内部调用了操作系统计数器 API，而这些 API 只有在调用 StartOS() 之后才有效。由于 EcuM_Init() 在 StartOS() 之前执行，因此在此阶段调用 OS API 违反了 AUTOSAR OS 调用级别规则。 推荐解决方案： 对于所有通过 EcuM_Init()（操作系统启动前阶段）初始化的 MCAL 驱动程序，请将超时方法配置为： OSIF 计数器类型：OSIF_COUNTER_DUMMY TimeoutValue：使用 EB MCAL 配置中定义的默认值 OSIF_COUNTER_DUMMY 不调用任何操作系统 API，在操作系统启动前的环境中使用是安全的。

AUTOSARでEBtresosを使ってみましたが、アクティベートできませんでした。 こんにちは、 AUTOSARでEBtresosを使ってみようとしたのですが、有効化できませんでした。 アクティベーションコード：7416-E905-5CC2-F20A エラー: flxActAppActivationSend (50040,41147,10248) 指定された数量は、最大許容数量（0）を超えています。 FlexNetオペレーションサーバーへの接続に失敗しました。 そのため、EBtresosを使用するには別の認証コードが必要です。 ありがとう！ Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 ハイ ご迷惑をおかけして申し訳ございません！この件については既に社内チームに報告済みです。返信があり次第、ご連絡いたします。 敬具、ロビン Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 ご辛抱いただきありがとうございます。 社内チームがウェブページ上のアクティベーションコードを更新しました。 最新の認証コードを確認するには、以下のリンクをクリックしてください。 S32K3標準ソフトウェア - > オートモーティブ SW - EB tresos Studio / AUTOSAR Configuration Tool - > EB tresos Studio 29.0.0

mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, I'm attempting to bind multiple IP addresses to a single Ethernet port using different struct netif logical interfaces. My current implementation involves disabling one interface for it to work. Seeking guidance or resources on the correct approach. Any insights appreciated. Thanks, int main(void) { struct netif netif1, netif2; int ret; ip4_addr_t netif1_ipaddr, netif1_netmask, netif1_gw; ip4_addr_t netif2_ipaddr, netif2_netmask, netif2_gw; ethernetif_config_t enet_config = {.phyHandle = &phyHandle, .phyAddr = EXAMPLE_PHY_ADDRESS, .phyOps = EXAMPLE_PHY_OPS, .phyResource = EXAMPLE_PHY_RESOURCE, }; BOARD_ConfigMPU(); BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); BOARD_InitModuleClock(); SCB_DisableDCache(); IOMUXC_SelectENETClock(); BOARD_InitBothEnetPins_test(); BOARD_ENET_PHY1_RESET; EnableIRQ(ENET_1G_MAC0_Tx_Rx_1_IRQn); EnableIRQ(ENET_1G_MAC0_Tx_Rx_2_IRQn); MDIO_Init(); g_phy_resource.read = MDIO_Read; g_phy_resource.write = MDIO_Write; time_init(); CRYPTO_InitHardware(); lwip_init(); // Add the first logical interface with its IP configuration IP4_ADDR(&netif1_ipaddr, 192, 168, 0, 102); IP4_ADDR(&netif1_netmask, 255, 255, 255, 0); IP4_ADDR(&netif1_gw, 192, 168, 0, 100); netif_add(&netif1, &netif1_ipaddr, &netif1_netmask, &netif1_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_default(&netif1); netif_set_up(&netif1); // Add the second logical interface with its IP configuration IP4_ADDR(&netif2_ipaddr, 192, 168, 0, 111); IP4_ADDR(&netif2_netmask, 255, 255, 255, 0); IP4_ADDR(&netif2_gw, 192, 168, 0, 100); netif_add(&netif2, &netif2_ipaddr, &netif2_netmask, &netif2_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_up(&netif2); while (1) { // Poll both netifs for incoming frames ethernetif_input(&netif1); ethernetif_input(&netif2); sys_check_timeouts(); // Handle all system timeouts for all core protocols } return -1; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Mapping multiple IP addresses to a single Ethernet interface in LWIP can be useful in systems that need to handle different network identities or services through one physical connection. The key is ensuring the IP configuration, routing, and ARP handling are properly managed so each address responds correctly without conflicts. When designing embedded networking solutions, it also helps to understand the available hardware options and Explore Networking Products that support flexible network setups and reliable communication. Proper testing with different network scenarios can help identify issues related to packet handling and interface configuration. Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, It's been quite some time since you posted the issue but did had any luck figuring this out?  I am currently trying the same thing with a TI TMS570LC43 launchpad and lwIP 1.4.1 version

MPC5644A core test I am attempting to perform a core test on the MPC5644A chipset. My current environment is Eclipse and Wind River. I downloaded the manufacturer's library, e200Zx_ICST_RTMC_3.0.0, which contains several assembly source (.s) files. Of these, vle compiles successfully. However, book_e and spe fail to compile. During compilation, errors occurred in various assembly instructions such as bc, bcl, bclr, xoris, bclrl, and bcctrl. I opened the properties of the book_e and spe assembly files and added -tPPCE200Z4NEG:simple to C/C++ Build --> Settings --> Diab Assembler --> Other --> Other options and flags, and successfully completed the compilation. However, during the debugging process, I reach just before `Fsl_call_test_execution_icst` in `fsl_self_test_icst.c`, which actually executes the core test. If I proceed to the next step, I fall into an infinite loop. Checking with Eclipse's disassembly, I found that when I step into address 0x51518 (immediately after the start of `SPE_ICST_int_logical_test`), it jumps immediately to 0x3f2b90 (an empty space). What should I do? I don't know where to start. Re: MPC5644A core test Hello, SCST supports only following devices from MPC56xx family: MPC560xP MPC564xB-C Since MPC5644A and MPC564xB share the same e200z4 CPU core, the CPU-focused portions of an SCST library may be adaptable. However, all integration aspects must be reviewed: Exception vector addresses Memory maps Clock initialization Peripheral dependencies Linker script assumptions The actual CPU test algorithms should be largely portable because they target the same e200z4 architecture. NXP does not provide an official SCST library for the legacy MPC5644A device. However, since MPC5644A uses the same e200z4 core as the MPC564xB family, it may be possible to adapt CPU-focused self-test routines from MPC564xB solutions after reviewing device-specific integration details. Alternatively, a custom startup diagnostic implementation can be developed using the MCU's built-in safety mechanisms (ECC, CRC, watchdog, MPU, exception handling) to satisfy project-specific functional safety requirements. What should I do? I don't know where to start. If the code enters SPE_ICST_int_logical_test() at 0x51518 and then immediately branches to 0x3F2B90, which appears to be empty memory, my first suspicion would not be a CPU failure but rather a linker / library integration issue. For an SCST library, this usually means one of the following: 1. Function pointer or branch table not linked correctly 2. Missing library object 3. Wrong memory model / VLE mismatch 4. SCST library built for another device 5. MMU/TLB translation issue best regards, Peter

GoldVip画像のS32G3 LLCE こんにちは、 GoldVip-ユーザー-Manual.pdfの第 23 章の説明に従って、LLCE に必要なコンポーネントも含めて、GoldVip イメージを SD カード (Yocto を使用) に構築し、インストールしました。システムを起動すると、確かに LLCE ファームウェアがロードされていることがわかります。また、DTS（添付）のllce_canエントリが「OK」に設定されており、 .configでは私は持っている： CONFIG_CAN_LLCE=y CONFIG_CAN_LLCE_CORE=y CONFIG_CAN_LLCE_CONTROLLER=m しかし、問題は、ifconfig または ip link show でllce_CANインターフェースが表示されず、CAN0、CAN、CAN1 (FlexCAN に属する) しか表示されないことです。 どうしてこんなことが可能なのでしょうか? Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV 返信ありがとうございます。 提供された方法は純粋な BSP44 で使用できますが、GoldVIP は A53 側の実装に BSP44 を利用します。ただし、これはオートモーティブ用の完全なリファレンス ソフトウェアであり、すべての CAN の使用はリアルタイム コアによって管理されるため、LLCE-CAN を Linux に追加しても成功しない可能性があります。 GoldVIP で LLCE-CAN がどのように処理されるかの詳細については、GoldVIP ユーザー マニュアルの第 14 章を参照することをお勧めします。 BR チェイン Re: S32G3 LLCE on GoldVip image こんにちは、 LLCE FW を有効にして BSP 44 イメージをビルドできました。 次に、GoldVip ベース イメージと添付の local.conf ファイルから YOCTO イメージを構築しようとしました。 イメージをビルドすることはできましたが、SD カードにロードしてボードの電源をオンにすると、ifconfig 出力に LLCE インターフェースが表示されません。ただし、ビルド後の DTS ファイルでは LLCE インターフェースが有効になっていることがわかります (添付も参照)。 この状況にどう対処すればいいのか説明していただけますか？ ありがとう。 Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV 問題が解決したと聞いてうれしいです どういたしまして。 BR チェイン Re: S32G3 LLCE on GoldVip image BSPのエラーを修正しました。それは local.conf 内のおかしなエラー名でした。 サポートありがとうございます Re: S32G3 LLCE on GoldVip image お返事ありがとうございます。 BSP44.0で試してみましたが、しかし、まだインターフェースが表示されません。あなたが言ったセリフを使いました。 ブート ログ (実行したいくつかの操作を含む) を添付します。 また、ブートではこのメッセージがはっきりと表示されます。 "[ 7.054478] llce_mb 43a00000.llce_mb: LLCEモジュールはリセット中です。LLCEファームウェアはロードされていますか? [ 7.062890] llce_mb: 43a00000.llce_mb のプローブがエラー -13 で失敗しました ビルドを行う前にバイナリをアップロードし、おっしゃるとおり local.conf を変更しました (LLCE 1.0.9 のバイナリで実行したのと同じ手順ですが、少なくともそこではファームウェアがアップロードされたようです)。 Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV ご返信ありがとうございます。 私はBSP44 Yoctoソースを直接使用し、conf/local.confを変更して簡単なテストを行いました。 DISTRO_FEATURES:append = " llce-fw-load llce-can" NXP_FIRMWARE_LOCAL_DIR = "LLCEFWへのパス" 再構築すると、llcecan0-15 が Linux シェルから表示できるようになります。 BR チェイン Re: S32G3 LLCE on GoldVip image ご指摘ありがとうございます。 はい、1.0.9 を使用していましたが、1.0.10 で再構築しました。 とにかく、私はいつも同じ問題を抱えています (インターフェースが表示されません)。また、NOR フラッシュ ブート モード (ログを添付) でブートしてもボードを起動できません。 Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV ご返信ありがとうございます。 リリースノートによると、GoldVIP1.14ではBSP44とLLCE1.0.10が使用されている。ログによると、1.0.9 が使用されたようです。テストから確認していただけますか？ よろしくお願いします。 BR チェイン Re: S32G3 LLCE on GoldVip image GoldVip 1.14.0を使用しています ブートログを次のファイルに添付します Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV ご投稿ありがとうございます。 1. 使用している GoldVIP のバージョンを教えていただけますか? 2. コンソールからの完全な起動ログを共有していただけますか? よろしくお願いします。 BR チェイン Re: S32G3 LLCE on GoldVip image こんにちは、 @MrAlexIV さん。私も全く同じ問題を抱えています。解決策は見つかりましたか？ Re: S32G3 LLCE on GoldVip image 投稿ありがとうございます

在 AUTOSAR 中使用 EBtresos，但未能激活。 您好， 我试图在 AUTOSAR 中使用 EBtresos，但未能激活。 激活代码 ：7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) 指定的数量超过允许的最大数量 (0)。 与 FlexNet Operations Server 的连接失败。 因此，我需要另一个激活代码才能使用 EBtresos。 谢谢！ Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 HI 给您带来的不便，我们深表歉意！我已经将此问题报告给了内部团队，一旦收到他们的回复，我会立即通知您。 此致敬礼，罗宾 Re: 在 AUTOSAR 中使用 EBtresos，但未能激活。 感谢您的耐心等待。 内部团队已更新网页上的激活码。 请点击下方链接查找最新激活码： S32K3 标准软件 -> 汽车软件 - EB tresos Studio / AUTOSAR 配置工具 -> EB tresos Studio 29.0.0

AutosarプログラムでOsIf_GetCounterを呼び出すとE_OS_CALLEVEL チームの皆さん、こんにちは。 私たちは NXP S32K588 をAUTOSARベースのプログラムで使用しており、 ETAS OS と EB MCALを組み合わせています。 いくつかのMCALコンポーネントは、タイムアウト方法を以下のいずれかに設定できるタイムアウト機構を提供しています: OSIF_COUNTER_SYSTEM OSIF_COUNTER_DUMMY タイムアウト方法が OSIF_COUNTER_SYSTEMに設定されている場合、影響を受けるドライバーは初期化シーケンス中にOsIf_GetCounter()を通じてOSIFカウンターにアクセスしようとします。 これらのドライバー初期化関数は EcuM_Init()から呼び出されるため、AUTOSAR OSは以下の方法でエラーを報告します: エラーフック => E_OS_CALLEVEL 私たちの理解では、これはAUTOSAR OSカウンターAPIは タスク や ISRなどの有効なOSコンテキストからのみアクセスが許可されているのに対し、EcuM_Init()はOSスケジューラが起動する前に実行されるためです。 この状況に対処するための推奨されるアプローチについてアドバイスをいただけますか?具体的には： OS起動前のMCALタイムアウト処理に関して、推奨される設定はありますか？ EcuM_Init()から初期化されたドライバーにはOSIF_COUNTER_DUMMYを使うべきでしょうか? プリOSフェーズ中にタイムアウト機能を安全に有効にするための、ETAS OS、EB MCAL、またはNXP固有のガイドラインや回避策はありますか？ Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL こんにちは、 ありがとうございます。SW/RTDチームに追加のフィードバックがあれば聞いてみます。 BR、ペトル Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL こんにちは、 あなたの分析は正しいようです。OSIF_COUNTER_SYSTEMで設定されたドライバがOS起動前にEcuM_Init()から初期化されている場合、AUTOSAR OSの実装によってOsIf_GetCounter E_OS_CALLEVELが発生することがあります。 OS起動前の段階で初期化されるモジュールの場合、一般的な回避策は、OSベースのタイミングサービスの使用を避け、代わりにOSIF_COUNTER_DUMMY（または別のOS以外のタイミングソース）を使用することです。 具体的な推奨事項は、ETAS OSの実装方法や使用しているMCAL/RTDのバージョンによっても異なる場合があります。さらなる検証のためにS32DSとRTD(またはMCAL)バージョンを共有していただけませんか? BR、ペトル Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL こんにちは、 RTDチームからのフィードバックは以下をご覧ください。 BR、ペトル このタイムアウト構成(OSIF_COUNTER_SYSTEM / OSIF_COUNTER_DUMMY)はNXPベンダー固有のものであり、AUTOSAR標準自体で定義されていません。 E_OS_CALLEVELエラーの根本原因は、OSIF_COUNTER_SYSTEMが内部的にOSカウンタAPIを呼び出すことですが、これらのAPIはStartOS()が呼び出された後にのみ有効になります。EcuM_Init()はStartOS()より先に実行されるため、この段階でOSのAPIを呼び出すことはAUTOSAR OSの呼び出しレベルルールに違反します。 推奨される解決策： EcuM_Init()(OSフェーズ前)から初期化されたすべてのMCALドライバーについては、タイムアウトメソッドを次のように設定してください。 OSIFカウンタータイプ: OSIF_COUNTER_DUMMY TimeoutValue: EB MCAL構成で定義されているデフォルト値を使用します。 OSIF_COUNTER_DUMMYはOS APIを呼び出さず、OS以前のコンテキストで安全に使用できます。

S32 Design Studio version v.3.4 expired My S32 Design Studio for S32 Platform v.3.4  expired, could you please expand the license? Order Number: S32DS-3-4_156834637 Total Number of Licenses: 101 Activation Code: 7F70-B731-EFE8-3F4B Thank you very much. Re: S32 Design Studio version v.3.4 expired Hi,  your S32DS license has been extended, please activate S32DS again with your old code. 

S32 设计工作室版本 v.3.4 已过期 我的 S32 设计工作室（适用于 S32 平台）v.3.4许可证已过期，请问能否延长许可证期限？ 订单号： S32DS-3-4_156834637 许可证总数： 101 激活码： 7F70-B731-EFE8-3F4B 非常感谢。 Re: S32 Design Studio version v.3.4 expired 你好， 您的 S32DS 许可证已延期，请使用您的旧代码重新激活 S32DS。

IMX8M+（BT+WiFiモジュール搭載）（AW-XB583MA-PUR）BTの初期化には50～60秒かかります。 NXPチームの皆様へ 当社はiMx8M+ベースのカスタムボードを使用しており、PCIeとUARTを介してそれぞれBTとWiFi（Azurawave製のモジュールAW-XB583MA-PUR）を使用しています。 BTの初期化中に問題が発生しており、UART経由で最初のHCIリセットコマンドを送信してから応答が得られるまでに約50～60秒（常に一定の時間）かかります。Azurawaveチームと確認・デバッグを行ったところ、NXP側にも確認するよう提案されました（彼らの見解では、これはNXP側の問題である可能性が高いとのことです）。 以下は、SoCとモジュール間の接続図です。 NXP: UART1_RXD <---> モジュール: UART TXD NXP: UART1_TXD <---> モジュール: UART RXD NXP: UART3_TXD <---> モジュール: UART RTS NXP: UART3_RXD <---> モジュール: UART CTS デバイスツリーの変更点： &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; 割り当てられたクロック = <&clk IMX8MP_CLK_UART1>; 割り当てられたクロック親 = <&clk IMX8MP_SYS_PLL1_80M>; /*fsl,uart-has-rtscts;*/ ステータス = "正常"; }; pinctrl_uart1: uart1grp { fsl、pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized こんにちは、 @hiteshviradiya さん。 お元気でお過ごしのことと思います。 デバイスツリーの詳細を教えていただけますか？Pinmuxのコードしか見えません。 また、使用しているBSPのバージョンと、Wi-Fiモジュールへの接続に使用しているドライバの詳細も教えてください。 よろしくお願いいたします。 サラス。 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized @Manuel_Salas様、 弊社では、カスタマイズされたBuildroot（バージョン2024.08）を使用しています。カーネルバージョン：6.6.36。以前、BT関連のデバイスツリーコードとPinmuxを共有しましたが、以下に改めて共有します。 &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; 割り当てられたクロック = <&clk IMX8MP_CLK_UART1>; 割り当てられたクロック親 = <&clk IMX8MP_SYS_PLL1_80M>; fsl、uart-has-rtscts; ステータス = "正常"; }; pinctrl_uart1: uart1grp { fsl、pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; 他に特定のデバイスツリーノードが必要な場合はお知らせください。 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized こんにちは、 使用しているドライバを指定してください。 それは習慣ですか？当サイトのBSPではAW-XB583MAを直接サポートしていません。 よろしくお願いいたします。 サラス。 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 現在は汎用UARTドライバが使用されています

Wi-Fi 命令响应超时 我正在使用基于恩智浦 IW612 芯片组的 i.MXRT1062 跨界微控制器和村田 2EL M.2 无线卡开发一个项目。该项目使用了 MCUXpresso SDK 和 FreeRTOS。当前 SDK 版本为 25.12。 在固件运行过程中，调试控制台有时会显示以下输出： `[wifi] 警告：命令响应超时。命令 0x0，长度 1514，序列号 0x16` 或 `[wifi] 警告：命令响应超时。命令 0x0，长度 66，序列号 0x16` 或 `[wifi] 警告：命令响应超时。命令 0x0，长度 190，序列号 0x16` 或 `[wifi] 警告：命令响应超时。命令 0x0，长度 60，序列号 0x16` 我不知道这些行是什么意思，可能是无线模块出了问题。打印任务列表之后，会触发紧急情况并使固件停止运行。我认为这个问题通常发生在通过无线网络连接进行流量大小不一的传输约30分钟后。 SDK 文件中的相应位置位于 `wifi_wait_for_cmdresp` 函数中的 `中间件/wifi_nxp/wifidriver/wifi.c` 中。这一点还进一步得到证实：在之前的调试控制台输出与这一行之间，大约有20秒的间隔。 我该如何排查这个问题？我可以与您合作，提供进一步的调试信息或测试 SDK 的修复方案。 Re: Wi-Fi command response timeout 您好， 我知道您正在使用一个自定义应用程序，但您是以哪个 SDK 示例作为起点开发的？如果您能使用未经修改的 SDK 示例重现相同的问题，这将极大有助于定位问题。 看来驱动程序一直在等待命令响应，但在超时结束前并未收到响应。 请在 wifi_config.h 中启用以下调试宏： CONFIG_WIFI_CMD_RESP_DEBUG CONFIG_WIFI_EVENTS_DEBUG CONFIG_WIFI_IO_INFO_DUMP CONFIG_WIFI_EXTRA_DEBUG 启用宏后，请重新编译示例并再次进行测试。请分享输出结果。 最好用最新的 SDK 进行测试，看看问题是否依然存在。 Re: Wi-Fi command response timeout 这是固件卡住时的调试输出。如果您需要之前的日志行，请告诉我。 2026年6月23日 12:27:48.808 [RX] - [wifi] 警告：命令响应超时。命令 0x0，长度 890，序列号 0x16 SDIO多端口组寄存器值： **** 转储 @ 20218FC0 长度：196 **** 00 00 00 00 ff 00 00 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 7f 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 03 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 00 00 00 00 00 87 0c 00 00 00 00 00 00 00 00 00 00 1c c2 06 c0 f4 德 09 c0 00 1e ff ff 00 0a 36 01 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 10 cc f0 ff ff ff ff ff 00 00 ff ff ff ff ff ff f4 74 04 c0 80 98 04 c0 00 00 00 00 ******** 结束转储 ******* 名称 状态 优先级 堆栈号 ================================================== 主任务 X 3 581 6 print_dhcp R 0 683 17 空闲 R 0 92 2 tcp/ip B 3 400 1 Tmr Svc B 4 196 3 supplicant_main_tas B 2 1456 14 nfc_cfg B 0 715 7 dhcpd_task B 3 406 15 HTTP 服务器 B 1 888 18 wifi_scan_task B 1 255 11 wlcmgr_task B 3 244 13 wifi_drv_task B 3 228 10 lwip_rx B 3 431 8 wifi_core_task B 3 276 12 [wifi] 开始处理挂起 [wifi] 正在发起 wifi 身份验证 [固件下载] S 2026年6月23日 12:27:48.824 [RX] - 开始从 0x602319fc 下载固件：1618224 2026年6月23日 12:27:54.807 [RX] - [wifi_io] 错误：SDIO - 固件就绪寄存器未设置 [wifi] 错误：sd_wifi_reinit 失败。状态码-1 断言：wlan_process_hang：550 断言失败：恐慌！ 断言错误“0”：文件“C:/tmp/mcuxsdk/mcuxsdk/中间件/wifi_nxp/wifidriver/incl/mlan_api.h”第65行函数名“panic” Re: Wi-Fi command response timeout @DanielRuvalcaba你好，请问这个问题有任何进展吗？SDK 26.03 版本也存在这个问题，您还需要我提供更多调试信息吗？ Re: Wi-Fi command response timeout 你使用的是哪个SDK示例？ 请问能否提供重现此问题的步骤？ 您使用的是定制电路板还是恩智浦参考电路板？ 是否存在任何特定的操作或条件会持续触发该问题？ 问候， 丹尼尔。 Re: Wi-Fi command response timeout 我最初使用的是 wifi_setup SDK 示例，但现在已经做了很大的修改。我使用的是定制板。 我们注意到，当无线网卡接收（可能发送）流量较大（每秒 60 兆字节或更多）时，就会出现此问题，同时固件会向无线网卡发送命令以查询平均 RSSI 和 SNR。我们的代码每秒执行一次该操作，问题通常会在一分钟内（通常更短）被触发。 如果我禁用命令传输，就不会触发该问题。 我希望这些信息能帮助您重现该问题（关键时刻是接收流量和命令传输同时进行）。

Wi-Fi command response timeout I'm working on a project using i.MXRT1062 crossover MCU and Murata 2EL M.2 wireless card based on NXP IW612 chipset. The project uses MCUXpresso SDK and FreeRTOS. The current SDK version is 25.12. During the firmware operation, sometimes I get the following output in the debug console: `[wifi] Warn: Command response timed out. command 0x0, len 1514, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 66, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 190, seqno 0x16` or `[wifi] Warn: Command response timed out. command 0x0, len 60, seqno 0x16` I don't know what do these lines mean, probably some problem with wireless module. After that a task list is printed, panic is triggered and the firmware stalls. I think the problem happens after ~30 minutes during more or less heavy traffic through the wireless connection. A corresponding place in the SDK files is located at `middleware/wifi_nxp/wifidriver/wifi.c` in `wifi_wait_for_cmdresp` function. This is further confirmed that there's a pause of roughly 20 seconds between the previous debug console print and this line. How can I troubleshoot the problem? I can work with you to provide further debugging information or test SDK fixes. Re: Wi-Fi command response timeout Hi, I understand you are using a custom application, but which SDK example did you use as a starting point? If you can reproduce the same behavior using an unmodified SDK example, it would significantly help isolate the issue. Seems the driver was waiting for a command response, and did not receive it before the timeout expired. Please enable the following debug macros in wifi_config.h: CONFIG_WIFI_CMD_RESP_DEBUG CONFIG_WIFI_EVENTS_DEBUG CONFIG_WIFI_IO_INFO_DUMP CONFIG_WIFI_EXTRA_DEBUG Once the macros are enabled; rebuild the example and test it again. Please share the output. I would be a good idea to test it with the latest SDK and see if the problems still occurs. Re: Wi-Fi command response timeout This is the debug output when the firmware hangs up. Please let me know if you need any previous log lines. 23/06/2026 12:27:48.808 [RX] - [wifi] Warn: Command response timed out. command 0x0, len 890, seqno 0x16 SDIO multiple port group registers value: **** Dump @ 20218FC0 Len: 196 **** 00 00 00 00 ff 00 00 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 7f 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 03 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 00 00 00 00 00 87 0c 00 00 00 00 00 00 00 00 00 00 1c c2 06 c0 f4 de 09 c0 00 1e ff ff 00 0a 36 01 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 10 cc f0 ff ff ff ff ff 00 00 ff ff ff ff ff ff f4 74 04 c0 80 98 04 c0 00 00 00 00 ******** End Dump ******* Name State Priority Stack Num ================================================== main_task X 3 581 6 print_dhcp R 0 683 17 IDLE R 0 92 2 tcp/ip B 3 400 1 Tmr Svc B 4 196 3 supplicant_main_tas B 2 1456 14 nfc_cfg B 0 715 7 dhcpd_task B 3 406 15 HTTP server B 1 888 18 wifi_scan_task B 1 255 11 wlcmgr_task B 3 244 13 wifi_drv_task B 3 228 10 lwip_rx B 3 431 8 wifi_core_task B 3 276 12 [wifi] Start to process hanging [wifi] initiating wifi-deauth [FW Download] S 23/06/2026 12:27:48.824 [RX] - tart to download firmware from 0x602319fc: 1618224 23/06/2026 12:27:54.807 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_reinit failed. status code -1 ASSERT: wlan_process_hang: 550 Assert failed: Panic! ASSERT ERROR " 0 ": file "C:/tmp/mcuxsdk/mcuxsdk/middleware/wifi_nxp/wifidriver/incl/mlan_api.h" Line "65" function name "panic" Re: Wi-Fi command response timeout Hi @DanielRuvalcaba , is there any update on this issue? This also happens on SDK 26.03, do you need more debug info from me? Re: Wi-Fi command response timeout What SDK example are you using? Could you please share the steps required to reproduce the behavior? Are you using a custom board or an NXP reference board? Is there any specific action or condition that consistently triggers the issue? Regards, Daniel. Re: Wi-Fi command response timeout I started with wifi_setup SDK example, but it is very heavily modified now. I'm using a custom board. We noticed this issue happens when there is heavy Rx (maybe Tx works too) traffic to the wireless card (60 MegaBytes/second or more), and at the same time the firmware sends a command to the wireless card to query the average RSSI and SNR. Our code did that once per second, and the issue was triggered within a minute, usually less. If I disable the command transmission, the issue is not triggered. I hope this info helps you in reproducing the issue (the key moments are heavy Rx traffic and command transmission at the same time).

CLI/无头模式 您好！GUI Guider 2.0.0 是否有任何 CLI / 无头构建功能，可以用于自动化我项目中的一些 CI 版本？我不想在我的代码仓库中跟踪生成的 C 文件。 Re: CLI/Headless 我也想知道这一点。 Re: CLI/Headless 嗨@nbarrett ， @znickerson ， GUI Guider 本身并不支持 CLI 或无头代码生成，因此无法从 CI 管道中调用这些代码。 也就是说，GUI Guider 2.0.0 利用 CMake 和 Ninja 将 GUI Guider 项目生成的代码构建并编译成可刷写的 .bin 文件。或 .elf因此，通过创建使用这些工具的脚本，应该可以实现此过程的自动化。我们目前没有任何关于如何完成此操作的文档指南或脚本示例，但您可以参考 GUI Guider 工具的构建和编译日志，详细了解 GUI Guider 2.0.0 在基于 ARMGCC 的项目上执行的过程。 BR， 埃德温。

IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Dear NXP team, We have iMx8M+ based custom board and using BT & WiFi ( module AW-XB583MA-PUR from Azurawave) over PCIe and UART respectively. We are facing issue while BT initializing which takes around 50-60 seconds (fixed duration always) to get response on 1st HCI reset command over UART. We checked/debugged it with Azurawave team and they suggested also to check w/ NXP (as it seems to them) that this might be NXP side issue. Below are the SoC connections to module: NXP: UART1_RXD <---> Module: UART TXD NXP: UART1_TXD <---> Module: UART RXD NXP: UART3_TXD <---> Module: UART RTS NXP: UART3_RXD <---> Module: UART CTS Device tree changes we did: &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; assigned-clocks = <&clk IMX8MP_CLK_UART1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; /*fsl,uart-has-rtscts;*/ status = "okay"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Hello @hiteshviradiya  Hope you are doing very well. Could you please share details on device tree? I just can see the Pinmux code. Also, details about the BSP version you are using and the driver used to connect to the WIFI module. Best regards, Salas. Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Dear @Manuel_Salas, We are using customized buildroot (version 2024.08) w/ Kernel version: 6.6.36. I already shared BT related device tree code along with Pinmux but sharing it again as below: &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; assigned-clocks = <&clk IMX8MP_CLK_UART1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; Let me know if you want any other specific device tree node. Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Hello. Please specify the driver you are using. Is it a custom? we do not support AW-XB583MA directly in our BSP. Best regards, Salas. Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized the generic UART driver is currently in use

CLI/ヘッドレス こんにちは！GUI Guider 2.0.0には、プロジェクトのCIビルドを自動化するためのCLI/ヘッドレスビルド機能はありますか？生成されたCファイルを自分のリポジトリで追跡したくはありません。 Re: CLI/Headless 私も知りたいです。 Re: CLI/Headless こんにちは、@nbarrett さん、 @znickerson さん、 GUI Guiderは、CIパイプラインから呼び出せるCLIやヘッドレスコード生成をネイティブにサポートしていません。 とはいえ、GUI Guider 2.0.0はCMakeとNinjaを利用して、GUI Guiderプロジェクトから生成されたコードをビルドおよびコンパイルし、フラッシュ可能な.binファイルを作成します。または.elfイメージを使えば、これらのツールを使ったスクリプトを作成すれば、このプロセスを自動化できるはずです。現時点では、これがどのように行われるのかのガイドやスクリプトの例はありませんが、GUI Guiderツールのビルド&コンパイルログを参照すると、GUI Guider 2.0.0がARMGCCベースのプロジェクトでどのように処理しているかを詳しく確認できます。 BR、 エドウィン。

MPC5644A 核心测试 我正在尝试对 MPC5644A 芯片组进行核心测试。 我目前使用的环境是 Eclipse 和 Wind River。 我下载了制造商的库 e200Zx_ICST_RTMC_3.0.0，其中包含几个汇编源 (.s) 文件。 其中，vle 编译成功。 但是 book_e 和 spe 编译失败。 编译过程中，各种汇编指令（如 bc、bcl、bclr、xoris、bclrl 和 bcctrl）出现错误。我打开了 book_e 和 spe 汇编文件的属性，并将 -tPPCE200Z4NEG:simple 添加到 C/C++ 版本 --> 设置 --> Diab 汇编器 --> 其他 --> 其他选项和标志中，并成功完成了编译。然而，在调试过程中，我到达了 `fsl_self_test_icst.c` 中的 `Fsl_call_test_execution_icst` 之前，而这部分实际上执行的是核心测试。如果我继续进行下一步，就会陷入无限循环。 通过 Eclipse 的反汇编检查，我发现当我单步进入地址 0x51518（紧接在 `SPE_ICST_int_logical_test` 开始之后）时，它会立即跳转到 0x3f2b90（一个空白空间）。 我应该怎么办？我不知道从哪里开始。 Re: MPC5644A core test 你好， SCST 仅支持 MPC56xx 系列中的以下设备： MPC560xP MPC564xB-C 由于 MPC5644A 和 MPC564xB 共享相同的 e200z4 CPU 内核，因此 SCST 库中以 CPU 为中心的部分可以进行调整。但是，所有整合方面都必须进行审查： 异常向量地址 存储器映射 时钟初始化 外围依赖性 链接器脚本假设 实际的 CPU 测试算法应该具有很强的可移植性，因为它们针对的是相同的 e200z4 架构。 NXP 没有为旧款 MPC5644A 设备提供官方的 SCST 库。然而，由于 MPC5644A 与 MPC564xB 系列使用相同的 e200z4 内核，因此在审查特定设备的集成细节后，或许可以采用 MPC564xB 解决方案中以 CPU 为中心的自检例程。或者，可以使用 MCU 的内置功能安全机制（ECC、CRC、看门狗、MPU、异常处理）开发自定义启动诊断实现，以满足项目特定的功能安全要求。 我应该怎么办？我不知道从哪里开始。 如果代码在 0x51518 处进入 SPE_ICST_int_logical_test()，然后立即跳转到 0x3F2B90（看起来像是空内存），我首先怀疑的不是 CPU 故障，而是链接器/库集成问题。 对于 SCST 库而言，这通常意味着以下情况之一： 1. 函数指针或分支表未正确链接 2. 缺少库对象 3. 内存模型错误/虚拟环境不匹配 4. 为另一台设备构建的 SCST 库 5. MMU/TLB 翻译问题 顺祝商祺！ Peter

GoldVip 图像上的 S32G3 LLCE 你好， 我在 SD 卡（使用 Yocto）上构建并安装了 GoldVIP 镜像，如 GoldVip-User-Manual.pdf 第 23 章所述，还包括 LLCE 所需的元器件。当我启动系统时，我确实可以看到 LLCE 固件已加载。我还看到 DTS（附后）中的llce_can条目被设置为 "okay"，而.config 中的 我有 CONFIG_CAN_LLCE=y CONFIG_CAN_LLCE_CORE=y CONFIG_CAN_LLCE_CONTROLLER=m 但我的问题是，我在 ifconfig 或 ip link show 中看不到llce_can接口；我只看到 can0、can和 can1（属于 FlexCAN）。 这怎么可能？ Re: S32G3 LLCE on GoldVip image 你好，@MrAlexIV 感谢您的回复。 提供的方法可以在纯 BSP44 下使用，GoldVIP 利用 BSP44 进行 A53 端实现，但是，它是一个用于汽车用途的完整参考软件，所有 CAN 用途都由实时内核管理，因此将 LLCE-CAN 添加到 Linux 中可能不成功。 我建议参考GoldVIP用户手册的第14章，详细了解GoldVIP如何处理LLCE-CAN。 BR 切宁 Re: S32G3 LLCE on GoldVip image 你好，启用 LCE 固件后， 我得以版本 电路板支持包。 44 映像。 然后我正在尝试从 GoldVIP 基础镜像和随附的本地.conf 文件开始版本我的 YOCTO 镜像。 我设法版本了镜像，但是当它加载到 SD 卡上并且板开启时，ifconfig 输出中没有出现 LLCE 接口。不过，我可以在版本后在 DTS 文件中看到 LLCE 接口已启用（也附在附件中）。 您能解释一下如何面对这种情况吗？ 谢谢。 Re: S32G3 LLCE on GoldVip image 你好，@MrAlexIV 很高兴听到问题已得到解决 不客气。 BR 切宁 Re: S32G3 LLCE on GoldVip image 我修复了电路板支持包的错误。这是 local.conf 中一个愚蠢的错误名称。 感谢您的支持 Re: S32G3 LLCE on GoldVip image 谢谢您的答复。 我用 BSP44.0 试过、但我还是看不到界面。我用了你提到的台词。 我附上了启动日志（还有我做的一些操作）。 另外，在启动时我能清楚地看到这条消息： " [7.054478] llce_mb 43a00000.llce_mb：LLCE 模块处于 RESET 状态。LCE 固件加载了吗？ [7.062890] llce_mb：对 43a00000.llce_mb 的探测失败了，错误是 -13 " 我在版本之前上传了二进制文件并按照你提到的更改了 local.conf（我对 LCE 1.0.9 的二进制文件所做的过程相同，但至少固件似乎已经上传了）。 Re: S32G3 LLCE on GoldVip image 你好，@MrAlexIV 感谢您的回复。 我直接使用 BSP44 Yocto 源码进行了快速测试，对 conf/local.conf 进行了修改 DISTRO_FEATURES:append =" llce-fw-load llce-can" NXP_FIRMWARE_LOCAL_DIR ="PATH_TO_LLCEFW" 重建后，就可以通过 linux shell 看到 llcecan0-15 了。 BR 切宁 Re: S32G3 LLCE on GoldVip image 谢谢你的意见。 是的，我使用的是 1.0.9 版，但我现在重新构建了 1.0.10 版。 总之，我总是遇到同样的问题（我看不到接口）。我还注意到我无法在或非闪存启动模式下启动板（附上日志）。 Re: S32G3 LLCE on GoldVip image 您好，@MrAlexIV 感谢您的回复。 根据版本说明，GoldVIP1.14 中使用了 BSP44 和 LLCE1.0.10，从日志来看，似乎使用的是 1.0.9 版？您能从您的测试中检查一下吗？ 谢谢！ BR 切宁 Re: S32G3 LLCE on GoldVip image 我使用的是GoldVip 1.14.0 我在以下文件中附上了启动日志 Re: S32G3 LLCE on GoldVip image 你好，@MrAlexIV 谢谢您的帖子。 1.请问您使用的是哪个版本的 GoldVIP？ 2。你介意和我分享控制台的完整启动日志吗？ 谢谢！ BR 切宁 Re: S32G3 LLCE on GoldVip image 嗨@MrAlexIV 。我的问题也完全一样。你找到解决方法了吗？ Re: S32G3 LLCE on GoldVip image 感谢4条帖子

S32G3 LLCE on GoldVip image Hi, I built and installed the GoldVip image on the SD card (using Yocto), as described in chapter 23 of the GoldVip-User-Manual.pdf, also including the components required for LLCE. When I boot the system, I can indeed see that the LLCE firmware is loaded. I also see that the llce_can entries in the DTS (attached) are set to “okay,” and in the .config I have:  CONFIG_CAN_LLCE=y CONFIG_CAN_LLCE_CORE=y CONFIG_CAN_LLCE_CONTROLLER=m My problem, however, is that I don’t see the llce_can interfaces with ifconfig or ip link show; I only see can0 and can and can1 (which belong to FlexCAN). How is this possible? Re: S32G3 LLCE on GoldVip image Hello, @MrAlexIV  Thanks for the reply. The method provided could be used under pure BSP44, GoldVIP utilize the BSP44 for its A53 side implementation, however, it is a whole reference software for automotive purposes, all CAN uses are managed by the real time cores, therefore adding LLCE-CAN to Linux may not be successful. I suggest referencing the chapter 14 of GoldVIP User Manual, to get details of how the LLCE-CAN are handled in the GoldVIP. BR Chenyin Re: S32G3 LLCE on GoldVip image Hi, I was able to build the BSP 44 image with the enabling of the LLCE FW. Then I was trying to build my YOCTO image starting from the GoldVip base image and the attached local.conf file. I managed to build the image, but when it is loaded on the SD card and the board is on, no LLCE interfaces appear in ifconfig output. Although, I can see the LLCE interfaces as enabled in the DTS file after the build (attached as well).  Can you explain how to face with this situation? Thank you. Re: S32G3 LLCE on GoldVip image Hello, @MrAlexIV  Glad to hear that the issue has been fixed You are welcome. BR Chenyin Re: S32G3 LLCE on GoldVip image I fixed the error for the BSP. It was a silly error name in the local.conf. Thank you for your support Re: S32G3 LLCE on GoldVip image Thank you for your reply. I tried with the BSP44.0, but I still can't see the interface. I used the lines you mentioned. I attach the boot logs (with some operations I did). Also, in the boot I can clearly see this message : "[ 7.054478] llce_mb 43a00000.llce_mb: LLCE modules are under reset. Is the LLCE firmware loaded? [ 7.062890] llce_mb: probe of 43a00000.llce_mb failed with error -13" I uploaded the binaries before doing the build and changed the local.conf as you mentioned (the same procedure I did with the binaries of the LLCE 1.0.9, but at least there the firmware seemed uploaded). Re: S32G3 LLCE on GoldVip image Hello, @MrAlexIV  Thanks for your reply. I did a quick test with the BSP44 Yocto source directly, with the modification on the conf/local.conf DISTRO_FEATURES:append = " llce-fw-load llce-can" NXP_FIRMWARE_LOCAL_DIR = "PATH_TO_LLCEFW" Once rebuilt, the llcecan0-15 could be seen from the linux shell. BR Chenyin  Re: S32G3 LLCE on GoldVip image Thank you for the observation. Yes, I was using 1.0.9, but I now re-builded with the 1.0.10. Anyway, I always have the same problem (I do not see the interfaces). I also noticed that I can't start the board in booting in NOR Flash Boot Mode (log attached). Re: S32G3 LLCE on GoldVip image Hello, @MrAlexIV  Thanks for your reply. From the release notes, the BSP44 and LLCE1.0.10 are used in GoldVIP1.14, from the log, seems it was 1.0.9 used? would you mind checking it from your test？ Thanks BR Chenyin Re: S32G3 LLCE on GoldVip image I am using GoldVip 1.14.0 I attach the boot log in the following file Re: S32G3 LLCE on GoldVip image Hello, @MrAlexIV  Thanks for your post. 1. May I know which version GoldVIP you are working with? 2. Would you mind sharing me with the full booting log from console? Thanks BR Chenyin Re: S32G3 LLCE on GoldVip image Hi @MrAlexIV. I have the exact same problem. Did you find a solution? Re: S32G3 LLCE on GoldVip image tnx 4 post