EB Tresos configuration : XRDC domain master instance, Xrdc_0_HSE_B is not available Hello, I'm migrating from RTD 4.0.0_P20 to 7.0.1 + 7.0.2_P02. I'm using EB tresos for configuration. In the RM module, I have an error in XRDC domain master instance => Domain master assignement => Xrdc Master instance  I can't choose Xrdc_0_HSE_B. As I remember without this my software stuck when using HSE jobs. what should I do ? Sophie Re: EB Tresos configuration : XRDC domain master instance, Xrdc_0_HSE_B is not available Hello @sobo, I've triggered an internal discussion regarding this configuration, as it seems a specific SBAF and HSE framework version does not need MDAC3 assignment through RTD. I will let you know as soon as I get a response. Best regards, Julián

GUI Guider シミュレータとi.MX RT1040、およびディスプレイが展開時にハングアップする そこで、GUI GuiderでUIを作成し、シミュレーションを実行すると、何度試してもシミュレータが応答しない状態になります。同様に、コードをボードに書き込むと、数秒後に画面がフリーズし、再書き込みや再起動後も応答しなくなります。 困っています。この問題をデバッグする方法がわかりません。 Re: Gui Guider Simulator and the i.MX RT1040 along with the display hangs on deployment はい、正しく初期化されます。コードを生成してデバッグおよびシミュレートすると、ログにエラーはありません。シミュレーターウィンドウがポップアップ表示されますが、数回クリックすると応答しなくなります。同様に、ボードにフラッシュすると、数回押すと画面がフリーズします。これは私のプロジェクトでのみ発生していることに気づきましたが、プリインストールされているサンプルを試すと正常に動作します。 エラーメッセージもデバッグ情報も表示されないため、この問題を具体的にどのように解決すればよいのか知りたいです。 Re: Gui Guider Simulator and the i.MX RT1040 along with the display hangs on deployment こんにちは、 @svlute さん。 シミュレータに関してですが、応答状態になるとおっしゃっていますが、それは正しく初期化されるものの、実行中に停止してしまうという意味でしょうか？あるいは、ポップアップウィンドウがGUIとともに表示される前（または表示された直後）から、応答しなくなるということでしょうか？ログパネルに警告メッセージやエラーメッセージが表示されていますか？ RT1040へのインポートに関してですが、サンプルプロジェクトでも同様の問題が発生しますか？使用しているGUI Guiderのバージョンと表示形式は何ですか？ BR、 エドウィン。 Re: Gui Guider Simulator and the i.MX RT1040 along with the display hangs on deployment こんにちは、 @svlute さん。 ご説明いただいた状況から判断すると、問題はプロジェクト固有のコードに起因していると思われます。おそらく、変更すべきでない部分を変更するカスタムコードを使用していることが原因でしょう。GUI上のイベントにカスタムコードを使用していますか？もしそうなら、具体的にはどのようなことですか？ BR、 エドウィン。

enet_ethernetif_qos.c をビルドします。 こんにちは、 CMakeLists.txtからこれらのファイルを含める必要があります mcux_add_source ( SOURCES ../../../mcuxsdk/middleware/lwip/port/ethernetif.c ) mcux_add_source ( SOURCES ../../../mcuxsdk/middleware/lwip/port/ethernetif_mmac.c ) mcux_add_source ( SOURCES ../../../mcuxsdk/middleware/lwip/port/enet_ethernetif_qos.c )   イーサネットを使用してプロジェクトを構築するため。 代わりにprj.confファイルにKconfigのシンボルを設定することはできますか？   このプロジェクトはMCXE31Bに関するものです。 Re: Build enet_ethernetif_qos.c こんにちは、 @jonasa ご辛抱いただきありがとうございます。 いいえ、これはprj.confのKconfig経由ではできません。 Kconfigは機能の有効化のみを制御し、ソースファイルをビルドに追加する機能はありません。 そのため、これらのlwIPポートファイルは、CMakeLists.txtに手動で追加する必要があります。   よろしくお願いします。     BR アリス

Replacement for the SA602AD VHF Mixer Hi, I'm new here Since the SA602AD is out of production I would like to know if there is any replacement available for this product. It is used in a radio receiver that operates at 7MHz and is designed to receive a simple serial message at 115200bps. Thanks RF Re: Replacement for the SA602AD VHF Mixer Please check if this is the SA602AD model shown in the picture? I purchased 8000 original authentic products from this picture.

FRDM S32K344 172 引脚 QSPI - Qspi_Ip_EraseBlock 超时 您好， 我目前正在开发 FRDM S32K344 EVK（172 引脚），并将一个 W25Q64JVSSIQ外部闪存的接口。 我们从为 S32K344 提供的现有 QSPI 示例开始，当该示例独立组网 (SA) 执行时，QSPI 读/写操作可以正常运行。但是，在将 QSPI 与 CAN 和 LPUART 功能集成后，我们在闪存擦除操作期间开始遇到超时问题。 超时发生在 Qspi_Ip_EraseBlock() 我们还研究了 Mem_ExFls_PinSetup() 中的引脚配置。中的引脚配置，并尝试了以下两种方法： 守住底线I p_siul2->imcr[821 - 512]= siul2_imcr_sss(1u)； 注释掉上面一行。 遗憾的是，这两种方法都没有解决问题。 环境： 板：FRDM S32K344 EVK（172 针） 外置闪光灯：W25Q64JVSSIQ 集成开发环境用于 S32 平台的 S32 Design Studio 版本： 3.6.7 版本 ID：260420 热电阻： S32K3 RTD R23-11 v7.0.1 板修订版：SCH-94921 修订版 B 为您的 ref main.c 添加的代码片段 在将 QSPI 与 CAN 和 LPUART 等其他外围设备集成时，有没有人遇到过类似的超时问题？如果能就时钟配置、中断优先级、引脚复用或 QSPI 驱动程序设置提出任何建议，我们将不胜感激。 谢谢 Re: FRDM S32K344 172-pin QSPI - Qspi_Ip_EraseBlock Timeout 这显然纯粹是应用问题。不幸的是，我不要求你分享代码，因为如果没有提到不属于评估板的外部存储器，我就无法对其进行测试。 一开始我会尝试延长超时值。您可以在 Qspi_Ip_EraseBlock() 过程中暂时禁用中断，以验证时序敏感性。比较 QSPI 时钟配置（集成前/后，因为不清楚项目的基础是什么）。 如果可能，还可以在禁用 CAN/LPUART 但仍编入的情况下测试擦除，以隔离运行时与配置的影响。 Re: FRDM S32K344 172-pin QSPI - Qspi_Ip_EraseBlock Timeout 你好，大卫-托瑟诺夫扬、 感谢您的答复。我明白你的意思，我会尝试按照你建议的步骤来调试超时问题。 如果我需要进一步澄清，或者在调查过程中有任何发现，我会通知你。 再次感谢您的支持。

