PNEV7642FAMAパック SDK_2_12_1_PNEV7642FAMA の Keil MDK プロジェクトには PackID NXP.PN7642_DFP.15.0.0 が必要ですが、 https://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.pidxには存在せず、直接パック URL にアクセスすると 404 が返されます。NXPをご提供ください。PN7642_DFP.15.0.0.pack、またはアクセスを有効にしてください。 Re: PNEV7642FAMA pack こんにちは、 @Sinrow さん。 PackID NXP。PN7642_DFP.15.0.0はセキュリティファイルで、NXPとNDAに署名し、このファイルをリクエストする必要があります。

GUI Guider v1.9.0 インストーラーを探しています 現在、GUI Guider v1.9.0で作成されたプロジェクトに取り組んでいます。互換性の理由から、正確なv1.9.0インストーラーを入手する必要がありますが、公式NXPのウェブサイトでは今は新しいバージョンしか提供していません。 Gui-Guider-Setup-1.9.0ファイルはまだ手元にある方や、この古いバージョンをダウンロードできる場所をご存知の方はいらっしゃいますか?また、v1.9.0のプロジェクトを新しいバージョン(例:v1.10.0)で直接開いた場合、互換性の問題は起きませんか? 何か助言やアドバイスがあれば大変ありがたいです。ありがとうございます! Re: Looking for GUI Guider v1.9.0 installer こんにちは@李先森さん 投稿ありがとうございます。GUI Guider v1.9.0のインストーラーは提供されなくなりました。 しかし、GUI Guiderは前回のメジャーバージョンおよび関連するマイナーバージョンで作成されたプロジェクトをアップグレードできます。したがって、GUI Guider v1.10.xを直接使い、GUI Guider v1.9.xで作成されたプロジェクトをインポートできます。 お役に立てば幸いです。 BR セレステ ----------------------------------------------------------------------------------------------------------------------- 注：この投稿があなたの質問への回答になっている場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ -----------------------------------------------------------------------------------------------------------------------

このシステムは、IMX8MPプラットフォーム、SGTL5000サウンドカード、およびLinuxカーネルバージョン5.4.70を使用しています。音声再生時に、カーネルに「アンダーラン」メッセージが表示され、サウンドカードのDMA（データ転送解析）機能が正常に動作しなくなります。 メインコントローラー：imx8mp カーネル: Linux 5.4.70 サウンドカード：SGTL5000 アプリケーション：mmapを使用してデータをDMAバッファに移動します。 障害の症状: アプリケーションが一定時間オーディオを再生すると、カーネルに次のエラーメッセージが表示されます: fsl-sai 30C3000.sai: isr:Transmit。「アンダーランが検出されました」というメッセージが画面に表示され、特定のカーネルファイル（./kernel/kernel-5.4.70/sound/soc/fsl/fsl_sai.c）に対応しています。 .......... if(flags & FSL_SAI_CSR_FEF) { dev_dbg(dev,"isr:送信アンダーランを検出しました\n"); /* 安全のためFIFOをリセット */ xcsr |= FSL_SAI_CSR_FR; } .......... 同時に、`cat /proc/interrupts | grep sdma` コマンドを使用してサウンドカードの DMA 割り込み数をチェックし、増加しないようにします。 現在のコード構成では、FIFOがアンダーランするとFIFOの状態が異常になり、それが原因でDMAが誤動作するというのは本当でしょうか？ IMX8MPの仕様を見ると、次のような説明があります。FCONT: IMX8MP PRMドキュメント14.4.2.7.3。FIFOエラー継続が有効になっている場合、FIFOはアンダーラン後もソフトウェアの介入なしにデータの送信を継続します。データが正しい順序で送信されるようにするため、送信機は、FIFO がアンダーランしたフレーム内の同じワード番号から処理を続行しますが、送信 FIFO に新しいデータが書き込まれた後にのみ続行します。 仕様書に記載されているこの構成によると、この状況でDMAがアンダーランした後でも、正常に動作し続けることができるのでしょうか？DMAがデータをFIFOに移動すれば、以前のDMAが誤動作してFIFOがアンダーランする代わりに、以前のサウンドを再生し続けることができるのでしょうか？ Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 こんにちは@zhuliushun 1. FCONTの理解は基本的に正しいが、FCONTは根本的な解決策ではない。 2. 根本的な原因は、TX FIFOの供給速度が消費速度よりも遅いことです。この点を確認して、原因を特定してください。 3. 次の2つのパッチのインストールを検討してください。 LKML: Shengjiu Wang: [PATCH] ASoC: fsl_sai: 「FIFO continue on error」FCONTビットを有効にする ASoC: fsl_sai: ISR 内の不要な FIFO リセットを削除 - Patchwork よろしくお願いします、 志明 Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 こんにちは@Zhiming_Liu はい、この問題の原因は、FIFOへのデータ充填速度がFIFOのデータ消費速度よりも遅いことです。そして、FIFOへのデータ充填はDMAに基づいています。 1. 現在のデバッグにより、FIFOが空になるとアンダーランが発生し、DMAも動作を停止するため、FIFOが補充されなくなることが明らかになりました。 2.投稿にある 2 つのパッチを適用した後、デバッグの結果、FIFO がまだアンダーランしており、DMA が機能していないことが判明しました。 fsl_sai.c の割り込みコールバック関数 fsl_sai_isr() では、xcsr と tcr4 の値が出力されます。詳細は以下を参照してください。 fsl-sai 30c30000.saiscsr :ステータス:0xd0170c01 fsl-sai 30c30000.sai isr: 送信インダランを検出しました、tcr4: 0x18010f3a 不具合が発生した際、前述の印刷処理によって画面が繰り返し更新された。 3. 2の知見に基づくと、tcr4のbit[28]は=1、 FCONTが有効です。 4. 私の問題について：オーディオファイルの再生がフリーズします（FIFOアンダーラン、DMAが動作しない、停止）。私が望む解決策は、FIFOアンダーランが発生した場合、ハードウェアデータを保持し、リセットせずに現在の状態を移動させ、DMAは正常に動作することです。バッファにデータが利用可能になったとき（アプリケーションがmmapを使用してデータを埋めたとき）、 DMA（FIFOからのDMA要求に基づく）はデータをFIFOに移動し、オーディオファイルの再生を継続できるようにします。これは実現可能でしょうか？

PNEV7642FAMA 包 来自 SDK_2_12_1_PNEV7642FAMA 的 Keil MDK 项目需要 PackID NXP.PN7642_DFP.15.0.0，但该 PackID 在:·https://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.pidx·中缺失，并且直接的 pack URL 返回 404。请提供 NXP.PN7642_DFP.15.0.0.pack 或启用访问权限。 Re: PNEV7642FAMA pack 你好@Sinrow PackID NXP.PN7642_DFP.15.0.0 是安全文件，您需要与 NXP 签署保密协议，然后才能申请此文件。

