FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times I've recently been researching the power supply timing and mode switching for the FS2630. After switching the board to OTP emulation mode, downloading the mirror register, and switching SW7 to OFF, the initialization process began. Everything proceeded normally until normal mode was reached. Then, wakeup1 was configured as the wake-up source, and a standby command was sent. The FS2630 entered standby mode, and everything was normal at this point (no INT was triggered). However, after switching SW2, the NXP GUI INT reported VPRE_UVH and other INTs, and the FS2630's FS_STATUS also became 0-Undefined. Why didn't it return to normal mode? Afterwards, I turned off the 12V power supply to the FS2630 EVB board and prepared to try again. I found that the NXP GUI could not read the register values. I finally discovered that MOSI and SCK were shorted to ground. This happened twice, and I have no clue what to do. I hope you can give me some ideas? Recently, I have been studying the FS2630 power-up sequence and mode switching. The board is switched to OTP Emulation Mode. After downloading the mirror registers and setting SW7 to OFF, I start the initialization process and everything works normally until the device reaches Normal Mode. Next, I configure WAKEUP1 as the wake-up source and send the Standby command. The FS2630 enters Standby Mode, and at this point everything is still normal (INT is not triggered). However, when I toggle SW2, the NXP GUI reports a VPRE_UVH interrupt along with other interrupts. At the same time, the FS_STATUS of the FS2630 changes to 0 - Undefined. Why doesn't the device return to Normal Mode? In addition, I later turned off the 12 V power supply to the FS2630 EVB and attempted to repeat the process. I found that the NXP GUI could no longer read the register values. After some investigation, I discovered that MOSI and SCK were shorted to ground. This issue has occurred twice, and I have no clear idea what is causing it. I would appreciate any suggestions or insights on where to start troubleshooting. Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times I read the register M_WIO_FLG, M_REG_FLG, and M_VSUP_FLG after toggling SW2, M_REG_FLG: 0X00a0 M_VSUP_FLG: 0X0000 M_WIO_FLG: 0X0f00 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times I have another quesition,  LDT function 5, In Low Power mode, the count can not stop by the other wake-up event occurs? the count can only stop by overflows or LDT_EN=0 ?  the FS2630 has been waked up by other wake-up event before the count is running overflow,  then the count is running overflow, what will the FS2630 happen ? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times OK, I buy the MFS2630AMDA0AD , is shipping , I will read the register after receive the chip  another question 1 : FS2630 VDDIO and VBAT can power on simultaneously?  I have 4 questions about FS2630:  FS2630上电过程中如果MCU与SBC连接的RESET_B pin 被MCU 拉低，SBC的上电时序会受到什么影响？ FS2630正常工作过程中如果MCU与SBC连接的RESET_B pin 被MCU 拉低，SBC的行为会是什么？ FS2630通过接收MCU的SPI 进入low power 模式，接收命令后的行为是什么？是否有延时设置？ FS2630进入standby / LPOO后，通过唤醒源唤醒后，唤醒后的上电时序如何？ Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times Hello! Based on your description, it appears that the WAKE1 event is being detected and the FS2630 is attempting to exit Standby mode. However, the reported VPRE_UVH interrupt suggests that a voltage-related fault may be occurring during the Standby-to-Normal transition, preventing the device from completing the wake-up sequence successfully. As a result, the device may not be able to return to Normal mode and the FS_STATUS may appear as undefined. To help narrow down the root cause, could you please provide the following information? The values of M_WIO_FLG, M_REG_FLG, and M_VSUP_FLG after toggling SW2. Regarding the second issue, the behavior where MOSI and SCK appear shorted to ground is not expected under normal operation. Since this has occurred twice, we recommend checking if the EVB hardware for any damage or unintended shorts. Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times Hello, Yes, VBAT and VDDIO can be powered at the same time. 1. During the FS2630 power-up sequence, if the MCU pulls RESET_B low, what is the impact? The FS26 power-up sequence continues normally. However, because RSTB is bidirectional, the MCU can keep the reset line low even after the FS26 is ready to release it, keeping the MCU in reset. If RSTB remains low for more than 8 s, the device may enter Deep Fail-Safe. 2. During normal operation, if the MCU pulls RESET_B low, what happens? The reset line is asserted low, the MCU remains in reset, and the FS26 may assert the safety outputs according to its safety configuration. 3. What happens after the SPI command to enter Low Power mode? Is there a configurable delay? No configurable delay is described.  4. What is the power-up sequence after wake-up from Standby/LPOFF? Wake-up source detected → regulator startup sequence → LBIST (if enabled) → ABIST → RSTB release → INIT_FS state → watchdog refresh → release of safety outputs → Normal mode.  Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times Hello, Please capture VSUP, BATSENSE, VPRE, VDDIO, WAKE1, RSTB, and SPI signals before entering Standby, during Standby, and immediately after toggling SW2 with an oscilloscope. Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times Can an LDT Function 5 count be stopped by another wake-up event? No Can the count only stop by overflow or LDT_EN = 0? Yes. The LDT expires at timeout, or software can stop it by clearing LDT_EN = 0. If another wake-up source wakes the FS2630 before the LDT expires, and later the LDT reaches overflow, what happens? We do not have information about this specific case.  Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times Hello, No, The mirror register contents are not retained after a restart or a wake-up sequence. Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times VPRE  signal voltage is 6V on normal mode VPRE signal voltage is 5.35V on standby mode VPRE signal voltage : The voltage toggles/switches between 0V and 6V at a frequency of 450 kHz. By many  try, as I use FS2613AMDA0AD chip, use the OTP emulation to download the mirror register, the chip from standby mode to normal mode by the wakeup1 source,  the mirror register is lost , which lead to the VPRE voltage switches between 0V and 6V at a frequency of 450 kHz, Besides burning OTP, are there any other ways to solve this problem? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times a wake-up sequence include from standby / LPOFF mode to normal mode ?

