BLDC Motor Direction measurement using TRIGMUX+eMIOS Description : I am using NXP recommended solution for 6 step commutation to drive my BLDC motor. As per the App note "https://community.nxp.com/t5/S32M-Knowledge-Base/S32M276-Hall-sensor-based-6-step-BLDC-motor-control/ta-p/2035021#jump_PwmAndTriggers" Hall Sensor output is going to TRIGMUX and then LCU for commutation and also for calculating the speed signal. This article does not mention how the motor direction can be measured. Is there any NXP solution to measure motor direction? My understanding is that to measure direction we need to capture all the 3 Hall sensor outputs using an input capture unit. Is it feasible to configure my eMIOS channels as follows. CH0 - Input capture mode to receive Speed signal from LCU via TRIGMUX. CH1 - Input capture mode to receive Hall1. CH2 - Input capture mode to receive Hall2. CH3 - Input capture mode to receive Hall3. Please provide some clarification.

IMX8QXP OTAアップデート：OTAアップデートによるパーティションの作成とサイズ変更の実現可能性 チームの皆さん、こんにちは。 IMX8QXP - スカースギャップ - L 6.6.52   現在のソフトウェアターゲットのパーティションレイアウトがOTAパッケージと少し異なる場合、ソフトウェアアップデート(OTA)プロセスの一環として新しいパーティションを作成し、既存のパーティションのサイズを変更することは可能でしょうか? OTAの更新メカニズムが、パーティションのレイアウト変更を手動で処理し、パーティション作成、サイズ変更、対応するパーティション情報の更新を手動で行うことが可能かどうかを理解したいです。 実現可能性、制約、推奨されるアプローチについて、ご意見をお聞かせください。 ありがとうございます。 VKS i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project

S32M27x FCCU Utility This document describes how to use Lauterbach FCCU (fault collection and control unit) periphery extension for S32M27x devices. It is expected that user has deep knowledge on FCCU mechanisms in order to effectively use this extension. This scripting tool consist of 136 scripts for Lauterbach debugger. It helps user to quickly debug micro without need of reference manual. Here is and example of windows that user can use (detailed description can be found in user guide):

Kernel Panic When Enabling LPUART3 and CAN1 on Custom i.MX95 SOM Hi, We are working on a custom NXP i.MX95 SOM and are trying to configure LPUART3 for RS485 communication. However, when we enable LPUART3 in the Device Tree with the appropriate pinmux configuration, we encounter a kernel panic. We are observing a similar issue when configuring the CAN1 pins. During our investigation, we identified that these peripherals and pins are currently assigned to the M7 core through the imx-sm-manager configuration. We modified the mx95evk.cfg file to remove the M7 ownership and grant access permissions to the A55 cores. However, the kernel panic persists even after these changes. Could you please help us understand whether any additional resource ownership, access permissions, or configuration changes are required to enable LPUART3 and CAN1 on the A55 side? I will share the log files and cfg file for your reference. We would appreciate your guidance in identifying and resolving this issue.

RT1186 TSN DEMOビルドの問題 i.MX RT1186のFRDMボードを2枚持っていて、プロジェクトをfrdmimxrt1186_tsn_app_cm33インポートしますが、いくつかのビルド設定があり、どれを選べばいいのか全く分かりません。 私の目標は、fgptpを有効にした状態で基本的なTSN通信をテストすることです。イーサネットケーブルで2台のボードを接続した後、2台のデバイスがマスターとスレーブの役割を交渉したことを示すシリアルポートのログが見られるはずです。 ユーザーガイドの説明は複雑です。どなたか、これを達成するための一般的な手順を教えていただけませんか? Re: RT1186 TSN DEMO build problem @ChandlerY様、 fgptpのテストを行うには、「リリース」を選択してください。 詳細な設定手順については、以下を参照してください。 https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Step-by-Step-Guide-to-Running-the-GenAVB-TSN-Stack-FreeRTOS/ta-p/2390969 を参照してください。第2章4節： よろしくお願いいたします。 シェリー