The system uses an IMX8MP platform, an SGTL5000 sound card, and a Linux kernel version of 5.4.70. When playing sound, the kernel displays an "underrun" message, and the sound card's DMA (Data Transfer Analysis) function malfunctions. Main controller: imx8mp Kernel: Linux 5.4.70 Sound card: SGTL5000 Application: Moves data into the DMA buffer using mmap. Fault symptom: When the application plays audio for a period of time, the kernel displays the error message: fsl-sai 30C3000.sai: isr:Transmit. The "underrun detected" message is printed on the screen and corresponds to the specific kernel file: ./kernel/kernel-5.4.70/sound/soc/fsl/fsl_sai.c. ........... if(flags & FSL_SAI_CSR_FEF) { dev_dbg(dev,"isr:Transmit underrun detected\n"); /* FIFO reset for safety */ xcsr |= FSL_SAI_CSR_FR; } ........... At the same time, use the command `cat /proc/interrupts | grep sdma` to check the DMA interrupt count for the sound card and stop it from increasing. In the current code setup, is it true that when the FIFO goes underrun, the FIFO state becomes abnormal, which in turn causes the DMA to malfunction? Looking at the IMX8MP specifications, there's a description like this: FCONT: IMX8MP PRM document 14.4.2.7.3. When FIFO Continue on Error is enbaled, the FIFO continues transmitting data following an underrun without software intervention. To ensure that data transmits in the correct order, the transmitter continues from the same word number in the frame that caused the FIFO to inderrun, but only after new data writes to transmit FIFO ........................................ According to this configuration in the specification, in this situation, after the DMA goes underrun, can it still work normally? As long as the DMA moves the data to the FIFO, it can continue playing the previous sound, instead of the previous DMA malfunctioning and the FIFO going underrun? Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 Hi @zhuliushun 1. The understanding of FCONT is basically correct, but FCONT is not a fundamental solution. 2. The root cause is that the TX FIFO feeding speed is less than the consumption speed. You can check this to see if it is the case. 3. Consider installing the following two patches: LKML: Shengjiu Wang: [PATCH] ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit ASoC: fsl_sai: Remove unnecessary FIFO reset in ISR - Patchwork Best Regards, Zhiming Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 Hello @Zhiming_Liu Yes, the reason for this problem is that the FIFO filling speed is slower than the FIFO data consumption speed. And FIFO filling is based on DMA. 1. Current debugging has revealed that when the FIFO is depleted, it undergoes an underrun, and the DMA also stops working, thus preventing the FIFO from being refilled. 2. After applying the two patches from the post, debugging revealed that the FIFO still underruns, and DMA is not working . In the interrupt callback function fsl_sai_isr() in fsl_sai.c, the values of xcsr and tcr4 are printed. See below for details: fsl-sai 30c30000.sai scsr :status:0xd0170c01 fsl-sai 30c30000.sai isr: transmit inderrun detected,tcr4: 0x18010f3a When the malfunction occurred, the above-mentioned printing kept refreshing the screen. 3. Based on the findings in 2, bit[28] in tcr4 =1, FCONT is enabled . 4. Regarding my problem: audio file playback freezes (FIFO underrun, DMA not working, stuck). My desired solution is: when the FIFO underruns, preserve the hardware data and move the current state without resetting, while the DMA functions normally . When data becomes available in the buffer (filled by the application using mmap), the DMA (based on the DMA request from the FIFO) moves the data to the FIFO , allowing the audio file to continue playing. Is this feasible?

imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 主控：imx8mp 内核：linux5.4.70 声卡：sgtl5000 应用程序：基于mmap方式，向dma buffer中搬移数据。 故障现象：当应用程序播音一段时间，内核出现 fsl-sai 30C3000.sai：isr:Transmit underrun detected的刷屏打印，对应具体的内核文件：./kernel/kernel-5.4.70/sound/soc/fsl/fsl_sai.c文件。 ........... if(flags & FSL_SAI_CSR_FEF) {      dev_dbg(dev,"isr:Transmit underrun detected\n");      /* FIFO reset for safety*/      xcsr |= FSL_SAI_CSR_FR; } ........... 同时使用指令cat /proc/interrupts | grep sdma 查看声卡对那个的dma中断计数，停止增加。 在目前代码的设置里面，是不是当FIFO出现underrun的情形之后,FIF状态异常，进而导致dma工作异常呢？ 查看imx8mp的规格书，有这样一个描述FCONT:IMX8MPPRM文档 14.4.2.7.3章节。When FIFO Continue on Error is enbaled，the FIFO continues transmitting data following an underrun without software intervention. To ensure that data transmits in the correct order,the transmitter continues from the same word number in the frame that caused the FIFO to inderrun，but only after new data writes to transmit FIFO ............................................ 按照规格书的这段配置，针对这样的情况 是不是出现underrun之后，dma还可以正常工作，只要dma将数据搬移至fifo，就可以继续之前的声音播放，而不是像之前的dma异常工作，而FIFO处于underrun状态呢？ Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 Hi @zhuliushun  1.对FCONT 的理解方向基本正确，但是FCONT不是根本上的解决办法。 2.根本原因还是TX FIFO 投喂速度 < 消耗速度，这个你可以调试看看，是不是这样。 3.可以考虑打入下面的两个补丁： LKML: Shengjiu Wang: [PATCH] ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit ASoC: fsl_sai: Remove unnecessary FIFO reset in ISR - Patchwork Best Regards, Zhiming Re: imx8mp platform,sgtl5000声卡,linux内核版本5.4.70，当声音播放的时候，内核出现underrun的刷屏打印，而且声卡执行数据搬移的dma工作异常。 Hello @Zhiming_Liu  是的，这个问题的原因是FIFO填充慢的速度小于fifo的数据消耗速度。而FIFO填充是基于DMA来实现的。 1.  目前调试发现：当FIFO消耗完之后,FIFO发生underrun,同时dma也不工作，这样也不会填充fifo。 2.  将帖子中的2个patch打入之后,调试发现fifo依然后发生underrun,同时dma不工作。 在fsl_sai.c的中断回调函数中fsl_sai_isr()中，打印出xcsr的值与tcr4的值。具体如下所示： fsl-sai 30c30000.sai  scsr :status:0xd0170c01 fsl-sai 30c30000.sai isr: transmit inderrun detected,tcr4: 0x18010f3a 当故障发生的时候，上述的打印一直在刷屏打印 3.  依据2的发现.tcr4中bit[28] =1,FCONT是使能的。 4.  针对我的问题：播放音频文件卡死问题(fifo underrun,dma不工作,一直卡死)。我的一个期望的解决方案：当fifo发生underrun的时候，保留硬件数据搬移现场,不复位，dma工作正常。等到buffer有数据的时候(应用程序以mmap方式填充buffer)，dma(依据fifo发过来的dma request)将数据搬移至fifo，这样音频文件可以继续接着播放，不知道这样可以实现吗？

