iMX91-FRDM BLE接続の問題 こんにちは、 私は iMX91-FRDM ボード上の BLE コネクティビティに取り組んでいます。BLE チップは ( IW610 ) です。私の目標は、Gatt-Client を実装することです。 初期段階では特定の BLE デバイスに接続しようとしています。以下はその C コードです。 #define OCF_LE_EXT_CREATE_CONN 0x0043 int hci_connect( uint8_t *pMacAddr ) { le_ext_create_conn_cp cp; int ret; memset( (& cp), (0x00), sizeof(cp) ); cp.filter_policy = (0x00); //// do not filter cp.own_addr_type = (0x00); //// THIS device has a Random MAC address cp.peer_addr_type = (0x01); //// peer has a Random MAC cp.peer_addr.b[0] = (pMacAddr[0]); cp.peer_addr.b[1] = (pMacAddr[1]); cp.peer_addr.b[2] = (pMacAddr[2]); cp.peer_addr.b[3] = (pMacAddr[3]); cp.peer_addr.b[4] = (pMacAddr[4]); cp.peer_addr.b[5] = (pMacAddr[5]); cp.initiating_phys = (0x01); //// 01-->1M PHY cp.scan_interval = (0x0060); //// time between scans (x 0.625) => 60mS cp.scan_window = (0x0060); //// scan duration (x 0.625) => 60mS cp.conn_interval_min = (0x0050); //// connection interval MIN => 50mS cp.conn_interval_max = (0x00A0); //// connectino interval MAX => 100mS cp.conn_latency = (0x0000); //// connecion latency => 0mS cp.supervision_timeout = (0x03E8); //(0x0190); //// supervision timeout => 250mS cp.min_ce_length = (0x0000); //// 0 cp.max_ce_length = (0x0000); //// 0 ret = send_hci_command( m_hci_device, OGF_LE_CTL, OCF_LE_EXT_CREATE_CONN, (uint8_t *)(& cp), sizeof(cp) ); if ((0x00) != ret) { printf("-------- !!!! hci_connect() ---- %02x-%04x ", OGF_LE_CTL, OCF_LE_EXT_CREATE_CONN); printf(" ---- FAIL(0x%02x)\r\n", ret); return (0); } printf("@@@@@@@@ hci_connect() ---- %02x-%04x ", OGF_LE_CTL, OCF_LE_EXT_CREATE_CONN); printf(" ---- OK(0x%02x)\r\n", ret); return (1); } ........ bdaddr_t bdaddr; uint16_t handle; str2ba("CC:CD:C5:BA:7B:71", &bdaddr); int status = hci_le_add_white_list(m_hci_device, &bdaddr, 0, 1000); // 0 = public, 1 = random if (status == 0x00) printf("Device added to white list\n"); else printf("Failed, status: 0x%02x\n", status); scanEnabParm.enable = (0x00); //// enable == true printf("Set Scan-DISABLE Parameters.\n"); if (! send_hci_command( m_hci_device, 0x08, 0x0042, (uint8_t *)(& scanEnabParm), sizeof(scanEnabParm) )) { printf("\nSet Scan-Disable Parameters command failed.\n"); } sleep(2); if (! hci_connect(m_con_addr)) { printf("*Error- hci_connect() - FAILED \n"); return (0); } ただし、接続は完全には成功していません。以下はその hcidump です。 コードを実行すると、以下の応答が返されます。 HCI送信失敗: 入出力エラー 以下のコマンドは検出されません: HCIコマンド: 不明 (0x08|0x0043) plen 26   0000: 00 01 01 71 7b ba c5 cd  cc 01 60 00 60 00 50 00  ...q{.....`.`.P.   0010: a0 00 00 00 e8 03 00 00  00 00                    ………… > HCIイベント情報: コマンドステータス (0x0f) plen 4     不明 (0x08|0x0043) ステータス 0x00 ncmd 1 < HCIコマンド: LEデバイスを承認リストに追加 (0x08|0x0011) plen 7   0000: 00 71 7b ba c5 cd cc                              .q{.... > HCIイベント情報: コマンド完了 (0x0e) plen 4     LE デバイスを承認リストに追加 (0x08|0x0011) ncmd 1     ステータス 0x00 < HCIコマンド: 不明 (0x08|0x0042) plen 6   0000: 00 01 00 00 00 00                                …… > HCIイベント情報: コマンド完了 (0x0e) plen 4     不明 (0x08|0x0042) ncmd 1     0000: 00                                                。 < HCIコマンド: 不明 (0x08|0x0043) plen 26   0000: 00 01 01 71 7b ba c5 cd  cc 01 60 00 60 00 50 00  ...q{.....`.`.P.   0010: a0 00 00 00 e8 03 00 00  00 00                    ………… > HCIイベント情報: コマンドステータス (0x0f) plen 4     不明 (0x08|0x0043) ステータス 0x00 ncmd 1 > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 31     接続リクエスト     0000: 00 80 00 00 01 71 7b バ  c5 cd cc 00 00 00 00 00  .....q{.........     0010: 00 00 00 00 00 00 00 9c  00 00 00 e8 03 01        .............. < HCI コマンド: LE リモート使用機能の読み取り (0x08|0x0016) plen 2   0000: 80 00                                            .. > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 4     コマンド完了     0000: 80 00 01                                          ... > HCIイベント情報: コマンドステータス (0x0f) plen 4     LE リモート使用機能読み取り (0x08|0x0016) ステータス 0x00 ncmd 1 > ACLデータ: ハンドル128フラグ0x02 dlen 7     ATT: MTU要求 (0x02)       クライアント RX MTU 245 > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 11     お問い合わせ完了     0000: 80 00 f9 00 48 08 f9 00  48 08                    ……はぁ……はぁ。 > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 12     LE リモート読み取り使用機能完了       ステータス 0x00 ハンドル 128       機能: 0x25 0x41 0x00 0x00 0x00 0x00 0x00 0x00 < ACLデータ: ハンドル128フラグ0x00 dlen 7     ATT: MTU要求 (0x02)       クライアント rx mtu 517 < ACLデータ: ハンドル128フラグ0x00 dlen 7     ATT: MTU応答 (0x03)       サーバー rx mtu 517 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128フラグ0x02 dlen 7     ATT: MTU応答 (0x03)       サーバー RX MTU 245 < ACLデータ: ハンドル128 フラグ 0x00 dlen 11     ATT: タイプによる読み取り要求 (0x08)       開始 0x0001、終了 0xffff       タイプUUID 0x2b3a > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128フラグ0x02 dlen9     ATT: エラー (0x01)       エラー: 属性が見つかりません (10)       ハンドル 0x0001 のタイプ要求 (0x08) による読み取り < ACLデータ: ハンドル128 フラグ 0x00 dlen 11     ATT: グループによる読み取り要求 (0x10)       開始 0x0001、終了 0xffff       タイプUUID 0x2800 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128フラグ0x02 dlen 24     ATT: グループ応答による読み取り (0x11)       属性ハンドル 0x0001、終了グループハンドル 0x0009       値 0x00 0x18       属性ハンドル 0x000a、終了グループハンドル 0x000d       値 0x01 0x18       属性ハンドル 0x000e、終了グループハンドル 0x001a       値 0x0a 0x18 < ACLデータ: ハンドル128 フラグ 0x00 dlen 11     ATT: グループによる読み取り要求 (0x10)       開始 0x001b、終了 0xffff       タイプUUID 0x2800 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128 フラグ 0x02 dlen 86     ATT: グループ応答による読み取り (0x11)       属性ハンドル 0x001b、終了グループハンドル 0x002f       値 0x66 0x9a 0x0c 0x20 0x00 0x08 0x12 0xab 0xea 0x11 0x78 0x6f 0x40 0x1b 0xc9 0xed       属性ハンドル 0x0030、終了グループハンドル 0x003e       値 0x66 0x9a 0x0c 0x20 0x00 0x08 0xf4 0xbd 0xe6 0x11 0x42 0x5b 0x90 0x82 0xea 0x18       属性ハンドル 0x003f、終了グループハンドル 0x0053       値 0x66 0x9a 0x0c 0x20 0x00 0x08 0xf4 0xbd 0xe6 0x11 0xcc 0x8b 0x50 0x10 0x58 0x4b       属性ハンドル 0x0054、終了グループハンドル 0xffff       値 0x9e 0xca 0xdc 0x24 0x0e 0xe5 0xa9 0xe0 0x93 0xf3 0xa3 0xb5 0x01 0x00 0x40 0x6e < ACLデータ: ハンドル128フラグ0x00 dlen 9     ATT: 書き込み要求 (0x12)       0x000dの値を処理する  0x02 0x00 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128フラグ0x02 dlen5     ATT: 書き込み応答 (0x13) < ACLデータ: ハンドル128フラグ0x00 dlen 7     ATT: 読み取り要求 (0x0a)       ハンドル 0x0003 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 11     お問い合わせ完了     0000: 80 00 f9 00 48 08 f9 00  48 08                    ……はぁ……はぁ。 > HCI イベント情報: LE メタ イベント情報 (0x3e) プレン 6     認証完了     0000: 00 80 00 02 02                                    ..... > ACLデータ: ハンドル128フラグ0x02 dlen16     ATT: 読み取り応答 (0x0b)       0000: 53 42 44 2d 44 43 20 54  4f 4f 4c                SBD-DCツール < ACLデータ: ハンドル128フラグ0x00 dlen 7     ATT: 読み取り要求 (0x0a)       ハンドル 0x0005 > HCIイベント情報: 完了したパケットの数 (0x13) plen 5     128パケットを処理する1 > ACLデータ: ハンドル128フラグ0x02 dlen 7     ATT: 読み取り応答 (0x0b)       0000: c0 03                                            .. > HCIイベント情報: 切断完了 (0x05) plen 4     ステータス 0x00 ハンドル 128 理由 0x13     理由: リモートユーザーが接続を終了しました Re: iMX91-FRDM BLE connection issue こんにちは、 ご確認いただきありがとうございます。 - BluetoothCTを使用したテストのターミナル出力全体を共有してください - btmon -w file.pcapを使用してテストした HCI ログ ファイルを共有してください。 - 接続しようとしている BT デバイスの詳細を教えてください。IW610 がセントラルとして動作していると理解しています。ペリフェラルの GATT プロファイルを共有してください。 よろしくお願いいたします。 ダニエル。 Re: iMX91-FRDM BLE connection issue こんにちは、 私の返信は以下をご覧ください。 1. root@imx91frdm:~# cat /etc/os-release ID=fsl-imx-xwayland NAME="NXP i.MX リリース ディストリビューション" VERSION="6.6-スカースギャップ (スカースギャップ)" バージョンID=6.6-スカースギャップ VERSION_CODENAME="スカースギャップ" PRETTY_NAME="NXP i.MX リリース ディストリビューション 6.6-scarthgap (scarthgap)" CPE_NAME="cpe:/o:openembedded:fsl-imx-xwayland:6.6-scarthgap" ルート@imx91frdm:~#    uname -a Linux imx91frdm 6.6.36-lts-next-ge3c30730af75 #1 SMP PREEMPT 水曜日 9月  4 08:22:45 UTC 2024 aarch64 GNU/Linux 2. root@imx91frdm:~# bluetoothctl hci0 new_settings: 電源付きボンディング可能 le secure-conn cis-セントラル cis-ペリフェラル  エージェント登録済み [CHG] コントローラ B8:F4:4F:E0:53:A4 ペアリング可能: はい [Bluetooth] # バージョン バージョン5.72 [ブルートゥース] ＃ 3. bluetoothctl から接続を試みましたが、正常に接続されません。ACL ログは hcidump -X で表示されます。BLE デバイスからの応答が表示されます。また、モバイル上の nRF Connect アプリを使用して BLE デバイスを正常に接続できました。 Re: iMX91-FRDM BLE connection issue こんにちは、 以下の情報についてご協力をお願いします。 1. 使用している OS のバージョンは何ですか? 2. 使用しているワイヤレス ドライバのバージョンは何ですか? 3. 問題を再現するために、bluetoothctl などの BlueZ ツールを既に試しましたか? よろしくお願いいたします。 ダニエル。