Where to find AES_ACCEL Subsystem RM for S32K3? Hi，NXP I'm currently learning to use the AES_ACCEL​ module. I couldn't find much information in either the S32K3 Reference Manual​ or the HSE Reference Manual. The documentation mentions a dedicated AES_ACCEL Subsystem Reference Manual, but I wasn't able to locate it on the NXP website. Could you please provide a link or let me know where to download it? Thanks in advance. xianlong Re: Where to find AES_ACCEL Subsystem RM for S32K3? Hi @wuxianlong  I sent you a private message.

LPC55 USB 端点接收数据无响应 LPC55xx USB Re: LPC55 USB Endpoint rx data no respone 如果您需要任何进一步的帮助，请随时与我们联系。

S32K312 standby wakeup stops working after editing RamInit in startup_cm7.s to retain part of sram Description: In my linker script I have a 128-byte mailbox in SRAM at 0x20417F80 (top of RAM, NOLOAD, kept out of the init/zero tables). I use it to pass flags from my application to my bootloader when the application jumps to boot — this data needs to survive for programming flags  To stop the startup ECC-init loop from clearing that mailbox, I edited the RamInit section in startup_cm7.s so the zero loop stops before the mailbox instead of going to __INT_SRAM_END: RamInit: ldr r0, =__RAM_INIT cmp r0, 0 beq SRAM_LOOP_END ldr r0, =MCRGM_DES ldr r1, [r0] ldr r2, =MCRGM_DES_F_POR and r1, r1, r2 cmp r1, 0 beq NO_INIT_STANDBY_REGION ldr r1, =__INT_SRAM_START ldr r2, =__PBL_SBL_MAILBOX_ADDR ; <-- edited (was __INT_SRAM_END) b ZERO_64B_RAM NO_INIT_STANDBY_REGION: ldr r1, =__BSS_SRAM_START ldr r2, =__PBL_SBL_MAILBOX_ADDR ; <-- edited (was __INT_SRAM_END) ZERO_64B_RAM: With this edit, the mailbox retains correctly when the application jumps to the bootloader. for programming /flashing  But after this edit, standby wakeup stops working. My application goes into standby on IGN-low, and it no longer wakes up -the core gets stuck and doesn't resume. at rasr[] 0x2040012e  If I revert RamInit back to the default (loop ending at __INT_SRAM_END), then standby wakeup works fine again, but the mailbox is no longer retained. So the two are directly linked: the startup edit that retains my mailbox is what breaks my standby wakeup. My questions: Why does editing the RamInit region (changing where the SRAM zero loop stops) break standby wakeup? What in the standby/wakeup resume path depends on the startup RAM-init behavior? What is the correct way to modify startup so I can keep my mailbox region preserved across the application-to-bootloader jump, without breaking standby wakeup? Would switching to a different RTD version (e.g. RTD 2.0.0 or RTD 4.0.0) change this startup/wakeup behavior and resolve it, or is this independent of RTD version? Attachments: startup_cm7.s(txt) (edited RamInit), PBL linker script (txt) (shows mailbox at 0x20417F80), system.c.   S32DS-ARM     S32K312EVB-Q172     Debugging | Flash Programming SDKs Re: S32K312 standby wakeup stops working after editing RamInit in startup_cm7.s to retain part of s Hi @Arif9845, I can see you've also entered a support ticket; I will answer your questions through there so we can avoid any misunderstandings. Best regards, Julián

S32DS 3.5 S32K344 freertos OsifUseSystemTimer S32K344でMACLの代わりにFreeRTOSを使用する場合、OsifUseSystemTimerは使用できますか？使用できる場合、OsifCounterConfigのオプションはどのように設定すればよいですか？タイマーとしてPitまたはSTMを指定してOsifUseCustomTimerを使用する場合、OsifCounterConfigはどのように設定すればよいですか？ Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer もしこれを読んでいる方がいらっしゃいましたら、これは正しい情報ではありません。 OsIfsOperatingSystemTypeがOsIfFreeRtosTypeに設定されている場合、OsIfシステムタイマーは無効になります。 ベアメタルモードでのみ動作します https://community.nxp.com/t5/S32K/Microsecond-delay-outside-of-FreeRTOS-task-on-S32K344/td-p/1383622 Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer こんにちは、 @harryoceana さん。 すみません、FreeRTOSを使わずにシステムタイマーを使うという意味だと思っていました。オペレーティングシステムを使用している場合は、そのオペレーティングシステムの時計を使用する必要があります。 例えば、FreeRTOS_Toggle_Led_Example_S32K344では、 OsIfFreeRtosTypeが選択されており、代わりにFreeRTOSのクロックが使用されます。 よろしくお願いします、 ジュリアン Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer FreeRTOSでは、クロックリファレンスヒントはオペレーティングシステムなしでのみ使用できます。これは何か影響がありますか？ Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer こんにちは、 @harryoceana さん。 はい、システムタイマーは使えます。この投稿を参照してください:OSIFを使った遅延関数の解決 - NXPコミュニティ。 新しいRTDアップデートでは、MCALレイヤーにMCUドライバーの代わりに「Clock_Ip_ReferencePoints」コンポーネントを追加するだけで済みます。 よろしくお願いします、 ジュリアン