TJA1040T/CM,118 → TJA1044CT/0Z Migration: Functional & Software Differences 1. Introduction This document provides a detailed technical comparison between the TJA1040T/CM,118 (now EoL) and its recommended replacement, the TJA1044CT/0Z, with a focus on hardware and software compatibility. Our AH1308 Application Hints explicitly confirm that all Mantis-family transceivers (including the TJA1044) are drop-in replacements for the TJA1040 and TJA1042, as long as the SPLIT pin is not used in the existing design. Several functional differences nevertheless require engineering review, as detailed in the sections below. 2. Quick Reference: Key Differences at a Glance Key Differences.jpg 3. Pin 5: SPLIT vs. NC The TJA1040 provides an active VCC/2 voltage source on Pin 5 (SPLIT) in Normal mode, which is intended to be connected to the centre tap of a split bus termination network to stabilise the common-mode voltage and reduce EME. In Standby mode the SPLIT output is floating. The TJA1044CT pin 5 is internally not bonded (NC). The following scenarios apply: • SPLIT pin was NOT connected in the existing design: No hardware modification required. The two devices are pin-compatible in this configuration. • SPLIT pin WAS connected for split termination: The centre-tap capacitor should be reconnected to GND directly (passive split termination). This may cause a marginal EME difference, which should be verified against OEM requirements. 4. Wake-up Behavior (Key Functional/Software Difference) The TJA1040 implements "basic wake-up" per the older ISO 11898-2 standard: the low-power receiver monitors the bus and asserts RXD LOW as soon as a single continuous dominant phase longer than tBUS (0.75–5 µs) is detected. No pattern is required. The TJA1044CT implements "wake-up pattern" wake-up per ISO 11898-2:2024: a complete dominant–recessive–dominant (D-R-D) pattern must be received before RXD is asserted. Each phase must meet minimum filter requirements and the entire pattern must complete within the wake-up timeout window. Timing parameters.jpg Software impact: confirm the node is woken using a standard CAN wake-up pattern rather than a single dominant edge. Most CAN stacks already generate a WUP, but this should be verified for the end application. 5. TXD Dominant Time-out Both devices provide the TXD dominant time-out fail-safe (the transmitter is disabled if TXD is held LOW). The function behavior is identical, but the timing parameters differ: Screenshot 2026-07-24 090903.jpg The TJA1044 time-out is longer, which lowers the minimum supported bit rate. This is only relevant for very-low-bit-rate designs. 6. Standby-to-Normal Mode Transition Time The transition time from Standby to Normal mode is longer on the TJA1044CT. If the µC firmware drives STB LOW and immediately begins CAN transmission without a guard delay, the first transmitted frames may be corrupted or lost when using the TJA1044CT.  Standby-to-Normal Mode Transition Time.jpg Recommendation: ensure the µC waits a minimum of 47µs after asserting STB LOW before initiating any CAN frame transmission.  7. Undervoltage Detection and OFF Mode  The TJA1040 has two operating modes (Normal, Standby). When VCC is lost, pins TXD/STB/RXD become floating, with no defined bus disengagement. The TJA1044CT introduces a third operating mode, OFF, with two undervoltage detection thresholds on VCC: 7.jpg This is a fail-safe improvement. The bus is properly disengaged (zero load) when VCC is insufficient, preventing an unpowered node from affecting bus communication. No software change is required to benefit from this feature. 8. VCC Range and Additional Electrical Improvements The TJA1044CT offers several electrical improvements over the TJA1040 that are fully backward compatible and require no design changes: 8.jpg 9. Summary of Required Actions 9.jpg

Methods to update NBU firmware on KW47 and MCX W72 This post provides guidance on how to update the NBU firmware on MCX W72 and KW47 devices through several methods: Bootloader Host Application (blhost), Secure Provisioning Tool, LinkServer. The Narrow Band Unit (NBU) is a dedicated compute subsystem for the Narrowband Radio, present in select NXP wireless microcontrollers. It is comprised of an Arm® Cortex®-M33 and associated peripherals that, in conjunction with the Bluetooth Unit, support the Bluetooth LE protocol. Running at 96 MHz alongside a 2.4 GHz transceiver, the NBU operates independently from the main application core, offloading all radio processing from the primary CPU and freeing it for application tasks. While the NBU allows for flexibility for evolving requirements, firmware to implement radio protocols is intended to be developed and delivered by NXP. Note: It is important that the NBU firmware version matches the SDK version of the application. After downloading the SDK and before running any wireless examples, update the NBU firmware using the binaries provided in the SDK folder. The NBU binary file is located in the SDK folder. Go to the SDK root folder and open the path: path_to_SDK\mcuxsdk\middleware\wireless\ble_controller\bin Prerequisites To follow this guide, the following environment is required: Software Setup Bootloader Host Application (blhost). Download here. MCUXpresso Secure Provisioning Tool. Download here. LinkServer for Microcontrollers. Download here. Hardware Setup Development boards associated with the MCX W72 or KW47 microcontroller families may be used. The ISP button varies by board and is referred to as ISP_button  throughout this guide: Development board ISP_button FRDM-MCXW72 SW3 MCXW72-LOC SW4 KW47-EVK SW4 KW47-LOC SW4 To set the board to the Bootloader ISP mode, press and hold the ISP_button , connect the development board via the MCU-Link connector to the PC, then release ISP_button . Bootloader Host Application (blhost) Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. Verify the COM port assigned to the board by opening Device Manager in Windows and searching for Ports (COM & LPT). Identify and note the corresponding COM port number. Open a command prompt and change the directory to the location of the blhost.exe file: (BLHost_root_location)\blhost_2.6.7\bin\win Verify communication by running the following command, making sure to replace COMX with the COM port assigned to your device: blhost.exe -p COMX get-property 1 Update the NBU firmware image. First, erase the NBU memory: blhost.exe -p COMX flash-erase-all 2 Write the new firmware image using the following command. The write-memory command uses 0x48800000 as the start address, which corresponds to the NBU memory base. Provide the full path to the binary file, or alternatively, copy the .bin file into the same directory as blhost.exe to simplify the command: blhost.exe -p COMX write-memory 0x48800000 .bin sofiaurueta_0-1784588034793.png MCUXpresso Secure Provisioning Tool Create a workspace for the device. To use the keys same as the development board, select the processor relevant to the FRDM/EVK board. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. To verify communication, click the UART tab, refresh the Port field selection and select the assigned COM Port identified. Click Test connection and confirm that the result displays OK. In the toolbar, select the boot type as Plain unsigned or Plain with CRC. In the Build Image view, load the binary file in Source executable image, enter the start address as  0x48800000  (which corresponds to the NBU memory base), and click Build image. SECTool_1.jpg Navigate to the Write Image view, select Use built image, and click Write image. SECTool_2.jpg A success message appears when the NBU firmware loading is complete. LinkFlash Tool For this method, a LinkServer debug probe must be available on the board. The steps on how to install the CMSIS-DAP/SEGGER J-link firmware are available here. Navigate to the main LinkServer folder in your computer and execute the  LinkFlash.exe  file. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. In the LinkFlash tool, after the device is connected, click the Refresh button to update and set the probe target of the board. Go to the Program tab, click Browse, select the NBU firmware file, and enter the start address  0x48800000 . Ensure to check the boxes Mass erase before programming and Reset target after programming. To load the NBU firmware, click Program. LinkFlashTool.jpg

