Imx6ull KSZ8041NL ethernet issue Hello There , To utilize dule ethernet for one of our potential project , We have connected 2 Ethernet phy with Imx6ull processor , One phy is KSZ8081 and one phy is KSZ8041 , below is our DTS configuration : &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1: ethernet-phy@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1: enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; Both The Ethernet Phys are getting detected in kernel logs and also when we connect ethernet  cable , link is also getting detected on both. but Ip is arriving on ethernet which is connected to KSZ8081 phy , the IP is not getting assigned with the Ethernet which is connected to KSZ8084NL. and there is rx errors are observed in KSZ8041NL Ethernet which is eth0 , below are the logs : root@sls-imx6ull14x14evk:~# ifconfig eth0      Link encap:Ethernet  HWaddr BA:9C:69:1F:76:3A           UP BROADCAST MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:1065 dropped:0 overruns:0 frame:1065           TX packets:65 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:0 (0.0 B)  TX bytes:12024 (11.7 KiB) eth1      Link encap:Ethernet  HWaddr 42:19:11:7F:5E:89           inet addr:10.20.0.184  Bcast:10.20.1.255  Mask:255.255.254.0           inet6 addr: fe80::8248:9837:9647:2a00/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:18 errors:0 dropped:0 overruns:0 frame:0           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2494 (2.4 KiB)  TX bytes:3162 (3.0 KiB) lo        Link encap:Local Loopback           inet addr:127.0.0.1  Mask:255.0.0.0           inet6 addr: ::1/128 Scope:Host           UP LOOPBACK RUNNING  MTU:65536  Metric:1           RX packets:17 errors:0 dropped:0 overruns:0 frame:0           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2011 (1.9 KiB)  TX bytes:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 Settings for eth0:         Supported ports: [ TP    MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Supported FEC modes: Not reported         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Advertised FEC modes: Not reported         Link partner advertised link modes:  10baseT/Half 10baseT/Full                                              100baseT/Half 100baseT/Full         Link partner advertised pause frame use: No         Link partner advertised auto-negotiation: Yes         Link partner advertised FEC modes: Not reported         Speed: 100Mb/s         Duplex: Full         Auto-negotiation: on         Port: Twisted Pair         PHYAD: 3         Transceiver: external         MDI-X: Unknown         Supports Wake-on: g         Wake-on: d         Link detected: yes   We have also checked the clock which is 50MHz , which is generated properly and also coming into phy KSZ8041NL. In short 1 Ethernet with KSZ8081 is working properly but 2nd Ethernet not working with KSZ8041NL. Please suggest us solution. we have also attached screenshot of both Ethernet phy Hardware  for your reference . image (1).png image (2).jpg i.MX6 All i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Team , Is there any update for us for our asked query ? Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Support Team, We have already shared details about Ethernet issue which we are facing at our end.  So, would you please check it from your end and let us know resolution if anything from your end?  If needed then we will be available over call to discuss issue with your team as well. Waiting for positive feedback from your team end.  Regards, Ritesh Prajapati Re: Imx6ull KSZ8041NL ethernet issue Hello @HarshilSoni434 @ritesh_prajapat  Hope you are doing very well. Looking at your KSZ8041 schematic's Strapping Option: Manuel_Salas_0-1785172670273.png Isolate Mode: Pull-up (Default) = Enable Pull-Down = Disable The PHY disconnects its RMII data pins (RXD0, RXD1, CRS/DV, RX_ER, TXD0, TXD1, TX_EN) from the MAC. MDIO/MDC remains fully functional and PHY is discovered, link pulse is still generated and maybe this is why the PHY appears detected and link is UP. Can you please try Changing R37 from pull-up to a pull-down resistor (~4.7kΩ to GND) on the ISOLATE pin? The second thing to check is the Reset Pin. Can you please confirm that the reset is properly asserted? And check the reset_n signal is according connected to the: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; Then, please check the CONFIG[2:0] Strapping for RMII are physically well asserted. Also, in the KSZ8041 schematic's signal mapping table: Manuel_Salas_1-1785173206995.png The net names appear swapped (MDC labeled as enet_mdio and vice versa). Best regards, Salas. Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas , Thank you for your response , As per your suggestion , We have done the pull-down resistor change and checked the Ethernet communication , Unfortunately the behavior is same. We are getting RX-errors during IP Negotiation. We have also verified the below points : - The reset pin is proper based on imx6ull pin connection. we have also applied manual pulse on reset line , the phy (KSZ8041NL) is getting reset but the behavior is same. - The MDIO and MDC pin swap is the schematic issue , the connection is proper in actual hardware . So the behavior is same after changes , Both Phy is getting detected but IP is coming with KSZ8081 only not with KSZ8041NL. below is the updated log : root@sls-imx6ull14x14evk:~# dmesg | grep fec [ 2.124528] fec 20b4000.ethernet eth0: registered PHC device 0 [ 2.207221] fec 2188000.ethernet eth1: registered PHC device 1 [ 72.966866] fec 20b4000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root@sls-imx6ull14x14evk:~# dmesg | grep eth0 [ 2.124528] fec 20b4000.ethernet eth0: registered PHC device 0 [ 72.966866] fec 20b4000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root@sls-imx6ull14x14evk:~# ifconfig eth0 Link encap:Ethernet HWaddr 26:F5:A6:8C:73:42 inet6 addr: fe80::f2af:2d7a:228c:2038/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:63 dropped:0 overruns:0 frame:63 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:2093 (2.0 KiB) eth1 Link encap:Ethernet HWaddr 22:81:A6:66:8C:3A UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:91 errors:0 dropped:0 overruns:0 frame:0 TX packets:91 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7797 (7.6 KiB) TX bytes:7797 (7.6 KiB) root@sls-imx6ull14x14evk:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: g Wake-on: d Link detected: yes Please provide us the your suggestion for the same. Re: Imx6ull KSZ8041NL ethernet issue Thanks @Manuel_Salas for providing suggestions from your end. We will check all things suggested from your end and will post results mostly by today. Regards, Ritesh Prajapati Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas we have done further debugging into ethernet fec driver fec_main.c for identifying the rx error root-case. So we found that driver is ignoring all the rx-packets due to CRC mismatch error BD_ENET_RX_CR. so based on this , please provide your suggestion for issue resolution . Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas  , Based on our last observation , is there any update for us .? just updating you again that all the rx-packets are ignored due to CRC error. so what can be the cause of it ? Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas , Good Morning, Did you get a chance to review last couple of updates regarding issue which @HarshilSoni434 has already shared to you? Can you please look into it and let us know if you have any clue or any further findings from your end to narrow down exact issue of CRC mismatch failed for receive packet?  Let us know if need any information from our end.  Regards, Ritesh Prajapati

