MCXA185 ポテンショメータの値の読み取り MCXA185 LPADCポテンショメータの読み取り – より安定したADC値を求めて NXP MCXA185を使って作業しており、LPADCを使ってP2_0/ADC0_A0に接続されたポテンショメーターを読み取っています。 私の現在の実装では以下を使用しています。 ADC0 / ADC0_A0 高解像度変換モード LPADCハードウェアによる128サンプルの平均化 長時間のADCサンプリング時間（kLPADC_SampleTimeADCK19） 1ミリ秒ごと（1000Hz）にADCの読み取り値を取得 ソフトウェアトリガー変換 100サンプルのブロック平均 結果として得られる平均値は100ミリ秒ごとに更新されます。 つまり、ブロック平均に使われる各値は、ADCハードウェアによって128回の変換で平均化されているのです。 現在のアプローチ cmdConfig.conversionResolutionMode = kLPADC_ConversionResolutionHigh; cmdConfig.hardwareAverageMode = kLPADC_HardwareAverageCount128; cmdConfig.sampleChannelMode = kLPADC_SampleChannelSingleEndSideA; cmdConfig.sampleTimeMode = kLPADC_SampleTimeADCK19; そして1ミリ秒ごとに： LPADC_DoSoftwareTrigger(POT_LPADC_BASE, (1U << POT_LPADC_TRIGGER_ID)); while (!LPADC_GetConvResult(POT_LPADC_BASE, &result)) { /* Wait for conversion */ } s_blockSum += result.convValue; s_sampleCount++; if (s_sampleCount >= 100U) { s_lastAverage = (uint16_t)(s_blockSum / 100U); s_blockSum = 0U; s_sampleCount = 0U; } 私の質問 これは安定したポテンショメータ値を得るための良い方法でしょうか、それとももっと優れたADCフィルタリング／平均化戦略があるでしょうか？ 特に、以下の点について疑問に思っています。 ポテンショメーターとして 128カウントのハードウェア平均+100サンプルのソフトウェア 平均を使うのは過剰でしょうか? これは実際に有用な追加のノイズ低減になれるのでしょうか?それとも単にレスポンスレイテンシを増やしているだけでしょうか? 16サンプルや32サンプルのような小さなハードウェア平均を使い、その後ソフトウェアフィルターを使う方が良いのでしょうか? ポテンショメータの場合、 IIR/指数移動平均は100サンプルブロック平均よりも優れているでしょうか？なぜなら、IIR/指数移動平均の方が、つまみの動きに素早く反応しつつ、より滑らかな値が得られるからです。 kLPADC_SampleTimeADCK19は一般的なポテンショメータに適していますか、それとも別のサンプリング時間を使用すべきでしょうか？ 安定性を向上させるために有効にすべき、MCXA185固有のLPADC設定はありますか？ 1ms関数内でADCの結果をポーリングする方法は妥当な実装でしょうか、それともハードウェアタイマートリガーとADC FIFO/割り込み方式を組み合わせた方が望ましいでしょうか？ ピン構成 現在使用しているもの： cfg.pullSelect = kPORT_PullDisable; cfg.driveStrength = kPORT_LowDriveStrength; cfg.passiveFilterEnable = true; cfg.inputBuffer = kPORT_InputBufferDisable; ポテンショメータは電圧分圧器として接続され、ワイパーは P2_0/ADC0_A0に接続されています。 私が主に知りたいのは、以下の値です。 ポテンショメータが動いていないときは安定している ポテンショメータを回すと反応する 過度の平均化による不必要な遅延がない 小さなADC/ワイパーノイズに耐性がある 現在の ハードウェア平均128+100サンプルブロック平均 のアプローチが適切かどうか、またこの用途にどのようなフィルタリング戦略を推奨するかについてフィードバックをいただけるとありがたいです。 アナログ(ADC|CMP|DAC|OpAmp) MCXA Re: MCXA185 Reading values of a potentiometer こんにちは、 高速チャネルを使っているか確認してもらえますか?SDKの例をベースに使っていますか? 高いAVGS値を使っていますが、変換値を平均すると応答が安定しますが、よりバランスの取れた応答を求めるなら、16サンプル(0100)の小さいAVGSを使うことで、変換時間を短縮して良いノイズ抑制が得られます。 MCX-A-185のデータシートでは、図11と図12が高速モードを考慮すると、どれだけ平均が必要なかの方向転換に役立ちます。 kLPADC_SampleTimeADCK19を使うかどうかは、あなたのアプリケーションミッションによります。最短のサンプリング時間は、低インピーダンス入力における変換速度を最大化します。サンプリング時間を延長することで、より高いインピーダンスの入力も正確にサンプリングできるようになる。ポテンショメータのようにインピーダンスを抑える変換速度を最適化したいなら、例えばサンプル時間を短くする方法kLPADC_SampleTimeADCK7。 必要なサンプル時間を望ましい精度を考慮して計算する必要がある場合は、データシート表33小節4.Bの公式を確認できます おそらく MCX-A-18リファレンスマニュアル 45.5.1.2章のADCキャリブレーションの説明書でしょう- 45.5.1.4あなたが探しているのはこれです。 よろしくお願いいたします。