How to PORT/PINS 1 Table of Contents • Introduction • Pins Configuration • Configure Port Component • Conclusion • References 2 Introduction Before a microcontroller can interact with external hardware, its pins must be configured correctly. Whether you want to read a button state, drive an LED, communicate with a sensor, or use a peripheral, the first step is to configure the corresponding pins. 3 Pins Configuration First, identify the pin you want to use. In this example, we will use the following pin: RGBLED0_RED PTA29 GPIO29 Note: When working in S32 Configuration Tools, the pin MSCR value (third line) is not required. However, it will be needed later if you also configure the same pins in EB tresos. Configure the pins according to their intended use: input, output, or input/output. To begin, open the Pins Tool by clicking the Pins button in the upper-right corner. configToolView.png In the Pins Tool, the pins are organized into Functional Groups. In the default projects provided with the Model-Based Design Toolbox, these groups are arranged based on the peripheral to which the pins are routed. functionalGroups.png For this step, focus on the Pins tab in the upper-left area of the window. Search for the pin you want to configure; in this example, PTA29. pinPinsView.png If the desired functionality is already routed to a different pin, first disable that routing by clearing the corresponding selection before assigning it to PTA29. Next, update the identifier and label as needed, then enable the routing by selecting the checkbox on the left. This opens the routing selection dialog. selecttypeofsignal.png Select SIUL2:gpio,29 , as it matches the intended functionality. A second dialog then prompts you to select the pin direction. directionofpin.png  In this example, the LED is configured as Input/Output, matching the configuration used by the example project. Depending on the intended use of the pin, a different direction may be required — for example, a push button is typically configured as an input. Additional examples can be found in the default projects provided with the Model-Based Design Toolbox. 4 Configure Port Component The Port component must reflect the same pin configuration defined in the Pins Tool. After returning to the Peripherals Tool, the Port component may be highlighted in red because the pin configuration was modified in the Pins Tool and has not yet been updated in the Port component. PortComponent.png  In the default Model-Based Design Toolbox projects, PortPins are grouped into PortContainers according to their associated peripheral, such as Dio_Pins or Can_Pins . Locate the Dio_Pins PortContainer and update the PortPin entries so that they match the values configured in the Pins Tool. rgbled.png The pin will already contain the MSCR value inherited from the Pins configuration. Update the pin name as desired so it can be easily identified in the model, then repeat the process for each additional pin. The PortPin Id uniquely identifies each PortPin entry. The identifier must remain unique across all PortContainers. Note: If a duplicate PortPin Id value is used, the configuration will report an error. Assign a unique PortPin Id value to each configured pin. For example, a configuration containing 40 pins can use identifiers within the range described by the tool configuration. 5 Conclusion Once the pin configuration is complete and the Port component has been updated accordingly, you can continue with the configuration of the software components that will use those pins. 6 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344

How to DIO 1 Table of Contents • Introduction • Component Configuration  • Conclusion • References 2 Introduction Before configuring the DIO component, make sure that the pins you intend to use have already been configured in both the Pins Tool and the Port component. If not, refer to the previous articles on pins and port configuration. 3 Component Configuration In order to configure the Dio peripheral, press on the Dio component on the left side of the screen for the Dio Configuration tab to be opened. There, press on the Dio Config tab. portpin.png Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. Register half DioPort value AL 0 AH 1 BL 2 BH 3 CL 4 CH 5 DL 6 DH 7 EL 8 EH 9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_RED pin is assigned to PTA29. From that we can conclude that, since 29 is higher than 15 (the 16th value of AL, since the first value is 0), the PTA29 pin must be assigned to the AH register. To reiterate, the PTA0–PTA15 pins belong to the AL register while the PTA16–PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too: PTB, PTC, PTD, PTE. Note: When computing the channel Id for pins in the upper half of a port (e.g. PTA16–PTA31), subtract 16 from the pin number. To create a new channel, select the appropriate DioPort and click the + button next to DioChannel. A new channel entry will be created. Fill in the required channel information according to the pin that was previously configured in the Pins Tool and Port component. ADDNEWCHANNEL.png Repeat this process for each newly configured pin, ensuring that the channel is added under the correct DioPort. 4 Conclusion After configuring the required DioChannels, save the configuration and regenerate the code. The configured DIO channels can then be used by the application to access the corresponding digital inputs and outputs. 5 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344

Software and Hardware Setup for the S32N55 Communication Hub 1 Table of Contents • Introduction • Required Software • Required Hardware • Communication and Board-Specific Setup • References • Conclusion   2 Introduction The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible. Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series. This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system. CristinaB_0-1784806267828.png Figure 1. Position of the Main Node within the system architecture. 3 Required Software The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis. 3.1 Modeling and Application Development The Main Node application is developed as a Simulink model. MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved. The software environment used for this project includes: MATLAB R2024a or newer Simulink Simulink Coder Embedded Coder MATLAB Coder Stateflow These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware. 3.2 Network Definition and Validation Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network. Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system. The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes. Required tools: Vehicle Network Toolbox CANdb++ 3.1 or newer 3.3 Target Support and Code Generation The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package. The toolbox provides: Main target platform support Peripheral integration blocks Build integration Deployment support FreeMASTER integration Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code. 3.4 Build and Configuration Environment After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board. In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow. Together, these tools ensure that the generated software and the target configuration remain aligned throughout development. 3.5 Runtime Monitoring and Validation Once deployed, the Main Node can be observed through two complementary mechanisms. FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network. These tools are used throughout development and validation activities to verify both application behavior and network communication. CristinaB_1-1784806393422.png Figure 2. Development workflow used by the Main Node application. 4 Required Hardware Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution. 4.1 S32N55 Board The Main Node application executes on an S32N55 board selected for the central application role. Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways. The board provides: CAN FD communication interfaces UART communication interfaces Debug and deployment connectivity I2C peripherals Processing resources required by the Main Node application The Main Node target board is the primary hardware platform referenced throughout this article series. 4.2 Host PC The host PC provides the environment used to interact with the full setup. Depending on the activity being performed, it may host: MATLAB and Simulink RoadRunner simulation environments FreeMASTER Lite CAN analysis software The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER. 4.3 CAN Analyzer A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways. Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled. 5 Communication and Board-Specific Setup Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup. 5.1 Communication Topology The Main Node does not communicate directly with every vehicle-domain node. Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes. This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently. 5.2 CAN Transceiver Initialization One hardware-specific detail of the target board concerns the external CAN transceiver. Note: Before CAN communication becomes available, the transceiver must first be switched from standby mode into normal operation. This transition is not controlled directly through a dedicated GPIO. Instead, it is performed through an I2C-connected port expander located on the board. As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication. CristinaB_2-1784806522309.png Figure 3. CAN transceiver enable sequence on the target board. 5.3 FreeMASTER Telemetry Interface In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite. This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time. 6 References Model-Based Design Toolbox (MBDT) Community NXP S32N Vehicle Super-Integration Processors MathWorks Vehicle Network Toolbox NXP FreeMASTER Run-Time Debugging Tool 7 Conclusion This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network. Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board. The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.