S32G399Aの8進数DTR読み取りがMacronix MX66UM2G45G QSPIフラッシュで失敗する こんにちは、コミュニティの皆さん。 私たちはS32G399A-RDB3リファレンスデザインを基にしたカスタムボードを持っています。主な ブートフラッシュの変更点は、MX25UW51245G (64 MB) を Macronix MX66UM2G45G (256 MB、1.8 V 8進数、JEDEC ID C2 80 3C)。すべて 1-1-1 SPIで動作します。8D-8D-8D(八進DTR)読み取りを正しく返すことはできません そしてNXPに助けを求めています。また、この部分はどの中にも見つかりませんでした S32 BSPはbsp48.0までリリースされています。AMDのU-Bootは、 2024.1. ソフトウェア TF-A bsp43.0-2.10.7、U-Boot bsp43.0-2022.04、Linux bsp43.0(6.6.52) BootROM QSPIパラメータ:mx66_sim133sdr.bin(512バイト、「OPI SDR 133 MHz」)、 S32 Design Studio 3.6.1から変更せずに採用されました。プラットフォーム SDK S32XX 4.0.0, プロセッサー/S32G399A/.../quadspi/default_boot_images/。私たちは生成しませんでした U-Bootのs32cc_qspiparamsツールを使用してください。 U-Bootの変更点：0xC2803CのフラッシュIDエントリ、および8進数SDRソフト リセット。BootROMはフラッシュをOPI SDRのままにし、リセットRDIDなしで 00 00 00 を返します。 効果的な点: - QSPIから1-1-1、133 MHz(~16 MB/s)、BootROM、TF-A、u-Bootで起動 Linux。 - LinuxはIPコマンドパスを強制した後に読み書きを行います。フラッシュと共に 1ビットモードでは、spi-fsl-qspi.cのAHBダイレクトマップ読み取りパス原因となる 同期的な外部アボートまたはハング。 U-Bootで8進数DTRを有効にするために行ったこと 1. spi-tx-bus-width / spi-rx-bus-width を 8 に設定します。するとフラッシュがネゴシエートし、 8D-8D-8D を有効にする: オペコード 0xEE、octal_dtr_enable() は 0 を返し、プローブ 256 MiB と報告されています。 2. ダミーサイクルの不一致が見つかりました。SFDPは14回のダミーサイクルを実行したが、フラッシュ デフォルト値は20（CR2、アドレスは0x300）です。ここで、CR2[0x300] = 0 (20サイクル) とプログラムします。 そして、read_dummy = 20 に設定します。この修正前は、読み取りによってランダムなデータが返されていました。 同じアドレスを読み取るたびに変更されます。 *** Warning - bad CRC, using default environment Too large ELF file, size: 3568570404 <- PFE firmware header, read 1 Too large ELF file, size: 1226703397 <- same header, read 2 Bad Linux ARM64 Image magic! 3. DTRモードでIDを読み戻します: 3c 3c 3c 3c c2 c2。両方の正しい値が揃っています 戻ってきて、私たちはフラッシュが本当に八進DTRにあると考えています。 問題 カーネルオフセットでの最初のバイトの期待値: 1f 20 03 d5 19 80 31 14。その コントローラレジスタ(個別に読み取る)は以下の通りです: MCR 030f00cc SMPR 33000000 DLLCRA c280000d DLCR 40ff40ff DLLSR 8000c078 (both DLLs locked) FR 09000001 (no DLPFF flag) - MCR DQS source = 外部(DDRのドライバーデフォルト):DTRクロックは2つだけです データの後、ゼロ:1f 20 1f d5 00 00 00 00 00。結果はデターミニスティックである。 そして管制官が転送成功を報告します。 - MCR DQS ソース = 内部 (MCR[25:24] = 1): すべてのデータが到着しますが、1 つ DDRエッジは、もう一方のエッジに対してちょうど1クロック遅れている。 expected: 1f 20 | 03 d5 | 19 80 | 31 14 read: 1f 20 | 1f d5 | 03 80 | 19 14 | 31 .. 各ペアの2バイト目は正しい。各ペアの最初のバイトは 正しいシーケンスが、1クロック分遅れて表示される。 DQSソーススイープ（MCR[25:24]、BSWAPオン/オフ）、最初の12バイトを読み取ります。 bswap src MCR data result on 2 020f00cc 19 80 19 19 14 14 31 14 00 00 00 00 bad on 3 030f00cc 1f 20 1f d5 00 00 00 00 00 00 00 00 bad off 0 000f00cc 31 0c 00 1d 55 02 19 18 31 20 00 00 bad off 1 010f00cc 1f 20 1f d5 03 80 19 14 31 00 00 00 bad off 2 020f00cc 80 19 19 19 14 14 14 31 00 00 00 00 bad off 3 030f00cc 20 1f d5 1f 00 00 00 00 00 00 00 00 bad 完全な無効化→設定→有効化→DLLロックサイクルで掃討した 毎回（どれも解決しなかった）： - SMPR DLLFSMPFA/FB_NTH 0-7、DLPオン/オフ - MCR END_CFG 0-3、SFACR BSWAP のオン/オフ: これは同じものを並べ替えるだけです 間違ったバイト - MCR DQSソース0-3 - SMPR DDRSMP 0-7、FSPHSのオン/オフ：データに全く影響なし コードの変更（テストビルドのみ、bsp43.0 をベースに）情報源） TF-A fdts/s32cc-nxp-flash-macronix.dtsi（U-Bootが使用するDTB）： mx66um2g45g@0 { compatible = "jedec,spi-nor"; spi-tx-bus-width = <8>; /* was 1 */ spi-rx-bus-width = <8>; /* was 1 */ }; U-Boot ドライバ/mtd/spi/spi-nor-core.c, spi_nor_macronix_octal_dtr_enable(), CR2[0x0]がDTR OPIにスイッチ前に: u8 dc = 0x00; /* CR2[0x300] = 0 -> 20 dummy */ write_enable(nor); op = (struct spi_mem_op) SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRCR2, 1), SPI_MEM_OP_ADDR(4, 0x300, 1), SPI_MEM_OP_NO_DUMMY, SPI_MEM_OP_DATA_OUT(1, &dc, 1)); spi_mem_exec_op(nor->spi, &op); spi_nor_wait_till_ready(nor); nor->read_dummy = 20; /* SFDP gave 14 */ U-Bootドライバ/spi/fsl_qspi.c、enable_octal_ddr()、DQSソーステスト (octal_ddr_confのデフォルトDQS_EXTERNALではなく内部DQS): mcr |= octal_ddr_conf.mcr; mcr &= ~QUADSPI_MCR_DQS_EXTERNAL; /* clear MCR[25:24] */ mcr |= QUADSPI_MCR_DQS_INT_PAD; /* MCR[25:24] = 1 */ qspi_writel(q, mcr, base + QUADSPI_MCR); レジスタスイープでは、完全なU-Bootコマンドを繰り返すテストU-Bootコマンドが使用されました。 enable_octal_ddr() シーケンス (MDIS=1、プログラム MCR/SMPR/DLCR/SFACR、MDIS=0、 各設定に対してDLLロックを待機し、その後512バイトを3回読み取ります。 基板側： DQSはピン多重化されています（パッド85～93、IMCR 540～548）。 質問 1.S32G3 QuadSPIで133MHzの8D-8D-8D動作を実現するには、外部DQSが必要ですか？は 「時計が2つ表示されてからゼロが表示される」というのは、DQSの返却が欠落しているか、不良であることを示す既知の症状ですか？ 2. DDRモードでは内部DQS（ループバック）はサポートされていますか？もしそうなら、どのレジスターか 設定でエッジ間の1クロックのクロックスキューを修正できますか?DLLCRAスレーブ遅延設定、 多分？ 3. QuadSPI 設定 (MCR/SMPR/DLLCRA/FLSHCR) の検証済み、または BootROMパラメータセット（MX66UM2G45Gまたはその他の1.8V Macronix 8進数用） S32G3の部品ですか？同じS32DSフォルダには、mx66_sim133ddr.binも含まれています。それはある 8進数DTRブートイメージはS32G3で検証済みで、どのボードで確認されていますか? 4. Linuxのspi-fsl-qspiドライバにおけるAHB読み取りパスは、 八進DTR?フラッシュが1-1-1で動作すると故障するのが普通でしょうか? 5. NXPはS32 BSPにMX66UM2G45G(JEDEC ID C2 80 3C)を追加する計画ですか? U-Boot、Linux、TF-Aのbsp48.0までのリリースを調べましたが、見つかりませんでした その入り口。AMDのU-Bootフォーク(u-boot-xlnx)はこの部分をサポートしています。 2024.1リリース以降のoctal-DTR読み取りおよびプログラム、そしてメインラインのU-Boot 1 Gbitの兄弟機であるMX66UM1G45G(C2 80 3B)をサポートしています。もしサポートが 計画中ですが、どのBSPリリースをターゲットにしていますか?検証済みのものも含まれますか 8進数DTR用のQuadSPIおよびBootROMパラメータは？ ログ全体とレジスタスイープテーブルを共有できます。ありがとう。

A53 reset and lockstep boot with S32G3 Dear NXP Support Team, When booting from Cortex-M7 on the S32G399A-EVB3, does Cortex-A53 automatically remain in reset? After M7 configures Cortex-A53 Lockstep mode, what is the correct procedure to release the A53 reset and allow it to start execution? Could you please clarify the expected reset behavior and provide the recommended reset-release sequence? Best regards, Toan Re: A53 reset and lockstep boot with S32G3 Hi, Toan Thank you for contacting us. I will help you check it and reply to you at the following case. Clarification on Reset Sequence and A53 Lockstep Boot Flow with S32G3 BSP 48.0.0 - NXP Community BR Joey

S32K312 SIUL interrupt When an effective interrupt is generated，can not into void SIUL_2_Handler(void)，but can into void Default_Handler(void)，why？ Re: S32K312 SIUL interrupt Hello @joshua9264 , The map file and memory view confirm that the vector table is correct. SIUL_2_Handler is located at 0x00400765 and the corresponding vector entry at 0x0040021C contains the same address. Therefore, the weak handler and vector-table linkage are not the cause. The reported CFSR.INVSTATE HardFault indicates an invalid processor execution state. Since the vector entry includes the required Thumb bit, the fault may occur inside the interrupt handler or during the exception return. The displayed Default_Handler may actually be the weak handler used for the HardFault exception. Please set an instruction breakpoint at 0x00400764, which is the actual first instruction of SIUL_2_Handler and step through the handler in the Disassembly view. This will confirm whether the processor enters the handler and identify the instruction after which the fault occurs. If the fault occurs during the return from the handler, please also provide the following values immediately after the HardFault: SCB->CFSR SCB->HFSR SCB->SHCSR SCB->ICSR MSP value The stacked PC and xPSR values The stacked xPSR must have the Thumb state bit, bit 24, set. A stacked PC of 0x00000000 or a cleared Thumb bit would explain the INVSTATE fault. Best regards, Pavel Re: S32K312 SIUL interrupt thank you PavelL I checked these addresses and data are correct，But it still cannot enter SIUL_2_Handler。 I will generate a project using S32DS to test The processor has escalated a configurable-priority exception to HardFault. I don't know what caused it   Re: S32K312 SIUL interrupt Hello @joshua9264 , Thank you for providing the project files. I checked the startup file, vector table, main.c, linker configuration and IAR project settings. The handler name appears to be correct: The vector table uses SIUL_2_Handler. main.c provides a strong implementation of SIUL_2_Handler. The startup file defines the default implementation as a weak alias to Default_Handler. SystemInit() sets SCB->VTOR to the __VECTOR_TABLE symbol. Therefore, the implementation in main.c should override the weak default handler. At this point, please check the final linker output to confirm which address was actually assigned to the vector table entry. The IAR project has map file generation enabled. Please check the Debug\List directory for a .map file. In the map file, search for: SIUL_2_Handler Default_Handler __VECTOR_TABLE Please verify that SIUL_2_Handler has its own address and is not resolved to the same address as Default_Handler. The map file should also indicate that the implementation comes from main.o, while the weak definition comes from the startup object. For the flash configuration, the vector table should start at 0x00400100. Since SIUL_2_IRQn is IRQ 55, its vector table entry should be located at: 0x00400100 + 4 × (16 + 55) = 0x0040021C Please also check the following values in the debugger after SystemInit() has executed: The value of SCB->VTOR. It should be 0x00400100 for the flash configuration. The 32-bit value stored at address 0x0040021C. The address of SIUL_2_Handler. The address of Default_Handler. The value stored at 0x0040021C should correspond to the address of the application implementation of SIUL_2_Handler, with bit 0 set because the Cortex-M7 executes Thumb instructions. If the vector entry points to Default_Handler, please perform a Clean and Rebuild in IAR and make sure that the newly generated .out file is downloaded to the MCU.  Best regrads, Pavel Re: S32K312 SIUL interrupt and this is  my project file Re: S32K312 SIUL interrupt Hi：PavelL This is startup file and vector table，I haven't found SIUL_2_IRQHandler， I am using an IAR project generated by S32DS。 Re: S32K312 SIUL interrupt Hello @joshua9264 , Since the CPU enters Default_Handler(), the SIUL2 interrupt is most likely generated correctly, but the interrupt vector is still linked to the default weak handler. Please check the startup file or vector table and use the exact ISR name assigned to SIUL_2_IRQn. The expected name may be SIUL_2_IRQHandler() rather than SIUL_2_Handler(). The linker map file can be used to verify which function is actually assigned to the interrupt vector. Best regards, Pavel

S32G399A octal DTR reads fail with Macronix MX66UM2G45G QSPI flash Hi Community, We have a custom board based on the S32G399A-RDB3 reference design. The main change to the boot flash is that we replaced the MX25UW51245G (64 MB) with a Macronix MX66UM2G45G (256 MB, 1.8 V octal, JEDEC ID C2 80 3C). Everything works in 1-1-1 SPI. We cannot get 8D-8D-8D (octal DTR) reads to return correct data, and we would like help from NXP. We also could not find this part in any S32 BSP release up to bsp48.0, although AMD's U-Boot has supported it since 2024.1. Software TF-A bsp43.0-2.10.7, U-Boot bsp43.0-2022.04, Linux bsp43.0 (6.6.52) BootROM QSPI parameters: mx66_sim133sdr.bin (512 bytes, "OPI SDR 133 MHz"), taken unchanged from S32 Design Studio 3.6.1, Platform SDK S32XX 4.0.0, processors/S32G399A/.../quadspi/default_boot_images/. We did not generate it with U-Boot's s32cc_qspiparams tool. U-Boot changes: the flash ID entry for 0xC2803C, plus the octal-SDR soft reset. The BootROM leaves the flash in OPI SDR, and without the reset RDID returns 00 00 00. What works: - Boot from QSPI at 1-1-1, 133 MHz (~16 MB/s), in BootROM, TF-A, U-Boot and Linux. - Linux reads and writes, after we forced the IP-command path. With the flash in 1-bit mode, the AHB direct-map read path in spi-fsl-qspi.c causes a synchronous external abort or a hang. What we did to enable octal DTR in U-Boot 1. Set spi-tx-bus-width / spi-rx-bus-width to 8. The flash then negotiates and enables 8D-8D-8D: opcode 0xEE, octal_dtr_enable() returns 0, and probe reports 256 MiB. 2. Found a dummy-cycle mismatch. SFDP gave 14 dummy cycles, but the flash defaults to 20 (CR2 at 0x300). We now program CR2[0x300] = 0 (20 cycles) and set read_dummy = 20. Before this fix, reads returned random data that changed on every read of the same address: *** Warning - bad CRC, using default environment Too large ELF file, size: 3568570404 <- PFE firmware header, read 1 Too large ELF file, size: 1226703397 <- same header, read 2 Bad Linux ARM64 Image magic! 3. Read the ID back in DTR mode: 3c 3c 3c 3c c2 c2. Both correct values come back, so we believe the flash really is in octal DTR. The problem Expected first bytes at the kernel offset: 1f 20 03 d5 19 80 31 14. The controller registers (read individually) are: MCR 030f00cc SMPR 33000000 DLLCRA c280000d DLCR 40ff40ff DLLSR 8000c078 (both DLLs locked) FR 09000001 (no DLPFF flag) - MCR DQS source = external (driver default for DDR): we get only 2 DTR clocks of data, then zeros: 1f 20 1f d5 00 00 00 00. The result is deterministic, and the controller reports a successful transfer. - MCR DQS source = internal (MCR[25:24] = 1): all the data arrives, but one DDR edge lags the other by exactly one clock: expected: 1f 20 | 03 d5 | 19 80 | 31 14 read: 1f 20 | 1f d5 | 03 80 | 19 14 | 31 .. The second byte of every pair is correct. The first byte of every pair is the correct sequence, delayed by one clock. DQS source sweep (MCR[25:24], BSWAP on/off), first 12 bytes read: bswap src MCR data result on 2 020f00cc 19 80 19 19 14 14 31 14 00 00 00 00 bad on 3 030f00cc 1f 20 1f d5 00 00 00 00 00 00 00 00 bad off 0 000f00cc 31 0c 00 1d 55 02 19 18 31 20 00 00 bad off 1 010f00cc 1f 20 1f d5 03 80 19 14 31 00 00 00 bad off 2 020f00cc 80 19 19 19 14 14 14 31 00 00 00 00 bad off 3 030f00cc 20 1f d5 1f 00 00 00 00 00 00 00 00 bad What we swept, with a full disable -> configure -> enable -> DLL-lock cycle each time (none fixed it): - SMPR DLLFSMPFA/FB_NTH 0-7, with DLP on and off - MCR END_CFG 0-3, with SFACR BSWAP on and off: this only reorders the same wrong bytes - MCR DQS source 0-3 - SMPR DDRSMP 0-7, with FSPHS on and off: no effect at all on the data Code changes (test builds only, on top of the bsp43.0 sources) TF-A fdts/s32cc-nxp-flash-macronix.dtsi (the DTB that U-Boot uses): mx66um2g45g@0 { compatible = "jedec,spi-nor"; spi-tx-bus-width = <8>; /* was 1 */ spi-rx-bus-width = <8>; /* was 1 */ }; U-Boot drivers/mtd/spi/spi-nor-core.c, spi_nor_macronix_octal_dtr_enable(), before CR2[0x0] is switched to DTR OPI: u8 dc = 0x00; /* CR2[0x300] = 0 -> 20 dummy */ write_enable(nor); op = (struct spi_mem_op) SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRCR2, 1), SPI_MEM_OP_ADDR(4, 0x300, 1), SPI_MEM_OP_NO_DUMMY, SPI_MEM_OP_DATA_OUT(1, &dc, 1)); spi_mem_exec_op(nor->spi, &op); spi_nor_wait_till_ready(nor); nor->read_dummy = 20; /* SFDP gave 14 */ U-Boot drivers/spi/fsl_qspi.c, enable_octal_ddr(), DQS source test (internal DQS instead of the octal_ddr_conf default DQS_EXTERNAL): mcr |= octal_ddr_conf.mcr; mcr &= ~QUADSPI_MCR_DQS_EXTERNAL; /* clear MCR[25:24] */ mcr |= QUADSPI_MCR_DQS_INT_PAD; /* MCR[25:24] = 1 */ qspi_writel(q, mcr, base + QUADSPI_MCR); The register sweeps used a test U-Boot command that repeats the full enable_octal_ddr() sequence (MDIS=1, program MCR/SMPR/DLCR/SFACR, MDIS=0, wait for DLL lock) for each setting, then reads 512 bytes 3 times. Board side: DQS is pinmuxed (pads 85-93, IMCR 540-548). Questions 1. Is external DQS required for 8D-8D-8D at 133 MHz on the S32G3 QuadSPI? Is "2 clocks then zeros" a known symptom of a missing or bad DQS return? 2. Is internal DQS (loopback) supported in DDR mode? If so, which register settings fix the one-clock skew between edges? DLLCRA slave-delay settings, perhaps? 3. Do you have validated QuadSPI settings (MCR/SMPR/DLLCRA/FLSHCR), or a BootROM parameter set, for the MX66UM2G45G or another 1.8 V Macronix octal part on S32G3? The same S32DS folder also has mx66_sim133ddr.bin. Has that octal DTR boot image been validated on S32G3, and on which board? 4. Is the AHB read path in the Linux spi-fsl-qspi driver validated only for octal DTR? Is it expected to fault when the flash runs in 1-1-1? 5. Is NXP planning to add the MX66UM2G45G (JEDEC ID C2 80 3C) to the S32 BSP? We checked the U-Boot, Linux and TF-A releases up to bsp48.0 and found no entry for it. AMD's U-Boot fork (u-boot-xlnx) has supported this part with octal-DTR read and program since its 2024.1 release, and mainline U-Boot supports its 1 Gbit sibling, the MX66UM1G45G (C2 80 3B). If support is planned, which BSP release is it targeted for? Would it include validated QuadSPI and BootROM parameters for octal DTR? We can share full logs and the register sweep tables. Thank you.