IMX9596 和 IMX9594 电路板支持包 兼容性 根据 IMX95 的规格，IMX9594 和 IMX9596 的唯一区别似乎在于 CPU 内核。是否需要对 电路板支持包。 代码进行任何更改才能支持 IMX9594？ 我的 电路板支持包 代码库是 " Walnascar，imx-6.12.34-2.1.0.xml " MACHINE=imx95EVK DISTRO=fsl-imx-Wayland source ./imx-setup-版本.sh -b build-imx95 Re: IMX9596 and IMX9594 BSP compatibility 你好@pengyong_zhang 感谢您的反馈。 因此，同一图像可以在 imx9594 和 imx9596 上使用。是这样吗？ Re: IMX9596 and IMX9594 BSP compatibility 你好@avery 对于 IMX9594 和 IMX9596，无需更改电路板支持包代码。 B.R Re: IMX9596 and IMX9594 BSP compatibility 你好@avery 是的，没错。 B.R

关于 S32K396 上的 eTPU 解析器外推信道触发器 你好，我正在使用 EB 配置 S32K396 上的 eTPU 解析器。 目前，我在调用 Etpu_Resolver_Ip_GetExtrapolatedOutputs(&Etpu_Resolver_Ip_Instance_I0,&pResolverOutputsExtrapolated) 时遇到一个问题：外推输出值总是为零。 从代码中，我注意到 Extrapolated 通道被配置为上升沿触发器，但是在演示项目中，我找不到这个触发器实际发生的位置或方式，也找不到哪个配置启用了它。 此外，手册指出，外推线程可以通过三种方式触发。 我通过调用 Etpu_Resolver_Ip_Sample(&Etpu_Resolver_Ip_Instance_I0)尝试了第一种方法（主机服务请求）； 内的ATO 通知（在 ATO 更新第 2 次）回调。这确实触发了外推频道，然后我可以使用上面的函数读取有效数据。不过，我不确定这是否是正确或有意的做法。 作为参考，我在 EB 中基于 s32k3_etpu_sw _4.7_2.0.0_cd04_d2502_motorControlExample 配置了这个项目。我的环境详情如下 RTD 版本：SW32K3_S32M27x_RTD_R21-11_5.0.0 eTPU 版本：S32K3_ETPU_SW_4.7_2.0.0_CD04 编译：全球统一制度 你能否帮忙澄清一下在这种配置中应该如何触发外推通道，以及我目前的方法是否与预期的设计一致，谢谢！ Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 我相信您已在 TRGMUX_APP 中正确地将 LCU 输出路由至 eTPU 通道 A7。我认为您漏掉了 eTPU 通道 A7 的 IMCR 配置 /* 从 TRGMUX 分配 eTPU 输入 */ Siul2_Port_Ip_SetInputBuffer(NULL_PTR, 0U, 1, 458, 4U)；   TRGMUX 电子表格中的橙色标记单元格注释中提到了这种配置： Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 感谢您之前的回复。接下来我想再问一个关于触发 eTPU 解析器外推的问题。 在我目前的设置中，PWM 触发信号首先通过 TRGMUX 路由到 LCU。LCU 应用所需的延迟，然后其输出再次通过 TRGMUX 路由到外部 IO 引脚和 eTPU 外推通道。 在示波器上，我可以清楚地观察到 IO 引脚上的预期信号。但是，eTPU 外推通道仍未被触发。 请问是什么原因导致了这个问题。外推通道是否需要任何其他配置才能通过 TRGMUX 接受来自 LCU 的触发信号。 下面两张图片显示了 EB 中的 Resolver 通道配置和我的项目中相应的外设初始化代码。 Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 你好，李哲、 这取决于您的应用。我相信你会控制电机。因此，你需要在测量电机电流的同时触发外推，这样才能同时获得电机控制算法所需的所有数据（相位电流、Udcbus、电动机的位置和速度）。 在电机控制中，我们使用的触发信号与 BCTU/SARADC 相位电流测量使用的触发信号相同。它由 FlexPWM 产生。并通过 LCU 和 TRGMUX 路由至 eTPU。LCU 可以延长触发脉冲的时间，这样 eTPU 逻辑才能看到触发脉冲。 您可以在 S32K396 单电机控制套件 SW 中查看配置。S32K396 BLDC/PMSM 电机控制开发套件|恩智浦半导体。代码使用的是 RTD 低电平驱动器，但 eTPU 的配置与此基本相同。 此致， 托马斯 Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 此外，基于相同的项目设置，我在 ATO 通知（关于 ATO 更新第 2 次）功能中添加了一个测试，以手动写入外推通道的 HSR。这样就可以正常工作了。下图显示了我在中断回调中添加的函数。 下图显示了我在调试器中观察到的外推数据。 如果我注释掉对Etpu_Resolver_Ip_Sample(&Etpu_Resolver_Ip_Instance_I0);的调用，就会在调试器中观察到如下状态，所有外推值都保持为零。 Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 请与我分享精灵文件，好吗？ 在使用设计工作室进行编辑时，能否请您分享一下整个项目？ 谢谢、 此致， 托马斯 Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 是的，请告诉我您的电子邮件地址。   Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 我之前配置了这个寄存器，在用你提供的功能替换了我之前的配置之后，eTPU 仍然没有被触发。 如下图所示，触发信号的脉冲宽度为 8.4 µs。 下面是我的 EB 配置，其中 LCU0_LC0_OUT1 被路由到 eTPU A7 通道。 这就是我在调试器中观察到的 TRGMUX 配置。 Re: About eTPU Resolver Extrapolated Channel Trigger on S32K396 你好，李哲、 我刚刚找到了最后一块拼图。我认为没有 RTD/MCAL 驱动程序，因此您可以使用下面的代码，这样您也可以使用。 /* 配置传送到 eTPU 的外推触发信号的 IGF */ void IGF_Init(void) { IP_IGF->MCR[8].MCR= IP_IGF->MCR[8].MCR|igf_mcr_fgen(1)； // 仅在旁路模式下启用滤波器，以使信号从焊盘传递到 eTPU 通道输入端 } 此致， 托马斯

MWCT2016 || ADC分解能 チームの皆さん、こんにちは。 当社製品ではMWCT2016を使用しています。データシートから、ADCの分解能が12ビットであることがわかっています。解像度が15ビットかどうかを知りたいです。チームから「 32747」というADCの10進数値が読み取られたとの報告があったため、解像度が15ビットか12ビットかを確認したいのです。 Re: MWCT2016 || ADC resolution こんにちは、 @diwakar1307 さん。 ADCの分解能は常に15ビット幅ですが、選択できる分解能は最大14ビット（8ビット、10ビット、12ビット、14ビット）までです。 MWCT2xxxSのリファレンスマニュアルおよびいくつかのコミュニティ投稿に記載されています。 解決済み：S32K344 ADCのデータアライメントとビット分解能 - NXPコミュニティ S32K3 ADCの精度と結果に関する混乱 ただし、高精度チャネルと標準チャネルのTUE仕様（製品のデータシートに記載）は、12ビットレベルの分解能に基づいていることにご注意ください。 よろしくお願いします、 ジュリアン

MPX5999D アプリケーションの問題 こんにちは。MPX5999D製品についていくつか質問があります。水中での使用時に発生した問題点についてご説明いたします。まず、基準圧力P2はリアルタイムで読み取られるのでしょうか、それとも電源投入時の圧力値のみでしょうか？次に、基準圧力P2が大気圧より低い場合でも、センサーは正常に動作するのでしょうか？最後に、センサー内部回路の校正を行う際、校正条件として大気圧が使用されるのでしょうか？このため、水中での使用時に誤差が生じる可能性があります。

从 TJA1145 读取 ID 的 SPI 问题示例 在尝试通过 SPI 读取 ID 时，我收到了以下回复。0xFD74.根据数据表，预计为 0x74。   但如果我再次发送 0xFD00 服务，TJA1145 会给出不同的回应。为什么会这样呢？响应循环重复，这意味着 BufferRx[4] 将是 0xFD74。   我想使用 0x0207 将收发器设置为正常模式。然而，在这里我也收到了不同的答复，但却不是我所期望的答复。   感谢您的支持！ Re: SPI problem example read ID from TJA1145 感谢您的回复。 如果我按照建议发送信息，会得到如下答复： 看起来 TJA1145 正在通过以下寄存器值（16 位）做出响应 ，并在 SDO 上反映 SDI。我还可以看到，如果我发送帧 1，将 SDI 调至低电平，然后开始读取寄存器 0x7E，就会出现预期的响应。 根据数据表，S D I 在传输后可以保持浮空。从机需要低级别来重置其内部状态机吗？ 预先表示感谢！ Re: SPI problem example read ID from TJA1145 您好，SPI 接口以全双工模式运行，即同时传输和接收数据。但是，设备不会在同一 SPI 帧内返回当前命令的结果。取而代之的是与之前接收到的命令相对应的响应。 因此，请您尝试一下 第 1 帧： TX (MOSI)：READ命令 → 地址 0x7E，RO = 1 RX (MISO)：未定义或之前的数据 第 2 帧： TX（MOSI）：虚拟数据（例如 0x0000） RX（MISO）：有效响应 → 设备 ID 值（例如 0x74） Re: SPI problem example read ID from TJA1145 连接到 SDI 的外部上拉值是多少？ 请参阅 AH1903 应用提示 - 用于部分联网的高速 CAN 收发器 TJA1145A 第 7.4.1 节安全文件下的 SDI 引脚输入行为！ Re: SPI problem example read ID from TJA1145 你好，我找到了根本原因。由于硬件配置的原因，CS引脚的电压过低。感谢您的支持！

NXPのMCXマイコンとSDKを使ったSPI通信の基本：SPIの4つのモードと実際の信号確認 (日本語ブログ) はじめに 前回は、SPI通信の 前編としてFRDMボード2台用いて、SPI通信のサンプルアプリケーションを動かしてみました。 NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) 今回は、４つのSPIモードの設定を変えながら、実際に送受信されるSPI信号を確認してみようと思います。本稿では、以下の[前編]記事の作業が完了していることを前提に進めます。 [前編] SPI通信のサンプルアプリケーションを動かしてみる。 [後編] SPIのモードを変えながら、実際のSPI信号を観測して、変化を見てみる。 (作業時間：20分) ※前編の内容（MCUXpresso for VSC, SDKがインストールされていて、SPIのアプリケーション動作確認）が済んでいる前提。 目次  準備するもの SPIモード CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？) SPI信号を実際に確認 各SPIモードにおける信号の測定結果 おわりに １．準備するもの ハードウェア ・FRDM-MCXN947 (USBケーブル付属) x 2枚 ・ジャンパ線 : 複数本 ・ロジックアナライザー ※SPI信号解析用 ソフトウェア ・FRDM-MCXN947用のSDK 　＊MCX N947向けのSDK(ver. 26.3.0)をVSCodeにインストールした前提で説明していきます。 　　開発環境(MCUXpresso for VSC)の準備、SDKのインストール方法は、以下の記事をご参考ください。 　　記事：MCUXpresso for VSCとSDKのインストール (日本語ブログ)   ２．SPIモード 記事SPIバスの概要 (日本語ブログ)にて、CPOL = 0 or 1, CPHA = 0 or 1の組み合わせ、計4通りのモードがあると説明されています。 CPOL（Clock Polarity：クロックの極性）：通信していない「アイドル時(=非転送時)」に、クロック線（SCLK）がどちらの電圧レベルになっているかを設定。 CPOL=0 : アイドル時Low CPOL=1 : アイドル時High CPHA（Clock Phase：クロックの位相）：データ送信とラッチ(サンプリング)タイミングをクロックのエッジ（立ち上がり・立ち下がり）のどちらに合わせるかを設定。 CPHA=0 : 1回目のクロックエッジでデータをサンプリング、2回目でデータを出力 CPHA=1 : 1回目のクロックエッジでデータを出力、2回目でデータをサンプリング 表１　４つのモードとCPOL，CPHA   CPOL CPHA mode=0 0 0 mode=1 0 1 mode=2 1 0 mode=3 1 1   図１　CPOL，CPHAの設定による挙動   ３．CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？) 先ずは波形を確認していく前に、前回SPI通信のサンプル・アプリケーションをデフォルトの状態でビルドして動かしてみました。デフォルト状態のCPOL、CPHAの設定を確認します。  CPOLとCPHAは、fsl_lspi.hの中で定義されています。  図２　CPOLとCPHAの定義(fsl_lspi.h) 次にSPIの初期化は、fsl_lpspi.c内のLPSPI_MasterGetDefaultConfig()内で実施されていました。 下図赤枠内で、コントローラ(マスタ)側のCPOL=0, CPHA=0が設定されていることが分かりました。また同じファイル内にデバイス(スレーブ)側の設定LPSPI_SlaveGetDefaultConfig()も含まれているので、CPOL、CPHAをマスタとスレーブの2カ所ともパラメータを変更しながらテストしていきます。 図３　マスタ側の設定箇所 LPSPI_MasterGetDefaultConfig()    図４　スレーブ側の設定箇所 LPSPI_SlaveGetDefaultConfig()   ４．SPI信号を実際に確認 それでは、「前回の記事」を参考に２つのFRDMボードとPCを接続させて、シリアル・モニターも２つ開いて、それぞれのサンプル・アプリケーションが動作していることを確認してください。 図５　シリアルモニターでのSPI通信結果 この状態で、２つのFRDMボードのSPIを結線します。 ※先に結線してからFRDMボードに電源を入れてしまうと、うまく動かないことがありますので、ご注意ください。 前回の記事と同じ内容ですが、FRDM-MCXN947の回路図を確認してみると、以下のJ2コネクタの#8がMOSI、#10がMISOであることが分かります。 図６　FRDM-MCXN947のSPI回路図 FRDM-MCXN947上のJ2コネクタ同士を以下のように、ジャンパ線で接続してください。 ※J2の#6ピンと#8ピンをクロスさせて接続してください。 表２　FRDM-MCXN947同士のSPI結線 LPSPI_master LPSPI_slave J2-14 : GND J2-14 : GND J2-12 : CLK J2-12 : CLK J2-6 : SOUT(MOSI) J2-8 : SIN(MISO) J2-8 : SIN(MISO) J2-6 : SOUT(MOSI) J2-6 : SS(PCS) J2-6 : SS(PCS) 通常ArduinoシールドソケットでSPIに使われるD10、D11、D12、D13に相当する端子です。 図７　SPI接続図  ※今回はこのMaster - Slave間の信号を確認するためにロジック・アナライザーを接続します。 ではロジック・アナライザが正しく動作しているか実際にSPI信号を送受信して確認してみます。 図８　SPIデータ送受信をシリアル・モニターで表示した結果   図９　SPIデータ送受信をロジック・アナライザーで表示した結果 　上図の文字が小さいのですが、Masterから見た際に、送信、受信共に正しく動作していることが確認できました。 　ここで送信部分(↑画像上半分)を見てみると、MOSI(Master Out Slave In)はデータがインクリメントされていくのに対して、MISO(Master In Slave Out)がずっと"High (=hFF)"であることが分かります。反対に受信部分(↑画像下半分)を見てみると、今度はMOSIが"High (=hFF)"固定で、MISOはデータがインクリメントされています。 これは正しい動きで、SPIバスの概要 (日本語ブログ)にも記載があるとおり、非データ転送時のMOSI，MISOの出力はハイ・インピーダンス状態におかれるためです。 それでは実際の信号を見ていきます。 ５．各SPIモードにおける信号の測定結果 ここからは３．CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？)を参考にしながら、マスタ、スレーブ両方の「CPOL、CPHAの値を変更→ビルド→書き込み」を行い、測定を行いました。 SPIモード0：CPOL=0, CPHA=0のSPI信号 (デフォルト設定の状態) 図１０　CPOL=0, CPHA=0時のMasterからSlaveへのデータ送信波形 図１０を見るとクロック(CLK)はデータが転送される前(アイドル時)にLowとなっている(図中の橙枠)ので、POL=0であることが分かります。 また1回目のCLKの立ち上がりエッジでMOSIのデータをラッチ(図中の赤線)しており、2回目のCLKの立ち下がりエッジでMOSIのデータを変化(図中の緑線)させているので、CPHA=0であることが分かります。 SPIモード1：CPOL=0, CPHA=1のSPI信号 図１１　CPOL=0, CPHA=1時のMasterからSlaveへのデータ送信波形 図１１を見るとCLKはデータが転送される前(アイドル時)にLowとなっている(図中の橙枠)ので、POL=0であることが分かります。 今度は、1回目のCLKの立ち上がりエッジでMOSIのデータを変化(図中の緑線)させており、2回目のCLKの立ち下がりエッジでMOSIのデータをラッチ(図中の赤線)しているので、CPHA=1であることが分かります。 SPIモード2：CPOL=1, CPHA=0のSPI信号 図１２　CPOL=1, CPHA=0時のMasterからSlaveへのデータ送信波形 図１２を見るとCLKはデータが転送される前(アイドル時)にHighとなっている(図中の橙枠)ので、POL=1であることが分かります。 また1回目のCLKの立ち下がりエッジでMOSIのデータをラッチ(図中の赤線)させており、2回目のCLKの立ち上がりエッジでMOSIのデータを変化(図中の緑線)しているので、CPHA=0であることが分かります。 ※クロックの極性が変わっているので、1回目と2回目のクロックが混同しないように。 SPIモード3：CPOL=1, CPHA=1のSPI信号  図１３　CPOL=1, CPHA=1時のMasterからSlaveへのデータ送信波形 図１３を見るとCLKはデータが転送される前(アイドル時)にHighとなっている(図中の橙枠)ので、POL=1であることが分かります。 また1回目のCLKの立ち下がりエッジでMOSIのデータを変化(図中の緑線)させており、2回目のCLKの立ち上がりエッジでMOSIのデータをラッチ(図中の赤線)しているので、CPHA=1であることが分かります。 あらためて今回の測定結果をまとめると以下(表３)のようになりました。 表３　４つのモードとCPOL、CPHAの関係まとめ SPIモード CPOL CPHA アイドル時のCLK 1回目のCLK 2回目のCLK mode=0 0 0 Low 立ち上がりエッジでデータをラッチ 立ち下がりエッジでデータを変化 mode=1 0 1 Low 立ち上がりエッジでデータを変化 立ち下がりエッジでデータをラッチ mode=2 1 0 High 立ち下がりエッジでデータをラッチ 立ち上がりエッジでデータをラッチ mode=3 1 1 High 立ち下がりエッジでデータを変化 立ち上がりエッジでデータをラッチ ６．おわりに 実際にSPIモードを4通り、CPOLとCPHAを変えながら信号の測定をしてみました。自分で測定しながら、極性と位相が変わると混乱しましたが、期待通りの動作を確認できました。基礎を学ぶ際には、プログラムを変えてビルドして動いたことを確認するだけでなく、実際に信号を見てみると理解が進むかもしれません。是非、みなさんも試してみてください。 参考情報 (前編) NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) NXPのインターフェース製品 ～まとめページ～ (日本語ブログ) SPIバスの概要 (日本語ブログ) NXP システム・マネジメントI²C, I3C, SPIセレクタ・ガイド =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 前回は、SPI通信の 前編としてFRDMボード2台用いて、SPI通信のサンプルアプリケーションを動かしてみました。 NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) 今回は、４つのSPIモードの設定を変えながら、実際に送受信されるSPI信号を確認してみようと思います。本稿では、以下の[前編]記事の作業が完了していることを前提に進めます。 [前編] SPI通信のサンプルアプリケーションを動かしてみる。 [後編] SPIのモードを変えながら、実際のSPI信号を観測して、変化を見てみる。 (作業時間：20分) ※前編の内容（MCUXpresso for VSC, SDKがインストールされていて、SPIのアプリケーション動作確認）が済んでいる前提。 Interface MCUXpresso MCUXpresso SDK MCX 日本語ブログ