IW611 RU 设置 我想请教一下如何设置RU。 对于射频测试，技术人员参照“UM11749”手册第12章进行RU设置测试。但是，当我们编辑配置文件“TF_Config_20MHz.txt”时按照第 12.6 章的示例加载后，输出波形类似于未调制信号，我们无法确认预期的波形。 由于输出的是波形，我们认为文件已正确加载。 配置文件描述如下。 =================================================================== FRAME_CTRL_TYPE=1 \\IEEE_TYPE_CONTROL FRAME_CTRL_SUBTYPE=2 \\TRIGGER 配置持续时间字段 最大持续时间 帧持续时间=5484 \\0x156C 配置触发帧的通用信息字段 HE_trigger_frame.TrigCommonField.TriggerType = BASIC_TRIGGER; \\ HE_trigger_frame.TrigCommonField.UlLen = 1000; \\ 最大限度 HE_trigger_frame.TrigCommonField.MoreTF = FALSE; HE_trigger_frame.TrigCommonField.CSRequired = FALSE; HE_trigger_frame.TrigCommonField.UlBw = TB_BW_20MHZ; HE_trigger_frame.TrigCommonField.LTFType = LTF_1_GI_1_6uS; HE_trigger_frame.TrigCommonField.LTFMode = MU_MIMO_SINGLE_STREAM; HE_trigger_frame.TrigCommonField.LTFSymbol = 0; HE_trigger_frame.TrigCommonField.UlSTBC = FALSE; HE_trigger_frame.TrigCommonField.LdpcESS = TRUE; HE_trigger_frame.TrigCommonField.ApTxPwr = 0 HE_trigger_frame.TrigCommonField.PreFecPadFct = 1; HE_trigger_frame.TrigCommonField.PeDisambig = 0; HE_trigger_frame.TrigCommonField.SpatialReuse = 65535; HE_trigger_frame.TrigCommonField.Doppler = FALSE; HE_trigger_frame.TrigCommonField.HeSig2 = 0x1FF; 保留 TrigCommonField=0;1000;0;0;0;1;0;0;0;1;0;1;0;65535;0;511 配置触发帧的用户信息字段 HE_trigger_frame.TrigUserInfoField.AID12 = (5 & 0xFFF); HE_trigger_frame.TrigUserInfoField.RUAllocReg = 0; HE_trigger_frame.TrigUserInfoField.RUAlloc = 61; 53 (106 音调) HE_trigger_frame.TrigUserInfoField.UlCodingType = CODING_TYPE_LDPC; HE_trigger_frame.TrigUserInfoField.UlMCS = 0; HE_trigger_frame.TrigUserInfoField.UlDCM = FALSE; HE_trigger_frame.TrigUserInfoField.SSAlloc = 0; HE_trigger_frame.TrigUserInfoField.UlTargetRSSI = 80; TrigUserInfoField=5;0;61;1;0;0;0;80 配置触发信号依赖用户信息字段 HE_trigger_frame.BasicTrigUserInfo.MPDU_MU_SF = MPDU_SPACING_MULT_1; \\ HE_trigger_frame.BasicTrigUserInfo.TID_AL = 0; HE_trigger_frame.BasicTrigUserInfo.AC_PL = FALSE; HE_trigger_frame.BasicTrigUserInfo.Pref_AC = TB_AC_VO; BasicTrigUserInfo=0;0;0;0 =================================================================== 如果此描述有任何错误，请告知我。 另外，如果还有其他方法（不使用文件的方法），请告诉我。 Re: IW611 RU setup 你好@SA2 能否提供测试日志和捕获到的频谱图？ 顺祝商祺！ 肖恩 Re: IW611 RU setup 你好，肖恩。 感谢你的回复。 我分享一下光谱图的截图。 captured spectrum.png Re: IW611 RU setup 你好@SA2 能否分享一下您在标准样机和待测设备 (DUT) 上执行的命令？包括实验室工具返回值 顺祝商祺！ 肖恩 Re: IW611 RU setup 你好，肖恩。 在下达命令之前，我们想确认一些事情。 我们已经复习了第 12 章，但所有射频测试都必须使用传导测量进行。 （测试时，被测器件样品通过SMA电缆连接到频谱分析仪进行传导测量。） 因此，如果我们只使用一组被测器件进行传导测量，是否应该参考第 12.2 章？ Re: IW611 RU setup 你好@SA2 建议采用标准测试方法进行测量。这样我们就可以轻松地与测试报告进行比较，并找出是否存在任何问题。 顺祝商祺！ 肖恩