S32K312 SIUL割り込み 効果的な割り込みが生成された場合、Void SIUL_2_Handler(void)には入れないが、void Default_Handler(void)には入れるのか?なぜ? Re: S32K312 SIUL interrupt こんにちは、 @joshua9264 さん、 マップファイルとメモリビューにより、ベクターテーブルが正しいことが確認されました。SIUL_2_Handlerは0x00400765に位置し、対応するベクターエントリ0x0040021Cには同じアドレスが含まれています。したがって、弱いハンドラとベクターテーブルのリンクが原因ではありません。 報告されたCFSR.INVSTATEハードフォールトは、プロセッサの実行状態が無効であることを示します。ベクタエントリには必須のサムビットが含まれているため、割り込みハンドラ内または例外戻り時に障害が発生する可能性があります。表示されている Default_Handler は、実際には HardFault 例外に使用される弱いハンドラーである可能性があります。 SIUL_2_Handler の最初の命令である 0x00400764 に命令ブレークポイントを設定し、逆アセンブリビューでハンドラをステップ実行してください。これにより、プロセッサがハンドラーに入ったかどうか、そして故障が発生する命令を識別します。 ハンドラからの戻り時にエラーが発生した場合は、ハードフォルトの直後に以下の値も指定してください。 SCB->CFSR SCB->HFSR SCB->SHCSR SCB->ICSR MSP値 積み重ねられたPC値とxPSR値 スタックされたxPSRは、サム状態ビット（ビット24）がセットされている必要があります。スタックされたPCが0x00000000であるか、サムビットがクリアされている場合、INVSTATEエラーが説明できます。 よろしくお願いいたします。 パベル Re: S32K312 SIUL interrupt パベルさん、ありがとう これらのアドレスとデータは正しいものを確認しましたが、それでも入力できませんSIUL_2_Handler。 S32DSを使用してプロジェクトを生成してテストします プロセッサはHardFaultに対して設定可能な優先度の例外をエスカレーションしました。 何が原因かはわかりません   Re: S32K312 SIUL interrupt こんにちは、 @joshua9264 さん、 プロジェクトファイルをご提供いただきありがとうございます。 起動ファイル、ベクターテーブル、main.c を確認しました。リンカーの設定とIARプロジェクトの設定。ハンドラー名は正しいようです。 ベクトルテーブルはSIUL_2_Handlerを使用します。 main.c は、SIUL_2_Handler の強力な実装を提供します。 起動ファイルでは、デフォルトの実装を Default_Handler の弱いエイリアスとして定義しています。 SystemInit() は SCB->VTOR を __VECTOR_TABLE シンボルに設定します。 したがって、main.c の実装弱いデフォルトハンドラをオーバーライドする必要があります。この時点で、最終的なリンカーの出力を確認し、ベクターテーブルのエントリに実際に割り当てられたアドレスを確認してください。 IARプロジェクトでは、地図ファイルの生成機能が有効になっています。Debug\List ディレクトリに .map ファイルがあるかどうか確認してください。ファイル。地図ファイル内で以下を検索してください: SIUL_2_ハンドラー デフォルトハンドラー __VECTOR_TABLE SIUL_2_Handlerが独自のアドレスを持ち、Default_Handlerと同じアドレスに解決されていないことを確認してください。マップファイルには、実装がmain.oから来ており、弱い定義がスタートアップオブジェクトから来ていることも明記する必要があります。 フラッシュ構成の場合、ベクターテーブルは0x00400100から開始する必要があります。SIUL_2_IRQnはIRQ 55であるため、そのベクタテーブルエントリは次の場所に配置されます。 0x00400100 + 4 × (16 + 55) = 0x0040021C SystemInit() の実行後、デバッガーで以下の値も確認してください。 SCB->VTOR の値。フラッシュ構成の場合は0x00400100である必要があります。 アドレス0x0040021Cに格納されている32ビット値。 SIUL_2_Handler のアドレス。 Default_Handler のアドレス。 0x0040021Cに保存される値は、SIUL_2_Handlerのアプリケーション実装のアドレスに対応し、ビット0はCortex-M7がサム命令を実行するために設定されます。 ベクターエントリが Default_Handler を指している場合は、IAR でクリーンと再構築を実行し、新しく生成された .out ファイルが正しく生成されていることを確認してください。ファイルはMCUにダウンロードされます。 よろしくお願いいたします。 パベル Re: S32K312 SIUL interrupt そしてこれが私のプロジェクトファイルです Re: S32K312 SIUL interrupt こんにちは：パベル これは起動ファイルとベクターテーブルです。SIUL_2_IRQHandler は見つかりませんでした。 私はS32DSで生成されたIARプロジェクトを使用しています。 Re: S32K312 SIUL interrupt こんにちは、 @joshua9264 さん、 CPUがDefault_Handler()に入るため、SIUL2割り込みは正しく生成される可能性が高いですが、割り込みベクタは依然としてデフォルトの弱いハンドラにリンクされています。 スタートアップファイルまたはベクターテーブルを確認し、SIUL_2_IRQnに割り当てられた正確なISR名を使用してください。期待される名前は SIUL_2_Handler ()ではなく SIUL_2_IRQHandler()かもしれません。リンカーマップファイルを使って割り込みベクターに実際に割り当てられた関数を検証できます。 よろしくお願いいたします。 パベル