S32K3系列MCU的DFARS原产国/合格国家合规性 大家好， 我正在评估 NXP S32K3 系列 MCU，用于一个需要符合 DFARS 标准的采购项目，我希望这里有人能帮我指明正确的方向，或者以前处理过类似的事情。 具体来说，我想确认的是： 特定 S32K3 零件编号的制造/组装国家/地区（晶圆厂和封装/测试地点）——合规性通常与零件是否在DFARS 252.225-7002（合格国家/地区来源作为分包商）规定的 DFARS“合格国家/地区”制造有关，因此我需要零件编号/封装级别的信息，而不是一般的“NXP 符合规定”声明。 NXP 能否为特定部件出具原产地证书 (COO)或正式的DFARS 合规声明。 是否有TAA 合规函可供参考，因为这可能也适用于我们的项目。 感兴趣的部分（也欢迎符合同一级别的其他选择）： S32K344 S32K358 S32K314 我们的目标是闪存容量≥512 kB、RAM容量≥128 kB的MCU，所以我主要关注的是内存容量更高的S32K3系列产品，但如果其他S32K3系列产品（或更广泛的S32K1/S32K2系列）在合规性方面有更好的文档记录，我也很乐意了解。 向社区提出的问题： 有没有人成功直接从NXP获得过S32K3部件的COO/DFARS文件？如果是的话，您是与哪些人员合作的（现场应用工程师、代理商、质量团队）？ NXP 是否会公布这些信息，还是总是根据零件/日期代码逐个申请？ 是否有特定的 S32K3 零件编号或包装已知来自符合 DFARS 资格的国家，而其他不符合 DFARS 资格的国家则不然？ 鉴于 S32K3 主要面向汽车/工业功能安全应用，有没有人有获得国防相关项目合规性文件的经验？ 我知道社区工程师可能无法直接获取这些信息，所以如果有更好的渠道（例如区域现场应用工程师、代理商合规部门等）可以让我联系，请告诉我。非常感谢您的指导！ 谢谢您！ Re: DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs 嗨@dbow12 ， 我们没有公开的相关信息。 如需咨询首席运营官相关事宜，请联系[email protected] 。 如有任何出口管制方面的疑问，请联系[email protected]。 不过，我建议您先联系当地的代理商，他们应该能够在这方面为您提供帮助。 此致， 丹尼尔

GUI Guider 1.10.1 在背景不透明度为 0 时会忽略背景样式属性。 环境 GUI 指南：1.10.1 LVGL：8.3 小部件：按钮 款式部分：LV_PART_MAIN 样式状态：LV_STATE_DEFAULT 问题描述 我在 GUI Guider 1.10.1 中发现了一个可重现的代码生成问题。 当按钮配置了背景颜色，但其背景不透明度设置为 0 时，GUI Guider 不会生成相应的背景颜色属性。 当在运行时动态更改背景不透明度时，这会导致意外行为。 生殖 创建按钮并进行配置： 背景颜色：#F08300 背景不透明度：0 然后生成 LVGL 8.3 代码。 GUI 指南程序生成： lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 0， LV_PART_MAIN | LV_STATE_DEFAULT); 但是，配置的背景颜色并未生成： lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); 测试：仅将背景不透明度从 0 改为 1 我只将背景不透明度从 0 改为 1，而背景颜色保持为 #F08300。 代码重新生成后，GUI Guider 会生成： lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 1、 LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_grad_dir(ui->screen_password_btn_15, LV_GRAD_DIR_NONE， LV_PART_MAIN | LV_STATE_DEFAULT); 因此，生成的代码取决于背景不透明度是否恰好为 0。 背景不透明度 = 0： 生成 bg_opa bg_color 未生成 背景不透明度 = 1： 生成 bg_opa bg_color 已生成 还会生成其他背景属性。 运行时影响 我的应用程序使用背景不透明度来指示当前选定的密码数字。 GUI Guider 中将背景颜色配置为 #F08300，而应用程序仅动态更改背景不透明度。 例如： lv_obj_set_style_bg_opa(btn, LV_OPA_COVER， LV_PART_MAIN | LV_STATE_DEFAULT); 对于初始背景不透明度为 0 的按钮，生成的代码不包含配置的背景颜色。 当应用程序将不透明度从 0 更改为 LV_OPA_COVER 时，按钮将显示 LVGL 主题或默认背景颜色，而不是 GUI Guider 中配置的 #F08300 颜色。 这种行为是： GUI引导程序配置： 背景颜色 = #F08300 背景不透明度 = 0 生成的代码： bg_opa = 0 bg_color 未生成 运行时： bg_opa 已更改为 LV_OPA_COVER 结果： 显示的是默认背景色或主题背景色，而不是 #F08300。 临时解决方案 在应用程序代码中显式设置背景颜色可以解决此问题： lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER， LV_PART_MAIN | LV_STATE_DEFAULT); 另一种可能的解决方法是在 GUI Guider 中将背景不透明度设置为 1，因为这会导致 GUI Guider 生成配置的背景颜色。 但是，这会改变初始用户界面状态，因此并不理想。 预期行为 背景颜色和背景不透明度是独立的 LVGL 样式属性。 如果用户明确配置： 背景颜色 = #F08300 背景不透明度 = 0 我希望 GUI Guider 能在生成的代码中保留这两个属性： lv_obj_set_style_bg_opa(btn, 0， LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); 虽然当 bg_opa 为 0 时 bg_color 没有明显的影响，但当应用程序在运行时动态更改 bg_opa 时，它就变得重要了。 当前代码生成行为会丢失在 GUI Guider 中配置的背景颜色信息。 实际行为 GUI Guider 1.10.1 在背景不透明度为 0 时似乎会忽略背景样式属性。 仅将不透明度从 0 改为 1，会导致背景颜色和其他背景属性重新生成。 重现步骤 在 GUI Guider 1.10.1 中创建按钮。 将背景颜色设置为 #F08300。 将背景不透明度设置为0。 生成LVGL 8.3代码。 注意，已生成值为 0 的 lv_obj_set_style_bg_opa。 请注意，未生成颜色为 #F08300 的 lv_obj_set_style_bg_color。 仅将背景不透明度从 0 改为 1。 重新生成代码。 请注意，现在已生成颜色为 #F08300 的 lv_obj_set_style_bg_color。 在运行时，将原始按钮的不透明度更改为 LV_OPA_COVER。 请注意，除非应用程序明确设置了 bg_color，否则配置的背景颜色不会显示。 问题 这是 GUI Guider 1.10.1 中有意为之的代码大小优化，还是代码生成问题？ 如果这种优化是有意为之，GUI Guider 能否提供一个选项，在背景不透明度为 0 时保留背景属性？ 运行时应用程序通常会动态更改 LVGL 样式属性，因此仅根据其初始不透明度省略 bg_color 可能会导致运行时行为与 UI 配置不同。 Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 你好@zzjgood， 感谢你的帖子。 我可以重现您描述的情况。我认为这是一个代码生成问题。如果用户明确配置了背景颜色，即使初始背景不透明度为 0，GUI Guider 也应该保留相应的 bg_color 代码，或者提供一个选项来保留透明对象的背景样式属性。我会将此问题报告给 GUI-Guider 团队，以便他们进一步修复。此外，根据我们的内部升级流程，如果您能提供以下信息，我们将不胜感激： - 你用的是哪款NXP产品？ - 你的最终应用是什么？ 目前实际的变通方法是在应用代码中明确设置背景色和不透明度： 复制 lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); 希望它有帮助。 BR 塞莱斯特

