Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
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 硬件上评估性能,并直接测量延迟,以便更好地了解两种实现方式之间的差异。 再次感谢您的帮助。 此致,
查看全文
我们可以使用 SEGGER ARM Debugger 来调试 S32G-VNP-RDB3 的 M7 内核吗? 你好, 我们正在尝试使用 SEGGER ARM 调试器调试 S32G-VNP-RDB3 板。SEGGER 驱动程序版本为 V9.85,支持 S32G399A 的 A53 内核和 M7 内核(我们主要想调试 M7 内核)。IDE 为 S32DS.3.5,RTD 为 S32 G3 4.4.4。当我们尝试将 *.elf 文件下载到板子时,GDB 服务器总是提示我 S32G399A 无法识别(S32G399A-M7 和 S32G399A-M7-0 也无法识别)。请问如何设置 SEGGER J-link 调试来调试 S32G399A 开发板? Jimmybai_0-1784102264959.png Jimmybai_1-1784102335731.png 金VIP Re: Can we use SEGGER ARM Debugger to debug S32G-VNP-RDB3's M7 Core? 你好, Jimmybai 感谢您与我们联系。 对于 S32G,推荐的调试方法是使用 S32 Debug Probe 和 Trace32。这两个调试器都可以在 S32DS 中使用,而且 Trace32 也有自己的官方 IDE。 虽然 J-Link 已正式声明支持 S32G RDB2/RDB3,但您可以参考以下链接了解更多信息: https://kb.segger.com/NXP_S32G-VNP-RDB3 https://www.segger.com/supported-devices/nxp/s32g3/s32g399a_m7_0 然而,对于 S32G,没有相关信息可用于在 S32DS IDE 中使用 Jlink。 BR 乔伊
查看全文
JTAG on FRDM iMX95 Hi all,  I just bought FRDM iMX95 recently, i am curious about how to use JTAG to debug this board  As check in schematic it has JTAG exposed at 6 test point pin here  Zk47T_0-1781286344908.png At board layout it here  Zk47T_1-1781286419335.png How should i connect jtag to it, do i need any rework ? And does this JTAG support to debug all A55, M33, and M7 core ?  Which device should i use here, it seem we have 6 pin needle but it 2x3 not 1x6  I would appreciate any guide or docment to set up JTAG  Thank you !!   Linux Re: JTAG on FRDM iMX95 Hello, Your understanding is correct. As you can see in schematic is needed to add the DNP resistors and a connector for the debugger. Best regards. Re: JTAG on FRDM iMX95 Hello, Thank you for your confirmation @JorgeCas  Summary : Please help with JTAG problem ""DAP: Could not power-up system power domain."" I have done the rework for 3 resistor and measure the pin, it successfully pull up. One note that to enable JTAG, i need to disable LPUART5 in device tree  because it use the same pin (i follow the same modify as imx95-19x19-jtag.dtb ) or else TMS (Test point 49) will always 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"; After this i need to find the connector with 1.27mm pin. It take me some time to find this pcb test by pogo pin, it has 6 pin, perfectly fit.  Zk47T_0-1782485750558.png Here is my current setup  95a82f536c8bedd5b49a.jpg It seem a mess but the connection is not problem, i check the HWStatus and it look good  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 I try connect it by these 2 command for A55 and M33 but same issue show is "DAP: Could not power-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 What could i do wrong here ? Maybe it fall to my JLink device is not good, can MCU-Link Pro replace it ? Can MCU-Link Pro debug both A55 and M core ?  I would still prefer do the debug through JTAG because i already had it. Please help  If you guy plan to add document guide for JTAG on FRDM iMX95, please update it soon like FRDM iMX93.   Re: JTAG on FRDM iMX95 Dear @JorgeCas  Any update ? Can i use MCU-Link Pro to debug all core A55, M33 and M7 core ?  Re: JTAG on FRDM iMX95 Hello, I apologize for the delay. We suggest you any debugger from MACRAIGOR Systems, Wind River or any of ARM. NXP team uses Lauterbach Trace32 as debugger tool for Cortex-A cores, J-link is for Cortex-M cores. In the case of i.MX95, as prerequisite to use the CM7 or CA55 scripts the SM should be already running on the i.MX device. it has the CM33 for resource management and security reasons, it's open source, it's compliant to a HW resource management standard by ARM, and its code it's meant (between a lot of them) to partition hardware, assign resources to either Cortex-A or Cortex-M7. You can use this document as reference. Debugging Cortex-M with VS Code on i.MX 8M, i.MX 8ULP, and i.MX 9 If you still having issues after this considerations, please look for hardware issues in your adapter. Best regards.  Re: JTAG on FRDM iMX95 Dear @JorgeCas  Thank you for your reply.  Okay so the hardware could be the problem, but i am still wonder these thing  Can i have a picture for your setup debug ? I am not sure what is the official way to connect to these test point. does we need to use kind of this  Zk47T_0-1783994808434.png 2. The docs only for Debug core M, not core A. Can you give me more guide for "Debug core A linux using Trace32 or JLink or MACRAIGOR " as you said ?  3. Not relate to this thread, but can i have the estimated release date for FRDM iMX95 Pro ?  Re: JTAG on FRDM iMX95 Hello, 1. Our available boards for testing are not modified since if JTAG is needed, we use EVK instead FRDM boards. The recommended approach is use shorter wires as possible between the boards and debugger to warranty a good connection and signal integrity. As you can see in this post, the issue was solved with shorter cables soldered to the board. 2.  This information is in probe manual since each manufacturer uses their process and scripts to connect with the processor. There is no documentation in our side regarding these probes connection. 3. Unfortunately we do not have this information, I suggest you check our official web site for further updates. Best regards.
查看全文
ブート時にはC40を使用してフラッシュメモリを消去し、書き換えます。 こんにちは。ブートローダーでC40チップを使用してフラッシュメモリへの書き込みに問題が発生しています。300KBのバイナリプログラムを作成しているのですが、9番目のデータパケット(2番目のブロック)で頻繁に失敗し、完全に成功する確率は10分の1程度です。C40チップに問題があるかどうか確認していただけないでしょうか?作成中のメインプログラムは… Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) を使用したリセットに問題がありますか? 8 回試行した後に連続リセットを防ぐにはどうすればよいでしょうか?また、ジャンプにはどの関数を使用すればよいでしょうか? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> ハードフォールトを回避するために必要 リセットとジャンプの後、以前のプログラムの残留データは残りますか? RAMをクリーンアップする必要はありますか? もし必要なら、どのようにすればよいですか? よろしくお願いいたします。 回复: boot使用C40擦写flash こんにちは@ LJH1 問題を再現できる簡単なデモを提供してください。そうすれば、私もあなたの問題を再現できます。製品プロジェクト全体や、散在するドライバファイルは必要ありません。 回复: boot使用C40擦写flash RTD社は標準バージョンとして4.0.0を使用しています。 回复: boot使用C40擦写flash その後のテストで、C40 の書き込みが断続的に成功していることが判明しました。`status = C40_Ip_MainInterfaceWriteStatus(); ` コマンドは値 2 を返しました。 ErrorFlags = C40_Ip_pFlashBaseAddress -> MCRS & ( FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK ) ; ErrorFlagsが最終的に0になった場合、エラーを返します。 回复: boot使用C40擦写flash 2つのプログラムをオフラインで書き込むことで、より迅速な再現が可能になります。最初の起動ではアプリに直接ジャンプし、アプリが30秒間点滅してブートモードに入り、消去/書き込みサイクルが1秒間点滅します。これを合計300回繰り返します。問題がなければリセットされ、問題がある場合はオンまたはオフの状態が維持されます。 回复: boot使用C40擦写flash こんにちは@ LJH1 あなたのプログラムはあまりにも複雑で、私にはテストする方法がありません。 あなたのテストのロジックに基づいてテストプログラムを作成しました。 アドレス0x1000A000から始まる8KBの領域に、128バイトずつ書き込みが行われ、このアドレスは64回連続して書き込まれ、合計8KB、合計300回書き込まれる。 (128 * 64 * 300) クロックを変更する必要があります。なぜなら、私は16MHzの外部クロック水晶を搭載したS32K311EVB-Q100を使用しているからです。
查看全文
SEGGER ARM Debuggerを使ってS32G-VNP-RDB3のM7コアをデバッグできますか? こんにちは、 SEGGER ARM Debuggerを使ってS32G-VNP-RDB3ボードのデバッグを試みています。SEGERドライバーはV9.85で、S32G399AのA53コアとM7コアをサポートしています(主にM7コアのデバッグを目的としています)。IDEはS32DS.3.5で、RTDはS32 G3 4.4.4です。ボードに*.elfファイルをダウンロードしようとすると、GDBサーバーから常にS32G399Aが認識されないというメッセージが表示されます(S32G399A-M7とS32G399A-M7-0も認識されません)。SEGGER J-linkデバッグをボードのデバッグに設定する方法S32G399A教えてもらえますか? Jimmybai_0-1784102264959.png Jimmybai_1-1784102335731.png ゴールドVIP Re: Can we use SEGGER ARM Debugger to debug S32G-VNP-RDB3's M7 Core? こんにちは、ジミーバイ お問い合わせいただきありがとうございます。 S32Gの場合、推奨されるデバッグ方法はS32 Debug ProbeとTrace32です。これらのデバッガはどちらもS32DSで使用可能であり、Trace32には独自の公式IDEも存在します。 J-Linkは公式にS32G RDB2/RDB3のサポートを表明していますが、詳細については以下のリンクをご覧ください。 https://kb.segger.com/NXP_S32G-VNP-RDB3 https://www.segger.com/supported-devices/nxp/s32g3/s32g399a_m7_0 しかし、S32Gに関しては、S32DS IDE上でJlinkの使用に関する関連情報がありません。 BR ジョーイ
查看全文
boot使用C40擦写flash 你好,我这边使用boot里面使用C40写flash大概率失败,我写300K左右的bin程序,经常在第9包数据,也就是第二个块就失败,1/10可能性完整通过,请帮我看一下是不是C40是不是使用有问题,写的主要程序 Flash_UnlockSectorIfProtected(cur_sector); DisableAllInterrupts(); DisEnableIrq1(); if (Flash_Write(flash_write_addr + offset, &payload[2], FIXED_PACKET_DATA_LEN) != 0) { EnableIrq1(); EnableAllInterrupts(); } EnableIrq1(); EnableAllInterrupts(); 我使用Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE);复位有没有问题,怎么避免8次后连续复位,跳转函数 func = *(uint32_t volatile *)(ADDR_APP + 0xC); func = *(uint32_t volatile *)(((uint32_t)func) + 0x4); func = ((((uint32_t)func) & 0xFFFFFFFFU)); // Reset_Handler+1 --> required to avoid hard fault (* (void (*) (void)) func)();复位和跳转后会不会有之前程序的数据残留,需要清理ram吗,如果需要怎么清理。麻烦了 回复: boot使用C40擦写flash Hi@LJH1 做一个最简单可以复现问题的demo给我,方便我复现你们的问题,我不要你们的完整产品工程或者是零散的驱动文件。 回复: boot使用C40擦写flash RTD公司统一使用的4.0.0 回复: boot使用C40擦写flash 离线烧录两个程序,一起复现快:首次boot直接跳app,app快闪30s进入boot,擦写1s闪烁,一共300次,没问题复位,有问题就常亮或长灭。 回复: boot使用C40擦写flash 后续测试 ,C40写时好时坏        status = C40_Ip_MainInterfaceWriteStatus();status结果等于2; ErrorFlags = C40_Ip_pFlashBaseAddress->MCRS & (FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK); ErrorFlags最终等于0;返回error 回复: boot使用C40擦写flash Hi@LJH1 你的程序太乱了,我完全没办法帮你测试。 我按照你测试的逻辑,写了一个测试程序 从地址0x1000A000开始的8KB空间,每次写入128byte,地址连续写入64次共8KB,连续300次。 (128 * 64 * 300)。 你要改一下时钟,因为我用的是S32K311EVB-Q100,外部时钟晶振是16MHz.
查看全文
需要提高射频鲁棒性 # NXH3675 @pramodhag @VishwaOzlo 你好, 我们正在寻求提高 audiohub 和 wasra 设备(外壳和耳塞)之间的射频鲁棒性。我们遇到的一个问题是,CIS 连接的 PHY 不对称,M 到 S 为 2M,S 到 M 为 1M。 仅仅更改此设置不会创建 CIG,因为我们连接的是 2 个耳机。请帮助我们确定其他可以调整的参数,以便使用 1M PHY 实现从属到主的更好性能。 谢谢。 射频 Re: Need to improve RF robustness 你好, 希望你一切都好。   对于由此造成的不便,我深表歉意,但 NXH3675 及其配套产品(文档、软件和板)仅提供给已签署保密协议的特定客户。   如需了解有关芯片、技术及相关支持的更多信息,请联系我们代理商网络|NXP中的代理商之一。他们不仅可以帮助您完成保密协议流程,还可以帮助您检查是否可以获得相关文件以及他们可以为您提供的支持。 我已经给你发了私信。 此致, 安娜·索菲亚。
查看全文
Need to improve RF robustness # NXH3675 @pramodhag @VishwaOzlo Hello, We are looking for improvements in the RF robustness between the audiohub and wasra based units (case and buds). One of the points that we came across is having asymmetric PHY for the CIS connection with M to S as 2M and S to M as 1M. Just by changing this would not create the CIG as we connect to 2 buds. Please help us with other parameters that could be tuned to get a better performance with 1M PHY for Slave to Master. Thanks. RF Re: Need to improve RF robustness Hello, Hope you are doing well.   I apologize for the inconveniences, but NXH3675 and enablement (documentation, software and boards) are available for select customers with an approved NDA.   For more information about the chips, technology and any related support, could you please contact one of our distributors available in the Distributor Network|NXP? They can not only help you with the NDA process, but also help you check if you can get documentation and the support they can offer you. I already sent you a private message. Best regards, Ana Sofia.
查看全文