Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
ビルドエラー、.axfファイルが見つかりませんファイル、およびデバッグ起動中の RedlinkServerException こんにちは、NXPサポートチームの皆さん、 MCUXpresso IDEでプロジェクトの構築とデバッグを試みているときに、複数の問題に直面しています。 環境の詳細: MCUXpresso IDE バージョン:v11.8.0 ホストOS: Windows ターゲットボード/MCU:MKM34z256vll7 デバッグプローブ: CMSIS-DAP 観察された症状: ビルドエラー / .axf/.elf ファイルが見つかりません:リリース構成をビルドしようとすると、ビルドエラーが発生します。これらのエラーのため、.axf/.elf 出力ファイルが生成されず、 「プログラム ファイルが存在しません」というデバッグ起動エラーが発生します。 RedlinkServerException: デバッグや接続を試みると、RedlinkServerException: Write not opened(開いていないサーバーに書き込みできません)というメッセージを受け取り、LinkServerとの通信失敗を示しています。 プローブ発見の問題: IDEがデバッグプローブと正しく検出または通信できないことがあります。 既に試したトラブルシューティング手順: ビルドエラーを解決する必要があることは確認済みですが、.axf ファイルの生成を妨げる特定のコンパイル/リンカーエラーの解決方法についてガイダンスが必要です。ファイル生成。 MCUXpresso IDEを再起動し、デバッグプローブ/開発ボードの電源を入れ直しました。 Re: Build errors, Missing .axf file, and RedlinkServerException during debug launch こんにちは、 @Maheswari123 さん。 投稿ありがとうございます。 1. リリースビルドの失敗 / .axf ファイルが見つからないまたは.elfファイル .axf/.elf実行ファイルは、プロジェクトが成功裏にコンパイル・リンクされた後にしか生成できません。 したがって、まずリリースビルドの完了を妨げている実際のコンパイラ/リンカーエラーを特定してください。プロジェクトをクリーンアップしてリリース構成を再構築し、コンソールからの完全なビルド出力、特に最初のエラーとその周辺のメッセージを提供してください。実際のコンパイラ/リンカーエラーを使えば、問題がソース/インクトゥルパス、リンカーの設定、未定義の参照、あるいは他の何かに関連しているのかを判断できます。 SDKデモを開いて、うまくビルドできるか試してみてください。これにより、問題がツール自体にあるのか、カスタムコードにあるのかを判断するのに役立ちます。 2. CMSIS-DAP / LinkServer 通信の問題 RedlinkServerExceptionおよび断続的なプローブ検出については、WindowsがCMSIS-DAPプローブを認識しているか、またファイアウォールやセキュリティソフトウェアがRedlinkサーバーとの通信をブロックしていないかを確認してください。デバッグセッションを終了した後、クリーンアップデバッグを試してから再度プローブを検索することができます。 さらに、使用されている正確なCMSIS-DAPプローブ(例:MCU-Link、OpenSDA CMSIS-DAP、または他のプローブ)も教えてください。問題が解決しない場合は、エラーに関連するLinkServerのコンソール/ログ出力全体も提供してください。 ご返信をお待ちしております。 BR セレステ
記事全体を表示
Air Travel Partner in the USA - We Gooo Welcome to We gooo, your trusted air travel agent in the USA, connecting you with airlines and offering a seamless booking experience. By creating a profile with us, you can easily manage your trips, stay up to date with flight information, and receive personalized recommendations, all while understanding the key terms and conditions involved.
記事全体を表示
S32k342: Bctudmabuffer is not updating with data. Hello, I have configured PIT,BCTU , DMA(Ch6) for ADC0 having 10 channel. had checked register value LISTCHR and FIFO1DR, MSR:(Decimal) MSR : 32768, TRGCFG[23] :268477184 MCR: 67305600 FIFO1DR: 781516942 LISTCHR[0] : 2162725 LISTCHR[1] : 65576 LISTCHR[2] : 6 LISTCHR[3] : 327687 LISTCHR[4] : 2147909636 FIFCR: 16777216 FIFOERR: 151060480 FIF0SR: 0 FIFOCNTR: 15 Have configured the DMA ch 6 for autosar MCAL with help of example code using https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-PIT-BTCU-parallel-ADC-FIFO-DMA-DS3-... query is here i am not getting DMA watermark notification and data on bctudma buffer. what is missing , please guide. Thansk Re: S32k342: Bctudmabuffer is not updating with data. i am using AUTOSAR MCAL . Is transfer config also require to configure. and require to call  transfer API .? Mcl_SetDmaChannelTransferList and Mcl_SetDmaCHannelCommand with MCL_DMA_CH_START_REQUEST. Re: S32k342: Bctudmabuffer is not updating with data. Currently i am using path and have shared config for this : PIT_CH0 → TRGMUX → BCTU_Trg23 → ADC0/Adc1 → DMA please let me. Final path which i will use : PIT_CH0 - TRGMUX - BCTU_Trg23  ADC0 (5 channel) -  FIFO1 -  eDMA PIT_CH1  - TRGMUX - BCTU_Trg47 -  ADC1   (5 channel)   - FIFO2 - eDMA Please also let me know config for this. Re: S32k342: Bctudmabuffer is not updating with data. I am using RTD 3.0.0 Re: S32k342: Bctudmabuffer is not updating with data. Bctu Config:  Adc: DMA:  Also Peripheral clock enabled for BCT, PIT, EDMA,DMAMUX_0 Re: S32k342: Bctudmabuffer is not updating with data. Hi, Thank you for the details. From the register values alone it is difficult to determine what is missing. Since the ADC conversions appear to be reaching the BCTU FIFO, the issue may be related to the BCTU→DMA request path, DMA channel configuration, or the DMAMUX setup. Could you please provide either: a simplified test project reproducing the issue, or screenshots of your S32 Configuration Tools settings for: ADC BCTU DMA/eDMA DMAMUX PIT Additionally, please let us know RTD version you are using. With the configuration or a simplified project, we can compare it against the working example and identify any missing or incorrect settings much more efficiently. BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. Hi, no transfer config and code coresponding to it is needed. Transfer config is done in driver. Have you config and init the DMAMUX as well through Rm component? You should have something like this... with desired channel selected. Then call Rm init in code  #include "CDD_Rm.h" /* Initialize DMAMUX via HLD RM driver */ Rm_Init(&Rm_Config); BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. Yes am doing . and also doing Rm_Init Re: S32k342: Bctudmabuffer is not updating with data. All the config i have shared you  previously . Adc:  using control mode with the calling API Adc_EnableCtuControlMode fro both Adc 0 and 1. is it also require to call Adc_CtuEnableHwTrigger this one i have not called yet.? Re: S32k342: Bctudmabuffer is not updating with data. Hi, Thank you for the details. Based on the information provided so far, it is difficult to determine the root cause. The register dump alone is not sufficient to identify whether the issue is in the BCTU, DMA, DMAMUX, or software configuration. A few additional things to verify: Is the DMA interrupt enabled and correctly configured? Are you using ADC BCTU Control Mode or Trigger Mode? Please note that DMA watermark notifications are available only when using BCTU Control Mode. If you are using Trigger Mode, receiving a DMA watermark notification is not expected. To help us analyze the issue, could you please share either: a simplified standalone project reproducing the problem, or complete screenshots of the relevant S32 Configuration Tools settings (ADC, BCTU, DMA/DMAMUX, PIT) together with related code? Ideally, a complete simplified project would allow us to review the configuration and compare it against the working reference example more efficiently. BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. Hi,  from given screenshots I do not see obvious issue. As you did share project, code used, let me create some to test your indended trigegr scenario. BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. Please check config. Re: S32k342: Bctudmabuffer is not updating with data. Yes please , as it is difficult to share the code , please create a test project for s32k342 . Thanks. Re: S32k342: Bctudmabuffer is not updating with data. Hi, finally I did a ADC HLD demo for your intended configuration Trigger paths: PIT0_CH0 -> TRGMUX -> BCTU Trigger 23 -> ADC0 (5 channels) -> BCTU FIFO1 -> eDMA (ch0) PIT1_CH1 -> TRGMUX -> BCTU Trigger 47 -> ADC1 (5 channels) -> BCTU FIFO2 -> eDMA (ch16) It is posted here: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-FRDM-A-S32K344-PIT-ADC-BTCU-ControlMode-FIFO-DMA-HLD/ta-p/2420432 Hope it helps. BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. Thank, I will check and confirm. Re: S32k342: Bctudmabuffer is not updating with data. I checked example code but it is not working . Re: S32k342: Bctudmabuffer is not updating with data. Can you please reply.? Re: S32k342: Bctudmabuffer is not updating with data. Hi, I see data updated BR, Petr Re: S32k342: Bctudmabuffer is not updating with data. I have configured same channel as you did , and i can see BCTUDMA buffer is updating. But still did not get how did you aligned the Adc0/1channel  and why the ADC0 VREFL/H data is not matching with ADC1 VREFL/H channel. , same for P0? and also some channel is internal which is not require to configure on port but channel like p7 and p0 which is external then why it was not configured in port.?. And i fi want to configure my channel (10) how do i aligned it on BCTU and also do i require to configure on PORT also as p7 and p0 not done in your config.?  why all the channel of Adc0/1 you have not included in ADC configuration array.? Why only one channel for each ADC0/1? Re: S32k342: Bctudmabuffer is not updating with data. Hi, The channels listed in the BCTU list are used only in BCTU control mode, while the channels defined in the ADC unit’s group are used for normal or injected conversions. The group and channels in AdcHwUnit cannot simply be omitted, even if they are not used in this example. No ADC channel needs to be defined in Port. The ADC path is always enabled, so no Port configuration is required. In general, ADC channels do not require PORT configuration. Regarding the buffer misalignment, I originally tested this in Lauterbach, where the buffers were displayed correctly, as expected. Within S32DS, the data becomes misordered when code execution is stopped. I found that this was caused by the PITs being configured to continue running during debug mode. Change the setting to enable freezing the PITs during debugging. The buffers were also incorrectly defined; they should have been declared as uint16_t. Then buffers becomes displayed in S32DS properly as well. BR, Petr    
記事全体を表示
How to access and test the 32 MB embedded NVM on S32E288 Hello NXP Team, I am using the S32E288 device on the S32E288-975EVB and running an application on RTU0 Cortex-R52. The S32E2 product brief shows: - 0/16/32/64 MB embedded NVM - 512 KB data flash with ECC - QuadSPI NOR flash interface Our team wanted to test the NVM region with checker board pattern, Not albe to see any information on RM of s32e27RM where can we get the info, How can we access the Embedded NVM as we are using s32E288 board... I need clarification specifically for the 32 MB embedded NVM, not the 512 KB C55 data flash and not the external NOR flash fitted on the EVB. Could you please clarify the following? 1. Is the 32 MB embedded NVM a serial-flash die integrated inside the    S32E288 package/SiP? 2. Which controller and controller instance provides software access    to this embedded NVM?    Is it accessed through QuadSPI0, QuadSPI1, HSE firmware, or another    dedicated interface? 3. What is the RTU0 CPU-visible address range of the 32 MB embedded NVM?    Is there a memory-mapped read aperture, or must all reads be performed    using QuadSPI IP commands? 4. Are 0x00000000 to 0x01FFFFFF only flash-device offsets, or are they    valid Cortex-R52 system addresses for the embedded NVM? 5. Which QuadSPI chip-select or flash-address-assignment entry corresponds    to the embedded NVM? How can it be distinguished from the external NOR    flash on the S32E288-975EVB? 6. Which RTD driver and example should be used to read, erase, program,    and verify the embedded NVM from RTU0?    Please provide the exact driver/component name and a suitable example. 7. Does RTU0 have permission to erase/program the embedded NVM directly,    or must these operations be requested through HSE/System Manager firmware? 8. The safety manual states that the SiP serial flash does not support XIP.    Does this mean that memory-mapped reads are also unavailable, or only    instruction execution is unsupported? 9. What is the recommended method for a non-destructive read/write test on    one unused sector of this embedded NVM?    Are there protected/reserved areas for boot images, IVT, HSE, or OTA    metadata that must not be erased? My objective is to perform: read, write and verify the NVM region  Please share the relevant S32E2 Reference Manual section, address mapping, RTD example, and required access/protection configuration. Device: S32E288 Board: S32E288-975EVB Core: RTU0 Cortex-R52 / RTU1  Reference Manual: S32E2 RM Rev. 5 RTD: S32ZE AUTOSAR R21-11 RTD Re: How to access and test the 32 MB embedded NVM on S32E288 Hello, @NeelimaRagipindi  Thanks for your post. I had just noticed that you had a similar issue raised via our supporting portal, let me reply there together. BR Chenyin
記事全体を表示
机械图纸需求:RK055HDMIPI4MA0 显示屏 PCB 外形图、安装孔和 FPC 连接器 我正在设计一款定制的 i.MX RT1176 板,以 MIMXRT1170-EVKB Rev C3 为参考设计。它将使用 RK055HDMIPI4MA0 5.5 英寸 MIPI DSI 显示套件,通过套件 PCB 上的四个安装孔直接安装到我的板上。因此,我的板外形和安装孔需要与该PCB相匹配。 我找不到这块PCB板的机械图纸。我查看了 RK055HDMIPI4MA0 产品页面、MIMXRT1170-EVKB 用户指南和设计文件,以及 Rocktech RK055MHD091A0-CTG 面板数据手册,但该手册仅涵盖玻璃模块。 请提供 RK055HDMIPI4MA0 PCB 的机械图纸,格式为 DXF 或 PDF,或者提供 STEP 模型,图纸需包含以下内容: 1.PCB外形尺寸和厚度。 2. 安装孔相对于 PCB 边缘的位置、成品孔径、孔是否镀层以及推荐的螺钉或支架。 3. PCB 背面的 FPC 连接器:零件编号、位置、引脚 1 位置、触点侧以及电缆开口朝向。 4. 提供的 FPC 电缆:零件号、长度、触点类型、同侧或异侧。 5.PCB背面最高的元器件,以及任何禁入区域。 如果旧款 RK055HDMIPI4M PCB 在机械结构上有所不同,也请提供其图纸。 作为参考,以下是我目前为止的计算结果: - 在 MIMXRT1170-EVKB 布局中,LCD 安装孔 SS1 至 SS4 形成 147.253 x 72.905 毫米的图案,孔径为 3.53 毫米,并配有 16.1 毫米长的 M3 支架。 - 我测量了显示屏PCB的尺寸,大约为155 x 83.5毫米。 - 在 EVKB 上,显示器的连接器位于 J48 一侧约 8 毫米处,50 毫米长的电缆是能够应对这种偏移的最短电缆。我想把板上的两个连接器对齐。 感谢您的帮助。 NIC Re: Mechanical drawing request: RK055HDMIPI4MA0 display PCB outline, mounting holes and FPC connecto 嗨@nicnewdigate , 感谢您对恩智浦产品的关注。遗憾的是,该PCB的机械图纸并未公开,因此我们无法分享。由此给您带来的不便,我深表歉意,并感谢您的理解。
記事全体を表示
Mechanical drawing request: RK055HDMIPI4MA0 display PCB outline, mounting holes and FPC connector I am designing a custom i.MX RT1176 board, using the MIMXRT1170-EVKB Rev C3 as the reference design. It will use the RK055HDMIPI4MA0 5.5-inch MIPI DSI display kit, mounted directly on my board through the four mounting holes in the kit's PCB. My board outline and mounting holes therefore need to match that PCB. I could not find a mechanical drawing of this PCB. I have checked the RK055HDMIPI4MA0 product page, the MIMXRT1170-EVKB user guide and design files, and the Rocktech RK055MHD091A0-CTG panel datasheet, which only covers the glass module. Could you please send a mechanical drawing of the RK055HDMIPI4MA0 PCB, as DXF or PDF, or a STEP model, showing: 1. The PCB outline dimensions and thickness. 2. The mounting hole positions relative to the PCB edges, the finished hole diameter, whether the holes are plated, and the recommended screws or standoffs. 3. The FPC connector on the back of the PCB: part number, position, pin 1 location, contact side, and which way the cable opening faces. 4. The supplied FPC cable: part number, length, and contact type, same-side or opposite-side. 5. The tallest component on the back of the PCB, and any keep-out areas there. If the older RK055HDMIPI4M PCB differs mechanically, I would be grateful for its drawing too. For reference, here is what I have worked out so far: - In the MIMXRT1170-EVKB layout, the LCD mounting holes SS1 to SS4 form a 147.253 x 72.905 mm pattern of 3.53 mm plated holes, fitted with M3 standoffs 16.1 mm long. - I measured the display PCB at about 155 x 83.5 mm. - On the EVKB, the display's connector sits about 8 mm to one side of J48, and a 50 mm cable is the shortest that copes with the offset. I would like to line the two connectors up on my board. Thank you for your help. Nic Re: Mechanical drawing request: RK055HDMIPI4MA0 display PCB outline, mounting holes and FPC connecto Hi @nicnewdigate, Thank you for your interest on NXP products. Unfortunately, mechanical drawing of this PCB is not publicly available, so we’re unable to share it. I apologize for the inconvenience this may cause and appreciate your understanding.
記事全体を表示
FRDM-MCXW72: AN14889 Sensitivity test Hello, I am following the steps in the AN14889 to run sensitivity tests on  FRDM-MCXW72 but without success I use the following sequence to run the test on channel 0 (2402 MHz). Could you check it? Connectivity Test Interface short cuts ------------------------------------------ -Press [t] for Tx operation -Press [r] for Rx operation -Press [z] to increase mode (GENFSK, BLE) and rate -Press [x] to decrease mode (GENFSK, BLE) and rate -Press [c] to toggle between fixed or per channel whitening (for BLE only) -Press [q] for channel up -Press [w] for channel down -Press [a] for Power up -Press [s] for Power down -Press [n] to increase the Payload -Press [m] to decrease the Payload -Press [d] to increase the XTAL Trim value -Press [f] to decrease the XTAL Trim value These keys can be used all over the application to change the test parameters ________________________________ | | | Select the Test to perform | |________________________________| -Press [1] Continuous tests -Press [2] Packet Error Rate test -Press [3] Range test -Press [4] Adjust RTC XTAL -Press [5] Adjust PLL numerator offset -Press [!] Reset MCU Mode RX, Rate BLE 1Mbps, Whiten Chan, Channel 42, Power 8, Payload 6, XtalTrim 10> -------------------------------------------------------------- [t] Tx [z] Mode/Rate+ [c] Fix/Ch whit. [q] Ch+ [a] Pw+ [r] Rx [x] Mode/Rate- [w] Ch- [s] Pw- [n] Pyld+ [d] XtalTrim+ [m] Pyld- [f] XtalTrim- -------------------------------------------------------------- ______________________ | | | PER Rx Test Menu | |______________________| -Press [space bar] to start/stop Receiving Packets -Press any push button to stop Receiving Packets -Press [p] Previous Menu Mode RX, Rate BLE 1Mbps, Whiten Chan, Channel 42, Power 8, Payload 6, XtalTrim 10> PER Test Rx Running PER Test Rx Stopped Average Rssi during PER: 0 dBm Received 0 of 0 packets transmitted Press [ENTER] to go back to the Per Rx test menu I use a BLE tester to send the standard BLE test packets but the board doesn't receive any packet. The application note does not specify any setting for the sensitivity test. On the other hand if I use hci_bb application and standard HCI commands, the board gets stuck randomly at all PHY only when the tester sends the HCI_LE_RECEIVER_TEST or HCI_LE_ENHANCED_RECEIVER_TEST make it impossible to run the tests. The transmitter test command works flawlessly. Could you give me some advices? I am using SDK_26_06_00_FRDM-MCXW72. Thanks, Marco Development Board Re: FRDM-MCXW72: AN14889 Sensitivity test Hello, hope you are doing well. Some features of the Connectivity Test Application like Packet Error Rate or Range Tests require the usage of two devices.  One of the platforms must be set in RX mode (by pressing “r”) and the other in TX (by pressing “t”). Could you please try the PER test with a board to board scenario? One board as the Tx and the other as Rx. This to first validate the Connectivity Test application in a controlled environment , and to identify if the configuration of the Rx was correct. You can find more information on steps and packet configuration to perform the PER test here: Steps to perform a PER test | Connectivity Test CLI — MCUXpresso SDK Documentation The RF test flow described in AN14889 does not specify a custom packet or frame format for the sensitivity test, but instead relies on the standard Bluetooth Low Energy specifications. BLE RF PHY tests, including sensitivity and PER measurements, can also be performed using Direct Test Mode (DTM), which is defined in the Bluetooth Core Specification, Vol. 6, Part F. This section defines the LE Test packets and the standardized test procedures used for RF validation. The underlying packet structure itself (preamble, access address, PDU, CRC) is defined in the Bluetooth Core Specification, Vol. 6, Part B. The LE Test packets used in DTM follow this same structure, with controlled payload patterns and parameters for testing. The specific test conditions and limits for measurements such as sensitivity and PER are also defined in the Bluetooth RF-PHY Test Suite. Best Regards, Sofia.
記事全体を表示
Selftest in s32k312 Hello NXP Team, I am working with the S32K312 SAR ADC and I would like to understand the ADC self-test feature in more detail, especially Algorithm S, Algorithm C, and the RTD self-test API. I have gone through the S32K3 reference manual and available documentation, but I would like to understand what is actually happening inside the ADC hardware during these self-test algorithms. 1. Algorithm S – Supply Self-Test From the documentation, my understanding is that Algorithm S contains three steps and checks internal ADC-related voltages such as the bandgap/reference/supply voltages. Could you please explain in more detail what happens internally for each Algorithm S step? For example: What internal signal is connected to the SAR ADC during S0, S1 and S2? Which supply/reference is measured in each step? Does the ADC perform these tests using the same SAR conversion path used for normal ADC conversions? Is the sampling capacitor/CDAC also involved during Algorithm S? What exactly is compared against the Self-Test Analog Watchdog thresholds? Are the expected values/thresholds derived from factory calibration information? I would like to understand the complete signal path: Internal test voltage → sampling network → SAR/CDAC → comparator → conversion result → self-test watchdog comparison 2. Algorithm C – Capacitive Self-Test I am particularly interested in understanding Algorithm C. The documentation mentions that Algorithm C contains multiple steps (C0–C11) and performs a capacitive self-test. Could you please explain what the ADC hardware is actually doing during these steps? My current understanding is that the SAR ADC contains a capacitive DAC/CDAC and Algorithm C internally exercises different capacitor combinations in order to detect errors in the sampling/conversion capacitor network. Is this understanding correct? More specifically: What is being changed between C0, C1, C2 … C11? Are individual capacitors or groups of binary-weighted capacitors being switched/tested? Is an external analog input used during Algorithm C, or is the test completely internal? What voltage/charge is applied to the capacitor network? What does the ADC result returned for each Algorithm C step physically represent? Documentation mentions an "offset/error" compared with a previously calibrated value. Where is this calibrated reference value stored? How is the expected result determined? Why is an ideal Algorithm C result expected to be approximately zero? What type of hardware faults can Algorithm C detect? For example: capacitor mismatch, open/shorted capacitor, switch failure, leakage, comparator error, charge redistribution error. If possible, could you provide a simplified internal block-level explanation showing how the sampling capacitor/CDAC, comparator and SAR logic participate in Algorithm C? 3. Difference Between Normal Conversion and Algorithm C For a normal ADC conversion, I understand the operation approximately as: Input sampling → charge stored in sampling/CDAC network → SAR successive approximation → conversion result During Algorithm C, is the normal external input sampling phase replaced by an internally generated capacitor test condition? In other words, does Algorithm C mainly test the analog SAR conversion path itself, rather than measuring an external ADC channel? 4. RTD Self-Test API I am using the S32K3 RTD ADC driver and would also like to understand exactly what happens when the RTD self-test API is called, for example: Adc_Sar_Ip_SelfTest() Could you please explain the internal software sequence performed by this function? Could you please clarify which of these operations are actually performed by the RTD API and which operations must be configured by the application? I am particularly interested in knowing: Whether Algorithm S and Algorithm C run automatically as one hardware sequence after the API starts the self-test. Whether the RTD API itself evaluates the results or whether the ADC hardware analog watchdog performs the actual PASS/FAIL comparison. What return value/status from the RTD function indicates a failed self-test. 5. Self-Test Analog Watchdog Thresholds Could you also explain how the Self-Test Analog Watchdog thresholds are determined? Are the upper/lower threshold values: fixed values recommended by NXP, device-specific factory calibration values, generated by Tresos/RTD configuration, or values that the application developer must configure manually? For Algorithm C specifically, how are the allowed positive/negative error limits determined for each C0–C11 step? 6. Self-Test Timing Finally, I would like to understand the timing of the complete self-test. If Algorithm S contains 3 steps and Algorithm C contains 12 steps: S0 → S1 → S2 → C0 → C1 → ... → C11 does each step internally perform a complete ADC operation consisting of something similar to: pre-sampling + sampling + SAR conversion + evaluation/watchdog comparison? If so, is there any documentation or formula that can be used to calculate the expected execution time of: Algorithm S, Algorithm C, and the complete S+C self-test? My main goal is to understand the hardware operation of the S32K312 SAR ADC self-test, rather than only how to call the RTD function. If possible, please point me to any S32K3-specific application note, detailed ADC self-test documentation, or RTD source/documentation that explains these sequences. Thank you. Re: Selftest in s32k312 Hello, I have gone through the S32K3 reference manual and available documentation, but I would like to understand what is actually happening inside the ADC hardware during these self-test algorithms. For such purpose I have wrote application note in ST which explains it to the details. The test are the same as S32K inhered the module from MPC56xx devices. Most of your questions are answered in it, however it is not to be found publicly. I can share it via ticket if you rise one on NXP.com I will not explain on public community how in the details the self test work. Basic answers are: What internal signal is connected to the SAR ADC during S0, S1 and S2? ADC internal bandgap voltage (S0 - step0) – (Vbandgap / Vref) ADC supply voltage (S1 - step1) – (VDDA / Vbandgap) ADC reference voltage (S2 - step2) – (Vref' / Vref) What is being changed between C0, C1, C2 … C11? Capacitive Self-test Algorithm C includes a sequence of 11 (or varius) test conversions (steps) by setting the capacitive elements comprising the sampling capacitor/ capacitive DAC. This algorithm is designed to highlight faults in the sampling capacitor matrix. Each step considers two elements of the sampling capacitor matrix. For each step a sequence of pre-sampling, sampling and evaluation phases are executed. Best regards, Peter
記事全体を表示
S32k342:Bctudmabuffer 未更新数据。 你好, 我已经为具有 10 个通道的 ADC0 配置了 PIT、BCTU、DMA(通道 6)。 已检查寄存器值 LISTCHR 和 FIFO1DR,MSR:(十进制) MSR:32768 TRGCFG[23] :268477184 MCR:67305600 FIFO1DR:781516942 LISTCHR[0] : 2162725 LISTCHR[1] : 65576 LISTCHR[2] : 6 LISTCHR[3] : 327687 LISTCHR[4] : 2147909636 FIFCR:16777216 FIFOERR:151060480 FIF0SR:0 FIFOCNTR:15 已参考示例代码(https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-PIT-BTCU-parallel-ADC-FIFO-DMA-DS3-...)配置了用于自动 SAR MCAL 的 DMA 通道 6。 问题是:我没有收到 DMA 水印通知和 bctudma 缓冲区的数据。 请问还缺少什么?请指正。 谢谢 Re: S32k342: Bctudmabuffer is not updating with data. 我正在使用AUTOSAR MCAL。 传输配置是否也需要配置? 需要调用传输 API .? Mcl_SetDmaChannelTransferList 和 Mcl_SetDmaChannelCommand,并使用 MCL_DMA_CH_START_REQUEST。 Re: S32k342: Bctudmabuffer is not updating with data. 目前我正在使用路径,并且已经为此共享了配置: PIT_CH0 → TRGMUX → BCTU_Trg23 → ADC0/Adc1 → DMA 请允许我这样做。 我最终将使用的路径: PIT_CH0 - TRGMUX - BCTU_Trg23 ADC0(5通道) - FIFO1 - eDMA PIT_CH1 - TRGMUX - BCTU_Trg47 - ADC1(5通道) - FIFO2 - eDMA 请告知我相关的配置信息。 Re: S32k342: Bctudmabuffer is not updating with data. 我使用的是 RTD 3.0.0 版本。 Re: S32k342: Bctudmabuffer is not updating with data. Bctu 配置: ADC: DMA: 同时,BCT、PIT、EDMA、DMAMUX_0 的外设时钟也已启用。 Re: S32k342: Bctudmabuffer is not updating with data. 您好, 谢谢你提供的详细信息。 单从寄存器值很难确定缺少什么。由于 ADC 转换似乎已到达 BCTU FIFO,因此该问题可能与 BCTU→DMA 请求路径、DMA 通道配置或 DMAMUX 设置有关。 请您提供以下任一信息: 一个能够重现该问题的简化测试项目,或者 以下是您的 S32 配置工具设置的屏幕截图: ADC BCTU DMA/eDMA DMAMUX PIT 另外,请与我们联系您使用的RTD版本。 通过配置或简化项目,我们可以将其与工作示例进行比较,从而更高效地识别任何缺失或不正确的设置。 BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 您好, 无需传输配置及其对应的代码。传输配置在驱动程序中完成。 您是否已通过 Rm 元器件配置并初始化了 DMAMUX?你应该有类似这样的东西…… 已选择所需频道。然后在代码中调用 Rm init #include "CDD_Rm.h" /* 通过 HLD RM 驱动程序初始化 DMAMUX */ Rm_Init(&Rm_Config); BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 是的,我正在做。 同时执行 Rm_Init Re: S32k342: Bctudmabuffer is not updating with data. 您好, 谢谢你提供的详细信息。 根据目前掌握的信息,很难确定根本原因。单凭寄存器转储不足以确定问题是出在 BCTU、DMA、DMAMUX 还是软件配置中。 还有几项需要核实: DMA中断是否已启用且配置正确? 您使用的是ADC BCTU控制模式还是触发信号模式? 请注意,DMA 水印通知仅在使用 BCTU 控制模式时可用。如果您使用的是触发模式,则不会收到 DMA 水印通知。 为了帮助我们分析问题,请您提供以下任一信息: 一个简化的独立组网 (SA)项目,用于重现该问题,或者 请提供所有相关的S32配置工具设置(ADC、BCTU、DMA/DMAMUX、PIT)的完整屏幕截图以及相关代码? 理想情况下,一个完整的简化项目将使我们能够更高效地审查配置并将其与工作参考示例进行比较。 BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 我之前已经分享过所有配置信息了。 ADC: 使用调用 API Adc_EnableCtuControlMode 对 Adc 0 和 1 启用控制模式。 是否还需要调用 Adc_CtuEnableHwTrigger?我还没有调用过这个函数。 Re: S32k342: Bctudmabuffer is not updating with data. 你好, 从提供的截图中,我没有发现明显的问题。 既然您分享了项目和使用的代码,让我创建一些代码来测试您预期的触发场景。 BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 请检查配置。 Re: S32k342: Bctudmabuffer is not updating with data. 好的,由于代码难以共享,请为 s32k342 创建一个测试项目。 谢谢。 Re: S32k342: Bctudmabuffer is not updating with data. 您好, 最后,我针对您预期的配置做了一个 ADC HLD 演示。 触发信号路径: PIT0_CH0 -> TRGMUX -> BCTU 触发信号 23 -> ADC0(5 通道) -> BCTU FIFO1 -> eDMA(通道 0) PIT1_CH1 -> TRGMUX -> BCTU 触发信号 47 -> ADC1(5 通道) -> BCTU FIFO2 -> eDMA(通道 16) 链接在此: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-FRDM-A-S32K344-PIT-ADC-BTCU-ControlMode-FIFO-DMA-HLD/ta-p/2420432 希望对您有所帮助。 BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 感谢, 我会核实确认。 Re: S32k342: Bctudmabuffer is not updating with data. 我查看了示例代码,但它无法正常运行。 Re: S32k342: Bctudmabuffer is not updating with data. 您好, 我看到数据已更新。 BR,彼得 Re: S32k342: Bctudmabuffer is not updating with data. 请问您能回复一下吗? Re: S32k342: Bctudmabuffer is not updating with data. 我配置了和你一样的通道,可以看到 BCTUDMA 缓冲区正在更新。 但我仍然不明白你是如何对齐 ADC0/1 通道的,以及为什么 ADC0 VREFL/H 数据与 ADC1 VREFL/H 通道不匹配。P0通道也一样吗?另外,有些通道是内部通道,不需要在端口上配置,但像P7和P0这样的外部通道为什么没有在端口上配置呢?我想配置我的频道(10),如何在BCTU上对齐它?另外,我是否也需要在端口上进行配置,因为您的配置中没有设置p7和p0? 为什么ADC0/1的所有通道都没有包含在ADC配置数组中?为什么每个ADC0/1只包含一个通道?
記事全体を表示
FRDM-MCXW72:AN14889 灵敏度测试 你好, 我正在按照 AN14889 中的步骤运行灵敏度测试 FRDM-MCXW72 ,但未成功 我使用以下序列在通道 0 (2402 MHz) 上运行测试。 你能帮忙查一下吗? 连接测试接口快捷方式 ------------------------------------------ -按 [t] 进行 Tx 操作 -按 [r] 进行 Rx 操作 -按 [z] 键可增加模式(GENFSK、BLE)和速率 -按 [x] 键降低模式(GENFSK、BLE)和速率 -按 [c] 键可在固定白化和单通道白化之间切换(仅适用于 BLE) 按 [q] 键向上切换频道 按 [w] 键向下切换频道 -按[a]键启动 按 [s] 键掉电 按 [n] 键增加有效载荷 按 [m] 键减少有效载荷 -按 [d] 键增加晶振调整值 -按 [f] 键可降低晶振调整值 这些按键可以在应用程序的各个角落用于更改 测试参数 ______________________________ __ | | | Select the Test to perform | |__ ______________________________| -按[1]连续测试 -按[2]进行丢包率测试 -按[3]进行范围测试 -按 [4] 调整 RTC 晶振 -按[5]调整PLL分子偏移 -按 [!] RESET MCU 模式 RX,速率 BLE 1Mbps,Whiten Chan,信道 42,功率 8,有效载荷 6,XtalTrim 10> -------------------------------------------------------------- [t] 发射 [z] 模式/速率+ [c] 固定/通道 wit。[q] Ch+ [a] Pw+ [r] 接收 [x] 模式/速率- [w] 通道- [s] 功率- [n] Pyld+ [d] XtalTrim+ [m] Pyld- [f] XtalTrim- -------------------------------------------------------------- ____________________ __ | | | PER Rx Test Menu | |__ ____________________| -按[空格键]开始/停止接收数据包 -按下任意按钮即可停止接收数据包 -按 [p] 上一菜单 模式 RX,速率 BLE 1Mbps,Whiten Chan,信道 42,功率 8,有效载荷 6,XtalTrim 10> PER 测试处方运行 PER 测试处方已停止 PER期间平均RSSI:0 dBm 已接收 0 个数据包(已发送 0 个数据包) 按 [ENTER] 键返回 Per Rx 测试菜单 我使用 BLE 测试仪发送标准 BLE 测试数据包,但板没有收到任何数据包。 该应用笔记没有对灵敏度测试做出任何设置。 另一方面,如果我使用 hci_bb 应用程序和标准 HCI 命令,则当测试仪发送 HCI_LE_RECEIVER_TEST 或 HCI_LE_ENHANCED_RECEIVER_TEST 时,板会随机卡在所有 PHY 上,导致无法运行测试。 发射器测试指令运行正常。 您能给我一些建议吗? 我使用的是 SDK_26_06_00_FRDM-MCXW72。 谢谢, 马可 开发板 Re: FRDM-MCXW72: AN14889 Sensitivity test 你好,希望你一切都好。 连接测试应用程序的某些功能,例如数据包错误率测试或范围测试,需要使用两台设备。其中一个平台必须设置为 RX 模式(通过 按下“r”),另一个在TX(按下“t”)。 请您尝试使用板对板场景进行 PER 测试吗?一块板用作发射机(Tx),另一块板用作接收机(Rx)。首先在受控环境中验证连接测试应用程序,并确定 Rx 的配置是否正确。 您可以在此处找到有关执行 PER 测试的步骤和数据包配置的更多信息:执行 PER 测试的步骤 | 连接测试 CLI — MCUXpresso SDK 文档 AN14889 中描述的 RF 测试流程没有为灵敏度测试指定自定义数据包或帧格式,而是依赖于标准的低功耗蓝牙规范。 BLE RF PHY 测试(包括灵敏度和 PER 测量)也可以使用直接测试模式 (DTM) 进行,该模式在蓝牙核心规范第 6 卷 F 部分中定义。本节定义了 LE 测试包和用于 RF 验证的标准化测试程序。 底层数据包结构(前导码、接入地址、PDU、CRC)在蓝牙核心规范第6卷B部分中定义。DTM中使用的LE测试数据包遵循相同的结构,但有效载荷模式和参数受到控制,用于测试。 蓝牙射频物理层测试套件中还定义了灵敏度和误码率等测量的具体测试条件和限值。 此致, 索菲亚。
記事全体を表示
RTD 7.0.0 で生成された設定ファイル名の問題 こんにちは、チームの皆さん、 機能群名SEHS2を付けましたが、この名前は生成されたファイル名に現れ、RTD 7.0.0とDS 3.6.4を使用しています。 以前の6.0.0ではそうではありませんでした。 Re: generated Config file name issue for RTD 7.0.0 こんにちは、ダニエルさん。 依然として同じ問題が発生しています。 BR Re: generated Config file name issue for RTD 7.0.0 こんにちは、 @sbidkar さん、 これはグローバル設定で変更可能です: BR、ダニエル Re: generated Config file name issue for RTD 7.0.0 これで合っているはずです。 Re: generated Config file name issue for RTD 7.0.0 解決しました。ありがとうございました。 BR
記事全体を表示
s32k312でのセルフテスト NXPチームの皆様、こんにちは。 私はS32K312 SAR ADCを使用しており、ADCの自己テスト機能、特にアルゴリズムS、アルゴリズムC、およびRTD自己テストAPIについてより詳しく理解したいと考えています。 S32K3のリファレンスマニュアルや利用可能なドキュメントは確認しましたが、これらの自己テストアルゴリズム中にADCハードウェア内で実際に何が起きているのかを理解したいです。 1. アルゴリズムS – 供給自己テスト ドキュメントによると、アルゴリズムSは3つのステップで構成されており、バンドギャップ/基準/供給電圧などの内部ADC関連電圧をチェックするようです。 各アルゴリズムSステップで内部で何が起こっているのか、もう少し詳しく説明していただけますか? 例: S0、S1、S2の間、SAR ADCに接続されている内部信号は何ですか? 各ステップで測定される供給/参照物質はどれですか? ADCは、通常のADC変換で使用されるのと同じSAR変換パスを使用してこれらのテストを実行しますか? アルゴリズムSの実行中に、サンプリングコンデンサ/CDACも関与しますか? Self-Test アナログ Watchdogの閾値と比べて具体的に何が比較されるのでしょうか? 期待値/閾値は、工場出荷時の校正情報に基づいて算出されたものですか? 信号経路全体を理解したいです。 内部テスト電圧→サンプリングネットワーク→SAR/CDAC→コンパレータ→変換結果→自己テスト監視犬比較 2. アルゴリズムC – 容量性自己診断 私は特にアルゴリズムCを理解することに興味があります。 ドキュメントには、アルゴリズムCが複数のステップ(C0–C11)を持ち、容量性の自己テストを行うと記載されています。 これらのステップでADCハードウェアが実際に何をしているのか説明していただけますか? 私の現在の理解では、SAR ADCには容量性DAC/CDACが内蔵されており、アルゴリズムCは内部的にさまざまなコンデンサの組み合わせを動作させることで、サンプリング/変換コンデンサネットワークのエラーを検出します。 この理解は正しいでしょうか? より具体的に言うと: C0、C1、C2…C11の間で何が変わっているのでしょうか? 個々のコンデンサや2進加重コンデンサのグループがスイッチング・テストされているのでしょうか? アルゴリズムCの際に外部アナログ入力が使われるのか、それともテストは完全に内部で行われるのか? コンデンサネットワークにはどのような電圧/電荷が印加されますか? アルゴリズムCの各ステップで返されるADCの結果は、物理的に何を表していますか? ドキュメントには、以前にキャリブレーションされた値と比較して「オフセット/誤差」があると記載されています。この校正済み基準値はどこに保存されていますか? 期待される結果はどのように決定されるのですか? 理想的なアルゴリズムCの結果がほぼゼロになると期待されるのはなぜですか? アルゴリズムCはどのようなハードウェア障害を検出できるのでしょうか?例えば: コンデンサの不一致、 コンデンサのオープン/ショート、 スイッチの故障、 漏れ、 比較器エラー、 電荷再分配エラー。 可能であれば、サンプリングコンデンサ/CDAC、コンパレータ、SARロジックがアルゴリズムCにどのように関与しているか、簡略化された内部ブロックレベルの説明を教えていただけますか? 3. 通常変換とアルゴリズムCの違い 通常のADC変換の場合、その動作はおおよそ次のようになると理解しています。 入力サンプリング → サンプリング/CDACネットワークに蓄積された電荷 → SAR逐次近似 → 変換結果 アルゴリズムCの実行中、通常の外部入力サンプリングフェーズは、内部で生成されるコンデンサテスト条件に置き換えられますか? 言い換えれば、アルゴリズムCは主に外部ADCチャネルを測定するのではなく、アナログSAR変換経路自体をテストしているのでしょうか? 4. RTDセルフテストAPI 私はS32K3のRTD ADCドライバーを使っており、RTDセルフテストAPIが呼び出されたときに正確に何が起こるのかも知りたいです。例えば: Adc_Sar_Ip_SelfTest() この関数が実行する内部ソフトウェアのシーケンスについて説明していただけますか? これらの操作のうち、どれが実際にRTD APIによって行われ、どの操作がアプリケーションによって設定されるのか、明確に教えていただけますか? 私が特に知りたいのは以下の点です。 APIが自己テストを開始した後、アルゴリズムSとアルゴリズムCが1つのハードウェアシーケンスとして自動的に実行されるかどうか。 RTD API自体が結果を評価するのか、ADCハードウェアのアナログウォッチドッグが実際のPASS/FAIL比較を行うのか。 RTD関数からの戻り値/ステータスのうち、自己診断テストの失敗を示すものはどれですか。 5. 自己テストアナログ監視犬閾値 自己テストのアナログ監視ドッグ閾値がどのように決定されるのかも説明していただけますか? 上限値/下限値は以下のとおりです。 NXPが推奨する固定値、 デバイス固有の工場出荷時校正値、 Tresos/RTD構成によって生成されました。 あるいは、アプリケーション開発者が手動で設定しなければならない値は? アルゴリズムCに関して具体的に、C0~C11の各ステップにおける許容される正負の誤差範囲はどのように決定されるのでしょうか? 6. セルフテストのタイミング 最後に、自己診断テスト全体の実施時期について教えていただきたいです。 アルゴリズムSが3ステップ、アルゴリズムCが12ステップの場合: S0 → S1 → S2 → C0 → C1 → ... → C11 各ステップは内部的に以下のような完全なADC演算を実行しますか? 事前サンプリング+サンプリング+SAR変換+評価/ウォッチドッグ比較? もしそうなら、以下の予想実行時間を計算するためのドキュメントや数式はありますか? アルゴリズムS、 アルゴリズムC、 そして、S+Cの完全な自己診断テストは? 私の主な目標は、RTD関数を呼び出す方法だけでなく、S32K312 SAR ADCのセルフテストのハードウェア動作を理解することです。 可能であれば、S32K3専用のアプリケーションノート、詳細なADC自己テストドキュメント、またはRTDのソースやドキュメントでこれらのシーケンスを説明していただければ教えてください。 よろしくお願いします。 Re: Selftest in s32k312 こんにちは、 S32K3のリファレンスマニュアルや利用可能なドキュメントは確認しましたが、これらの自己テストアルゴリズム中にADCハードウェア内で実際に何が起きているのかを理解したいです。 そのために、詳細を説明したアプリケーションノートをSTで作成しました。テスト結果は、S32KがMPC56xxデバイスからモジュールを引き継いだのと同じです。 あなたの質問のほとんどはそこに回答されていますが、一般には公開されていません。もし NXP.com で1つ上がったらチケットで共有できます 自己診断テストの仕組みを詳細に説明するつもりはありません。 基本的な答えは次のとおりです。 S0、S1、S2の間、SAR ADCに接続されている内部信号は何ですか? ADC内部バンドギャップ電圧(S0 - step0)-(Vbandgap / Vref) ADC電源電圧(S1 - ステップ1)-(VDDA / Vbandgap) ADC基準電圧(S2 - ステップ2) – (Vref' / Vref) C0、C1、C2…C11の間で何が変わっているのでしょうか? 容量性自己テストアルゴリズムCは、11(または可変)のテスト変換(ステップ)のシーケンスを含み、 サンプリングコンデンサ/容量性DACを構成する容量性素子。このアルゴリズムは次のようになります。 サンプリングコンデンサマトリックスの欠陥を強調するために設計されています。各ステップは2つの要素を考慮します サンプリングコンデンサマトリックスの。各ステップでは、事前サンプリング、サンプリング、および 評価段階が実行されます。 よろしくお願いいたします。 ピーター
記事全体を表示
RTD 7.0.0 生成的配置文件名称问题 各位团队成员,大家好! 我已将功能组命名为 SEHS2,该名称出现在生成的文件名中,我正在使用 RTD 7.0.0 和 DS 3.6.4。 此前在 6.0.0 版本中并非如此。 Re: generated Config file name issue for RTD 7.0.0 问题已解决,谢谢。 BR Re: generated Config file name issue for RTD 7.0.0 你好,丹尼尔, 问题依旧存在。 BR Re: generated Config file name issue for RTD 7.0.0 应该就是这样了: Re: generated Config file name issue for RTD 7.0.0 你好@sbidkar , 这可以在全局设置中更改: BR,丹尼尔
記事全体を表示
分かりにくいデータシートNAFE33352 良い一日、 私の任務は、将来的にNAFE33352を使用する可能性を考慮して、その特性を評価し、テストすることですが、以下のデータシートに記載されている情報の一部が理解しにくく、見つけるのに苦労しています。https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf これまで、最も重要な機能にざっと目を通しただけで、以下のような問題点/疑問点がいくつか浮かびました(順不同)。 a) 7.6.3HV入力: シングルエンドアナログ測定の場合、データシートにはLVMUXを次のように構成すると書かれています: HV入力ポジティブ:AI1P、Isense HV入力ポジティブ:AI1N、Vsense 表12にはその構成が見つかりません。少し空想的に考えれば、最初のものは00010/bで、VsenseがVSNSだと仮定すると考えられます。しかし、2番目の組み合わせは存在しないようだ。たとえ存在したとしても、3つのSENSEピンをGNDに結びつければいいのでしょうか? AI1PとAI1NをGNDと比べて、他にどのように測定できますか?私のアプリケーションにはシングルエンドチャネルが2つ必要です。 b) 7.6.6低電圧多重化器へのアナログ入力(LV_MUX) 表12、VCMとは何ですか?図1に示すMUXのCOM入力は?COMは、差動PGAのコモンモード出力レベルのことですか?COMをシングルエンドの測定基準として使えますか? c) 5 ブロック図 なぜ1つのマルチプレクサに2つのLS入力があるのですか?また、それは何を意味するのですか?DACとVSENSEのAMPの出力はどのようにコネクテッドできますか? d) 7.5.8電圧源の極性切り替え(交流励起) VIEX_CHOPに何が起こったのですか?このセクションでは2回しか言及されていませんが、どこにあるのか、どのレジスタに設定すればよいのかは一切説明されていません。 e) 7.14 CMD_MM、マルチチャネルマルチリーディングコマンド それぞれのレジスタはどう設定すればいいですか?どのチャンネルから選べますか?このチップは2チャネルADCだけ搭載していないのでしょうか?このセクションで言及されているCH_CONFIGxレジスターはどこで見つけられますか? また、表20にはDATA0...最大8チャネルのDATA7についても記載されていますが、これ以上の情報はありません。これは何を意味するのでしょうか?表12の組み合わせはチャネルと見なされますか? 私が探している情報がデータシートのどこかにある可能性もありますが、たとえそうであっても、隠し方が多かったり、異なる用語や略語が使われているため、さらに混乱し、見つけにくくなります。 このICを使いたいなら、できるだけ早く評価ボードを注文する必要がありますが、未解決の疑問が多く、チップでできることが可能かどうかも分からないのでできません。要するに、アナログ入力が1つ、アナログ入力チャネルが2つ独立しています。 近いうちにご連絡いただけることを楽しみにしています。よろしくお願いします、 ルーカス SPI Re: Confusing datasheet NAFE33352 こんにちは、 a) AI1PとAI1Nは独立した単端入力(IN_SEL = 00100および00101)として使用可能です。外部信号の戻り線をAGNDに接続します。同じADCを共有しているので、測定は順番です。有効な設定は以下のとおりです。 b) VCMとCOMは内部信号であり、外部基準ピンではありません。シングルエンド測定の場合は、信号リターンをAGNDに接続してください。 c) 2つのLSブロックは、正および負のMUXパス用の内部レベルシフターです。これらは追加の外部入力を表すものではありません。 d) 極性チョッピング機能は、AI_CONFIG2 (0x22) の AIO_CHOP[7:6] で設定されます。2つの平均化されたADC読み取り値を使用してDACの極性チョッピングを行うには、AIO_CHOP = 11b に設定します。 e) デバイスは同じADCを共有する8つの論理チャネル(CH0–CH7)をサポートしています。各論理チャネルは独自の入力およびADC構成を持ち、AI_MULTI_CH_ENで有効化され、対応するAI_DATA0–AI_DATA7の結果レジスタを持ちます。 お役に立てば幸いです!
記事全体を表示
Confusing datasheet NAFE33352 Good day, my task is to characterize and test the NAFE33352 for potential later use, but have difficulty following or locating some information in the following datasheet. https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf Until now, after just glancing over the most important functionalities, I have the following problems/questions in no specific order: a) 7.6.3 HV Input: For single-ended analog measurements the datasheet says to configure the LVMUX like this: HV input positive: AI1P, Isense HV input positive: AI1N, Vsense I can't find those configurations in Table 12. With a bit of fantasy, the first could be 00010/b, assuming Vsense is VSNS. But the second combination doesn't seem to exist. Even if they existed, do I just have to tie the three SENSE pins down to GND? How else can I measure AI1P and AI1N vs GND? I need two single-ended channels for my application. b) 7.6.6 Analog inputs to low-voltage multiplexer (LV_MUX) Table 12, what is VCM? The COM input of the MUX seen in Figure 1? Is the COM the common mode output level for the differential PGAs? Can I use COM as reference for my single-ended measurements? c) 5 Block diagram Why are there 2 LS inputs per MUX and what do the mean? How can the outputs of the AMPs of DAC and VSENSE be connected together? d) 7.5.8 Voltage sources polarity switching (AC excitation) What happened to VIEX_CHOP? It's only mentioned twice in this section but never where to find it and in which register to set it. e) 7.14 CMD_MM, multichannel multireading command How do I configure the respective registers, which channels can I choose from? Does this chip not only have a 2-channel ADC? Where can I find the CH_CONFIGx registers that are mentioned in the section? Also Table 20 mentions DATA0...DATA7 for up to 8 channels but no more information what this means? Are the combinations of Table 12 considered channels? It may be that some information I'm looking for is somewhere in the datasheet, but even if that is the case, it is well hidden or a different terminology/abbreviation is used, which makes it even more confusing and hard to find. If I want to use this IC, I would need to order an eval-board as soon as possible, but I can't with so many open questions and not knowing if it's even possible to do what I try to do with the chip. In a nutshell, one analog input and 2 independent analog input channels. Hoping to hear from you soon. Best regards, Lukas SPI Re: Confusing datasheet NAFE33352 Hello, a) AI1P and AI1N can be used as two independent single-ended inputs (IN_SEL = 00100 and 00101). Connect the external signal return to AGND. They share the same ADC, so measurements are sequential. The valid configurations are: b)VCM and COM are internal signals, not external reference pins. For single-ended measurements, connect the signal return to AGND. c)The two LS blocks are internal level shifters for the positive and negative MUX paths. They do not represent additional external inputs. d) The polarity-chopping function is configured through AIO_CHOP[7:6] in AI_CONFIG2 (0x22). Set AIO_CHOP = 11b for DAC polarity chopping with two averaged ADC readings. e) The device supports 8 logical channels (CH0–CH7) sharing the same ADC. Each logical channel can have its own input and ADC configuration, is enabled through AI_MULTI_CH_EN, and has a corresponding AI_DATA0–AI_DATA7 result register. Hope this helps!
記事全体を表示
NAFE33352 数据手册令人困惑 再会, 我的任务是表征和测试 NAFE33352,以便将来可能使用,但在以下数据表中,我很难理解或找到某些信息。https://www.nxp.com/docs/en/data-sheet/NAFE33352.pdf 到目前为止,在粗略浏览了最重要的功能之后,我还有以下问题/疑问,排名不分先后: a) 7.6.3高压输入: 对于单端模拟测量,数据手册中指出 LVMUX 的配置方式如下: 高压输入正极:AI1P、Isense 高压输入正极:AI1N、Vsense 我在表 12 中找不到这些配置。稍加想象,第一个可能是 00010/b,假设 Vsense 是 VSNS。但第二种组合似乎并不存在。即使它们存在,我是否只需要将三个感知引脚接地即可? 除了以上方法,我还能如何测量 AI1P 和 AI1N 与 GND 的关系?我的应用需要两个单端通道。 b) 7.6.6低压多路复用器 (LV_MUX) 的模拟输入 表 12,VCM 是什么?图 1 中所示的 MUX 的 COM 输入是什么?COM 是差分 PGA 的共模输出电平吗?我可以将 COM 用作单端测量的参考吗? c) 5 方框图 为什么每个多路复用器有 2 个 LS 输入,它们分别代表什么?如何将 DAC 和 VSENSE 的 AMP 输出端连接在一起? d) 7.5.8电压源极性切换(交流激励) VIEX_CHOP 发生了什么事?本节中只提到了两次,但从未说明在哪里可以找到它,以及应该在哪个寄存器中设置它。 e) 7.14 CMD_MM,多通道多读命令 我该如何配置各个寄存器?我可以从中选择哪些通道?这款芯片不仅有双通道ADC吗?我可以在哪里找到本节中提到的 CH_CONFIGx 寄存器? 表 20 中提到了 DATA0...DATA7,最多可表示 8 个通道,但没有提供更多信息说明其含义?表 12 中的组合是否被视为通道? 或许我要找的信息就在数据手册的某个地方,但即使是这样,它也隐藏得很深,或者使用了不同的术语/缩写,这使得查找起来更加令人困惑和困难。 如果我想使用这款集成电路,我需要尽快订购一块评估板,但由于还有太多疑问,而且我也不知道是否能够用这款芯片实现我想要的功能,所以我无法订购。简而言之,就是一个模拟输入和两个独立的模拟输入通道。 希望能尽快收到您的回复。此致, 卢卡斯 SPI Re: Confusing datasheet NAFE33352 你好, a) AI1P 和 AI1N 可用作两个独立的单端输入(IN_SEL = 00100 和 00101)。将外部信号返回端连接到 AGND。它们共用同一个模数转换器(ADC),因此测量是顺序进行的。有效的配置如下: b)VCM 和 COM 是内部信号,不是外部参考引脚。对于单端测量,将信号返回端连接到 AGND。 c)这两个LS模块是正负MUX路径的内部电平转换器。它们不代表额外的外部输入。 d) 极性斩波功能通过 AI_CONFIG2 (0x22) 中的 AIO_CHOP[7:6] 进行配置。设置 AIO_CHOP = 11b 以使用两个平均 ADC 读数进行 DAC 极性斩波。 e) 该设备支持 8 个逻辑通道(CH0–CH7),共享同一个 ADC。每个逻辑通道都可以有自己的输入和 ADC 配置,通过 AI_MULTI_CH_EN 启用,并具有相应的 AI_DATA0–AI_DATA7 结果寄存器。 希望这能帮到你!
記事全体を表示
i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12.23 Title: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12.23 Hello NXP Team, I am debugging WiFi initialization on the following setup: Board: NXP i.MX95 19x19 EVK WiFi module: u-blox JODY-W263-00B Android build: AOSP 15 (Android property verification pending) Running kernel: 6.12.23-android16-5-maybe-dirty-4k Exact NXP Android BSP release/tag: not yet confirmed WiFi driver: mlan/moal (MWLAN) Selected firmware: sduart8987_combo.bin SDIO device: mmc2:0001:1 Running kernel information: The SDIO device is detected, and the driver reports “FW download over”. However, the firmware does not become active within the timeout, and the WiFi SDIO probe fails. Relevant boo$ adb shell uname -a Linux localhost 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT Thu Jan 1 00:00:00 UTC 1970 aarch64 Toybox t logs: [ 10.845985] mlan: loading out-of-tree module taints kernel. [ 10.961712] wlan: Loading MWLAN driver [ 10.973277] wlan: Register to Bus Driver... [ 11.016613] Attach moal handle ops, card interface type: 0x105 [ 11.070275] sta_name=wlan [ 11.086277] uap_name=wlan [ 11.086294] fw_name=sduart8987_combo.bin [ 11.168031] Enable moal_recv_amsdu_packet [ 11.168086] Attach mlan adapter operations.card_type is 0x105. [ 11.257673] wlan: Enable TX SG mode [ 11.257679] wlan: mpa_tx.buf_size=65280 [ 11.257682] wlan: Enable RX SG mode [ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156 [ 17.279039] FW failed to be active in time! [ 17.286246] wlan_dnld_fw fail ret=0xffffffff [ 17.296825] WLAN: Fail download FW with nowwait: 0 [ 17.502477] woal_request_fw failed [ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 [ 17.547534] wlan: Register to Bus Driver Done [ 17.553159] wlan: Driver loaded successfully After unloading and reloading the driver, I also observed: [ 4051.080660] fw_name=sduart8987_combo.bin [ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0 [ 4056.079262] FW failed to be active in time! [ 4056.084697] wlan_dnld_fw fail ret=0xffffffff [ 4056.089909] WLAN: Fail download FW with nowwait: 0 [ 4056.250548] woal_request_fw failed [ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 I found this related community discussion: https://community.nxp.com/t5/Wi-Fi-Bluetooth-802-15-4/88W8801-LILY-W131-WiFI-SDIO-chip-not-responding-after-FW/m-p/1986943 The discussion concerns 88W8801 on Nvidia AGX Orin, so it is a different module/platform. The author reported improvement after removing no-sd and changing bus-width from 4 to 1, followed by successful operation with the original configuration. I have not yet tested these changes on my board. Could you please help clarify: Is sduart8987_combo.bin the correct firmware for JODY-W263-00B? Which firmware release and mlan/moal driver revision are recommended for this Android/kernel combination? What are the recommended SDIO device-tree settings for this module on the i.MX95 19x19 EVK, particularly bus width, maximum frequency, pinctrl, power supplies, reset GPIO, and power-sequence delays? Would testing bus-width = <1> or a lower SDIO clock help diagnose this timeout? Is removing no-sd relevant or recommended for this platform? What could cause the firmware activation timeout after the driver reports firmware download completion? Does downloaded 0 after driver reload indicate that a full module power cycle or hardware reset is needed before retrying? Are there known issues or required patches for this board/module/kernel combination? Which additional debug settings, SDIO register dumps, or logs should I collect to distinguish firmware/driver compatibility issues from SDIO communication or power/reset sequencing issues? I can provide the full boot log, relevant device-tree nodes, wifi_mod_para.conf, and exact BSP/driver revisions once confirmed. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hello NXP Team, We have collected further diagnostic evidence for the firmware activation timeout on i.MX95 19x19 EVK with JODY-W263-00B. Hardware mode verification Both register reads succeed: WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0 WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0 WIFI_DIAG: magic=0x24 strap=0x0 WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selection The masked strap indicates SD-UART mode according to our driver source, consistent with the configured firmware name. Download-loop exit confirmed WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100 WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16 Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! The requested-length registers remain zero throughout 100 polling attempts, causing the download loop to exit. Firmware binary inspection Using the source’s 16-byte FWHeader layout and command-length rules, offline parsing identifies a CMD4 record at offset 619140, ending at 619156—exactly matching the download counter. The source defines CMD4 as FW_HAS_LAST_BLOCK. There are 9044 bytes after this record. We have not established their purpose or confirmed that these parsing rules fully describe the SDIO bootloader format. We therefore do not consider the counter difference alone proof of an incomplete download. Additional details: MOAL/MLAN version: 537.p9 Embedded firmware string: w8987o-V0, RF878X, FP92, 16.92.21.p151.4 Firmware size: 628200 bytes SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 Actual 1-bit SDIO operation was previously verified at 50 MHz, with the same timeout. The latest diagnostic test runs at 4-bit, 50 MHz. Expected firmware READY status is 0xfedc; observed status remains 0xf005. No Wi-Fi network interface is created. Exact NXP BSP release/tag is still being confirmed. Could you please clarify: Is stopping at the CMD4 boundary, offset 619156, expected for this specific image? What is the purpose of the remaining 9044 bytes? What does 0xf005 indicate during SD8987 firmware activation? Is firmware containing version string 16.92.21.p151.4 supported with driver 537.p9 for JODY-W263-00B? Which BSP and firmware/driver package should we use? Which module power/reset timing, supply and reference-clock checks are recommended for this failure? Which additional registers or diagnostics would distinguish a firmware startup failure from a communication or hardware initialization issue? The firmware binary remains unchanged. Our source modifications add diagnostic logging, and full boot logs and source diffs are available. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 One important clarification about the failure stage: The processor detects the SD8987 Wi-Fi device over SDIO, and the firmware download routine reports “FW download over”. However, during the subsequent activation check, the driver expects SDIO_FIRMWARE_READY = 0xfedc, while the reported status is 0xf005. Firmware initialization and the SDIO probe therefore fail, and no Wi-Fi network interface is created. This remains unchanged after verifying actual 1-bit SDIO operation at 50 MHz. Could you please explain what 0xf005 indicates for SD8987 at this stage and which additional register values or logs would help identify why the firmware does not reach READY status? Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hello NXP Team, Following up on my original report, we have completed additional checks and a controlled SDIO bus-width experiment. Wi-Fi initialization still fails at the firmware activation stage. 1. Confirmed device and software details Board/module: i.MX95 19x19 EVK with JODY-W263-00B Android fingerprint: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys Kernel: 6.12.23-android16-5-maybe-dirty-4k Exact NXP BSP release/tag: still being confirmed SDIO device: mmc2:0001:1 SDIO ID: 02DF:9149, mapped to SD8987 in the driver source Host controller: USDHC3, mmc@428b0000 Both moal and mlan report version 537.p9 MOAL srcversion: 358C14898F4DDF4EB40AB03 Source repository revisions: nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad imx-firmware: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b Both commits have the subject “MA-23689-1 [Android-15]WCS Q2 release patch integrate”. Mapping these source revisions to the installed module build is still being verified. 2. Firmware identity verified The selected firmware is /vendor/firmware/sduart8987_combo.bin, size 628200 bytes. The source copy and installed board copy have the same SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 This confirms that the copies match; firmware compatibility with the module still needs confirmation. 3. Actual 1-bit SDIO test completed Initially, the live Device Tree reported bus-width = <1>, but /sys/kernel/debug/mmc2/ios still showed 4-bit operation. In our source, mmc_of_parse() does not clear an existing 4-bit capability for bus-width = <1>, while generic SDHCI setup adds MMC_CAP_4_BIT_DATA unless SDHCI_QUIRK_FORCE_1_BIT_DATA is set. We therefore added a diagnostic block in sdhci-esdhc-imx.c, immediately after the mmc_of_parse() error check: { u32 bus_width; if (!of_property_read_u32(np, "bus-width", &bus_width) && bus_width == 1) { host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA; host->mmc->caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA); } } After rebuilding and deploying the modified kernel and DT configuration, we verified: Live DT bus-width: 00 00 00 01 clock: 50000000 Hz bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) However, the same failure remained: Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 No Wi-Fi network interface appears. The configured maximum frequency is 100 MHz, but actual operation remained at 50 MHz. We have therefore not completed a lower-clock test. Also, no-sd was absent from the reviewed USDHC3 configuration, so no removal was performed. 4. WLAN-only firmware reload test We temporarily bind-mounted sd8987_wlan.bin over the configured firmware path and reloaded MOAL. The driver read the alternative file size, but reported: firmwarelen=416836 downloaded 0 firmwarestat=0xf005 FW failed to be active in time! Because this was a reload after an earlier failed initialization, we consider the result inconclusive. It does not establish WLAN-only firmware compatibility or successful transfer. A reboot removed the temporary bind mount, and the original 628200-byte combo firmware was verified again. 5. Current investigation We are preparing diagnostic logging in moal_sdio_mmc.c to capture: Raw chip magic and host strap register values. Return status of both register reads. Masked magic and strap values. The source defines CHIP_MAGIC_VALUE = 0x24 and CARD_TYPE_SD_UART = 0. The existing boot log did not expose these values. This logging change has not yet been deployed. The exact meaning of firmwarestat=0xf005 and the repeated 9044-byte difference between firmware size and download counter remain unresolved. We are not treating the completion message as proof that firmware is active. Could you please advise on the following? Is this firmware/driver package appropriate for JODY-W263-00B on this BSP/kernel? How can we identify the exact firmware release from the binary or package? Is downloaded 619156 for a 628200-byte combo image expected for this firmware format, or does it indicate premature termination? What does firmware status 0xf005 mean for SD8987 during initialization? Is the diagnostic host-driver change above appropriate for enforcing a 1-bit test, or is there a preferred BSP mechanism? Which registers/logging should we collect to verify strap-based firmware selection, and does an explicit fw_name override that selection? What power/reset sequence is required before retrying after this failure? Would you recommend a lower-clock test or another targeted experiment next? We can provide the full boot logs, DT/overlay changes, host-driver diff, and wifi_mod_para.conf. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Dear @Rakesh_Kumar-Thakur , Thanks for your Inquiry. I saw you are using uSDHC3 interface for your WiFi module,  i.MX95-EVK supports the uSDHC3 on M.2 KEY E connector, so I assume you are using M.2 WiFi module, JODY-W263-00B based on 88W8987. We need to clarify the following steps when enabling SDIO WiFi on M.2 KEY E connector. -- uSDHC3 IO level is determined by NVCC_WAKEUP NVCC_WAKEUP is 1.8V (from VDD_1V8_S). --M.2 Power,VCC_KE_3V3 is disabled by default The power is generated by NX5P2924DUK, M2_KE_PWREN is controlling it's enablement. 3. What software will do (1) Adding uSDHC3 node to imx95-19x19-evk.dts There is no uSDHC3 node by default, it should be added manually. [Note] You can refer to imx95-15x15-evk.dts's usdhc3 code to add it. please pay attention to different GPIOs. --Enabling power GPIO --Pull up W_DISABLE1# and W_DISABLE2 pins of M.2 --SDIO_WAKE# & SDIO_RST# pins (3)Android 15 SDIO WiFi Power Enablement Check haredBoardConfig.mk files for i.MX95 and confirm if pwrseq_simple.ko has been supported, if not , add it, please.  maybe like below: ...... $(KERNEL_OUT)/net/wireless/cfg80211.ko \ $(KERNEL_OUT)/drivers/mmc/core/pwrseq_simple.ko \ ...... (3) Enabling imx95-19x19_gki.fragment (Maybe different name, confirm it , please.) ...... CONFIG_PWRSEQ_SIMPLE=m ...... (4) Disabling pcie1 node (in imx95-19x19-evk.dts) ...... &pcie1 { pinctrl-0 = <&pinctrl_pcie1>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_slot_pwr>; status = "disabled"; }; ...... (5) BoardConfig.mk can support 8987 directly You can change default WiFi firmware files' name to 88W8987's. OK, try it, please. Thanks, Regards, Weidong Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, Thank you for your guidance. I tested the following configuration updates, but firmware initialization still fails: Disabled pcie1 in imx95-19x19-evk.dts. The existing uSDHC3 configuration was retained. Updated the Wi-Fi configuration labels and module-parameter filename in BoardConfig.mk and SharedBoardConfig.mk. Updated the firmware configuration destination name in evk_95.mk. Found CONFIG_PWRSEQ_SIMPLE=m already present in the kernel fragments. Runtime loading of pwrseq_simple.ko and the DTS power-sequence connection still need verification. The latest boot uses: moal.mod_para=wifi_mod_para_sd8987.conf The module is reported as JODY-W263-00B, based on NXP 88W8987, and the Wi-Fi driver version is 537.p9. Current firmware: Path: /vendor/firmware/sduart8987_combo.bin Size: 628200 bytes SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34 Boot logs: SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 Previously, I also tested a replacement firmware from branch lf-6.18.20_2.0.0: Size: 644352 bytes SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 Its deployed hash was verified, but it produced the same firmwarestat=0xf005 activation failure. Could you please provide or point me to a validated sduart8987_combo.bin for JODY-W263-00B / 88W8987 compatible with driver 537.p9? Please include the firmware version, repository commit/tag, SHA-256 and recommended module parameters. If another driver release is required, please specify the matching driver–firmware pair. For reference, our source revisions are: Driver: 9630752ea1d9e28d9956adf27c652f40399e85ad Original firmware repository: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b Please also advise what 0xf005 indicates and which additional status-register captures or power/reset checks would help identify the cause. Electrical measurements and complete reset-sequence verification are still pending. Regards, Rakesh Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Dear @Rakesh_Kumar-Thakur , Thanks for your update. >>Regarding 0xf005  code 0xf005 means that the driver did not observe the firmware reaching the Ready/Active state within the polling timeout. It is a firmware activation status, not a specific hardware-fault code. However, hardware issues such as SDIO communication, power, reset, or clock problems may still cause this status. >>Regarding switching to the lf-6.18.20_2.0.0 branch: The correct approach is to use the complete, matching Wi-Fi driver and firmware from that branch. We should not replace only the firmware, because the driver and firmware versions must be compatible and kept in sync. So you can try to update Wi-Fi driver & firmware to the latest branch. I have one question and one suggestion: Do you have to use Android 15? Since the i.MX95 is relatively new, it would be better to use the latest BSP version. You could use Android 16.0.0_2.0.0 with the L6.18.20_2.0.0 BSP. I suggest first verifying the Wi-Fi hardware, driver, and firmware on the Linux BSP. Once the Wi-Fi module works properly on Linux, you can migrate the solution to Android 16. This approach can reduce the complexity of Android-specific configuration and make debugging more efficient. Thanks, Regards, Weidong Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, Thank you for the clarification. We must retain AOSP 15 with kernel 6.12.23; upgrading to Android 16 is not an option. Could you please recommend a supported Wi-Fi driver–firmware pair for this setup with JODY-W263-00B / 88W8987? Our current driver is reported as 537.p9. If you recommend the pair from lf-6.18.20_2.0.0, please confirm whether that driver supports kernel 6.12.23 and whether any integration patches are required. Please provide the exact driver and firmware commits/tags, the matching sduart8987_combo.bin version/checksum, and recommended module parameters. Regards, Rakesh Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, While reviewing Android Automotive Release Notes (RN00227), Rev. automotive-15.0.0_2.1.0, dated 14 October 2025, I noticed that Section 4, Table 2 — Connectivity Wi-Fi lists PCIe9098 / u-blox JODY-W3 for i.MX95. I have attached a screenshot of this entry. Our setup uses: Board: i.MX95 19×19 EVK Module: u-blox JODY-W263-00B / 88W8987 over uSDHC3 SDIO BSP: Android Automotive 15.0.0_2.1.0 Kernel: 6.12.23 The SDIO device is detected and firmware transfer completion is reported, but firmware activation fails with firmwarestat=0xf005. Could you please clarify: Has JODY-W263-00B / SDIO8987 been validated on this BSP, or does it require additional integration beyond the previously recommended changes? If supported, could you provide the matching driver–firmware revisions and required DTS, power/reset and module-parameter configuration? Is JODY-W3 / PCIe9098 the recommended module for this release? If replacement is recommended, please specify the exact module/carrier part number and required board configuration. We must retain Android 15 and kernel 6.12.23. Please advise the supported path for this setup. Regards, Rakesh Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Dear @Rakesh_Kumar-Thakur , i.mx95 is designed for automotive applicaiton. Wi-Fi module, AW693 & PCIe 88Q9098 is supported by automotive android, I have tested AW693 module, no problem. I am building L6.12.49 linux bsp , I want to test 88W8987 on i.mx95. Best Reards, Weidong Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, Thank you for the detailed explanation. We understand that 0xf005 means the driver did not observe the firmware reaching the Ready/Active state within the polling timeout, and that it is not a specific hardware-fault code. On our i.MX95 19x19 EVK with the u-blox JODY-W263-00B (88W8987), SDIO detection and firmware download complete, but activation still times out with status 0xf005. Our current platform is Android 15 with kernel 6.12.23 and MOAL/MLAN driver 537.p9. The software power/reset checks and boot-time reset sequencing changes are complete, but the issue remains. Physical voltage, reset and clock measurements are pending. Following your recommendation, we plan to validate Wi-Fi on Linux first using a complete, matching driver and firmware pair. We are checking internally whether migration to Android 16 is possible. If Android 15 remains mandatory, we will evaluate backporting the matching pair while retaining kernel 6.12.23. Could you please confirm the following? Earlier test result: What was the outcome of your L6.12.49 test with JODY-W263-00B on i.MX95? Validated release: Has this exact module been validated on the i.MX95 19x19 EVK with L6.18.20_2.0.0 and Android 16.0.0_2.0.0? Linux setup: Please provide the manifest branch and XML filename, MACHINE, DISTRO, image name, and official build/flashing instructions. Matching Wi-Fi pair: Please provide the driver repository and pinned revision, firmware package and revision, correct firmware filename, and required module configuration. Is sduart8987_combo.bin correct for this module’s SD-UART configuration? Android setup: Please confirm the corresponding Android release and manifest, including the Automotive variant if applicable. Additional diagnostics: Are any specific Device Tree settings, power/reset timings, patches or register dumps required to investigate this activation timeout? After Linux validation, we will share the boot logs, driver/firmware versions, firmware SHA-256 and available hardware measurements. Best regards, Rakesh Thakur Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, Thank you for the update. We will wait for your test results next week. Could you please confirm that your test setup uses the u-blox JODY-W263-00B / NXP 88W8987 module with Wi-Fi over SDIO? When sharing the results, please include the exact BSP version, driver revision, firmware version/file and required board configuration. If the test succeeds, please also share where we can obtain the same driver–firmware pair. This will help us reproduce your working setup and compare it with our Android 15 / kernel 6.12.23 integration. Thanks and best regards, Rakesh Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hello Weidong, Following your recommendation, we integrated a matching Wi-Fi driver and firmware pair from lf-6.18.20_2.0.0. However, the firmware activation failure remains. Before proceeding with further changes, we need confirmation of the supported driver–firmware package for our exact installed Wi-Fi module, along with its download source and support ownership. 1. Hardware and software setup Component Details Board NXP i.MX95 19×19 EVK Installed Wi-Fi module u-blox JODY-W263-00B Wi-Fi chipset NXP 88W8987 Wi-Fi interface SDIO Intended Bluetooth interface UART Android BSP Automotive Android 15.0.0_2.1.0 Kernel base 6.12.23 Detected SDIO device mmc2:0001:1 Our installed module uses SDIO for Wi-Fi, rather than the PCIe Wi-Fi configuration discussed for the default EVK setup. Please base your recommendation specifically on JODY-W263-00B / 88W8987 in SD-UART mode. 2. Original and updated driver–firmware pairs Component Original setup Updated setup Driver version 537.p9 543.p18 Firmware embedded version 16.92.21.p151.4 16.92.21.p156.2 Firmware filename sduart8987_combo.bin sduart8987_combo.bin Firmware size 628200 bytes 644352 bytes Result Activation timeout, 0xf005 Same activation timeout, 0xf005 The updated pair was selected from lf-6.18.20_2.0.0 and backported into our existing Android 15 / kernel 6.12.23 environment. We have not performed a full Android 16 / Linux 6.18 BSP migration. Selected reference revisions: Driver: 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 Firmware: cc78ca8b1ee28ff741bcc160246f61b008f6c89f 3. Integration and deployment evidence Updated driver compilation and MODPOST passed. Image packaging and local AVB verification passed. After flashing, the loaded driver version was verified as 543.p18. Board module and firmware hashes matched the packaged artifacts. SDIO enumeration succeeded. The same activation failure occurred on the first post-flash boot and during a cold-power test. The updated firmware in the integrated source was also inspected directly: Filename: sduart8987_combo.bin Size: 644352 bytes Embedded identification: $Id: w8987o-V0, RF878X, FP92, 16.92.21.p156.2 $ SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823 4. Failure evidence Original pair: SD8987: init module param from usr cfg card_type: SD8987, config block: 0 fw_name=sduart8987_combo.bin Request firmware: sduart8987_combo.bin Wlan: FW download over, firmwarelen=628200 downloaded 619156 Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! Firmware Init Failed wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1 Updated pair: Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 The driver detects the module and reports firmware transfer completion, but firmware activation fails. This does not currently point to an obvious detection or firmware-file-loading failure. However, we are not claiming that the driver is fully validated or that firmware incompatibility is the confirmed root cause. 5. Specific confirmation and package request Please answer the following points for JODY-W263-00B / 88W8987: Are both driver–firmware pairs listed above supported for this exact module in SD-UART mode? Please confirm each pair separately. Is either existing driver suitable, with only a different firmware required, or must we obtain a different matching driver–firmware pair? Please identify the exact supported combination. Where can we obtain that package? Please provide the official download link, repository/branch and commits, or the process for requesting access. Who is responsible for supplying and confirming it—NXP or u-blox? If this requires u-blox support, please identify the appropriate support route and the package information we should request. Is the generic NXP 88W8987 firmware suitable for JODY-W263-00B, or does this module require a u-blox-qualified package or additional module-specific files/configuration? Can the confirmed pair operate on Android 15 / kernel 6.12.23? If additional patches are required, please identify them. If this platform is unsupported, please specify a supported BSP and known working configuration for this exact module. What was the specific basis for recommending the driver update? Was there a known issue with 537.p9 and firmware 16.92.21.p151.4, or was the recommendation intended to establish a consistent release baseline? When can we expect compatibility confirmation and access to the recommended package? If engineering review is required, please provide an estimated response timeline. If the updated pair is already correct for this module, please state that explicitly and identify the next targeted diagnostic check for the 0xf005 activation failure. A separate Binder module packaging mismatch has also been corrected locally; those corrected images still require board retesting. Its relationship to the Wi-Fi failure has not been established. Our immediate request is a module-specific confirmation of the correct driver and firmware, their official source, the responsible supplier, and an expected timeline, so that further testing proceeds from a verified baseline. Thank you. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, Following your recommendation, we have now integrated and tested the complete matching Wi-Fi driver and firmware pair from lf-6.18.20_2.0.0 on our i.MX95 19×19 EVK with JODY-W263-00B / 88W8987. Android 15 and kernel 6.12.23 must be retained. Integrated revisions: Driver: 2e481212d262758cbd4d0fc7ea95a2ad5f704bc3 Firmware: cc78ca8b1ee28ff741bcc160246f61b008f6c89f Loaded MLAN/MOAL version: 543.p18 Firmware: sduart8987_combo.bin, 644352 bytes Compilation and image packaging passed. On the board, we verified the intended kernel, loaded driver version, and module/firmware hashes against the packaged artifacts. Android boot and SDIO enumeration succeeded. However, both the first post-flash boot and a cold-power test produced the same activation failure: Wlan: FW download over, firmwarelen=644352 downloaded 635356 Fail to poll firmware status: firmwarestat=0xf005 Firmware Init Failed probe with driver wlan_sdio failed with error -1 No WLAN interface was created. Therefore, updating the matching pair from 537.p9 to 543.p18 has not resolved the failure. Software power/reset sequencing changes are in place. Physical supply, reset and clock measurements remain pending. An earlier verified 1-bit SDIO test at 50 MHz also produced the same timeout. Separately, we identified a kernel/system-module mismatch affecting rust_binder and rebuilt the images with matching modules. Board retesting of that corrected image set is pending; its relationship to the Wi-Fi failure has not been established. Could you please help us prioritize the next steps? Your Linux test: What is the result of your planned L6.12.49 test with 88W8987 on i.MX95? Please confirm the exact module/carrier, driver–firmware revisions and DTS configuration used. Android 15 support: Is this 543.p18 pair suitable for kernel 6.12.23? Are any compatibility patches required, or do you recommend another validated pair? Targeted diagnostics: We understand that 0xf005 indicates failure to reach READY. Can your Wi-Fi team interpret this specific SD8987 status and provide the exact registers, addresses and capture procedure needed to investigate startup failure? Next controlled experiment: Given that matching-pair integration and 1-bit testing have already been completed, which single software experiment should we perform next, with what settings and expected result? Hardware validation: Please provide the required supply levels, reset timing, clock requirements and confirmed measurement points for this board/module combination. If JODY-W263-00B has not been validated on this Android release, please state that explicitly and recommend the supported integration or replacement path. Full boot logs, source diffs, hashes and image verification records are available. Regards, Rakesh Thakur Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Please confirm whether driver 537.p9 + firmware 16.92.21.p151.4, and driver 543.p18 + firmware 16.92.21.p156.2, are supported combinations for JODY-W263-00B / 88W8987 in SD-UART mode. For the second pair, please also confirm support on Android 15 / kernel 6.12.23, including required patches or configuration. Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Dear @Rakesh_Kumar-Thakur , Please don't worry about it for now. The Yocto BSP is still being built, and the server is a bit slow. I expect to have some test results next week.     Thanks, Best Regards, Weidong Re: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12 Hi Weidong, We have now completed the following three tests on the i.MX95 19×19 EVK with JODY-W263-00B / 88W8987: Original setup: Automotive Android 15.0.0_2.1.0, kernel 6.12.23, driver 537.p9 and firmware 16.92.21.p151.4. The same activation failure remained after applying your suggested DTS and power/reset configuration changes. Backported setup: Integrated the matching driver 543.p18 and firmware 16.92.21.p156.2 from Linux release lf-6.18.20_2.0.0, retaining Android 15 and kernel 6.12.23. The same failure persisted. Linux validation: Built, flashed and tested Linux BSP L6.18.20_2.0.0, running kernel 6.18.20-2.0.0-g88cb92741827. The same failure occurred. In all three setups, firmware activation times out with firmwarestat=0xf005, and no WLAN interface is created. The attached screenshot shows the Linux result. We have therefore tried both the matching driver–firmware update and Linux BSP validation you recommended. Could you please suggest the next targeted debugging approach and share the result of your planned L6.12.49 test? Physical power/reset/clock measurements remain pending.   Regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hi Weidong, Thank you for sharing the successful W603C test and the DTS. We use u-blox JODY-W263-00B (88W8987) on the i.MX95 19×19 EVK. Firmware download completes, but activation fails with 0xf005. Our final target is Android 15.0.0_2.1.0 / kernel 6.12.23. Before testing your changes, could you please clarify: Does this configuration also apply to JODY-W263-00B? Is W603C a required replacement, or simply the module used for your test? The description mentions P0_5, whereas the DTS uses offset 4 (P0_4), GPIO_ACTIVE_HIGH. Please confirm the correct GPIO and required physical levels during reset and normal operation, particularly for W_DISABLE2#. Please share the driver revision, firmware binary/hash, wifi_mod_para.conf, and exact BSP manifest/build configuration used. We plan to compare your DTS with our setup and test the applicable changes on our existing JODY module. Best regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Dear @Rakesh_Kumar-Thakur , I enabled 88W8987 M.2 module on linux platform. --L6.12.49_2.2.0 --Module: Amphenol W603C (Base on 88W8987) 0. Control flow on i.MX95-EVK hardware. =================================================== 1. Wi‑Fi Loading Mechanism on linux platform. So Wi-Fi driver will be loaded during Linux boot. 2. Tunning device tree - Adding usdhc3 node and related GPIO Control. (1) PCAL6524HEAZ.P2_4 -- Output High -- Enable VCC_KE_3V3, supported by imx95-19x19-evk.dts by default. reg_m2_pwr: regulator-m2-pwr { compatible = "regulator-fixed"; regulator-name = "M.2-power"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&i2c7_pcal6524 20 GPIO_ACTIVE_HIGH>; enable-active-high; /* * M.2 device only can be enabled(W_DISABLE1#) after all Power * Rails reach their minimum operating voltage (PCI Express M.2 * Specification r5.1 3.1.4 Power-up Timing). * Set a delay equal to the max value of Tsettle here. */ startup-delay-us = <5000>; }; (2) Pull up SDIO_RST# pin PCAL6524HEAZ.P2_3 & P0_5 - Output High - Enable Wi-Fi/Bluetooth Module. Loaded by 'mmc-pwrseq' of usdch3 node directly.   usdhc3_pwrseq: usdhc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; reset-gpios = <&i2c7_pcal6524 19 GPIO_ACTIVE_LOW>, <&i2c7_pcal6524 4 GPIO_ACTIVE_HIGH>; /* W_DISABLE2# */ }; (3)Pull-up W_DISABLE1# PIN to Enable WiFi PCAL6524HEAZ.P0_6 - Output High - Enable Wi-Fi. Loaded by ‘vmmc-supply’ of usdch3 node directly. reg_usdhc3_vmmc: regulator-usdhc3 { compatible = "regulator-fixed"; regulator-name = "WLAN_EN"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&reg_m2_pwr>; gpio = <&i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>; /* * IW612 wifi chip needs more delay than other wifi chips to complete * the host interface initialization after power up, otherwise the * internal state of IW612 may be unstable, resulting in the failure of * the SDIO3.0 switch voltage. */ startup-delay-us = <20000>; enable-active-high; }; (4) usdhc3 pin control pinctrl_usdhc3: usdhc3grp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl,pins = < IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe >; }; (5)Disable pcie0 on M.2 (Optional, since not using it, disable it) &pcie0 { pinctrl-0 = <&pinctrl_pcie0>; pinctrl-names = "default"; reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; supports-clkreq; status = "disabled"; }; (6) Adding usdhc3 node &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; pinctrl-3 = <&pinctrl_usdhc3>; mmc-pwrseq = <&usdhc3_pwrseq>; vmmc-supply = <&reg_usdhc3_vmmc>; bus-width = <4>; keep-power-in-suspend; non-removable; wakeup-source; status = "okay"; }; 3. Running Linux BSP and getting message of Wi-Fi This indicates that, from a hardware platform perspective, the M.2 SDIO interface on the i.MX95-EVK fully supports SDIO Wi‑Fi devices without any issues.   Attachment is the dts I am using. share it with you here. Test it, please.   Thanks, Best Regards, Weidong Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Dear @Rakesh_Kumar-Thakur , Thanks for your update. >>Does this configuration also apply to JODY-W263-00B? Is W603C a required replacement, or simply the module used for your test? --Does this configuration also apply to JODY-W263-00B? Yes. fully same. Because M.2 Key E is a standard spec for Wi-Fi card. --Is W603C a required replacement, or simply the module used for your test? No need. Because current test result only can indicate i.mx95-evk M.2 is no problem for SDIO Wi-Fi. It doesn't mean JODY-W263-00B has issues. >>The description mentions P0_5, whereas the DTS uses offset 4 (P0_4), GPIO_ACTIVE_HIGH. Please confirm the correct GPIO and required physical levels during reset and normal operation, particularly for W_DISABLE2#. Yes, it should be P0_4, my mistake. >>Please share the driver revision, firmware binary/hash, wifi_mod_para.conf, and exact BSP manifest/build configuration used. here is the link for driver branch. https://github.com/nxp-imx/mwifiex/tree/lf-6.12.49_2.2.0 BUT just remind you, the issue you encountered is not caused by driver. don't try to change wifi driver. no help. Next week, I will prepare android 15 source code and try to enable it.  the android bsp you are using is automotive version or standard android bsp? Thanks, Best Regards, Weidong Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hi Weidong, Thank you for confirming that the configuration applies to JODY-W263-00B, that no W603C replacement is required, and that the correct GPIO is P0_4. We are using the Automotive Android BSP, with the following baseline: Board: i.MX95 19×19 EVK Module: u-blox JODY-W263-00B / 88W8987, SDIO BSP: Automotive Android 15.0.0_2.1.0 Manifest: imx-automotive-15.0.0_2.1.0.xml Build target: evk_95_car-nxp_stable-userdebug Kernel: 6.12.23 Our final requirement is to enable this module on the above Android 15 / kernel 6.12.23 baseline. We have completed the planned multimeter and oscilloscope checks covering the module supply, reset, W_DISABLE1#/PDn, and SDIO CLK/CMD/DATA0–3. The measurements and waveform captures have been documented. Firmware download still completes, followed by the same activation timeout, firmwarestat=0xf005. Following your advice, we will stop further driver-version changes and focus on the remaining configuration and sequencing checks. We also reviewed the driver branch you shared. It identifies the driver release as 540.p33, with the current branch HEAD at 84ca65c9ff935d7f2999af100a82531c22c65234. The repository contains firmware filename references, but not the firmware binaries, actual module-parameter configuration or board DTS. Could you please help with the following? P0_4 / W_DISABLE2# sequencing: Please confirm the required physical HIGH/LOW levels during power-up, reset assertion, reset release and normal operation. Your DTS includes P0_4 in reset-gpios as GPIO_ACTIVE_HIGH, alongside P2_3 / offset 19 as GPIO_ACTIVE_LOW. Is this combination intentional for JODY-W263-00B, and what physical level should each pin have after the power sequence completes? Tested firmware and parameters: Please share the exact firmware binary used in your successful W603C test, including its filename, version and SHA-256 hash, or its download link and exact repository commit. Please confirm whether the same firmware should be used with JODY-W263-00B. Please also share the actual wifi_mod_para.conf used, or the exact module-loading command and parameters if no configuration file was used. Successful Linux reference: Please confirm whether your test used the driver commit identified above and whether any additional driver patches were applied. To reproduce your L6.12.49_2.2.0 test with our existing JODY module, please share the final board DTS/patch and exact BSP manifest, MACHINE, DISTRO and image configuration. Would you recommend this comparison before your Android test? A suitable prebuilt image, if available, would also help. Planned Android 15 test: Could you please use Automotive Android 15.0.0_2.1.0 / kernel 6.12.23, matching our baseline? Please also confirm whether you will test with W603C or JODY-W263-00B. Once available, please share the enablement patches, firmware details and initialization logs so we can reproduce the result. We can provide our hardware-validation report, waveform captures, current DTS and complete boot/driver logs for comparison. Please let us know if you need any additional targeted measurement or register dump. I am currently working dedicatedly on this bring-up, and your clarification on the remaining points will help me proceed with the next tests. If possible, I would appreciate an early response, particularly on the GPIO sequencing and tested firmware/configuration, so I can continue validation while you prepare the Android 15 setup. Thank you for your continued support. Best regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Dear @Rakesh_Kumar-Thakur , Actually, as long as it's based on the NXP 88Q9098, AW693 M.2 Key E module, it will work. So, your choice of the u-blox module is fine. I have modified the code for Auto Android 15_2.1.0 for 88W8987, and there will be test results this week. If your application is designed for automotive use, you indeed need to use the NXP 88Q9098, AW693 Wi-Fi chips, which are designed specifically for the automotive domain.   Thanks, Best Regards, Weidong Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hi Weidong, Before purchasing a supported Wi-Fi card, could you please confirm the exact manufacturer and complete M.2 ordering part number tested on i.MX95 19×19 EVK with Automotive Android 15.0.0_2.1.0 / kernel 6.12.23? We are considering: M2-JODY-W377-00C — NXP 9098-based, PCIe Wi-Fi / UART Bluetooth M2-JODY-W683-00C — NXP AW693-based Please confirm which exact card you recommend, its chipset number, and whether it works with the released BSP or requires additional patches/configuration. If possible, please share a purchase link. Best regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hi Weidong, Could the firmware size difference be related to our initialization failure? The firmware file size is 628,200 bytes, but the driver reports only 619,156 bytes downloaded—a difference of 9,044 bytes. Our diagnostic logs show that the device stops requesting further data at offset 619,156. Offline parsing identified a last-block record ending at the same offset, but the purpose of the remaining bytes is still unconfirmed. Is this expected for this firmware image, or could it indicate an incomplete transfer related to the subsequent 0xf005 activation timeout? We are using JODY-W263-00B / 88W8987 with driver 537.p9 and firmware 16.92.21.p151.4 on Automotive Android 15.0.0_2.1.0 / kernel 6.12.23. Best regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Hi Weidong, Thank you for confirming the default support for 88Q9098 and AW693. We checked DigiKey and Mouser for these M.2 cards, but neither is currently in stock: M2-JODY-W377-00C — 9098-based M2-JODY-W683-00C — AW693-based We have a one-week deadline to demonstrate Wi-Fi operation on our i.MX95 19×19 EVK with Automotive Android 15.0.0_2.1.0 / kernel 6.12.23. Could you suggest another supplier, purchase link, or an available supported M.2 card? An evaluation sample would also help. Have any other Wi-Fi modules been tested successfully on i.MX95 with Android Automotive 15, Android 16, or another BSP release? If so, please share the exact M.2 card part number, chipset, tested BSP/kernel version, and purchase source. Our final target remains Android 15 / kernel 6.12.23, so please clarify whether those alternatives would require additional integration for our target. Meanwhile, our existing JODY-W263-00B / 88W8987 still fails firmware activation with 0xf005. Could you prioritize assistance and share any available enablement patches, matching driver–firmware package, and the results of your Linux and Android tests? You mentioned that we could send you our module for testing. Our office is in Pune, Maharashtra, India. Could you help arrange joint debugging with the NXP team in Noida? Alternatively, if NXP has an office or a suitable technical support team in Pune, please let us know. I can visit with the module and, if required, our EVK this week, preferably by Thursday, 29 October, subject to the team’s availability. Your coordination and continued involvement would help the local team build on the investigation already completed. Please let us know whether this can be arranged and whom we should contact. If local testing is not possible, please advise how we can arrange to send the module to you. Best regards, Rakesh Re: Request for confirmed driver–firmware package for JODY-W263-00B / 88W8987 on i.MX95 — activ Dear @Rakesh_Kumar-Thakur , Thanks for you detailed information. >>P0_4 / W_DISABLE2# sequencing:  The pin should be pulled up to HIGH. which is used to enable Bluetooth. No problem to pull it up to HIGH using external pull-up resistor. Some M.2 modules use the PIN to control Bluetooth software reset, But some modules don't use it. W603C uses it.   >>JODY-W263-00B. I don't have the M.2 module on my hand, but I have AW-CM358-SUR (M.2 module), I will also test it tomorrow on linux platform. >>Enable it on auto android 15-2.1.0. Yes, I have planned to enable the 8987 module under the version of bsp. you know it needs long time to repo sync android source code. So I need some time.  By default, auto android bsp only supports 88Q9098 and AW693, which are automotive Wi-Fi products. For other Wi-Fi chips, we should do some extra work to enable it. [Note] If W603C or AW-CM358-SUR M.2 module can normally work on my side, and JODY-W263-00B still can not work yet, you can consider send one JODY-W263-00B to me, let me try it on my platform. Thanks, Best Regards, Weidong
記事全体を表示
RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi, We are implementing WPA2-Enterprise / IEEE 802.1X on an RW612-based product using Zephyr 4.3 and Hostap/wpa_supplicant. Initial authentication works correctly with both PEAP/MSCHAPv2 and EAP-TLS. EAP-TLS also works with a PSA/ELS-backed non-exportable private key. We see a problem specifically during Wi-Fi in-place reauthentication. Observed sequence: RADIUS Access-Accept → EAP success → 4-way handshake → AP retransmits Message 3 → Wi-Fi link is lost → device reconnects and authenticates successfully again Our current evidence suggests a possible ordering issue between transmission of the final EAPOL-Key response and installation of the new PTK. The PTK update appears able to proceed while the final EAPOL frame may still be queued for transmission. We tried to find a supported mechanism to guarantee: final EAPOL-Key frame transmission completed BEFORE new PTK installation However, we could not find an EAPOL TX-completion callback, TX queue drain/fence, or equivalent API in the RW612 Wi-Fi driver/firmware path. As a diagnostic experiment only, adding a 100 ms delay before PTK installation allowed several PEAP and EAP-TLS reauthentication attempts to complete without interruption. We do not consider a fixed delay to be a production solution. Could you please clarify: - Is there a supported API to know when an EAPOL data frame has actually been transmitted by the firmware? - Is there a TX queue flush/drain or key-install fence that should be used before updating PTK? - Is this a known limitation or known issue in the RW612 Wi-Fi driver/firmware? - Is there a newer driver or Wi-Fi firmware version that addresses this? Tested versions: RW612 driver: v1.3.r52.z_up.p11 Wi-Fi firmware: 18.99.6.p47 We can provide detailed traces and a vendor issue package if needed. Thanks. RW612  Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi @sukrusinan, hope you are doing well. To get a better understanding on your setup and case scenario, could you please share the following information? Share the used base example for your application. Is it Zephyr Wi-Fi Shell? Has this setup worked before as-is? If it has, could you please share which modifications were implemented? Provide terminal logs from a failing authentication case. What are you using as RADIUS server?  What AP model are you using? Are you able to reproduce this behavior on Zephyr latest version (4.4.2)? Please let us know the requested information.  Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi @RomanVR , Thanks for your reply. Please find the requested information below. 1. Base application This is a custom Zephyr application for an NXP RW612-based device. It is not based directly on the Zephyr Wi-Fi Shell sample. It uses: standard Zephyr Wi-Fi management APIs Hostap/wpa_supplicant the NXP RW612 Wi-Fi driver The standard Wi-Fi shell and wpa_cli are enabled only for diagnostics. 2. Has the setup worked before? Initial WPA2-Enterprise authentication works correctly with both: PEAP/MSCHAPv2 EAP-TLS Reboot and reconnect also work. The issue is specifically Wi-Fi in-place reauthentication. Seamless in-place reauthentication has not worked reliably with the current setup. In the failing case: initial authentication succeeds -> RADIUS Access-Accept -> EAP succeeds -> in-place reauthentication is triggered -> Wi-Fi link is lost -> IPv4 is removed -> device reconnects automatically -> authentication and connectivity recover We consider this a FAIL because the network connection is interrupted during reauthentication. The issue has been reproduced with both PEAP/MSCHAPv2 and EAP-TLS. 3. Terminal logs Attached are sanitized terminal captures for: PEAP/MSCHAPv2 reauthentication failure EAP-TLS reauthentication failure The captures contain no credentials, keys, internal addresses, SSIDs, MAC addresses, or private certificate information. At the current log level, per-frame EAPOL TX completion and detailed PTK installation timing are not available. 4. RADIUS server FreeRADIUS running on Ubuntu. 5. Access point Ubiquiti UniFi U6 Pro using WPA2-Enterprise. 6. Zephyr 4.4.2 We have not yet performed a hardware test with Zephyr 4.4.2. We created an isolated checkout of the official v4.4.2 source. However, our current integration contains version-pinned Zephyr/Hostap adapters, and these patches do not apply cleanly to 4.4.2. Therefore, changing only ZEPHYR_BASE would not provide a valid comparison. The integration must first be ported to the 4.4.2 Hostap and NXP HAL revisions before we can perform a meaningful hardware A/B test. We have attached a short note with the exact result of this check. Current tested versions: Zephyr: 4.3.0 based Hostap: 2.11 NXP Wi-Fi driver: v1.3.r52.z_up.p11 Wi-Fi firmware: 18.99.6.p47 We would also appreciate guidance on the following point: Does the RW612 Wi-Fi driver/firmware provide a supported mechanism to guarantee completion of an EAPOL-Key frame transmission before a subsequent PTK/key update? In particular, is there a supported: EAPOL/data TX completion callback, TX queue drain or flush, firmware synchronization/fence, or documented key-update ordering guarantee? We are trying to determine whether such a mechanism already exists in the RW612 stack or whether this behavior requires a driver/firmware correction. The attached logs only demonstrate the link interruption after successful in-place EAP authentication; they do not by themselves establish the internal firmware root cause. Best Regards Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi @sukrusinan, thank you for sharing additional details. The information provided helps understand the conditions under which the behavior occurs. Since the application is fully custom, it becomes complex for us to debug and analyze the problem, hence, it would be very helpful if you could confirm if this behavior can be reproduced in a simpler example and how to do it, in order to reproduce it on our side. Additionally, in order to narrow down the root cause, could you please check or confirm whether the same application in RW612 reproduce the reported behavior with another access point?  To investigate further, if possible, could you please share the following logs: AP (Ubiquiti) logs showing the reauthentication and 4-way-handshake exchange. An independent over-the-air capture of a failing attempt with a sniffer. This information would help us determine whether the RW612 stack’s EAPOL TX-completion or key-update ordering behavior should be evaluated further. Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi, Thanks for your suggestions. We have made some progress and can now reproduce the issue in a minimal Zephyr PEAP/MSCHAPv2 application on the same RW612 hardware, with the unrelated product services removed. Our setup: Zephyr 4.3.0 / Hostap 2.11 NXP Wi-Fi driver v1.3.r52.z_up.p11 Radio firmware 18.99.6.p47 UniFi U6 Pro / FreeRADIUS Initial PEAP authentication works correctly, including RADIUS Access-Accept, DHCP and ping. However, in-place reauthentication receives another Access-Accept and then drops the Wi-Fi link before eventually reconnecting. We investigated the timing between EAPOL-Key transmission and pairwise key installation. Using the minimal application, we performed an A/B/A/B test with continuous ICMP monitoring (250 ms intervals), starting before reauthentication. Configuration Ping replies Link interruption 0 ms delay, attempt 1 131/288 27.844 s 100 ms delay, attempt 1 288/288 None observed 0 ms delay, attempt 2 159/288 27.840 s 100 ms delay, attempt 2 288/288 None observed The 100 ms delay was introduced before the subsequent pairwise key-install request. This suggests a timing-sensitive interaction, but we don't consider a fixed delay a proper solution. We also collected UniFi AP-side EAPOL logs and an independent OTA capture from an earlier EAP-TLS reauthentication failure. The OTA capture shows M4 transmitted from the station to the AP (key-info 0x030a, replay counter 4). However, we cannot confirm whether the AP received or accepted it, and the sniffer's AP-side coverage is incomplete. We investigated the newer r54 driver with its matching firmware, but the port is currently blocked by Hostap scheduled-scan and ROC/cookie API incompatibilities, so we haven't tested it on hardware. Could you help clarify a few points? Is there a supported mechanism to ensure EAPOL-Key TX completion before installing the new pairwise key? Are there any known reauthentication or key-update issues with our current driver/firmware versions? Which RW612 driver, firmware and Zephyr/Hostap combination would you recommend? Is there an updated version or patch addressing this behavior? Are there firmware traces or callbacks available to verify EAPOL TX completion and key-installation status? Testing with another AP vendor is still pending. I've attached a ZIP containing the minimal application test results, AP-side EAPOL summaries, RADIUS events and independent OTA capture findings. The captures and AP logs are from separate test sessions, as described in the README. We can also share the minimal reproducer source and raw captures privately if needed. Our main goal is to identify a reliable fix for seamless Wi-Fi reauthentication. Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation Hi @sukrusinan, sorry for the late reply. Thank you for sharing the logs, after reviewing them, the following points are needed in order to narrow down the root cause of the authentication failure: Test with a different AP: This will help determine if the reauthentication failure can be reproduced on a different AP, which would help isolate the watched behavior. Synchronized OTA capture during the PEAP failure: The OTA excerpt you shared is from a separate EAP-TLS session and cannot be correlated with the PEAP AP log. This would help to analyze if the AP is rejecting the M4 due to being in an invalid format for the AP. Minimal reproducer: Could you please share the steps to reproduce the behavior in a minimal Zephyr application? This would help to try to reproduce it on our end. Regarding your questions: It is suggested to always work on the latest Zephyr version and test on downstream repository (add link) for potential bug fixes not available on Zephyr main repository. Regarding software mechanisms, we would still need to be able to determine if this behavior is present with a different AP. Therefore, while you are able to perform a test with a different AP vendor, please try enabling the following debug logs on your side, as it will provide a better insight on the STA side: CONFIG_WIFI_NM_WPA_SUPPLICANT_LOG_LEVEL_DBG CONFIG_WIFI_NM_WPA_SUPPLICANT_DEBUG_LEVEL Please let us know your findings as per the requested tests.
記事全体を表示
RT1170 支持 QSPI Flash (MX25L51245G) 您好, RT1170 是否支持 MX25L51245G QSPI 闪存? 是否需要修改配置文件“evkmimxrt1170_flexspi_nor_config.c”才能与该芯片兼容? 如果是这样,该如何修改?应该修改哪些参数? 感谢您的支持! 顺祝商祺! 世界青年大会 Re: RT1170 support QSPI Flash (MX25L51245G ) 你好@jeremyzhou 我们使用 MX25L51245G 外置闪存和 RT1176,并实现了如下所示的配置。它在 XIP 模式下运行完美,但我也想得到您的验证。 但是,当在“链接应用程序模式”下运行多核应用程序时,系统会发生硬故障。具体来说,由于从 FlexCAN MCR 寄存器读取的值,它触发信号一个断言。 下面附上一些截图和我的查找表供您参考,引用。 M7 闪存初始化(RAM): M4 闪存初始化(RAM): 多核(RAM)的硬故障: 以下是为支持软件在 RAM 和 XIP(就地执行)模式下无缝运行而设计的查找表配置:   #define FLASH_DUMMY_CYCLES 0x08 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG , .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc= kFlexSPIReadSampleClk_LoopbackFromDqsPad , .csHoldTime = 3u, .csSetupTime = 3u, .controllerMiscOption = 0x10, .deviceType = kFlexSpiDeviceType_SerialNOR , .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz , // kFlexSpiSerialClk_120MHz​​ .sflashA1Size = 64u * 1024u * 1024u, //64MB //她的acilista QE = 1. ROM 一次 WREN'i ( seq 3) kendisi gonderir , sonra 4*12' yi 0x40 ile calistirir . //NXP RT1170 EVK'daki configCmd kalibinin aynisi .configCmdEnable = 1u, .configModeType[0] = kDeviceConfigCmdType_Generic, .configCmdSeqs[0] = {.seqNum = 1u, .seqId = 12u, .reserved = 0u}, //1 个序列calistir : 4*12 // asagiyi 0x20 yapinca calismadi Dogrudan内存hatasinda patladi main'e gelmeden .configCmdArgs[0] = 0x40u, //WRITE_SDR'nin gonderecegi 字节: SR = 0x40 .lookupTable = { [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x6C, RADDR_SDR, FLEXSPI_1PAD, 0x20), //6Ch QREAD4B: komut ve 4 字节地址tek hattan (1-1-4) [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), //8 虚拟bekle , 数据 4 hattan [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), //状态寄存器0x05'den okuyacam (WIP = bit0) [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), //写入en ettim // asagidakini yoruma alinca gercekten silmedi [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4 字节地址alarak 4 kb扇区silecem [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20), //64 kb块silecem (app'de kullanmiyoruz ) [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), //4 字节 1 页yazacam [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // datayi gonder ve bitir (WEL'i flash 程序bitince kendisi temizler ) [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC7, STOP, FLEXSPI_1PAD, 0x0), //转flashi silecem (app'de kullanmiyoruz ) [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x01, WRITE_SDR, FLEXSPI_1PAD, 0x01), //WRSR + tam 1 字节 (configCmdArgs[0]): sadece SR yazilir , CR'ye dokunmaz // seq 6/7 bos : ROM API 暂停/恢复kullanmiyor }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 0x1, .blockSize = 64u * 1024u, .isUniformBlockSize = true, }; Re: RT1170 support QSPI Flash (MX25L51245G ) 你好, 感谢您对恩智浦半导体产品的关注,并感谢您给我们提供服务的机会。 1) RT1170 是否支持 MX25L51245G 作为 QSPI 闪存? - 是的。 2)是否需要修改配置文件“evkmimxrt1170_flexspi_nor_config.c”以适配此芯片? 是的,请参考以下代码。 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64u * 1024u * 1024u, .lookupTable = { // Read LUTs FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 256u * 1024u, .isUniformBlockSize = false, }; 祝你有美好的一天, 信息通信技术 ------------------------------------------------------------------------------- 笔记: - 如果此回复解答了您的问题,请点击“标记为正确答案”按钮。谢谢你! - 我们会持续关注帖子,从最后一条回复发出后持续7周,之后的回复将被忽略。 如果您之后有相关问题,请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------
記事全体を表示
RW612 WPA2-Enterprise再認証 – PTKインストール前のEAPOL TX完了 こんにちは、 Zephyr 4.3とHostap/wpa_supplicantを使用したRW612ベースの製品上でWPA2-Enterprise / IEEE 802.1Xを実装しています。 初期認証はPEAP/MSCHAPv2およびEAP-TLSの両方で正しく動作します。EAP-TLSは、PSA/ELSで保護された非エクスポート型の秘密鍵でも動作します。 特にWi-Fiのインプレース再認証時に問題が発生することが確認されています。 観測されたシーケンス: RADIUS アクセス-受け入れ → EAPの成功 → 4ウェイハンドシェイク → APがメッセージ3を再送信します → Wi-Fi接続が途絶えました →デバイスは再接続し、再び認証に成功します 現在の証拠は、最終的なEAPOL-Key応答の送信と新しいPTKの設置の間に順序の問題の可能性を示唆しています。 PTKの更新処理は、最終的なEAPOLフレームが送信待ちの状態であっても、続行できるようです。 私たちは、以下のことを保証するサポートされたメカニズムを見つけようとしました。 最終的なEAPOLキーフレーム送信が完了しました 前に 新しいPTKのインストール しかし、RW612のWi-Fiドライバ/ファームウェアパス内でEAPOL TX完了コールバック、TXキュードレイン/フェンス、または同等のAPIは見つかりませんでした。 診断実験としてのみ、PTKのインストール前に100ミリ秒の遅延を追加することで、PEAPおよびEAP-TLSの再認証試行が複数回、中断なく完了することができました。固定遅延は、生産上の解決策とは考えていません。 もう少し詳しく教えていただけますか: ファームウェアによってEAPOLデータフレームが実際に送信されたかどうかを知るための、サポートされているAPIはありますか? - PTKを更新する前に使うべきテキストラキューのフラッシュ/ドレインやキーインストールフェンスはありますか? - これはRW612のWi-Fiドライバ/ファームウェアにおける既知の制限や既知の問題ですか? - この問題に対応する新しいドライバやWi-Fiファームウェアはありますか? テスト済みバージョン: RW612ドライバ:v1.3.r52.z_up.p11 Wi-Fiファームウェア:18.99.6.p47 必要に応じて詳細なトレースやベンダー発行パッケージをご提供いたします。 ありがとう。RW612 Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation こんにちは、 @sukrusinan さん。お元気でお過ごしでしょうか。 あなたのセットアップやケースシナリオをよりよく理解するために、以下の情報を共有していただけませんか? あなたのアプリケーションで使われているベース例を共有してください。Zephyr Wi-FiのShellですか? この設定は以前、このままの状態で正常に動作したことがありますか?もし実装されているなら、どのような変更が施されたのか教えていただけますか? 認証が失敗した場合の端末ログを提供します。 RADIUSサーバーとして何を使用していますか? どのAPモデルを使っていますか? Zephyrの最新バージョン(4.4.2)でこの動作を再現できますか? ご要望の情報をお知らせください。 Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation こんにちは、 @RomanVR さん。 ご返信ありがとうございます。 ご依頼いただいた情報は下記に記載しております。 1. 基本適用 これはNXP RW612ベースのデバイス向けにカスタムされたZephyrアプリケーションです。 これはZephyr Wi-Fi Shellのサンプルに直接基づいているわけではありません。使用するもの: 標準的なZephyr Wi-FiマネジメントAPI Hostap/wpa_supplicant NXP RW612 Wi-Fiドライバ 標準のWi-Fiシェルとwpa_cliは、診断目的でのみ有効になっています。 2. この設定は以前にも正常に機能したことがありますか? 初期のWPA2-エンタープライズ認証は以下の両方で正しく動作します: PEAP/MSCHAPv2 EAP-TLS 再起動して再接続するのも有効です。 問題は具体的にはWi-Fiのインプレース再認証にあります。現在の設定では、シームレスなインプレース再認証が安定して動作していません。 失敗したCASE: initial authentication succeeds -> RADIUS Access-Accept -> EAP succeeds -> in-place reauthentication is triggered -> Wi-Fi link is lost -> IPv4 is removed -> device reconnects automatically -> authentication and connectivity recover 再認証中にネットワーク接続が中断されたため、これは失敗と判断します。 この問題は、PEAP/MSCHAPv2とEAP-TLSの両方で再現されています。 3. ターミナルログ 添付ファイルは、以下の端末のデータを匿名化したものです。 PEAP/MSCHAPv2再認証失敗 EAP-TLS再認証失敗 キャプチャされたデータには、認証情報、鍵、内部アドレス、SSID、MACアドレス、またはプライベート証明書情報は含まれていません。 現在のログレベルでは、フレームごとのEAPOL送信完了時刻や詳細なPTKインストールタイミングは利用できません。 4. RADIUSサーバー Ubuntu上で動作するFreeRADIUS。 5. アクセスポイント WPA2-Enterprise を使用する Ubiquiti UniFi U6 Pro。 6. Zephyr 4.4.2 Zephyr 4.4.2でのハードウェアテストはまだ実施していません。 公式v4.4.2ソースの独立したチェックアウトを作成しました。しかし、現在の統合にはバージョンピン留めのZephyr/Hostapアダプターが含まれており、これらのパッチは4.4.2にはクリーンに適用されません。 したがって、変更のみ ZEPHYR_BASEは 有効な比較にはなりません。統合はまず4.4.2 HostapおよびNXP HALリビジョンに移植されなければ、意味のあるハードウェアA/Bテストを行うことはできません。 この調査の正確な結果を記載した短いメモを添付いたしました。 現在テスト済みのバージョン: Zephyr: 4.3.0 based Hostap: 2.11 NXP Wi-Fi driver: v1.3.r52.z_up.p11 Wi-Fi firmware: 18.99.6.p47 また、以下の点についてもご助言いただければ幸いです。 RW612のWi-Fiドライバ/ファームウェアは、EAPOL-Keyフレームの送信を次のPTK/キー更新前に完了させることを保証するサポートメカニズムを提供していますか? 特に、サポートされている機能はありますか? EAPOL/データTX完了コールバック、 TXキューのドレインまたはフラッシュ、 ファームウェア同期/フェンス、 あるいは、ドキュメント化されたキー更新順序保証はありますか? このような仕組みがすでにRW612スタックに存在しているのか、それともこの動作にドライバやファームウェアの修正が必要なのかを判断しようとしています。 添付のログは、EAP認証が成功した後のリンク中断のみを示しています。それだけでは内部ファームウェアの根本原因を特定するものではありません。 よろしくお願いいたします。 Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation こんにちは、 @sukrusinan さん。追加情報を共有していただきありがとうございます。 提供された情報は、その行動が発生する状況を理解するのに役立ちます。アプリケーションは完全にカスタムなので、問題のデバッグや分析が複雑になります。したがって、この動作がより簡単な例で再現可能かどうか、またどのように行うかをご確認いただけると、私たちの側で再現できるよう助かります。 さらに、根本原因を絞り込むために、同じRW612アプリケーションが別のアクセスポイントでも報告された挙動を再現しているかどうか、確認していただけますか? さらに調査するために、可能であれば以下のログを共有していただけませんか: AP(Ubiquiti)のログには、再認証と4ウェイハンドシェイクのやり取りが記録されている。 スニファによる通信失敗の試みを、無線経由で独自にキャプチャした。 この情報は、RW612スタックのEAPOL TX補完動作やキー更新順序付けの動作をさらに評価すべきかどうかを判断するのに役立ちます。 Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation こんにちは、 ご提案ありがとうございます。いくつかの進展があり、同じRW612ハードウェア上で最小限のZephyr PEAP/MSCHAPv2アプリケーションで問題を再現できるようになりましたが、関連のない製品サービスは削除されています。 私たちの体制: Zephyr 4.3.0/ Hostap 2.11 NXP Wi-Fiドライバ v1.3.r52.z_up.p11 無線ファームウェア 18.99.6.p47 UniFi U6 Pro / FreeRADIUS 初期PEAP認証は正しく動作し、RADIUSアクセス承認、DHCP、pingも含まれます。しかし、インプレース再認証は再度アクセス承認を受け取り、その後Wi-Fiリンクを切断して最終的に再接続します。 EAPOL鍵の送信とペアワイズ鍵のインストールとの間のタイミングについて調査した。最小限のアプリケーションを用いて、再認証前から連続ICMP監視(250ミリ秒間隔)を伴ったA/B/A/Bテストを実施しました。 設定 Ping応答 リンクの中断 0ミリ秒の遅延、試行1回目 131/288 27.844秒 100ミリ秒の遅延、試行1回目 288/288 観察されなかった 0ミリ秒の遅延、2回目の試行 159/288 27.840秒 100ミリ秒の遅延、2回目の試行 288/288 観察されなかった 100ミリ秒の遅延は、後続のペアワイズキーインストール要求の前に導入されました。これはタイミングに敏感な相互作用を示唆しているが、固定遅延は適切な解決策とは考えていない。 また、以前に発生したEAP-TLS再認証失敗時のUniFi AP側のEAPOLログと、独立したOTAキャプチャも収集しました。OTAキャプチャでは、ステーションからAPにM4が送信されたことが示されています(キー情報0x030a、リプレイカウンタ4)。しかし、APが受信したか受け入れたか確認できず、スニッファーのAP側のカバレッジも不完全です。 新しいr54ドライバとそれに対応するファームウェアを調べましたが、現在HostapのスケジュールスキャンやROC/クッキーAPIの互換性の問題でポートがブロックされており、ハードウェアでのテストはまだしていません。 いくつかポイントを明確にしていただけますか? 新しいペアワイズキーをインストールする前に、EAPOLキーの送信が完了していることを確認するためのサポートされているメカニズムはありますか? 現在のドライバやファームウェアのバージョンで、既知の再認証やキー更新の問題はありますか? どのRW612ドライバ、ファームウェア、Zephyr/Hostapの組み合わせをおすすめしますか?この不具合を修正するアップデート版やパッチはありますか? EAPOL TXの完了とキーのインストール状況を確認するためのファームウェアのトレースやコールバックはありますか? 別のアクセスポイントベンダーとのテストはまだ実施中です。 最小限のアプリケーションテスト結果、AP側のEAPOL要約、RADIUSイベント情報、独立したOTAキャプチャ結果を含むZIPファイルを添付しました。キャプチャデータとAPログは、READMEに記載されているとおり、別々のテストセッションから取得したものです。 必要に応じて、最小限の再生ソースや生のキャプチャもプライベートで共有可能です。 私たちの主な目標は、シームレスなWi-Fi再認証を実現するための確実な解決策を見つけることです。 Re: RW612 WPA2-Enterprise reauthentication – EAPOL TX completion before PTK installation こんにちは、 @sukrusinan さん。返信が遅くなり申し訳ありません。 ログを共有してくださりありがとうございます。確認した上で、認証失敗の根本原因を特定するために以下のポイントが必要です。 別のAPでテスト: これにより、再認証失敗が別のAPで再現可能かどうかを判断でき、監視された動作を分離するのに役立ちます。 PEAP障害時の同期OTAキャプチャ: 共有されたOTAの抜粋は別のEAP-TLSセッションからのもので、PEAP APログとは関連付けられません。これは、APがM4を拒否している理由が、M4がAPにとって無効なフォーマットであるかどうかを分析するのに役立ちます。 最小限の再現: 最小限のZephyrアプリケーションでこの挙動を再現する手順を教えていただけますか?これは、こちら側で再現を試みる際に役立つでしょう。 ご質問について: 最新のZephyrバージョンで作業し、下流リポジトリ(リンク追加)でZephyrメインリポジトリにはないバグ修正をテストすることが推奨されます。 ソフトウェアの仕組みに関しては、この挙動が別のAPでも存在するかを判断する必要があります。したがって、別のAPベンダーでテストを実行することは可能ですが、STA側の状況をより詳細に把握するために、以下のデバッグログを有効にしてみてください。 CONFIG_WIFI_NM_WPA_SUPPLICANT_LOG_LEVEL_DBG CONFIG_WIFI_NM_WPA_SUPPLICANT_DEBUG_LEVEL ご依頼いただいた検査結果についてお知らせください。
記事全体を表示