S32K312 SIUL 中断 当产生有效中断时，不能进入void SIUL_2_Handler(void)，但可以进入void Default_Handler(void)，为什么？ Re: S32K312 SIUL interrupt 你好@joshua9264 ， 映射文件和内存视图证实矢量表是正确的。SIUL_2_Handler 位于 0x00400765，对应的向量条目位于 0x0040021C，包含相同的地址。因此，弱处理程序和向量表链接不是原因。 报告的 CFSR.INVSTATE HardFault 表示处理器执行状态无效。由于向量条目包含所需的 Thumb 位，因此故障可能发生在中断处理程序内部或异常返回期间。显示的 Default_Handler 实际上可能是用于 HardFault 异常的弱处理程序。 请在 0x00400764 处设置指令断点，这是 SIUL_2_Handler 的实际第一条指令，并在反汇编视图中逐步执行该处理程序。这将确认处理器是否进入处理程序，并确定发生故障的指令。 如果故障发生在处理程序返回期间，请在 HardFault 之后立即提供以下值： SCB->CFSR SCB->HFSR SCB->SHCSR SCB>ICSR MSP值 堆叠 PC 和 xPSR 值 堆叠的 xPSR 必须设置 Thumb 状态位（第 24 位）。PC 堆叠值为 0x00000000 或 Thumb 位被清除，可以解释 INVSTATE 故障。 顺祝商祺！ 帕维尔 Re: S32K312 SIUL interrupt 谢谢你，帕维尔 我检查过这些地址和数据，确认无误，但仍然无法进入SIUL_2_Handler。 我将使用 S32DS 生成一个项目来进行测试。 处理器已将可配置优先级异常升级为 HardFault。 我不知道是什么原因造成的。   Re: S32K312 SIUL interrupt 你好@joshua9264 ， 感谢您提供项目文件。 我检查了启动文件、向量表和 main.c 文件。链接器配置和 IAR 项目设置。处理程序名称似乎正确： 向量表使用 SIUL_2_Handler。 main.c 提供了 SIUL_2_Handler 的强大实现。 启动文件将默认实现定义为 Default_Handler 的弱别名。 SystemInit() 将 SCB->VTOR 设置为 __VECTOR_TABLE 符号。 因此，main.c 中的实现。应该覆盖默认的弱处理程序。此时，请检查最终的链接器输出，以确认哪个地址实际分配给了向量表条目。 IAR项目已启用地图文件生成功能。请检查 Debug\List 目录中是否存在 .map 文件。文件。在地图文件中，搜索： SIUL_2_Handler 默认处理程序 __VECTOR_TABLE 请确认 SIUL_2_Handler 有自己的地址，并且没有解析到与 Default_Handler 相同的地址。映射文件还应表明实现来自 main.o，而弱定义来自启动对象。 对于闪存配置，向量表应从 0x00400100 开始。由于 SIUL_2_IRQn 的 IRQ 为 55，因此其向量表条目应位于： 0x00400100 + 4 × (16 + 55) = 0x0040021C 请在执行完 SystemInit() 函数后，在调试器中检查以下值： SCB->VTOR 的价值。闪存配置应为 0x00400100。 存储在地址 0x0040021C 处的 32 位值。 SIUL_2_Handler 的地址。 Default_Handler 的地址。 存储在 0x0040021C 处的值应该对应于 SIUL_2_Handler 应用程序实现的地址，位 0 已设置，因为 Cortex-M7 执行 Thumb 指令。 如果向量入口指向 Default_Handler，请在 IAR 中执行清理和重建操作，并确保新生成的 .out 文件正确无误。文件已下载到MCU。 此致敬礼， 帕维尔 Re: S32K312 SIUL interrupt 这是我的项目文件 Re: S32K312 SIUL interrupt 你好： PavelL 这是启动文件和向量表，我没有找到 SIUL_2_IRQHandler， 我正在使用S32DS生成的IAR项目。 Re: S32K312 SIUL interrupt 你好@joshua9264 ， 由于 CPU 进入Default_Handler() ，SIUL2 中断很可能已正确生成，但中断向量仍然链接到默认的弱处理程序。 请检查启动文件或向量表，并使用分配给SIUL_2_IRQn的确切 ISR 名称。预期名称可能是SIUL_2_IRQHandler()而不是SIUL_2_Handler() 。可以使用链接器映射文件来验证哪个函数实际分配给了中断向量。 顺祝商祺！ 帕维尔