Issues with IMX95 15x15 package DDR5 Hi NXP I'm currently debugging an .imx95 15x15 packaged DDR5 and have encountered a problem. DDR5: RS2G32LO5D4FB-31BT 1. I used ConfigTools for i.MX 26.06, verification, using the .bin file compiled with lpddr5_timing.c, during flashing, the M33 core showed DDR...OEI: done, err = -1 2. I reduced the DDR speed to 1866 MT/s, but I still got a -1 error. 3. I noticed that the SDK does not include an official version of the IMX9596 15x15 DDR5. yrj_0-1786433338089.png yrj_1-1786433341485.png Re: imx95 15x15封装 DDR5的问题 Hi @yrj The IMX95 does not support DDR5. B.R Re: imx95 15x15封装 DDR5的问题 HI @pengyong_zhang Is it LPDDR5? Does it support it? Re: imx95 15x15封装 DDR5的问题 HI @yrj Yes, it supports LPDDR5 and LPDDR4X. B.R Re: imx95 15x15封装 DDR5的问题 The part is LPDDR5 and you may need to review the schematics 

GUI Guider 1.10.1 では、背景の不透明度が 0 の場合、背景スタイルのプロパティが省略されます。 環境 GUI Guider: 1.10.1 LVGL: 8.3 ウィジェット: ボタン スタイルパーツ: LV_PART_MAIN スタイル状態: LV_STATE_DEFAULT 問題の説明 GUI Guider 1.10.1 で再現可能なコード生成の問題を発見しました。 ボタンに背景色が設定されているにもかかわらず、背景の不透明度が0に設定されている場合、GUI Guiderは対応する背景色プロパティを生成しません。 実行時に背景の透明度を動的に変更すると、予期しない動作が発生します。 再生 ボタンを作成して設定します。 背景色：#F08300 背景の不透明度: 0 次に、LVGL 8.3コードを生成します。 GUI Guider が生成するもの: lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 0、 LV_PART_MAIN | LV_STATE_DEFAULT); しかし、設定した背景色は生成されません。 lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); テスト：背景の不透明度のみを0から1に変更する 背景色の#F08300はそのままに、背景の不透明度だけを0から1に変更しました。 コードを再生成した後、GUI Guiderは以下を生成します。 lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 1、 LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_grad_dir(ui->screen_password_btn_15, LV_GRAD_DIR_NONE、 LV_PART_MAIN | LV_STATE_DEFAULT); したがって、生成されるコードは、背景の不透明度が正確に0であるかどうかによって異なります。 背景の不透明度 = 0: bg_opaが生成されます bg_color は生成されません 背景の不透明度 = 1: bg_opaが生成されます bg_color が生成されます その他の背景プロパティも生成されます 実行時への影響 私のアプリケーションは背景の不透明度を使って現在選択されているパスワード番号を示します。 背景色はGUI Guiderで #F08300 として設定され、アプリケーションは背景の不透明度のみを動的に変更します。 例： lv_obj_set_style_bg_opa(btn, LV_OPA_COVER、 LV_PART_MAIN | LV_STATE_DEFAULT); 初期の背景不透明度が0のボタンの場合、生成されるコードには設定された背景色が含まれません。 アプリケーションが不透明度を0からLV_OPA_COVERに変更すると、ボタンはGUI Guiderで設定された #F08300 色の代わりにLVGLテーマまたはデフォルトの背景色を表示します。 その動作は以下のとおりです。 GUI Guiderの設定： 背景色 = #F08300 背景の不透明度 = 0 生成されたコード: bg_opa = 0 bg_color は生成されません ランタイム： bg_opa が LV_OPA_COVER に変更されました 結果： #F08300の代わりに、デフォルトまたはテーマの背景色が表示されます。 応急措置 アプリケーションコード内で背景色を明示的に設定すると、以下の問題が解決します。 lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER、 LV_PART_MAIN | LV_STATE_DEFAULT); 別の回避策としては、GUI Guiderで背景の不透明度を1に設定する方法があります。これにより、GUI Guiderは設定された背景色を生成するようになります。 しかし、これは初期のUI状態を変更してしまうため、理想的とは言えません。 期待される動作 背景色と背景の不透明度は、それぞれ独立したLVGLスタイルプロパティです。 ユーザーが明示的に以下を設定する場合: 背景色 = #F08300 背景の不透明度 = 0 GUI Guiderは、生成されたコードにおいて両方のプロパティを保持するはずです。 lv_obj_set_style_bg_opa(btn, 0、 LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300)、 LV_PART_MAIN |LV_STATE_DEFAULT); bg_color bg_opa が0のときは目に見える影響はありませんが、アプリケーションが実行時に動的にbg_opaが変化すると重要になります。 現在のコード生成動作では、GUI Guiderで設定された背景色情報が失われます。 実際の行動 GUI Guider 1.10.1 では、背景の不透明度が 0 の場合、背景スタイルのプロパティが省略されるようです。 不透明度を0から1に変更するだけで、背景色やその他の背景プロパティが再生成されます。 再現手順 GUI Guider 1.10.1 でボタンを作成する。 背景色を#F08300に設定してください。 背景の不透明度を0に設定してください。 LVGL 8.3コードを生成します。 値0のlv_obj_set_style_bg_opaが生成されていることを確認してください。 #F08300 を指定した lv_obj_set_style_bg_color は生成されないことに注意してください。 背景の不透明度のみを0から1に変更してください。 コードを再度生成してください。 #F08300 を指定した lv_obj_set_style_bg_color が生成されていることを確認してください。 実行時に、元のボタンの不透明度をLV_OPA_COVERに変更します。 設定された背景色は、アプリケーションが明示的に設定しない限り表示bg_colorないことに注意してください。 質問 これはGUI Guider 1.10.1における意図的なコードサイズ最適化なのでしょうか、それともコード生成の問題なのでしょうか？ もしこの最適化が意図的であれば、GUI Guiderはバックグラウンド不透明度が0のときにバックグラウンドプロパティを保持するオプションを提供してくれますか? ランタイムアプリケーションはLVGLスタイルのプロパティを動的に変更することが多いため、初期の不透明性だけでbg_colorを省略すると、UI設定とは異なる実行時の挙動が生じる可能性があります。 Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 こんにちは、 @zzjgood さん、 投稿ありがとうございます。 あなたが説明した行動を再現できます。これはコード生成の問題だと思います。ユーザーが背景色を明示的に設定する場合、GUI Guiderは初期の背景不透明度が0でも対応するbg_colorコードを保持するか、透明オブジェクトの背景スタイルプロパティを保持するオプションを提供するべきです。この件はGUI-Guiderチームに報告し、修正を依頼します。さらに、当社の内部エスカレーションプロセスに基づき、以下の情報を提供していただけるとありがたいです。 - どのNXP製品を使っていますか? - 最終的なアプリケーションは? 現在の実用的な回避策は、アプリケーションコード内で背景色と不透明度の両方を明示的に設定することです。 コピー lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); お役に立てば幸いです。 BR セレステ

