Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
PWMキャプチャはfrdm_mcxw72ボードでは動作しません こんにちは、 frdm_mcxw72 ボードで pwm キャプチャ サンプルを試してみましたが、残念ながらシリアル ツールのプリント メッセージには「 capture cycle err -134 」としか表示されません。frdm_mcxw72ボードのPTA21ピンには、1kHz、デューティサイクル50%のPWM信号が注入されているはずです。 デモケースからプロジェクトファイル全体をインポートしましたが、オーバーレイファイルだけを追加しただけで変更はありません。以下にオーバーレイファイルの設定があります。 anliu114036_0-1783501416708.png なぜ正しい印刷情報がないのか、その理由を調べていただけますか?前もって感謝します! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 あなたの調子が良いといいのですが。どのZephyrリポジトリを使っているのか、教えていただけますか? また、あなたは提示された例を参考にしていますか?何か変更しましたか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん リポジトリのバージョンはV4.4.1.0です。以下は私の手順です 1. リポジトリからキャプチャ例のアプリケーションをインポートする anliu114036_0-1783644698775.png 2. 最初のメッセージで投稿したオーバーレイファイルの内容であるDTSオーバーレイファイルをボードフォルダに追加します。 3. 手元にある frdm_mcxw72 ボードにビルドしてフラッシュすると、プリントメッセージは次のようになります。 「キャプチャサイクルエラー」、PWM信号を注入していないのでボードの状態は問題ないように見えますが、PTA21ピンにPWM信号を注入した後もプリントメッセージは同じです。     Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 どのリポジトリを使っているのか教えていただけますか? アップストリームとダウンストリームのどちらを使用していますか? また、そのサンプルコードは、修正なしでそちら側でも正常に動作しますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルド リポジトリのバージョンはこちらです anliu114036_0-1783902527295.png オーバーレイファイルだけを更新しますが、このファイルがなければビルドが成功しません。 よろしくお願いいたします! Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、 Upstreamを使っているのか、それともDownstreamを使っているのか、教えていただけますか? よろしくお願いいたします。 リカルド Re: PWM Capture can't work in frdm_mcxw72 board こんにちは、リカルドさん すみません、ここでいう「上流」や「下流」が何なのかよく理解できませんでした。下流側であるべきだと思う。それとも別の説明を変えてもらえますか?
記事全体を表示
IMXRT LPUART 非阻塞传输 API 使得错误处理变得困难。 您好, 我一直在研究 LPUART 的“传输”API,用于基于中断的非阻塞传输。它似乎很好地封装了所有“正常情况”下的 LPUART 中断处理等,并提供了一个良好的高级 API,用于在数据准备就绪时接收数据(即)。处理 IDLE、RX 就绪、TX 完成等状态)。然而,这使得处理 UART 错误变得非常困难。 LPUART_TransferHandleIRQ 函数内部没有错误处理,并且在 fsl_lpuart.c 中紧随其后的是一个虚假的空 LPUART_TransferHandleErrorIRQ 函数,其中包含注释“由用户实现”。这看起来完全是半成品。 处理 UART 错误的唯一方法似乎是覆盖默认的 LPUARTx_IRQHandler 函数,这样就不需要调用 LPUARTx_RX_DriverIRQHandler(或 TX),而是需要调用自己的函数来处理错误,并将“正常情况”中断传递给原始的 LPUARTx_RX/TX_DriverIRQHandler,以便它可以调用 LPUART_TransferHandleErrorIRQ。 此外,您还需要在传输 API 之外通过调用 LPUART_EnableInterrupts 来启用这些错误中断,并在错误处理中调用 LPUART_DisableInterrupts 并处理清除它们等操作。 这样处理错误似乎很麻烦。为什么这项功能没有内置到转账 API 中? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 感谢您提供的详细反馈。我理解 SDK 可能有点含糊不清,因为这些 SDK 的目的是为每个外围设备功能提供常见的用例。我们也一直在努力改进我们的 API,这也要感谢像这样的建议。感谢您的建议,我们希望 LPUART 的错误处理功能能在未来的版本中得到实现。 另一方面,请问您想处理哪些具体的错误状态,以及您使用的是哪款设备?有了这些信息,我可以向您推荐一些与这些错误状态相关的文档,这些文档可能会对您的实施有所帮助。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 所有可能的错误。这几乎适用于所有具有传输 API 但没有错误处理的外围设备(SPI、I2C 等)。IMXRT1172 上的 LPUART 存在帧错误、奇偶校验错误和噪声错误,这些错误无法得到处理。遗憾的是,目前所有这些外围设备都需要一些破解才能处理使用传输 API 时出现的错误。我必须覆盖默认的 IRQ 处理程序,以便在调用 SDK 处理程序之前检查错误。 谢谢! -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 我知道这可能需要额外的开发时间,对此我们深表歉意,我们将继续努力改进我们的SDK。作为参考,您可以查看 SDK(版本 26.6)中名为“LPUART_TransferHandleIRQ”的函数的以下结构,并根据您的应用程序需要实现类似的恢复流程。 Habib_MS_1-1784062752001.png BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 , 如果您还有其他问题,请告诉我。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 是的,我已经实现了类似的功能。谢谢你发来这个。
記事全体を表示
S32DS 3.4 compilation failed when importing adc_example_s32k118. make: *** [src/main.o] Error 1 make: *** Waiting for unfinished tasks.... In file included from ../Project_Settings/Startup_Code/exceptions.c:30: /home/xysun/NXP/S32DS.3.4/S32DS/software/PlatformSDK_S32K1_2022_02/SW32K1_RTD_4_4_1_0_1_D2202/Base_TS_T40D2M10I1R0/include/Mcal.h:62:10: Fatal error: Soc_Ips.h: No such file or directory. 62 | #include "Soc_Ips.h" | ^~~~~~~~~~~ Compilation failed. Re: S32DS 3.4导入adc_example_s32k118编译失败 1.jpg periherals of ConfigTools is “SoC_Ips.h”,but RTD and generate/include source code use #include "Soc_Ips.h" then linux strictly distinguish between uppercase and lowercase letters,this is a bug of S32 IDE?should manual modification the file name of generate/include/SoC_Ips.h to generate/include/Soc_Ips.h,then compile succeed Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu For your new question:"The window installation is OK, but the Ubuntu installation fails. I can't found reason" Could you please create a new topic , because I know nothing about Ubuntu. Re: S32DS 3.4导入adc_example_s32k118编译失败 The window installation is OK, but the Ubuntu installation fails. I can't found reason Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu I can't think of other possible reasons. I can only suggest that you reinstall the IDE and RTD. Try not to use Chinese and try again. Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent look,version is ok 2024-03-29 14-55-50 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu please show me your S32 DS version like picture below, you can see the RTD 1.0.1 require "Update 1" and above version installed. Senlent_1-1711693579879.png Senlent_0-1711693544628.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent, have this error 2024-03-29 11-18-54 的屏幕截图.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi senlent Maybe the component function does not exist. How to install this function? 2024-03-29 10-32-55 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu According to the log file you provided, the Soc_Ips.h file is missing from your current project, but in fact the file will be generated in your project directory after you update the code. So my conclusion is that you probably didn't generate the configuration code correctly Senlent_0-1711674664635.png Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi Senlent Already updated, but still the same problem 2024-03-28 18-22-49 的屏幕截图.png   Re: S32DS 3.4导入adc_example_s32k118编译失败 Hi@yshenu please click "Update code" to generate config file before building it. Senlent_0-1711618540617.png
記事全体を表示
i.MX95 - Unable to perform the SOC reset from A55 core Hello Experts, I am working on i.MX95 and would like to perform the SOC reset (including M55 and M7 cores) from the A55 core. With reference to section 18.2 in https://www.nxp.com/docs/en/user-guide/UG10163.pdf CRRM also needs a cold reboot (reboot SoC) to trigger the mode switch, for example, from recovery downloading to recovery installation. To meet it, we implement PSCI RESET2 in ATF, and use "reboot" rather than "reset" in U-Boot for this SoC reset. The kernel also adds the imx-sm-reset driver to call PSCI RESET2 to ATF. User application needs to use the following syscall to trigger the board reset. syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "board_reset"); I have created a test application(In attachments) with this syscall included to trigger SOC reset from A55 core. However upon execution, it only resets A55 core and other M33 and M7 cores remain intact. If someone has tried this before and reset the complete SOC, kindly let me know Thanks in Advance ! BR, Arun Kumar  Re: i.MX95 - Unable to perform the SOC reset from A55 core Hello, When using the SCMI protocol to manage SoC regional resets, SM must handle the associated LP handshakes generated by the regional reset. In addition, some regional resets such as A55 have dependencies on each other. For example, issuing a A55Cx reset can only be issued in conjunction with an overall A55 regional (non-cooperative) reset. Reset from bash using reboot command has the same behavior, if a complete SoC restart is required, including all processing domains, a watchdog-triggered reset or a PMIC-driven power cycle may be required. Best regards.
記事全体を表示
Regarding 8M Plus Real time Accuracy Hi,  We would like to lean more about 8M Plus capabilities regarding its real-time applications. Are there any test reports or related materials available concerning TSN or real-time performance, or jitter? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy Area Available material What it contains Real-time CPU/RTOS latency Harpoon User’s Guide Measured real-time latencies on i.MX 8M Plus / Zephyr , including IRQ latency and task latency in ns. Example results: no-load IRQ latency min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns ; task latency = 2,583 / 2,671 / 13,041 / 6,045 ns . Under Linux CPU + memory load, IRQ latency = 625 / 798 / 4,250 / 4,674 ns , and task latency = 2,583 / 2,670 / 14,333 / 10,407 ns . Real-time benchmark method Harpoon User’s Guide — rt latency application Defines the benchmark as the time delta between hardware IRQ events and software actions, measured with a hardware timer and sub-microsecond precision. TSN capability i.MX 8M Plus product / reference material i.MX 8M Plus includes dual Gb Ethernet, with one Ethernet supporting TSN, and uses the integrated 800 MHz Arm Cortex-M7 for industrial real-time control. TSN hardware standards i.MX 8M Plus Reference Manual TSN support includes IEEE 802.1Qbv Time-Aware Shaper , 802.1Qav Credit-Based Shaper , IEEE 1588v2 PTP , and the Ethernet block implements 802.1Qbv-2015 , 802.3br , and 802.1Qbu frame preemption-related TSN functions. TSN test / validation environment Real-Time Edge User Guide Describes a TSN test environment for evaluating i.MX 8M Plus TSN capabilities, including traffic generation/analysis and monitoring of latency, jitter, and synchronization accuracy. TSN jitter / latency example Real-Time Edge User Guide — TSN endpoint sample app Provides TSN endpoint statistics including traffic latency min/mean/max and notes latency around 503 µs with latency jitter around 300 ns in the shown example. TSN application demo AN13588 Demonstrates a GenAVB/TSN real-time control application. It describes a 2 ms cycle , a 400 µs reserved/guaranteed control-traffic window , and a statistics thread for scheduling, processing timing, traffic correctness, and latency. TSN 802.1Qbv demo AN13995 Demonstrates TSN 802.1Qbv using i.MX 8M Plus and explains how time-aware shaping uses fixed repeating cycles to provide deterministic latency; it also includes Linux  tc  /  taprio  configuration examples.   Re: Regarding 8M Plus Real time Accuracy @yipingwang  Thank you for providing the information. Could you also please provide us with information about the iMX8M Plus EVK? Thanks. Re: Regarding 8M Plus Real time Accuracy We understand that no public "real-time performance report" has been officially released for i.MX95 EVK. However, NXP does internally perform real-time benchmarking on i.MX95 platforms. Internal benchmark documents indicate that cyclictest and EtherCAT performance evaluations have been executed on i.MX95 LPDDR5 EVKs running Real-Time Edge software with PREEMPT_RT Linux. Reported examples include a maximum cyclictest latency of approximately 38 µs during a 6-hour stress-ng test and EtherCAT filtered maximum jitter of approximately 12 µs under the documented test conditions. Because real-time performance depends strongly on BSP version, kernel configuration, CPU isolation, workload, and network traffic, these values should be considered reference measurements rather than guaranteed application-level limits.   Please refer to https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf as supported benchmarking platforms and provide detailed cyclictest, stress, and rt_latency procedures. Re: Regarding 8M Plus Real time Accuracy Our distributor informed us that there is currently no official performance report available for the NXP i.MX95 EVK regarding real-time performance or jitter. However, they also provided documentation describing the testing methodology (e.g., cyclictest) for evaluating real-time latency. This leads to some confusion on our side. Since a standardized testing methodology exists, we assume that such tests must have been performed internally—at least on the reference EVK platform. Therefore, we would like to clarify: Has NXP conducted any internal measurements of real-time performance (e.g., latency, jitter) on the i.MX95 EVK? If so, are there any reference or baseline results that could be shared? We understand that real-time performance may vary depending on system configuration and workload. However, even a baseline result under controlled conditions (e.g., default BSP, minimal load) would be very helpful for initial evaluation. Thank you for your support. hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (Real-Time Edge Software User Guide) (https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) . Real-Time Edge Software (most relevant) NXP's Real-Time Edge Software officially supports the i.MX8M Plus EVK and includes: PREEMPT_RT Linux TSN stack IEEE 802.1AS (gPTP) synchronization TSN traffic shaping and scheduling EtherCAT, OPC-UA, CAN-related industrial protocols Heterogeneous real-time operation using Cortex-A53 + Cortex-M7 The internal document REALTIMEEDGEUG states that Real-Time Edge Software provides: Real-time networking (TSN) Real-time Linux (PREEMPT_RT) Pure RTOS/Bare-metal options Jailhouse partitioning Industrial protocol support Support for i.MX 8M Plus LPDDR4 EVK NXP Application Note AN13995 – TSN 802.1Qbv Demonstration using i.MX 8M Plus The Real-Time Edge Six Pack materials describing PREEMPT_RT + TSN support Re: Regarding 8M Plus Real time Accuracy @yipingwangThank you very much for the information you provided.
記事全体を表示
adc_example_s32k118をインポートした際に、S32DS 3.4のコンパイルが失敗しました。 make: *** [src/main.o]エラー1 make: *** 未完了のタスクを待機中... ../Project_Settings/Startup_Code/exceptions.c:30 からインクルードされたファイル内: /home/xysun/NXP/S32DS.3.4/S32DS/software/PlatformSDK_S32K1_2022_02/SW32K1_RTD_4_4_1_0_1_D2202/Base_TS_T40D2M10I1R0/include/Mcal.h:62:10:致命的なエラー: Soc_Ips.h: そのようなファイルまたはディレクトリはありません。 62 | #include "Soc_Ips.h" | ^~~~~~~~~~~ コンパイルに失敗しました。 Re: S32DS 3.4导入adc_example_s32k118编译失败 1.jpg ConfigTools の周辺機器は「SoC_Ips.h」ですが、RTD およびソースコードの生成/組み込み #include "Soc_Ips.h" それからLinuxは大文字と小文字を厳密に区別します。これはS32 IDEのバグです。generate/include/SoC_Ips.hのファイル名を手動で修正してgenerate/include/Soc_Ips.hにしてからコンパイル成功すべきでしょうか? Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、@ yshenu 新しい質問に対して:「Windowsのインストールは問題ないのですが、Ubuntuのインストールは失敗します。理由が見つからない」 Ubuntuについては何も知らないので、新しいトピックを作成してもらえますか? Re: S32DS 3.4导入adc_example_s32k118编译失败 Windowsのインストールは問題なく完了するが、Ubuntuのインストールは失敗する。理由が見つからない Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、@ yshenu 他に考えられる理由が思い浮かびません。IDEとRTDを再インストールすることをおすすめします。中国語を使わずに、もう一度試してみてください。 Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlent 見て、バージョンは問題ない 2024-03-29 14-55-50 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu 下の写真のように、あなたのS32 DS版を見せてください。RTD 1.0.1は「Update 1」以上のバージョンをインストールする必要があります。 Senlent_1-1711693579879.png Senlent_0-1711693544628.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlentさん、 このエラーが発生しています 2024-03-29 11-18-54 的屏幕截图.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、senlent コンポーネント関数が存在しない可能性があります。この機能をインストールするにはどうすればよいですか? 2024-03-29 10-32-55 的屏幕截图.png     Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu ご提供いただいたログファイルによると、Soc_Ips.h現在のプロジェクトにファイルが見つかりませんが、実際にはコードを更新するとプロジェクトディレクトリにファイルが生成されます。ですので、おそらく設定コードを正しく生成していないのだと思います Senlent_0-1711674664635.png Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは、センレント 既にアップデート済みだが、依然として同じ問題が発生している。 2024-03-28 18-22-49 的屏幕截图.png   Re: S32DS 3.4导入adc_example_s32k118编译失败 こんにちは@yshenu ビルド前に「コードの更新」をクリックして設定ファイルを生成してください。 Senlent_0-1711618540617.png
記事全体を表示
i.MX95 - A55コアからSOCリセットを実行できません こんにちは、専門家の皆様。 私はi.MX95を扱っており、A55コアからSOCリセット(M55およびM7コアを含む)を実行したいと考えています。 https://www.nxp.com/docs/en/user-guide/UG10163.pdfのセクション 18.2 を参照してください。 CRRM also needs a cold reboot (reboot SoC) to trigger the mode switch, for example, from recovery downloading to recovery installation. To meet it, we implement PSCI RESET2 in ATF, and use "reboot" rather than "reset" in U-Boot for this SoC reset. The kernel also adds the imx-sm-reset driver to call PSCI RESET2 to ATF. User application needs to use the following syscall to trigger the board reset. syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "board_reset"); このシステムコールを含めたテストアプリケーション(添付ファイル内)を作成し、A55コアからのSOCリセットをトリガーしています。しかし、実行時にはA55コアのみがリセットされ、他のM33およびM7コアはそのまま残ります。 以前にこれを試してSOC全体をリセットした方がいらっしゃいましたら、ぜひ教えてください。 よろしくお願いいたします! BR、 アルン・クマール Re: i.MX95 - Unable to perform the SOC reset from A55 core こんにちは、 SCMIプロトコルを使用してSoCのリージョンリセットを管理する場合、SMはリージョンリセットによって生成される関連するLPハンドシェイクを処理する必要があります。さらに、A55などの一部の地域リセットは、互いに依存関係を持っています。例えば、A55Cxリセットの発行は、全体のA55地域(非協力)リセットと同時に発行される場合のみ可能です。 再起動コマンドによるbashからのリセットも同様の動作をしますが、SoCの完全な再起動(すべてのプロセッシングドメインを含む)が必要な場合は、ウォッチドッグトリガーリセットやPMIC駆動の電源サイクルが必要になることがあります。 よろしくお願いいたします。
記事全体を表示
Example SJA1110 FreeRTOS lwIP S32G-VNP-RDB2 S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board S32G-VNP-RDB2 * to enable ping from the command window, from all applicable ports * *ping 192.168.0.210 * *Pinging 192.168.0.210 with 32 bytes of data: *Reply from 192.168.0.210: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.210: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - SW10[1]: On, SW10[2]: Off * - SW12[1]: On, SW12[2]: Off * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Changed IP address to 192.168.0.210 * - Added DIO * - Added nvm_metadata * - MAC learning is disabled * - The example includes two flash images for Port 4 SGMII speed * configuration towards the S32G: * - flash_image_2G5.bin (tested) * - flash_image_1G.bin (not tested) * * main.c * - Updated only the header * device.c * - Added LED routines * test.c * - Removed code that shuts down the TCP/IP stack after its predefined timeout * - Added debug stuff * - Commented out the code that initializes 2nd switch * * ----------------------------------------------------------------------------- * Test HW: S32G-VNP-RDB2 REV E * MCU: SJA1110A * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
Example SJA1110 FreeRTOS lwIP SJA1110-MGS-EVM S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board SJA1110-MGS-EVM * to enable ping from the command window, from all applicable ports * *ping 192.168.0.200 * *Pinging 192.168.0.200 with 32 bytes of data: *Reply from 192.168.0.200: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - All jumpers in default positions, except J76 - open * - SW2.7 ON and SW2.6 OFF -> 0b01 - NVM Boot - SPI Flash * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Added DIO * - Added nvm_metadata * - MAC learning is disabled * - All ports initialized, except: * - TJA1104B - Port 2 SGMII * - Port 3 2.5G SGMII has not been tested * - cage - Port 4 SGMII * * Copied pcal9722 driver from SJA1110_MGS_Minimal (from package SJA1110 examples 0.2.0) * - fixed to MCAL Spi driver * - Updated Spi configuration * * main.c * - Updated only the header * device.c * - Added LED routines * test.c * - Removed code that shuts down the TCP/IP stack after its predefined timeout * - Added LED ALIVE task * - Added RX/TX blinking LED * - Added debug stuff * - Commented out the code that initializes 2nd switch * * ----------------------------------------------------------------------------- * Test HW: SJA1110-MGS-EVM SCH-94089_B1 * MCU: SJA1110 * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port <-> Media converter TE-1402 (1000M or 100M, Leader) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
RFの堅牢性を向上させる必要性 #NXH3675 @pramodhag @VishwaOzlo こんにちは、 Audiohubとwasraベースのユニット(CASEやバッズ)間のRFの堅牢性向上を目指しています。私たちが気づいた点の1つは、CIS接続において、MからSへの接続を2M、SからMへの接続を1Mとする非対称PHYを採用することです。 これを変更するだけでは、2つのバッドに接続するため、CIGは生成されません。Slave to Masterの1M PHYでより良いパフォーマンスを得るために調整できる他のパラメータについても教えてください。 ありがとうございます。 RF Re: Need to improve RF robustness こんにちは、 あなたの調子が良いといいのですが。   ご不便をおかけして申し訳ありませんが、承認されたNDAを持つ特定の**お客様**にはNXH3675と**イネーブルメント**(ドキュメント、ソフトウェア、ボード)が利用可能です。   チップや技術、関連**サポート**について詳しくは、**代理店ネットワーク**に掲載されている当社の**代理店**のいずれかに**お問い合わせ**ください。NXPですか?NDAの手続きだけでなく、ドキュメントの入手やサポートの確認も行ってくれます。 既にプライベートメッセージを送りました。 よろしくお願いします、 アナ・ソフィア。
記事全体を表示
Boot uses C40 to erase and rewrite flash. Hello, I'm having trouble writing to flash memory using the C40 chip in the bootloader. I'm writing a 300KB binary program, and it frequently fails at the 9th data packet (the second block), with only a 1/10 chance of succeeding completely. Could you please check if there's a problem with my C40 chip? The main program I'm writing... Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Is there a problem with my use of Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) for resetting? How can I prevent consecutive resets after 8 attempts, and what function should I use for jumps? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> required to avoid hard fault After resetting and jumping , will there be any residual data from the previous program? Is it necessary to clean up the RAM? If so , how? Thank you . 回复: boot使用C40擦写flash Hi@ LJH1 Please provide me with a simple demo that can reproduce the problem so I can reproduce your issue. I don't need your complete product project or scattered driver files. 回复: boot使用C40擦写flash RTD Company uses version 4.0.0 as standard. 回复: boot使用C40擦写flash Subsequent testing revealed that C40 writes were intermittently successful. The `status = C40_Ip_MainInterfaceWriteStatus(); ` command returned a value of 2. ErrorFlags = C40_Ip_pFlashBaseAddress -> MCRS & ( FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK ) ; ErrorFlags eventually equals 0; returns an error. 回复: boot使用C40擦写flash Offline burning of two programs allows for faster reproduction: the first boot directly jumps to the app, the app flashes for 30 seconds to enter boot, the erase/write cycle flashes for 1 second, a total of 300 times. If there are no problems, it resets; if there are problems, it stays on or off. 回复: boot使用C40擦写flash Hi@ LJH1 Your program is too messy; I have no way of testing it for you. I wrote a test program based on the logic of your test. The 8KB space starting from address 0x1000A000 is written in 128 bytes each time, and the address is written 64 times consecutively, totaling 8KB, for a total of 300 times. (128 * 64 * 300). You need to change the clock, because I'm using an S32K311EVB-Q100 with a 16MHz external clock crystal.
記事全体を表示
Can we use SEGGER ARM Debugger to debug S32G-VNP-RDB3's M7 Core? Hello,      We are try to debug S32G-VNP-RDB3 board using SEGGER ARM Debugger. The SEGGER driver is V9.85, which support S32G399A's A53 core and M7 core(We mainly want to debug M7 core). The IDE is S32DS.3.5 and RTD is S32 G3 4.4.4. When we try to download *.elf file to board, the GDB server always prompt me that the S32G399A is not regonized(S32G399A-M7 and S32G399A-M7-0 also aren't regonized). Can you tell me how to set the SEGGER J-link debugging to debug S32G399A board?  Jimmybai_0-1784102264959.png Jimmybai_1-1784102335731.png GoldVIP Re: Can we use SEGGER ARM Debugger to debug S32G-VNP-RDB3's M7 Core? Hi,Jimmybai Thank you for contacting us. For S32G, the recommended debugging method is to use S32 Debug Probe and Trace32. Both of these debuggers can be used in S32DS, and Trace32 also has its own official IDE. Although J-Link has officially stated its support for S32G RDB2/RDB3, you can refer to the following links for more information: https://kb.segger.com/NXP_S32G-VNP-RDB3 https://www.segger.com/supported-devices/nxp/s32g3/s32g399a_m7_0 However, for the S32G, there is no relevant information to provide the use of Jlink in the S32DS IDE. BR Joey
記事全体を表示
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「コアリセットの原因を特定する」を参照してください。 Alice_Yang_0-1784105602643.png BR アリック
記事全体を表示
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ハードウェアでの性能を評価し、レイテンシを直接測定して両実装の違いをよりよく理解します。 ご協力ありがとうございました。 よろしくお願いします、
記事全体を表示
FRDM iMX95 上的 JTAG 大家好 我最近刚买了 FRDM iMx95,我很好奇如何使用 JTAG 来调试这个板 根据原理图,JTAG 接口在此处的第 6 个测试点引脚上暴露出来  Zk47T_0-1781286344908.png 在板布局上,在这里 Zk47T_1-1781286419335.png 我该如何将 JTAG 连接到它,需要进行任何返工吗?那么,这个 JTAG 是否支持对所有 A55、M33 和 M7 核心进行调试?  我应该在这里用哪个设备,看来我们有 6 针但它是 2x3 而不是 1x6 如果有任何设置 JTAG 的指南或文档,我将不胜感激 谢谢!!   Linux Re: JTAG on FRDM iMX95 你好 你的理解是正确的。 如原理图所示,需要添加 DNP 电阻和一个用于调试器的连接器。 顺祝商祺! Re: JTAG on FRDM iMX95 你好, 感谢您的确认@JorgeCas 摘要:请帮忙解决 JTAG 问题“DAP:无法启动系统功率域。” 我已经对 3 个电阻进行了改造,并测量了引脚,它成功上拉了。 需要注意的是,要启用 JTAG,我需要在设备树中禁用 LPUART5,因为它使用相同的引脚(我按照 imx95-19x19-jtag.dtb 中的修改方式进行修改),否则 TMS(测试点 49)将始终为低电平。 diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts index c45f28efb568..598e16af0ebd 100644 --- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts @@ -520,7 +520,7 @@ &lpuart5 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart5>; - status = "okay"; + status = "disabled"; bluetooth { compatible = "nxp,88w8987-bt"; 接下来我需要找到针脚为 1.27mm 的连接器。我花了一些时间才找到这个用弹簧针测试的PCB板,它有6个引脚,完美匹配。 Zk47T_0-1782485750558.png 这是我目前的配置。 95a82f536c8bedd5b49a.jpg 看起来有点乱,但连接没问题,我检查了硬件状态,看起来不错。 J-Link>ShowHWStatus VTref=3.324V ITarget=0mA TCK=1 TDI=1 TDO=0 TMS=0 TRES=1 TRST=1 Supported target interface speeds: - 120 MHz/n, (n>=8). => 15000kHz, 13333kHz, 12000kHz, ... - Adaptive clocking 我尝试使用这两条命令连接 A55 和 M33,但出现同样的问题,显示“ DAP:无法启动系统功率域”。 zk47@ltu:~$ JLinkExe -device MIMX9516_M33 -if JTAG -speed 200 SEGGER J-Link Commander V9.42 (Compiled May 6 2026 12:36:02) DLL version V9.42, compiled May 6 2026 12:35:00 zk47@ltu:~$ JLinkExe -device MIMX9516_A55 -if JTAG -speed 200 我做错了什么? 或许是我的JLink设备不好用,MCU-Link Pro可以替代它吗?MCU-Link Pro 可以调试 A55 和 M 内核吗? 我还是更倾向于通过 JTAG 进行调试,因为我手头已经有了 JTAG。请帮忙 如果你们计划为 FRDM iMX95 添加 JTAG 文档指南,请尽快更新,就像 FRDM iMX93 一样。 Re: JTAG on FRDM iMX95 亲爱的@JorgeCas 有任何更新吗?我可以使用MCU-Link Pro调试所有A55、M33和M7核心吗? Re: JTAG on FRDM iMX95 你好 很抱歉耽搁了这么久。 我们建议您使用 MACRAIGOR Systems、Wind River 或 ARM 的任何调试器。 NXP 团队使用 Lauterbach Trace32 作为 Cortex-A 内核的调试工具,而 J-link 用于 Cortex-M 内核。 对于 i.MX95,要使用 CM7 或 CA55 脚本,前提是 SM 已经在i.MX设备上运行。它采用 CM33 进行资源管理和网络安全,它是开源的,符合 Arm 的硬件资源管理标准,其代码(在很多情况下)旨在对硬件进行分区,并将资源分配给 Cortex-A 或 Cortex-M7。 您可以将此文档用作参考。 在 i.MX 8M、i.MX 8ULP 和 i.MX 9 上使用 VS Code 调试 Cortex-M 如果经过以上检查后问题仍然存在,请检查适配器是否存在硬件问题。 顺祝商祺!  Re: JTAG on FRDM iMX95 亲爱的@JorgeCas 感谢你的回复。 好吧,硬件可能确实是问题所在,但我仍然对这些事情感到疑惑。 能否提供一张您调试设置的图片?我不太清楚连接这些测试点的官方方法是什么。我们需要使用这种东西吗? Zk47T_0-1783994808434.png 2. 文档只针对调试核心 M,不针对核心 A。您能否提供更多关于“使用 Trace32、JLink 或MACRAIGOR调试 Linux 核心 A”的指南,就像您所说的那样? 3.虽然与本帖无关,但请问FRDM iMX95 Pro的预计发布日期是什么时候? Re: JTAG on FRDM iMX95 你好 1. 我们现有的测试用板没有进行任何修改,因为如果需要 JTAG,我们会使用 EVK 而不是 FRDM 板。建议尽可能使用较短的导线连接电路板和调试器,以确保良好的连接和信号完整性。 正如你在这篇文章中看到的,这个问题是通过将更短的电缆焊接到电路板上解决的。 2. 由于每个制造商都使用自己的流程和脚本与处理器连接,因此该信息在探针手册中。我们这边没有关于这些探针连接的文档。 3. 很遗憾,我们没有这方面的信息,建议您查看我们的官方网站以获取更多更新信息。 顺祝商祺!
記事全体を表示
Cannot detect watchdog reset for LPC18xx I have a problem detecting when a watchdog reset has occurred. I am currently following the steps listed in the user guide which states: The Watchdog time-out flag (WDTOF) can be examined to determine if the Watchdog has caused the reset condition. The WDTOF flag must be cleared by software. Although the device resets correctly, the flag doesn't appear to be set afterwards. I saw there was an old post related to a similar issue on the LPC4357 (Solved: LPC4357: Cannot detect watchdog reset - NXP Community), but I couldn't see anything listed in the LPC18xx errata. Please could you confirm whether the LPC18xx suffers from the same issue as above? lpc18xx Re: Cannot detect watchdog reset for LPC18xx Hi @ejg  Thank you for the post! Could you please specify which LPC18xx are you using?  Also, at what time did you review the Flag? If you call the WWDT_Init function from lpc18xx_wwdt.h it clears the interrupt flags, so the WDTOF needs to be read before.  Re: Cannot detect watchdog reset for LPC18xx Hi @carlos_o , thank you for your reply. I am using LPC1837. The flag is checked at startup before interacting with any other WWDT registers. After CMSIS SystemInit completes, I setup the systick, and then check this flag. Re: Cannot detect watchdog reset for LPC18xx Hi @ejg  Yes, LPC18xx has the same issue as LPC43xx. To determine the cause of the core reset, please refer to Section 14.5.1, "Determine the Cause of a Core Reset," in the LPC18xx User Manual. Alice_Yang_0-1784105602643.png BR Alic
記事全体を表示
无法检测到 LPC18xx 的看门狗复位 我无法检测看门狗何时RESET。我目前正在按照用户指南中的步骤操作,指南中指出: 看门狗超时标志(WDTOF)经过检查后可确定看门狗是否导致了复位条件。 WDTOF标志必须通过软件清零。 虽然设备重置成功,但之后该标志似乎并未被设置。 我看到之前有一个关于 LPC4357 类似问题的帖子(已解决:LPC4357:无法检测到看门狗 RESET - 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 完成后,我设置了系统同步,然后检查此标志。 Re: Cannot detect watchdog reset for LPC18xx 嗨@ejg 是的,LPC18xx 与 LPC43xx 存在同样的问题。 要确定核心复位的原因,请参阅 LPC18xx 用户手册中的第 14.5.1 节“确定核心复位的原因”。 Alice_Yang_0-1784105602643.png BR 爱丽丝
記事全体を表示
FRDM iMX95のJTAG こんにちは、みんな、 最近FRDM iMX95を購入したのですが、このボードをJTAGでデバッグする方法に興味があります。 回路図を確認すると、6番目のテストポイントピンにJTAGが露出しています。 Zk47T_0-1781286344908.png ボードレイアウトではここに Zk47T_1-1781286419335.png JTAGをどのように接続すれば良いですか?何か改造が必要ですか?このJTAGは、A55、M33、M7コアのデバッグをすべてサポートしていますか? ここではどのデバイスを使用すればよいでしょうか。ピンが6本あるようですが、1x6ではなく2x3です。 JTAGの設定方法に関するガイドやドキュメントがあれば教えていただけるとありがたいです。 ありがとう !! Linux Re: JTAG on FRDM iMX95 こんにちは、 あなたの理解は正しいです。 回路図に示すように、DNP抵抗器とデバッガ用のコネクタを追加する必要があります。 よろしくお願いいたします。 Re: JTAG on FRDM iMX95 こんにちは、 確認していただきありがとうございます、@JorgeCasさん。 概要:「JTAGの問題「DAP: システムの電源ドメインを起動できません」について助けてください。 3つの抵抗器の修理を行い、ピンを測定したところ、正常にプルアップされました。 JTAGを有効にするには、デバイスツリーでLPUART5を無効にする必要があります。これは、LPUART5が同じピンを使用しているためです(imx95-19x19-jtag.dtbと同じ変更を行いました)。そうしないと、TMS(テストポイント49)が常にLOWになります。 diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts index c45f28efb568..598e16af0ebd 100644 --- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts @@ -520,7 +520,7 @@ &lpuart5 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart5>; - status = "okay"; + status = "disabled"; bluetooth { compatible = "nxp,88w8987-bt"; 次に、1.27mmピンのコネクタを探す必要があります。この基板をポゴピンでテストするのに少し時間がかかりましたが、6ピンで、ぴったり合いました。 Zk47T_0-1782485750558.png これが私の現在のセットアップです 95a82f536c8bedd5b49a.jpg 見た目はごちゃごちゃしているように見えるけど、接続に問題はないよ。HWStatusを確認したけど、問題なさそうだ。 J-Link>ShowHWStatus VTref=3.324V ITarget=0mA TCK=1 TDI=1 TDO=0 TMS=0 TRES=1 TRST=1 Supported target interface speeds: - 120 MHz/n, (n>=8). => 15000kHz, 13333kHz, 12000kHz, ... - Adaptive clocking A55とM33の2コマンドで接続しようとしましたが、同じ問題で「DAP: Couldnpowered up system power domain」と表示されます。 zk47@ltu:~$ JLinkExe -device MIMX9516_M33 -if JTAG -speed 200 SEGGER J-Link Commander V9.42 (Compiled May 6 2026 12:36:02) DLL version V9.42, compiled May 6 2026 12:35:00 zk47@ltu:~$ JLinkExe -device MIMX9516_A55 -if JTAG -speed 200 ここで私が何を間違えたのでしょうか? もしかするとJLinkデバイスが問題なのかもしれません。MCU-Link Proで交換できますか?MCU-Link ProはA55とMコアの両方をデバッグできますか? 既にJTAGを持っているので、やはりJTAG経由でデバッグする方が良いと思います。助けてください FRDM iMX95のJTAGに関するドキュメントガイドを追加する予定がある場合は、FRDM iMX93のように早急に更新してください。 Re: JTAG on FRDM iMX95 @JorgeCas様 何か進展はありましたか?MCU-Link Proを使ってA55、M33、M7のコア全てをデバッグできますか? Re: JTAG on FRDM iMX95 こんにちは、 遅れて申し訳ありません。 MACRAIGOR Systems、Wind River、またはARMのいずれかのデバッガをおすすめします。 NXPチームはCortex-AコアのデバッガツールとしてLauterbach Trace32を使用し、J-linkはCortex-Mコア用です。 i.MX95の場合、CM7またはCA55スクリプトを使用する前提条件として、SMはすでに i.MX デバイス上で動作している必要があります。リソースマネジメントとセキュリティの理由でCM33を採用しており、オープンソースで、Armのハードウェアリソースマネジメント標準に準拠しています。コードは(多くのものの中で)ハードウェアのパーティション分割やCortex-AかCortex-M7へのリソース割り当てを目的としています。 この書類を参考資料として使うことができます。 i.MX 8M、i.MX 8ULP、i.MX 9 での VS Code による Cortex-M デバッグ これらの点を考慮しても問題が解決しない場合は、アダプターのハードウェアに問題がないか確認してください。 よろしくお願いいたします。  Re: JTAG on FRDM iMX95 @JorgeCas様 お返事ありがとうございます。 ハードウェアが問題かもしれませんが、soこの機器はどうなのか疑問です セットアップデバッグ用の写真を撮ってもらえますか?これらのテストポイントに接続する正式な方法がわかりません。このようなものを使う必要があるでしょうか Zk47T_0-1783994808434.png 2. ドキュメントはDebugコアMのみで、コアAは含まれません。「Trace32やJLink、MACRAIGORを使ってコアAのLinuxをデバッグする」というガイドをもう少し教えてもらえますか? 3.このスレッドには関係ありませんが、FRDM iMX95 Proの予定発売日を教えてもらえますか? Re: JTAG on FRDM iMX95 こんにちは、 1. テストに使用できるボードは改造されていません。JTAGが必要な場合は、FRDMボードの代わりにEVKボードを使用します。推奨される方法は、基板とデバッガ間の配線をできるだけ短くして、良好な接続と信号の完全性を確保することです。 この投稿でご覧の通り、短いケーブルを基板にハンダ付けすることで問題は解決しました。 2. この情報はプローブマニュアルに記載されており、各メーカーは自社のプロセスとスクリプトを使ってプロセッサーと接続しています。我々側にはこれらの探査機との関連に関するドキュメントは存在しません。 3. 残念ながら、この情報は持ち合わせておりません。最新情報については、弊社の公式ウェブサイトをご確認ください。 よろしくお願いいたします。
記事全体を表示
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,
記事全体を表示
KW47 上的 ELEMU 与 LTC:除了性能之外,LTC 还有其他优势吗? 你好。 我想了解 KW47 平台上 ELEMU(EdgeLock 消息单元驱动程序)和 LTC(LP 可信加密)在使用上的区别。 我目前的理解如下: ELEMU ・通过请求专用网络安全核心来执行加密操作,由于密钥可以存储在隔离的安全环境中,因此具有很强的防篡改能力。 ・由于需要与安全核心进行通信,因此可能不适合对延迟要求非常严格的应用程序。 ・它支持 LTC 提供的所有加密算法,并且还支持 LTC 无法处理的算法,例如 ECDH。 ・还可以利用安全启动集成等安全相关服务。 因此,我的理解是,ELEMU 更适合需要高安全性的加密操作。 长期护理 ・通过直接控制 LTC 硬件加速器寄存器来执行加密操作,从而实现极低的开销和高性能。 ・支持的算法仅限于硬件加速函数,例如 AES、DES、HASH 等。 ・钥匙无法存放在安全的隔离环境中,因此其防篡改能力低于安全核心所提供的防篡改能力。 因此,我的理解是,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 可信加密)驱动程序提供对 KW47 硬件加密加速器的直接访问。这条路径提供了更低的软件开销,因为应用程序直接与硬件加速器 API 交互,而不是像 ELE_MU 那样通过安全核心进行通信。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 高出几倍甚至几十倍? 或者,在大多数实际应用场景中,加密处理时间本身是否会占据整个执行时间的大部分,使得 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 硬件上评估性能,并直接测量延迟,以便更好地了解两种实现方式之间的差异。 再次感谢您的帮助。 此致,
記事全体を表示