Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
S32 设计工作室版本 v.3.4 已过期 我的 S32 设计工作室(适用于 S32 平台)v.3.4许可证已过期,请问能否延长许可证期限? 订单号: S32DS-3-4_156834637 许可证总数: 101 激活码: 7F70-B731-EFE8-3F4B 非常感谢。 Re: S32 Design Studio version v.3.4 expired 你好, 您的 S32DS 许可证已延期,请使用您的旧代码重新激活 S32DS。
記事全体を表示
为了完善解决方案,本文将介绍如何在 MCUXpresso IDE 中使用 printf 函数打印浮点数。 您好: 之前的主题中讨论过如何在 MCUXpresso IDE 和 SDK 中打印浮点数。 尝试这些方法并总结最终解决方案: 1. 将浮点数打印到 UART 控制台 在项目配置->C/C++ 版本->设置中设置以下宏 PRINTF_FLOAT_ENABLE=1 这样的代码可以运行。 float test1 = 0.15; PRINTF("%f\r\n",test1); 2.使用 sprintf() 函数将浮点数转换为字符串。 SDK 用户手册中有一处错误:“请确保已选择 Redlib: 使用 printf 的浮空版本”。 “在项目创建过程中不起作用。” 默认的 C 库 Redlib 不支持浮空,因此无法与 redlib 一起使用。 正确答案是: (1)将链接库更改为 NewLib,它是一个完整的 C 库,支持浮点 printf。 但请注意,需要在相关的 c 文件中包含 ,否则 sprintf(float) 将无法按预期工作。 (2)将链接库更改为 NewLib Nano,这是一个紧凑的 C 库,需要点击“启用 print float”来启用 float 函数,这实际上会添加“-u _printf_float”链接符号。 但请注意,需要在相关的 c 文件中包含 ,否则 sprintf(float) 将无法按预期工作。 因此,该解决方案肯定会增加项目的闪存和内存消耗,但对于 i.MXRT 系列来说,这不是问题。 附件是 RT1020 EVK 的一个例子。 Re: To complement solution how to printf float number in MCUXpresso IDE 谢谢你!问题解决了。 Re: To complement solution how to printf float number in MCUXpresso IDE 嗨@daweiyou 非常感谢您的贡献。这些信息很有帮助,可能对很多人都有用。 再次感谢。 此致。 巴勃罗·阿瓦洛斯。
記事全体を表示
S32 Design Studio バージョン v.3.4 の期限切れ 私のS32 Design Studio for S32 プラットフォーム v.3.4期限切れです。ライセンスを拡大していただけますか? 注文番号: S32DS-3-4_156834637 ライセンス総数: 101 アクティベーションコード: 7F70-B731-EFE8-3F4B ご返信よろしくお願いします。 Re: S32 Design Studio version v.3.4 expired こんにちは、 S32DSのライセンス期間が延長されました。以前のコードを使用してS32DSを再度アクティベートしてください。
記事全体を表示
MCUXpresso IDEsでfloat番号を印刷する方法を補完するために こんにちは: 以前のトピックでは、MCUXpresso IDEsやSDKsでfloat番号を印刷する方法についての議論がありました。 それらを試してみて、最終的な解決策をまとめると次のようになります。 1.浮動小数点数をUARTコンソールに出力します。 プロジェクト構成->C/C++ビルド->設定で以下のマクロを設定してください。 PRINTF_FLOAT_ENABLE=1 そのコードは動作するはずです。 float test1 = 0.15; PRINTF("%f\r\n",test1); 2. sprintf() 関数を使用して浮動小数点数を文字列に変換します。 SDKユーザーマニュアルには「Ensure Redlib: Use floating some version of printfが選択される」というエラーがあります プロジェクト作成中は動作しません。 デフォルトのCライブラリであるRedlibはフローティングをサポートしていないため、redlibでは動作しません。 正解は以下の通りです。 (1)リンクライブラリをNewLibに変更してください。完全なCライブラリでfloat printfもサポートします。 ただし、関連する c ファイルに を含める必要があることに注意してください。そうしないと、sprintf(float) が期待どおりに動作しません。 (2)リンクライブラリをNewLib Nanoに変更します。これはコンパクトなCライブラリで、「enable print float」をクリックしてfloat関数を有効にする必要があります。これにより、実際には「-u _printf_float」リンクシンボルが追加されます。 ただし、関連する c ファイルに を含める必要があることに注意してください。そうしないと、sprintf(float) が期待どおりに動作しません。 SO、プロジェクトでは確実にフラッシュとRAM消費が増えますが、i.MXRTシリーズでは問題ありません。 AttachはRT1020 EVKの一例です。 Re: To complement solution how to printf float number in MCUXpresso IDE ありがとう!これで問題は解決しました。 Re: To complement solution how to printf float number in MCUXpresso IDE こんにちは@daweiyou ご協力ありがとうございますSO。その情報はとても役に立ち、多くの人にも役立つかもしれない。 改めてありがとうございました。 よろしくお願いします。 パブロ・アバロス。
記事全体を表示
Wi-FiチップセットMCU制御 こんにちは、みんな、 AP+STA機能を備えたWi-Fiモジュールを探していました。例えば、NXP、Microchip、Infineonなどのモジュールを見つけました。しかし、ほとんどのモジュールはPCIe経由でWiFiインターフェースを使えず、高度なOSでしか対応していません。 しかし、InfineonのAIROC CYW55X(シリーズ)というMCU+WiFiモジュールのセットを見つけました。 こういったタイプのモジュールの統合や制御に関する経験はありますか?もしそうなら、これまでに使っていて外部MCUとうまく統合できた他のモジュールを教えてもらえますか?私の意図は、データをマイクロコントローラにオフロードするのではなく、例えばメッシュやAPの機能を制御することです。 Wi-Fiモジュールを制御しながら基本的なAIモデルに対して推論を行うために、MCU(例えばSTM)を使っています。 ありがとう、みんな Re: Wi-Fi Chipset MCU Control こんにちは、 @maiyaa さん。お元気でお過ごしでしょうか。 ホスト型ワイヤレスモジュールにご興味があるなら、 IW611を検討してみてはいかがでしょうか。このSoCはSDIOを介してWi-Fiインターフェースを提供し、FreeRTOSでサポートされています。さらに、IW611を統合するすべてのモジュールを含む Wi-Fi + Bluetooth + 802.15.4パートナーモジュール のページもご参照ください。また、各モジュールの推奨ホストも表示されます。MCUの場合はIW611+RT1060で動作することが推奨されています。 ちなみに、 RW61Xファミリはホストレスで、Wi-Fi+Bluetooth+802.15.4(RW612用)やWi-Fi+Bluetooth(RW610用)ラジオをMCU内に統合するソリューションです。 これらのソリューションのどれかがご要望に合っているか、または特定の特徴があれば教えてください。より良いおすすめをお伝えします。
記事全体を表示
Arm FuSaコンパイラを使ってi.MXRT1170 EVKBで32ビット命令(16ビットサムを避けて)強制する方法 こんにちは、皆さん 現在、i.MXRT1170 EVKBボード上のNXP MIMXRT1176DVMAAプロセッサを使った概念実証(PoC)プロジェクトに取り組んでいます。 私の開発環境は、Embedded FuSa用のセーフティ認証済みArmコンパイラを備えたMCUXpresso IDEで構成されています。コンパイル中は16ビット命令の生成を避け、ツールチェーンが32ビット命令のみを出力するように強制したいと考えています。Thumb-2(T32)命令セットは、性能とコードサイズのバランスを取るためにデフォルトで16ビットと32ビットの命令を混ぜていると理解しています。しかし、私たちのプロジェクト要件では、生成されるすべての命令が正確に32ビット幅である必要があります。 MCUXpresso IDEで32ビット幅の命令生成を強制するために、コンパイラやツールチェーンのオプションをどのように設定すればよいか、どなたかご案内いただけませんか? ありがとう、 カルティ Re: How to force 32-bit instructions (avoiding 16-bit Thumb) on i.MXRT1170 EVKB using Arm FuSa Compi こんにちは、 @KD7 さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます! RT1170 / Cortex-M7では、これはグローバルコンパイラ設定としてサポートされていません。このコアはARMv7-M Thumb/T32コードを実行し、T32は本質的に16ビットと32ビットが混在した言語です。A32 -marm オプションは、固定の 32 ビット命令セットオプションですが、M プロファイルのターゲットには有効ではありません。 手書きアセンブリのみの場合、 。Wは有効な場合、選択されたT32命令を32ビットエンコーディングに強制できますが、すべてのコンパイラ生成のC/C++命令を32ビットに強制することはできません。 Armはこのトピックについてさらに詳しい情報を提供できるかもしれません。 ありがとうございます。よろしくお願いいたします。 ギャビン
記事全体を表示
将 LS1046/26 CPU 的 u-boot 从 Zeus 2019.04 +fslc 迁移到 Wrynose 2026.01 你好 我们使用的是来自“git://source.codeaurora.org/external/qoriq/”的u-boot代码版本。适用于我们基于 LS1046/26 CPU 的显卡。此 u-boot 版本为 2019.04 +fslc。我们也支持安全启动。 我们现在正在考虑将我们的 u-boot 升级到 Wrynose 2026.01。 我们现有的 U-Boot 源代码最初是从现已弃用的存储库中获取的: git://source.codeaurora.org/external/qoriq/。 请问最新代码应该使用哪个合适的 Git 仓库? 此外,如果您能分享一些关键注意事项或最佳实践,以确保升级过程顺利进行,那就太好了。 Re: u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU 你好, 对于 LS1046/LS1026A 系列 Layerscape U-启动,已弃用的 CodeAurora QorIQ 树的替代方案是: git clone https://github.com/nxp-qoriq/u-boot.git NXP 的指导意见是替换旧的 URL,例如: 源.codeaurora.org / external / qoriq / qoriq - 元器件 / u - 启动.git 其中: github . com / nxp - qoriq / u - boot . git 或者更一般地说,替换 source.codeaurora.org/external/qoriq/qoriq-components 在版本脚本、清单和 Yocto 配方中使用 github.com/nxp-qoriq 。 对于基于 Wrynose 的 电路板支持包。 ,我会从QorIQ Yocto SDK 清单开始,而不是单独克隆 U-Boot: repo init -u https : // github . com / nxp - qoriq / yocto - sdk - b wrynose repo sync --force - sync 公开的 nxp-qoriq/yocto-sdk 仓库显示有一个活跃的 wrynose 分支。同一个仓库记录了一般的仓库初始化流程,并列出了 Yocto 分支/版本映射机制。 具体来说,对于 U-Boot,公共的 nxp-qoriq/u-boot 仓库是 QorIQ U-Boot 树;其在检索到的仓库页面中显示的默认分支是 lf_v2024.04 ,活动分支列表还显示了 lf_v2026.04 。显示的标签包括最近的 lf-* 版本标签,例如 lf-6.12.49-2.2.0 、 lf-6.18.2-1.0.0 和 lf-6.18.20-2.0.0 。因此,实际的规则是:使用 Wrynose Yocto 清单/配方选择的 U-Boot 版本,而不是手动选择任意的“最新”U-Boot 分支。 过渡期的关键考虑因素: 迁移所有 CodeAurora 引用 在版本树中搜索旧 URL: grep - rn 'source.codeaurora.org/external/qoriq' 。 替换 source.codeaurora.org/external/qoriq/qoriq-components 在清单、版本配置和配方中使用 github.com/nxp-qoriq 。 使用版本清单作为真实信息的来源 对于电路板支持包升级,请保持 U-Boot、ATF、RCW、CST、内核、设备树和配方与同一 NXP 版本流保持一致。 NXP 目前的 Layerscape 流程通常使用ATF + U-Boot ,而不是单独的 U-Boot。 再次将你的定制电路板从 LS1046ARDB 参考电路板移植过来 对于 LS1046 定制板,NXP 指向 LS1046ARDB U-Boot 参考文件: configs/ls1046ardb_tfa_defconfig 、 arch/arm/dts/fsl-ls1046a-rdb.dts 和 board/freescale/ls1046ardb/ 。 对于旧式自定义,还要查看 include/configs/ls1046ardb.h 和板文件夹。 请将您现有的板更改与新的设备模型/Kconfig/DTS 结构进行协调,而不是直接复制旧的 2019.04 代码。 安全启动:重建并重新验证整个链 在 Yocto 中,安全启动映像的构建方式如下: DISTRO_FEATURES :追加= "安全" 然后运行: bitbake 安全启动- qoriq 在修改生产熔丝设置之前,应该在开发/未熔丝单元上重新验证 CST、SRKH、OTPMK、RCW SB_EN 、ATF 和签名 U-Boot 启动映像处理。 预计 2019 年 4 月起启动流程会有所不同 自 LSDK 18.12 起,NXP 为 Layerscape RDB 引入了 TF-A 启动流程: 与旧的 PPA 式流程相比, Boot ROM → BL2 → BL31 → U-Boot/UEFI → Linux 。 如果您的当前产品仍然沿用旧的 PPA/直接 U-Boot 路径的假设,请仔细检查这些假设。 保持可控的迁移基线 首先,建立一个与您的硬件接近的、未经修改的 NXP 参考配置。 然后分小组应用您的电路板增量:RCW/SerDes、DDR、控制台、启动介质、QSPI/eMMC/SD、以太网/FMan、环境布局、安全启动。 在声明与旧的 2019.04 + fslc 树的一致性之前,请验证非安全启动路径和安全启动路径。 此致
記事全体を表示
32 位并行接收上升沿引脚 (FRDM-MCXN947) 我目前正在尝试配置一个 32 位并行移位器,以从外部设备接收数据,其中一个引脚(FLEX_D4/DATA_VALID)用作移位数据的信号。 我取得的进展使我能够在 DATA_VALID 触发时读取 32 位数据,并将数据移动到 eDMA Ping-Pong 缓冲区。我目前正在通过 Printf 语句测试将缓冲区数据读取到控制台,如果移位器出现任何错误(通常根据数据手册指示为溢出),它们也会打印到控制台。 我认为我的主要问题出在 TimerConfig 上,因为它在 DATA_VALID 的一个上升沿触发 Shifter 读取过多次,但我还没有找到一种配置,允许我只读取一次,同时实际移动正确的数据。 控制台输出: 读取缓冲区 A:0x3fffefff 换挡器错误代码:0x8 换挡器状态:0x0 SHIFTSDEN:0x8 DMA CSR:0x0 DMA 错误:0x0 TCD BITER:0x2 CSR:0x12 CH_MUX: 0x40 读取缓冲区 B:0x3fffefff 换挡器错误代码:0x8 换挡器状态:0x0 SHIFTSDEN:0x8 DMA CSR:0x0 DMA 错误:0x0 TCD BITER:0x2 CSR:0x12 我的FLEX_IO设置已附上。谢谢。 时钟|计时器 通信与控制(I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO) 开发板 MCX N Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 更新:我推断出“ kFLEXIO_TimerDisableOnTriggerFallingEdge ”导致我的 CPU 一直处于回调状态。 我想在计时器比较后禁用它,但使用此选项后,SHIFTBUF 只报告值为 0x0,而没有 SHIFTERR 标志。 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 嗨@carlos_o,谢谢你的回复! 我如愿以偿地在 DATA_VALID 边沿获取了定时器读数,但没有更新线程。我的代码已附上。 我现在面临的问题是如何让 FlexIO 跟上其他设备的运行速度。在我目前的设置中,我基本上是在对 DATA_VALID 进行采样,并且在更高的速度下,Shifter 可能会过载。我的想法是,我的设计需要 MCX 和发送 32 位数据的主机设备之间共享时钟。我可以使用 32 位数据总线中的一个引脚作为该信号,因此我不需要拆分 FlexIO 引脚。欢迎大家就这个想法提出任何意见! 回答你之前的问题: 1.寄存器正在按预期以较低速度填充数据。在每个 DATA_VALID 下降沿,SHIFTBUF 存储来自 32 个引脚的数据,EDMA 通过 Scatter-Gather 方法传输到我的 Ping-Pong 缓冲区。 2. 我正在通过 Analog Discovery 2 模拟输入,因为它只有 16 个数据引脚,所以我只写入 32 位的上限值,在 DATA_VALID 引脚上模拟时钟,并将未使用的引脚连接起来。低速测试数据匹配正确。 3. 我正在使用 FRDM-MCXN947 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 嗨@Flexin_On_The_IO 感谢您的帖子! 请问您能否分享一下您在收银机中观察到的当前情况? 您想接收哪些测试数据?您目前接收到的数据是什么? 请问您使用的是哪个版本的MCXN? 这是定制电路板吗?否则,请说明您使用的板型号。 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 嗨@Flexin_On_The_IO 很抱歉回复晚了。 请问您想要达到的速度是多少? 您可以查看AN14284:FlexIO 仿真接口的时序参数调整,这篇应用笔记可能对您的目标有所帮助。    Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) @carlos_o你好! 我想要达到的最低速度是 18.5MHz。我可以确认 Shifter 在 6.25MHz 左右的频率下可以保持稳定,但由于我的硬件限制,在更高的速度下我遇到了问题 :P。 下面是我的 Analog Discovery 2 波形,其中我只提供了 MCLK 信号、一个用于数据的二进制计数器(由于 AD2 上的引脚数量较少,因此只有 12 位),并手动控制了 DATA_VALID 信号。 当频率达到更高(20 MHz)时,我发现 AD2 实际上无法提供像样的方波,并且由于信号完整性差,可能导致我的 FRDM 触发不必要的频移。 我看了你发给我的文件,我觉得它可能可以解决我想解决的一个问题。如果 DATA_VALID 与 MCLK 同时上升/下降,我认为它会错过数据移位,因为时钟无法完全递减。 我的主要问题是,即使来自其他设备的触发信号变为低电平,换挡器通常是否需要延迟时钟/计时器才能完成其完整的换挡周期?我目前的设置要求 DATA_VALID 在 MCLK 边沿之间保持高电平,以免丢失数据。
記事全体を表示
S32k344マルチリンクfxの使い方 私はFRDM-A-S32K344モデルを使っていて、Multilink FXでLEDの点滅機能をダウンロードしようとしていますが、うまくいきません。理由を知りたいです。エラーが頻繁に発生し、Gemini経由で修正しようとしても解決しません。助けてください。 また、Multilink FXモデルのオレンジライト(TGPWR)が点灯していることも確認しました。 GeminiはJP11 OPENSDAの電圧を外すように指示していますが、その方法がわかりません。 Re: how to use S32k344 multilink fx 解決しました。JP11を削除したらうまくいった。
記事全体を表示
S32DS 3.5 How can I obtain the toolchain classification report for S32DS3.5, including... What about the TI/TD/TCL reports on analysis and use of constraints and known limitations? Re: S32DS 3.5 Hi, lhy These types of documents have security attributes and require an NDA. Please submit a case through the internal support system. https://support.nxp.com BR Joey Re: S32DS 3.5 thank you
記事全体を表示
MCUXpressoでのMCUをLPC54S018J4MからLPC54S018J2Mに変更する方法 みなさんこんにちは、 私は上記のMCUの評価ボードを使ってMCUXpressoでプロジェクトを開発しました。 評価ボードにはLPC54S018J4Mが搭載されており、私のカスタムボードにはLPC54S018J2Mが搭載されています。フラッシュメモリの容量(2MB/4MB)が異なる点を除けば、基本的に同じものです。 両方のプロセッサのSDKsの起動ファイルを比較しましたが、どちらもまったく同じで、つまり4MBフラッシュ用のSPIディスクリプタが内蔵されています /* SPI ディスクリプタ - Winbond W25Q32JV */ メモリ詳細の最初の行にあるメモリサイズを0x400000から0x200000に変更するだけで安全でしょうか? よろしくお願いいたします。 ライナー Re: Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso こんにちは、 @hfuhruhurr 投稿ありがとうございます! 常に推奨されるのは、プロジェクトで使っている特定のデバイスやパッケージを選ぶことです。 新しいプロジェクトを作成し、正しいデバイスパッケージを選択し、既存のソースファイル、プロジェクト設定、設定を新しいプロジェクトにコピーしてください。 これにより、選択したパッケージごとにデバイス固有の設定が正しく生成され、設定に関する問題が解決される可能性があります。 また、選択しているMCUを変更する方法も可能です:MCUXpressoでMCUを変更する方法 この情報がお役に立てば幸いです! Re: Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso カルロス様、 ご回答ありがとうございます。推奨されている方法を知っていますが、避けたくてこの特定のモデルをお願いしました...元の投稿で私の理由は述べました。 考えていた通りに(マップ内のメモリを4MBから2MBに変更する)実行したところ、完璧に動作しました。 よろしくお願いいたします。 ライナー
記事全体を表示
NXPS32k144EVBの問題 こんにちは NXPS32K144EVBボードを使っていますが、S32 Design Studioでコードをフラッシュしようとすると問題が発生し、同じウィンドウを再度押すと、JFLASHに接続するとこのウィンドウが表示されます 接続中... - USB 経由でプローブ/プログラマデバイス 0 に接続中 - プローブ/プログラマファームウェア: J-Link V9 コンパイル日 2021 年 5 月 7 日 16:26:12 - プローブ/プログラマ S/N: 69408845 - デバイス "S32K144" が選択されました。- ターゲットインターフェース速度:4000 kHz(固定) - VTarget = 3.288V - InitTarget() 開始 - SWD 選択。JTAGからSWDへの切り替えシーケンスを実行しています。-アドレス 0x400 - 0x40F のフラッシュメモリ内の保護バイトは、読み出し保護が設定されていることを示します。デバッガーを接続するには、デバイスのセキュリティ設定を解除する必要があります。注意:固定を解除すると内部フラッシュの大量消去が発生します。レジストリに以前保存されたデフォルトの動作を実行します。- デバイスのセキュリティは解除されます。デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は決して止まらない。- InitTarget() 終了 - 2.15 秒かかりました - ID 0x2BA01477 の SW-DP を検出しました - DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - CPUへの接続に失敗しました。リセット状態で接続を実行します。- DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - Coresightセットアップでコアが見つからず - InitTarget() 開始 - SWDを選択しています。JTAGからSWDへの切り替えシーケンスを実行しています。- アドレスのフラッシュメモリ内の保護バイト。0x400~0x40Fは、読み出し保護が設定されていることを示します。デバッガーを接続するには、デバイスのセキュリティ設定を解除する必要があります。注意:固定を解除すると内部フラッシュの大量消去が発生します。レジストリに以前保存されたデフォルトの動作を実行します。- デバイスのセキュリティは解除されます。デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は決して止まらない。- InitTarget() 終了 - 2.15 秒かかりました - ID 0x2BA01477 の SW-DP を検出しました - DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - CPUへの接続に失敗しました。リセット状態で接続を実行します。- DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - Coresightの設定でコアが見つからず - エラー:接続に失敗しました。ターゲットとの接続が確立できませんでした。- エラー: 接続に失敗しました Re: NXPS32k144EVB issue ハイ 考えられる原因: フラッシュセキュリティはフラッシュ構成フィールドで設定されます。 S32K144では、セキュリティ状態はフラッシュセキュアレジスタから得られます  FSEC  。これはリセット時にフラッシュ構成フィールドのフラッシュセキュリティバイトから読み込まれます。デバイスは安全である場合  SEC  安全でない  0b10  です。 一括消去が必要ですが、ブロックされています。 S32K144は通常、関連する FSEC ビット によって有効化された Mass Erase または Verify Backdoor Access Key によって安全解除されることがあります。しかし、もし CSEcはパーティショニングによって有効化されました 、 一括消去はブロックされています 一括消去が有効になっている場合でも  MEEN/MEEM  。https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 CSEcが有効になっている場合、復旧にはCSEcデバッグ認証フローが必要です。 文書化された復旧手順は、CSEc パーティションを破壊することです。  CMD_DBG_CHAL  そして  CMD_DBG_AUTH  知識を持って  MASTER_ECU_KEY  その後、一括消去が再び可能になります。 。キーが不明で、デバイスがCSEcによる一括消去ブロックで保護されている場合、そのデバイスを復元する手段はありません。 。https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 私が試してみる手順は以下の通りです(順不同): このボードで過去にCSEc/セキュアブート/EEPROMパーティショニングのサンプルが実行されたことがある場合: CSEcのパーティショニングが関係している可能性があると想定してください。使用する  MASTER_ECU_KEY  キーを持っている場合は、以下の手順を実行してください。  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → CSEcパーティションを破壊 → 一括消去。 CSEcが意図的に有効化されていなかった場合: もう一度、非常に低いSWD速度で基本的なJ-Link復帰を試し、電源を入れ直し、リセットを正しくアサート/リリースし、  unlock Kinetis  。これはマス消去が実際に許可されている場合にのみ機能します。   unlock Kinetis  マスイレイスを有効にしていれば動作するはずです。https://community.nxp.com/t5/S32K/S32K148-Unsecurity/mp/1182938 もしPEmicroやOpenSDAスタイルのフローで接続する方法があれば NXPは、PEmicroツールは Erase Flash Block で消去し、J-Linkは mass ease を用いて新しいプロジェクトを読み込むと述べているので、試す価値はあるかもしれません。この区別はCSEcが大量消去をブロックする場合に影響します。 リセットボタンが物理的にローレベルに保持されている場合: まずそれを直してください。リセット中にスタックしたターゲットもコアアタッチを妨げることがありますが、ログの繰り返しのセキュリティ/大量消去タイムアウトの方がより強力な手がかりです。 結論としては、これは通常の接続速度の問題ではなく セキュリティ/CSEc/大量消去によるブロック状態 ようです。CSEcが有効で  MASTER_ECU_KEY  がない場合は、実際の解決策は通常MCUを交換することです。 決定的な分岐は、CSEcパーティショニングが有効になっているかどうかです。  MASTER_ECU_KEY  CSEcパーティションを破壊して消去してください。そうしないと、保護されたS32K144は復元できない可能性があります。   よろしくお願いいたします ロビン
記事全体を表示
DCDxツールが無効になっています DCDの設定が無効になっているようです。それを可能にするために何がCANできるのでしょうか? ツールの互換性に問題があるのでしょうか? MCUXpresso IDE v25.6.136を使用中です。 SDK_26_03_00_FRDM-MCXA266から抽出したサンプルプロジェクトusb_cdcを開いています Re: DCDx Tool is disabled Hello サンプルに修正を加えているのか、それともSDKsからのインポートによる修正なしのサンプルなのか、確認を手伝ってもらえますか? おそらく、MCXA266が含まれていない古いバージョンのConfig Toolsを使用しているため、アップデートする必要があります。 バージョンを確認しましたが、エラーメッセージは表示されませんでした。バージョンを更新しました。 MCUXpresso IDEでは、設定ツールの更新はデフォルトで無効になっています。MCUXpresso IDEに統合されたConfig Toolsを更新するには、この投稿の指示に従ってConfigツールの更新を有効にしてください。 ウィンドウ>設定>インストール/更新>利用可能なソフトウェアサイト>MCUXpresso設定ツールを有効にする MCUXpresso IDEsの設定ツールを更新すること、 その後、利用可能なアップデートに関するウィンドウがいくつか表示されるので、それらを選択して次へ進み、ライセンス契約の条項に同意してください。 「Accept>Finish>Select All>Trust Selected>Restart MCUXpresso IDEをクリックしてください その後、再度試行してMCUXpressoのIDEs機能ウィンドウを表示し、バージョンを確認してください。 それがうまくいくか教えてください。もしダメなら、最新バージョンのConfig Tools(26.03)を手動でMCUXpresso Config Tools v26をインストールするのを手伝ってもらえますか?03、調査結果を教えてください。 敬具、ルイス Re: DCDx Tool is disabled こんにちは、 あなたは何を達成しようとしているのですか?DCDツール(デバイス構成データの略で、一部のI.MXRT10xxでしか利用できない)と、特定のツールはなく、一部のMCUのペリフェラルツールのサポート以外には特別なツールがないUSB CDCクラスを混同しているようです。 DCDツールはMCXAファミリでサポートされることはありません。私の知る限り、DCDツールに必要な機能を持っていません。 よろしくお願いします。 ペトル・フラドスキー 設定ツールチーム Re: DCDx Tool is disabled 現在、DCDファイルを手動で追加しています。なぜMCXAファミリのツールでサポートしてはいけないのでしょうか? Re: DCDx Tool is disabled 設定ツールを最新バージョンにアップデートしましたが、選択されたプロセッサ(TEE、デバイス設定)ではツールがサポートされていないことが依然として確認されています。バージョン26.03を使用しています。 Re: DCDx Tool is disabled DCDファイルには何が入っていますか?DCDツールは、デバイスの起動時にロードされるバイナリデータを生成します。現在、この機能がブートROMによって提供されるi.MXRT10xx向けに提供されています。
記事全体を表示
NXPS32k144EVB 问题 你好 我正在使用 NXPS32K144EVB 开发板,当我尝试使用 S32 Design Studio 烧录代码时,出现以下问题。如果我点击重试,同样的窗口会再次出现。我注意到,当我连接 JFlash 时也会出现这个问题。 正在连接... - 通过 USB 连接到探针/编程器设备 0 - 探针/编程器固件:J-Link V9,编译于 2021 年 5 月 7 日 16:26:12 - 探针/编程器序列号:69408845 - 已选择设备“S32K144”。- 目标接口速度:4000 kHz(固定) - VTarget = 3.288V - InitTarget() 开始 - 已选择 SWD。执行 JTAG -> SWD 切换序列。-闪存地址 0x400 - 0x40F 处的保护字节表示已设置读取保护。要连接调试器,设备必须处于非加密状态。注意:解除安全设置将触发对内部闪存的大规模擦除。- 执行之前保存在注册表中的默认行为。- 设备现在将处于不安全状态。- 解除设备安全保护时超时。抹除永无止境。- InitTarget() 结束 - 耗时 2.15 秒 - 找到 ID 为 0x2BA01477 的 SW-DP - DPIDR:0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 映射以查找所有可用的 AP - AP[2]:已到达 AP 映射的末尾,停止 AP 扫描 - AP[0]:AHB-AP(IDR:0x24770011) - AP[1]:JTAG-AP(IDR:0x001C0000) - 正在遍历 AP 映射以查找要使用的 AHB-AP - AP[0]:已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。非AHB-AP - 连接到CPU失败。执行RESET后的连接操作。- DPIDR:0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 地图以查找所有可用的 AP - AP[2]:已到达 AP 地图末尾,已停止 AP 扫描 - AP[0]:AHB-AP(IDR:0x24770011) - AP[1]:JTAG-AP(IDR:0x001C0000) - 正在遍历 AP 地图以查找要使用的 AHB-AP - AP[0]:已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。不是 AHB-AP - 在 Coresight 设置中找不到核心 - InitTarget() 开始 - 已选择 SWD。执行 JTAG -> SWD 切换序列。- 地址处的闪存中的保护字节。0x400 - 0x40F 表示已设置读取保护。要连接调试器,设备必须处于非加密状态。注意:解除安全设置将触发对内部闪存的大规模擦除。- 执行之前保存在注册表中的默认行为。- 设备现在将处于不安全状态。- 解除设备安全保护时超时。抹除永无止境。- InitTarget() 结束 - 耗时 2.15 秒 - 找到 ID 为 0x2BA01477 的 SW-DP - DPIDR:0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 映射以查找所有可用的 AP - AP[2]:已到达 AP 映射的末尾,停止 AP 扫描 - AP[0]:AHB-AP(IDR:0x24770011) - AP[1]:JTAG-AP(IDR:0x001C0000) - 正在遍历 AP 映射以查找要使用的 AHB-AP - AP[0]:已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。非AHB-AP - 连接到CPU失败。执行RESET后的连接操作。- DPIDR:0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 地图以查找所有可用的 AP - AP[2]:已到达 AP 地图末尾,已停止 AP 扫描 - AP[0]:AHB-AP(IDR:0x24770011) - AP[1]:JTAG-AP(IDR:0x001C0000) - 正在遍历 AP 地图以查找要使用的 AHB-AP - AP[0]:已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。不是 AHB-AP - 在 Coresight 设置中找不到核心 - 错误:连接失败。无法与目标建立连接。- 错误:连接失败 Re: NXPS32k144EVB issue HI 最可能的原因: 闪存网络安全设置在闪存配置字段中。 在 S32K144 上,网络安全状态来自闪存安全寄存器。  FSEC  该值在 RESET 时从闪存配置字段中的闪存安全字节加载;设备在以下情况下处于网络安全状态:  SEC  不是  0b10  。 需要进行批量擦除,但该操作被阻止。 S32K144 通常可以通过以下方式解除安全: 批量擦除 或者 验证后门访问密钥 如果这些路径已由相关系统启用  FSEC  比特 。然而,如果 CSEc是通过分区实现的。 , 批量擦除功能已被阻止 即使批量擦除功能似乎已启用  MEEN/MEEM  。https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 如果启用了 CSEc,则恢复需要 CSEc 调试认证流程。 已记录的恢复路径是使用以下命令销毁 CSEc 分区  CMD_DBG_CHAL  和  CMD_DBG_AUTH  具备以下方面的知识  MASTER_ECU_KEY  之后,批量擦除功能将再次可用。 。如果密钥未知,且设备启用了 CSEc 安全机制以阻止批量擦除,则该设备无法恢复。 。https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 我会按以下顺序尝试: 如果该板曾经运行过 CSEc / 安全启动 / EEPROM 分区示例: 假设可能涉及 CSEc 分区。使用  MASTER_ECU_KEY  如果你有密钥,流程如下:  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → 销毁 CSEc 分区 → 批量擦除。 如果并非有意启用 CSEc: 再次尝试使用非常低的SWD速度进行基本的J-Link恢复,断电重启,RESET已正确钳位/释放,并且  unlock Kinetis  。只有在允许批量擦除的情况下,这种方法才有效;  unlock Kinetis  如果启用批量擦除功能,应该可以正常工作。https://community.nxp.com/t5/S32K/S32K148-Unsecurity/mp/1182938 如果您仍然能够使用 PEmicro/OpenSDA 风格的流程进行连接: 或许值得一试,因为NXP指出PEmicro工具可以使用擦除功能。 擦除闪存块 而 J-Link 使用 批量擦除 加载新项目时;当 CSEc 阻止批量擦除时,这种区别可能很重要。 如果RESET物理保持低电平: 先解决这个问题。目标卡在RESET状态也可能阻止核心附加,但日志中反复出现的网络安全/批量擦除超时才是更有力的线索。 总之:这看起来像是一个 网络安全/CSEc/批量擦除阻止条件 这不是普通的连接速度问题。如果启用了 CSEc 并且您没有  MASTER_ECU_KEY  通常情况下,实际的解决方法是更换MCU。 决定性的分支在于是否启用了 CSEc 分区:启用后  MASTER_ECU_KEY  销毁 CSEc 分区并擦除;没有它,受保护的 S32K144 可能无法恢复。   此致敬礼, Robin
記事全体を表示
Backward compatibility TJA1051 Hi, i am using the TJA1050 in our products and replaced it with the TJA1051 because of this line in the datasheet: Today i was working on another project and came across the TJA1051 again and saw this: with Vio = VCC this means that VIH = 0,7*5=3,5V From the datasheet TJA1050: So in other words: TJA1050 and TJA1051 are not compatible on controller side. Somehow i missed that part and now our products are running with the TJA1051 (not the /3 variant) directly connected to a Kinetis MK22, which has 3.3V outputs. And it just works fine. So my question is: am i lucky that it works? Or is this a combination of the five volt tolerant MK22 pins and the internal pull up from the TJA1051 on TXD? I am not sure on which way to go now... Accept the fact that this is working or redesign all of our products? Thanks in advance! Greetings Jörn Re: Backward compatibility TJA1051 1:You can test the TX pin value during TJA1051 work. 2: change it into TJA1051/3,it should be no more risk.
記事全体を表示
LS1046/26 CPU向けu-bootのZeus 2019.04 +fslcからWrynose 2026.01への移行 こんにちは 私たちは「git://source.codeaurora.org/external/qoriq/」のu-bootコードバージョンを使用しています。当社のLS1046/26 CPU搭載カード向け。このU-Bootのバージョンは2019.04 +fslcです。また、セキュアブートもサポートしています。 現在、U-BootをWrynose 2026.01にアップグレードすることを検討しています。 既存のU-Bootソースコードは、元々は現在非推奨となっているリポジトリから入手したものです。 git://source.codeaurora.org/external/qoriq/. 最新のコードに使うのに適したGitリポジトリについてアドバイスいただけますか? また、アップグレード期間中のスムーズな移行を確実にするための重要なポイントやベストプラクティスを教えていただけると助かります。 Re: u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU こんにちは、 LS1046/LS1026AファミリのLayerscape U-Bootの場合、廃止されたCodeAurora QorIQツリーの代替は以下の通りです: git clone https://github.com/nxp-qoriq/u-boot.git NXPのガイダンスでは、次のような古いURLを置き換えることを推奨しています。 source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git​​​​​​​​​​​ 説明: ギットハブ。 com / nxp - qoriq / u - boot 。 git または、より一般的には、 source.codeaurora.org/external/qoriq/qoriq-components /qoriq/qoriq-components を置き換えます。ビルドスクリプト、マニフェスト、Yoctoレシピに入 github.com/nxp-qoriq 。 WrynoseベースのBSPなら、U-Bootだけをクローンするのではなく、QorIQ Yocto SDKのマニフェストから始めます。 リポジトリ init - u https: / //GitHub. com / nxp-qoriq / yocto-sdk - b wrynose repo sync -- force-sync 公開 nxp-qoriq/yocto-sdk リポジトリにはアクティブな wrynose ブランチが表示されています。同じリポジトリには一般的なリポジトリ-initの流れやYoctoのブランチ/リリースマッピングメカニズムが記載されています。 U-Boot に関しては、公開されている nxp-qoriq/u-boot リポジトリは QorIQ U-Boot ツリーです。取得したリポジトリページに表示されるデフォルトのブランチは lf_v2024.04 で、アクティブなブランチのリストには lf_v2026.04 も表示されます。表示されるタグには、 lf-6.12.49-2.2.0 、 lf-6.18.2-1.0.0 、 lf-6.18.20-2.0.0 などの最近の lf-* リリース タグが含まれます。実用的なルールとしては、 Wrynose Yoctoのマニフェストやレシピで選択したU-Bootのリビジョンを使う べきで、任意の「最新」U-Bootブランチを手動で取得するのではなく、 移行における重要な考慮事項: CodeAuroraへの参照をすべて移行する ビルドツリーで古いURLを検索してください: grep - rn 'source.codeaurora.org/external/qoriq' 。 source.codeaurora.org/external/qoriq/qoriq-components を置き換えてください。マニフェスト、ビルド構成、レシピに github.com/nxp-qoriq を使用します。 リリースマニフェストを信頼できる情報源として使用する BSPのアップグレードを行う際は、U-Boot、ATF、RCW、CST、カーネル、デバイスツリー、およびレシピを同じNXPリリースストリームに合わせておいてください。 NXPの現在のLayerscapeフローでは、一般的にATFとU-Bootを組み合わせて使用しており、スタンドアロンのU-Bootのみを使用しているわけではありません。 LS1046ARDBリファレンスからカスタムボードを再度移植してください。 LS1046カスタムボードの場合、NXPはLS1046ARDB U-Bootのリファレンスファイル( configs/ls1046ardb_tfa_defconfig 、 arch/arm/dts/fsl-ls1046a-rdb.dts 、 board/freescale/ls1046ardb/ )を指しています。 旧式のカスタマイズについては、 include/configs/ls1046ardb.h とボードフォルダも確認してください。 既存の基板変更を、古い2019.04コードを丸ごとコピーするのではなく、新しいデバイスモデル/Kconfig/DTS構造と照合してください。 セキュアブート:フルチェーンを再構築して再検証する Yoctoでは、セキュアブートイメージは以下を追加することで構築されます: DISTRO_FEATURES : append = " secure" そして実行中: bitbake secure - boot - qoriq CST、SRKH、OTPMK、RCW SB_EN 、ATF、および署名付きU-Bootイメージの処理は、製品版のヒューズ設定を変更する前に、開発用/非ヒューズユニットで全て再検証する必要があります。 2019.04以降、ブートフローに違いが生じる可能性があります。 LSDK 18.12以降、NXPはLayerscape RDB用のTF-Aブートフローを導入しました。 Boot ROM → BL2 → BL31 → U-Boot/UEFI → Linux 、従来のPPAスタイルのフローと比較して。 もし現在の製品に古いPPA/直接U-Bootの想定がまだ残っているなら、よく見直してください。 管理された移行ベースラインを維持する まず、変更を加えていないNXPのリファレンス構成を、ご使用のハードウェアの近くで起動してください。 その後、ボードのデルタを小グループに分けて適用します:RCW/SerDes、DDR、コンソール、ブートメディア、QSPI/eMMC/SD、イーサネット/FMan、環境レイアウト、セキュアブート。 古い2019.04 + fslcツリーとの互換性を宣言する前に、非セキュアブートパスとセキュアブートパスの両方を検証してください。 よろしくお願いします。
記事全体を表示
後方互換性 TJA1051 こんにちは、 私は製品にこのTJA1050を使い、データシートの以下の文言のためにTJA1051に置き換えました。 今日、別のプロジェクトに取り組んでいたところ、再びTJA1051に出くわし、以下の内容を見つけました。 Vio = VCC の場合、VIH = 0.7 * 5 = 3.5V となります。 データシートTJA1050より: つまり、TJA1050とTJA1051はコントローラ側で互換性がないということです。 なぜかその部分を見落としていたのですが、今ではTJA1051(/3バリアントではなく)をKinetis MK22に直接接続し、3.3V出力で製品は動作しています。 そして、それは何の問題もなく機能します。 SO質問ですが、うまくいっているのは幸運でしょうか? それともこれは、5ボルト耐性のMK22ピンと、TXD上のTJA1051による内部プルアップ抵抗の組み合わせによるものなのでしょうか? 今はどちらの方向へ進むべきか迷っています…。 これがうまくいっていることを受け入れるべきか、それともすべての製品を再設計すべきか? よろしくお願いいたします! ご挨拶 ヨルン Re: Backward compatibility TJA1051 1:作業中にTXピン値をテストTJA1051。 2:TJA1051/3に変更すれば、リスクはなくなるはずです。
記事全体を表示
NXPS32k144EVB issue Hello i am using nxps32k144evb board when i try to flash code using s32 design studio following issue occure and if i press retry same window again appear one this i notices when i connect jflash  Connecting ... - Connecting via USB to probe/ programmer device 0 - Probe/ Programmer firmware: J-Link V9 compiled May 7 2021 16:26:12 - Probe/ Programmer S/N: 69408845 - Device "S32K144" selected. - Target interface speed: 4000 kHz (Fixed) - VTarget = 3.288V - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Attach to CPU failed. Executing connect under reset. - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Could not find core in Coresight setup - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Attach to CPU failed. Executing connect under reset. - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Could not find core in Coresight setup - ERROR: Failed to connect. Could not establish a connection to target. - ERROR: Connect failed Re: NXPS32k144EVB issue Hi Most likely causes: Flash security is set in the Flash Configuration Field. On S32K144, the security state comes from the Flash Secure Register  FSEC  , which is loaded from the flash security byte in the Flash Configuration Field at reset; the device is secure when  SEC  is not  0b10  . Mass erase is required but is being blocked. S32K144 can normally be unsecured by Mass Erase or Verify Backdoor Access Key , if those paths are enabled by the relevant  FSEC  bits . However, if CSEc was enabled by partitioning ,  mass erase is blocked , even if mass erase appears enabled in  MEEN/MEEM  . https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 If CSEc is enabled, recovery requires the CSEc debug-auth flow. The documented recovery path is to destroy the CSEc partition using  CMD_DBG_CHAL  and  CMD_DBG_AUTH  with knowledge of  MASTER_ECU_KEY  ; after that, mass erase becomes available again . If the key is not known and the device is secured with CSEc blocking mass erase, there is no recovery path for that device . https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 What I would try, in order: If this board ever ran CSEc / secure boot / EEPROM-partitioning examples: assume CSEc partitioning may be involved. Use the  MASTER_ECU_KEY  flow if you have the key:  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → destroy CSEc partition → mass erase. If CSEc was not intentionally enabled: try a basic J-Link recovery once more with very low SWD speed, power-cycle, reset asserted/released correctly, and  unlock Kinetis  . This only works when mass erase is actually allowed;   unlock Kinetis  should work if mass erase is enabled. https://community.nxp.com/t5/S32K/S32K148-Unsecurity/m-p/1182938 If you still have any way to connect using a PEmicro/OpenSDA-style flow: it may be worth trying because NXP notes that PEmicro tools erase using Erase Flash Block , while J-Link uses mass erase when loading a new project; that distinction can matter when CSEc blocks mass erase. If reset is physically held low: fix that first. A target stuck in reset can also prevent core attach, but your log’s repeated security/mass-erase timeout is the stronger clue. Bottom line: this looks like a security/CSEc/mass-erase-blocked condition , not a normal connection-speed problem. If CSEc is enabled and you do not have the  MASTER_ECU_KEY  , the practical answer is usually to replace the MCU. The decisive branch is whether CSEc partitioning was enabled: with the  MASTER_ECU_KEY  , destroy the CSEc partition and erase; without it, the secured S32K144 is likely unrecoverable.   Best Regards, Robin
記事全体を表示
DCDx 工具已禁用 DCD配置似乎已被禁用。如何才能实现这一点? 是工具兼容性问题吗? 使用 MCUXpresso IDE v25.6.136。 打开从 SDK_26_03_00_FRDM-MCXA266 中提取的示例项目 usb_cdc Re: DCDx Tool is disabled Hello 能否请您确认一下,您是否对示例进行了修改,还是直接从 SDK 导入的示例未经任何修改? 可能是您的配置工具版本过旧,其中不包含 MCXA266,您需要更新。 我检查了我的版本,没有出现错误信息。我已经更新了版本。 在 MCUXpresso IDE 中,配置工具更新默认处于禁用状态。要更新 MCUXpresso IDE 中集成的配置工具,请按照本文中的说明启用配置工具更新。 窗口>首选项>安装/更新>可用软件站点>启用MCUXpresso配置工具 更新MCUXpresso IDE中的配置工具 之后可能会出现一些更新提示窗口,选择更新并点击“下一步”,然后接受许可协议条款。 点击“接受”>“完成”>“全选”>“信任所选”>“重启 MCUXpresso IDE”。 然后请重试并再次查看 MCUXpresso IDE 功能窗口以确认版本。 如果这样可以解决问题,请告诉我;如果不行,能否请您手动安装最新版本的 Config Tools (26.03) MCUXpresso Config Tools v26.03,并告知我您的发现。 此致敬礼,路易斯 Re: DCDx Tool is disabled 我已将配置工具更新到最新版本,但仍然看到所选处理器不支持该工具:TEE,设备配置。使用 26.03 版本。 Re: DCDx Tool is disabled 你好, 你想达到什么目的?您似乎将 DCD 工具(代表设备配置数据,仅适用于部分 I.MXRT10xx)与 USB CDC 类混淆了,后者没有任何特殊工具,只是外设工具对某些 MCU 提供支持。 DCD 工具永远不会支持 MCXA 系列,因为据我所知,它不具备 DCD 工具所需的功能。 此致 彼得·赫拉德斯基 配置工具团队 Re: DCDx Tool is disabled 目前我正在手动添加DCD文件。为什么 MCXA 系列工具不支持它? Re: DCDx Tool is disabled 你的DCD文件里有什么内容?DCD 工具生成在设备启动期间要加载的二进制数据,目前适用于 i.MXRT10xx,该功能由启动 ROM 提供。
記事全体を表示
后向兼容性 TJA1051 您好, 我的产品中使用的是TJA1050,但由于数据手册中的这一行,我将其替换为TJA1051: 今天我在做另一个项目的时候又遇到了TJA1051,然后看到了这个: 当 Vio = VCC 时,这意味着 VIH = 0.7 * 5 = 3.5V 数据手册 TJA1050 内容如下: 换句话说:TJA1050 和 TJA1051 在控制器方面不兼容。 不知何故我错过了那部分,现在我们的产品使用的是直接连接到 Kinetis MK22 的 TJA1051(不是 /3 版本),而 Kinetis MK22 有 3.3V 输出。 而且它运行良好。 所以我的问题是:我运气好吗?它居然奏效了? 或者这是由于 MK22 引脚具有 5 伏耐压能力,以及 TXD 上的 TJA1051 内部上拉电阻共同作用的结果? 我现在不知道该往哪个方向走了…… 接受现状,还是重新设计我们所有的产品? 提前感谢! 您好 约恩 Re: Backward compatibility TJA1051 1:您可以在 TJA1051 工作期间测试 TX 引脚值。 2:换成 TJA1051/3,应该就没有风险了。
記事全体を表示