LPC55S69 与 SPI - DMA - 关联或乒乓传输无缘 这件事已经拖得太久了...... 我看过单次 SPI/DMA 传输的示例，这些都能正常工作。 我看过 DMA/链接内存传输的示例，这些都能正常工作。 但没有一个能满足我的要求，我想尽办法也找不到合适的。 我需要一个使用 DMA 的自由运行 SPI TX/RX，既可以是链接配置，也可以是乒乓启动。 这里肯定有人已经做到了这一点，愿意分享一些知识？ 到目前为止，我所能做到的最好的方法是为 SPI_DMA 设置一组链接配置，这些配置只执行一次（尽管最后一个链接会返回到第一个链接），然后停止。 更糟糕的是，链接 16 位传输只需一次 8 位传输。 我已经没有办法了，而且很确定我现在正在尝试一些已经失败的事情。 有人吗？ 概述 LPC55xx 外设 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 我知道这是个老帖子了，但不管怎样......问题与您的 Tx 传输宽度有关。要配置 fifo，必须是 32 位（16 个数据 + 16 个 cfg），否则 spi 中的所有配置位都是 0，就会出现您遇到的问题。 --格拉 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 你好@IanMcCarthy 我想对延误表示歉意。这些天，我们正在试验一个正常的问题量。真的非常感谢你们的耐心。 关于你的问题，一旦你进行一次手动启动（在调试会话中运行），所有代码都必须无限期运行，来自SPI的SCK必须生成2个以上的脉冲（持续直到你按停止）。请问您使用的是 LPC55S69 SDK 中的哪个示例？您对代码做了哪些修改？这样我就可以在我的板上重现你的代码，看看发生了什么。 非常感谢你们的帮助。如果您有更多问题，请告诉我。 致以最崇高的敬意 巴勃罗-阿瓦洛斯 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 第三次尝试发布更新... 我需要以固定速率持续接收来自从属SPI设备的数据（手动触发不符合要求）。 下面的代码显示了我目前所做的工作，但这只是生成 2 个 SPI 时钟增量，仅此而已。 我想一旦配置了 SPI，就可以配置一组关联的 DMA 描述符，然后手动启动一次，就可以无限期运行，还是我弄错了？ 如果有人愿意帮忙，将不胜感激。 srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 我还没完全理解你的回答，你能再解释一下吗？为什么不保留传输的 uint8_t 宽度？ 我还注意到函数 DMA_SetupDescriptor() 的第 3 个和第 4 个输入参数位置不正确。 此外，每个描述符目标地址是否应该将数据重定向到另一个内存位置，而不是全部指向 &masterTxData？

