Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
必要なサポート:Wayland-EGLプラグインおよびIVI-Shellのビデオ再生パフォーマンスの問題 こんにちは、NXP チームの皆様、 Yocto Linuxのセットアップで確認されたWayland/Westonシェル関連の問題について、皆様のサポートをお願いしています。 現在、 kiosk-shellとivi-shellを使用した動画再生の検証を行っています。kiosk-shellを使用すると、wayland-egl プラグインが検出されてアクセス可能になり、フレーム落ちやシステムハングアップもなく、ビデオ再生がスムーズに動作します。しかし、 ivi-shellを使うとwayland-eglプラグインに正しくアクセス・取得できず、動画再生時にフレームロスや断続的なハングが発生します。 問題の概要は以下のとおりです。 項目観察 プラットフォーム i.MX8QXP C0 MEK OS Yocto Linux [ Scarthgap L6.6.5] ウェストンシェル1 キオスクシェル ウェストンシェル2 イヴィシェル グラフィックスインターフェース ウェイランド / ウェイランド-EGL ビデオ再生 GStreamerベースの再生 観察 テストケース結果 キオスクシェル + ウェイランドEGL プラグインは利用可能でアクセス可能です キオスク端末+ビデオ再生 動画はフレーム落ちやフリーズなくスムーズに再生されます。 ivi-shell + wayland-egl Wayland-eglプラグインが正しく検出・アクセスされません ivi-shell + ビデオ再生 フレーム落ちや断続的なフリーズが観測された サポートが必要です 以下のポイントについてご助言いただけますか? wayland-eglはi.MX8QXP Yocto Linux 6.6.5バージョンの ivi-shell で完全にサポートされているのでしょうか wayland-eglをivi-shellで有効にするために、Weston、IVI-shell、またはコンポジタの設定で何か特別な変更が必要ですか? i.MX8QXP上でivi-shellを使用する場合、推奨されるweston.iniの設定はありますか? ivi-shellの動画再生やGPUによるレンダリングに既知の制限はありますか? ivi-shell + wayland-egl + video playbackの参考文献、パッチ、または例のアプリケーションはありますか? フレームの損失やハングは、コンポジターの設定、バッファの処理、GPU/VPUの統合、またはGStreamerのスリンク選択に関連しているのでしょうか? 要求 この問題を解決するためのガイダンス、推奨構成、および利用可能な参考資料やパッチをご提供ください。 Re: Support Required: Wayland-EGL Plugin and Video Playback Performance Issue with IVI-Shell こんにちは、 以下のドキュメントを参照してください。 https://wayland.pages.freedesktop.org/weston/toc/ivi-shell.html https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/AGL-architecture-and-How-to-port-in-i-MX8qm/ta-p/1383200 よろしくお願いいたします。 アルド。
View full article
iMX 937プロセッサの最小から最大スリープ電流mAはどれくらいですか?   私のプロジェクトではI.MX937プロセッサを使っていますが、i.MX 937プロセッサの典型的なスリープ電流(mA)はどれくらいですか?   Re: What is the min to max sleep current mA for the iMX 937 processor これらのリソースを使い続けるためには、 150μAのスリープ電流は i.MX 937 / i.MX 93プロセッサ自体では現実的ではありません 。 なぜ: モード 電流/電力への影響 150μAに適合しますか? 機能的な適合性 BBSM / RTCモード データシートには、 1.8Vで0.14mW 電力測定アプリのメモには、約 合計97.978 µW わずか  NVCC_BBSM_1P8  アクティブ。 パワーの面では、はい いいえ — BBSM/RTCロジックのみに電源が供給され、GPIOウェイクアップはオフになり、タイマー/PWM/ADCは使用できません。 中断 データシートには、 標準値:15.1mW 25℃で。 いいえ — 150 µA相当をはるかに超える いいえ/制限付き — サスペンドはクロックをオフにし、Cortex-A55の電源を落とし、内部の論理/アナログブロックを停止させることができます。 WFIにおけるLinux Suspend + M33 アプリのノートにはこの用途で合計 122.4 mW 記載されています。 なし 建築的には近いが、それでも現在の目標をはるかに上回っている。 Cortex-M33を用いた低消費電力実行/AONMIX AONMIXは他のドメインが電源オフ中でも動作可能で、タイマー/PWMおよびタイマーリソースを含みます。 150 µAの要件を満たしているとは文書化されていません これはペリフェラルがアクティブでなければならない場合の i.MX 93モードクラスの関連ですが、150 μAクラスのモードではありません。   150 µA の予算は、 1.8Vで0.27mW または 3.3Vで0.495mW 。それはi.MX 93の範囲内です BBSM/RTC専用 アクティブなタイマー出力、ADC、PWM、RTC、およびGPIOを備えた状態ではない状態。 推奨アーキテクチャ:i.MX 937を BBSM/RTCまたは完全電源ゲートスリープ に置き、常時稼働機能(タイマー出力、ADC監視、PWM、GPIO監督)を非常に低消費電力のコンパニオンMCUまたはアナログ/RTC回路に移すこと。条件が満たされると、伴随デバイスが i.MX 937を起動させることができます。 i.MX 937は、非常に限られたRTC/BBSMスタイルの状態でのみ~150μAを供給できます。その予算内でタイマー/PWM/ADC/GPIOの機能を有効に保つことはできません。 Re: What is the min to max sleep current mA for the iMX 937 processor 当社のアプリケーションでは、低消費電力/スリープモードで機能を維持するために以下のリソースが必要です: 1 タイマー出力ピン 1つのADC入力 1 PWM RTC 2~3個のGPIO スリープ時の必要電流は150μAです。 Re: What is the min to max sleep current mA for the iMX 937 processor i.MX 937 / i.MX 93プロセッサ自体については、データシートにはmA単位の「スリープ電流」は一切記載されていません。SUSPENDモードの総電力=25°Cで15.1 mWを指定し、この数値はユースケース依存であることが記されています。SUSPENDは最も低消費電力モードで、クロックはオフ、不要な電源はオフ、パワーゲート可能なSoC部分はゲート、Cortex-A55は完全にパワーゲート、DRAMは自己更新/保持状態です。 予算編成のために同等の電流が必要な場合は、以下を使用してください。 したがって、15.1 mWはおおよそ次の通りに対応します: 想定供給基準 等価電流 5.0V入力 3.0 mA 3.3V入力 4.6 mA これは単なるSoCレール電流ではなく、等価入力電流です。実際のプロセッサ電流は複数の電源レールに分散されます。 もし基板やSOMのディープスリープ電流のことを指しているなら、測定値はより高いもので構成依存することがあります。i.MX93 SOM DSMの測定結果の一つでは、 5Vで4.04mAという値が報告されており、その他の最適化/構成依存の報告では、5Vで1.5mAから9.3mA程度となっている。 プロセッサ仕様には15.1 mWの典型的なSUSPEND電力を使用します。実際の入力レールに対してのみmAに変換してください。例えば、5Vで約3.0mAです。
View full article
What is the min to max sleep current mA for the iMX 937 processor   In my project I am using I.MX937 processor, what is the typical sleep current (mA) for the i.MX 937 processor?    Re: What is the min to max sleep current mA for the iMX 937 processor With those resources required to stay functional, 150 µA sleep current is not realistic for the i.MX 937 / i.MX 93 processor itself . Why: Mode Current/power implication Fits 150 µA? Functional fit BBSM / RTC mode Datasheet lists 0.14 mW at 1.8 V , and the power-measurement app note shows about 97.978 µW total , with only  NVCC_BBSM_1P8  active. Power-wise, yes No — only BBSM/RTC logic remains powered; GPIO wakeup is OFF, and timer/PWM/ADC are not available. Suspend Datasheet lists 15.1 mW typical at 25 °C. No — far above 150 µA equivalent No / limited — suspend turns off clocks, powers down the Cortex-A55, and powers down internal logic/analog blocks that can be shut off. Linux Suspend + M33 in WFI App note lists 122.4 mW total for this use case. No Closer architecturally, but still far above your current target. Low-power run / AONMIX using Cortex-M33 AONMIX can run while other domains are powered down, and includes timer/PWM and timer resources. Not documented as meeting 150 µA This is the relevant i.MX 93 mode class if peripherals must remain active, but it is not a 150 µA-class mode.   A 150 µA budget corresponds to only 0.27 mW at 1.8 V or 0.495 mW at 3.3 V . That is in the range of the i.MX 93 BBSM/RTC-only state, not a state with active timer output, ADC, PWM, RTC, and GPIOs. Recommended architecture: keep the i.MX 937 in BBSM/RTC or fully power-gated sleep , and move the always-on functions — timer output, ADC monitoring, PWM, and GPIO supervision — to a very-low-power companion MCU or analog/RTC circuit. The companion device can wake the i.MX 937 when the condition is met. The i.MX 937 can meet ~150 µA only in a very limited RTC/BBSM-style state; it cannot keep timer/PWM/ADC/GPIO functionality active within that current budget. Re: What is the min to max sleep current mA for the iMX 937 processor In our application, the following resources are required to remain functional during the low-power/sleep mode: 1 Timer output pin 1 ADC input 1 PWM RTC 2–3 GPIOs Our requirement of sleep current is 150 µA. Re: What is the min to max sleep current mA for the iMX 937 processor For the i.MX 937 / i.MX 93 processor itself, the datasheet does not give a single “sleep current” in mA. It specifies SUSPEND mode total power = 15.1 mW at 25 °C , and notes that the number is use-case dependent . SUSPEND is the lowest-power mode where clocks are off, unnecessary supplies are off, power-gateable SoC portions are gated, Cortex-A55 is fully power-gated, and DRAM is in self-refresh/retention. If you need an equivalent current for budgeting, use: So 15.1 mW corresponds approximately to: Assumed supply basis Equivalent current 5.0 V input 3.0 mA 3.3 V input 4.6 mA That is an equivalent input current , not a single SoC rail current; the actual processor current is distributed across multiple power rails. If you mean board/SOM deep-sleep current , measured values can be higher and configuration-dependent. One i.MX93 SOM DSM measurement reported 4.04 mA at 5 V , with other optimized/configuration-dependent reports around 1.5 mA to 9.3 mA at 5 V . Use 15.1 mW typical SUSPEND power for the processor spec; convert to mA only against your actual input rail, e.g. about 3.0 mA at 5 V .
View full article
lowlight opensource ai-isp test on imx95   There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) FLOL cidautai/FLOL Lightweight CNN High SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low KinD zhangyhuaee/KinD Retinex + CNN Medium RetinexNet-lite Derived Light CNN Medium EnlightenGAN-lite Derived Small CNN Very High Fast LLIE CNN Various Small CNN High Tested above open-source models with UVC to perform performance evaluation on the exip-os08a20 module with linear mode. Found that SCI(GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexib...) computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed. i.MX Processors Sensor
View full article
关于将自定义 LPDDR5 时序集成到 i.MX95 OEI 和 DDR PHY 固件使用中的说明 您好,NXP团队, 我正在开发一款基于 i.MX9596 处理器和 LPDDR5 内存,并使用 i.MX OEI 引导加载程序的定制电路板。 我使用 MCUXpresso 配置工具 26.3 版为我的定制板生成了 DDR 配置。生成的文件如下: lpddr5_timing.c lpddr5_config.ds 外围设备.c peripherals.h pin_mux.c pin_mux.h 在 OEI 源代码目录 板/mx95lp5/ddr 下,我找到了以下文件: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c 我想确认一下定制LPDDR5板的正确集成流程。 生成的 lpddr5_timing.c是否可以用此文件代替 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c,并更新 OEI_DDR_CONFIG 以引用新的时序文件? XIMX95LPD5EVK19_6400mbps_train_timing_a1.ca 是 NXP 提供的芯片专用训练文件,定制板需要保持不变吗? OEI 使用以下 DDR PHY 固件二进制文件: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin 只要固件版本与生成的 DDR 时序配置匹配,这些相同的固件二进制文件是否可以在定制的 LPDDR5 板上重复使用? 是否只有在启用 LPDDR5 ECC 时才需要启用 ECC 的时序文件?如果定制板上未使用 ECC,则普通时序文件是否足够? 从 EVK DDR 配置迁移到定制 LPDDR5 板时,是否需要重新生成或修改任何其他文件?请告知。 谢谢! Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage 你好, 1. 是的,您需要将 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c 替换为您的自定义配置。 2. 这是该特定硅片版本的一种不同配置,如果这是你的情况,可以将其用作参考。如果您不使用此配置,则可以保持不变。 3. 是的,这些二进制文件可以重复用于类似的配置,如果您不使用 ECC,则普通的计时文件就足够了。 顺祝商祺!
View full article
s32k 148個のLED点滅サンプルコード こんにちは。S32K148 LED点滅のサンプルコードを使用しているのですが、デバッグ中に問題が発生しています。エラー画面のスクリーンショットを共有します。ご確認いただき、考えられる原因とコードに必要な変更点をお知らせください。 Re: s32k 148 Led Blinking example code こんにちは S32DS v3.4でS32K1 SDK RTM 4.0.3のftm_periodic_interrupt_s32k148プロジェクトをデバッグした際にはこの問題に遭遇しませんでした。 この問題の再現方法、例えばどのような変更を加えたかなどを教えてください。もしよければ、修正したプログラムをアップロードしてください。S32K148EVBで原因を素早く確認できます。 よろしくお願いいたします ロビン
View full article
s32k 148 Led Blinking example code Hi, I am using the S32K148 LED blinking example code, but I am facing an issue while debugging it. I will share a screenshot of the error. Please check it and let me know the possible reason and what changes are required in the code. Re: s32k 148 Led Blinking example code Hi  I didn't encounter this problem when debugging the ftm_periodic_interrupt_s32k148 project of S32K1 SDK RTM 4.0.3 in S32DS v3.4. Please tell me how to reproduce this problem, such as what modifications you made. If convenient, please upload the modified program so I can quickly troubleshoot the cause on S32K148EVB. Best Regards, Robin
View full article
Register app for Android and iOS doesn't work I registered my app for Android, But when trying to do the same for iOS it says "Package Name already exists", Which makes no sense, Android and iOS can have the same package name, it's 2 different platforms. App registration Re: Register app for Android and iOS doesn't work Hello @Skel Hope you are doing well. Although they are different platforms, according to UG10044 and UG10045 Chapter 2, the package string must be unique on the NXP Server for getting a TapLinx license string. I apologize for the inconvenience this might cause you. Regards, Eduardo. Re: Register app for Android and iOS doesn't work @EduardoZamora Hi, How can i transfer my iOS app to Android?
View full article
Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hello, currently I am trying to perform an A/B swap on an S32K314HMS microcontroller. The swap is requested via:         /* Reset the job status variable */       SwapJobStatus = SWAP_JOB_PENDING;       /* Set the service descriptor for the HSE request */       swapHseSrvDescriptor.srvId = HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK;       /* Set the request parameters to be sent to Hse Ip layer */       swapHseIpRequest.eReqType = HSE_IP_REQTYPE_ASYNC_POLL;       swapHseIpRequest.u32Timeout = SWAP_TIMEOUT;       swapHseIpRequest.pfCallback = SwapProcessMuChannelResponse;       /* Send the service request to Hse Ip layer */       if (HSE_SRV_RSP_OK != Hse_Ip_ServiceRequest(SWAP_MU_INSTANCE, SWAP_MU_ADMIN_CHANNEL, &swapHseIpRequest, &swapHseSrvDescriptor))       {          result = E_NOT_OK;       } Then swapHseIpRequest.pfCallback (SwapProcessMuChannelResponse) will be reached and the returned HseResponse will be: static void SwapProcessMuChannelResponse( uint8 u8MuInstance, uint8 u8MuChannel,                                              hseSrvResponse_t HseResponse, void* pCallbackParam ) {    if (HseResponse == HSE_SRV_RSP_OK)    {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK;    }    else    {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED;       VStdLib_ConvertUint32ToUint8ArrayBigEndian((uint32)HseResponse, DebugData);    } } #define HSE_SRV_RSP_NOT_SUPPORTED               ((hseSrvResponse_t)0xAA55A11EUL)  /**< @brief The operation or feature not supported. */ This happens sporadically, sometimes the swap works as expected. What could be the reason ? Where can I find the reasons / scenarios when HSE responds with this return code ? This swap is triggered at the end of an update sequence, a couple of minutes after reset/power on (so HSE is 100% initialized). Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hi @AlexI  This is very simple service with no parameters. The only explanation I have is that it is caused by data cache memory. Please make sure that the descriptor is placed in non-cacheable memory. Generally, all data objects used for communication with HSE must be forced to non-cacheable memory because HSE can’t see the cache. Probably not the reason in this case but: if DTCM memory is used, it’s necessary to use backdoor addresses. Normal addresses are visible only for a core which owns the memory. Other bus masters (other cores, DMA, HSE…) can see this memory only via backdoor addresses. Regards, Lukas Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Thank you for this response @lukaszadrapa. I changed the implementation so that swapHseSrvDescriptor & swapHseIpRequest have initial values and are initialized by the linker at startup and not at runtime, now it works. 
View full article
LPC18xxのウォッチドッグリセットを検出できません ウォッチドッグリセットが発生したことを検出する際に問題が発生しています。現在、ユーザーガイドに記載されている手順に従っています。 ウォッチドッグのタイムアウトフラグ(WDTOF)を調べることで、ウォッチドッグがリセット状態を引き起こしているかどうかを判断できます。WDTOFフラグはソフトウェアによってクリアされなければなりません。 デバイスのリセットは正しく行われるものの、その後フラグが設定されていないようです。 LPC4357で似たような問題に関する古い投稿(解決済み:LPC4357:ウォッチドッグリセットを検出できない - NXPコミュニティ)を見かけましたが、LPC18xxのエラッタには何も記載されていませんでした。 LPC18xxも上記と同じ問題を抱えているかどうか確認していただけますか? lpc18xx Re: Cannot detect watchdog reset for LPC18xx こんにちは@ejg 投稿ありがとうございます! どのLPC18xxを使っているのか、具体的に教えていただけますか? また、国旗をレビューしたのはいつですか? lpc18xx_wwdt.hからWWDT_Init関数を呼び出すと割り込みフラグが消去されるため、WDTOFを読み込む必要があります。 Re: Cannot detect watchdog reset for LPC18xx こんにちは、 @carlos_o さん、ご返信ありがとうございます。 私はLPC1837を使用しています。 このフラグは、他のWWDTレジスタとやり取りする前に、起動時にチェックされます。CMSIS SystemInitが完了したら、systickを設定し、このフラグを確認します。 Re: Cannot detect watchdog reset for LPC18xx こんにちは@ejg はい、LPC18xxはLPC43xxと同じ問題を抱えています。 コアリセットの原因を特定するには、LPC18xxユーザーマニュアルのセクション14.5.1「コアリセットの原因を特定する」を参照してください。 BR アリック
View full article
RT1064:引脚配置,用于从内部闪存启动 你好, 这可能听起来像个愚蠢/新手问题,但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源(通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC),但没有列出内部闪存,就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存,但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出,只有两种启动模式可用(QSPI 或 SD 卡),并且还声称不支持 QSPI 启动(参见 2.7 段),因此 SD 卡是唯一的启动源…… 非常感谢您的帮助! i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat , 如 AN12290 中所述,MIMXRT1064 只能从 FlexSPI2 启动,FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存,该接口可用于保存数据或其他功能,但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源,即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC;通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI,并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动,引导设备开关 (SW7) 设置应为: SW7-1 关闭,SW7-2 关闭,SW7-3 打开,SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0,才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时,BOOT_CFG2[2:0]引脚也必须设置为0,以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR, 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好,埃德温, 确实有道理。我感到很困惑,因为外部闪存和内部闪存都是 QSPI 接口的,很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”,并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。
View full article
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
View full article
在 i.MX8M Plus 和 TIM-VX/VSINPU 上,GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。: i.MX8M Plus,aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时,带有 VSINPUExecutionProvider(静态链接到 libtim-vx.so) Vivante OpenCL ICD 已存在且功能正常(Vivante.icd → libVivanteOpenCL.so) 目标: 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试(MLPerf loadgen 测试框架),以便与已收集的现有 NPU(VIP8000Nano)和 CPU 基准测试结果进行比较。 已确认有效的功能: 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备: 设备 0:GC7000UL.6204.0000 设备 1:VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR,没有错误,通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度: ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so(OVXLIB/vsi_nn_* API)。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等)。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex,但是从 OVXLIB/TIM-VX 到该调用没有明显的管道,这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心,而不管设备索引如何。 具体问题: 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标?或者,此版本中的图编译器是否设计为仅限 NPU?我如何验证是否可以以这种方式运行它? 如果 TIM-VX 上游支持 GPU 目标图编译,但 NXP 提供的版本中未启用,是否有构建标志/SDK 元器件可以启用它? 如果无法通过 TIM-VX/ORT 获得支持,NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理(例如通过 OpenCL/OpenVX 层,因为该部分协议栈已被确认功能正常),或者是否有示例应用程序、SDK 组件或参考实现可供我们参考? 我目前是一名学生,正在尝试进行这项实现,并在 GPU 上运行 ORT,请问是否有任何方法或途径可以使用 GPU 进行推理? 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO , 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理,您应该使用 GPU 委托,它允许由 GPU 加速支持的操作,而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南,以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例,可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题,请分享您的模型、BSP 版本以及您正在使用的命令,我将很乐意为您提供进一步的帮助。 此致, 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现,GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU(Arm Mali G310)中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下:VX 代理 ==> TIM-VX ==> GPU/NPU(统一驱动程序) ==> I.MX 8 系列 NPU 和 GPU(GC7000、GC7000L、GC7000UL)。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时,它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作?或者是否有任何手动覆盖或我可以实现的技术,以便我可以手动将编译目标设置为 NPU 或/和 GPU? 非常感谢您的回复。 亲切的问候, IMX8MPLUS #TIM-VX #VX-delegate
View full article
複数のAB_SWAPロケーションにおけるIVTの使用に関する説明(S32K328) こんにちは、NXPチームの皆様、 私はAB_SWAPとHSE_Bを使用してS32K328のメモリレイアウトを作成しているのですが、IVTの位置をどのように扱うべきかについて明確な説明が必要です。 S32K3xxリファレンスマニュアルより: IVTは、フラッシュメモリ内の固定位置に定義された、主要なブートエントリ構造です。 IVTにはアプリケーションイメージ、起動設定、オプションの認証データへのポインタが含まれています。 AB_SWAP構成では、デバイスと設定に応じて、ブートとイメージ選択に関連付けられた複数の定義済みフラッシュ領域/アドレスが存在します。 S32K328のメモリマップを見ると、次のようになっています。 IVT は0x0040_0000 (アクティブバンク) にあります 同じバンク内の0x0060_0000にある別の整列領域は、ブート/優先度処理または一部のレイアウトにおける予約領域に関連しているようです。 質問: IVT配置 IVTは、各バンクのプライマリロケーション(例:0x0040_0000)にのみ存在することが想定されていますか? それとも、IVT(またはIVTに似た構造)が別の住所(例えば 0x0060_0000)にも存在しなければならないという要件(または支持されるケース)はありますか? AB_SWAP内の複数のIVTアドレス RMに複数のIVT関連アドレス(例:0x0040_0000、0x0050_0000、0x0060_0000など)が表示されている場合、これらは何を表していますか? 別々のIVTインスタンス、または 同じIVTコンセプトで使用される代替ブートスロット/優先ロケーション? 二次/代替領域の使用 0x0060_0000のような領域がIVTを含むことが明示的に文書化されていない場合: 予約しておくべきか、 アプリケーションデータやメタデータには安全に使えますか? ベストプラクティス AB_SWAP + HSEセキュアブートシステムにおいて、IVTに関連してこれらの追加のアラインメントされたアドレスをどのように解釈するのが推奨されますか? コンテクスト: デバイス: S32K328 ブートモード: AB_SWAP セキュリティ:セキュアブートが有効HSE_B 目標:正しい起動動作と安全なメモリ割り当て S32K3 #s32k328 Re: Clarification on IVT usage at multiple AB_SWAP locations (S32K328) こんにちは、 @venkatesh-kv 1.利用可能な定義済みアドレスにIVTを1つ配置すれば十分です。必ずしも0x40_0000のようなプライマリロケーションである必要はありません。有効なIVTを指定された順番で検索するのはSBAFの責任です。 IVT のアップデート中に何らかの問題が発生した場合に備えて、2 番目の IVT をバックアップとして使用するオプションがあります。これは通常、IVT のブート構成ワードの BOOT_SEQ ビットによってセキュアブートを有効にする際に行われます。 2. AB_SWAP モードの S32K328 には、IVT の可能な位置が 3 つあります: 0x40_0000、0x60_0000、0x1000_0000。SBAFは有効なIVTをこの順番で検索します。住所が小さいほど、優先順位が高くなります。例えば、0x40_0000に有効なIVTが存在する場合、SBAFはこのIVTを使用し、他の場所をチェックしません。 3. エリアを予約しておく必要はなく、コードやデータ用に利用できます。 4. このユースケースでは、前述のバックアップとして他のIVTロケーションを利用することができます。また、Secure Boot アプリケーションノートの「6.2 Update IVT」セクションでも説明されています。 ダウンロード可能: https://www.nxp.com/products/S32K3 アプリケーションノートはこちらでご覧いただけます: ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511) 関連するデモプロジェクトはこちらからダウンロードできます: Design Resources - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310) よろしくお願いいたします。 ルーカス
View full article
KW47におけるELEMUとLTCの比較:LTCには性能以外に何か利点があるのか? こんにちは。 KW47プラットフォーム上のELEMU(EdgeLockメッセージングユニットドライバー)とLTC(LP信頼暗号)の使用違いについてお聞きしたいです。 私の現在の理解は以下のとおりです。 エレム ・暗号処理は専用のセキュリティコアを要求することで行われ、鍵を隔離された安全な環境に保存できるため強力な改ざん耐性を提供します。 ・セキュリティコアとの通信が必要なため、非常に厳しいレイテンシ要件を持つアプリケーションには適さない場合があります。 ・LTCで利用可能なすべての暗号アルゴリズムをサポートし、さらにECDHなどLTCが扱えないアルゴリズムもサポートしています。 ・セキュリティ関連サービス(セキュアブート統合など)も利用可能です。 したがって、私の理解では、ELEMUは高度なセキュリティを必要とする暗号処理により適していると理解しています。 LTC ・暗号操作はLTCハードウェアアクセラレータレジスタを直接制御することで実行されるため、非常に低コストかつ高性能です。 ・対応アルゴリズムはAES、DES、ハッシュなどのハードウェアアクセラレーション関数に限定されています。 ・鍵は安全で隔離された環境に保管できないため、改ざん抵抗レベルはセキュリティコアが提供するものより低い。 したがって、私の理解ではLTCはレイテンシに敏感なプロセッシングやセッションキーのような一時キーを使ったユースケースにより適していると理解しています。 上記の理解が正しければ、LTCがELEMUに対して最大の利点はパフォーマンスやレイテンシであり、タイミング要件を満たせばLTCで実現できることはすべてELEMUを通じて実現できると言ってもよいでしょうか? あるいは、機能的な制限や対応アルゴリズム、ハードウェアアクセス制限、その他の考慮点で、LTCが特定のシナリオで好まれたり必須の選択肢になるのでしょうか? ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 あなたの調子が良いといいのですが。   ELEメッセージングユニット(ELE_MU)は、アプリケーションコアとEdgeLock Enclave(ELE)セキュリティコア間の通信メカニズムです。このインターフェースを通じて、ホストプロセッサはELEに暗号およびセキュリティ関連サービスを要求できます。暗号操作に加え、ELEは鍵生成、インポート/エクスポート、安全な鍵保存、非揮発性保存のための暗号化鍵ブロブ生成などの安全な鍵マネジメント機能を提供します。 より詳細な情報は KW47セキュリティリファレンスマニュアル 第9章に記載されています。 LTC(LP Trusted Cryptography)ドライバは、KW47ハードウェア暗号加速器への直接アクセスを提供します。この方法は、アプリケーションがELE_MUのようにセキュリティコアを通るのではなく、ハードウェアアクセラレータAPIと直接やり取りするため、ソフトウェアのオーバーヘッドが低減されます。LTCハードウェアはAES、DES、HASH、PKHAなどのアルゴリズムの加速をサポートしています。( KW47 APIリファレンス・マニュアルを参照) つまり、あなたの理解は概ね正しいですが、最終的には実装要件によります。低レイテンシと最小限のソフトウェアオーバーヘッドを主な目標にしているなら、長期介護(LTC)が望ましい選択肢です。しかし、セキュリティ境界やキーライフサイクル管理が重要な考慮事項であれば、一般的にELE_MUがより良い選択肢です。 よろしくお願いします、 ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 お返事ありがとうございます。 私の理解がおおむね正しいと分かって安心しました。 LTCとELE_MUのレイテンシの違いについてもう一つ質問があります。 実際の性能差は、使用されている暗号アルゴリズム、セキュリティコアとのやり取り回数、処理されるデータのサイズなどの要因によって異なると理解しています。具体的なユースケースの詳細な条件を提供できないため、予想されるレイテンシの違いの大まかなガイドラインや一般的な特徴を教えていただけるとありがたいです。 例えば、セキュリティコアとの通信のオーバーヘッドは通常、実際の暗号処理時間よりもはるかに大きく、その結果、LTCの数倍、あるいは数十倍の遅延が発生するのでしょうか? それとも、ほとんどの実用的なCASEでは、暗号処理時間自体が全体の実行時間を支配し、総処理時間の割合で見ると追加のオーバーヘッドは比較的小さくなELE_MUのでしょうか? ELE_MUのパフォーマンスへの影響が顕著になる時期を理解するためには、大まかなガイドラインや定性的な比較だけでも非常に役立つだろう。 ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 不便をおかけして申し訳ありません。現時点では、ELE_MUとLTCのレイテンシ差を比較したり定性的に説明したドキュメントが存在しません。 ELE暗号エンジンは速度よりも安全な実行を優先して最適化されていますが、具体的な性能指標については、特定の目標条件下でKW47ハードウェア上で直接測定することをお勧めします。 KW47におけるELE機能や暗号操作に関しては、最も関連するガイダンスがKW47セキュリティリファレンスマニュアルに記載されています。 よろしくお願いします、 アナ・ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 ご回答ありがとうございます。 ELE_MUとLTCのレイテンシを比較したり、レイテンシー特性を定性的に説明したりするドキュメントは存在しないことは理解しています。 その場合は、実際のKW47ハードウェアでの性能を評価し、レイテンシを直接測定して両実装の違いをよりよく理解します。 ご協力ありがとうございました。 よろしくお願いします、
View full article
ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi. I would like to ask about the differences in usage between ELEMU (EdgeLock Messaging Unit Driver) and LTC (LP Trusted Cryptography) on the KW47 platform. My current understanding is as follows: ELEMU ・Cryptographic operations are performed by requesting the dedicated Security Core, providing strong tamper resistance because keys can be stored in an isolated secure environment. ・Since communication with the Security Core is required, it may not be suitable for applications with very strict latency requirements. ・It supports all cryptographic algorithms available through LTC, and additionally supports algorithms that LTC cannot handle, such as ECDH. ・Security-related services such as secure boot integration can also be utilized. Therefore, my understanding is that ELEMU is better suited for cryptographic operations that require a high level of security. LTC ・Cryptographic operations are executed by directly controlling the LTC hardware accelerator registers, resulting in very low overhead and high performance. ・Supported algorithms are limited to hardware-accelerated functions such as AES, DES, HASH, etc. ・Keys cannot be stored in a secure isolated environment, so the level of tamper resistance is lower than that provided by the Security Core. Therefore, my understanding is that LTC is better suited for latency-sensitive processing or use cases involving temporary keys such as session keys. If the above understanding is correct, is it fair to say that the primary advantage of LTC over ELEMU is performance/latency, and that if timing requirements can be met, everything that can be accomplished with LTC can also be accomplished through ELEMU? Or are there any functional limitations, supported algorithms, hardware access restrictions, or other considerations that would make LTC the preferred or required choice in certain scenarios? Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, Hope you are doing well.   The ELE Messaging Unit (ELE_MU) is a communication mechanism between the application core and the EdgeLock Enclave (ELE) security core. Through this interface, the host processor can request cryptographic and security-related services from ELE. In addition to cryptographic operations, ELE provides secure key management capabilities, including key generation, import/export, secure key storage, and encrypted key blob generation for non-volatile storage. More detailed information can be found in KW47 Security Reference Manual Chapter 9. The LTC (LP Trusted Cryptography) driver provides direct access to the KW47 hardware cryptographic accelerator. This path offers lower software overhead because the application interacts directly with the hardware accelerator APIs rather than communicating through the security core like ELE_MU. The LTC hardware supports acceleration for algorithms such as AES, DES, HASH, and PKHA. (See KW47 API Reference Manual) So your understanding is generally correct, it will ultimately depend on your implementation requirements. If low latency and minimal software overhead are your primary goals, LTC would be the preferred option. But if security boundaries and key lifecycle management are important considerations, ELE_MU is generally the better choice. Best regards, Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your reply. I am glad to know that my understanding is generally correct. I have one additional question regarding the latency difference between LTC and ELE_MU. I understand that the actual performance difference depends on factors such as the cryptographic algorithm being used, the number of interactions with the Security Core, and the size of the data being processed. Since I am not able to provide detailed conditions for a specific use case, I would appreciate even a rough guideline or general characterization of the expected latency difference. For example, is the overhead of communicating with the Security Core typically much larger than the actual cryptographic processing time, resulting in latency that is several times or even tens of times higher than LTC? Or, in most practical use cases, does the cryptographic processing time itself dominate the overall execution time, making the additional overhead introduced by ELE_MU relatively small when viewed as a percentage of the total processing time? Even a high-level guideline or qualitative comparison would be very helpful for understanding when the performance impact of ELE_MU becomes significant. Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, I apologize for the inconveniences, currently there is no available documentation that provides a comparison or qualitative guideline characterizing the latency difference between ELE_MU and LTC. While the ELE cryptographic engines are optimized for secure execution rather than speed, for specific performance metrics, direct measurement on KW47 hardware under the specific target conditions would be recommended. Regarding ELE functionality or cryptographic operations on KW47, the most relevant guidance is provided in the KW47 Security Reference Manual. Best regards, Ana Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your response. I understand that there is no available documentation that compares the latency of ELE_MU and LTC or describes their latency characteristics qualitatively. In that case, I will evaluate the performance on actual KW47 hardware and measure the latency directly to gain a better understanding of the differences between the two implementations. Thank you again for your help. Best regards,
View full article
RDDRONE-BMS772开发板配件 RDDRONE-BMS772开发板配件 抱歉,你没听懂我的意思。我目前的研究是关于电池状态估计,这需要测量真实电池的电压、电流和温度数据。因此,我不需要电池模拟器;我需要的是真正的电池。所以,我需要一块与我的开发板兼容的电池,以及一个特定型号的配套电池充电器。另外,链接中提到的 PEMicro 适配器和 SEGGER J-Link Mini 调试器是调试或编程开发板所必需的硬件吗?开发板能否直接连接到电脑进行调试和编程?这些适配器和调试器在市场上可以买到吗?此外,除了您提到的硬件之外,开发板是否还有其他必要的硬件元器件?如果是,请列出详细的配件类别及其对应的型号。非常感谢您对这些问题的详细解答。 抱歉,你没明白我的意思,我目前的研究是关于电池状态估计的,需要测量真实电池的电压和温度数据,所以我不需要电池模拟器,我需要真实的电池,所以我需要改装开发板的电池和对应电池充电器的具体型号;以及那个链接里提到的PEMicro适配器以及SEGGER J-Link迷你调试器是开发板或者烧录算法必须的硬件吗?开发板不能直接连接到电脑上进行调试和烧录程序吗?这些调试器和调试器在可以买到吗?还有,开发板除了你提到的这几个硬件以外还必须硬件吗?如果有的话请帮我列出详细的配件类别及其对应的型号;请您详细解答一下这些疑问,万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 亲爱的 Fan007, 对于电池状态估计研究,RDDRONE-BMS772 支持真正的 3S 至 6S 锂离子/锂聚合物电池组(6 V 至 26 V),并且不需要特定的电池型号。所选电池必须包含电池平衡连接器。 需要使用与所选电池化学成分和电芯数量兼容的充电器。RDDRONE-BMS772 无需专用的 电池管理系统 通信接口,因为必要时它可以断开充电路径。 对于固件开发和调试,NXP 建议使用外部 SWD 调试器,例如 PEMicro Universal Multilink 或 SEGGER J-Link Mini。RDDRONE-BMS772 没有板载 USB 调试接口,因此需要使用外部调试器。这些调试器在市场上均有销售。 对于电池特性分析和 SOC/SOH 算法开发,强烈建议使用可编程电子负载 (E-load) 进行受控充放电测试。   最诚挚的问候, 约瑟夫
View full article
IMXRT 1180 系列 您好,NXP团队, 我们目前正在评估恩智浦半导体微控制器在空间机载计算机 (OBC) 应用中的使用情况。 最初,我们考虑的是i.MX RT1170 (MIMXRT1170) ,在评估过程中,我们注意到 NXP 的文档明确指出该器件采用28nm FD-SOI 技术制造。由于半导体工艺技术是我们应用的关键评估标准,因此我们现在也对评估i.MX RT1180系列感兴趣。 在继续进行下一步之前,我们希望了解i.MX RT1180的制造工艺: i.MX RT1180 是否也像 i.MX RT1170 一样,采用28nm FD-SOI 技术制造? 如果没有,能否请您提供RT1180所采用的工艺技术信息? 是否有任何官方文档或产品简介提及该设备的制造节点和工艺技术? 我们查阅了公开的文档,但未能找到有关 RT1180 工艺技术的官方声明。 这些信息对我们的内部技术评估和认证活动非常重要,我们非常感谢您的指导。 感谢您的支持。 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的快速回复,并确认i.MX RT1180采用28nm FD-SOI 技术制造。 我们希望您能再澄清一点。请问这是否适用于整个 i.MX RT1180 系列,包括以下设备? i.MX RT1186 i.MX RT1187 i.MX RT1189 如果 RT1180 系列的所有成员都采用相同的 28nm FD-SOI 工艺制造,则此信息将有助于我们进行外围和特征分析,以确定最适合我们应用的设备。 希望您能确认一下。 感谢您的支持。 此致, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 非常感谢您对我们产品的关注以及对我们社区的使用。 是的。i.MX RT1180 采用 28 纳米 FD-SOI 技术。 抱歉,目前还没有任何公开的官方文件或产品简介明确提及该设备的制造节点或工艺技术。 希望对你有帮助 顺祝商祺! 5月 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的及时回复和确认。这些信息非常有帮助,非常感谢。 根据您的确认,我们将继续进行评估,并将此视为对该制造技术的确认。 感谢您的支持。 问候, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 感谢您的反馈。 是的,我查阅了 i.MX RT1186、i.MX RT1187 和 i.MX RT1189 的相关信息。它们均采用相同的 28nm FD-SOI 工艺技术制造。   希望对你有帮助 顺祝商祺! 5月
View full article
How to measure CPU load for S32G399 baremetal application on S32DS Hi everyone, I would like to know how to measure CPU load for S32G399 while it is running.  Background: my S32G399 project is a four-core M7 baremetal one with one ELF file which is developed on S32DS3.5.10. I use a custom bootloader to boot up A53 and M7 which has been implemented. My request is measuring CPU load on M7 end. I have S32 Debug Probe on hand, so I can attach to my M7 application while it is running. However, I don't know the detailed steps/way to measure the load. I even don't know if it is feasible only using S32 Debug Probe to reach this goal.  Hopefully someone can provide relevant document or some guidance. Thank you. Re: How to measure CPU load for S32G399 baremetal application on S32DS Hello, @Yang_C  Thanks for your post. 1. From my understanding, solely depend on the debugger may not obtain run time CPU load accurately. 2. It is possible to add some code to your own application, for example, to enable timer, then measure the time executing your main task, at last. calculate the portion of (executing time)/(running time) to evaluate the rough CPU load. BR Chenyin Re: How to measure CPU load for S32G399 baremetal application on S32DS Thank you very much. I will try code-side measuring.
View full article
PN7160 在内核版本 6.6.92 下无响应 我们的团队已将PN7160移植到内核6.6.92 , 但它目前无法读取任何NFC标签。 以下是我们的DUT信息: 内核版本: 6.6.92 操作系统: Yocto Scarthgap PN7160 驱动程序补丁文件: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch(克隆自 NFC GitHub 项目并修改以适配内核 6.6) nfcDemoApp 配方: recipes-nfc.7z(从 NFC GitHub 克隆并修改以修复构建错误) 内核日志: nfc-log.txt 您能否提供一些建议,帮助我们解决这个问题? 回复: PN7160 no response with kernel 6.6.92 请在 libnfc-nxp.conf 中将 LOGLEVEL 设置为 0x03。然后把运行 nfcDemoApp 时的日志发给我。请同时将 libnfc-nci.conf 和 libnfc-nxp.conf 文件发送给我,以便我检查。 回复: PN7160 no response with kernel 6.6.92 感谢您的回复。 日志文件和配置文件(libnfc-nci.conf 和 libnfc-nfc.conf)已附上。 您能给我们一些建议吗?
View full article