将新相机移植到 imx7d 时出现的 Android 框架问题 您好， 我正在将新相机移植到 imx7D 板上。它输出 640x480 YUYV 图像，而我的屏幕是 320x240 RGB565。我注意到 libcamera3 中有一些用于 OV5640 的配置文件，我试着参考这些文件编写自己的 cpp 文件。但看起来，安卓框架在颜色转换方面存在一些错误。我的屏幕显示大量绿色像素。 您能给我一些建议吗？ #linux #Android Linux Re: Android framework issue while porting new camera to imx7d 问题解决了。以前的相机不能输出 YUYV 格式，只能提供 RAW8/RAW10 格式（但数据表上说有 YUYV 格式......）。我又买了一批新相机，它们都能正确显示视频。 Re: Android framework issue while porting new camera to imx7d 你好， ，我之前尝试过两种 YUYV，但都不行 --> 最初的 hal 驱动程序也支持它，但它可以在捕获和渲染时运行。请确保 HAL 格式的输入和输出没有问题。然后检查 android 框架配置和您的应用程序，确保应用层可以正确转换和显示它。 致敬， Zhiming Re: Android framework issue while porting new camera to imx7d 嗨，志明、 我之前试过两种 YUYV，但都不行。因此，我试图在这里使用不同的 availFormats。 顺祝商祺！ PatrickZ     Re: Android framework issue while porting new camera to imx7d 你好， 你想在 HAL 层中将相机格式转换为 RGB 吗？为什么要在 HAL 代码中注释 YUYV。我认为你不需要在 HAL 层中将其转换为 RGB。 Zhiming_Liu_0-1739930697854.png 致敬， Zhiming

TEF82XX ATBの問題 こんにちは。ADC をバイパスし、RX をアナログ ポートに直接テストしてみたいと思います。スペクトル アナライザーを使用して内部のアナログ信号を表示します。関連するレジスターはどこにありますか?ADC と ATB のクロックと電源制御関連のレジスタしか確認しなかったためです。予約済みの ATB ポートがありませんか?または、RC 受信データはデフォルトで ADC および ATB ポートに送信され、切り替える必要はありませんか? レジスタ R2M0A_LO_INTERFACE_CONTROL_U16:0x000 で、バッファ B3、B2、および B1 の有効設定を確認しました。しかし、回路図で対応するポジショニングを見つけることができませんでした。場所を特定するのを手伝ってもらえますか?それとも、TEF82xx にはこれらのバッファがないのでしょうか? Re: TEF82XX ATB Issue こんにちは、 私は TEF82xx FAE と話していましたが、ATB は社内用であり、お客様とは話し合われません。 さらに質問がある場合は、少なくともNDAが必要となるため、NXP FAE / Salesに問い合わせることをお勧めします。 よろしくお願いいたします。 ピーター 回复： TEF82XX ATB Issue バッファ B1 ～ B4 はデータシートに記載されています。ありがとう。

S32K144コントローラのUART通信の問題について こんにちは 、 現在、プロジェクトに S32K144 コントローラを使用していますが、UART 受信に問題が発生しています。ブレークポイントがない場合、ソフトウェアは正常に実行され、UART はすべてのデータを適切に受信します。しかし、ブレークポイントが適用されると、UART 受信は行われなくなります。その間割り込みも発生しません。 使用コントローラ：S32K144 SDKスタック: LPUART2 この原因は何ですか、またこれを解決するにはどうすればよいですか? コールバック関数は以下のとおりです。 uint8_t 受信バイト = 0U; void vidRxUARTCallback(void *driverState, uart_event_t event, void *userData) { /* イベント情報タイプを確認する */ if (イベント情報 == UART_EVENT_RX_FULL) { LPUART_DRV_SetRxBuffer(INST_LPUART1, &rxbyte, 1U); } } Re: Regarding the UART communication issue in S32K144 controller こんにちは@Avinash_PAZHAMALAI 、 DATA レジスタからの RX データにはデバッガーからもアクセスでき、デバッガーは読み取り時に対応するフラグを自動的にクリアします。意図しないフラグのクリアを防ぐには、DATA レジスタにアクセスするすべてのレジスタまたはメモリ ビューが閉じられていることを確認します。 BR、ダニエル