清除 ECC RAM MCU：S32K148 驱动程序：RTD 3.0.0 操作系统：裸机 对于上述MCU，是否有办法“擦除”ECC SRAM？“擦除”是指，如果检测到可纠正的错误，则在用户配置一些适当的寄存器后，将SRAM单元更新为正确的值。一些竞争产品，例如 TI Hercules，就具备此功能。 Re: Scrubbing ECC RAM 非常感谢您的反馈。 Re: Scrubbing ECC RAM S32K1 设备不支持硬件 SRAM 擦除机制，该机制可以在可纠正的 ECC 事件发生后自动将更正后的数据写回内存。基于软件的实现也不可行，因为 ERM 不会报告单比特 SRAM ECC 纠错事件，因此应用程序无法识别受影响的内存位置。 虽然 S32K3 系列也不提供自动 SRAM 擦洗功能，但它会报告单比特 ECC 事件，这使得应用程序能够了解这些错误，并实现更高级的故障处理策略。

S32K3シリーズMCUのDFARS原産国／認定国準拠 こんにちは、皆さん。 私はDFARS準拠の調達が必要なプログラムのためにNXP S32K3ファミリのMCUを評価しており、ここで誰かが正しい方向を教えていただけるか、以前にこの問題に対処したことがある方がいればと思っています。 具体的には、以下の点を確認しようとしています。 製造・組立国(ウェハーファブおよびパッケージ/試験場所)に関する特定のS32K3部品番号 — コンプライアンスは一般的に、部品がDFARSの「認定国」である DFARS 252.225-7002(下請け業者としての適格国)で製造されているかどうかに結びついているため、一般的な「NXPは準州です」という説明ではなく、部品番号やパッケージレベルで必要です。 NXPが特定の部品に対して原 産証明書(COO) または正式な DFARS準拠声明 を発行できるかどうか。 TAA（貿易調整支援法）の遵守証明書が入手可能かどうかも確認したい。というのも、それが当プログラムにも適用される可能性があるからだ。 関心のある部品（同じレベルに該当する代替品も検討可）： S32K344 S32K358 S32K314 私たちは≥512 kBフラッシュ、≥128 kB RAMを搭載したMCUをターゲットにしているので、主に高容量メモリのS32K3バリアントを検討していますが、他のS32K3ファミリ(またはより広範なS32K1/S32K2ライン)がコンプライアンスのためにより詳しいドキュメントがあるかどうかも聞きたいです。 コミュニティへの質問： 誰か、S32K3部品のCOO/DFARSドキュメントをNXPから直接取得することに成功した方はいらっしゃいますか?もしそうなら、誰と仕事をしましたか(FAE、代理店、品質チームなど)? これはNXPが公開するものなのでしょうか?それとも常に部品や日付コードごとにCASEバイCASEでリクエストされるのでしょうか? DFARS資格のある国から調達されているとされる特定のS32K3部品番号やパッケージはありますか?それとも、そうでない国から調達されているのでしょうか? S32K3はオートモーティブやインダストリアルセーフティのアプリケーションに強く位置づけられているため、防衛関連プログラム向けのコンプライアンス文書を入手した経験がある方はいらっしゃいますか? これはコミュニティエンジニアが直接アクセスできないかもしれないと理解していますが、もしより良いチャネル(地域のFAE、代理店コンプライアンスデスクなど)があれば本来ならこのルートをルーティングすべきなので、そちらを教えてください。アドバイスをいただければ幸いです！ よろしくお願いします！ Re: DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs こんにちは、 @dbow12 さん。 この情報は一般には公開されていません。 COOに関するお問い合わせは [email protected] までお問い合わせください。 輸出管理に関するお問い合わせは、ご連絡ください [email protected]。 ただし、まずは地元の代理店に連絡することをお勧めします。彼らはこの点でサポートしてくれるはずです。 よろしくお願いいたします。 ダニエル