S32DS_ARM_Win32_v2018.R1_b180326.exe 激活失效 激活码失效：8FE5-AD8E-E76D-42C8

使用 Macronix MX66UM2G45G QSPI 闪存时，S32G399A 八进制 DTR 读取失败 大家好， 我们有一款基于 S32G399A-RDB3 参考设计的定制板。主要 启动闪存的更改在于，我们将 MX25UW51245G (64 MB) 替换为…… Macronix MX66UM2G45G（256 MB，1.8 V 八脚，JEDEC ID C2 80 3C）。一切 适用于 1-1-1 SPI 模式。我们无法获取正确的 8D-8D-8D（八进制 DTR）读取结果。 我们需要数据，并希望得到 NXP 的帮助。我们也找不到这部分内容。 S32 电路板支持包。版本最高可达 bsp48.0，尽管 AMD 的 U-Boot 自那时起就支持它了。 2024.1. 软件 TF-A bsp43.0-2.10.7，U-Boot bsp43.0-2022.04，Linux bsp43.0（6.6.52） BootROM QSPI 参数：mx66_sim133sdr.bin（512 字节，“OPI SDR 133 MHz”）， 直接取自 S32 Design Studio 3.6.1，未做任何修改。平台 SDK S32XX 4.0.0 processors/S32G399A/.../quadspi/default_boot_images/。我们没有生成 使用 U-Boot 的 s32cc_qspiparams 工具。 U-Boot 更改：闪存 ID 条目为 0xC2803C，以及八进制 SDR 软启动 重置。BootROM 将闪存设置为 OPI SDR 模式，并且不包含 RESET RDID。 返回 00 00 00。 有效的方法： - 从 QSPI 以 1-1-1 模式、133 MHz（~16 MB/s）启动，在 启动ROM、TF-A、U-启动 中均可实现。 Linux。 - 在我们强制执行 IP 命令路径后，Linux 可以进行读写操作。闪光灯 在 1 位模式下，spi-fsl-qspi.c 中的 AHB 直接映射读取路径导致 同步外部中止或挂起。 我们在 U-Boot 中启用八进制 DTR 的方法 1. 将 spi-tx-总线-width / spi-rx-总线-width 设置为 8。然后闪存会进行协商并 启用 8D-8D-8D：操作码 0xEE，octal_dtr_enable() 返回 0，并进行探测 报告显示 256 MiB。 2. 发现虚拟周期不匹配。SFDP 提供了 14 个虚拟循环，但闪光灯 默认值为 20（CR2 位于 0x300）。我们现在将 CR2[0x300] 编程为 0（20 个周期） 并设置 read_dummy = 20。在此修复之前，读取操作返回的是随机数据。 每次读取同一地址时都会发生变化： *** Warning - bad CRC, using default environment Too large ELF file, size: 3568570404 <- PFE firmware header, read 1 Too large ELF file, size: 1226703397 <- same header, read 2 Bad Linux ARM64 Image magic! 3. 在 DTR 模式下读取 ID：3c 3c 3c 3c c2 c2。两个正确值都来自 由此可见，我们认为闪光灯确实是八进制 DTR。 问题 内核偏移处的预期首字节：1f 20 03 d5 19 80 31 14。这 控制器寄存器（单独读取）包括： MCR 030f00cc SMPR 33000000 DLLCRA c280000d DLCR 40ff40ff DLLSR 8000c078 (both DLLs locked) FR 09000001 (no DLPFF flag) - MCR DQS 源 = 外部（DDR 驱动程序默认值）：我们只能获得 2 个 DTR 时钟 数据，然后是零：1f 20 1f d5 00 00 00 00。结果是确定性的。 控制器报告转账成功。 - MCR DQS 源 = 内部 (MCR[25:24] = 1): 所有数据都已到达，但有一个 DDR 时钟周期比其他时钟周期慢一个时钟周期： expected: 1f 20 | 03 d5 | 19 80 | 31 14 read: 1f 20 | 1f d5 | 03 80 | 19 14 | 31 .. 每对数据中的第二个字节都是正确的。每对数据的第一个字节是 正确的序列，延迟一个时钟周期。 DQS 源扫描（MCR[25:24]，BSWAP 开/关），读取前 12 个字节： bswap src MCR data result on 2 020f00cc 19 80 19 19 14 14 31 14 00 00 00 00 bad on 3 030f00cc 1f 20 1f d5 00 00 00 00 00 00 00 00 bad off 0 000f00cc 31 0c 00 1d 55 02 19 18 31 20 00 00 bad off 1 010f00cc 1f 20 1f d5 03 80 19 14 31 00 00 00 bad off 2 020f00cc 80 19 19 19 14 14 14 31 00 00 00 00 bad off 3 030f00cc 20 1f d5 1f 00 00 00 00 00 00 00 00 bad 我们通过完整的禁用 -> 配置 -> 启用 -> DLL 锁定循环彻底清除了所有问题。 每次都这样（但都没能解决问题）： - SMPR DLLFSMPFA/FB_NTH 0-7，DLP 开启和关闭 - MCR END_CFG 0-3，SFACR BSWAP 开启和关闭：这只会重新排序相同的 错误字节 - MCR DQS 源 0-3 - SMPR DDRSMP 0-7，无论 FSPHS 开启还是关闭：对数据完全没有影响 代码更改（仅限测试版本，基于 bsp43.0）（来源） TF-A fdts/s32cc-nxp-flash-macronix.dtsi（U-Boot 使用的 DTB）： mx66um2g45g@0 { compatible = "jedec,spi-nor"; spi-tx-bus-width = <8>; /* was 1 */ spi-rx-bus-width = <8>; /* was 1 */ }; U-Boot drivers/mtd/spi/spi-nor-core.c，spi_nor_macronix_octal_dtr_enable()， 在 CR2[0x0] 切换到 DTR OPI 之前： u8 dc = 0x00; /* CR2[0x300] = 0 -> 20 dummy */ write_enable(nor); op = (struct spi_mem_op) SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRCR2, 1), SPI_MEM_OP_ADDR(4, 0x300, 1), SPI_MEM_OP_NO_DUMMY, SPI_MEM_OP_DATA_OUT(1, &dc, 1)); spi_mem_exec_op(nor->spi, &op); spi_nor_wait_till_ready(nor); nor->read_dummy = 20; /* SFDP gave 14 */ U-Boot drivers/spi/fsl_qspi.c，enable_octal_ddr()，DQS 源测试 （内部 DQS 而不是 octal_ddr_conf 默认的 DQS_EXTERNAL）： mcr |= octal_ddr_conf.mcr; mcr &= ~QUADSPI_MCR_DQS_EXTERNAL; /* clear MCR[25:24] */ mcr |= QUADSPI_MCR_DQS_INT_PAD; /* MCR[25:24] = 1 */ qspi_writel(q, mcr, base + QUADSPI_MCR); 寄存器扫描使用了一条测试用的 U-Boot 命令，该命令重复执行完整的操作。 enable_octal_ddr() 序列（MDIS=1，程序 MCR/SMPR/DLCR/SFACR，MDIS=0， 等待 DLL 锁定）对于每个设置，然后读取 512 字节 3 次。 板面： DQS 采用引脚复用（焊盘 85-93，IMCR 540-548）。 问题 1.在 S32G3 QuadSPI 上，133 MHz 频率下，8D-8D-8D 是否需要外部 DQS？是 “2 个时钟然后是 0”是 DQS 返回缺失或错误的一个已知症状吗？ 2. DDR 模式下是否支持内部 DQS（环回）？如果是这样，是哪个注册表 设置可以修复边缘之间的一个时钟刻度偏差吗？DLLCRA 从属延迟设置， 也许？ 3. 您是否已验证 QuadSPI 设置（MCR/SMPR/DLLCRA/FLSHCR）？ 适用于 MX66UM2G45G 或其他 1.8V Macronix 八进制微控制器的 BootROM 参数集 S32G3 的部件是什么？S32DS 文件夹中还包含 mx66_sim133ddr.bin。有那个吗？ 八进制 DTR 启动映像已在 S32G3 上验证过，是在哪款板上验证过的？ 4. Linux spi-fsl-qspi 驱动程序中的 AHB 读取路径是否仅针对以下情况进行验证 八进制DTR？当闪存以 1-1-1 模式运行时，是否预期会出现故障？ 5. NXP 是否计划将 MX66UM2G45G（JEDEC ID C2 80 3C）添加到 S32 电路板支持包。中？ 我们检查了 U-Boot、Linux 和 TF-A 的版本，最高到 bsp48.0，没有发现任何问题。 它的条目。AMD 的 U-Boot 分支（u-boot-xlnx）已支持此部分。 自 2024.1 版本发布以来，八进制 DTR 的读取和编程以及主线 U-Boot 均已支持。 支持其 1 Gbit 同系列产品 MX66UM1G45G (C2 80 3B)。如果支持是 计划中，目标 电路板支持包。版本是什么？它会包含已验证的内容吗？ QuadSPI 和 BootROM 的八进制 DTR 参数是什么？ 我们可以共享完整的日志和寄存器扫描表。谢谢。