eTPU crank, cam, injections and Ignitions on S32K3 Hello, I need to implement drivers to actuate Injections and ignitions phased with crank and cam signals. I need to understand which is the best solution to implement this drivers. My doubt are: 1) The API provided by AN4907SW.zip are compatible with eTPU present in S32K3xx? 2)If no, it's a good solution adapt this API for S32K3xx or the best solution it's use ConfigTool ? There is an example for S32K3xx about this application? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico  Converting data from big-endian to little-endian involves reversing the byte order by adjusting bit shifts and masks according to the data type size. GCC provides built-in functions to simplify this process, for example: uint32_t __builtin_bswap32 (uint32_t x). You can find more details in the GCC documentation: 7.2.3 Byte-Swapping Builtins Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @VaneB , if I understood well , the Automotive functions (CRANK, SPARK...), are made for big endian microcontrollers. To use eTPU with Automotive functions on S32K364 (little endian), I need to download a function set selecting : francescovico_0-1761136257258.png And change the functions: uint32_t *fs_memcpy32(uint32_t *dest,uint32_t *source,uint32_t size); void fs_memset32(uint32_t *start,uint32_t value,int32_t size); to swap each 32 bit values to read/write little endian code and parameters, it's true? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico  The S32K39/37/36 Microcontrollers for Electrification Applications, includes eTPU. However, there is currently no dedicated documentation or demo similar to the MPC5634's AN4907 available for these devices. That said, the AN4907 document, demo, and microcode are suitable for the S32K39/37/36 family, but please note that these devices use a little-endian architecture. Therefore, you will need to modify the memory access API. You can refer to the motor control-related modules in the CodeWarrior eTPU Function Selector, which has been updated to little-endian. BR, VaneB Re: eTPU crank, cam, injections and Ignitions on S32K3 Thanks for pointing this out! There was an endianity conversion issue. As a result, the missing tooth mask was not configured correctly and it counted 350 deg per rev resp 700 deg per cycle. Now, the demo app in the original post is fixed. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , Now I'm trying to use Fuel Cyl 1 etpu driver. It seem that  the driver use s24AngleNormalEnd as "start angle" and stop all injections at s24AngleStop. The duration u24InjectionTime it's never respected. It's possible? Attached there is a .rar file that contain  picoscope acquisition of "fuel cyl 1" where the injector parameter are: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd = DEG2TCR2(-180), .s24AngleStop = DEG2TCR2(-360), .s24AngleOffsetRecalc = DEG2TCR2(-30), .u24InjectionTime = USEC2TCR1(1200), .u24CompensationTime = USEC2TCR1(0), .u24InjectionTimeMinimum = USEC2TCR1(0), .u24OffTimeMinimum = USEC2TCR1(0), .eGenerationDisable = ETPU_FUEL_GENERATION_ALLOWED }; In the picoscope acquisition it's visible start of injection exactly at 180° , stop of injection at 360° and injection duration of 30 ms (it should be 1,2ms). Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl  , Now I'm trying to use Fuel Cyl 1 etpu driver. It seem that  the driver use s24AngleNormalEnd as "start angle" and stop injection ever at s24AngleStop. The duration u24InjectionTime it's never respected. It's possible? Attached there is a .rar file that contain  picoscope acquisition of "fuel cyl 1" where the injector parameter are: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd = DEG2TCR2(-180), .s24AngleStop = DEG2TCR2(-360), .s24AngleOffsetRecalc = DEG2TCR2(-30), .u24InjectionTime = USEC2TCR1(1200), .u24CompensationTime = USEC2TCR1(0), .u24InjectionTimeMinimum = USEC2TCR1(0), .u24OffTimeMinimum = USEC2TCR1(0), .eGenerationDisable = ETPU_FUEL_GENERATION_ALLOWED }; In the picoscope acquisition it's visible start of injection exactly at 180° , stop of injection at 360° and injection duration of 30 ms (it should be 1,2ms). Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , You are right, the s24AngleOffsetRecalc must be a positive number, but putting: s24AngleOffsetRecalc = DEG2TCR2(30) The result it's the same (. I'm using S32K364 that have 2 ETPU (A and B) with 16 channels. Using fuel driver on ETPUA the driver work correctly, but I need to use ETPUB channel 0. My necessity it's to share TCR1 and TCR2 from ETPUA to ETPUB, using STAC registers. It's possible that STAC registers are not correctly initialized? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico, this is how to configure STAC_ENG1 and STAC_ENG2 registers to share TCR1 and TCR2 from eTPU1 to eTPU2: MilanBrejl_0-1770199430269.png Let me know if it helps.  Regards, Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , my registers are exactly the same of your suggestion: ETPU_A_B_REGISTER.png But the problem it's still present. In the attached picoscope acquisition you can see the spark generated with ETPU A in BLU and spark generated with ETPU B in RED. Both sparks have end angle 180 degree and dwell time 8000 us. Regards, Francesco.   Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico, I duplicated your issue on my site and found the root cause. It is not enough to share TCR1/TCR2 time/angle buses between both eTPU engines. Spark and Fuel functions do time to angle transformation, based on the actual engine speed. It uses TRR (Tick Rate Register). This register is part of the Angle Clock logic and it is maintained by Crank eTPU function, running on eTPU A. Hence, TRR has the correct value on eTPU A only. Then, time to angle transformation on eTPU B, using eTPU B TRR, returns a wrong result. This is pretty fundamental, I probably never met anybody running engine control over both eTPU engines and hence this has not been solved. And especially with the new S32K3 devices limited to 16+16 channels this becomes important. Thanks for bringing up this use-case and thanks for your patience. The attached demo application is based on the previous one (in this thread) and adds the following changes: Spark 2 channel is moved from eTPU engine A to eTPU engine B MilanBrejl_0-1770672522362.png Channel masks are updated accordingly MilanBrejl_1-1770672675064.png Channel links need to support usage of both engines (use macro ETPU_IP_CHANNEL_TO_LINK) MilanBrejl_2-1770672729220.png pin configuration is updated, interrupt configuration updated And now new features of Crank eTPU FW: eTPU FW image is updated. The Crank function can run on both engines and update the TRR value also for the other eTPU engine.  This new feature requires to set one new parameter to the Crank configuration MilanBrejl_4-1770673143063.png where MilanBrejl_3-1770673103441.png I hope this helps.  Regards, Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , Now It's working perfectly. Thank you very much for the support! Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hello, I'm also researching the K396 board and want to use ETPU for crankshaft, camshaft, and oil injectors. Could we discuss this further?