QorIQ T1024: Linux Ethernet driver stucks on high traffic Hello, I have a custom board with QorIQ T1024 processor running Linux Kernel version 5.4.3 (source https://github.com/nxp-qoriq/linux). I am now trying to migrate to the kernel version 6.6.52 (branch lf-6.6.y). The new kernel boots fine and all work as expected except Ethernet connection (100Mb, duplex full, autoneg off). Normal traffic using SSH or SFTP (transfer of large files) works. However, when I generate high traffic the connection stops working until reboot. Note that, this happens only in TX direction. RX direction works fine also on high traffic when running iperf test in direction PC -> target. I did not experience this issue on 5.4.3 kernel. When I run iperf test in direction target -> PC with limited bitrate 1Mb/s, the eth connection survives but full bitrate causes that functional Ethernet connection immediately stops working and stucks so I can't send data anymore nor ping the PC. The interface still appears as UP (ip link command). When I attempt to get interface statistics (ethtool -S ), ethtool hangs. I've learnt that the kernel driver is stuck and does not respond. When I attempt to turn off the interface, kernel messages are outputted - see attached ip_link_driver_busy.png On high traffic, when it stucks, bit PBSY_DF is set in register FMQM_PnS and does not get cleared. Documentation says that it means response from Qman did not arrive. It appears like on high traffic, there is some problem with allocation/deallocation of resources in TX direction and it remains in locked state. The driver seems to be stucked while waiting for HW, a lock or a system resource. The only way to recover is reboot. Setting the interface down and up does not help. I have upgraded Fman microcode to fsl_fman_ucode_t1024_r1.0_108_4_9.bin without any effect. Is QorIQ T1024 still supported in 6.6.y kernels? Are you aware of any changes incompatible with T1024? Are the FSL SDK DPAA and FSL SDK FMAN drivers still maintained in 6.6.y kernels? Are there any changes between version 5.4.3 and 6.6.52 that might break the functionality on T1024? Kernel sources I am using: Old: https://github.com/nxp-qoriq/linux/tree/134788b16485dd9fa81988681d2365ee38633fa2 New: https://github.com/nxp-qoriq/linux/tree/e0f9e2afd4cff3f02d71891244b4aa5899dfc786 Snippet of my kernel 6.6.52 config: # # Frame Manager support # CONFIG_FSL_SDK_FMAN=y # CONFIG_FSL_SDK_FMAN_TEST is not set # # FMAN Processor support # # CONFIG_FMAN_P3040_P4080_P5020 is not set # CONFIG_FMAN_P1023 is not set # CONFIG_FMAN_V3H is not set CONFIG_FMAN_V3L=y # end of FMAN Processor support # CONFIG_FSL_SDK_FMAN_RTC_API is not set # CONFIG_FMAN_MIB_CNT_OVF_IRQ_EN is not set CONFIG_FSL_FM_MAX_FRAME_SIZE=1522 CONFIG_FSL_FM_RX_EXTRA_HEADROOM=64 # CONFIG_FMAN_PFC is not set # end of Frame Manager support CONFIG_FSL_SDK_DPAA_ETH=y # CONFIG_FSL_DPAA_HOOKS is not set CONFIG_FSL_DPAA_OFFLINE_PORTS=y CONFIG_FSL_DPAA_ADVANCED_DRIVERS=y # CONFIG_FSL_DPAA_ETH_JUMBO_FRAME is not set # CONFIG_FSL_DPAA_TS is not set # CONFIG_FSL_DPAA_1588 is not set CONFIG_FSL_DPAA_ETH_MAX_BUF_COUNT=1024 CONFIG_FSL_DPAA_ETH_REFILL_THRESHOLD=512 CONFIG_FSL_DPAA_CS_THRESHOLD_1G=0x06000000 CONFIG_FSL_DPAA_CS_THRESHOLD_10G=0x10000000 CONFIG_FSL_DPAA_INGRESS_CS_THRESHOLD=0x10000000 CONFIG_FSL_DPAA_ETH_DEBUGFS=y CONFIG_FSL_DPAA_ETH_DEBUG=y # CONFIG_FSL_DPAA_DBG_LOOP is not set Appreciate any help. Thank you, Jiri QorIQ T1 Devices Re: QorIQ T1024: Linux Ethernet driver stucks on high traffic Hello, Based on the support status of the QorIQ Power Architecture T-series software, T1024 should not be considered officially supported on the newer lf-6.6.y kernel branch . NXP’s official SDK support for T1024/T-series ended with the older QorIQ SDK line. The documented guidance says there is no SDK release for T1024 after SDK 2.0-1703 , and SDK 2.0-1703 used kernel 4.1.35 . NXP guidance also states that newer Linux BSPs may still contain T1024-related files, but they are not released to officially support T-series . Another NXP support statement says there is no official release after SDK 2.0-1703 for T-series products and no continuing SDK upgrade plan for that product line . So the presence of T1024, DPAA, FMAN, QMan, or BMan code in lf-6.6.y should not be interpreted as NXP validation of T1024 operation on that kernel branch. The public nxp-qoriq/linux repository is a general QorIQ Linux tree, but the branch contents alone do not establish T1024 support or validation for 6.6.x This is not a PHY/autoneg issue; the evidence points to a TX DPAA/QMan hang on an unvalidated T1024 kernel baseline, so the practical path is either stay on the working supported/validated baseline or debug the 6.6 port as custom maintenance. Regards  

在修改 startup_cm7.s 中的 RamInit 后，S32K312 的待机唤醒功能停止工作。保留部分 sram 说明： 在我的链接器脚本中，我在 SRAM 的 0x20417F80 处有一个 128 字节的邮箱（RAM 顶部，NOLOAD，不包含在 init/零表中）。我用它来在应用程序启动时将标志从应用程序传递给引导加载程序——这些数据需要保留下来以用于编程标志。 为了阻止启动时的 ECC 初始化循环清除该邮箱，我编辑了 startup_cm7.s 文件中的 RamInit 部分。因此，零循环在邮箱之前停止，而不是进入__INT_SRAM_END： RamInit： ldr r0，=__RAM_INIT cmp r0, 0 beq SRAM_LOOP_END ldr r0，=MCRGM_DES ldr r1，[r0] ldr r2，=MCRGM_DES_F_POR 以及 r1、r1、r2 cmp r1，0 beq NO_INIT_STANDBY_REGION ldr r1, =__INT_SRAM_START ldr r2, =__PBL_SBL_MAILBOX_ADDR ; <-- 已编辑（原为 __INT_SRAM_END） b ZERO_64B_RAM NO_INIT_STANDBY_REGION： ldr r1, =__BSS_SRAM_START ldr r2, =__PBL_SBL_MAILBOX_ADDR ; <-- 已编辑（原为 __INT_SRAM_END） ZERO_64B_RAM： 通过此修改，当应用程序跳转到引导加载程序时，邮箱可以正确保留。用于编程/刷写 但修改后，待机唤醒功能停止工作了。我的应用程序在 IGN-low 状态下进入待机状态，并且不再唤醒——核心卡住无法恢复。在 rasr[] 0x2040012e 如果我将 RamInit 恢复为默认值（循环在 __INT_SRAM_END 结束），则备用唤醒功能可以再次正常工作，但邮箱将不再保留。 所以这两者直接相关：保留我的邮箱的启动编辑破坏了我的备用唤醒功能。 我的问题： 为什么编辑 RamInit 区域（改变 SRAM 零循环停止的位置）会导致待机唤醒功能失效？待机/唤醒恢复路径中的哪些部分取决于启动时的 RAM 初始化行为？ 如何正确修改启动程序，以便在应用程序到引导加载程序跳转过程中保持邮箱区域不变，同时又不破坏待机唤醒功能？ 换用不同的即饮型饮料（例如）会怎么样？RTD 2.0.0 或 RTD 4.0.0）更改此启动/唤醒行为并解决此问题，或者这与 RTD 版本无关？ 附件： startup_cm7.s(txt)（编辑了 RamInit），PBL 链接器脚本（txt）（显示邮箱位于 0x20417F80），system.c. S32DS-ARM S32K312EVB-Q172 调试 | Flash 编程 SDK Re: S32K312 standby wakeup stops working after editing RamInit in startup_cm7.s to retain part of s 你好@Arif9845 ， 我看到您也提交了支持工单；我将通过工单回答您的问题，以免产生任何误解。 此致， 朱利安

LPC55 USBエンドポイント受信データ応答なし LPC55xx USB Re: LPC55 USB Endpoint rx data no respone さらにお助けが必要な場合は、どうぞお気軽にお問い合わせください。

iMX95 FRDM用のlibcameraをビルドする方法 現在、Ubuntu 20.04が動作するホストPC上でlibcameraをクローンしてビルドすることができています。提供されているREADMEファイルには、使用する必要のあるツールチェーンに関する情報が一切記載されていません。これを克服するにはどうすればよいでしょうか？IMX95 FRDM用のyoctoビルド用のソースが提供されているのでしょうか?それを使ってSDKを入力し、それに応じてビルドできるでしょうか? Re: How to build the libcamera for iMX95 FRDM オプション1(推奨):Yocto内にlibcameraを構築する FRDM-i.MX95 用に libcamera を変更または再構築することが目的の場合： お使いのボード/カーネルバージョンに対応するi.MX BSPリリースをダウンロードしてください。 Yocto環境をセットアップしてください。 Yoctoパッケージとしてlibcameraを構築する: bitbake libcamera または画像に含めてください。 IMAGE_INSTALL:append = " libcamera" 次に再構築する： bitbake imx-image-full ` これにより、以下のことが保証されます。 正しいaarch64コンパイラ 正しいカーネルヘッダー NXP Neoパイプラインサポート 一致するIPAバイナリ 対応するGStreamer libcamerasrcプラグイン これはi.MX95にとって最も安全なルートです。 オプション2:Yoctoの外側でリブカメラをクロスビルド Ubuntu 20.04 に既に libcamera をクローンしていて、手動でクロスビルドしたい場合は、以下の手順に従ってください。 ホストのgccを使用しないでください。 代わりにYoctoからSDKを生成してください: bitbake imx-image-full -c populate_sdk i.MX Linuxユーザーズガイドでは、SDK生成とYoctoベースのワークフローについて明示的に言及しています。 SDKが生成された後: tmp/デプロイ/sdk/*.sh インストールしてください： ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh 環境の源泉： ソース /opt/FSL-IMX-Xwayland/ /environment-setup-aarch64-poky-linux 次に、mesonを使用してlibcameraをビルドします。 シェル メソンセットアップビルド --cross-file= ニンジャ -C ビルド 正確なクロスファイルはSDKのリリースとBSPバージョンによって異なります。 i.MX95用のYoctoソースはありますか? はい。内部Linuxユーザーガイドに基づき、i.MX95のサポートは標準のNXP Yocto BSPおよびmeta-imxインフラストラクチャを通じて提供されています。このガイドでは、以下の点についても言及しています。 bitbake imx-image-full また、meta-imxのREADMEやYoctoのドキュメントへのユーザーを案内します。[UG10163_i....-09_review | PDF] 特にFRDM-i.MX95の場合、ボードの資料によると、ボードには組み込みLinuxのYoctoソリューションが搭載されています

Output UART data on Arduino Pins on MCXN947 I was trying to output UART data through Arduino pins :P4_3/FC2_UART_RXD-ARD_D0 / P4_2/FC2_UART_TXD-ARD_D1 instead of using internal debugger (MCU-Link). Based on that I changed the pin mux and tried to test with simple loopback test. But it not at all working. I even tried with different pins. Am I missing some configuration setting other than Mux? I am attaching my project for reference. Looking forward for help. Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO)

[安全启动] S32K14X 37.5.8.4 允许同时进行闪存操作 尊敬的恩智浦 S32K-RM.pdf 37.5.8.4 允许同时进行闪存操作 根据上图可知，CSEc 和 P-Flash 读取操作之间存在**竞争条件**（如红色方框所示）。 因此，从 P-Flash 调用 `CSEC_DRV_VerifyMAC` 时，是否应应用以下变通方法？ 1. 在调用 `CSEC_DRV_VerifyMAC` 之前**禁用中断**，并在函数返回后**重新启用中断**。 2. **将 `CSEC_DRV_VerifyMAC` 重新定位到 RAM 中执行**（即，从 RAM 而不是 P-Flash 运行该函数）。 Re: [secureboot] S32K14X 37.5.8.4 Allowed simultaneous flash operations 嗨@Prophet_Samuel 这里已经讨论过类似的问题了： https://community.nxp.com/t5/S32K/use-CSEC-DRV-GenerateMACAddrMode-to-generate-CMAC-but-occurs/mp/1531146/highlight/true#M18072 只需禁用中断即可，因为 SDK 中的 CSEc 驱动程序已经从 RAM 执行代码的关键部分。 还有一点——CSEC_DRV_VerifyMAC 和 CSEC_DRV_VerifyMACAddrMode 之间存在差异（CSEC_DRV_GenerateMAC 和 CSEC_DRV_GenerateMACAddrMode 之间也存在差异）。 只有指针方法（这是 S32K1 参考手册中的术语）。SDK API 使用“addr 模式”，不允许在执行期间访问程序闪存。普通的非指针方法没有这种限制。 此致， Lukas

FS2630評価ボード、FS2630のMOSIピンとSCKピンがショートしており、3倍 最近、FS2630の電源タイミングとモード切り替えについて調べています。 ボードをOTPエミュレーションモードに切り替え、ミラーレジスタをダウンロードし、SW7をOFFに切り替えた後、初期化プロセスが開始されました。通常モードに達するまで、すべて正常に進行しました。次に、ウェイクアップソースとしてwakeup1が設定され、スタンバイコマンドが送信されました。FS2630はスタンバイモードに入り、この時点ではすべて正常でした（INTはトリガーされませんでした）。しかし、SW2を切り替えた後、NXP GUI INTはVPRE_UVHなどのINTを報告し、FS2630のFS_STATUSも0-Undefinedになりました。なぜ通常モードに戻らなかったのでしょうか？ その後、FS2630 EVBボードへの12V電源をオフにして、再度試す準備をしました。すると、NXP GUIがレジスタ値を読み取れないことがわかりました。最終的に、MOSIとSCKがグランドに短絡していることが判明しました。これが2回発生し、どうすればよいのか全く見当がつきません。何かアドバイスをいただけないでしょうか？ 最近、FS2630の電源投入シーケンスとモード切り替えについて研究しています。 ボードはOTPエミュレーションモードに切り替わりました。ミラーレジスタをダウンロードし、SW7をOFFに設定した後、初期化プロセスを開始すると、デバイスがノーマルモードに達するまで全て正常に動作します。 次に、WAKEUP1をウェイクアップソースとして設定し、スタンバイコマンドを送信します。FS2630はスタンバイモードに入り、この時点ではすべてが正常です（INTはトリガーされません）。 しかし、SW2を切り替えると、NXP GUIは他の割り込みとともにVPRE_UVH割り込みを報告します。同時に、FS2630のFS_STATUSが0 - 未定義に変わります。なぜデバイスは通常モードに戻らないのですか？ さらに、その後、FS2630 EVBへの12V電源をオフにして、同じ手順を繰り返してみました。NXPのGUIがレジスタ値を読み取れなくなっていることに気づきました。調査の結果、MOSIとSCKが接地短絡していることが判明しました。 この問題は2回発生しており、原因が全く分かりません。トラブルシューティングを始めるにあたって、何かご提案やご意見があればぜひお聞かせください。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times SW2を切り替えた後、レジスタM_WIO_FLG、M_REG_FLG、およびM_VSUP_FLGを読み取りました。 M_REG_FLG: 0X00a0 M_VSUP_FLG: 0X0000 M_WIO_FLG: 0X0f00 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times もう一つ質問があります。 LDT機能5、低消費電力モードでは、他のウェイクアップイベントが起きてカウントが止まらないのですか? カウントはオーバーフローかLDT_EN=0 ? FS2630はカウントオーバーフローが始まる前に他のウェイクアップイベントで起きており、その後カウントがオーバーフローになっている場合、FS2630はどうなるのでしょうか? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times はい、MFS2630AMDA0ADを購入しました。発送済みです。チップを受け取ったらレジスタを読み取ります。 別の質問1:FS2630のVDDIOとVBATは同時に電源を入れられますか? FS2630について4つ質問があります。 FS2630上電過程ならMCU与SBC连接的RESET_B pin 被MCU 拉低,SBC的上电时序会受到什么影响? FS2630正常工作过程中ならMCU与SBC连接的RESET_B pin 被MCU 拉低,SBC的行为会是什么? FS2630通过接收MCU的SPI進入low power 模式,接收命令后的行为是什么?是否有延时设置? FS2630がスタンバイ/LPOOに入った後、覚醒ソース経由で覚醒後、覚醒後の上電時系列はどのようになりますか？ Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは！ 説明からすると、WAKE1イベントが検出されており、FS2630がスタンバイモードから退出しようとしているようです。しかし、報告されたVPRE_UVH割り込みは、スタンバイ状態から通常状態への移行中に電圧関連の障害が発生し、デバイスがウェイクアップシーケンスを正常に完了できない可能性があることを示唆しています。その結果、デバイスが通常モードに戻れなくなり、FS_STATUSが未定義と表示される可能性があります。 根本原因を絞り込むために、以下の情報を教えていただけますか? SW2を切り替えた後のM_WIO_FLG、M_REG_FLG、およびM_VSUP_FLGの値。 2つ目の問題に関してですが、MOSIとSCKがグランドに短絡しているように見える動作は、通常の動作では想定されていません。このような事態が2回発生しているため、EVBハードウェアに損傷や意図しないショートがないか確認することをお勧めします。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times LDT機能5カウントは別の起床イベントで止まることがありますか? いいえ カウントはオーバーフローや LDT_EN = 0 まで止まるのでしょうか? はい。LDTはタイムアウト時に期限切れになります。またはソフトウェアがLDT_EN = 0をクリアして停止できます。 LDTの期限が切れる前に別のウェイクアップソースによってFS2630がウェイクアップされ、その後LDTがオーバーフローした場合、どうなりますか？ この特定の事件に関する情報はありません。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 はい、VBATとVDDIOは同時に電源を供給できます。 1.FS2630の電源を入れるシーケンス中に、MCUがRESET_Bを引いたら、どのような影響がありますか? FS26の電源起動シーケンスは通常通り続きます。しかし、RSTBは双方向であるため、FS26がリセットラインをリリースする準備が整ってもMCUは低く保ち、リセットされたままにできます。RSTBが8秒以上低血糖を維持すると、デバイスはディープフェイルセーフに入ることがあります。 2. 通常の運用中にMCUがRESET_Bを低下させた場合、どうなるのか? リセットラインは低くアサートされ、MCUはリセットされたまま、FS26はセーフティ設定に応じてセーフティ出力をアサートできます。 3. SPIコマンドで低電力モードに入ると、何が起こりますか？設定可能な遅延時間はありますか？ 設定可能な遅延時間については記載されていません。 4. スタンバイ/LPOFFからの起床後のパワーアップシーケンスは? ウェイクアップソース検出 → レギュレーター起動シーケンス → LBIST (有効な場合) → ABIST → RSTBリリース → INIT_FS状態 → ウォッチドッグリフレッシュ → セーフティ出力の解放 → ノーマルモード。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 スタンバイモードに入る前、スタンバイモード中、およびSW2を切り替えた直後に、VSUP、BATSENSE、VPRE、VDDIO、WAKE1、RSTB、およびSPI信号をオシロスコープでキャプチャしてください。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 いいえ、ミラーレジスタの内容は再起動またはウェイクアップシーケンス後には保持されません。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 通常モードでのVPRE信号電圧は6Vです。 スタンバイモード時のVPRE信号電圧は5.35Vです。 VPRE信号電圧:電圧は450kHzの周波数で0Vから6Vの間を切り替えます。 多くの人が試していますが、私FS2613AMDA0ADチップを使ってOTPエミュレーションでミラーレジスタをダウンロードします。ウェイクアップ1ソースによってチップはスタンバイモードからノーマルモードに移行しますが、ミラーレジスタが失われ、その結果VPRE電圧 スイッチが450kHzの周波数で0Vから6Vの間で変わります。 OTPを焼く以外に、この問題を解決する方法はありますか? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times スタンバイ/LPOFFモードから通常モードへのウェイクアップシーケンスが含まれますか？

How to build the libcamera for iMX95 FRDM I have currently cloned and able to build libcamera in my HOST PC which runs on ubuntu 20.04. The README provided doesnt provide any information regarding the tool chain needed to be used. How to overcome this ? Is there a source provided for yocto build for the IMX95 FRDM so with that we can able to populate SDK and build accordingly. Re: How to build the libcamera for iMX95 FRDM Option 1 (Recommended): Build libcamera inside Yocto If your goal is to modify or rebuild libcamera for FRDM-i.MX95: Download the i.MX BSP release corresponding to your board/kernel version. Set up the Yocto environment. Build libcamera as a Yocto package: bitbake libcamera or include it in your image: IMAGE_INSTALL:append = " libcamera" Then rebuild: bitbake imx-image-full ` This ensures: Correct aarch64 compiler Correct kernel headers NXP Neo pipeline support Matching IPA binaries Matching GStreamer libcamerasrc plugin This is the safest route for i.MX95. Option 2: Cross-build libcamera outside Yocto If you already cloned libcamera on Ubuntu 20.04 and want to cross-build it manually: You should not use the host gcc. Instead generate the SDK from Yocto: bitbake imx-image-full -c populate_sdk The i.MX Linux User's Guide explicitly references SDK generation and Yocto-based workflows. After the SDK is generated: tmp/deploy/sdk/*.sh Install it: ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh Source the environment: source /opt/fsl-imx-xwayland/ /environment-setup-aarch64-poky-linux Then build libcamera using meson: Shell meson setup build \ --cross-file= ninja -C build The exact cross-file depends on the SDK release and BSP version. Is there Yocto source available for i.MX95? Yes. Based on the internal Linux User Guide, i.MX95 support is provided through the standard NXP Yocto BSP and meta-imx infrastructure. The guide also references: bitbake imx-image-full and points users to the meta-imx README and Yocto documentation. [UG10163_i....-09_review | PDF] For FRDM-i.MX95 specifically, the board ships with an Embedded Linux Yocto solution according to the board collateral

将 UART 数据输出到 Arduino 引脚上的 MCXN947 我尝试通过 Arduino 引脚 :P4_3/FC2_UART_RXD-ARD_D0 / P4_2/FC2_UART_TXD-ARD_D1 输出 UART 数据，而不是使用内部调试器 (MCU-Link)。基于此，我更改了引脚复用器，并尝试使用简单的环回测试进行测试。但这完全行不通。我甚至尝试过使用不同的别针。除了 Mux 之外，我是否还遗漏了其他配置设置？ 我附上我的项目供您参考。期待您的帮助。 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO）

S32DS 3.5 S32K344 freertos OsifUseSystemTimer If using FreeRTOS instead of MACL on the S32K344, can OsifUseSystemTimer be used? If so, how should the options in OsifCounterConfig be configured? If OsifUseCustomTimer is used, with Pit or STM as the timer, how should OsifCounterConfig be configured? Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer If anyone is reading this, this is not correct information. When OsIfsOperatingSystemType is set to OsIfFreeRtosType, the OsIf System Timer is disabled. Works only in baremetal mode https://community.nxp.com/t5/S32K/Microsecond-delay-outside-of-FreeRTOS-task-on-S32K344/td-p/1383622  Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer Hi @harryoceana, Sorry, I thought you meant to use System Timer without FreeRTOS. If you are using any operating system, you must use that clock instead. For example, in FreeRTOS_Toggle_Led_Example_S32K344, the OsIfFreeRtosType choice is set, and the FreeRTOS clock is used instead. Best regards, Julián Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer In FreeRTOS, the clock reference hint can only be used without an operating system. Does this have any impact? Re: S32DS 3.5 S32K344 freertos OsifUseSystemTimer Hi @harryoceana, Yes, you can use the System Timer. Please refer to this post: Solved: Delay function using OSIF - NXP Community. In the newer RTD updates, you can simply add the "Clock_Ip_ReferencePoints" component instead of the Mcu driver in the MCAL layer: Best regards, Julián

如何为 iMX95 FRDM 构建 libcamera 目前我已经克隆并能够在运行 ubuntu 20.04 的主机 PC 上构建 libcamera。提供的 README 文件没有提供任何关于所需工具链的信息。如何克服这个问题？是否有适用于 IMX95 FRDM 的 Yocto 构建源代码，以便我们能够填充 SDK 并进行相应的构建？ Re: How to build the libcamera for iMX95 FRDM 选项 1（推荐）：在 Yocto 内部构建 libcamera 如果您的目标是修改或重新构建适用于 FRDM-i.MX95 的 libcamera： 下载与您的开发板/内核版本对应的 i.MX BSP 版本。 设置 Yocto 环境。 将 libcamera 构建为 Yocto 软件包： bitbake libcamera 或者将其包含在您的图片中： IMAGE_INSTALL:append = " libcamera" 然后重建： bitbake imx-image-full ` 这确保： 正确的 aarch64 编译器 正确的内核头文件 NXP Neo 流水线支持 匹配的IPA二进制文件 匹配 GStreamer libcamerasrc 插件 这是 i.MX95 最安全的路线。 方案二：在 Yocto 之外交叉编译 libcamera 如果您已经在 Ubuntu 20.04 上克隆了 libcamera，并且想要手动交叉编译它： 你不应该使用主机上的 gcc 。 而是从 Yocto 生成 SDK： bitbake imx-image-full -c populate_sdk i.MX Linux 用户指南明确提到了 SDK 生成和基于 Yocto 的工作流程。 SDK生成之后： tmp/deploy/sdk/*.sh 安装它： ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh 环境来源： 源 /opt/fsl-imx-xwayland/ /environment-setup-aarch64-poky-linux 然后使用 meson 构建 libcamera： shell meson 设置 版本 \ --cross-file= ninja -C 版本 具体交叉文件取决于 SDK 版本和 电路板支持包。 版本。 是否有适用于 i.MX95 的 Yocto 源代码？ 是的。根据内部 Linux 用户指南，i.MX95 支持通过标准的 NXP Yocto 电路板支持包和 meta-imx 基础架构提供。该指南还提到： bitbake imx-image-full 并引导用户查看 meta-imx README 和 Yocto 文档。[UG10163_i....-09_review | PDF] 具体到 FRDM-i.MX95，根据电路板说明书，该电路板预装了嵌入式 Linux Yocto 解决方案。

Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT). 3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow. 4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.

Designing a CAN-Based Communication Hub with the S32N55 using Model Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement. 3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation. 4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent. Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate. 5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors 6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.

S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello, I am developing an application on the following platform: MCU: NXP S32K314 RTD 7.0.0 (AUTOSAR MCAL) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 During development, I encountered a deadlock related to high-priority interrupts and would like to ask whether my understanding is correct and whether there is a recommended solution. Background FreeRTOS specifies that ISRs with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY must not call FreeRTOS APIs. However, I found that many RTD MCAL APIs internally execute FreeRTOS critical section APIs through the following call chain: MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() and MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() This behavior exists even in APIs that only perform simple peripheral register accesses, such as DIO and GPT. Problem When a MCAL API is called from a high-priority ISR (priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY), the internal call to taskENTER_CRITICAL_FROM_ISR() causes the FreeRTOS interrupt masking state to become inconsistent. As a result, after taskEXIT_CRITICAL_FROM_ISR() returns, BASEPRI is not restored correctly, causing lower-priority interrupts such as SysTick and PendSV to remain masked. The scheduler eventually stops because xPortSysTickHandler() is no longer executed. I was able to reproduce this issue using APIs such as: Dio_FlipChannel() GPT (PIT) interrupt processing Other MCAL APIs that use SchM exclusive areas Current Workaround To avoid modifying RTD-generated source code directly, I used the GNU linker --wrap option to wrap the following functions: OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() The wrapper checks the current interrupt priority. Please refer to the attached WrapperExample.c. If the current ISR priority is higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, it skips the original function. Otherwise, it calls the original implementation. This workaround appears to resolve the deadlock while leaving the generated RTD source unchanged. Questions Is this behavior expected by design in the RTD MCAL? Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Is there an official or recommended solution for this problem that does not require modifying generated RTD source code? Any advice or recommendations would be greatly appreciated. Thank you. Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello @tobara, The case is currently pending input from the RTD development team. BR, Daniel Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hi, please see below punctual answers to your question: Is this behavior expected by design in the RTD MCAL?Answer: yes, this happens because you are calling OS APIs from a CAT1 interrupt (aka interrupts with prio higher than MAX SYSCALL).  The purse of interrupts higher than MAX_SYSCALL is to do work with minimal latency also unhindered by the RTOS.If you need to avoid latency introduced by RTOS then you should not call APIs that in the end use the RTOS. Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Answer:  no, not larger than MAX_SYSCAL, for the reason mentioned in first answer. Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Answer: if you already can tolerate the latency introduced by the RTD SchM, OSIf APIs, RTOS then you can just use the existing drivers but just call them from the higher interrupt but lower than MAX_SYSCALL. You still get the priority boost but not the problems described in the ticket. Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Answer: No, a quick analysis points in the direction that this workaround protects in only one direction. It might avoid the deadlock but does not protect lower prio ISR that share registers / resources with higher prio ISR (> MAX_SYSCALL). This implementation can introduce race conditions on shared registers and global variables. Is there an official or recommended solution for this problem that does not require modifying generated RTD source code?Answer (but it needs to be confirmed by the RTD team): do not call RTD / RTOS APIs from IRQ > MAX_SYSCALL. If you can tolerate the current RTD->OSIF->RTOS latencies then just use a  higher prio IRQ but lower than MAX_SYSCALL. All answers need to be confirmed by the RTD team, I'm answering from a RTOS point of view.

S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 你好， 我正在以下平台上开发一个应用程序： MCU：NXP S32K314 RTD 7.0.0（AUTOSAR MCAL） FreeRTOS 7.0.0 S32 设计工作室 3.6.4 在开发过程中，我遇到了与高优先级中断相关的死锁，想请教一下我的理解是否正确，以及是否有推荐的解决方案。 背景信息 FreeRTOS 规定优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 的中断服务例程 (ISR) 不得调用 FreeRTOS API。 然而，我发现许多 RTD MCAL API 在内部通过以下调用链执行 FreeRTOS 临界区 API： MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() 以及 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() 即使在仅执行简单外设寄存器访问的 API（例如 DIO 和 GPT）中，也存在这种行为。 问题 当从高优先级 ISR（优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY）调用 MCAL API 时，对 taskENTER_CRITICAL_FROM_ISR() 的内部调用会导致 FreeRTOS 中断屏蔽状态变得不一致。 因此，在 taskEXIT_CRITICAL_FROM_ISR() 返回后，BASEPRI 无法正确恢复，导致 SysTick 和 PendSV 等低优先级中断保持屏蔽状态。 调度程序最终停止，因为 xPortSysTickHandler() 不再执行。 我使用以下 API 重现了这个问题： Dio_FlipChannel() GPT（PIT）中断处理 其他使用 SchM 专属区域的 MCAL API 当前解决方法 为了避免直接修改 RTD 生成的源代码，我使用了 GNU 链接器的 --wrap 选项来包装以下函数： OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() 该包装器会检查当前的中断优先级。 请参考附件WrapperExample.c 。 如果当前 ISR 优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY，则跳过原始函数。 否则，它将调用原始实现。 这种变通方法似乎可以解决死锁问题，同时保持生成的 RTD 源不变。 问题 RTD MCAL 的这种行为是设计预期的吗？ 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？ 任何建议或推荐都将不胜感激。 谢谢！ Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 你好@tobara ， 目前该案件正在等待RTD开发团队的意见。 BR，丹尼尔 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 您好， 以下是对您问题的及时解答： RTD MCAL 的这种行为是预期行为吗？答：是的，这是因为您正在从 CAT1 中断（即优先级高于 MAX SYSCALL 的中断）调用操作系统 API。大于 MAX_SYSCALL 的中断次数是为了以最小的延迟完成工作，并且不受 RTOS 的干扰。如果您需要避免 RTOS 引入的延迟，则不应该调用最终会使用 RTOS 的 API。 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ 答：不，不能大于 MAX_SYSCAL，原因已在第一个答案中提及。 NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 回答： 如果您已经能够容忍 RTD SchM、OSIf API、RTOS 引入的延迟，那么您可以直接使用现有的驱动程序，但只需从高于 MAX_SYSCALL 的中断调用它们即可。您仍然可以获得优先级提升，但不会遇到工单中描述的问题。 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 答：不，简单的分析表明，这种变通方法只能在一个方向上起到保护作用。它或许可以避免死锁，但不能保护与优先级更高的 ISR (> MAX_SYSCALL) 共享寄存器/资源的优先级较低的 ISR。这种实现方式可能会在共享寄存器和全局变量上引入竞争条件。 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？答案（但需要 RTD 团队确认） ：不要从 IRQ > MAX_SYSCALL 调用 RTD / RTOS API。如果您可以容忍当前的 RTD->OSIF->RTOS 延迟，那么只需使用优先级更高的 IRQ，但低于 MAX_SYSCALL 即可。 所有答案都需要RTD团队确认，我是从RTOS的角度回答的。