IMX8MP Linux U-Boot 需要使用默认环境变量并添加额外变量进行配置。 IMX8MP linux uboot 在通过 uuu 刷写引导加载程序后，需要设置默认环境和其他一些变量。 使用案例： IMX8MP SoM 出厂时自带厂商提供的默认 uboot。因此，第一次写入需要刷写新的 uboot 镜像时，我们将其设置为默认环境，并在工厂流程中设置了一些板级特定的环境变量。 所以当我使用命令 `uuu -b emmc_all bl-imx8mp.bin image.wic.zst` 时，它使用的是内置脚本。 uuu_version 1.4.149 # @_flash.bin | 引导加载程序，可以从 WIC 镜像中提取 # @_image [_flash.bin]| 将 WIC 镜像刻录到 EMMC。 # 此命令将在 i.MX6/7、i.MX8MM、i.MX8MQ 运行时运行 SDP：启动 -f bl-imx8mp.bin -scanlimited 0x800000 # 当 ROM 支持流模式时，将运行此命令 # i.MX8QXP，i.MX8QM SDPS：boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # SDPU 将被弃用。请使用 SDPV 代替 SDPU # { SDPU：延迟 1000 SDPU：写入 -f bl-imx8mp.bin -offset 0x57c00 SDPU：跳转 -scanlimited 0x800000 # } # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # 如果（SPL 支持 SDPV） # { SDPV：延迟 1000 SDPV：写入 -f bl-raptor-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV：跳转 -scanlimited 0x800000 # } FB：ucmd setenv fastboot_dev mmc FB：ucmd setenv mmcdev ${emmc_dev} FB：ucmd mmc dev ${emmc_dev} FB：flash -raw2sparse 所有 image.wic.zst/* FB：flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd 如果环境变量 emmc_ack 存在；则；否则设置环境变量 emmc_ack 为 0；结束； FB：ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB：完成 所以我的要求是 刷写引导加载程序 + 根文件系统/镜像 恢复默认设置。 添加新变量。 使用具有预期环境的正确工作的新引导加载程序重新启动。 但现在是先刷写根文件系统，然后再刷写新的引导加载程序。所以当我执行 env default -f -a 之后，它导致 SoM 板上旧引导加载程序的默认环境。重置后，它会使用新的引导加载程序启动，但会保留旧引导加载程序的默认设置。有什么建议可以解决这个问题吗？ Re: IMX8MP linux uboot need to be set up with the default environment + extra variables 你好@jake4 希望你一切都好。 您可以尝试编写自己的自定义脚本并添加以下内容： FB: ucmd env default -f -a 完整脚本示例： uuu_version 1.4.149 SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 SDPU: delay 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: jump -scanlimited 0x800000 SDPV: delay 1000 SDPV: write -f bl-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: ucmd env default -f -a FB: ucmd setenv board_version "1.0" FB: ucmd setenv my_custom_var "value" FB: ucmd saveenv FB: ucmd reset FB: done 顺祝商祺！ 萨拉斯。 Re: IMX8MP linux uboot need to be set up with the default environment + extra variables 嗨@Manuel_Salas ， 我们只会在 uboot 中启用 eth fastboot，因此我们不能使用 SDP 的启动开关。请问是否有只使用fastboot命令的选项？ 谢谢！

カメラモジュールの互換性OX05B1S センサーおよび内蔵ISPとi.MX95 FRDM対応 こんにちは、皆さん。 ox05b1sセンサーと内蔵ISPを搭載したカメラモジュール(NVIDIA Jetson AGX Orin用の5MP RGB-IR Global Shutter GMSL2カメラに似たもの)がi.MX95 FRDMボードに対応しているか知りたいです。 i.MX95はポートがMIPI_CSI2しかないので、GMSL2からMIPI_CSI2コンバータを探す必要があるのは理解していますが、私の質問はNXP Linux BSPに含まれる既存ドライバの互換性に関するものです。NXP Linuxリリースのドライバ カメラドライバーはこのカメラモジュールと直接動作しますか? dtbファイルに変更を加える必要はありますか？他に何か変更点や追加作業が必要で、計画しておくべきことはありますか？