关联命令中的随机数据 -（使用 Murata NXP 88W8801 Typ2 2DS） 大家好 在分析了 HostCmd_CMD_802_11_ASSOCIATE 命令后，我得出结论，在作为一个站连接到接入点时，有一些字段没有设置，而是发送了随机数据。 这涉及到全局例程wlan_cmd_802_11 _associate()： 第一个位置位于 /* 设置监听间隔 */ passo->监听间隔= wlan_cpu_to_le16(pmpriv-)>listen_interval); /* 设置信标周期 */ 通过>信标周期= wlan_cpu_too_le16(pbss_desc-)>信标周期); 在这里，监听和信标周期被插入报文头，但还有一个名为 t_u8dtim_period; 的字段没有填写，因此有一个随机值（取决于缓冲区中原来使用的值） 第二个位置位于 pss_tlv = (MrvlIEtypes_SsParamSet_t *)(void *)pos; pss_tlv->header.type = wlan_cpu_too_le16(TLV_TYPE_CF); pss_tlv->header.len = sizeof(pss_tlv->cf_ibss.cf_param_set)； pos += sizeof(pss_tlv->header) + pss_tlv->header.len； 可以看出，插入了一个类型为 TLV_TYPE_CF 的条目，其固定长度为 6 字节，但是 6 字节未写入，因此具有随机值（取决于原始缓冲区内容）。 看起来，如果收到 CF_PARAM_SET ID，cf_param_set 的内容可以选择由扫描数据填充。如果没有收到，最好不要插入存档数据，但如果已经收到，将数据复制到这里可能是正确的。 欢迎提出意见。 Regards Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 嗨，Christine ，我同意这份报告--这正是我所理解（和看到的）的问题。 Regards Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 谢谢您的答复，好的，我明白了。 您能帮忙确认一下我们的理解是否与您一致吗？ ============ 关联命令中的未初始化字段 在 wlan_cmd_802_11_associate() 中构建 HostCmd_CMD_802_11_ASSOCIATE 命令时，命令结构中的某些字段从未被明确初始化。 从未明确初始化.这些字段包括 dtim_period（1 字节）位于 listen_interval 和 beacon_period 之后。 类型为 TLV_TYPE_CF 的 TLV 内的 6 字节 cf_param_set。 未初始化数据的影响 由于命令缓冲区可以重复使用，因此这些字段会保留 先前内存内容 中的 随机剩余值 。这可能导致： 向 AP 发送的 DTIM 周期不正确，可能会影响省电和组播传输。 TLV 中包含随机 CF 参数值，可能导致无法预测的接入点行为或协商失败。 您的验证 您可以通过在函数运行之前使用已知模式（0x55 和 0xAA）初始化缓冲区并在执行后观察未更改的字节来确认这一点。 屏幕截图显示这些字节仍然是初始模式，这证明它们从来不是由代码编写的。 您的期望 这些字段 不应保持未初始化状态.它们应该 使用扫描结果中的有效数据填充（例如，用于 DTIM 的 pbss_desc->dtim_period）。 如果没有有效数据，则明确清零。 对于 TLV_TYPE_CF，如果扫描期间未收到 CF 参数，则应跳过该 TLV 或将其填为 0。   根本原因 关联命令生成器没有完全初始化命令结构。 添加可选的字段时未对缺失的扫描数据进行适当处理。 =========== 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好 Christine 我用的是嵌入式艺术家板：https://www.embeddedartists.com/products/imx-rt1062-oem/ 为了使用它，我使用了 EVK-MIMXRT1060 的 SDK_2.14.0 以及 Embedded Artists 提供的补丁，以便在他们的硬件上运行。 WiFi 部分没有补丁，只是从 SDK 中获取。 因此，我相信我已经有了最新的 WiFi 库代码。 Regards Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 1.首先，请确认我们的理解是否与您一致。 2. 我想你提到过你在使用：SDK_2.14.0_EVK-MIMXRT1060，但你不太确定。因此，请先检查一下你手中的板是什么，或者给我拍张照片。这样我就可以帮你检查一下。还要让我知道你是否在板上做过任何硬件重做。这样我就能更好地了解你在使用哪个板。 3. 你可以从这里获得我们的最新版本： https://mcuxpresso.nxp.com/select 选择你正在使用的板。 友情提醒 我们有 MIMXRT1060-EVKB/MIMXRT1060-EVKC和 EVK-MIMXRT1060 请手里拿着板选择正确的棋子。   Christine_Li_0-1763174519987.png 如果你使用的是：EVK-MIMXRT1060，那么 SDK_2.14.0 是最新的 SDK 版本。 如果你使用的是 MIMXRT1060-EVKB 或 MIMXRT1060-EVKC ，最新的 SDK 版本是：SDK 25.09 作为我的屏幕截图 。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好 Christine 不幸的是，我不知道在哪里可以找到我正在使用的版本号，也不知道在哪里可以访问新版本，比如参考的 v25.09.00。 你知道它在哪里吗？ 此致 Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 请参阅下文，了解我们内部团队的反馈意见，并确认我们的理解。 关联命令中的未初始化字段 在 wlan_cmd_802_11_associate() 中构建 HostCmd_CMD_802_11_ASSOCIATE 命令时，命令结构中的某些字段从未被明确初始化。 从未明确初始化.这些字段包括 dtim_period（1 字节）位于 listen_interval 和 beacon_period 之后。 类型为 TLV_TYPE_CF 的 TLV 内的 6 字节 cf_param_set。 未初始化数据的影响 由于命令缓冲区可以重复使用，因此这些字段会保留 先前内存内容 中的 随机剩余值 。这可能导致： 向 AP 发送的 DTIM 周期不正确，可能会影响省电和组播传输。 TLV 中包含随机 CF 参数值，可能导致无法预测的接入点行为或协商失败。 您的验证 您可以通过在函数运行之前使用已知模式（0x55 和 0xAA）初始化缓冲区并在执行后观察未更改的字节来确认这一点。 屏幕截图显示这些字节仍然是初始模式，这证明它们从来不是由代码编写的。 您的期望 这些字段 不应保持未初始化状态.它们应该 使用扫描结果中的有效数据填充（例如，用于 DTIM 的 pbss_desc->dtim_period）。 如果没有有效数据，则明确清零。 对于 TLV_TYPE_CF，如果扫描期间未收到 CF 参数，则应跳过该 TLV 或将其填为 0。   根本原因 关联命令生成器没有完全初始化命令结构。 添加可选的字段时未对缺失的扫描数据进行适当处理。   为了帮助缩小问题范围，请帮助使用最新版本 (v25.09.00) 进行测试，并确认该版本中是否存在相同的行为。 致以最诚挚的问候 Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 从我个人的理解来看，我认为你是对的。 但我需要向我们内部的 SDK 专家团队报告，以进行仔细检查，而且我也没有直接修改 SDK 的权限。 一旦得到内部团队的反馈，我们将及时更新。 感谢您与我们分享这些信息，这确实有助于我们改进产品。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 嗨，Christine 以下是显示该问题的调试屏幕截图。 1.我在 wlan_cmd_802_11_associate()[此函数准备关联命令] 中的 cmd->command = wlan_cpu_to_le16(HostCmd_CMD_802_11_ASSOCIATE); ，当工作站连接到接入点时就会出现中断。 2. 我将缓冲区（cmd）设置为初始模式，这样就可以看到例程填写了哪些元素： mjbcswitzerland_0-1762801362068.png 3.我让函数完成（现在可以发送内容了），然后再次检查缓冲区的内容。 mjbcswitzerland_3-1762802420464.png 从缓冲区中可以看出，有 7 个字节没有更改（初始值仍为 0x55）。 (请注意，缓冲区开头的其他一些值也没有改变，但它们是最低一级驱动程序传输内容时填充的长度值） 4. 我现在重复一次，但将 0xAA 设置为初始缓冲区模式。 然后，我让缓冲区再次填满： mjbcswitzerland_2-1762801787074.png 这验证了 0x55/0xAA 不是真实值，并确认缓冲区没有完全写入。 第一个单字节是 dtim_period 的位置，通过在代码中添加 p asso-> dtim_period = pbss_desc-> dtim_period; 可以很容易地纠正这个位置。 接下来的 6 个缺失字节是 mrvlieTypes_ssparamset_T 的联合 cf_ibss 的内容应该所在的位置。我不知道它们是从哪里来的，所以没有尝试修改代码。 下面是一个真实连接尝试的示例，缓冲区从之前使用过的内容开始。 填写之前： mjbcswitzerland_4-1762802551148.png 填写后 mjbcswitzerland_5-1762802638051.png 因此，它 "随机 "拥有这些位置上缓冲区中的任何值，这些值可能有效，也可能无效，这取决于它们实际控制的内容和它们碰巧拥有的值。当然，代码的更改或缓冲区使用顺序的改变会导致原始缓冲区内容的不同，从而可能导致整体行为的改变。 我希望我能充分说明这个错误，以便在项目中加以纠正。 Regards Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 当然，请帮助发送截图，以便我们更好地理解您的意思。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 嗨，克里斯蒂娜 cmd 是一个输出缓冲区，原本是空的，在例程中被填满，因此 cmd 不会传递任何值。 下次使用调试器时，我会给你发送调试器屏幕截图来说明问题。 Regards Mark Regards Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 我下载了相同版本的 SDK，并检查了你提到的内容。 参数通过 IN HostCmd_DS_COMMAND *cmd 传递。 请参见下文： HostCmd_DS_802_11_ASSOCIATE *passo = &cmd->params.associate; 如果我的理解有误，请告诉我。 或者您可以提供调试器截图，以便我更好地理解您的疑虑。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，克里斯蒂娜 我正在使用 MCUXpresso SDK 中包含的恩智浦 WiFi 库开发 i.MX RT 1062。 MCUXpresso IDE v11.9.1 [内部版本 2170] [2024-04-19] 我不确定 SDK 的版本号，但该项目最初是在 26.8.2024 上安装的。但是我的 SDK 生成器仪表板显示了 SDK_2.14.0_EVK-MIMXRT1060 下面是显示其 mlan 文件和第一个代码问题的屏幕截图，其中 dtim_period 条目没有添加到它生成的命令中；我在命令缓冲区中的相关字节位置看到随机数据，这些数据是在使用调试器查看时创建的。 此致 马克 mjbcswitzerland_0-1761730101326.png Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 您是在 RTOS 还是 Linux 上使用 88W8801？ 如果使用 RTOS，能否告诉我您的主机平台名称？是我们的 I.MX RT 系列吗？您的 SDK 版本和 IDE 版本是什么？ 如果使用 Linux，能否告诉我您的主机平台名称？是我们的 I.MX 6、7、8、9 系列吗？你的 Linux 内核版本是什么？你的 Wi-Fi 驱动程序版本是什么？ 您有相关日志吗？ 或者您如何检测到这个问题？ 请帮忙介绍一下这个问题的更多背景，然后我们可以进一步讨论。 谢谢！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 我们检查了最新的 MCUXpresso SDK（v2.16.0）代码，并将其与您报告的问题进行了对比。我们的分析确认了以下字段 dtim_period 和 cf_param_set 字段未被初始化。   作为可能的修复方法，我们已准备了一个补丁。能否就此向我们提供反馈意见？ 该补丁解决了以下问题： 通过对命令结构进行零初始化，确保不会出现之前使用缓冲区时遗留的垃圾值。 保证 DTIM 周期取自扫描描述符或设置为零。 通过明确对 6 字节 CF 参数集进行零初始化来防止 6 字节 CF 参数集中的随机值。   同时，我们将继续评估未来版本中是否可以提供更稳定、更永久的修复程序。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) Hi Christine 我没有修改代码，只是在内存窗口中显示缓冲区，并手动设置其内容，这样我就能看到哪些内容被写入，哪些没有被写入。 如果您想通过修改代码来进行测试，可以按照您展示的方法进行。 此致 Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 现在我需要你们在 Wi-Fi 端所做的修改，以确认所报告的问题。 请确认以下几点？ 您是否在函数 wlan_cmd_802_11_associate () 中初始化了 passo 变量？ 中初始化 passo 变量了吗？   memset(passo, 0x55, sizeof(HostCmd_DS_802_11_ASSOCIATE))； 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，Christine 事实上，在开始填充之前，我已经将"complete" cmd 缓冲区全部设置为零（这对所有可能的信息都有效）。这是一种很好的做法，因为它可以确保任何未设置的字段都有一个定义为 0 的值（甚至可以省去将其清零的代码，因为它知道它们已经是这样了）。 如果只将缓冲区的一部分设置为零，就只能处理一部分缓冲区，我不会这样做，因为这样并不能解决数据丢失的问题。 passo->dtim_period = pbss_desc->dtim_period ?pbss_desc->dtim_period : 0; 是正确的，但可以简化为（因为对 0 的检查是多余的）。 passo->dtim_period = pbss_desc->dtim_period； pbss_desc->dtim_period 必须在每次使用前初始化为 0，因为它是由扫描结果选择性填写的 - 参见： 情况 DTIM_PARAM_SET:<---------------- pdtim_param_set = (IEEEtypes_DtimParamSet_t*)(void*)pcurrent_ptr； pbss_entry->dtim_period= pdtim_param_set->dtim_period;<------------- 打破; 如果是 pss_tlv->cf_ibss.cf_param_set我认为不应该设置零，因为这是一个可以选择从接入点接收的字段 - 参见 情况 CF_PARAM_SET:<--------------------- pcf_param_set = (IEEEtypes_CfParamSet_t*)(void*)pcurrent_ptr； (void)__memcpy(pmadapter、&pbss_entry->ss_param_set.cf_param_set, pcf_param_set,<----------- MIN(total_ie_len、 sizeof(IEEEtypes_CfParamSet_t))); pbss_entry->ss_param_set.cf_param_set.len= MIN(element_len, (sizeof(IEEEtypes_CfParamSet_t) - sizeof(IEEEtypes_Header_t))); 打破; 按照这种写法，它不一定是一个有固定长度的字段。如果可以假定长度固定，则可以使用 memcpy(&pss_tlv->cf_ibss.cf_param_set、& pbss_entry-> ss_param_set. cf_param_set 、sizeof(pss_tlv->cf_ibss.cf_param_set))； 否则，只需复制有效长度，TLV 的长度也需要修改。 不过，我认为解决方案取决于您的开发团队，因为他们才是专家。我只是想指出明显不正确的地方，以便专家们能正确修正。 此致 Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 我们的内部团队仍在根据您的反馈意见对补丁进行审核，一旦得出结论，我们会及时更新。 顺祝商祺！ Christine。 Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 嗨克里斯汀 ，这很有道理。 谢谢 Mark Re: Random data in the association command - (with Murata NXP 88W8801 Typ2 2DS) 你好，@mjbcswitzerland 请参阅以下内部团队的反馈意见： 附上修改后的更新补丁。 根源分析 DTIM 周期：在 802.11 关联请求中，此字段是可选的。目前的代码为其分配了空间，但从未对其进行初始化，导致传输的数据是随机的。 CF 参数集：这是一个条件参数，只有当 AP 在其信标或探测响应中宣传 CF 功能时才应包含。目前的实施情况： 始终插入 TLV_TYPE_CF 条目 为 cf_param_set 分配 6 字节 从不填充实际数据   建议 根据问题分析和客户反馈：   DTIM 期间： 初始化为 0或合理的默认值 由于它是可选的，因此根据 802.11 标准，将其设置为 0 是可以接受的 用于 CF 参数集： 有条件包容:仅在从 AP 收到 CF_PARAM_SET 时添加 TLV_TYPE_CF 正确的数据拷贝:如果 AP 宣传了 CF 功能，则复制实际的 CF 参数数据 如果不需要，请删除:如果 AP 不宣传 CF 功能，则完全不包含此 TLV     影响 遵守协议:目前的实施违反了 802.11 协议的正确实施 互操作性：关联帧中的随机数据可能会影响与某些 AP 的兼容性 网络安全：发送未初始化的内存内容可能是轻微的信息泄露   根据上述数据，根据从 AP 收到的数据，这两个值似乎都是强制性的，也可以是可选的，这就是未设置这两个参数的原因。   请注意，由于这两个参数是可选的，不会造成任何其他问题（在其他位置），因此其他芯片组和代码库不需要进行这些更改，您可能需要对其进行测试并将更改保留在您的端。 如果您对此案有任何其他关切，请告诉我。 如果没有其他问题，请将我的回答标记为解决方案，以便我们结案。 如果您在使用我们的产品过程中遇到任何其他问题，请随时向我们提交新的案例。 顺祝商祺！ Christine。