使用 S32G3 进行 A53 RESET 和锁步启动 尊敬的恩智浦技术支持团队： 当从 S32G399A-EVB3 上的 Cortex-M7 启动时，Cortex-A53 是否会自动保持 RESET 状态？ M7 配置 Cortex-A53 锁步模式后，释放 A53 RESET 并允许其开始执行的正确步骤是什么？ 请您阐明预期的 RESET 行为，并提供推荐的 RESET 释放顺序？ 此致， 托安 Re: A53 reset and lockstep boot with S32G3 你好，Toan 感谢您与我们联系。 我会帮您核实，并在下次回复您。 关于 S32G3 电路板支持包。48.0.0 的 RESET 顺序和 A53 锁步启动流程的说明 - NXP 社区 BR 乔伊

RT1186 TSN DEMO build problem I have two i.MX RT1186 FRDM boards, then import frdmimxrt1186_tsn_app_cm33 project, there are several build configrations, I have no idea which one should I choose. My goal is to test the basic TSN communication with fgptp enabled. After connecting two boards via an Ethernet cable, I expect to see serial port logs showing that the two devices have negotiated their master and slave roles. The description in the user guide is complicated. Could anyone please outline the general steps to achieve this? Re: RT1186 TSN DEMO build problem Dear @ChandlerY , Please select ‘release’ for fgptp testing. For detailed configuration instructions, please refer to  Please refer to https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Step-by-Step-Guide-to-Running-the-GenAVB-TSN-Stack-FreeRTOS/ta-p/2390969, chapter 2.4: Best Regards, Shelly