关于通过 I2C 进行 PCA9450CHN 电压配置的查询 我们正在使用 PCA9450CHN PMIC，并且了解到它使用默认稳压电压上电，可以通过 I2C 编程进行修改。请您解释一下上电后更改这些电压的完整步骤，包括SoC开始与PMIC通信时的步骤？另外，请告知我们推荐的调试器或工具，以便监测和验证 PMIC 寄存器编程和电压变化。 电路板设计 HW-开源 Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png 您可以参考以上内容，在 POR_B 信号拉高且 PCA9450C 进入 RUN 模式后，您可以更改其电源轨输出值。

如何使用MC33 PT2000集成电路调整SOI-EOI 正如主题所述，我们需要能够建立整个流程的帮助，该流程使用PT2000进行燃油喷射SOI-EOI测量。 H桥驱动器 小型发动机驾驶员 电磁阀控制器 Re: How use adjust SOI -EOI with use MC33 PT2000 IC 谢谢！ Re: How use adjust SOI -EOI with use MC33 PT2000 IC 亲爱的K爱津斌， PT2000 产品页面上提供了 PT2000 注射结束检测应用笔记，可供下载，并附有有效的保密协议。 JozefKozon_0-1786079976443.png 如果您还没有保密协议，并且想要签署一份，请在此处创建一个新工单，我们的保密协议事务代表将协助您完成该流程。 此外，请从FRDMPKPT2000EVM 产品页面下载 PT2000SWUG 和 PT2000-IDEUG。您也可以从同一页面下载 PT2000 Developer Studio IDE 以及峰值保持和 DCDC 软件的软件文件。之后，您可以在FRDMPKPT2000EVM 评估板上测试软件示例。 JozefKozon_1-1786080423866.png 最诚挚的问候， 约瑟夫

PPF0900AMBA1ES 您好，NXP团队： 我正在开发一款基于 i.MX95（MIMX9596，19x19 封装，LPDDR5）的定制板，采用 PPF0900AMBA1ES PMIC。 请您确认一下： 1.该部件号出厂时是否已预先编程了OTP，还是未编程的工程样品？ 2.如果未进行编程，建议如何对 OTP 配置进行编程（或模拟）以进行启动和评估？ 3.是否有适用于 i.MX95 + LPDDR5 (19x19) 实现的参考 OTP 配置文件 (.CFG) 可供我们用作起点？ 作为背景，我们的原理图与 i.MX95 EVK 参考设计（PF09 + PF5301 + PF5302）非常接近，我们目前正在进行初始上电启动。 谢谢！ PMIC Re: PPF0900AMBA1ES PPF0900AMBA1ES 是 OTP 部分，这意味着已经完成了 OTP。 https://www.nxp.com/docs/en/supporting-information/MPF0900AMBA1ES.zip 请从上方链接下载OTP文件。

S32K566 LPUART通信の問題 こんにちは、 S32K566マイクロコントローラの4 Uart_Example_S32K566_M7モジュールを使い、LPUARTモジュールクロックは50MHzです。ボーレートを115200に設定し、UARTからUSBへのコンバータを使ってPCにデータを送0xAAしています。しかし、受信したデータは誤りです（0x00 0x80 0x80）。ボーレートを115200/8 = 14400に設定すると、データは正しく受信されます。9600や19200といった異なるボーレートも試してみました。 私はS32DS 3.6.6とSDK 0.8.0を使っています。 Uart_Example_S32K566_M7のソースコードも添付しておりますので、ご確認ください。 参考資料として、設定ファイルと受信データのスクリーンショットを添付しました。 Manikandan_Aruchamy_0-1786092514163.png レシーバ端子のウィンドウボーレートは115200です: Manikandan_Aruchamy_1-1786092584169.png レシーバ端末のウィンドウボーレートは14400です: Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue こんにちは、 @Manikandan_Aruchamy さん。 このメールが、あなたがお元気でいらっしゃる時に届くことを願っています。現在お手元にある製品、まだ正式に発売されていないNPI(新製品導入)についてお手伝いしています。 これらの製品の早期アクセス権を得たお客様は、現場エンジニアを割り当てていることにご注意ください。指定されたフィールドエンジニアが、この製品に関する問題や懸念、問い合わせの主要なサポートチャネルとなります。 正式リリース後、オンラインサポートチームはより幅広いサポートを展開していきます。それまでは、私たちは必要な支援を提供する体制が整っていません。 ご理解いただきありがとうございます。 よろしくお願いいたします。 パベル

PPF0900AMBA1ES こんにちは、NXPチームの皆様、 i.MX95(MIMX9596、19x19パッケージ、LPDDR5)をベースにしたカスタムボードをPPF0900AMBA1ES PMICを使って作っています。 確認いただけますか: 1. この部品番号の商品は、OTPが既にプログラムされた状態で出荷されますか、それともプログラムされていないエンジニアリングサンプルですか？ 2. プログラムされていない場合、起動および評価目的でOTP構成をプログラム（またはエミュレート）するための推奨手順は何ですか？ 3.Is 参照OTP設定ファイル(.i.MX95 + LPDDR5(19x19)実装で利用可能なCFG)を出発点として使えるでしょうか? 参考までに、私たちの回路図はi.MX95 EVKのリファレンスデザイン(PF09 + PF5301 + PF5302)に忠実に従っており、現在は初期電源オンの起動作業を行っています。 よろしくお願いします。 PMIC Re: PPF0900AMBA1ES PPF0900AMBA1ESはOTP部分であり、既にOTPが実行されていることを意味します。 https://www.nxp.com/docs/en/supporting-information/MPF0900AMBA1ES.zip OTPファイルは上記のリンクからダウンロードしてください。