S32G2 ロック喪失（PLL） こんにちはサポーターさん、 私はシステムセーフティアーキテクチャです。 現在、NXP SS32G2 チップを使用した自動車のシステムセーフティをデザインしています。PLL（Loss of Lock）に関して質問させていただきます。 私の知る限り、障害が発生すると、HW は FCCU に障害を報告します。しかし、PLL をチェックすると、PLL 障害のあるこのコンテンツは見つかりません。 手伝っていただけませんか？ よろしくお願いします。 Re: S32G2 Loss of lock (PLL) こんにちは、 @phuong3_tran 投稿ありがとうございます。 PLLはLOL表示を提供します。LOL （Loss of Lock）モジュールはPLL出力クロックを監視できます。これは、重大な障害の検出を目的としています。 LOL イベント情報 のトリガーとして考えられるものは次のとおりです。 1. 特定のイベント情報により、FXOSC 入力信号の周波数に大きな偏差が発生しました。 2. チップの供給電圧に大きな変化が生じます。 3. 接合部温度が仕様外です。 よろしくお願いします。 BR チェイン

GHS マルチデバッガ - マイクロコントローラの POR 後に再開しない こんにちは。私は Renasas E1 デバッガーと GHS マルチ デバッガーを使用しています。マイクロコントローラの電源をオフにして再びオンにすると、デバッガー ウィンドウが停止します。デバッグのために再開する必要があります。これに対する解決策を提供してください。セッションを再開するためにソフトウェアを再度フラッシュせずにこれを行うことは可能ですか。 Re: GHS Multi debugger - Not resuming after Microcontroller POR こんにちは@danielmartynek 、 私はルネサスRH850 - RH850/C1M-A2を使用しています よろしくお願い申し上げます。 Re: GHS Multi debugger - Not resuming after Microcontroller POR こんにちは@Lokesh_0109さん、 MCU部分を指定してください。 よろしくお願い申し上げます。

P1.27（下降沿）上的 ADC 硬件触发信号在 LPC1768 硬件上不起作用 你好 我正在尝试使用 P1.27 作为带下降沿检测的触发信号源，在 LPC1768 上测试 ADC 硬件 触发信号。在仿真中，当我在 P1.27 上生成下降沿时，ADC 会正确开始转换 ，但在实际硬件上，ADC 无法开始 转换。 我的 ADC 配置为在 P1.27 上触发信号硬件，通道已启用，ADC 已 通电。 我想知道在 LPC1768 硬件上使用 P1.27 作为 ADC 触发信号 是否存在任何限制 ？ 如能提供任何说明或指导，将不胜感激。 谢谢！ Re: ADC Hardware Trigger on P1.27 (falling edge) not working on LPC1768 hardware 你好@AkshayNaik1907 是的——LPC176x上有一个已知的勘误表，它会影响使用P1.27作为ADC外部触发信号。在实际硬件上，ADC 可能会错过 P1.27（和 P2.10）上的边沿，因此即使模拟器显示转换正常，也无法可靠地启动转换。失误率取决于 ADC 外围时钟。 您可以参考 errta ES_LPC176x 勘误表 Harry_Zhang_0-1756285675029.png BR 哈利