LPC54S018をSPI-MRAM（MR25H40）から起動します。 私はLPC54S018を搭載したEVB LPC54S018M-EVKを購入し、それにSPI-MRAMチップ=MR25H40を接続します。 SPI-MRAM（MR25H40）からLPC54S018にファームウェアをロードする必要があります。MRAMをFLEXCOMM9に接続しました。ファームウェアからこのMRAMへのデータの読み書きは正常にできますが、問題ありません。でもMCUを起動できません。 オシログラムでは(RESET後に)マイクロコントローラのブートROMコードがMRAMと通信し始めるのがデフォルト速度=12 MHz(起動ROMがウェイクアップコマンド(opcode = 0xAB)を送信し、その後「read JEDEC-ID」コマンドを3回送信します(opcode = 0x9F))。その後、SPI上ではそれ以上の活動は発生しない。ウェイクアップコマンドはMRAMによって正常に処理されますが、「JEDEC-ID読み取り」コマンドはメモリによってサポートされていません（MRAMのデータシートによる）。私は、ブートROMコードが「JEDEC-IDの読み取り」コマンドに対する応答を受け取らなかったため、デフォルトの速度で起動を続行するだけだと思っていました。しかし、理由は不明だが、「JEDEC-IDの読み取り」を3回試みた後、ブートプロセスがキャンセルされる。 LPC54S018のISPピンを以下の状態に設定してみました。 1) または ISP0 = high、ISP1 = high、ISP2 = high; 2) または ISP0 = high、ISP1 = low、ISP2 = high。 何も変わりません。マイクロコントローラが起動しません。 「read JEDEC-ID」コマンドへの応答を待たずに、SPIメモリからLPC54S018の起動を続行する方法はありますか？ 追伸：負荷処理のオシログラムを添付します。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). LPC540xxをSPI-MRAM（MR20H40/MR25H40）から起動することは不可能であるようです。SPI-MRAMは「read JEDEC-ID」コマンドをサポートしていないためです。 😞😞 しかし、SPI-FRAM(SPI-MARMとは異なり)は「read JEDEC-ID」コマンドをサポートしています。SPI-MRAMをSPI-FRAM（FM25V05）に交換したところ、LPC54S018の起動に成功しました！しかし、FM25V05では、ファームウェアはアドレス0x0000からではなく、0x0001から開始する必要があります。「read JEDEC-ID」コマンドの後、LPC540xxブートROMはまず24ビットアドレスを持つ読み出しコマンド0x03をSPIメモリに送信します。読み取りが失敗した場合は、32ビットのアドレスを持つ読み取りコマンド0x03を送信します。FM25V05は16ビットのアドレスを持ちます。しかし、ブートイメージをアドレス0x0001にシフトすると、LPC540xxはFM25V05からでも正常にブートします。ブートROMでは24ビットの読み取りコマンドが使われるため、最初のバイト読み込みは省略されます。 添付のオシログラムを参照してください。 後で、24ビットアドレス指定が可能なCY15B104QN（SPI-FRAM）からの起動を試してみます。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). こんにちは、 @jcxzさん ボードが正常に起動したと聞いて大変嬉しく思います。 他に何かご質問やご不明な点はありますか？ よろしくお願いします。 BR アリス Re: Boot LPC54S018 from SPI-MRAM (MR25H40). はい。次に、CY15B104QN-50SXI SPI-FRAMからの起動を試みました。機能しません 😞 CY15B104QNからは起動しません。このチップは「JEDEC-ID読み取り」コマンドに応答しますが、しかし、CY15B104QN は逆バイト順の JEDEC-ID を出力します: "00,2C,C2,7F,7F,7F,7F,7F,7F" (16 進数)。おそらくそれが、LPC54018のブートROMがそこから起動しない理由でしょう。 FM25V05は「7F,7F,7F,7F,7F,7F,C2,23,00」(16進数)の形式でJEDEC-IDを出力します。LPC54018ブートROMはこれを受け入れて起動します。しかし、FM25V05の容量は私のプロジェクトには小さすぎます。 それでは、FM25V20Aから起動してみます。そこから起動してくれるといいのですが。 PS: CY15B104QNは、新世代のSPI-FRAMチップである「EXCELON™ F-RAM」（Infineon社製）に属します。どうやらLPC54018ブートローダーはそれらをサポートしていないようです。 Re: Boot LPC54S018 from SPI-MRAM (MR25H40). FM25V20A-GからLPC54018を正常に起動できました！ LPC54018のMRAM/FRAMブート機能チェックの最終結果： 1. SPI-MRAM (MR25H40) からのブート:失敗。考えられる原因＝JEDEC-ID読み取りコマンドがサポートされていない。 2. SPI-FRAM CY15B104QN からのブート、JEDEC-ID = "00,2C,C2,7F,7F,7F,7F,7F,7F" (16 進数):失敗。考えられる原因＝ブートROMがJEDEC-IDを認識していない。 3. SPI-FRAM FM25V20A-G からブート中、JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,25,08" (16 進数):成功。考えられる理由＝ブートROMがJEDEC-IDを認識している。 4. SPI-FRAM FM25V05 からブート、JEDEC-ID = "7F,7F,7F,7F,7F,7F,C2,23,00" (16 進数):成功。考えられる理由：ブートROMがJEDEC-IDを認識している。ただし、ブートイメージはアドレス1（0ではない）に配置する必要があります。 しかし、CY15B104QNのメモリファミリは新しいです。これは旧型のFM25Vxxの後継機種です。したがって、CY15B104QNを使用したいと思います。CY15B104QNからのブートがサポートされていないのはなぜですか？また、FUTUREのLPC540xxのリビジョンでは、CY15B104QN(またはこのファミリの他のチップ)からの起動機能は追加されるのでしょうか?

LPC54113 电源 API 我想了解如何使用“power”函数的API。通过 SDK，我发现这个函数可以直接用于某些函数。但是，与 IAP API 不同，它没有提供入口点或使用说明。 1123HENRY_0-1784703504100.png 1123HENRY_1-1784703542044.png LPC541XX Re: LPC54113 Power API 嗨@jcxz 是的，你说得对。 您可以参考其他 SDK，其中包含有关 POWER API 的更详细说明。 BR 爱丽丝 Re: LPC54113 Power API 通过下载 54 系列其他芯片的 SDK，我找到了 POWER_Type 和 POWER_BASE。谢谢。 Re: LPC54113 Power API 对于我的 LPC54S018，我从 NXP 网站下载了 SDK。它包含了 PowerAPI、ClockAPI 等函数。 例如：POWER_SetVoltageForFreq(...)等。 它还描述了调用 API 函数的入口点和原型。 我认为LPC54113的情况也类似。

