Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
AT&Tの担当者と直接話すにはどうすればよいですか? 自動音声メニューにうんざりして、実際に人と話したいと思いませんか?AT&T カスタマーサポートチーム (米国)
查看全文
运行 OpenGL 程序时出现多次 GPU 崩溃/无效输出 您好, 三年多来,我们一直在销售基于 i.MX6QuadPlus 的设备,该设备基于 Yocto hardknott 构建,并搭载了基于 Weston 的 Qt 6.3.2。随着产品的发展,我们开始收到越来越多的用户崩溃报告,但我们在自己的代码或 Qt 中都找不到原因。我们已经修复了一些问题——通过重新调整 DDR 时序、禁用某些视图中的阴影、增加一些内部缓冲大小以及使用 GPU_VIV_EXT_RESOLVE=0 运行应用程序——但我们仍然会收到报告,其中很大一部分与 GPU 相关,并在日志中显示如下: 内核:*** GPU DRV 配置 *** 内核:Galcore 版本 6.4.3.336687 内核:Galcore 选项: ... 内核: [galcore]: 停止驱动程序以保持场景。 这是驱动程序自身的挂起报告——监测计时器未见任何进展,gckKERNEL_Recovery 转储 GPU 状态,并且由于 recovery=0,驱动程序停止服务而不是重置核心(recovery=1 对我们来说不是一个选项,因为需要重新启动每个 GUI 应用程序)。屏幕彻底冻结,即使使用 SIGKILL 也无法杀死 Weston,唯一的解决办法是断电——这对我们的客户来说非常糟糕。 由于我们已经在 Qt 和应用程序层面尝试了很多方法,但都只得到了变通方案,所以我决定停止测试高级功能,而是直接测试 OpenGL ES 入口点——如果它们运行正常,那就是我们的问题;如果它们运行不正常,那就是驱动程序/硬件的问题(至少是部分问题)。 我使用 VK-GL-CTS( https://github.com/KhronosGroup/VK-GL-CTS )实现了这一点。首先移植到 Rust 以便于交叉编译(仍在进行中,因此目前只能检查大约一半的相关情况)。案例名称与上游 deqp-gles2/gles3/gles31 相同,并且在 Mesa llvmpipe 和运行 Ubuntu 24.04 的普通笔记本电脑上,所有测试均通过,并且也安装了 mesa 驱动程序,因此板上的失败说明板存在问题。我利用周末时间在硬件上运行了它,并在人工智能的帮助下,找到了 14 个不同的缺陷并将其最小化,每个缺陷现在都可以独立复现:一个没有任何依赖项的纯 Rust 项目,仅使用 cargo build 构建,GLSL 代码放在单独的文件中。 (只需运行- 在本地运行,您可以提取仅 arm部分,只需构建步骤即可收集二进制文件(您需要先安装cargo install --locked cargo-zigbuild )) 6.4.11.p4 版本(我们能为该部件构建的最新驱动程序)仍然存在问题: 0001 GPU 锁死 - synchronization.inter_invocation.ssbo_atomic_read_write,独自一人,站在一块刚启动的板上。只有重启才能清除它,而且该进程无法终止,因此重启本身需要 8-10 分钟。 0002 GPU 锁定 - synchronization.inter_invocation.ssbo_atomic_overwrite,单独发生。 0003 GPU 锁死 - 二十个 synchronization.inter_invocation.* 中的十个个别案例单独存在,其他十个案例则不存在,因此这是一个边界,而不是“计算出错”。所有原子 ssbo/图像变体。所有二十台设备都进行了十次运行,每次运行都是从它自己的重启开始。 0010 链路故障 - 7 个 ubo 案例,其中两个阶段读取了同一个 std140 块的 47 个成员。单独一个阶段可以连接,但两个阶段一起连接则不行,glGetProgramInfoLog 为空,并且没有任何东西接近驱动程序本身报告的限制(每个阶段 3 个块 vs 16 个,704 字节 vs 65536)。至少需要 47 次阅读,46 个链接。 0011 结果错误 - shaders.invariance.highp.loop_*:两个着色器使用相同的表达式计算不变的 gl_Position,结果相差几个像素的深度。 0013 错误状态枚举 - fbo.completeness.size.distinct:请求的上下文是 ES 2.0,但报告的是 ES 3.1,然后根据 ES 2.0 规则回答完整性问题,并返回一个 ES 3.x 未定义的枚举。 已在 6.4.3.p2 版本中修复-> 6.4.11.p4 跳转: 0004 GPU 死锁 - image_load_store.cube.qualifiers.*_r32f(旁边的 r32ui/r32i 型号都没问题) 0006 GPU 锁死 - image_load_store.* 每当图像分层时都会发生,21 层中有 8 层发生,而 2D 图像上 7 层中没有发生,间歇性发生 0005 客户端冻结 - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange 永远不会返回 0014 客户端冻结 - 同样,通过 upload_buffer.empty_command 命令实现。一旦调度任务已经完成映射 0007 结果错误 - 计算着色器中包含十八个 && 的链,并且声明了一个原子计数器,当每个项都为真时,结果为假(2007 个 ssbo.layout 案例中的 44 个) 0008 编译器 - 保留字表适用于错误的语言版本,正反两面都是如此。 0009 结果错误 - 对于两个相等的向量,vec3 == vec3 为 false,这是通过 inout 参数返回的结构体成员的结果。 0012 编译器 - mediump vec2(1.0,1.0) 可以编译,其中 ESSL 1.00 语法中没有精度限定符的位置。 两次测试均在同一块主板上进行:i.MX6QP 硅 rev 1.0,2 GiB DDR,LVDS 1280x1024@60,Weston on fbdev with use-g2d=1,GL_RENDERER "Vivante GC2000+"。 旧版本:hardknott,BSP imx-5.10.52-2.1.0,内核版本 5.10.52galcore 6.4.3.p2.336687,imx-gpu-viv 1:6.4.3.p2.2-aarch32,Weston 9.0.0.imx,Qt 6.3.2 新增:wrynose,BSP imx-6.18.20-2.0.0,内核 6.18.20,galcore 6.4.11.p4.1190909,imx-gpu-viv 1:6.4.11.p4.6-aarch32Weston 10.0.5.imx,Qt 6.11.0 CONFIG_MXC_GPU_VIV=y,recovery=0 和 stuckDump=0 在两者上;超时时间为 20000 -> 30000 毫秒,并且 6.4.11.p4 添加了 softReset=1。 所以版本升级有所帮助,但一些问题仍然存在。由于 i.MX6 的供货情况,我们将很快迁移到 i.MX8,但我们现有的用户群无论如何都会继续使用 i.MX6 硬件,因此我们希望这些问题在未来能够得到解决。 这些问题有没有可能在新版本的驱动程序中得到修复,即使这意味着我们需要升级 Yocto 版本? 我担心 i.MX8 也可能存在某种程度的此类问题,那么是否已经对 Vulkan/OpenGL CTS 进行过测试,现在是否正在进行测试,或者是否有计划进行测试?因为如果不通过那项测试(再加上一些模糊测试,例如随机执行cts函数),我认为我们遇到的随机崩溃问题无法在驱动程序之上的层级中得到修复。 Re: Several gpu crashes/invalid output, when running opengl es cts 你好, i.MX 6/7 的最新公开发布驱动程序是 imx-gpu-viv 6.4.11.p4.6 ,随附 wrynose 电路板支持包 (imx-6.18.20-2.0.0)。发行说明将此次升级描述为对 i.MX 6/7/8 系列进行了“错误修复和性能优化”,这与您的观察结果相符,即 .p2 和 .p4 之间解决了 14 个缺陷中的 8 个。是的,这确实正在发生——但各个平台都有一些重要的限制条件。对于配备 Vivante (VSI) GPU 的 i.MX8,CTS 正在运行。作为每个版本候选周期的一部分,内部 Linux Factory 测试流程都会针对 i.MX8 板运行 opengl-es-cts 和 vulkan-cts 软件包。在 Linux Factory Jira 项目 CTS 中跟踪在 i.MX8M Nano、i.MX95 上发现的缺陷。这意味着 i.MX8M Plus、i.MX8QuadMax 等产品中的 Vivante GC7000 系列 GPU 在每次正式版本前都会经过系统的符合性测试。 适用于配备 Mali / OSS Mesa 的 i.MX9 版本说明明确指出,对于采用 Mesa OSS GPU 堆栈的 i.MX 95/952:“OpenGL ES11、Vulkan 1.4.5 和 OpenCL 3.0 的基本功能可以正常工作,但一致性测试未通过。” 这i.MX9 上的 Mali DDK 默认路径通过了 CTS 测试,但开源 Panfrost/PanVK 路径仍在努力使其符合标准。 特别是对于 i.MX6 (GC2000+) 而言,CTS 的覆盖范围非常有限。 在当前的 Linux Factory 流水线中,没有发现针对 GC2000+ 的系统性 deqp/CTS 运行的内部证据。GC2000+ 仅支持 OpenGL ES 3.0(不支持 3.1/3.2)。测试基础设施似乎针对的是较新的 i.MX8/9 板。您与 VK-GL-CTS 的合作是对该特定 IP 进行的最彻底的一致性级别测试,在任何内部渠道中都是可见的。   总之:虽然不能保证未来会发布 i.MX6 驱动程序补丁,但通过您开放的支持帖子提供独立的重现步骤才是正确的做法。对于您的 i.MX8 迁移,Vivante GC7000 系列的兼容性情况比 GC2000+ 要好得多,并且系统性的 CTS 测试是发布过程的一部分——尽管即便如此, galcore 6.4.11.p4 中的活跃驱动程序错误仍然不断被发现和提交。   此致 Re: Several gpu crashes/invalid output, when running opengl es cts 我没看到附件,看来是我忘记添加了,所以我再添加一次。
查看全文
关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug 我使用的GUI Guider版本是2.0.0。当我为Top Layer添加事件时,生成的gg_event_layer_top.c中关于Top Layer的事件回调函数名会异常,目前的情况是,事件回调函数名的中间会被插入一对括号,就像这样“ static void lv_layer_top () _event_handler ( lv_event_t * e )”。事实上,对于Bottom Layer也存在相同的问题,而Screens则未出现类似的问题。希望能尽快修复bug。谢谢! 回复: 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug Hi @UENG , 感谢您的反馈,该问题已经在V2.0.1中修复,请下载安装该版本:GUI Guider Best Regards, Wenbin
查看全文
OpenGL es ctsを実行しているときに、いくつかのGPUがクラッシュしたり無効な出力が出たりします こんにちは、 3年以上にわたり、私たちはi.MX6QuadPlusでデバイスを出荷してきました。これはYocto hardknott上で構築され、WestonのQt 6.3.2で構築されています。製品が成長するにつれて、ユーザーからクラッシュ報告が増え、自分たちのコードやQtの中に原因が見つかりませんでした。一部は修正できました。DDRのタイミングを調整したり、特定のビューでシャドウを無効にしたり、内部バッファのサイズを増やしたり、アプリをGPU_VIV_EXT_RESOLVE=0で動かしたりしましたが、それでもレポートは届き、その多くはGPU関連でログに次のように表示されます。 カーネル: *** GPU DRV 設定 *** カーネル:Galcore バージョン 6.4.3.336687 カーネル:Galcoreオプション: ... カーネル:[galcore]: シーンを保つためにドライバを止めてください。 これはドライバ自身のハングレポートで、モニタータイマーは進行状況を認識せず、GPUの状態をダンプgckKERNEL_Recovery、recovery=0なのでドライバはコアをリセットせずサービスを停止します(recovery=1は私たちには選択肢にありません。なぜなら、すべてのGUIアプリケーションを再起動する必要があるからです)。画面は完全にフリーズし、ウェストンはSIGKILLを使っても倒せないことが多く、唯一の脱出方法は停電で、これはお客様にとって非常に悪いことです。 Qtやアプリケーションレベルで多くのことを試しましたが、回避策しか得られなかったため、高レベルの機能テストをやめ、OpenGL ESのエントリポイントを直接テストすることにしました。正常に動作すれば問題は私たちの責任、そうでなければドライバやハードウェアの故障(少なくとも部分的)です。 私はVK-GL-CTS( https://github.com/KhronosGroup/VK-GL-CTS )を使ってそれをやりました。クロスコンパイルを簡単にするために最初はRustに移植されました(まだ進行中で、関連するケースの約半分しか確認できませんでした)。ケース名は上流のdeqp-gles2/gles3/gles31と同じで、Mesa llvmpipeやUbuntu 24.04のカジュアルノートPC(Mesaドライバー付き)でもすべてパスされます。つまり、ボードの故障はボード自体の問題です。週末にハードウェア上で実行したところ、AIの助けを借りて14個の異なる欠陥を発見し、最小限に抑えることができました。それぞれが独立した再現可能なコードになっています。具体的には、依存関係のないシンプルなRustプロジェクト、cargoビルドのみ、そしてGLSLを独自のファイルに記述したものです。 (JUst Run - ローカルで実行、 Armパーツだけ を抽出して、ビルドステップのみでバイナリを集められます(最初の カーゴインストールが必要で、ロックされたカーゴ・ジグビルド) この部分のために構築可能な最新ドライバー、6.4.11.p4で依然として問題が残っています: 0001 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_read_write,一人きり、新しく履き替えたばかりのボードの上で。再起動しないとクリアできませんし、プロセス自体は壊せないので8〜10分かかります。 0002 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_overwrite、単体で。 0003 GPUのロックアップ - 20 synchronization.inter_invocation中10件。*ケースは単独で起こるが、他の10個はそうではないため、これは境界であり「計算が壊れている」とは言えない。すべての原子SSBO/イメージのバリアント。20人全員がそれぞれ10回のレースを制覇し、すべてのレースはリブート版から始まった。 0010リンク障害 - 同じstd140ブロックの47個のメンバーが両段階で読み取れた7件のUBOケース。どちらのステージだけでもリンクしますが、一緒にはリンクしません。glGetProgramInfoLogは空で、ドライバー自体が報告する制限(ステージあたり3ブロック対16ブロック、704バイト対65536バイト)はほとんどありません。最低でも47回の閲覧と46のリンクが必要です。 0011 結果が間違っています - shaders.invariance.highp.loop_*:同じ式から不変なgl_Positionを計算する2つのシェーダーが、深度に関して数ピクセルの差を生じます。 0013 ステータス列挙型が間違っています - fbo.completeness.size.distinct: ES 2.0 として要求されたコンテキストが ES 3.1 を報告し、その後 ES 2.0 ルールで完全性に応答し、ES 3.x で定義されていない列挙型を返します。 6.4.3.p2で修正済み-> 6.4.11.p4 ジャンプ: 0004 GPUロックアップ - image_load_store.cube.qualifiers.*_r32f(隣にあったr32ui/r32iは問題なかった) 0006 GPUのロックアップ - image_load_store.* 画像がレイヤー化されるたびに、21枚中8枚、2Dでは7枚中0枚、断続的です 0005 クライアントフリーズ - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange は決して戻りません 0014 クライアントフリーズ - upload_buffer.empty_command 経由、同じ一度、配車がすでにマッピングされている場合 0007 誤った結果 - 18 &&の連鎖で、原子カウンタも宣言される場合、すべての項が真である場合にfalseになります(2007年のssbo.layoutケース中44件) 0008 コンパイラ - 保留ワードテーブルは間違った言語バージョン用、両方向に適用されます 0009 誤った結果 - 入力パラメータを介して返される構造体メンバーに対して、2 つの等しいベクトルに対して vec3 == vec3 が false になります 0012 コンパイラ - mediump vec2(1.0,1.0) コンパイルは成功するが、ESSL 1.00 文法には精度修飾子を入れる場所がない。 両方のテストは同じボードで行いました:i.MX6QPシリコンリビジョン1.0、2 GiB DDR、LVDS 1280x1024@60、fbdev上のWeston、use-g2d=1、GL_RENDERER "Vivante GC2000+"。 古い: hardknott、BSP imx-5.10.52-2.1.0、カーネル 5.10.52、Galcore 6.4.3.p2.336687、IMX-GPU-VIV 1:6.4.3.p2.2-aarch32,Weston 9.0.0.imx、Qt 6.3.2 new: wrynose、BSP imx-6.18.20-2.0.0、kernel 6.18.20、galcore 6.4.11.p4.1190909、imx-gpu-viv 1:6.4.11.p4.6-aarch32,Weston 10.0.5.imx、Qt 6.11.0 CONFIG_MXC_GPU_VIV=y、recovery=0、stuckDump=0 の両方でタイムアウトが発生し、20000 -> 30000 ms となり、6.4.11.p4 で softReset=1 が追加されました。 バージョンアップは助けになりますが、いくつかの問題は残っています。i.MX6の入手可能性のため、近いうちにi.MX8に移行する予定ですが、既存の基盤はいずれにせよi.MX6のハードウェアを保持しているので、将来的にこうした問題が解決されるのを見たいです たとえYocto版をやめざるを得なくても、新しいドライバーでこれらの問題が修正される可能性はありますか? この問題はi.MX8にもある程度存在しているのではないかと懸念していますが、Vulkan/OpenGL CTSでテストは行われていますか?現在行われているのか、それとも計画されているのでしょうか?それを通さなければ(さらにcts関数のランダム実行などのファズ処理も)、ドライバーの上層でランダムクラッシュは修正できないと思います Re: Several gpu crashes/invalid output, when running opengl es cts こんにちは、 i.MX 6/7の最新公開ドライバーは imx-gpu-viv 6.4.11.p4.6 で、wrynose BSP(imx-6.18.20-2.0.0)が付属しています。リリースノートでは、そのジャンプが i.MX 6/7/8ラインの「バグ修正、パフォーマンス最適化」をもたらしたと説明されており、これはあなたの観察と一致しています。 .p2 と .p4 の間に14の欠陥のうち8つが解決されたという点です。そして確かに、それは行われていますが、プラットフォームごとに重要な条件があります。Vivante(VSI)GPU搭載のi.MX8では、CTSが動作しています。Linux Factory内部のテストパイプラインでは、各リリース候補サイクルの一環として、i.MX8ボードに対して opengl-es-cts および vulkan-cts パッケージの両方を実行させます。発見された欠陥は、Linux Factory JiraプロジェクトCTSのi.MX8M Nano、i.MX95上で追跡されています。これは、i.MX8M Plus、i.MX8QuadMaxなどに搭載されているVivante GC7000シリーズGPUは、各GAリリース前に体系的な適合性テストを受けていることを意味します。 i.MX9(Mali / OSS Mesa搭載)向け リリースノートには、Mesa OSS GPUスタック搭載 i.MX 95/952について明記されています:「OpenGL ES11、Vulkan 1.4.5、OpenCL 3.0の基本機能は動作していますが、適合性テストは合格していません。」そのi.MX9上のMali DDKのデフォルトパスはCTSに合格していますが、オープンソースのPanfrost/PanVKパスはまだ適合化の作業中です。 i.MX6 (GC2000+) に関しては、CTS のカバー範囲は最小限です。 現在のLinux Factoryパイプラインにおいて、GC2000+に対して体系的なdeqp/CTS実行が行われているという内部証拠は見つかりませんでした。GC2000+はOpenGL ES 3.0のみをサポートしており(3.1/3.2はサポートしていません)、テストインフラストラクチャは新しいi.MX8/9ボードをターゲットにしているようです。VK-GL-CTSでの作業は、この特定のIPに対する内部チャネルで見られる最も徹底した適合レベルのテストです。   結論として、FUTURE i.MX6ドライバーパッチが保証されているわけではありませんが、オープンサポートThreadを通じてスタンドアロンのリプロダクションを提供するのが正しい方法です。i.MX8移行に関しては、Vivante GC7000シリーズの適合状況がGC2000+よりも大幅に優れており、体系的なCTSテストもリリースプロセスの一部となっていますが、それでもなお galcore 6.4.11.p4 のドライバーバグは依然として発見・報告されています。   よろしくお願いします。 Re: Several gpu crashes/invalid output, when running opengl es cts 添付ファイルが見当たらず、追加を忘れたようだったので、もう一度追加しました
查看全文
KE18F512VLH16 ECC RAM シングルビット訂正 先日@sean_dvorscakさんが投稿された記事( KE1 ECC RAM シングルビット訂正)に関連して、追加の質問があります。 @Celeste_Liuは答えた。 ->> オプションのスクラブを実装する場合は、アクセスを実際のアクセスサイズやスクラブの粒度に基づいてアライメントし、生の MCM_LMFAR 値に盲目的に合わせないでください。また、アドレスを適切にアラインメントし、アクセスサイズが有効であることを確認しない限り、固定4バイトのアクセスは使わないでください。 MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを判定できますか?もしそうなら、これをMCM_LMFARと組み合わせて読み取り・正解・書き込み操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、同じアドレスに8ビットの書き込みをして誤りを訂正することは可能でしょうか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビット書き込みを行うことはできますか? Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 あなたの投稿を拝見しました。この件について少し調査させてください。詳しい情報が分かり次第、改めてご連絡いたします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは@Celeste_Liu - P7は最終アプリケーションの名前です。 Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 ご質問につきましては、社内の担当チームに調査を依頼する必要があります。当社の手続きに従い、 最終的な申請 名を記載してください。 ご協力ありがとうございました。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @Celeste_Liu さん、この件について何か進展はありますか? Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 申し訳ありませんが、まだ社内からの返答がありません。 再度連絡を取り、これを最優先事項として取り組みます。何か返事が来たらすぐにお知らせします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @rseigle77 さん、 ご辛抱いただきありがとうございます。社内から返信がありました。 ECCの「訂正」とは、SRAMに格納されている基となるビットを修正するのではなく、修正されたデータをCPUに返すことを意味します。自動修復には、別途スクラブ/ライトバック機構が必要です。 ソフトウェアスクラブを使用する際の推奨フロー: ECCは読み取り時にデータを訂正します。 シングルビットエラー割り込み/ステータスが発生します。RM 6.3.1.1を参照してください。割り込みの発生源を特定する。MCM_LMPECR [ER1BR] =1 ソフトウェアが故障アドレスを読み込みます。MCM_LMPEIR[PEELOC] = 5'h08 - SRAM_Lからの1ビット訂正可能なECCイベントで、MCM_LMFAR故障アドレスを示します。 ソフトウェアは修正された値を同じアドレスに書き換えます。 新たなECC症候群が生成され、保存される。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction @Celeste_Liu さん、ご回答ありがとうございます。しかし、 MCM_LMFATR[PEFSIZE]に関する私の質問には答えていません。 「MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを決定できますか?もし可能なら、これをMCM_LMFARと併用して読み込み・正書き書き返し操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、その後同じアドレスに8ビットの書き込みを行いエラーを訂正できますか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビットの書き込みを行うことは可能でしょうか?
查看全文
How to Speak Directly to an AT&T Agent? Tired of automated menus and just want to talk to a real person? AT&T Customer Support Team ((USA))
查看全文
画面の最上位レイヤーにおけるイベントコールバック関数名の生成が正しく行われないことに関連するバグ。 私が使用している GUI Guider のバージョンは 2.0.0 です。Top で作業しているときに...レイヤーにイベントを追加する際、生成されるgg_event_layer_top.cファイル内のトップレイヤーのイベントコールバック関数名が異常です。現在、イベントコールバック関数名の途中に括弧が挿入されており、例:「static void lv_layer_top () _event_handler ( lv_event_t * e )」のようになっています。実際、ボトムレイヤーでも同様の問題が発生しますが、スクリーンでは同様の問題は発生しません。このバグが早急に修正されることを願っています。よろしくお願いいたします。 回复: 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug こんにちは@UENGさん フィードバックありがとうございます。この問題はバージョン2.0.1で修正されました。GUI Guiderをダウンロードしてインストールしてください。 よろしくお願いします、 ウェンビン
查看全文
S32K358 中TCP 客户端握手包接收不到 现在我建立了一个TCP 客户端线程,当执行到握手端函数时,通过wireshark 能够看到客户端发给服务器得报文,也能看到服务器给客户端得报文,但是最后一步TCp客户端没有返回帧。我一直监控GMAC接收中断,发现一直卡死在循环中。MCU TCP客户端一直没有接收到最后的确认返回帧,所以没有发出去最后一帧的确认握手协议。是什么原因那? Re: S32K358 中TCP 客户端握手包接收不到 你好@sunshine88 , 你使用的是RTD包中提供的lwip示例吗?如果可以,能否分享一下您的即饮版本? 您能否也分享一下RxStatus 返回的是哪个状态? 根据您在另一篇社区帖子( LWIP TCP/IP 服务器客户端实践)中的要求,我已经向您发送了一条包含 S32K148 的 Lwip_HandsOn 项目的私信。 此致, 朱利安
查看全文
S32K322およびS32K312:CMU割り込み、リセット反応、検出レイテンシに関するクエリ 故障 イベント情報 を それぞれの CMU インスタンス(CMU0、 CMU1、 CMU2) に マッピング していただけますか? 割り込み ドキュメント には 合計 7回 の 割り込み が記載 されています が、 各 CMU インスタンス が どの 障害 イベント情報 と それに対応する 障害 アクション を 処理 しているかは 明確 ではありません 。 添付画像をご覧ください システムクロックの監視.png Interruptmapping.png 「リセット 反応 割り込み 」 の 正確な 意味 は 何 ですか ? この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア が 介入 できるように なるのでしょうか? The clock monitoring レイテンシ can be configured from 1 µs to 1 ms. レイ テンシ を 低 くすることで 、 デバウンスやフィルタリング の時間を 短縮 し、 クロック 障害検出 の 感度 や速度 が 向上 するのでしょうか? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@ WadkarY 1. 障害発生 イベント情報 と それぞれ の CMU インスタンス (CMU0、 CMU1、 CMU2 ) と の マッピング を 提供していただけ ます か ? image.png image.png ご覧のとおり、CMU_FC_0、CMU_FM_1、CMU_FM_2のみが割り込みとして設定可能です。その他の割り込みは、標準のCMU割り込みとしてではなく、デフォルトでは破壊的なリセットの発生源として扱われるべきです。 CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMUリセット反応割り込み CMU_FC_4->AIPS_PLAT_CLK_FAIL CMUリセット反応割り込み CMU_FC_5->HSE_CLK_FAIL CMUリセット反応割り込み CMU_FC_6->CM7_CORE_CLK_FAIL CMUリセット反応割り込み 2. この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア の 介入 を可能にする のか? いいえ、MC_RGM/DCM破壊リセット割り込みバイパスが意図的に構成されていない限り、破壊リセット動作が予想されます。 以下にその例をご紹介します。 1. CMU_FC_4 は、AIPS_PLAT_CLK 周波数がしきい値を超えていることを検出します。 ↓ 破壊的リセットが主張され、同時にIRQ 215が発行されました。 ↓ ほぼ瞬時に MCUのリセット → リセットベクターからの再起動 ↓ ソフトウェアはMC_RGMを読みます。DES[AIPS_PLAT_CLK_FAIL]でリセット原因を特定します 3. レイテンシを低く設定することで、デバウンス/フィルタリング時間を効果的に短縮し、クロック障害の検出感度や検出速度を向上させることができますか? このパラメータはREF_CNTに関連しています。 •RCCR[REF_CNT]の値が高いほど測定ウィンドウが長くなり、監視対象のクロックチェックの精度が向上します。 ・RCCR[REF_CNT]の値が低いと測定ウィンドウが短くなり、FHHおよびFLLの反応が速くなりますが、報告結果の誤差が高まります。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@WadkarY 「CMUリセット反応割り込み」は、破壊的なリセットの前に発生する早期警告割り込みとして解釈すべきではありません。これらのCMU障害発生源の場合、破壊的リセット反応が設定されている場合、リセット要求とそれに対応するMC_RGMリセット反応割り込みはほぼ同時に生成されます。したがって、ソフトウェアは破壊的なリセットが起こる前にISRに入力し、復旧動作を完了することに依存してはなりません。 割り込みはMC_RGMリセットリアクション機構の一部であり、該当するリセットリアクションを割り込みにリダイレクト/バイパスできる構成に関連しています。ソースが破壊的リセットに設定されたままであれば、通常のソフトウェア戦略はリセットを待ってから、再起動後に対応するMC_RGMを確認することです。リセット原因を特定するためのDESステータスフラグ。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、チームの皆さん、 ご回答ありがとうございます。 しかし、「リセット反応割り込み」の意味と目的が理解できません。 CMU_FC_3->CORE_CLK_FAIL CMUリセット反応割り込み CMU_FC_4->AIPS_PLAT_CLK_FAIL CMUリセット反応割り込み CMU_FC_5->HSE_CLK_FAIL CMUリセット反応割り込み CMU_FC_6->CM7_CORE_CLK_FAIL CMUリセット反応割り込み これらの割り込みが、破壊的なリセットが生成される前にソフトウェア介入の機会を提供するかどうか、明確にしていただけますか? もしそうなら、ソフトウェアはどのように介入してリセットを防止または処理できるのでしょうか? そうでない場合、破壊的なリセットが直後に発生するのであれば、これらの割り込みを生成する目的は何ですか? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@WadkarY PLLには適用されないため、別途大偏差仕様は存在しません。PLLの出力周波数精度は、基準水晶の精度に、データシートのPLL特性表で「JPLL_acc」として定量化されている小さなジッタ成分を加えた値に等しくなります。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency お返事ありがとうございます。 PLLクロックの場合に可能な最大偏差について教えてもらえますか? データシートから、FIRCおよびSIRCの場合に許容される最大偏差、すなわち5%および10%の誤差が示されました。 DLLの逸脱については、DSには記載されていないので、もう少し説明していただけますか?
查看全文
LWIP TCP/IP Server-Client Hands-On       你好,我们有没有关于S32K358 的TCP 客户端握手例程,我现在遇到了一些问题,我在上一篇帖子中发出了这个问题。我看到之前有一篇帖子是关于S32K148相关问题的已解决: LWIP TCP/IP Server-Client Hands-On - NXP Community,不知道是否能够帮我我!       如果有,麻烦您发一份,我的邮箱是[email protected].。万分感谢!  Re: LWIP TCP/IP Server-Client Hands-On 你好@sunshine88 , S32K358 没有像 lwip_s32k148_HandsOn 工作坊那样的参考项目。我已向您发送了包含 lwip_s32k148_HandsOn_Server 和 lwip_s32k148_HandsOn_Client 的私信。 此致, 朱利安
查看全文
S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)? The interrupt documentation lists a total of seven interrupts, but it is not clear which failure events are handled by each CMU instance and their corresponding failure actions.  Please see attached images  system clock monitoring.png Interruptmapping.png What is the exact meaning of the "Reset Reaction Interrupt"? Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs? The clock monitoring latency can be configured from 1 µs to 1 ms. Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY 1.Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)? image.png image.png As can be seen, only CMU_FC_0,CMU_FM_1,CMU_FM_2 is configurable as an interrupt; the others should be treated by default as sources of a destructive reset, rather than as standard CMU interrupts. CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt 2.Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs? No, expect destructive reset behavior unless the MC_RGM/DCM destructive-reset interrupt bypass is deliberately configured for example: 1.CMU_FC_4 detects AIPS_PLAT_CLK frequency exceeding the threshold ↓  Destructive Reset asserted + IRQ 215 issued simultaneously ↓ Almost instantaneously MCU reset → Restart from Reset Vector ↓ Software reads MC_RGM.DES[AIPS_PLAT_CLK_FAIL] to identify the reset cause 3.Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster? This parameter is related to REF_CNT. •Higher values of RCCR[REF_CNT] results in longer measurement window, leading to better accuracy in monitored clock check. •Lower values of RCCR[REF_CNT] results in shorter measurement window, leading to faster FHH and FLL event response, but higher inaccuracy in reported result. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY The “CMU reset reaction interrupt” should not be interpreted as an early-warning interrupt before the destructive reset. For these CMU fault sources, when configured with their destructive-reset reaction, the reset request and the corresponding MC_RGM reset-reaction interrupt are generated essentially at the same time. Therefore, software must not rely on entering the ISR and completing recovery actions before the destructive reset occurs. The interrupt is part of the MC_RGM reset-reaction mechanism and is relevant to configurations where the applicable reset reaction can be redirected/bypassed to an interrupt. If the source remains configured for destructive reset, the normal software strategy is to allow the reset to occur and, after restart, check the corresponding MC_RGM.DES status flag to determine the reset cause. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Thank you for your reply. Could you help to understand the maximum deviation possible in case of PLL clock? From data sheet we got maximum deviation allowed in case of FIRC and SIRC i.e. 5% and 10% resp. Could you please clarify deviation of PLL as it is not mentioned in DS. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY There is no separate large deviation spec for the PLL because it is not applicable. The PLL output frequency accuracy equals the reference crystal accuracy, plus a small jitter contribution that the datasheet quantifies as "JPLL_acc" in the PLL characteristics table. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hello Team, thank you for your response. But I am not able to understand the meaning of "Reset Reaction Interrupt" and its purpose? CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt Could you please clarify whether these interrupts provide an opportunity for software intervention before a destructive reset is generated? If yes, how can the software intervene and prevent or handle the reset? If no, what is the purpose of generating these interrupts if a destructive reset will occur immediately afterward?
查看全文
S32k344 using green hills toolchain How can I relocate the vector section such that it stores vector table  in flash memory at 0x00400000, but at runs time, copies to DTCM memory and runs from there? How do I implement that in the Green hills linker file? Re: S32k344 using green hills toolchain Hi @XRen_Parker  Since this question is specifically related to the Green Hills toolchain and its integration, I would recommend contacting Green Hills directly. They should be able to provide the appropriate guidance and resources. https://support.ghs.com/ Regards, Lukas
查看全文
i.MX 9は「もう完成形」と言えるのでしょうか? 数年前にプロジェクトを始めたのですが、NXPの i.MX 9シリーズMPUがリリースされ始めていましたが、ほとんど入手困難だったため、重い i.MX 8 にしました。現段階では、これは私の必要以上の性能なので、もっと小型のMPUに移行したいと考えています。最小の1 i.MX 8を買うつもりでしたが、i.MX91が彼らのCPUの中で最も小さいです。より成熟した8よりも91の方が良いのではないかと考えていました。サーマルが一番気になるので、新品の方が良いと思いますが、まだ新しいので「まだ成熟している」かはわかりません。8に移植されるのがより公平な動きも動機になるかもしれません。 Re: Is i.MX 9 "there yet"? こんにちは、 @ceva156さん あなたのプロジェクトの主な目的は何ですか?現在どのIMX8シリーズ製品を使っていますか? BR Re: Is i.MX 9 "there yet"? こんにちは、 i.MX8のような重いマルチメディアGPU機能は不要です。i.MX91の方がずっと合いやすく、シンプルで低消費電力の設計ができるかもしれません。 Re: Is i.MX 9 "there yet"? こんにちは。もし熱性能とサイズを最優先事項とするなら、i.MX91をお勧めします。
查看全文
Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK We are trying to integrate an ST VL53L8CX ToF (Time-of-Flight) sensor over SPI on an NXP i.MX8MP LPDDR4 EVK using Yocto Linux. The objective is initially to achieve basic SPI communication and successfully detect the VL53L8CX device from a custom Linux kernel driver. Full ranging functionality is not required at this stage. Hardware Board: NXP i.MX8MP LPDDR4 EVK Sensor: VL53L8CX ToF sensor Interface: SPI EVK connector: J21 expansion connector SPI controller: ECSPI2 Chip select: ECSPI2 SS0 GPIO used for CS: GPIO5_IO13 SPI device: spi1.0 SPI speed: 1 MHz SPI mode: Mode 0 The device-tree configuration currently uses:   &ecspi2 { pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; status = "okay"; stmvl53l8cx: spi@0 { reg = <0>; compatible = "st,stmvl53l8cx"; spi-max-frequency = <1000000>; }; }; meta-vl53l8cx_8mp/ ├── conf/ │ └── layer.conf ├── recipes-kernel/ │ ├── linux/ │ │ ├── files/ │ │ │ └── 0001-add-vl53l8cx-spi-node.patch │ │ └── linux-imx_%.bbappend │ │ │ └── vl53l8cx/ │ ├── files/ │ │ ├── Makefile │ │ └── driver.c │ └── vl53l8cx.bb The SPI device is successfully created:   root@imx8mp-lpddr4-evk:~# ls -l /sys/bus/spi/devices/ spi0.0 spi1.0   The custom driver is also registered:   root@imx8mp-lpddr4-evk:~# ls -l /sys/bus/spi/drivers/ stmvl53l8cx   The driver probe() function is being called successfully. Could someone please advise what we should verify on the i.MX8MP EVK ECSPI2/J21 hardware and Device Tree configuration to make sure the VL53L8CX is communicating correctly over SPI? In particular, we would like to confirm: Is ECSPI2 / spi1.0 the correct SPI controller/device for the J21 expansion connector on the i.MX8MP LPDDR4 EVK? Is GPIO5_IO13 / ECSPI2_SS0 the correct chip-select for J21? Are the ECSPI2 SCK, MOSI, MISO and CS pinmux settings correct for this connector? Is any additional Device Tree configuration required for the VL53L8CX, such as: spi-cpol spi-cpha GPIO1/interrupt LPn/reset/power GPIO power-supply/regulator properties? Does the VL53L8CX require a particular SPI mode, timing, or initialization sequence before reading its device ID? Is there anything specific on the i.MX8MP ECSPI controller that needs to be configured for the VL53L8CX? Since spi_write() and spi_read() return 0, is there a recommended way to verify the actual MOSI/MISO electrical communication (for example with a logic analyzer) and determine whether the sensor is responding? We have also attached our custom driver.c driver and kernel logs for reference. Any guidance on the correct i.MX8MP EVK + J21 + ECSPI2 + VL53L8CX SPI configuration would be appreciated. I have attached custom driver file driver.c also I have attached logs Thank you. Re: Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK Hello @Manuel_Salas  Thank you for your response. We tried reading the device ID before proceeding with any further configuration. However, we are not able to read the device ID successfully. Our SPI driver is probing correctly, but the register read for the chip ID does not return the expected value. Because of this, we are unable to verify communication with the VL53L8CX and cannot proceed with the sensor initialization. We are currently checking our SPI configuration, device tree, and hardware connections to identify the issue. We will also attach our driver, logs and module image so you can review it. If you have any suggestions on what else we should verify for basic SPI communication with the VL53L8CX, we would greatly appreciate your guidance. Best regards, yogi96 Re: Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK Hello @yogi96  Hope you are doing very well. In general, all your steps looks good. The next step what yocan try is read any register of the sensor, for example, in your probe() function, read the ID from the chip. If ID is correct read, continue with the configuration. Also, I could not saw the driver attached. Please attach is possible. Best regards, Salas.
查看全文
MIMXRT700-EVK Flashing Error Hi, I am unable to flash my application to the MIMXRT700-EVK using NXP LinkServer. Hardware/Software: Board: MIMXRT700-EVK MCU: MIMXRT798S Debugger: On-board MCU-Link MCU-Link firmware: V3.172 LinkServer: 26.6.137 OS: Ubuntu Linux Power is supplied through J54 During flashing, LinkServer reports: Error: Wire Ack Fault - target connected? Error: Wire not connected Failed on connect: Ee(42). Could not connect to core. No connection to chip's debug port Flash operation exited with code 1 The MCU-Link is detected correctly by the PC, and LinkServer can detect the probe. The important hardware observation is that the D4 red LED is not glowing. According to the MIMXRT700-EVK documentation, D4 indicates the MCU/reset status, where ON indicates normal processor activity and OFF indicates that the processor is in reset. I also executed the RT700 preconnect script, but the SWD connection still fails with: Error: Wire Ack Fault - target connected? Error: Wire not connected Support Request Could you please advise: Why is the D4 LED OFF when the board is powered through J54? How can I bring the RT700 processor out of the reset state? Is there any required reset, boot, or hardware configuration that needs to be checked? What recovery procedure should I use to restore LinkServer connectivity so that I can flash the application? Evaluation Board Re: MIMXRT700-EVK Flashing Error Hi @Aparna1, It's likely that the power is not being properly distributed to the MCU/rest of the board, but rather just to the on-board debugger. Is the green D10 LED also OFF? Please make sure that the jumper position of J2 is shorting pins 7 and 8. BR, Edwin. Re: MIMXRT700-EVK Flashing Error Hi, Yes, I have verified the following: The green D10 LED is ON. J2 is shorting pins 7 and 8 . Please let me know if any additional checks are required from my side. Regards, Aparna Re: MIMXRT700-EVK Flashing Error    This is the Status after connecting USB  Re: MIMXRT700-EVK Flashing Error Hi, could you please provide an update on my ticket? I am still waiting for a response.   Thank you.    
查看全文
LWIP TCP/IP Server-Client Hands-On Hello, do we have any TCP client handshake examples for the S32K358? I'm encountering some problems, which I posted in my previous thread. I saw a previous post about a solved S32K148 issue: LWIP TCP/IP Server-Client Hands-On - NXP Community , I wonder if it could help me! If you have one, please send me a copy. My email address is [email protected]. Thank you very much! Re: LWIP TCP/IP Server-Client Hands-On Hello @sunshine88, There is no reference project as the lwip_s32k148_HandsOn workshop for the S32K358. I've sent you a private message with both lwip_s32k148_HandsOn_Server & lwip_s32k148_HandsOn_Client. Best regards, Julián
查看全文
S32k344はグリーンヒルズツールチェーンを使用しています ベクターセクションを0x00400000にフラッシュメモリにベクターテーブルを保存しつつ、実行時にDTCMメモリにコピーしてそこから実行するようにするにはどうすればいいですか?Green Hillsのリンカーファイルにそれをどのように実装すればよいですか? Re: S32k344 using green hills toolchain こんにちは、 @XRen_Parkerさん この質問は特にGreen Hillsのツールチェーンとその統合に関するものなので、Green Hillsに直接問い合わせることをお勧めします。彼らは適切な指導とリソースを提供できるはずだ。 https://support.ghs.com/ よろしくお願いいたします。 ルーカス
查看全文
HseFwInstall I downloaded the official HSE installation example, but after running it, I found that HSE failed to install. The program gets stuck in the `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );` loop. I'm at a loss and need help on how to successfully install HSE. The attached file is the official example; I downloaded it, changed the `.project` file to `S32K312`, and disabled the `baf` file in the linker script. I didn't modify anything else. Re: HseFwInstall Hi I suggest you obtain the latest s32k3_hse_lib_rtd400hf01_20260427.7z from the distributor FAE and test it again. The new version fixes some bugs found in older versions. According to section " 2.2 Version Number Details " of SBAF_S32K312_0_0_15_0_ReleaseNotes.pdf and the value shown in your screenshot at 0x4039C020 - 0x4039C027, it appears that AB_SWAP firmware was previously installed? If FULL_MEM was installed, the value at 0x4039C020 - 0x4039C027 should be 000D0000 000F0006. However, what I see in your attached project is S32K312_0_2_40_0_HSE_FULL_MEM. I'm a bit confused about whether you need to install FULL_MEM or the HSE FW for AB_SWAP? Please check which build option you selected for the HseLib_HseFwInstall_Rtd400 project. Please note that it is not possible to revert from AB_SWAP to FULL_MEM. The screenshot you provided shows 0x4039C028=0xC0 bit0=0, meaning SBAF failed to boot HSE FW. It appears the HSE FW firmware is corrupted. You'll likely need to refer to MU Restore FW_EN.pdf to restore HSE FW using MU. Please also refer to the manual s32k3_hse_lib_rtd400hf01_20260427\Doc\ S32K3_HSE_LIB_UserGuide.pdf . I didn't understand " blocked the baf file in the linker script ". Does it refer to page 19/51, section 3.3 of that document? .3In the "Build configuration - Settings of Linker" section, what about the file s32k3xx_flash_full_mem_0_2_40_0.ld? After installing SBAF_S32K312_0_0_15_0.exe, the path is C:\NXP\SBAF_S32K312_0_0_15_0\bin\s32k312_Secure_Baf_0.13.0_0.15.0.6_pb230804.bin.pink. This file does not need to be commented out. Best Regards, Robin
查看全文
有没有比较简单易用的8位微控制器/汇编语言? 我正在寻找一款可以查看实际十六进制/二进制代码的 8 位微控制器。我在大学学习 8051 汇编语言,我非常喜欢看到和理解内存中的每一条指令和值。但是这些微控制器已经过时,需要大量的“破解”才能兼容。至少每次我把代码放到真正的硬件上运行时,都会有这种感觉。那么,有没有一种简单的8位汇编语言,可以配合实际的芯片,让我能够编写简单的电子项目程序呢? Re: Is there a simple 8 bit microcontroller/assembly language that is nice to work with? 你好; 如果您正在学习汇编语言,S08PT 设备可能是一个不错的起点; S08PT|8 位 5V 全功能 MCU,带 EEPROM 和 TSI | NXP 半导体 。 使用该软件工具是CodeWarrior for MCUs (Eclipse IDE) v11.1,适用于 Windows 10/11;该工具可以使用汇编代码进行测试,因为它具有汇编调试工具视图,并且可以查看内存以了解代码的功能。 本设备配有评估板 S08PT60-EVK [MC9S08PT60],如果您感兴趣,请参阅 [ S08PT60-EVK 产品信息],其中包含各种外设,供您在实际硬件上测试代码的不同配置。 板载接口包括 RGB LED、6 轴数字加速度计和磁力计、环境温度传感器、两个电容式触摸板、电位器、两个用户按钮和红外收发器。同时兼容 Arduino 扩展板的引脚布局。 您可以在主页上阅读更多关于这些功能的信息: S08P MCU 评估套件 | 恩智浦半导体 此致敬礼,路易斯
查看全文
S32K3X4EVB-T172 Unable to Program using OpenSDA I have a fresh-out-the-box S32K3X4EVB-T172 Eval board. The S32 processor seems to be running some factory default code, but when I try to debug/reprogram using the on-board debugger (connected to my computer using USB) both the S32 and the on-board debugger go into reset. I am using the correct Power On/Plug in procedure as described by the S32K3X4EVB-T172 quick start guide. I also have installed the software and addons described there as well. Tried same process with a co-worker's S32K3X4EVB-Q172 and it worked just fine.\ Thanks in advance, -Tobiah Re: S32K3X4EVB-T172 Unable to Program using OpenSDA 1. Please refer to the discussion: PEmicro Connection Assistant Issue on S32K3X4EVB-T172. Do the red LEDs D15(RST_OSDA) and D3(RESET_K3) remain lit, or do they flash periodically? Is your board experiencing the same issue as this customer?   2. Is FS26(U12) hot? 3. Did you follow the steps "3.2 Plug in the Power Supply" and then "3.3 Connect the Debugger Cable"? 4. Plug in the J40 micro-USB cable and observe the D14STATUS OSDA LED. If the D14 orange LED does not light up: Check whether the USB cable is a data cable, verify if the PC enumerates the OpenSDA device, and ensure the USB port and drivers are functioning correctly. Connecting the USB cable to the PC via a USB hub is not recommended. 5. The onboard debugger is provided by PEMicro, it is recommended to download the latest "USB Multilink Resources Installer" from the "Support & Downloads" category of the "Multilink Debug Probes". After installation, open PEFirmwareConfig.exe located in C:\PEMicro\Multilink_Resources to check the firmware version. My onboard debugger's firmware version is 10.98. What version is your board? If the version is too old, it is recommended to update. If the update fails, it is recommended to contact PEMicro technical support. check the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.pngcheck the version of firmware on S32K3X4EVB-T172.png 6. Please use a multimeter in voltage mode or an oscilloscope to observe the voltage of P3V3_SDA (J34). S32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.png 7. The SDA_RST_TGTMCU is controlled by the output of the onboard debugger K26. If the SDA_RST_TGTMCU outputs a low level, both red LEDs D15 and D3 will light up. Please observe the SDA_RST_TGTMCU (J36) level using an oscilloscope. Is it always low, or is it periodically pulled low? Normally, when downloading a program or resetting the S32K3 via the onboard debugger, a 10ms low level should be observed in the SDA_RST_TGTMCU, causing red LEDs D15 and D3 to light up briefly. 8. Is it possible to debug the onboard S32K3 chip after connecting via J12 using an external debugger? Best Regards, Robin Re: S32K3X4EVB-T172 Unable to Program using OpenSDA I am not sure which version of the RTD Port_Example_S32K344 you are currently testing. However, I suggest setting J31 to positions 2-3 and trying again. Re: S32K3X4EVB-T172 Unable to Program using OpenSDA After some more testing: 5. I was able to update the onboard debugger firmware using the PEFirmwareConfig exe.  The behavior remains the same though when I try to debug/program. 6. J34 voltage is at 3.25V when USB is plugged in. 7. J36 is high until I try to debug/program. At which point it goes low and stays low until the micro USB is disconnected. Still waiting on an adapter for point 8.  It should arrive today. Thank you, -Tobiah Re: S32K3X4EVB-T172 Unable to Program using OpenSDA How can I determine what the version of the example project is? I switched J31 to 2-3. Same behavior. Thanks, -Tobiah Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Please take a photo of the S32K3X4EVB-T172 board after connecting the external 12V power supply to J14 and plugging in the USB cable; the image must be clear enough to show the jumper settings and which LEDs are lit. Please record a video of the S32DS interface, starting from when you click the debug button and continuing until the error screen appears. This will allow me to see exactly what is happening and help troubleshoot the issue quickly. If you cannot record a video of the operations performed in S32DS on the screen, could you take a few screenshots to show the error? Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Hello Robin, 1. Once I attempt to debug/program, both LEDs (D15 and and D3) remain lit. They do not flash.  I believe my board is experiencing the same issue as the customer in https://community.nxp.com/t5/S32K/PEmicro-Connection-Assistant-Issue-on-S32K3X4EVB-T172/m-p/2252525, but it seems he bypassed his issue by purchasing another EVB, which is unfortunate. 2. no 3. yes 4. D14 does light up when I plug in the micro-USB cable.  Device Manager shows "OpenSDA - CDC Serial Port (http://www.pemicro.com/opensda)".  There is no USB hub in the system, and my PC+cable can program other S32K344 EVBs using S32DS.  The issue seems tied specifically to this board. 5-7.  Give me some time to run these down.  I will respond shortly. 8. I have yet to try to JTAG directly as I am waiting on an adapter so I can interface with J12. Thank you for your detailed response, -Tobiah Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Please check whether the jumper settings match those described in "3.1 Set Up Jumpers in the S32K3X4EVB-T172 Evaluation Board." Is the input voltage for J14 12V? Which project did you debug? Would it be possible for you to record a video of the debugging process and share it with me? Re: S32K3X4EVB-T172 Unable to Program using OpenSDA The jumper settings do match. J16 is showing 12V (seemed easier than measuring the jack directly). I am using the project Port_Example_S32K344 as recommended in the quick start guide.  I don't think I will be able to video. -Tobiah Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Finally got a JTAG adapter that works for J12. I can debug the S32K344 chip using an external debugger. OpenSDA still doesn't work. Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Good morning, 00_evb.jpg  ^ Initial state of board after power on and connection of USB 00_dashboard.png  ^ Example project dashboard 03_debug3.png 01_debug1.png 02_debug2.png    ^Debug configuration 04_error1.png  ^ first error after debug 04_evb.jpg  ^ EVB after attempted debug (happens at the same time as the above error) 05_error2.png  ^ error after clicking abort   Re: S32K3X4EVB-T172 Unable to Program using OpenSDA Sorry for the inconvenience we bring you!  In my experience, the D15 LED on your development board is behaving abnormally.   The following two links contain our policy on returns and refunds. There is a 12-month window for warranty replacements and only a 30-day window for refunds. Once a request is submitted, the direct team forwards it to the person in charge of this process, and they will contact the customer directly to provide instructions on what to do next. Dev Tool Warranty Return Request Form Returns and Warranty Information
查看全文