LLCE_PFE 导致的过长延迟和帧丢失 使用 S32G 的 LLCE 和 PFE 模块的快速路径，实现多通道 CAN 到 AVTP 以太网数据包的转换，经历过多的延迟和帧丢失。造成这些问题的常见原因是什么？ Re: Excessive latency and frame loss caused by LLCE_PFE hi，liu823230301 您使用 can_llce-pfe_eth 演示版吗？在测试过程中，你还对它做了其他改动吗？您能分享一下您是如何测试的吗？例如，设置的网络速率和捕获帧的方法。 关于信息 Eth->EthCtrlConfig->EthCtrlConfigIngressFifo->EthCtrlConfigIngressFifoBufTotal。 >>>传输缓冲区的数量。最小值为 2，最大值为 512。它应存储刚刚从物理以太网接收到的帧，以防止 MAC 层丢包。 Eth->General->VarEthBmu2BufCnt。 >>>为所有 EMAC 和 HIF 提供统一的 2048B 缓冲区块，供 PFE 进行内部处理和转发。 Llce_AF->Eth2Can->Eth2Can 缓冲区的数量。 >>>为使用 Eth2Can 而在内存中创建的缓冲区数量。必须是>=73。 您的设置应符合设置要求。应用程序例程用作参考。 BR 乔伊 Re: Excessive latency and frame loss caused by LLCE_PFE 现在怀疑在以太网到广域网的转换过程中，LLCE_PFE 丢弃了数据包。以太网并发率低时，不会丢弃数据包，但以太网并发率高时，会在转换后造成帧丢失。 配置以下参数是否有特定规则？ Eth->EthCtrlConfig->EthCtrlConfigIngressFifo->EthCtrlConfigIngressFifoBufTotal、 Eth->General->VarEthBmu2BufCnt、 Llce_AF->Eth2Can->Eth2Can 缓冲区数量 Re: Excessive latency and frame loss caused by LLCE_PFE hi,liu823230301 感谢您的回复。 有关多核使用情况，请参阅 AN13750.LLCE。有关更具体的使用方法，您可以参阅 AN13423 获取更多信息和更详细的缓冲区设置建议。 Joey_z_0-1756709939621.png https://www.nxp.com.cn/docs/en/application-note/AN13423.pdf 希望能帮到你。 BR 乔伊 Re: Excessive latency and frame loss caused by LLCE_PFE 如何确认 Eth2can 是在单核心还是多核心上运行，以及如何在需要时将其配置为多核心运行。 LLCE 版本： LLCE_1_0_10，我使用了Eth2Can 缓冲区 255。 liu823230301_0-1756693023567.png Re: Excessive latency and frame loss caused by LLCE_PFE hi,liu823230301 感谢您的回复。 您是在单核心还是多核心上使用 ETH2CAN？什么是 LLCE 版本？ 您可以尝试在配置中添加缓冲区 ("Llce_Af > Eth2Can> Eth2Can 缓冲区的数量 (72 -> 255)")。 BR 乔伊 Re: Excessive latency and frame loss caused by LLCE_PFE 我在 S32G2 RD2 中使用 SW32_RTD_4.4_5.0.0_QLP03_D2505 和 PFE-DRV_S32G_M7_MCAL_1.6.0。 我发现在使用 LLCE 和 PFE 进行以太网到 CAN 的转换时，当三个以太网数据包同时到达时，往往会出现丢包现象。 在 S32G 中使用 LLCE 和 PFE 进行以太网到 CAN 的转换时，LLCE 和 PFE 可同时处理的以太网数据包的最大数量是多少？如果超过这个数字，数据包会被丢弃吗？ Re: Excessive latency and frame loss caused by LLCE_PFE hi,liu823230301 感谢您与我们联系。 您使用的是哪个版本的 LLCE？ 您使用 LLCE_PFE 演示吗？ BR 乔伊

I2C master not working Hello , I'm trying to test I2C master on S32K324 but i'ts not working. Actually I have no I2C slave connected to I2C master but I don't see any transition on PTD13 (LPI2C_SDA) or PTD14 (LPI2C_SCL), the two pins are ever HIGH. I expect to see start condition like attached file. Attached there is the project. Regards, Francesco. Re: I2C master not working Hi @francescovico, It does work on my side - I have tested your code. If it does not work on you side, explain in details what does not work.  Make sure the DBGEN bit is set at the time the transfer is called. Have you tested it with CM7_1 running? Do you use external pull-up resistors? Regards, Daniel Re: I2C master not working Hi Daniel, It still not working well . Regards, Francesco. Re: I2C master not working HI @francescovico, danielmartynek_0-1756971786422.png Enable it after the Init function. Otherwise, the Init function will clear the bit. Regards, Daniel Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction. Re: I2C master not working Hello Daniel, sorry but putting: IP_LPI2C_0->MCR |= LPI2C_MCR_DBGEN_MASK; The I2C still not working. Attached my project. Regards, Francesco. Re: I2C master not working Hi @francescovico, When CM7_1 is halted, the MCU enters debug mode. To ensure LPI2C continues functioning, either set the DBGEN bit in LPI2C_MCR to allow operation during debugging, or Keep CM7_1 running. BR, Daniel Re: I2C master not working Hello Daniel, Thank you, it's true I forgot to initialize interrupt. Also with interrupt enabled the I2C it's not working. Attached there is the project with interrupt enabled. Do you have other suggestions? Regards. Re: I2C master not working Hello Francesco, I haven't tested the code, but I see that you did not enable the LPI2C interrupt. Add IntCtrl_Ip driver with LPI2C0_Master_Slave_IRQHandler. And initialize the driver in the code. Regards, Daniel

ADC 压摆测试 项目概述 我正在研究一种通过 emiOS → BCTU → ADC 链触发信号 ADC 采样的设计。BCTU 从 配置在 OPWMT 模式下 的 emiOS PWM 通道 接收触发信号， 以便在触发事件之间创建精确的时间偏移。 当前设置 ADC0 处理两组信号： 由 em ios_0_ch@@ 1 触发的第 1 组 （两个 ADC 通道） 由 em ios_0_ch@@ 2 触发的第 2 组 （两个 ADC 通道） 每个信号采样大约需要 1.3 µs，因此每组信号大约需要 2.6 µs。 第二组（由 CH2 触发信号）偏移 3.6 µs（+1 µs 边距），以避免与第一组重叠。 时间顺序： Time (µs): 0 1.3 2.6 3.6 4.9 6.2 7.2 |----------|----------|----------|----------|----------|----------|----------| eMIOS_0_CH1 ---> adc_ch1 (start at 0 µs) ---> adc_ch2 (after 1.3 µs) eMIOS_0_CH2 (offset by 3.6 µs) ---> adc_ch1 (start at 3.6 µs) ---> adc_ch2 (after 1.3 µs → ~4.9 µs) eMIOS_0_CH4 (offset by 7.2 µs) ---> software trigger for ADC0 self-test 两个组都完成后，我添加了 emios_0_ch4 作为 软件触发器 （通过回调）在 ADC0 上启动 ADC 自检。使用 adc_sar_IP_SelfTest API CH4 偏移 7.2 µs ，以确保在自检开始前完成所有采样。 观察 当我在 CH4 回调中切换 GPIO 时，它如期触发。不过，为单个 ADC 实例运行 ADC 自检 需要约 13 µs （通过软件测量）。 Skærmbillede 2025-09-11 173539.png   问题 S32K3xx ADC（算法 S + C）的自检持续时间（约 13 µs）是预期的吗？ 我的计算结果 采样相位时间 (ST) = 23 每个比特的评估时间 = 4 数据处理时间 (DP) = 2 在不影响 25 µs 采集周期的情况下安排自检的最佳方法是什么？考虑到每个实例可能包含多个ADC通道组，是否有其他或更有效的方法可以触发信号ADC的自检？我目前使用的是 RTD 中的 Adc_Sar_Ip_SelfTest API，我想知道在初始化时执行自检更合适，还是在运行时执行自检更合适，还是两者都执行自检更合适。在时间、可靠性和整体系统性能方面，处理 ADC 自测试的最佳做法是什么？ 在自测期间仅屏蔽 ADC0 触发信号（而不是冻结所有 BCTU 触发信号）是否是保持 ADC1 和 ADC2 运行的正确方法？ 目标： 确保对 ADC0 进行定期自检，同时不干扰其他 ADC 的实时采样。 我附上了我的项目，你可以看一看。 s32k344 RTD_6.0.0 Re: ADC slef Test 感谢您关注我们的产品并为我们的社区做出贡献。 根据60.3.17.2 自检部分：在 80 MHz ADC 时钟频率下，单个步骤耗时可达 1 µs。 请参见所附示例。实际上，我无法让每个实例的运行时间少于 14us。 对于功能安全应用，必须定期验证操作是否正确。但也要考虑到，ADC 自检函数应在驱动程序初始化后的任何时间调用，并且没有正在进行的转换。 _Leo__0-1758237227307.png 当您暂停调试会话时，在 “表达式” 税务摊销收益中可以观察结果：g_FIFO1Resul t，它对应于 BCTU 列表测量值，同时 g _FIFO1Volts 对应的是以伏特为单位的转换。 _Leo__1-1758237302648.png 希望这能解决您的问题。 如有更多问题，请帮助我创建一个新职位。