TJA1120A RGMIIモード - 遅延設定 これはTJA1120Aのデバイスツリーです - cpsw_port1、cpsw3g_phy0 &cpsw_port1 { status = "okay"; phy-mode = "rgmii-txid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { compatible = "ethernet-phy-id001b.b031"; reg = <4>; }; cpsw3g_phy1: ethernet-phy@1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; }; ここでは、TJA1120Aのphy-modeとして「rgmii-txid」を指定します。 しかし、レジスタRGMII_TXC_DELAY_CONFIGを読み取ると、 0x0014が読み取られ、これは遅延なし（15ビット目）を意味し、 RGMII_RXC_DELAY_CONFIGは0x8014を読み取り、これは遅延が設定されている（15ビット目）ことを意味します。 また、DTでphy-modeを「rgmii-rxid」に変更すると、 RGMII_RXC_DELAY_CONFIGは0x0014、 RGMII_TXC_DELAY_CONFIGは0x8014になります。 DTで「rgmii」を設定し、phytoolを使用してこれらのレジスタを設定してみましたが、完全に反映され、pingが開始され、その後RGMII_RXC_DELAY_CONFIGの15ビット目がHIGHに設定され、 RGMII_TXC_DELAY_CONFIGの15ビット目がLOWに設定されました。 物理モードのDT設定において、なぜこのような反転現象が発生するのかを理解したい。 私たちのAM62A7ベースのECUでは、PCBがRX_Clockの内部遅延を必要としているため、「rgmii-txid」が設定されました。問題なく動作しています。 また、DTSが処理してくれるのであれば、このPHYモードにおけるピンストラップの使用についても知りたいです。 Re: TJA1120A RGMII Mode- Delay Config こんにちは、 TJA1120Aドキュメントによると、RGMIIの遅延構成はレジスタ名とレジスタ内で記述された遅延が直接一致しないため、やや混乱を招くことがあります。 デバイスDS内のRGMII_RXC_DELAY_CONFIG/RGMII_TXC_DELAY_CONFIGレジスタのビット説明を参照してください。 0xAFCC RGMII_RXC_DELAY_CONFIG: ビット15 = 内部TXC遅延を有効にする 0xAFCD RGMII_TXC_DELAY_CONFIG: ビット15 = 内部RXC遅延を有効にする   したがって、設定を確認する際に重要なのは、実際のレジスタビットの記述と初期化後の最終レジスタ読み返し値です。 また、ピンストラップはリセット後のデフォルト設定のみを定義する点に注意してください。ソフトウェアドライバは後でMDIOでこれを上書きできるため、システム起動後にレジスタを読み返すことで有効な構成を検証する必要があります。 また、同じRGMIIクロック遅延がMAC側とPHY側の両方で有効化されていないかも、基板のタイミング設計で意図されていないことを確認してください。 BR、ペトル

RT1010/RT1011 FLEXIO EDMA 我使用 iMX RT1011 Nano 套件 不错的板 我尝试从移位器 0 设置 8 位并行的 EDMA Flexio。 定时器 0 设置为 30MHz，EDMA 发送 512 字节（每个请求 1 字节） 代码： FLEXIO_DEV->SHIFTCTL[TX_SHIFTER] = FLEXIO_SHIFTCTL_TIMSEL(WR_TIMER) | FLEXIO_SHIFTCTL_TIMPOL(0U) | FLEXIO_SHIFTCTL_PINCFG(3U) /* 输出 */ | FLEXIO_SHIFTCTL_PINSEL（DATA_PIN_START） | FLEXIO_SHIFTCTL_PINPOL(0U) | FLEXIO_SHIFTCTL_SMOD(2U); /* 传输 */ /* 定时器0：写保护选通，每字节一个脉冲 * TIMCMP 低字节 = (flexio_clk / (2*wr_clk)) - 1 * TIMCMP[15:8] = (beats*2)-1 = 1，表示每次移位加载一个字节 */ timDiv = (flexioClk_Hz / (2U * wrClock_Hz)); 如果 (timDiv != 0U) { timDiv -= 1U; } timDiv &= 0xFFU; FLEXIO_DEV->TIMCMP[WR_TIMER] = (1U << 8U) | FLEXIO_DEV->TIMCMP[WR_TIMER] = (1U << 8U) |蒂姆迪夫； FLEXIO_DEV->TIMCFG[WR_TIMER] = FLEXIO_TIMCFG_TIMOUT(1U) | FLEXIO_TIMCFG_TIMDEC(0U) | FLEXIO_TIMCFG_TIMRST(0U) | FLEXIO_TIMCFG_TIMDIS(2U) /* 禁用比较 */ | FLEXIO_TIMCFG_TIMENA(2U) /* 高触发时启用 */ | FLEXIO_TIMCFG_TSTOP(0U) | FLEXIO_TIMCFG_TSTART(0U); FLEXIO_DEV->TIMCTL[WR_TIMER] = FLEXIO_TIMCTL_TRGSEL((4U * TX_SHIFTER) + 1U) /* Shifter0 标志 */ | FLEXIO_TIMCTL_TRGPOL(1U) /* 低电平有效 */ | FLEXIO_TIMCTL_TRGSRC(1U) /* 内部 */ | FLEXIO_TIMCTL_PINCFG(3U) /* 输出 */ | FLEXIO_TIMCTL_PINSEL（WR_PIN） | FLEXIO_TIMCTL_PINPOL(1U) /* WR 低电平有效 */ | FLEXIO_TIMCTL_TIMOD(1U); /* 双 8 位波特率/位 */ /* 启用来自 Shifter0 的 DMA 请求 */ FLEXIO_DEV->SHIFTSDEN |= (1U << TX_SHIFTER); /* 启用 FlexIO */ FLEXIO_DEV->CTRL |= FLEXIO_CTRL_FLEXEN_MASK； 我在逻辑分析仪上看到了信号。 看起来和我预期的一样，但我在某些 512 包中发现数据缺失。 我的意思是，比如先发送 200 字节，然后停止，之后再发送所有 512 个字节。 扎希 Re: RT1010/RT1011 FLEXIO EDMA 你好@TZAHI ， 非常感谢您对我们产品的关注以及对我们社区的使用。 最有可能的检查方向是：在 30 MHz WR 时钟下，eDMA 能否足够快地持续填充 FlexIO SHIFTBUF。 在当前每次请求传输一个字节的配置下，DMA 请求速率可能会非常高。这对于 eDMA、总线仲裁和 FlexIO SHIFTBUF 重新填充时间来说可能非常紧张。 一个可能的症状是变速箱换挡器运转不畅。请在传输失败后立即检查 SHIFTERR，然后再重新初始化或清除 FlexIO： mayliu1_0-1784792340391.png 如果可能的话，请尝试提高 CPU/总线时钟频率，或者将 WR 时钟频率降低到 30 MHz 以下，例如降低到 20 MHz 或 10 MHz。如果传输在较低的 WR 时钟频率下变得稳定，则强烈表明该问题与 DMA/FlexIO 的重新填充时序有关。 希望对你有帮助 顺祝商祺！ 5月

晶振波形异常 你好，@ lukaszadrapa 我们公司在使用贵公司的FS32K144HFT0MLHT这款MCU， 使用晶振为AV08000009这款8MHz的无源晶振，波形异常。请问这样的晶振波形 贵公司的MCU可以接受吗 是否会影响MCU的正常使用吗 IMG_20260718_141710.jpg Re: 晶振波形异常 嗨@Kyp 示波器截图似乎没有显示实际的 8 MHz 晶体波形。显示的频率（~256 Hz）与预期的振荡器频率不一致，很可能是由于所选示波器时基和采样率引起的混叠所致。因此，仅凭这一测量结果无法评估晶振（晶体振荡器）的质量。应该使用速度快得多的时基来观察实际的振荡器波形。 此致， Lukas Re: 晶振波形异常 HI ,lukaszadrapa   非常抱歉 ,我们用重新测了一下波形,图片如下 晶振波形.png 麻烦分析一下,有什么好的建议

S32K388 HSE_SWT Reboot for Fresh Chip flashing I have a fresh S32K388 which I'm trying to flash with some from-scratch firmware (this is not AUTOSAR nor RTD). I have the IVT setup to only boot core0, and I have hse_fw_header_start_address just set to zero. It appears though that this configuration is leading to resets with the MC_RGM DES reporting: 0x00000041 and the MC_RGM FES reporting 0x00010000 which, based on my reading on the S32K3XXRM, implies that HSE watchdog timeouts are leading to a destructive reset based on escalation. The interesting thing is that this behavior seems to go away when I connect with a j-link, but I can't seem to find a way to disable or service the SWT from my firmware. Do I need to download/install the standard HSE FW for the S32K388? Is there a reason this is required on the S32K388 and not on the S32K344? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing With some further testing - if I clear all the flags in MC_RGM FES/DES after reading them (so they're not sticky across boots), the boot loop starts to return: FES: 0x00010000 and occasionally DES: 0x00000040 (but most of the time DES: 0x00000000) And for clarity for the original post, I have the boot configuration word in the IVT set to 0x00000001 - which would seem to imply, in my reading, that only CM7_0_ENABLE is set and there shouldn't be any HSE/SWT_0 setting at all? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing Based on this post: https://community.nxp.com/t5/S32K/What-does-it-mean-HSE-SWT-RST-on-S32K311/m-p/1955147 And this image of S32K3xx_DCF_clients.xlxs from an older version of the S32K3XXRM: https://community.nxp.com/t5/S32K/S32K388-HSE-No-Response-Error/m-p/2090937/highlight/true?lightbox-message-images-2090937=336074i0A601700196531EB#M48394 It appears I may have solved my problem by writing: 0x40000101 0x00100006 to 0x1B000770in the UTEST memory sector (putting "2" into HSE_CLK_MODE_AND_GSKT_CTRL). In the current revision of S32K3xx_DCF_clients.xlxs, the description of HSE_CLK_MODE_AND_GSKT_CTRL is as follows: Screenshot From 2026-07-24 09-14-40.png But in the S32K3XXRM, I can't find a reference to what I should be configuring in the gasket configuration (the closest looks like "HSE_B" but the table refers to an impossible 1:1 configuration): Screenshot From 2026-07-24 09-22-01.png Is this just a documentation update failure? Should I have a 1:4 ratio in HSE_CLK_MODE_AND_GSKT_CTRL if I'm using Option A++ clocking (CORE_CLK at 160MHz, AIPS_SLOW_CLK at 40MHz)? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing And just in case my other comment turns out to not be the solution: The chip I am using is labelled S32K388HHMJBS 0P39J CTAJ2507E - let me know if you need me to read some registers for specific chip information HSE Firmware has never been installed - this is a factory-fresh device which I have only flashed with my bare-metal code For the IVT: hseFwHeaderStartAddr is zero recovery_app_start_address is zero I am uncertain which fields to provide from the IVT but everything is basically zero except the header set to 0x5AA55AA5, the boot_config set to 1, and the cm7_0_start_address set to the interrupt vector table I already provided the DES and FES I was getting in the original post, but let me know if those were unclear I will try and get this uploaded - I need to get approval to post this code publicly Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing As a quick correction - I meant to write "HSE_CLK at 160MHz and AIPS_SLOW_CLK at 40MHz" for that last sentence in the above comment. Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing Could you please provide: The exact S32K388 part number and chip revision being used. Confirmation whether HSE firmware has ever been installed on the device (or whether this is a completely blank/factory-fresh device). The IVT configuration, especially the values of hseFwHeaderStartAddr, appBootAddr, and any other HSE-related IVT fields. The complete reset status register dump after the reset (MC_RGM_DES, MC_RGM_FES, and any other relevant reset registers). Whether the issue occurs on multiple devices or only on a single board. A minimal project/application that reproduces the issue, or at least the startup code sequence executed before the reset occurs. At the moment it is not clear whether the reset is caused by HSE/SBAF, an application issue, or a device configuration issue, so the above information will help identify the root cause. Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing As far as we can tell - this has solved the issue. I would like to see the documentation updated to reflect that Option A++ requires this gasket change @davidtosenovjan 

Using IMX95 in MCUXpresso Secure Provisioning Tool Version 26.06 I have download imx-oei-master on github and use make to generate oei-m33-ddr.bin and oei-m33-tcm.bin. And I try to build image as picture attach. I have some questions: 1. Is my setting correct? 2. In "Type", I saw many of items. I don't know which one I need to select? 3. In "Load address" and "Entry point", Is my setting is correct or not? I only saw CM33_TCMU_OFFSET = 0x1ffc0000 in oei-m33-ddr.map. I even didn't see about lpddr5 4. In "Image Type", I also saw many of items. I don't know which one I need to select? By the way what is the difference between "Type" and "Image Type" 5. In "Container set", which one I should select Primary or Secondary image? Re: Using IMX95 in MCUXpresso Secure Provisioning Tool Version 26.06 Please refer to the guidance here for building i.MX95 boot images: https://docs.mcuxpresso.nxp.com/secure/26.06/06_processor_specific_workflow.html#i-mx-95-bootable-image-examples It has detailed description and snapshot about what images are needed. Also note that the ddr quick boot binaries can be selected for i.MX95 B0 devices while adding image "OEI DDR no QB" as below:   image-2026-07-24-17-41-23-792.png   image-2026-07-24-17-40-38-998.png   Re: Using IMX95 in MCUXpresso Secure Provisioning Tool Version 26.06 Thanks for your quickly reply.

LPC54113 Power API 「power」関数のAPIの使い方を知りたいです。SDKを通じて、この関数は特定の関数に直接使えることがわかりました。しかし、iap APIとは異なり、エントリーポイントや使用方法に関する説明は提供されていません。 1123HENRY_0-1784703504100.png 1123HENRY_1-1784703542044.png LPC541XX Re: LPC54113 Power API こんにちは、 @jcxzさん はい、おっしゃる通りです。 POWER APIのより詳細な説明を含む他のSDKを参照することもできます。 BR アリス Re: LPC54113 Power API 54シリーズの他のチップのSDKsをダウンロードすることで、私はPOWER_TypeとPOWER_BASEを見つけることができました。ありがとうございます。 Re: LPC54113 Power API 私のLPC54S018はNXPのウェブサイトからSDKをダウンロードしました。PowerAPI、ClockAPIなどの機能が含まれています。 例えば、POWER_SetVoltageForFreq(...) など。 また、API関数を呼び出すためのエントリーポイントとプロトタイプについても説明しています。 LPC54113についても同様だと思います。