カスタムi.MX95 SOMでLPUART3とCAN1を有効にするとカーネルパニックが発生する こんにちは、 私たちはNXP i.MX95カスタムSOMの開発に取り組んでおり、 RS485通信用にLPUART3を設定しようとしています。 しかし、デバイスツリーで適切なピン多重化設定を使用してLPUART3を有効にすると、カーネルパニックが発生します。CAN1ピンの設定時にも同様の問題が発生しています。 調査の結果、これらのペリフェラルとピンは現在imx-sm-manager構成を通じてM7コアに割り当てられていることが判明しました。 mx95evk.cfgファイルを修正し、M7の所有権を削除し、A55コアへのアクセス権限を付与しました。しかし、これらの変更後もカーネルパニックは解消されない。 A55側でLPUART3およびCAN1を有効にするために、追加のリソース所有権、アクセス権限、または設定変更が必要かどうか、ご説明いただけますか?参考のために、ログファイルと設定ファイルを共有します。 この問題の特定と解決にあたり、ご指導いただければ幸いです。

在自定义 i.MX95 SOM 上启用 LPUART3 和 CAN1 时发生内核崩溃 您好， 我们正在开发一款定制的NXP i.MX95 SOM ，并尝试配置LPUART3 以进行 RS485通信。 但是，当我们在设备树中启用 LPUART3 并进行适当的引脚复用配置时，会遇到内核崩溃。我们在配置CAN1 引脚时也观察到了类似的问题。 在调查过程中，我们发现这些外设和引脚目前通过 imx-sm-manager 配置分配给了 M7 内核。 我们修改了mx95evk.cfg 文件，移除了 M7 的所有权，并授予了 A55 内核的访问权限。然而，即使经过这些更改，内核崩溃仍然存在。 请问是否需要对 A55 端的 LPUART3 和 CAN1 进行任何额外的资源所有权、访问权限或配置更改？我会把日志文件和配置文件发给你参考。 我们希望您能指导我们找出并解决这个问题。