Lear - S32k3 FEEスワップブロック時間が長すぎる リアはこう言っています。 -------------------------------------------------------------------------------------- 添付の ARXML ファイルに基づいて、この書き込みブロック操作を完了するためにバンク スワップが必要な場合、一部の Fee ブロックを保存するためにソフトウェアが費やす時間は最大 10 秒であることがわかりました。 Fee 構成に存在するすべてのブロックには、データ フラッシュにすでに有効なコピーが格納されている。SO、バンク スワップ操作では、すべての Fee ブロックの最後の有効なコピーが検索されます。 要求されているのは、この実行時間をどのようにCAN改善できるかを理解することです。 添付のファイルセットが役に立つかどうか、または私が提供できる特定の情報が必要かどうかはわかりませんので、お知らせください。 -------------------------------------------------------------------------------------- BR ステファノ 優先度: 高 RTD 出典: 直接お客様 Re: Lear - S32k3 FEE swap block time too long 各リリースの品質パッケージには、関数の最小/平均/最大実行時間を測定するための RTD_FEE_ProfileReport レポートが含まれています。ただし、実行時間は TestCase 構成に基づいているため、SOユーザー構成によって異なる場合があります。 Re: Lear - S32k3 FEE swap block time too long こんにちは、 cuongnguyenphuさん 測定された時間の表はありますか? Lear の数字が正しいかどうかを理解するだけです。 BR ステファノ BR ステファノ Re: Lear - S32k3 FEE swap block time too long 他にアイデアはありません Re: Lear - S32k3 FEE swap block time too long こんにちは、 cuongnguyenphuさん リア： 私たちが知っている主な機能で CPU を支払います。FeeDataBufferSize はすでにテストされています。 システム クロックは 1 ミリ秒です。より高い頻度で行う予定はありません。nvm などに内部クロックがある場合にのみチェックできますが、OS の場合はチェックできません。 他に何かありますか? BR ステファノ Re: Lear - S32k3 FEE swap block time too long 以下のアイデアもぜひチェックしてみてください: 1.システムクロックのMCU周波数を確認し、周波数を高速化してみてください 2. MemAcc_MainFunction 期間: 0.005 (5ms) であることがわかりました。周波数を高速化するために1msまたは2msに設定することは可能ですか？ 3. FeeDataBufferSize を増やす: バッファサイズを2倍または3倍にすると、Feeクラスタ マネジメント操作のパフォーマンスが向上するかCAN確認します。 Re: Lear - S32k3 FEE swap block time too long こんにちは、 cuongnguyenphuさん Lear のフィードバックによると、指示に従って 10 秒間に 500 ミリ秒の短縮が実現しました。 少なくとも 5 秒の短縮が期待されます。 他に検討できる可能性はありますか? BR ステファノ Re: Lear - S32k3 FEE swap block time too long @StefanoGattazzo 同様の議論されたトピックについては以下を確認してください。 [RTD] S32K314 - FEEマネジメント効率 S32K312 FEE実行時間

Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) Hi:  Recently, I encountered a problem in the process of using: I created a label, and then triggered the event to enlarge or shrink another label, and then simulate was not successful. When the label was pressed, the other label did not respond. Four interface functions are used: lv_obj_set_style_transform_pivot_x(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_pivot_y(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_width(item_array_1a[i].item_obj_icon, 512, LV_PART_MAIN); lv_obj_set_style_transform_height(item_array_1a[i].item_obj_icon, 128, LV_PART_MAIN); so, why labels cannot be scaled up and down? Is the LVGL interface used incorrectly? 图像1.png 图像2.png Re: Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) The V8.3.10 version of the interface has a problem, the V9.2.1 version of the interface can achieve the function： lv_obj_set_style_transform_pivot_x(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_pivot_y(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_scale_x(item_array_1a[i].item_obj_icon,384,LV_PART_MAIN); lv_obj_set_style_transform_scale_y(item_array_1a[i].item_obj_icon,384,LV_PART_MAIN); Thanks to wenbin Re: Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) Hi: @WenbinYuan  Yeah, what I'm trying to do is I'm going to make label_b scale when I click on label_a. In addition, why use V8.3.10 version is because we use the development board of your company MIMXRT1170-EVK, LVGL V9.2.1 version does not have the corresponding device template, but V8.3.10 exists. Our company also hopes to use the latest version of LVGL version. Is it possible to use the device template without MIMXRT1170-EVK development board now? 是的，我目前想实现效果是点击label_a的时候让label_b缩放大小。另外，为什么使用V8.3.10版本是因为我们使用您公司MIMXRT1170-EVK的开发板，LVGL V9.2.1版本中没有对应设备模板，而V8.3.10中存在。我们公司也希望使用最新版的LVGL版本，现在是没有MIMXRT1170-EVK开发板的设备模板也可以使用吗？ zhuangfei_0-1758244955307.png Re: Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) Hi @zhuangfei, Could you please share a bit more about your project setup? For example, the logic behind this case — do you want to trigger a scaling effect on label_b when label_a is clicked? if yes, the  LV_OBJ_FLAG_CLICKABLE flag should be enabled to label_a In my case, using your code, at least the label_b does change its main size. However, the effect isn’t perfect — the font size doesn’t scale accordingly. BTW, could you please share the reason why you chose LVGL v8.3.10 for your project? We generally recommend using the latest version of LVGL, as it includes important improvements and bug fixes that might help with your use case. 您能麻烦给出这个用例的详细信息吗？例如具体的逻辑链条，您是想在点击 label_a 的时候让 label_b 缩放大小吗？这样的话 label_a 需要使能 LV_OBJ_FLAG_CLICKABLE  。 在我这边的重现中，至少 label_b 本身的大小是会改变的，只是文本的大小不会改变。 能顺便问一下您选择V8.3.10版本开发的原因吗？我们比较推荐使用最新的LVGL版本，因为有很多功能被丰富了，比如Transform有了更多的配置，可以顺利的改变整个label的大小包括字体本身。 Looking forward your update! Best Regards, Wenbin Re: Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) hi：@Wenbin I added flag: add clickable according to your screenshot, but there was still no reaction. For other keys, I set the trigger event to change the color of the background image of the label when clicked. This can be achieved, but the zoom and zoom note interface function has not been able to work 我按照你的截图增加了flag：add clickable但是点击还是没有反应，其他按键我是设置触发事件是点击标签背景图片变色这个是可以实现的，但这个放大缩小便签接口函数一直不行。 lv_obj_set_style_transform_pivot_x(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_pivot_y(item_array_1a[i].item_obj_icon, 50, LV_PART_MAIN); lv_obj_set_style_transform_width(item_array_1a[i].item_obj_icon, 512, LV_PART_MAIN); lv_obj_set_style_transform_height(item_array_1a[i].item_obj_icon, 128, LV_PART_MAIN); Re: Labels cannot be scaled up and down (Gui Guide 1.9.1, LVGL 8.3.10) Hi @zhuangfei, Could you please check whether the LV_OBJ_FLAG_CLICKABLE flag has been added to your trigger label widget? By default, label widgets do not have this flag enabled, so they won’t respond to click events unless it’s explicitly set. You can add the flag in the widget’s Flags section like this: WenbinYuan_2-1758189869524.png Hope this helps! Feel free to share more details or let us know if you need further assistance. Best Regards, Wenbin 

示例 MPC5748G SMPU 初始化 + 进程 ID 测试 GHS614 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** * 详细说明： *此示例初始化 SMPU_0 和 SMPU_1 以覆盖所有内存资源 * 所有大师。 * 本例进行简单测试：初始化后，SMPU_1 * 配置已更改为禁用对最后 4kB RAM 的写入访问 * 进程 ID 1。允许进程 ID 0 进行写访问。 * 如果在进程 ID 为 1 的情况下 CPU 写入该区域，则将引发异常 * 由于访问冲突而发生。 * ---------------------------------------------------------------------------------------------- * 测试硬件：MPC574XG-324DS Rev.A + MPC574XG-MB Rev.C * 微控制器: PPC5748GMMN6A 1N81M * 系统频率：160 MHz PLL * 调试器：Lauterbach Trace32 * 目标：internal_FLASH * ******************************************************************************** 概述

例MPC5777C GHS714 外部SRAM_test ******************************************************************************** *詳細な説明: *アプリケーションは基本的な初期化を実行し、次に外部のEBIを初期化します * SRAMをMPC5777C-516DSに接続し、ブロックの書き込みと読み出しでテストします。 *データ。 * * ------------------------------------------------------------------------------ ※テストHW:MPC5777C-512DS Rev.A + MPC57xx マザーボード Rev.C ※MCU:PPC5777CMM03 3N45H * Fsys: PLL1 = core_clk = 264MHz, PLL0 = 192MHz *デバッガ:Lauterbach Trace32 * 対象:internal_FLASH *端末:19200-8-パリティなし-1ストップビット-eSCI_Aのフロー制御なし * EVB接続:位置1-2のジャンパーJ4(CS0を選択) * ******************************************************************************** ******************************************************************************** *詳細な説明: *アプリケーションは基本的な初期化を実行し、次に外部のEBIを初期化します * SRAMをMPC5777C-516DSに接続し、ブロックの書き込みと読み出しでテストします。 *データ。 * * ------------------------------------------------------------------------------ ※テストHW:MPC5777C-512DS Rev.A + MPC57xx マザーボード Rev.C ※MCU:PPC5777CMM03 3N45H * Fsys: PLL1 = core_clk = 264MHz, PLL0 = 192MHz *デバッガ:Lauterbach Trace32 * 対象:internal_FLASH *端末:19200-8-パリティなし-1ストップビット-eSCI_Aのフロー制御なし * EVB接続:位置1-2のジャンパーJ4(CS0を選択) * ********************************************************************************

Using the i.MX8M Audio System The NXP i.MX 8M provides industry leading audio, voice and video processing for applications that scale from consumer home audio to industrial building automation and mobile computers. The i.MX 8M Quad supports multiple audio interfaces as listed below: Besides the general audio input/output function, the audio interfaces will supports following features: - SAI-1 supports up to 16-channels TX (8 lanes) and 16-channels RX (8 lanes) at 384KHz/32-bit. - SAI-5 supports up to 8-channels TX (4 lanes) and 8-channels RX (4 lanes) at 384KHz/32-bit. - SAI-2/3/6 supports up to 2-channels TX (1 lanes) and 2-channels RX (1 lanes) at 384KHz/32-bit. - SAI-2/3/6 support up to 2-channels TX (1 lane) and 2-channels RX (1 lane) at 384KHz/32-bit. - SAI-1 supports glue-less switching between PCM & DSD operation for popular audio DACs - SPDIF-1/2 supports raw capture mode that can save all the incoming bits into audio buffer The SAI-1/2/3/5/6 and SPDIF-1 share GPIO pads on the chip through IOMUX. Common use cases supported by the audio interfaces are listed in the table below (many other configurations are possible). The number is the data lanes supported. For the MCLK pin on each SAI module, it can be configured as either input or output. When configured as output, the SAI_CLK_ROOT from CCM will be routed to the pad output. When configured as input, the external input to the pad will be routed to SAI.MCLK, which can be used as master clock for SAI. Below is the diagram showing the both input/output options, by using SAI1 as the example. Each SAI module supports up to 3 master clock inputs. The TX and RX sub-module inside each SAI can independently select one of the clock inputs as its master clock. This allows TX and RX of one SAI to run from different clock source. The master clock inputs have following options: - SAI.MCLK[1] can be selected from SAI_CLK_ROOT from CCM or SAI.MCLK from IOMUX. This is the most straight-forward clock routing in which SAI only use its own clock source from CCM or IO pad. - SAI.MCLK[2] can be selected from following clock sources:       Any of the SAI_CLK_ROOT from CCM;       Any of the SAI.MCLK from IOMUX;       Other clock sources from SPIDF; - SAI.MCLK[3] has exact same clock source options as SAI.MCLK[2]. This allows both TX and RX can have access to all the options without any dependency between each other. The clock options for master clock on SAI are shown in the diagram blow, by using SAI-1 as an example. The options on MCLK[1] is also available on MCLK[2] and MCLK[3]. The reason to keep this options is to provide the similar SAI clock structure as i.MX6/i.MX7 processors. The configuration of the MUX for master clock are controlled by IOMUXC_GPR registers. They should be configured before SAI clock is enabled to avoid glitches on the clock. Note: Because those MUX on clocks are missed during the design, the actual implementation in the silicon is simplified as shown in the following diagram. All the SAI and SPDIF instances have SDMA support. In order to meet the audio data rate, two SDMA modules are used. Because the SAI-2/3 and SPDIF-1/2 do not require high data throughput, they are assigned to SDMA-1, shared with other peripherals such as UART/SPI. SAI-1/4/5/6 need to support high sample rate & multichannel audio, they are assigned to SDMA-2, which is a dedicated SDMA engine for audio. The SDMA-2 frequency is increased to 500/250 instead of 133/66 to make sure it has enough throughput. In order to allow SW tracking the progress of audio DMA, the TX_SYNC and RX_SYNC of SAI modules are routed to GPT as the external clock input. Since there are totally 6 SAI modules, these signals will be MUXed when connection to GPT. - GPT-4/5/6 external clock input can be selected from the TX_SYNC or RX_SYNC of any 6 SAI modules; - The MUX select is controlled by IOMUXC_GPR register; - The MUX select register for GPT-4/5/6 are fully independent of each other. Re: Using the i.MX8M Audio System Thank you Xiaocong Fu

PMIC PF3000/3001 资源 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> PF3000 是一款电源管理集成电路 (PMIC)，专为与 NXP i.MX 7 和 i.MX 6SL/SX/UL 应用处理器配合使用而设计。PF3000 配备最多四个降压转换器、六个线性稳压器、RTC 电源和纽扣电池充电器，可以为整个系统（包括应用处理器、内存和系统外设）供电。该设备采用 SMARTMOS 技术。 最新版本的数据表： https://www.nxp.com/docs/en/data-sheet/PF3000.pdf 应用笔记： https://www.nxp.com/docs/en/application-note/AN5132.pdf https://www.nxp.com/docs/en/application-note/AN5161.pdf https://www.nxp.com/docs/en/application-note/AN5094.pdf https://www.nxp.com/docs/en/application-note/AN5113.pdf 评估板用户指南： https://www.nxp.com/docs/en/user-guide/KTPF3000FRDMEVMUG.pdf PF 电源管理开发工具的 GUI： https://www.nxp.com/downloads/en/device-drivers/PF3000-HID-GUI.zip EVM 和工具： https://www.nxp.com/webapp/sps/download/license.jsp? colCode=KITPF3000FRDMEVM 更多信息： https://www.nxp.com/products/power-management/pmics/pmics-for-i.mx-application-processors/12-channel-configurable-pmic:PF3000 PF3000PF3001

例MPC5777M TSENS温度計算GHS616 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** 詳細な説明: 例は、TSENSを使用したMCUの温度測定を示しています。  TSENS0のキャリブレーション定数は、テストフラッシュから読み取られます。 SARADC_Bは、VbgおよびTSENS出力を測定するように設定されています。  計算された内部温度をターミナルに表示できます。  EVB接続: マザーボード J14 - SCI_RXオン J13 - SCI_TXオン J25 - SCI_PWRオン   PC端末(19200、8N1、なし)で結果を参照してください。次のテキストが表示されます (確かに値が異なります)  TSENS - 温度測定 続行するには、任意のキーを押してください... テストフラッシュから読み取られたTSENSのキャリブレーション定数 TSCA = 184 TSCB = 21   T = (232 + TSCA * 2^-6) * TSENS_code / VBG_code - (273 + TSCB * 2^-4) [°C] ---------------------------------------------------------------------------- VBG_code = 251 TSENS_code = 339 TSENS温度 = 42.91°C ------------------------------------------------------------------------------ テストHW:MPC5777M マスクセット:0N50N 対象 : RAM, internal_FLASH Fsys:600MHz PLL1、40MHz水晶リファレンス ターミナル:19200ボー、8N1 ******************************************************************************** 全般

实践研讨会：FreeMASTER 快速入门 – 轻松实现应用开发和调试 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在本课程中，您将学习使用 NXP 的 FreeMASTER 调试工具来辅助系统开发和调试。尽管它在各种应用中都有许多用途，但我们将通过基于我们的 MagniV MC9S12ZVMRM 微控制器的电机控制示例来演示 FreeMASTER 的功能和用法，以简化开发过程。参与者将看到它是多么有用和易于使用和配置，以便可以随时调整系统变量或实时观察系统参数。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在本课程中，您将学习使用 NXP 的 FreeMASTER 调试工具来辅助系统开发和调试。尽管它在各种应用中都有许多用途，但我们将通过基于我们的 MagniV MC9S12ZVMRM 微控制器的电机控制示例来演示 FreeMASTER 的功能和用法，以简化开发过程。参与者将看到它是多么有用和易于使用和配置，以便可以随时调整系统变量或实时观察系统参数。