Safety documentation for sCheck integration Device: NXP S32K388 microcontroller Components: SAF Package -  SW32K3_SAF_1.0.6_HF01_D2603, sCheck plugin ( SRAM ECC test) Available artifacts: S32K3xx Reference Manual (S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf, sCheck UserManual, sCheck SRAM ECC test source code. Gap: lack of end-to-end tehnical specification, device register mapping, dependecny interactions and expected outcomes. Release Note : specifies that following release has limitations Information requested: Precise safety goal(s) and ECC scheme assumed Which SRAM instances/banks/partitions are in scope and out of scope on S32K388 Step-by-step flow including initialization, fault injection method, verification, and restoration Required operating conditions (clock, MPU/XRDC settings, caches/TCM state, run-from-RAM/Flash) Cross-plugin preconditions/postconditions; example initialization sequence across components Version compatibility matrix for SAF/sCheck/eMcem/SafetyBase on S32K388 Pass/fail criteria, result codes, and how to interpret them Interrupts, NMI, or error reporting paths used; hooks/callbacks for application-level handling Re: Safety documentation for sCheck integration Hello, For sCheck integration, please refer primarily to the sCheck User Manual, especially the chapter"Software Integration". This chapter contains the integration requirements, assumptions, memory section definitions, linker file updates, MPU configuration requirements, and any test-specific prerequisites. In addition to the sCheck User Manual, please review the corresponding S32K3 Safety Manual, which identifies the safety mechanisms covered by sCheck (SM2.*.SCHECK) and explains their role within the overall safety concept. The SAF documentation package also contains module-specific integration guidance for the other SAF components (sBoot, mSel, eMCEM, BIST, etc.). The integration requirements are therefore distributed across the SAF module User Manuals rather than being collected in a single standalone safety integration document. As a minimum, we recommend reviewing: sCheck User Manual → Software Integration sCheck User Manual → Conditions, Limitations and Side Effects S32K3 Safety Manual → safety mechanisms covered by SAF/sCheck SAF integration documentation for linker, MPU, startup, and API integration requirements These documents provide the information required to integrate sCheck into a safety application. Best regards, Peter

sCheck統合のためのセーフティドキュメント デバイス:NXP S32K388 マイクロコントローラ コンポーネント:SAFパッケージ - SW32K3_SAF_1.0.6_HF01_D2603、sCheckプラグイン(SRAM ECCテスト) 利用可能なアーティファクト:S32K3xxリファレンスマニュアル (S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf、ユーザーマニュアルを確認し、SRAM ECC テストのソースコードを確認してください。 ギャップ：エンドツーエンドの技術仕様、デバイスレジスタマッピング、依存関係の相互作用、および期待される結果が不足している。 リリースノート：以下のリリースには制限事項があることを明記します 要求された情報： 正確なセーフティ目標とECCスキームの仮定 S32K388において、どのSRAMインスタンス/バンク/パーティションが対象範囲内であり、どのSRAMインスタンス/バンク/パーティションが対象範囲外であるか 初期化、故障注入方法、検証、復元を含むステップバイステップのフロー 必要な動作条件（クロック、MPU/XRDC設定、キャッシュ/TCM状態、RAM/フラッシュからの起動） プラグイン間の前提条件／事後条件。コンポーネント間の初期化シーケンスの例。 S32K388上のSAF/sCheck/eMcem/SafetyBaseのバージョン互換性マトリックス 合否判定基準、結果コード、およびその解釈方法 割り込み、NMI、またはエラー報告経路の使用;アプリケーションレベルのハンドリングのためのフック/コールバック Re: Safety documentation for sCheck integration こんにちは、 sCheck統合については、主にsCheckユーザーマニュアル、特に「ソフトウェア統合」章を参照してください。この章では、統合要件、前提条件、メモリセクションの定義、リンカファイルの更新、MPU構成要件、およびテスト固有の前提条件について説明します。 sCheckユーザーマニュアルに加え、対応するS32K3セーフティマニュアルもご確認ください。そこではsCheck(SM2.*.SCHECK)でカバーされているセーフティ機構が記載され、全体的なセーフティ概念における役割を説明しています。 SAFのドキュメントパッケージには、他のSAFコンポーネント(sBoot、mSel、eMCEM、BISTなど)に関するモジュール固有の統合ガイダンスも含まれています。したがって、統合要件は単一の独立したセーフティ統合文書にまとめられるのではなく、SAFモジュールのユーザーマニュアル全体に分散されています。 最低限、以下の項目を確認することをお勧めします。 sCheck ユーザーマニュアル → ソフトウェア統合 sCheck ユーザーマニュアル → 状態、制限および副作用 S32K3 セーフティマニュアル → SAF/sCheckで扱われる安全機構 リンカー、MPU、スタートアップ、API統合要件に関するSAF統合ドキュメント これらの書類は、sCheckをセーフティアプリケーションに統合するために必要な情報を提供します。 よろしくお願いいたします。 ピーター

SENT Protocol Hi community I am trying to figure out how to implement SENT protocol on S32K311 PCB board for position detection of Actuator as it has position sensor. As NXP doesn't have Block set related to SENT protocol. It will be a great help if someone is willing to share. Re: SENT Protocol Hi@Ganesh808 If you are using S32 DS + RTD, our S32 DS example code provides a demo of implementing the SENT protocol using flexio. Senlent_0-1785740424865.png If you are using MBDT, here's a similar answer I've seen: https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/SENT-Protocol-Support-in-S32K3-MBDT/td-p/1775025 If you are developing a project using MBDT and encounter any problems, please ask in the MBDT forum next time. This is a dedicated forum for answering MBDT questions.

Can an eBike motor get wet? Yes! An eBike motor can get wet from rain, mud, and splashing puddles, but it is water-resistant, not waterproof. This means your eBike can handle normal wet weather, but it will suffer severe damage if it gets submerged in deep water or blasted with a pressure washer. Using the Himiway D5 2.0 as a reference, here is everything you need to know about how your motor handles water, its safety limits, and how to maintain it after a wet ride. Can an eBike motor get wet.png Real-World Boundaries: What's Safe vs. What's Dangerous The Himiway D5 2.0 is an all-terrain fat-tire eBike built to handle mud, rain, and off-road trails. However, its powerful 750W rear hub motor still operates under key physical limits. What is safe: Riding through steady rain, splashing through shallow puddles, navigating wet off-road trails, and wiping down your frame with a damp cloth or soft brush. What is dangerous: Riding through deep streams or flooded streets where water reaches the center of the wheel hubs, riding in torrential downpours for hours, or using a high-pressure hose. High-pressure water forces moisture past rubber gaskets and into internal electronics. The "Thermal Vacuum" Risk: When you push your Himiway D5 2.0 hard up a steep hill, the hub motor warms up. If you immediately plunge that hot motor into a cold puddle or creek, the air inside contracts rapidly. This sudden cooling creates a vacuum effect that can pull moisture past the seals and directly into the internal circuitry. Understanding Ingress Protection (IP) Ratings Most eBikes use standard IP (Ingress Protection) ratings to define how well their motors and battery systems resist dust and moisture: IP Rating Level of Protection Real-World Application IPX4 Splashes from any angle Light drizzle and small splashes IPX5 Low-pressure water jets Moderate rain and road spray (Standard for Himiway D5 2.0 components) IPX6 Powerful high-pressure jets Heavy downpours and thick mud spray IPX7 Temporary submersion Shallow submersion up to 30 mins (Rarely found on standard eBikes) Note on the Himiway D5 2.0: The D5 2.0's motor, battery, and display screen carry solid IPX5/IPX6-equivalent weather sealing. It is engineered to keep wet trail spray and heavy rain out, provided the seals are not blasted with high pressure. 4 Rules for Wet Weather Maintenance Taking care of your eBike after a wet ride keeps the electronics dry and prevents corrosion over time. Ditch the Pressure Washer: Stick to a bucket of warm water, a gentle soap, a soft brush, and a low-pressure garden hose spray if needed. Dry Key Components Immediately: After riding through rain or mud, use a micro-fiber towel to wipe down the rear motor casing, display, throttle controls, and battery contacts. Never Store It Wet: Park your bike in a warm, dry room or garage so lingering surface humidity can evaporate naturally. If water got near the battery housing, drop the battery out to let the compartment air dry. Don't Power On a Flooded Bike: If you suspect deep water reached the interior of the motor or controller, leave the power off. Allow the bike to dry completely for 24 to 48 hours before turning it back on to avoid short-circuiting the system.

SPC入力がWUUに伝わらず、デバイスが起動しない [MCXN947との連携] SPCでは、低電力モードとアクティブモードの両方で、電圧検出割り込みを有効にしています（リセットは無効）。アクティブモードはリセットを無効にし、バンドギャップを有効にしています。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a WUUでSPCをウェイクアップソースとして有効にしました（WUU->MEビットが設定されています）。 SPC割り込みはアクティブモードで動作しますが、電源オフモードでは動作しません。つまり、プロセッサはSPC割り込みを処理するためにウェイクアウトしません。 MCX N Re: SPC input to WUU not waking device おそらく動作しているとは思うが、アクティブモードとパワーダウンモードでは反応に大きな違いがある。アクティブモードでは、SPC割り込みはより迅速に応答し、繰り返し発生しますが、パワーダウンモードからは、割り込みが発生するまでに非常に時間がかかり、一度しか発生しません。 Re: SPC input to WUU not waking device こんにちは、 @robert_hines さん。 電源オフモードからのウェイクアップレイテンシは、アクティブモードの割り込み応答時間よりも長くなると予想されます。電源オフモードでは、MCUの大部分が静的状態にあります。より深い低消費電力モードに入る際のトレードオフの一つは、そのモードの入り出時にレイテンシが増えることです。 割り込みが一度だけ発生する問題については、アプリケーションコードの処理に問題があるのではないかと疑っています。SDKに含まれるpower_mode_switch例を参照し、実装とあなたのコードを比較していただけますか? それでも問題が解決しない場合は、FRDM-MCXN947ボード上で問題を再現できる簡単なプロジェクトを提供してください。喜んでさらに詳しく調査いたします。 よろしくお願いします。 BR アリス Re: SPC input to WUU not waking device 状況は以下のとおりです。 - FreeRTOSへの移植 - 低電力タイマーを使用して、PM_EnterLowPower()で電源オフモードに移行します。 - IRQHandlers は setFromISR() と portYIELD_FROM_ISR() を使用します - 高優先度タスクがISRで設定されたイベントビットを待機している場合、xEventGroupWaitBits() - 一部の割り込みはWUUを経由して電源オフモードで利用可能にしており、外部ピンの一部(正常に動作しているようです)や、SPCが遅い/応答しない点を除き、問題なく動作する内部モジュール(VBAT、LPTMR、TDET、SPC)も含まれます。 - SPC割り込みはIRQHandlerで無効化され、イベントビットの設定を待つ高優先度タスクで処理された後に再有効化されます。この待機タスクはイベント情報ビットのプロセッシング後に再び PM_EnterLowPower() を呼び出します。 問題は、SPC割り込みが他の割り込みと同じように応答しないことだ。プロセッサが起動しても再びスリープに戻り、再びトリガーされません。アクティブモードで電源が切れても、発火は続けます(PM_EnterLowPower()でプロセッサを再び電源オフモードに戻せません)。

[i.MX95/AAOS16]ブリングアップ支援 ハードウェア: i.MX95 15x15 SW: AAOS16_1.3.0 ほぼすべてのファイルにパッチを適用しました。 しかし、カーネル起動の問題は依然として残っている。 リチャード・キムのサポートが必要です。 Re: [i.MX95/AAOS16] Bringup support こんにちは、 @Jaeheon-Sim_Mobis さん、 改訂版ガイドラインを添付いたしましたのでご確認ください。 また、パッチされたすべてのファイルを正しいディレクトリ構造で添付しているので、ソースツリーで直接上書きできるようにしています。 よろしくお願いします。 Re: [i.MX95/AAOS16] Bringup support これは15x15サイズのFRDM-MX95にも使えますか？ Re: [i.MX95/AAOS16] Bringup support いいえ、それらのパッチはi.MX95 15x15 EVKをベースにしたカスタムボード用です。

采用LCU互补PWM和死区时间实现6步BLDC换向的推荐方法是什么？ 大家好， 我正在使用S32K311 开发一个三相无刷直流电机六步换向项目： 用于 PWM 生成的 eMIOS TRGMUX 拉库 GD3000闸门驱动器 RTD 5.0.0 我的相位映射图是： U_HS = eMIOS ch0 U_LS = eMIOS ch1 V_HS = eMIOS ch2 V_LS = eMIOS ch3 W_HS = eMIOS ch4 W_LS = eMIOS ch5 我使用以下 LUT 值： #define LCU_LUT_OFF 0x0000U #define LCU_LUT_PWM 0xAAAAU #define LCU_LUT_INV_PWM 0x5555U #define LCU_LUT_ON 0xFFFFU 最初，我通过在每个扇区动态更改查找表 (LUT) 来实现换向： Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); V+ / W- 示例： Emios_Pwm_Ip_SetDutyCycle(EMIOS_INSTANCE, PWM_CHANNEL_V_HS, activeDuty); LCU_LutList[PWM_CHANNEL_V_HS].Value = LCU_LUT_PWM; LCU_LutList[PWM_CHANNEL_V_LS].Value = LCU_LUT_INV_PWM; LCU_LutList[PWM_CHANNEL_W_LS].Value = LCU_LUT_ON; Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); 出现了一个奇怪的问题： 如果在循环之前配置一次 V_HS，则会出现 PWM。 进入换向循环并反复调用 Lcu_Ip_SetSyncOutputLutControl() 后，V_HS 停止切换，而其他通道继续工作。 这让我不禁思考，动态同步 LUT 更新是否是电机换向的正确方法。   我的主要问题 对于S32K311 + GD3000 ，推荐的架构是什么？ 3对互补的PWM对 死时间插入 六步换算 安全切换 我应该： 保持 LCU LUT静态（PWM / INV_PWM），仅通过改变LCU 输出使能/覆盖状态来执行换向？ 是否使用 Lcu_Ip_SetOutputLutControl()（立即更新）代替 Lcu_Ip_SetSyncOutputLutControl()？ 完全避免动态 LUT 重写？   死时间问题 我想利用 LCU 生成具有死区时间的互补 PWM 。 预期方法是否为： 使用 eMIOS 仅生成 3 个基本 PWM（U、V、W）， 将它们通过 TRGMUX 路由到 LCU， 使用固定 LUT：HS = 0xAAAA LS = 0x5555 在LCU输出/滤波器设置中配置死区时间， 然后仅更改每个换向扇区的输出启用/覆盖设置？ 如果 NXP 有示例（RTD 或 MBDT）演示了带有 LCU 互补 PWM 和死区时间插入的 6 步 BLDC ，我将非常感激您提供参考，引用。 谢谢！ Re: Recommended way to implement 6-step BLDC commutation with LCU complementary PWM and dead time? 您好@Esakki 您可以参考以下链接中的电机解决方案，您可以在此页面找到演示代码和应用程序节点： https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTE1AK344 例如，在 BLDC 的六步法中，改变电机的旋转方向通常不是通过更新 LCU 的状态来实现的，您可以查看我们的演示代码和应用程序节点。

发送协议 大家好 我正在尝试弄清楚如何在 S32K311 PCB 板上实现 SENT 协议，以检测致动器的位置，因为它有一个位置传感器。由于 NXP 没有与 SENT 协议相关的块集。如果有人愿意分享，那将对我们非常有帮助。 Re: SENT Protocol 您好@ Ganesh808 如果您正在使用 S32 DS + RTD，我们的 S32 DS 示例代码提供了一个使用 flexio 实现 SENT 协议的演示。 Senlent_0-1785740424865.png 如果你使用的是 MBDT，以下是我见过的一个类似答案： https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/SENT-Protocol-Support-in-S32K3-MBDT/td-p/1775025 如果您在使用 MBDT 开发项目时遇到任何问题，请下次在 MBDT 论坛中提问。这是一个专门用于回答MBDT问题的论坛。

S32K3 DMA logic link channel Hello, How should I use the DMA logic link channel function (major loop or minor loop)? I use channel 0 to link to channel 1. Why does channel 0 complete the transport and cause an interruption, but channel 1 does not transport any data. Attached is my test project BR Jason 回复： S32K3 DMA logic link channel Jason22_0-1785726345456.png This configuration needs to be checked

eバイクのモーターはCAN濡れることはありますか? はい！eバイクのモーターは雨や泥、水たまりで濡れることがありますが、水道ではなく水道耐性があります。 つまり、eバイクは通常の雨天にも耐えられますが、深い水道に浸かったり高圧洗浄機で洗浄したりすると大きな損傷を受けます。 Himiway D5 2.0を参考にして、モーターの水道の扱い方、セーフティ限界、そして濡れた走行後のメンテナンス方法について知っておくべきことをすべてご紹介します。 Can an eBike motor get wet.png 現実世界の境界線：安全なものと危険なもの Himiway D5 2.0は、泥道、雨天、オフロードコースにも対応できるよう設計された、全地形対応のファットタイヤ電動自転車です。しかし、その強力な750Wリアハブモーターは、依然としていくつかの物理的な限界の中で動作する。 安全な走行方法：降り続く雨の中を走行すること、浅い水たまりをはためきながら走ること、濡れたオフロードを走行すること、そしてフレームを湿らせた布や柔らかいブラシで拭くこと。 危険なこと:深い小川や水没した通りを走り、水道がホイールハブの中心に達すること、豪雨の中を何時間も走ること、または高圧ホースの使用。高圧の水道はゴム製ガスケットを通って湿気を内部の電子機器に送り込みます。 「熱真空」のリスク: Himiway D5 2.0 を急な坂道で強く押すと、ハブモーターが熱くなります。熱くなったモーターをすぐに冷たい水たまりや小川に浸けると、内部の空気が急速に収縮します。この急激な冷却により真空効果が発生し、湿気がシールを越えて内部回路に直接引き込まれます。 侵入保護等級（IP等級）の理解 ほとんどの電動自転車は、モーターとバッテリーシステムが粉塵や湿気にどれだけ耐えられるかを定義するために、標準的なIP（侵入保護）規格を使用しています。 IP評価 保護レベル 実世界でのアプリケーション IPX4 あらゆる角度からの飛沫 小雨と小さな水しぶき IPX5 低圧水道噴射 中程度の雨と路面からの水しぶき（Himiway D5 2.0コンポーネントの標準仕様） IPX6 強力な高圧ジェット 激しい豪雨と濃い泥しぶき IPX7 一時的な水没 最大30分間の浅い水没に耐える（一般的な電動自転車ではめったに見られない機能） Himiway D5 2.0に関する注記：D5 2.0のモーター、バッテリー、およびディスプレイ画面は、IPX5/IPX6相当の優れた防水性能を備えています。シール部分に高圧が加えられない限り、濡れた路面からの水しぶきや激しい雨を防ぐように設計されています。 雨天時のメンテナンスに関する4つのルール 雨天走行後に電動自転車を適切に手入れすることで、電子機器を乾燥した状態に保ち、経年劣化による腐食を防ぐことができます。 高圧洗浄機をやめましょう:温かい水道の入ったバケツ、優しい石鹸、柔らかいブラシ、必要なら低圧のガーデンホーススプレーを使いましょう。 キー部品をすぐに乾燥させる:雨や泥の中を走った後は、マイクロファイバータオルでリアモーターケース、ディスプレイ、スロットルコントロール、バッテリーお問い合わせを拭き取ってください。 濡れた状態で保管しないでください:自転車は暖かく乾燥した部屋やガレージに停め、表面の湿気が自然に蒸発しやすくしましょう。もし水道がバッテリーハウジングの近くに入った場合は、バッテリーを抜いてコンパートメントを自然乾燥させてください。 浸水したバイクの電源を入れないでください:モーターやコントローラの内部に深い水道が達していると疑われる場合は、電源を切ったままにしてください。システムのショートを防ぐため、バイクの電源を入れる前に、24時間から48時間かけて完全に乾燥させてください。

S32K3 DMA 逻辑链路通道 你好， 我应该如何使用DMA逻辑链路通道功能（主循环或次循环）？我使用通道 0 连接到通道 1。为什么通道 0 完成了传输并导致中断，而通道 1 没有传输任何数据？ 附件是我的测试项目 BR 杰森 回复： S32K3 DMA logic link channel Jason22_0-1785726345456.png 需要检查此配置。

LCU補完PWMとデッドタイムを用いた6ステップBLDC整流を実装するための推奨方法は？ こんにちは、皆さん 私は S32K311を用いて3相のBLDCの6ステップ通勤プロジェクト に取り組んでいます。 PWM生成用eMIOS TRGMUX LCU GD3000ゲートドライバー RTD 5.0.0 私の位相マッピングは次のとおりです。 U_HS = eMIOS ch0 U_LS = eMIOS ch1 V_HS = eMIOS ch2 V_LS = eMIOS ch3 W_HS = eMIOS ch4 W_LS = eMIOS ch5 私は以下のLUT値を使用しています。 #define LCU_LUT_OFF 0x0000U #define LCU_LUT_PWM 0xAAAAU #define LCU_LUT_INV_PWM 0x5555U #define LCU_LUT_ON 0xFFFFU 当初、私は各セクターごとにLUTを動的に変更することで、以下の方法で切り替えを実装しました。 Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); V+ / W- の例: Emios_Pwm_Ip_SetDutyCycle(EMIOS_INSTANCE, PWM_CHANNEL_V_HS, activeDuty); LCU_LutList[PWM_CHANNEL_V_HS].Value = LCU_LUT_PWM; LCU_LutList[PWM_CHANNEL_V_LS].Value = LCU_LUT_INV_PWM; LCU_LutList[PWM_CHANNEL_W_LS].Value = LCU_LUT_ON; Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); 奇妙な問題が発生する： ループの前に一度V_HSを設定すると、PWMが利用可能になります。 整流ループに入り、Lcu_Ip_SetSyncOutputLutControl()を繰り返し呼び出すと、V_HSはスイッチングを停止しますが、他のチャネルは動作を続けます。 このことから、動的に同期されたLUT更新がモーター整流にとって正しいアプローチなのかどうか疑問に思った。   私の主な質問 S32K311 + GD3000の場合、推奨されるアーキテクチャは何ですか？ 3つの相補的なPWMペア デッドタイム挿入 6ステップ整流 安全なスイッチング 私はすべきでしょうか？ LCU LUT（PWM / INV_PWM）を静的に保ち、 LCU出力の有効/オーバーライド状態を変更するだけで整流を実行しますか？ Lcu_Ip_SetSyncOutputLutControl() の代わりに Lcu_Ip_SetOutputLutControl() (即時更新) を使用してください。 動的なLUT書き換えを完全に回避する？   暇つぶしの質問 LCUを使用して、デッドタイム付きの相補PWMを生成したいと考えています。 意図された方法は以下の通りです: eMIOSで3つの基本PWM（U、V、W）のみを生成します。 TRGMUX を介して LCU にルーティングします。 固定LUTを使用する：HS = 0xAAAA LS = 0x5555 LCU出力/フィルタ設定でデッドタイムを設定します。 そして、各整流セクターの出力有効化/オーバーライドのみを変更するのですか？ NXPのサンプル（RTDまたはMBDT）で、LCUによる相補型PWMとデッドタイム挿入を用いた6ステップBLDCモーターの動作を示すものがあれば、ぜひご紹介いただけると幸いです。 ご回答をお待ちしています。 Re: Recommended way to implement 6-step BLDC commutation with LCU complementary PWM and dead time? こんにちは、 Esakkiさん。 以下のリンクで「Out Motor Solution」をCANを参照できます。デモコードとアプリケーションノードはこのページでご覧いただけます: https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTE1AK344 例えば、BLDCの6ステップ方法では、モーターの回転方向を変えるのは通常LCUの状態を更新しても達成できません。デモコードとアプリケーションノードをご覧ください。

电动自行车电机可以进水吗？ 是的！电动自行车电机可能会被雨水、泥浆和溅起的水坑弄湿，但它是防水的，不是完全防水的。 这意味着您的电动自行车可以应对一般的潮湿天气，但如果浸入深水中或被高压水枪冲洗，则会遭受严重损坏。 以Himiway D5 2.0为参考，引用，以下是您需要了解的有关电机如何处理水、其功能安全限制以及如何在湿滑路面行驶后对其进行维护的所有信息。 Can an eBike motor get wet.png 现实世界的界限：什么是安全的，什么是危险的 Himiway D5 2.0 是一款全地形胖胎电动自行车版本，专为应对泥泞、雨天和越野路段而设计。然而，其强大的 750W 后轮毂电机仍然受到关键物理限制的影响。 安全行为包括：在持续的雨中骑行、溅过浅水坑、行驶在潮湿的越野小径上，以及用湿布或软刷擦拭车架。 危险行为包括：骑车穿过水淹到车轮轮毂中心的深溪流或被洪水淹没的街道；在暴雨中骑行数小时；或使用高压水枪。高压水流会将水分压过橡胶垫圈，渗入内部电子元件。 “热真空”风险：当您用力推着 Himiway D5 2.0 上陡坡时，轮毂电机就会发热。如果你立即将滚烫的发动机浸入冰冷的水坑或小溪中，发动机内部的空气会迅速收缩。这种突然的冷却会产生真空效应，可以将水分吸入密封件之外，直接进入内部电路。 了解防护等级（IP） 大多数电动自行车使用标准的 IP（防护等级）来定义其电机和电池系统防尘防潮的性能： IP防护等级 实际应用 IPX4 任何角度溅起的水花 毛毛细雨和零星小雨 IPX5 低压水射流 中等雨量和路面溅水（Himiway D5 2.0 元器件的标准配置） IPX6 强劲的高压喷射 暴雨倾盆，泥浆飞溅 IPX7 暂时浸没 浅水浸泡时间最长可达 30 分钟（标准电动自行车很少具备此功能） 关于 Himiway D5 2.0 的说明：D5 2.0 的电机、电池和显示屏具有可靠的 IPX5/IPX6 等效防水密封性能。它经过特殊设计，可以防止潮湿的路面溅水和暴雨进入，前提是密封件不受高压冲击。 雨天维护的 4 条规则 雨天骑行后妥善保养电动自行车，可以保持电子元件干燥，防止长期腐蚀。 别用高压清洗机：只需一桶温水、温和的肥皂、软刷，必要时可用低压花园水管喷水即可。 立即擦干关键元器件：在雨中或泥泞中骑行后，使用超细纤维毛巾擦拭后电机外壳、显示屏、油门控制装置和电池触点。 切勿潮湿存放：将自行车停放在温暖干燥的房间或车库中，以便残留的表面湿气能够自然蒸发。如果水溅到电池仓附近，请取出电池，让电池仓风干。 不要启动进水的自行车：如果您怀疑深水已进入电机或控制器内部，请保持电源关闭。为避免系统短路，请让自行车完全干燥 24 至 48 小时后再重新启动。

SPC 输入到 WUU 未唤醒设备 [与 MCXN947 合作] 我在 SPC 中启用了电压检测中断（禁用复位），无论是在低功耗模式还是运行模式下（禁用复位，启用带隙）。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a 我已在 WUU 中启用 SPC 作为唤醒源（WUU->ME 位已设置）。 SPC 中断在运行模式下工作，但在掉电模式下不工作，即处理器不会唤醒来处理 SPC 中断。 MCX N Re: SPC input to WUU not waking device 我觉得它可能在工作，但是工作模式和断电模式下的响应速度差异很大。在运行模式下，SPC 中断响应速度更快，会反复触发；但在掉电模式下，触发信号中断所需的时间要长得多，而且只会触发信号一次。 Re: SPC input to WUU not waking device 嗨@robert_hines 预计从断电模式唤醒的延迟时间将比运行模式下的中断响应时间长。在断电模式下，MCU 的大部分功能处于静态状态。进入更深层次的低功耗模式的弊端之一是进入和退出该模式时延迟会增加。 关于中断只发生一次的问题，我怀疑可能是应用程序代码处理方面存在问题。请您参考 SDK 中包含的 power_mode_switch 示例，并将实现方式与您的代码进行比较？ 如果问题仍然存在，请提供一个简单的项目，以便在 FRDM-MCXN947 板上重现该问题。我很乐意进一步调查此事。 谢谢！ BR 爱丽丝 Re: SPC input to WUU not waking device 上下文是： - FreeRTOS 移植 - 使用低功耗定时器进入关机模式，命令为 PM_EnterLowPower()。 - IRQHandlers 使用 setFromISR() 和 portYIELD_FROM_ISR() - 一个高优先级任务正在等待 ISR 中设置的事件位，xEventGroupWaitBits() - 一些中断通过 WUU 路由，以便在掉电模式下可用，包括一些外部引脚（似乎工作正常）和一些内部模块（VBAT、LPTMR、TDET、SPC），这些模块似乎工作正常，但 SPC 速度慢/无响应。 - SPC 中断在 IRQHandler 中被禁用，并在等待事件位设置的高优先级任务处理完毕后重新启用。该等待任务在处理事件位后还会再次调用 PM_EnterLowPower()。 问题在于SPC中断的响应方式与其他中断不同。当处理器被唤醒后，它会再次进入睡眠状态，并且不会再次发出触发信号。当它在运行模式下关闭时，它会继续触发（PM_EnterLowPower() 无法将处理器恢复到关机模式）。

Recommended way to implement 6-step BLDC commutation with LCU complementary PWM and dead time? Hi everyone, I am working on a 3-phase BLDC 6-step commutation project on S32K311 using: eMIOS for PWM generation TRGMUX LCU GD3000 gate driver RTD 5.0.0 My phase mapping is: U_HS = eMIOS ch0 U_LS = eMIOS ch1 V_HS = eMIOS ch2 V_LS = eMIOS ch3 W_HS = eMIOS ch4 W_LS = eMIOS ch5 I use the following LUT values: #define LCU_LUT_OFF 0x0000U #define LCU_LUT_PWM 0xAAAAU #define LCU_LUT_INV_PWM 0x5555U #define LCU_LUT_ON 0xFFFFU Initially I implemented commutation by dynamically changing the LUTs every sector using: Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); Example for V+ / W-: Emios_Pwm_Ip_SetDutyCycle(EMIOS_INSTANCE, PWM_CHANNEL_V_HS, activeDuty); LCU_LutList[PWM_CHANNEL_V_HS].Value = LCU_LUT_PWM; LCU_LutList[PWM_CHANNEL_V_LS].Value = LCU_LUT_INV_PWM; LCU_LutList[PWM_CHANNEL_W_LS].Value = LCU_LUT_ON; Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); A strange issue occurs: If I configure V_HS once before the loop, PWM is present. After entering the commutation loop and repeatedly calling Lcu_Ip_SetSyncOutputLutControl(), V_HS stops switching, while the other channels continue to work. This made me wonder whether dynamic synchronized LUT updates are the correct approach for motor commutation.   My main question For S32K311 + GD3000, what is the recommended architecture for: 3 complementary PWM pairs dead-time insertion 6-step commutation safe switching Should I: Keep the LCU LUTs static (PWM / INV_PWM) and perform commutation only by changing LCU output enable/override states? Use Lcu_Ip_SetOutputLutControl() (immediate update) instead of Lcu_Ip_SetSyncOutputLutControl()? Avoid dynamic LUT rewriting completely?   Dead-time question I would like to generate complementary PWM with dead time using the LCU. Is the intended method to: Generate only 3 base PWMs with eMIOS (U, V, W), Route them through TRGMUX to the LCU, Use fixed LUTs: HS = 0xAAAA LS = 0x5555 Configure dead time in the LCU output/filter settings, And then change only the output enable/override for each commutation sector? If there is an NXP example (RTD or MBDT) that demonstrates 6-step BLDC with LCU complementary PWM and dead-time insertion, I would greatly appreciate a reference. Thank you! Re: Recommended way to implement 6-step BLDC commutation with LCU complementary PWM and dead time? Hi@Esakki you can refer to out motor solution in the link below, you can find the demo code and application node in this page: https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTE1AK344 For example, in the six-step method for BLDC, changing the rotation direction of the motor is usually not achieved by updating the state of the LCU, you can take a look at our demo code and application node.

[i.MX95/AAOS16] 启动支持 硬件：i.MX95 15x15 软件版本：AAOS16_1.3.0 我们修补了几乎所有文件。 但是，仍然存在内核启动问题。 需要理查德·金的支持。 Re: [i.MX95/AAOS16] Bringup support 你好@Jaeheon-Sim_Mobis ， 请查收附件中的修订版指南。 我还附上了所有已打补丁的文件，并附上了正确的目录结构，以便您可以直接在源代码树中覆盖它们。 谢谢！ Re: [i.MX95/AAOS16] Bringup support 这个适用于 15x15 frdm-mx95 吗？ Re: [i.MX95/AAOS16] Bringup support 不，这些补丁是为基于 i.MX95 15x15 EVK 的定制板准备的。

S32K3 DMAロジックリンクチャネル こんにちは、 DMAのロジックリンクチャネル機能(メジャーループかマイナーループか)はどのように使えばよいでしょうか?チャネル0を使ってチャネル1に接続しています。なぜチャネル0はトランスポートを完了して中断を引き起こすのに、チャネル1はデータを一切転送しないのでしょうか。 テストプロジェクトを添付します。 BR ジェイソン 回复： S32K3 DMA logic link channel Jason22_0-1785726345456.png この設定を確認する必要があります

SENTプロトコル こんにちは、コミュニティの皆さん。 位置センサが付いているアクチュエータの位置検出のためにS32K311基板上でSENTプロトコルを実装する方法を模索しています。NXPはSENTプロトコルに関連するブロックセットを持っていません。どなたか情報を共有していただけると大変助かります。 Re: SENT Protocol こんにちは、@ Ganesh808 S32 DS + RTD を使用している場合は、弊社の S32 DS サンプルコードに flexio を使用して SENT プロトコルを実装するデモが含まれています。 Senlent_0-1785740424865.png MBDTを使用している場合、以下のような同様の回答を見たことがあります。 https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/SENT-Protocol-Support-in-S32K3-MBDT/td-p/1775025 MBDTを使用してプロジェクトを開発していて問題が発生した場合は、次回からはMBDTフォーラムで質問してください。ここはMBDTに関する質問に答えるための専用フォーラムです。