RT1186 TSN DEMO 版本问题 我有两块 i.MX RT1186 FRDM 板，然后导入 frdmimxrt1186_tsn_app_cm33 项目，有好几种版本配置，我不知道该选哪一种。 我的目标是测试启用 fgptp 后的基本 TSN 通信。通过以太网线连接两块板后，我希望看到串口日志显示这两个设备已经协商好主从角色。 用户指南中的描述很复杂。请问谁能概述一下实现这一目标的一般步骤？ Re: RT1186 TSN DEMO build problem 亲爱的@ChandlerY ， 请选择“版本”进行 fgptp 测试。 有关详细配置说明，请参阅 请参考https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Step-by-Step-Guide-to-Running-the-GenAVB-TSN-Stack-FreeRTOS/ta-p/2390969第2.4章： 顺祝商祺！ 雪莉

A53リセットとS32G3によるロックステップブート 親愛なるNXPサポートチームへ、 S32G399A-EVB3でCortex-M7から起動すると、Cortex-A53は自動的にリセットされたままになりますか? M7がCortex-A53ロックステップモードを設定した後、A53リセットを解除して実行を開始する正しい手順は何でしょうか? 想定されるリセット動作を明確にし、推奨されるリセットから解放までの順序を教えていただけますか? よろしくお願いします、 トアン Re: A53 reset and lockstep boot with S32G3 こんにちは、トアン お問い合わせいただきありがとうございます。 確認をお手伝いし、次のCASEで返信します。 S32G3 BSP 48.0.0におけるリセットシーケンスおよびA53ロックステップブートフローに関する説明 - NXPコミュニティ BR ジョーイ

S32DS_ARM_Win32_v2018.R1_b180326.exe のアクティベーションに失敗しました。 アクティベーションコードの有効期限が切れました：8FE5-AD8E-E76D-42C8