FRDM-MCX N947 和 OV5640 相机 我目前正在将一个摄像头流媒体管道（之前在 ESP32-S3 上开发）移植到 FRDM-MCXN947。目标分辨率为 1080p，通过 OV5640 摄像头模块进行捕获，通过 MCXN947 硬件加速器进行处理，并通过 SPI 流传输到 ESP32-C5 进行 Wi-Fi 传输。 硬件流水线： OV5640 摄像头（8 位 DVP）-> MCXN947（FlexIO / SmartDMA）-> 外部 PSRAM -> SPI -> ESP32-C5 -> Wi-Fi 当前进度和设置 SCCB/I2C 控制：功能齐全。相机寄存器读写操作成功，初始化完成。 SmartDMA 基准测试：测试了 OV7670（使用内部 SRAM）的 NXP SDK SmartDMA 示例，结果符合预期。 目标：使用 OV5640、外部 PSRAM 缓冲和 FlexIO 捕获，将其扩展到 1080p 分辨率。 问题 1：FlexIO 引脚重映射 & D4/D5 引脚数据无效 当尝试通过 FlexIO 进行 8 位并行捕获时，数据线 D4 和 D5 无法读取有效的像素数据，而数据线 D0-D3、D6 和 D7 则表现正常。 初始引脚映射： D0-D3：P1_4、P1_5、P1_6、P1_7 D4-D5：P3_4、P3_5（问题：无有效像素数据） D6-D7：P1_10，P1_11 控制：VSYNC > P1_18，HREF > P1_19，XCLK > P2_2 SCCB：SCL > P3_2，SDA > P3_3 已尝试的故障排除方法： 我尝试将 D4 和 D5 重新映射到其他引脚，并更新了相应的 FlexIO 和引脚复用器配置： 重新映射 D4：P2_8 重新映射 D5：P2_9 即使经过重新映射，D4 和 D5 仍然无法捕获有效数据。 问题 2：1080p 的 SmartDMA 路由到外部 PSRAM 由于 1080p 帧缓冲区超过了内部 SRAM 容量，因此必须将帧实时缓冲到外部 PSRAM 中。 我正在寻找最佳实践和配置步骤，以配置 SmartDMA，将传入的 FlexIO 相机数据直接路由到外部 PSRAM，而无需 CPU 干预或帧撕裂。 任何见解、引脚映射建议或参考代码都将不胜感激！ 电路板设计 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCX N Re: FRDM-MCX N947 and OV5640 Camera 嗨@DocMonster7 我们已经在 FRDM-MCXN947 板上验证了官方 SDK 示例 frdmmcxn947_smartdma_camera_flexio_mculcd_cm33_core0，该示例通过 J9 摄像头接口连接了 OV7670 相机。在本参考设计中，CAMERA_D4 和 CAMERA_D5 分别映射到 P3_4 和 P3_5，图像捕获工作正常。 根据此验证，P3_4 和 P3_5 似乎作为相机数据输入正常工作。因此，该问题不太可能是由这些MCU引脚本身的限制引起的。 我们建议进一步检查 OV5640 硬件连接、信号完整性、引脚复用配置以及对原始 SmartDMA 相机捕获实现所做的任何修改。 Harry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.png BR 哈里 Re: FRDM-MCX N947 and OV5640 Camera 嗨，哈里， 感谢您在 J9 上验证 SmartDMA OV7670 SDK 示例。这样就明确了二者的区别。 造成这种差异的原因是所使用的捕获外设不同。 SmartDMA（EZH 引擎）：直接对 GPIO/EZH 端口进行采样（其中 J9 上的 P3_4 和 P3_5 可作为 EZH_LCD_D4/D5 正常工作）。 FlexIO 并行引擎 (fsl_flexio_camera)：需要 8 个连续的 FlexIO 移位器数据引脚（FLEXIO0_D12 至 FLEXIO0_D19）。在 FRDM-MCXN947 上，J9 上的 P3_4 和 P3_5 没有 FlexIO 引脚复用。要获得连续的 FlexIO D16/D17 线，必须将它们路由到 P3_8 (TP16) 和 P3_9 (TP15)。 当将 D4 路由到 P3_8 (TP16) 以进行 FlexIO 捕获时，我们在 P3_8 上遇到了活跃的硬件争用（在 ~0.15V - 1.3V 钳位的主动驱动 GPIO 测试），因为 P3_8 与板载 QSPI Flash (U8 Winbond W25Q64, FlexSPI0_A_DATA0) 共享。 Re: FRDM-MCX N947 and OV5640 Camera 嗨@DocMonster7 谢谢分享。如果您没有其他问题，请接受此答案。 BR 哈里

S32K338に関する詳細情報 おはようございます。 S32K388マイクロコントローラがK324のように3つの独立したコアを持っているのか、そしてそのうち2つのコアがLockstepでも使えるのか知りたいです。 シングルコア1つ+ロックステップコア1つが欲しい場合、K358を使うべきでしょうか? ありがとう Re: Detail about S32K338 こんにちは、 @gianpiero_lenta さん、 ロックステップ操作は、独立したコア間で有効化できるソフトウェア設定可能な機能ではありません。それに対し、Lockstepは特定のS32K3派生製品に実装された専用のハードウェア構成である。 したがって、アプリケーションで独立したCortex-M7コアとLockstep Cortex-M7ペアが必要な場合は、このハードウェア構成で設計されたS32K358の使用をお勧めします。 よろしくお願いいたします。 パベル