智能设备网关 智能设备网关 在这篇文章中，我想简要介绍 智能设备网关 ，这是一款基于Fastapi的演示服务器，允许联网设备使用由Ara240 DNPU加速的本地GenAI功能。 该演示背后的想法是将人工智能集中在一个网关中，而不是向每台设备添加强大的人工智能硬件。连接的设备只需要麦克风、扬声器和网络连接即可成为支持语音的助手。   它的作用 智能设备网关使设备或嵌入式客户端等设备能够将音频发送到本地服务器，使用语音识别、RAG、在 Ara240 DNPU 上运行的 LLM 和文本转语音处理请求，然后将语音响应流回客户端。 当前的演示展示了通用烤箱和咖啡机/咖啡师用例的智能设备助手，使用设备手册作为上下文响应的知识库。   建筑概览 智能设备网关通过 WebSocket 接收来自客户端的音频，将语音转换为文本，从设备知识库检索相关上下文，通过 eIQ AAF 连接器将提示发送到 LLM，将生成的响应转换回语音，并将音频响应流式传输到客户端。 高层次的流程是 Audio Input → STT → RAG → eIQ AAF Connector / LLM → TTS → Audio Output LLM 在 Ara240 DNPU 上运行，而服务器则在 FRDM i.MX 平台上运行。   基本服务器安装 在板上安装 Debian 软件包： dpkg -i smart-device-gateway_1.0.0_all.deb 启动服务器： run_server_only --host 0.0.0.0 --port 8080 服务器预计eIQ AAF 连接器已在 0.0.0.0:8000 上运行，并已安装 Qwen2.5-7B-Instruct正确配置。 或者，演示程序可以与连接器一起启动服务器： run_server --host 0.0.0.0 --port 8080   主机 PC 客户端示例 该演示包括一个可在主机上运行的 push_to_talk 客户端。复制 push_to_talk 文件夹后，运行： python -m uv run push_to_talk.py --server_ip --port --device oven 您还可以使用 python -m uv run push_to_talk.py --server_ip --port --device barista 如果未提供设备名称，则不使用 RAG 知识库，响应由 LLM 的常识生成。   演示视频 在随附的视频中，我展示了如何启动智能设备网关服务器、连接客户端、选择烤箱或咖啡师等设备配置文件、提出语音问题以及接收使用Ara240 DNPU加速在本地生成的语音响应。 (function() { var wrapper = document.getElementById('lia-vid-6396695931112w960h540r659'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (在我的视频中查看）   摘要 智能设备网关演示了日常设备如何通过连接到本地 AI 网关成为支持语音的助手。该演示将Ara240 DNPU上的STT、RAG、LLM推断与TTS相结合，为在恩智浦i.MX平台上构建以隐私为中心的本地GenAI体验提供了实用参考。   链接 智能设备网关存储库 ARA2-M2-16G-GT ARA240 实践培训

PN76xx - ULPCD チェックリスト ES_PN7642およびAN15028に記載されているように、ICは超低消費電力カード検出（ULPCD）中にまれに応答しない状態になることがあります。 ICがこの状態に入った疑いがある場合、NXPはそれを検証・確認するためのチェックリストを提供しています。添付ファイルにあるチェックリストを参照してください。 NFCコントローラ・ソリューション

FOCベースのモータ制御システムにおける機能安全 オートモーティブやインダストリアルシステム向けのモータ制御を開発する際、機能安全は、モーターが意図しないトルクや速度を発生させないことを保証するための重要な要件です。 しかし、フィールド指向制御（FOC）のような複雑なアルゴリズムを機能的に安全なコンポーネントとして実装すると、アーキテクチャが著しく複雑化し、開発工数が大幅に増加し、全体的なパフォーマンスが低下します。 この問題を解決するために、NXPはセーフティ分解アプローチを採用しています。これにより、アプリケーションは安全関連以外の部分（QM）と安全関連の部分（ASIL）に分割されます。この枠組みの中で、NXPはASCLIB (オートモーティブ セーフティ チェッカーライブラリ）を提供しています。セーフティ部分向けのすぐに使えるセーフティチェッカーを提供することで、QMモータ制御部分を再設計することなく、高いセーフティ基準への準拠を実現できます。 完璧な組み合わせ：AMMCLIB（QM）＋ASCLIB（ASIL） ほとんどのお客様は、コアとなるMC処理に、高度に最適化されたNXP AMMCLIB（オートモーティブ数学およびモータ制御ライブラリ）を利用しています。AMMCLIBは優れたパフォーマンスを発揮するものの、品質管理（QM）レベルのライブラリである。 ISO 26262などの安全規格に準拠するためには、チームはQMレベルのAMMCLIBを中心に独自の安全機構を構築する必要があり、多大な時間と労力がかかった。このプロセスを効率化するため、NXPは標準化された、すぐに実用化可能なソリューションとしてASCLIBを提供しています。包括的な事前検証済み安全チェックツールを提供することで、独自の安全ソフトウェア開発の必要性を大幅に削減し、設計から認証までのサイクルを加速します。 AMMCLIBとASCLIBの連携方法 この概念が実際にどのように適用されるかを説明するために、以下のブロック図は標準的なフィールド指向制御（FOC）システムの例を示しています。このシナリオでは、モーター制御ブロックは既存のQMレベルのAMMCLIBコード上で動作し、ASCLIB安全チェッカーが重要なポイントを監視して安全性を確保します。このアーキテクチャは、FOC PMSM向けのIEEE低複雑度セーフティコンセプトに基づいています。   このリファレンスアーキテクチャは、ASCLIBを統合する際に、既存のQMモータ制御アーキテクチャに変更を加える必要がないことを示しています。完全なデータ型互換性により、ASCLIBチェッカーはAMMCLIB信号に直接マッピングできるため、シームレスな相互接続が保証されます。 標準的なFOCは一般的な使用例ですが、ASCLIBはそれに限定されるものではありません。モジュール式で独立したブロックのおかげで、このライブラリは、センサーレスFOCやシングルシャント電流測定など、代替トポロジーや高度な技術をサポートしています。 ASCLIBの内部構造：階層型セーフティアーキテクチャ ASCLIBは、階層的にレイヤーとパッケージに整理された、高度に構造化された階層型ソフトウェアモデルを特徴としています。 サービス層（最上位層） 2つの独立したパッケージを通じて、高度な機能を安全アプリケーションに直接公開します。 高レベルチェッカー（HLC）：さまざまなモータ制御システム向けにカスタマイズされた、幅広いアプリケーションのセーフティチェッカー。 障害マネージャ（FMG）：エラーの同期、構成、およびアプリケーション通知を管理する高度な障害処理コンポーネント。 コア層（基礎層） サービス層で使用される低レベルの構成要素を提供します。これは2つの重要なパッケージで構成されています。 低レベルチェッカー（LLC）：基本的な数学的機能と認証機能を提供します。 フォールトデバウンス（FDB）：汎用的なフォールトデバウンスアルゴリズムを提供します。 開発者向けヒント：ライブラリ全体は完全にモジュール化され、分離されており、独立しています。アプリケーションに独自のチェッカーが必要な場合は、LLCおよびFDBパッケージ内の既存の低レベルブロックを使用して、独自のカスタムチェッカーを簡単に構築できます。さらに、障害マネジメント（FMG）パッケージは完全にオプションであり、使用を強制されることはなく、代わりに独自のアプリケーションレベルのエラー処理を実装することも可能です。   オートモーティブに限らない 名前に惑わされないでください。ASCLIBは名称に「オートモーティブ」という言葉を含み、 ISO 26262ワークフローをネイティブにサポートし、そのセーフティ原則は普遍的なものです。ASCLIBは、IEC 61508に準拠したインダストリアルシステムに最適です。 既存の開発ワークフローにシームレスに統合できるよう、ASCLIBは2種類の配信オプションを提供しています。 純粋なC言語ソースファイル：ベアメタルまたはRTOSベースの組み込みプロジェクトに直接統合できます。 BAM（ビット精度モデル）：モデルベース設計（MBD）用のすぐに使えるブロックで、セーフティアーキテクチャをMATLAB/Simulinkに直接ドラッグ＆ドロップしてシミュレーションできます。 開発者にとっての主なメリット AMMCLIBは引き続きQM用です。コアMCには、既存の高度に最適化されたAMMCLIBコードを引き続き使用してください。 モデルベース開発：専用のASCLIB BAMを使用してMATLAB/Simulink内でセーフティ部品全体を構築およびシミュレーションしてからターゲットCコードを生成することで、設計サイクルを加速します。 認証手続きの迅速化：事前に設計されたセーフティブロックと統合された障害マネジメント機能により、セーフティ基準への準拠と監査プロセスが大幅に簡素化されます。 さあ、始めて、あなたの考えを共有しましょう ASCLIBは完全にMCUに依存しないように設計されているため、さまざまなハードウェアプラットフォームに柔軟に展開できます。開発を加速させるため、本製品は既に完全な検証済みであり、NXPのオートモーティブおよびインダストリアルMCUとの統合に対応しています。制御と安全性を分離することで、最高のモーター性能と妥協のない安全性という、両方の利点を享受できます。 近々、ISO 26262またはIEC 61508規格に準拠したモーター制御プロジェクトに取り組んでいますか？AMMCLIB + ASCLIB アプローチが設計をどのように簡素化できるかについて、コメント欄で議論しましょう。または、以下のフォームからフィードバックをお寄せください。[フォームへのリンク] 機能的に安全なモーター制御システムを構築することは、性能を犠牲にしたり、アーキテクチャを再設計したりすることを意味するものではありません。NXPがAMMCLIBとASCLIBを組み合わせることで、セーフティと制御を分離し、開発労力を削減し、認証を迅速化する方法を、効率性を損なうことなくご紹介します。 モータ制御 導入

在 128 个总线时钟内配置 WDOG 说明 根据我对参考手册中以下内容的理解，我遇到了意外的 WDOG 行为： " 在 128 个总线时钟内 重置后，所有监视程序控制位、超时值和窗口值都只写入一次。这意味着，写入完成后，除非进行RESET ，否则无法对其进行更改。" 我对此的初步解释是，你必须在 RESET 后的前 128 个总线时钟内配置 WDOG，否则它将使用 UPDATE=0 的默认配置。这将防止您再次重新配置 WDOG。 然而，我却遇到了不同的情况。由于退出 RESET 的 KE1 以相同的频率运行总线和内核时钟，因此我决定在重新配置 WDOG 时查看 IAR 调试器中的 CYCLECOUNTER，因为我认为它能告诉我自 RESET 以来还经过了多少总线时钟。它显示自RESET释放以来已经过去了144个周期。于是，我开始在函数的起始位置添加越来越长的延迟循环，看看它是否还能让我在 144 个循环之后继续重新配置。 无论延迟时间有多长，只要低于 WDOG 默认的 8 毫秒超时时间，就能成功重新配置 WDOG。我在使用调试器和不使用调试器的情况下都观察到了这种行为，以确保调试器没有起到任何作用。我还能够通过使用Oscope闪烁RESET来确认计时。 因此，现在我对参考手册的理解是，RESET后，您可以重新配置 WDOG。而且，一旦您对 WDOG 执行了第一次写入，您将获得 128 个总线时钟来重新配置剩余的寄存器字段。 例如，假设我在重置时等待 1000 个总线时钟，然后配置 WDOG_CS 寄存器。在配置 WDOG_CS 来配置 WDOG_TOVAL 之后，我得到了 128 个总线时钟。TOVAL 配置完成后，新配置即生效。 这是对参考手册的正确解释吗？或者我之前的解释是否正确，你在 RESET 时获得 128 个总线时钟，或者默认配置生效？ Re: Configure WDOG within 128 Bus Clocks Clarification 你好@sean_dvorscak、 谢谢你的帖子。 请参阅"第 30.4.3.2.1 节 解锁看门狗" 和第30 .5.2 节 配置看门狗 在KE1xFP100M168SF0RM 中。 "30.5.2 在 KE1xFP100M168SF0RM 中配置看门狗" 。 正确的解释似乎如下： 重置后，WDOG 处于启用状态，并使用其重置默认设置运行。 WDOG 配置寄存器仍可用于初始配置序列。 监视程序解锁后，其余配置寄存器必须在 128 个总线时钟内写入。 如果 UPDATE=0，则在该初始配置完成后，在下次 RESET 之前，无法再次更改 WDOG 配置。 如果 UPDATE=1，则可以解锁并稍后重新配置 WDOG，每次解锁后将应用相同的 128 总线时钟窗口。 这种解释与您的测量结果一致：即使自RESET以来经过了超过 128 个总线时钟，WDOG 仍可以成功重新配置，前提是这种情况发生在默认监视程序超时到期之前。 换句话说，128 总线时钟配置窗口与解锁顺序相关，而不仅仅是自RESET释放以来经过的时间。 如果未完成任何新配置，WDOG 将继续使用其重置默认设置运行。 希望对您有所帮助。 BR 西莱斯特 ------------------------------------------------------------------------------------------------------------------------ 注：如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。Thank you! ------------------------------------------------------------------------------------------------------------------------ Re: Configure WDOG within 128 Bus Clocks Clarification 更新看门狗设置需要遵循一定的命令顺序。我不知道 128 个总线时钟来自哪里，但以 K80 子系列参考手册，2015 年 9 月 4 日修订版为例： 只要在监视程序控制寄存器中设置了 ALLOW_UPDATE，您就可以解锁和修改一次只写控制和配置寄存器： 1. 在 20 个总线时钟周期内将 0xC520 然后写入 0xD928 到特定的解锁寄存器 (WDOG_UNLOCK)。 2。等待一个总线时钟周期。在写入解锁序列之后，您无法在总线时钟周期内立即更新寄存器。 3.打开一个与看门狗配置时间（WCT）等长的更新窗口。在该窗口中，您可以更新配置和控制寄存器位。 这些寄存器位在解锁后只能修改一次。如果在更新窗口内没有更新任何配置和控制寄存器，监视程序会向系统发出RESET，即中断然后RESET。初始解锁后，尝试在 WCT 内解锁看门狗不会有任何效果。 Re: Configure WDOG within 128 Bus Clocks Clarification 谢谢你的澄清。 很高兴得知我有超过 128 个总线时钟脱离 RESET，无法配置 WDOG。 如果他们对 ke1xfp100m168sf0rm 进行了新的修订，我想建议在 128 个总线时钟内删除 "..."自第 30.4.3.1 节第一句。 感谢这个建议可能很愚蠢，但我之所以这样做，只是因为我在网上发现了一些错误信息，引用了这个措辞，暗示你只有 128 个总线时钟来配置 WDOG 而不 RESET。不幸的是，它还会让谷歌人工智能概述重复同样的错误信息（......不得不爱未来）。 🙂 ).因此，我不得不在这里亲自提问。 Re: Configure WDOG within 128 Bus Clocks Clarification 明白。不幸的是，据我所知，Kinetis系列没有新的路线图。我们最近推出了MCX系列，如果你感兴趣，可以考虑探索这个系列。MCX Arm Cortex-M 工业和物联网微控制器 | 恩智浦半导体

通过以太网在 S32Z280-594EVB 上闪烁应用程序 您好，NXP团队， 我正在使用 S32Z280-594EVB 评估板，想知道是否有可能通过以太网接口对应用程序二进制进行闪存/编程，而不是使用调试器 (J-Link /P & E)。 如果支持基于以太网的闪烁： 有哪些可用的方法来实现这一目标？ 是否有支持以太网编程的引导加载程序或固件更新机制？ 是否有任何示例项目、应用笔记或参考文档？ 主机需要哪些工具和软件？ 能否请您指导我通过以太网对 S32Z280 进行编程的推荐方法？ 感谢您的支持。 致以最崇高的敬意 Karthik Re: Flashing Application via Ethernet on S32Z280-594EVB 你好，@karthik_nikil 谢谢你的帖子。 通过查看最新的 GreenVIP，似乎未实现/支持通过以太网将映像编程到闪存，因此没有相关示例可供直接参考。 很抱歉给您带来不便。 BR 切宁

S32K3 bricked, unable to debug Hi, I've been trying to use AB_SWAP firmware for bootloading. I've not progressed the lifecycle or anything like that, and secure boot is not enabled. I am flashing one bank, and then performing an active bank switch using HSE. I was experiencing compounding reset reasons Bit 0 (0x0001): Power On Reset Bit 8 (0x0100): FXOSC Failure Bit 15 (0x8000): System Clock Divider Failure  After experimenting with switching the clock to FIRC before the bank switch reset call, I have not been able to access my MCU with JLink. I've tried connect under reset, running in a loop and power cycling etc. Is there any boot configuration via pins I can use to keep it in a known state, or factory reset tools to recover this? Type "connect" to establish a target connection, '?' for help J-Link>connect Please specify device / core. : S32K358_M7_0 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF>s Specify target interface speed [kHz]. : 4000 kHz Speed> Device "S32K358_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 27us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 10.0ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ConfigTargetSettings() start ConfigTargetSettings() end - Took 13us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 20.5ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ****** Error: DAP error while reading AIRCR. Error occurred: Could not connect to the target device. For troubleshooting steps visit: https://kb.segger.com/J-Link_Troubleshooting J-Link> Re: S32K3 bricked, unable to debug I got new information from my colleague. If you meet this problem again, try following commands: r0 erase Do not use 'connect' before that. After 'erase' command, it will ask you to establish the connection. And then it will erase the flash and while no code is executed.  If it does not work, you can try to use JTAG mode instead of SWD. It looks like this can also make a difference.  Regards, Lukas Re: S32K3 bricked, unable to debug After 6 hours of leaving the board with the oscilloscope connected, I noticed the reset pattern had stopped. I was able to connect and erase the board. I'll continue with my development cautiously. A theory is that the code I added to switch HSE partition included a clock switch, from FXOSC + PLL to FIRC to resolve some reset issues. I guess not gracefully closing the GMAC peripheral that was using the PLL, or not waiting for it to complete shutdown was causing instability that was then exacerbated during clock init entering some kind of reset cycle. Re: S32K3 bricked, unable to debug To clarify. A 50us reset pulse is being asserted every 30ms, with or without the JLink connected Re: S32K3 bricked, unable to debug Hi Lukas, I scoped it out. Reset seems to be flickering intermittently without any JLink operation. It holds high during the connect, and then resets as part of the normal connection procedure. I tried with the Reset pin strongly pulled high to avoid any issues there but still I get the exact same issue Re: S32K3 bricked, unable to debug Hi @Greavesinator85  No, there are not boot configuration pins on this device. I know that this could be a workaround on some other devices but that’s not the case of S32K3. It always boots from internal flash memory only. Could you check the reset signal? Isn’t the reset asserted all the time? I was playing with JLink on my board and I got exactly the same error message when I kept the reset asserted during ‘connect’ command execution. Regards, Lukas Re: S32K3 bricked, unable to debug It's a custom board, but I have been using it for a few months so its not a hardware issue. Then its a J-Trace connected with SWD. Re: S32K3 bricked, unable to debug Could not connect to the target device.? What kind of board you are using for programming?

RPI-CAM-MINISAS用ファームウェアファイル RPI-CAM-MINISASボードを動作させようとしています。ap1302ドライバは、ファームウェアファイルap1302_ar0144_single_fw.binを要求します。 このページhttps://docs.nxp.com/bundle/RM00293/page/topics/ar0144.html州 ap1302_ar0144_single_fw.binという名前のファームウェアが必要です。/lib/firmwareフォルダに配置してください。 しかし、そのファイルの入手先については何も記載されていない。 OnSemiのGitHubリポジトリ（ https://github.com/ONSemiconductor/ap1302_binaries/tree/main ）で探してみました。 そのリポジトリには、このファイル名と完全に一致するファイルは存在しません。私が見つけた中で最も近いのは、 https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin です。 しかし、このファームウェアファイルは動作しません。ドライバーはファイルを読み込んだようですが、その後dmesgに以下が表示されます。 [ 11.201244] ap1302 1-003c: __ap1302_read: レジスタ 0x0000 の読み取りに失敗しました: -6 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 @rudolf_streif さん。 先ほどご提供いただいたログに基づくと、I2C通信に問題があるようです。このログが出力される前に、ファームウェアは既にロードされていたのでしょうか？そうでない場合は、AP1302のリセットピンとイネーブルピン（R82 → RST、TP1 → イネーブル）のGPIOステータスを確認する必要があると思います。 よろしくお願いします、 志明 Re: Firmware File for RPI-CAM-MINISAS ファームウェアファイルの確認をしていただき、 @Zhiming_Liu さん、ありがとうございます。 私はRPI-CAM-MINISASアダプタとAP1302/AR0144モジュールを組み合わせて使用しています。アダプタのLEDとカメラモジュールの赤色LEDが点灯していることから、FPCケーブルは正しく接続されています。 現在、私はimx93 evkではなくimx8mp evkを使用しています。NXPはこの組み合わせを公式にはサポートしていないという情報をどこかで見つけました。I2Cが動作するように、デバイスツリーを作成しました。しかし、24MHzクロックが正しく動作していない可能性もあります。私の理解では、カメラモジュールはI2C通信のために内部クロックで動作し、ファームウェアのダウンロード後に外部クロックに切り替わるようです。 もしかしたら、あなたはもっと深い洞察をお持ちかもしれませんね。 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 このリンクは正しいファームウェアのリンクです。L6.18.2でテストしたところ、正常に動作しました。 root@imx93evk:~# dmesg | grep ap1302 [ 0.350765] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.391204] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 0.486760] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.518939] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.560106] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 0.572201] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.591913] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 2.783982] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 2.795274] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 9.648423] ap1302 2-003c: AP1302 revision 0.2.6 detected ハードウェアの接続を確認してください。 よろしくお願いします、 志明 Re: Firmware File for RPI-CAM-MINISAS これは、以下のNXPレイヤーを使用したカスタムYocto Projectビルドです。 meta-freescale = "master:4cc4bc05063f7f4c105587332493742379d11ad7" meta-freescale-3rdparty = "master:29c36ae80ba5762091f48d6d15b637455cc15758" meta-freescale-distro = "master:70b7591ecaa99cb6366f93ee05df7c38d94d724b" 基本的にはYPウィンラッター/ライノーズと同じだ。 ファームウェアはfirmware-imxの一部だと思っていたのですが（バージョンは8.28）、そうではありませんでした。 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 @rudolf_streif さん。 使用しているBSPのバージョンを教えていただけますか？ よろしくお願いします、 志明

UJA1169 驱动程序代码 各位你好， 我需要可以通过 SPI 总线配置的 UJA1169ATK SBC 的示例驱动程序代码。 在产品页面上，有 AUTOSAR 驱动程序可用，但我们正在使用 NON_AUTOSAR 方法进行开发。 请分享这方面的示例项目。 谨致问候， Mohit Re: UJA1169 driver code 点击申请额外访问权限，然后上传 NDA 等待批准。 Re: UJA1169 driver code 你好， ，我有 NDA 权利，但没有显示。它要求添加权限，但按钮不起作用。 我试了好几次，都没有成功。 帮助我们更快地解决问题。 BR, Mohit Re: UJA1169 driver code 嗨 UJA1169ATK 迷你高速 CAN SBC |恩智浦半导体 您可以从上述链接下载。 谢谢！ BR

使用 SE050 时如何启用平台 SCP 大家好 我使用的是 SE050E，在使用 Platform SCP 时遇到了麻烦。我按照 AN12542(https://www.nxp.jp/docs/en/application-note/AN12542.pdf#4#4) 中的说明定义了 SSS_HAVE_SE05X_AUTH_PLATFSCP03 1，但当我调用 ex_sss_boot_open 函数打开会话时，结果却是 kStatus_SSS_Fail。我做错什么了吗？使用普通通信时，一切正常。如果还需要其他配置，请告诉我。 谢谢！ SE050 Re: How to enable Platform SCP when using SE050 你好@Kan_Li、 我按照第 6.2 和 6.3 节中的说明，尝试运行 SE-PLUG-TRUST-MW_04.07.01 中的 se05x_MandatePlatformSCP 示例，但 sss_key_object_init(eraseAuthCtx.auth.ctx.idobj.pObj、&pCtx->host_ks) 函数返回 kStatus_SSS_InvalidArgument。我需要调用 ex_sss_boot_open、ex_sss_key_store_and_object_init 和ex_sss_boot_open_host_session函数吗？调用sss_key_object_init函数之前先调用sss_key_object_init文件吗？代码如下： /* 关闭 clang-format */ #define MandateSCP_UserID_VALUE \ { \ n'、'e'、'e'、'd'、's'、'c'、'p    } /* clang-format ON */ sss_status_t se050_platformSCP03(void) { sss_status_t status = kStatus_SSS_Fail； sss_object_t keyObject； ex_sss_boot_ctx_t gex_sss_mandate_scp_boot_ctx； SE_Connect_Ctx_t eraseAuthCtx = { 0 }； sss_se05x_session_t *pSession = (sss_se05x_session_t *)&gex_sss_mandate_scp_boot_ctx.session； smStatus_t sw_status； Se05xSession_t *pSe05xSession； SE_Connect_Ctx_t* pOpenCtx； sss_object_t ex_id ={ 0 } ；   const uint8_t host_userid_value[] = MandateSCP_UserID_VALUE； const uint8_t userid_value_factoryreset[] = MandateSCP_UserID_VALUE； eraseAuthCtx.auth.ctx.idobj.pObj =&ex_id；   const char *portName = NULL；   memset(&gex_sss_mandate_scp_boot_ctx, 0, sizeof(gex_sss_mandate_scp_boot_ctx))；   //* 初始化会话以连接 SE050 */ // status = ex_sss_boot_open(&gex_sss_mandate_scp_boot_ctx, portName)； // 如果 (kStatus_SSS_Success != status) // { // ex_sss_session_close(&gex_sss_mandate_scp_boot_ctx)； // return status; /* return error if can't initialize session with SE050 */ // }   // ** 设置密钥存储 */ // status = ex_sss_key_store_and_object_init(&gex_sss_mandate_scp_boot_ctx)； // 如果 (kStatus_SSS_Success != status) // { // ex_sss_session_close(&gex_sss_mandate_scp_boot_ctx)； // return status; /* close sesion and return error if can't initialize fail */ // }   // ex_sss_boot_open_host_session(&gex_sss_mandate_scp_boot_ctx)； /* 准备主机 */ status = sss_key_object_init(eraseAuthCtx.auth.ctx.idobj.pObj.php)、&gex_sss_mandate_scp_boot_ctx.host_ks）； 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_object_init")； 去清理；    } status = sss_key_object_allocate_handle(eraseAuthCtx.auth.ctx.idobj.pObj.php)、 make_test_id(__LINE__)、 kSSS_KeyPart_Default、 kSSS_CipherType_UserID、 sizeof(host_userid_value)、 kKeyObject_Mode_Transient）； 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_object_allocate_handle")； 去清理；    } status = sss_key_store_set_key(&gex_sss_mandate_scp_boot_ctx.host_ks、 eraseAuthCtx.auth.ctx.idobj.pObj、 host_userid_value、 sizeof(host_userid_value)、 sizeof(host_userid_value) * 8、 NULL、 0); 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_store_set_key")； 去清理；    }   pSe05xSession =&pSession->s_ctx；   sw_status = Se05x_API_WriteUserID（pSe05xSession、 NULL、 SE05x_MaxAttemps_NA、 kSE05x_AppletResID_PLATFORM_SCP、 userid_value_factoryreset、 sizeof(userid_value_factoryreset)、 kSE05x_AttestationType_AUTH）；   pOpenCtx =&gex_sss_mandate_scp_boot_ctx.se05x_open_ctx； eraseAuthCtx.tunnelCtx = pOpenCtx->tunnelCtx； eraseAuthCtx.connType = pOpenCtx->connType； eraseAuthCtx.portName = pOpenCtx->portName； eraseAuthCtx.auth.authType = kSSS_AuthType_ID；     sss_session_close(&gex_sss_mandate_scp_boot_ctx.session)；   pSe05xSession =&pSession->s_ctx；   status = sss_session_open(&gex_sss_mandate_scp_boot_ctx.session、kType_SSS_SE_SE05x、 kSE05x_AppletResID_PLATFORM_SCP、 kSSS_ConnectionType_Password,&eraseAuthCtx)；     如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_session_open")； 去清理；    }     /* 调用 SE05X API 授权平台 SCP。*/   sw_status = Se05x_API_SetPlatformSCPRequest(&pSession->s_ctx, kSE05x_PlatformSCPRequest_REQUIRED)； if(SM_OK != sw_status) { LOG_E("Se05x_API_SetPlatformSCPRequest 失败")； 去清理；    } 否则 { LOG_I("Se05x_API_SetPlatformSCPRequest Successful")； LOG_W("进一步通信必须加密")；    }   清理： 如果 (kStatus_SSS_Success == status) { LOG_I("se05x_MandatePlatformSCP Example Success !!!...")；    } 否则 { LOG_E("se05x_MandatePlatformSCP Example Failed !!!...")；    } 返回状态； }   谢谢！ Duong Re: How to enable Platform SCP when using SE050 你好@yang_lee、 第 6 章中提供的示例仅适用于 SE050E，但首先请确定您使用的是哪个编译系统。 1.如果使用 MCUXpresso SDK，请按照 6.2 和 6.3 中的步骤操作 2.如果使用 Cmake，请按照 6.4 和 6.5 中的步骤操作 希望对你有所帮助、 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------