USBシリアルダウンロードモードが動作するかどうか こんにちは、 現在のプロジェクトでは、製品にはUSB 2.0高速を動作させる「USB-C」ポートが「1つ」のみあります。私たちの目標アプリケーションは、このUSBポートをUSBホストとして使い、USBメモリやソリッドステートドライブを接続してローカル録画を行うことです。 しかし、次の改訂版PCB回路では、以下に示すように、USB-Cの2つのCCピンの両方でVCC_5V0に56KΩのプルアップ抵抗を設ける予定です。つまり、CC構成定義に基づいて、USBポートをUSBホストにハードワイヤリングで固定したということです。ホストとデバイス間でCCピンを切り替えるジャンパー/スイッチ/Type-Cコントローラ(DRP(デュアルロールポート)論理IC)回路は存在しません。 Esther_Liu_0-1786180179443.png この回路に基づいて、i.MX8M+ USB シリアルダウンロードモードはまだ動作するのか知りたいです。i.MX8M+ Boot ROMがUSBシリアルダウンロードモードを有効にすると、ポートは自動的にUSBデバイスとして設定されることは理解しています(USBシリアルダウンロードモードが動作するため)が、それはチップのROMコードが内部USB PHYのみをデバイスモードに制御し、ハードウェアの外部CC抵抗状態(Type-Cポートの役割)を上書きできないことを意味します。その結果、PCはUSB経由で i.MX 8M Plusを列挙することができず(両者ともUSB物理層の視点からハンドシェイク(Type-C Attach)を完了できず)、UUUプログラミングが失敗します。上記の記述が正しい場合、USBシリアルダウンロードモードは起動前に動作不能になり（つまり全く動作しなくなり） 、工場出荷時のフラッシュ書き込み機能やシステム復旧機能が失われます。 私たちの理解は正しいでしょうか？ よろしくお願いいたします。 Re: Whether USB serial download mode can work or not こんにちは、 @Esther_Liu さん おっしゃる通りです。CCをプルアップ接続に強制すると、ホストモードのままになり、UUUが正常に動作しなくなる可能性があります。 B.R

I2Cを介したPCA9450CHNの電圧設定に関する問い合わせ 私たちはPCA9450CHN PMICを使用しており、デフォルトのレギュレーター電圧で電源が動くことを理解しており、I2Cプログラミングで修正可能です。電源オン後の電圧変更の全順、特にSoCがPMICと通信し始めるタイミングについて説明していただけますか?また、PMICレジスタのプログラミングや電圧変化を監視・検証するための推奨デバッガーまたはツールがあれば教えてください。 ボード設計 HW-Open-Source Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png 上記のように、POR_B信号がハイを引き、PCA9450CがRUNモードに入ると、電源レールの出力値を変更できます。

MIMXRT1170-EVK FreeRTOS Hello 示例问题 大家好， 我将 MCUXpresso SDK 中的evkbmimxrt1170_freertos_hello_cm7示例项目导入到 MCUXpresso IDE 中，没有做任何重大修改。 项目构建成功，没有任何错误或警告，并成功下载到 MIMXRT1170-EVK(MIMXRT1176DVMAA) 板。 任务创建成功，但只执行了一次，然后在地址0xDEADBEEE处停止。这种行为每次都会发生。 LED切换任务： 为了验证问题是否与 vTaskSuspend() 有关，我创建了另一个简单的 LED 闪烁任务。 预期行为： LED应该每100毫秒持续切换一次。 实际行为： LED灯只闪烁一次。 第一次执行后，调试器再次停止在： 0xDEADBEEE 请您解答以下疑问： 在 i.MX RT1170 的 MCUXpresso SDK 中，地址0xDEADBEEE表示什么？ 为什么该任务只执行一次而不是定期运行？ MIMXRT1170-EVK 是否需要进行任何额外的配置才能正常工作？ 要使任务按预期定期执行，需要进行哪些更改？ Rosh_0-1786093292545.png Rosh_1-1786093311524.png Rosh_2-1786093339102.png Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue 你好@Rosh ， 我了解到您目前正在使用 MIMXRT1170-EVK。请注意，MIMXRT1170-EVK 的 SDK 与 MIMXRT1170-EVKB 的 SDK 不同。请您使用 MCUXpresso SDK Builder下载并测试专门为 RT1170-EVK 生成的 SDK 好吗？ Habib_MS_0-1786125239179.png 我明白你的意思。SDK 示例旨在为每个外围设备功能提供常见用例。0xDEADBEE 值通常与 HardFault 情况相关。 请您在不做任何修改的情况下运行示例，并使用最新可用的 SDK 版本告诉我结果。 BR 哈比卜 Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue 你好@Habib_MS 我使用 MCUXpresso SDK Builder 下载了专门为 RT1170-EVK 生成的 SDK，并进行了测试。现在运行正常了。 感谢您的支持。

T Embedにはどのようなポートがありますか？ 標準モデルのTエンベッドを持っていますが、どのポートか全く分かりません(もう一つのポートで、USB-Cではありません)。公式サイトではGroveポートと書いてあり、LilygoのWikiサイトではQwiicポートと書かれています。どなたか助けていただけませんか?