Automotive Brake Status Monitoring Using S32K3 Microcontrollers Overview This article demonstrates how to implement a brake status monitoring system using NXP S32K3 microcontrollers. The solution is based on Application Code Hub examples for S32K344 and S32K312 platforms and showcases how real-time sensor data can be used to detect braking events and trigger visual feedback. This is based on the following Application Code Hub demonstrations: Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 The application simulates braking conditions using a sensor input and provides immediate system response via an LED indicator. Such systems are commonly used in automotive environments to improve system awareness and support safety-related functionality. Learning Scope This article covers both practical implementation and core embedded concepts, including: Reading analog signals using ADC Processing real-time signals Controlling outputs using GPIO Implementing decision logic based on thresholds Understanding signal flow in embedded systems System Architecture The application is built around a simple but representative embedded system: Input: Analog sensor (force / brake simulation) Processing: S32K3 microcontroller Output: LED indicator Functional Flow The sensor generates an analog signal proportional to applied force The ADC converts the analog signal into a digital value The software evaluates the value against defined thresholds The system updates the output (LED) based on braking state Brake Monitoring Application ArchitectureBrake Monitoring Application Architecture Key Concepts Analog Signal Acquisition (ADC) Sensors typically output analog values that must be digitized for processing. The ADC periodically samples this signal and produces a digital representation used by the application logic. Typical interpretation: Low value → no braking activity High value → braking detected Real-Time Signal Processing The system continuously reads sensor data and reacts immediately. This is essential in automotive contexts where delayed responses may impact system behavior. Output Control Using GPIO The LED output reflects the system state: OFF → no braking detected ON → braking condition detected In extended implementations, multiple states or patterns can be used. Hardware and Software Setup Required Hardware FRDM-A-S32K3xx development board FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 Force Click (or similar analog sensor module) Force ClickForce Click 4x4 RGB Click (LED output) 4X4 RGB Click4X4 RGB Click USB cable / power supply The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate brake inputs and outputs Software Environment S32 Design Studio S32K3 Automotive Software Package Application Code Hub project import Implementation Guide Step 1: Import the Project Open S32 Design Studio Use “Import project from Application Code Hub” Locate the brake monitoring example Import and configure the project Expected result: Project is successfully loaded into the workspace Step 2: Build the Application Compile the project Resolve any dependency issues if needed Expected result: No compilation errors Step 3: Connect Hardware Connect the development board via USB Attach sensor and LED modules Ensure correct pin connections Expected result: Board is powered and detected by the IDE Step 4: Flash and Run Program the MCU Start execution Expected result: Application runs continuously Step 5: Functional Validation Apply pressure to the sensor Observe LED behavior Expected result: LED activates when braking condition is detected Signal Behavior and Threshold Logic The application relies on threshold-based decision logic: If ADC value < threshold → no brake If ADC value ≥ threshold → brake active Placeholder: Signal vs Threshold Diagram Figure: Brake monitoring threshold behavior. The ADC raw value is converted into millivolts using a 0–5000 mV reference range. The converted value is compared against predefined thresholds to progressively activate the green, yellow, orange, and red LED columns.Figure: Brake monitoring threshold behavior. The ADC raw value is converted into millivolts using a 0–5000 mV reference range. The converted value is compared against predefined thresholds to progressively activate the green, yellow, orange, and red LED columns. Troubleshooting Board Not Detected Verify USB cable and drivers Check debugger connection Restart IDE No Output Response Validate GPIO configuration Check LED connections Confirm code execution Incorrect Sensor Readings Verify ADC configuration Inspect sensor wiring Confirm scaling and thresholds Extending the Application The basic implementation can be extended in several ways: Multi-Level Brake Detection Define multiple thresholds: Low → normal Medium → moderate braking High → emergency braking Noise Filtering Apply software filtering to stabilize readings Avoid false triggering from sensor noise Timing-Based Logic Add debounce or delay mechanisms Require sustained input before triggering State Machine Implementation A more advanced approach is to implement a state machine: Idle Braking Emergency Placeholder: State Machine Diagram [IMAGE_PLACEHOLDER: Brake State Machine] States: Idle → Brake → Emergency Transitions based on ADC thresholds Safety Context Although simplified, this application reflects concepts used in automotive safety systems: Continuous monitoring of input signals Immediate response to changes Clear indication of system state In real systems, additional mechanisms are required: Redundancy Fault detection Compliance with safety standards (e.g., ISO 26262) Conclusion This example demonstrates how a simple embedded application can model a real-world automotive use case. By combining ADC input, real-time processing, and GPIO output, it highlights the core principles behind monitoring functions in automotive ECUs. The provided implementation serves as a foundation for more advanced designs, including multi-state logic, filtering techniques, and safety-focused extensions. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

需要 S32K342 FOTA 引导加载程序架构指南（基于 UART 的更新） 您好，NXP团队， 我们正在为 S32K342 开发定制的固件空中升级 (FOTA) 解决方案，希望获得有关推荐的闪存架构和启动流程的指导。 MCU详情 设备：S32K342 PFlash：2 MB 银行 0：1 MB 银行 1：1 MB DFlash：128 KB 当前状态 我们使用UART作为固件更新接口。 目前为止，我们已成功做到： 通过 UART 接收固件（.bin 文件）。 将完整的二进制文件存储到闪存中 确认接收到的图像已正确存储。 我们剩下的挑战是实现引导加载程序架构和应用程序切换机制。 我们希望就以下问题获得澄清： 1. 推荐的FOTA Flash布局 对于 S32K342 双镜像 FOTA 实现，推荐的内存布局是什么？ 具体来说，我们想知道以下方面的推荐地点： 引导加载程序 应用插槽 A 应用插槽 B 元数据/启动标志 版本信息 CRC 回滚信息 提供一份包含地址的内存映射示例将非常有帮助。 2. 推荐的启动流程 请问有人能解释一下NXP推荐的完整启动顺序吗？ 例如： 重置 引导加载程序启动 检查启动标志 选择活动应用程序 验证图像（CRC/签名） 跳转到应用程序 我们希望能得到流程图或对整个流程的解释。 3. 从引导加载程序跳转到应用程序 对于 S32K342，标准的 Cortex-M7 跳转序列是否足够？ 例如： 从应用程序基地址读取 MSP 从基数 + 4 读取 Reset_Handler 设置 MSP 更新 VTOR 跳转到 Reset_Handler 在转移控制权之前，是否有任何 S32K342 特有的要求或初始化步骤？ 4. 双应用图像 如果应用 A 和应用 B 位于不同的闪存地址： 每个应用程序都应该有自己的链接脚本吗？ 或者，NXP 是否有推荐的构建双槽应用的方法？ 5. 闪存库的使用 由于 S32K342 有两个 1 MB 的 PFlash 存储区： 推荐的方法是否是： 从 Bank 0 执行引导加载程序 将新固件编程到 Bank 1 中。 验证成功后切换执行 两个 PFlash 存储体之间是否存在读写限制或擦除/编程限制？ 6. 元数据存储 理想的存储地点在哪里？ 活动图像标志 图像有效性 Firmware version CRC 回滚状态 这些物品应该存放在： 保留 PFlash DFlash 另一个专用的区域？ 7. 基于UART的FOTA 由于我们的更新接口是 UART，我们想知道推荐的工作流程。 以下流程是否正确？ 个人电脑 │ UART │ 引导加载程序接收 .bin 文件 │ 将固件存储到非活动闪存插槽中 │ 验证CRC │ 更新启动元数据 │ RESET MCU │ 引导加载程序选择新映像 │ 跳转至应用程序 或者恩智浦是否推荐其他方法？ 8. AB_SWAP 与自定义引导加载程序 对于 S32K342 的生产 FOTA 而言，HSE AB_SWAP 是否是强制性的？ 或者，具有双应用程序插槽的完全自定义引导加载程序也是一种受支持且常用的架构吗？ 如果您有任何专门介绍 S32K342 FOTA、UART 固件更新或双映像引导加载程序的应用笔记、参考项目、引导加载程序示例或文档，我们将非常感谢您提供这些参考资料。 感谢您的支持。 S32K3 S32DS-ARM Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) 你好@bavinkumar_02 1.对于 S32K342，AB_SWAP 只有一种可能的设置。参见“3.5.3.2HSE固件参考手册中提供了“AB_SWAP”模式下闪存布局的图示，该手册可从“文档”->“安全文件”下载： https://www.nxp.com/products/S32K3 就您的情况而言，最方便、最常见的布局是： 必须安装 AB_SWAP 版本的 HSE 固件（交换是 HSE 的一项功能，没有 HSE 固件就无法执行此操作）。固件已安装到两个分区，并且如图所示，它占用了两个分区中最后的 176KB。 因为整个数据块都被交换了，所以两个数据块中必须有完全相同的引导加载程序副本。其余部分分配给申请。 代码始终从活动块运行，因此引导加载程序和所有应用程序都是针对活动块中的地址编译的。 当引导加载程序更新应用程序时，它会将应用程序编程为被动阻塞，因此在闪存编程期间不会出现边读边写的问题。应用程序编程完成后，即可触发 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE 服务。下次RESET后，分区将被交换，引导加载程序将像往常一样跳转到应用程序（跳转到当前活动块中的新应用程序）。 2. 流程取决于应用程序。在现代汽车应用中，简单的基于 CRC 的验证已不再被认为足够。软件的完整性和真实性通常通过安全启动机制来保证。在 S32K3 设备上，这是由硬件网络安全引擎 (HSE) 处理的，它会执行加密验证（例如）。基于签名）在启动过程中自主进行。预计量产汽车系统将利用这些硬件支持的网络安全功能，而不是仅仅依赖 CRC 验证。 我们提供安全启动应用笔记，其中包括演示项目。可从以下网址下载： https://www.nxp.com/products/S32K3 应用笔记请点击此处查看： 文档 -> 安全文件 -> 安全启动应用笔记 v0.1.1.0（AN744511） 相关演示项目可在此处下载： 设计资源 -> 软件 -> 安全文件 -> SecureBootAppNoteDemo (SW745310) 您可以在 HSE 演示示例中找到其他安全启动示例： https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 三种模式——高级安全启动、基本安全启动和 SHE 安全启动——都有相应的示例。建议启用高级安全启动。 请参阅所有项目中包含的 Readme.md 文件。 3. 是的，这是标准的跳转序列。强烈建议在跳转之前取消初始化引导加载程序初始化的所有资源。 4. 如上所述，代码始终从活动分区执行，因此应用程序始终使用相同的链接器文件。 5. 前面已经讨论过了。 6.这取决于用户。您可以将数据存储在应用程序映像后面，或者存储在数据闪存中。 7. 对于生产汽车用例而言，从数据传输的角度来看，所提出的流程总体上是正确的，但正如前面提到的，我不建议依赖 CRC 作为主要的验证机制。 在汽车应用中，接收到的图像通常会受到加密保护——例如，图像可能会被加密，并且其真实性/完整性会通过数字签名（而不仅仅是 CRC）来验证。 此外，在使用 HSE AB_SWAP 机制时，引导加载程序在 RESET 后不会简单地通过软件元数据选择新映像。新映像被编程到被动分区并成功验证后，应用程序/引导加载程序应调用 HSE 服务 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK。这将激活被动块，因此RESET后设备将从新激活的分区启动。 8. HSE AB_SWAP 并非严格强制要求，但对于 S32K342 上的量产汽车 FOTA 解决方案，强烈建议使用。 如果没有 HSE 就实施 FOTA，那就意味着您没有利用 S32K3 平台的一个关键优势。这些设备的主要优点是内置支持 HSE 处理的 A/B 交换（分区重映射）。如果没有它，引导加载程序就必须手动管理一切。 具体而言，不包括 HSE AB_SWAP： 你需要自己实现一种机制来选择 A/B 图像。 您需要仔细管理地址空间，并将每个应用程序链接到不同的固定位置。 图像之间的切换不会由硬件自动处理，而完全由您的软件处理。 除了 HSE AB 交换功能之外，没有其他硬件支持的重映射机制可用。 此外，您还将失去与 AB_SWAP 集成的安全启动的简洁性和稳健性。借助 HSE，图像激活、验证和分区之间的切换以更加可控和高效的方式进行处理，符合汽车网络安全要求。 总之，虽然不考虑 HSE 也能做到这一点，但这会大大增加复杂性，并消除该平台的关键优势。 您可以查看“S32K3XX HSE 和 OTA 高级培训 [TR744101]”，该培训文档可从以下链接下载：文档 -> 安全文件： https://www.nxp.com/products/S32K3 问候， 卢卡斯

ウィンボンドW664GG6RB-06用IMX-8M-MINI DDRコントローラのタイミング こんにちは、 DDR4タイミングセットが正常に動作しない理由について説明を求めています。簡単に言えば、 DDRツールによって生成されたタイミングは校正および応力試験に合格しましたが、 断続的なLinuxカーネルは起動時にクラッシュし、「未定義命令」エラーが発生します。 設定(生の事実): - SoCはi.MX8M Mini Solo(シングルCortex-A53)、DDR4(Winbond W664GG6RB-06)です。 1200 MHz(DDR4-2400)は1:2 DFI(DDR PHYインターフェース)周波数比モードで、 単一のx16 4 Gbデバイス(512MB、ECCなし)。 - BSPはNXP L4.14.98_2.0.0(Linux 4.14.98、U-Boot 2018.03);DDRの設定は Mscale DDR Tool v3.31(Windows版)とPHYトレーニングファームウェアで生成 v201709。同じファームウェアがYoctoでU-Bootイメージの構築に使われています。 - 3つの交換可能な4Gb x16 DDR4メモリに対して、共通のタイミングセットを1つ認定しています。 部品（Alliance AS4C256M16D4、ISSI IS43QR16256B、Winbond W664GG6RB-06）はすべて動作しています 1200MHzで。 - 最も遅い部分 (Winbond) の tRCD/tRP/tAA (2400 bin で約 14.16 ns) を満たすために、 CL=17 (17-17-17) を設定すると、ツールはそれを MR0 = 0x0864 とエンコードし、対応する CL由来レジスタ（例：DFITMG0 = 0x038C8207、DRAMTMG2 = 0x0609050D)。 - DRAMは2400設定値で静的動作(デバイス内でDVFS/バス周波数が無効化) そのため、Linuxによる実行時の周波数スケーリングはありません。 観察結果： - 17-17-17構成は、DDRツールのストレステスト（約24時間）とU-Bootのmtest（約1時間）に合格します。 エラーなし。 - Linux上(シェルプロンプトに到達した起動時)ではstressapptest +にも合格します fio(CRC32C認証済み)は、Tj = 84°Cの温度で1時間以上連続かつ一定温度で、 データエラーはゼロです。 - それにもかかわらず、Linuxは起動時に「内部エラー: 未定義命令」(破損したカーネルの.text)、カーネル開始から約1.1秒後、 コールドブートの5～7％（自動コールド電源サイクルループで測定）。 - 故障はダイに依存しない:CL=17の画像も1秒間で同じ方法でクラッシュします これらの部分(ISSI)を使い、CL=16イメージは同じISSI上でLinuxを安定して起動します パート。 - 両方のeven-CL構成がLinuxを安定して起動します:16-16-16(当社の長年にわたる本番環境) タイミング)および新たに構築された18-18-18(カーネルクラッシュは見られません)—ただし、奇数CLのみです。 17-17-17は失敗。 - CL由来のレジスタのみが失敗設定と動作設定(MR0)で異なります CASビット、DFITMG0 dfi_t_rddata_en、DRAMTMG2リードレイテンシ/rd2wr、DFITMG2 rdcslat、 ODTCFG rd_odt_delay)。 仮説: 1:2のDFI比率での奇数CASレイテンシが根本原因、すなわち読み取りデータ(リードデータ)にあると推測しています 返還レイテンシはDFIクロックでCL/2であり、CL=17の場合は整数8.5、整数8.0は非整数です / 9.0 で CL=16 / 18。読み取りFIFO(DQSが書き、コントローラが読み取り)以降 クロック(リファレンス・マニュアル§9.3.2.2.2)は定常状態と定常応力を扱います 通過し、エッジ性は読み取りバースト間遷移で表面が現れると推測します。ここで 奇数CLの半DFIクロックオフセットは、RMが直面しない初拍・最後のビートのエッジCASEに当てはまります 記録を残す。 質問: CASレイテンシは奇数です(例:CL=17) は、1:2 DFI の i.MX8M Mini DDR4 PHY でサポートされています。 モード、または奇数CLに関する既知の制約/エラーはありますか？特にDDRは ツールは独自のストレステストを通過するが限界的な奇数CL構成を生成する 実際のブートトラフィックの下で、読書を制限する推奨方法はありますか? 奇数のCLのバースト・トゥ・バーストタイミングは? 添付ファイル：カーネルクラッシュコンソールダンプ、CL=17 .dsDDRツールのスクリプト、および ddr4_timing.c が生成されました。 どんなアドバイスでもありがたいです。 Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 申し訳ありませんが、何らかの理由で添付ファイルが添付されませんでした。それらは以下の通りです。 Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 以下の部品のタイミングパラメータで、CASレイテンシのtRCD(ns)tRP(ns)を確認してください。 Alliance AS4C256M16D4 DDR4-2400 17 14.1614.16 ISSI IS43QR16256B 2400Mbps 16-16-16 (-083R) ウィンボンド W664GG6RB-06 DDR4-2400 17-17-17 IS43QR16256Bの3番目のパラメータは異なります。そのため、3つのパーツごとに専用の設定が必要になるかもしれませんが、3つのパーツすべてに1つの設定を使うのではなく。問題は起動時のみ発生するようですね？ Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 こんにちは、 CL=17からCL=18に修正して再試し、DDRテストを実行し、Linuxを再度テストしてください。新しいバージョンへのアップグレードをおすすめします。

MCXA153：LPSPI 数据突发传输。 你好， 参考手册 MCXA153 包含了对 TDBRn 和 RDBRn LPSPI 寄存器的描述： “TDBRn 和 RDBRn 寄存器支持向发送 FIFO 发送数据进行突发传输，以便与 DMA 控制器一起使用”。 请问有人可以分享一下使用这些寄存器进行突发传输的示例代码吗？ 此致 博格丹 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCXA Re: MCXA153: LPSPI data burst transfer. 嗨@bogdan_u 抱歉，目前没有相关示例。 我找到的最接近的 MCXA153 示例使用 LPSPI_MasterTransferEDMALite() 和 eDMA，但驱动程序通过 LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() 来定位 TDR/RDR，而不是突发别名窗口。 但我认为你可以尝试使用。 typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR 哈里

S32K358 + FS2633:MCUを組み立てた状態でRSTBは低(LOW)のままですが、JTAGがコネクテッド時は高くなります 私はFS2633とS32K358を使用しています。FS2633セクション(MCUを取り外した部分)だけをテストすると、RSTBが解放され(HIGH)、3.3Vレールが存在します。 MCUとすべてのコンポーネントを組み立てた後、 RSTBはLOWのままで、MCUは起動しません。 JTAGデバッガを接続するとRSTBが高負荷になり、MCUを正常にプログラムでき、アプリケーションは通常通り動作します。しかし、JTAGを切断すると RSTBが再び低くなり 、MCUが停止します。 一つ気づいた点として、FS2633のRSTB出力は3.3Vの信号であるのに対し、私の基板ではS32K358のRESETラインは5Vにプルアップされている。この電圧差にもかかわらず、JTAGデバッガが接続されている間は正しく動作します。このリセット電圧レベルやデバッガーがリセットや電源オンの流れに影響を与えている可能性はありますか? この問題は、電源オンシーケンス、リセットタイミング、FS2633の起動設定、あるいはデバッガ関連の挙動に関連している可能性はありますか?同様の問題を経験された方、またはデバッグに関するご提案をお持ちの方はいらっしゃいますか？ Re: S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected FS2633 RSTBを3.3Vにプルアップしてテストしてみて、この問題が解決するかどうか確認した方が良いでしょう。

Regarding the CAN issue of s32k344 The compiler I am currently using is s32ds3.4, RTD2.0.0. Among them, CAN FD function is enabled for can0-can5, and ENABLE RX FIFO function is enabled for can0. The implemented function is that can1 sends 64bit data to can0, can4 sends 64bit data to can2, and can3 sends 64bit data to can5. However, why can can0 and can5 receive data normally but can2 cannot receive data? When I set can4 to Loop-back mode, can4 can also receive data normally. The hardware connection is achieved by connecting CANH of can1 to CANH of can0, CANL of can1 to CANL of can0, CANH of can4 to CANH of can2, CANL of can4 to CANL of can2, CANH of can5 to CANH of can3, and CANL of can5 to CANL of can3 using DuPont wires. Here is my code 回复： Regarding the CAN issue of s32k344 I found a problem. The pin configuration is incorrect

MCXA265VPNレイアウト案 NXPチーム、 MCXA265VPNのファンアウトの例はありますか？パッドと穴のサイズに関する推奨事項が必要です。ビアはパッド内ですか、それともピン間ですか? BGAでしっかりしたGND機が必要ですか? 助けてください。 ダン・ロジャースさん、ありがとう。 ボード設計 Re: MCXA265VPN Layout Suggestion チーム、 配線例が記載されたデモボードはありますか？知りたいこと： BGAピン間の配線に使われるトレース幅やサイズはどのくらいですか? 使用されているタイプとパッドサイズ、穴のサイズによって決まりますか？ スルーホール、BBVIA、スタック？ 配線後のピン間の間隔は？ 説明 = MCXA265VPN、NXP Semiconductors MXCA_169_BGA169（パッド幅10ミル、ピン間隔19.7ミル） どうもありがとうございます。皆さんのサポートに感謝します。 ダン・ロジャース

MCXA153：LPSPIデータバースト転送。 こんにちは、 リファレンス・マニュアルMCXA153 TDBRnおよびRDBRn LPSPIレジスタの説明が含まれています。 「TDBRnおよびRDBRnレジスタは、DMAコントローラで使用するための送信FIFOへのバースト転送をサポートします」。 これらのレジスタを使ったバースト転送のサンプルコードを誰か共有してもらえますか? よろしくお願いします ボグダン 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) MCXA Re: MCXA153: LPSPI data burst transfer. こんにちは、 @bogdan_u 申し訳ありませんが、現在、関連する事例はございません。 私が見つけた最も近い例はMCXA153 LPSPI_MasterTransferEDMALite()とeDMAを使っていますが、ドライバーはTDR/RDRをLPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress()経由でターゲットにしており、バーストエイリアスウィンドウではありません。 でも、試してみることはできると思います。 typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR ハリー

关于 s32k344 的 CAN 问题 我目前使用的编译器是s32ds3.4，RTD2.0.0。其中，CAN FD 功能对 can0-can5 启用，ENABLE RX FIFO 功能对 can0 启用。实现的功能是：can1 向 can0 发送 64 位数据，can4 向 can2 发送 64 位数据，can3 向 can5 发送 64 位数据。但是，为什么 can0 和 can5 可以正常接收数据，而 can2 却无法接收数据？当我将 can4 设置为环回模式时，can4 也能正常接收数据。硬件连接是通过使用杜邦线将 can1 的 CANH 连接到 can0 的 CANH，将 can1 的 CANL 连接到 can0 的 CANL，将 can4 的 CANH 连接到 can2 的 CANH，将 can4 的 CANL 连接到 can2 的 CANL，将 can5 的 CANH 连接到 can3 的 CANH，以及将 can5 的 CANL 连接到 can3 的 CANL 来实现的。这是我的代码 回复： Regarding the CAN issue of s32k344 我发现了一个问题。引脚配置错误

MCXA265VPN布局建议 NXP团队 您有MCXA265VPN扇出示例吗？需要根据垫片和孔径尺寸进行推荐。过孔是在焊盘内还是引脚之间？BGA下方是否需要完整的接地层？ 请帮忙。 谢谢丹·罗杰斯 电路板设计 Re: MCXA265VPN Layout Suggestion 团队， 你们有带有建议布线方案的演示板吗？我需要知道： 用于在BGA引脚之间布线的走线宽度尺寸是多少？ 使用的过孔类型、焊盘尺寸以及孔径大小？ 通孔，bbvia，堆叠？ 布线后引脚之间的间距是多少？ 描述 = MCXA265VPN，恩智浦半导体 MXCA_169_BGA169（10 mil 焊盘，引脚间距 19.7 mil） 非常感谢。感谢您的支持。 丹·罗杰斯

MCXA265VPN Layout Suggestion NXP Team, Do you have a MCXA265VPN fanout example?  Need recommended via pad and hole size.  Are the vias in pads or between pins?  Need to have a solid GND plane under BGA? Please help. Thanks Dan Rogers Board Design Re: MCXA265VPN Layout Suggestion Team, Do you have a demo board with suggested routing? I need to know: Trace widths sizes used to route between BGA pins? Via types used and pad sizes with hole size? thru hole, bbvia, stacked? Spacings used between pins after routing? DESCRIPTION = MCXA265VPN, NXP SEMICONDUCTORS MXCA_169_BGA169 (10 mil pads with 19.7 mil pitch between pins) Thank you very much. for your support. Dan Rogers

S32k344のCAN問題について 現在使用しているコンパイラはs32ds3.4です。RTD2.0.0その中で、can0-can5ではCAN FD機能が有効、can0ではENABLE RX FIFO機能が有効です。実装された機能は、can1がcan0に64ビットのデータを送信し、can4がcan2に64ビットのデータを送信し、can3がcan5に64ビットのデータを送信するというものです。しかし、なぜcan0とcan5は通常データを受け取れるのにcan2はデータを受け取れないのでしょうか?can4をループバックモードに設定すると、can4は通常通りデータを受け取ることができます。ハードウェア接続は、デュポンワイヤを使用して、can1のCANHとcan0のCANH、can1のCANLとcan0のCANL、can4のCANHとcan2のCANH、can4のCANLとcan2のCANL、can5のCANHとcan3のCANH、can5のCANLとcan3のCANLを接続することによって実現されます。これが私のコードです 回复： Regarding the CAN issue of s32k344 問題点を見つけました。ピン配置が間違っています

S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) Hello NXP Team, We are developing a custom Firmware Over-The-Air (FOTA) solution for the S32K342 and would like guidance on the recommended flash architecture and boot flow. MCU Details Device: S32K342 PFlash: 2 MB Bank 0: 1 MB Bank 1: 1 MB DFlash: 128 KB Current Status We are using UART as the firmware update interface. So far, we have successfully: Receive the firmware (.bin) over UART Store the complete binary into flash memory Verify that the received image is stored correctly Our remaining challenge is implementing the bootloader architecture and application switching mechanism. We would like clarification on the following: 1. Recommended FOTA Flash Layout What is the recommended memory layout for an S32K342 dual-image FOTA implementation? Specifically, we would like to know the recommended locations for: Bootloader Application Slot A Application Slot B Metadata / Boot flags Version information CRC Rollback information An example memory map with addresses would be extremely helpful. 2. Recommended Boot Flow Could someone explain the complete boot sequence recommended by NXP? For example: Reset Bootloader starts Check boot flags Select active application Validate image (CRC/signature) Jump to application We would appreciate a flow diagram or explanation of the complete process. 3. Bootloader to Application Jump For S32K342, is the standard Cortex-M7 jump sequence sufficient? For example: Read MSP from application base address Read Reset_Handler from base + 4 Set MSP Update VTOR Jump to Reset_Handler Are there any S32K342-specific requirements or initialization steps before transferring control? 4. Dual Application Images If App A and App B are located at different flash addresses: Should each application have its own linker script? Or is there a recommended NXP approach for building dual-slot applications? 5. Flash Bank Usage Since S32K342 has two 1 MB PFlash banks: Is the recommended approach to: Execute the bootloader from Bank 0 Program the new firmware into Bank 1 Switch execution after successful verification Are there any Read-While-Write or erase/programming restrictions between the two PFlash banks? 6. Metadata Storage Where is the preferred location to store: Active image flag Image validity Firmware version CRC Rollback status Should these be stored in: Reserved PFlash DFlash Another dedicated region? 7. UART-Based FOTA Since our update interface is UART, we would like to know the recommended workflow. Is the following flow correct? PC │ UART │ Bootloader receives .bin │ Store firmware into inactive flash slot │ Verify CRC │ Update boot metadata │ Reset MCU │ Bootloader selects new image │ Jump to application Or does NXP recommend a different approach? 8. AB_SWAP vs Custom Bootloader Is HSE AB_SWAP mandatory for production FOTA on S32K342? Or is a fully custom bootloader with dual application slots also a supported and commonly used architecture? If there are any application notes, reference projects, bootloader examples, or documentation specifically covering S32K342 FOTA, UART firmware updates, or dual-image bootloaders, we would greatly appreciate the references. Thank you for your support. S32K3 S32DS-ARM  Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) Hi @bavinkumar_02  1. In case of S32K342, there’s only one possible setup for AB_SWAP. See “3.5.3.2 Illustrations of Flash memory layout in AB_SWAP” in HSE Firmware reference manual which can be downloaded from Documentation -> Secure files: https://www.nxp.com/products/S32K3 In your case, the most convenient and most common layout is: It’s necessary to install AB_SWAP version of HSE firmware (the swap is a feature of HSE, it’s not possible to do that without HSE firmware). The firmware is installed to both partitions and it occupies last 176KB in both blocks as shown on the picture. Because whole blocks are swapped, it’s necessary to have exact copy of the bootloader in both blocks. The rest is allocated for applications. The code is always running from active block, so the bootloader and all applications are compiled for addresses in active block. When bootloader updates an application, it programs the application to passive block, so there’s no problem with read-while-write issues during flash programming. Once the application is programmed, you can trigger HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE service. After next reset, the partitions will be swapped and bootloader will jump to application as usual (to new application which is in active block now). 2. The flow is application dependent. In modern automotive applications, simple CRC-based validation is no longer considered sufficient. Integrity and authenticity of the software are typically ensured using Secure Boot mechanisms. On S32K3 devices, this is handled by the Hardware Security Engine (HSE), which performs cryptographic verification (e.g. signature-based) autonomously during boot. Production automotive systems are expected to leverage these hardware-backed security features rather than relying on CRC-only validation. We provide Secure Boot application note including demo projects. It can be downloaded from: https://www.nxp.com/products/S32K3 Application note can be found here: Documentation -> Secure Files -> Secure Boot Application note v0.1.1.0 (AN744511) Associated demo project can be downloaded here: Design Resources -> Software -> Secure Files -> SecureBootAppNoteDemo (SW745310) Other examples for secure boot can be found in HSE Demo Examples: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples There are examples for all three modes – advanced secure boot, basic secure boot and SHE secure boot. Advanced secure boot is recommended. See Readme.md file which is included in all projects. 3. Yes, that’s standard jump sequence. It’s just highly recommended to de-initialize all resources initialized by bootloader before the jump. 4. As mentioned above, the code is always executed from active partition, so the application always uses the same linker file. 5. Already discussed above. 6. This is up to user. You can store the data behind the application image or to data flash. 7. For a production automotive use case, the proposed flow is generally correct from the data-transfer point of view, but as already mentioned, I would not recommend relying on CRC as the main validation mechanism. In automotive applications, the received image is typically protected cryptographically - for example, the image may be encrypted and its authenticity/integrity is verified using a digital signature, not only by CRC. Also, when using the HSE AB_SWAP mechanism, the bootloader does not simply select the new image by software metadata after reset. After the new image is programmed into the passive partition and successfully verified, the application/bootloader should call the HSE service HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK. This activates the passive block, so after reset the device boots from the newly activated partition. 8. HSE AB_SWAP is not strictly mandatory, but for a production automotive FOTA solution on S32K342 it is strongly recommended. Implementing FOTA without HSE would mean you are not leveraging one of the key advantages of the S32K3 platform. The main benefit of these devices is the built-in support for A/B swap (partition remapping) handled by HSE. Without it, the bootloader would have to manage everything manually. Specifically, without HSE AB_SWAP: You would need to implement your own mechanism for selecting between A/B images You would have to carefully manage the address space and link each application to different fixed locations The swap between images would not be handled autonomously by the hardware, but entirely in your software There is no alternative hardware-supported remapping mechanism available outside of HSE AB swap feature In addition, you would lose the simplicity and robustness of Secure Boot integrated with AB_SWAP. With HSE, image activation, validation, and switching between partitions are handled in a much more controlled and efficient way, aligned with automotive security requirements. In summary, doing this without HSE is possible, but it significantly increases complexity and removes key benefits of the platform. You can take a look at “S32K3XX HSE and OTA Advance Training [TR744101]” which can be downloaded Documentation -> Secure files: https://www.nxp.com/products/S32K3 Regards, Lukas

Additional materials related to DRM099 application note Dear all, I'm an Electrical Engineering student and I'm using the document "Sensorless PMSM Vector Control with a Sliding Mode Observer for Compressors Using MC56F8013" (document number DRM099) to learn about the sliding mode observer for permanent magnet synchronous machines. So far this document has been very useful, and I'm really thankful that NXP made it available! In the document the authors mention some functions such as "PMSM_SL_DQSMOBemfSpedObservSclUniv32()", "EstimProcessing()", which would be very useful for me to look their code. In this way, I hope to better understand the concepts explained in DRM099, and hopefully tackle the challenge of implementing and tuning the SMO in the dq frame. Therefore, if it is not asking too much, I was wondering if I could have access to these additional files and materials, if possible. Anything you can share will be immensely appreciated and helpful. Thank you in advance for your time and consideration! I wish you a great day. Best regards, Rafael Re: Additional materials related to DRM099 application note Hello @Rafael1 , Thanks for your post. I think the information below is what you are looking for： RDDSCPMSMVCSMO: Sensorless PMSM Vector Control for Compressors Reference Design Using MC56F8013 https://www.nxp.com/search?keyword=pmsm_sensorlesscl&start=0  Download link: https://www.nxp.com/webapp/Download?colCode=PMSM_SENSORLESSCL_DQHREL&appType=license&location=null Hope it helps. BR Celeste Re: Additional materials related to DRM099 application note Thank you so much, @Celeste_Liu  After downloading and executing the .exe file, I was able to get the C code for the motor control with sliding mode observer. That was exactly what I was looking for. Thank you for your time and consideration! Have a nice day! Re: Additional materials related to DRM099 application note Glad to help! Any new questions, welcome to create a new post.

MPC5748G: MachineCheck exception hen trying to access peripherals in user mode Hello, I ported OpenPicoRTOS to PowerPC platforms & ran into an issue. Despite configuring the PBRIDGE (correctly ?) i get a MachineCheck exception every time i try to access a peripheral in user mode. Supervisor mode works fine but it's not really what i'm after, i want user/supervisor mode management (+MPU) & being able to access peripherals in user mode. I tried various things but nothing seems to work, i don't know if i'm doing something wrong of it it's simply not possible. Right now i just kept everything in supervisor mode for demonstration purposes, here's the current state of the code:  - My attempt at configuring the PBRIDGE: https://github.com/jnaulet/OpenPicoRTOS/blob/v1.11.x/arch/powerpc/e200z4/mach-mpc574x/startup.S  - The de-activated user mode (in arch_save_first_context): https://github.com/jnaulet/OpenPicoRTOS/blob/v1.11.x/arch/powerpc/e200z4/picoRTOS_portasm.S  - The complete demo i use for debugging this system: https://github.com/jnaulet/OpenPicoRTOS/tree/v1.11.x/demo/devkit-mpc5748g Any help is appreciated. Kind regards. Re: MPC5748G: MachineCheck exception hen trying to access peripherals in user mode Hello, there can be multiple reasons for user mode access rejection: Most probably PBRIDGE or MPU configuration. You can start checking following: PBRIDGE PACR/OPACR initialization. Whether all peripheral slots are configured for user access. MPU region definitions covering: 0xFxxxxxxx peripheral space read/write permissions supervisor/user attributes. MSR value after the RTOS drops to user mode. The exact peripheral address that causes the fault. MCSR/ESR/DEAR at IVOR1 entry. Best Regards, Peter

MCXA153: LPSPI data burst transfer. Hello, The Reference Manual MCXA153 contains a description of the TDBRn and RDBRn LPSPI registers: "TDBRn and RDBRn registers supports burst transfers of data to the transmit FIFO for use with the DMA controller". Can anyone share sample code for a burst transfer using these registers? best regards Bogdan Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXA Re: MCXA153: LPSPI data burst transfer. Hi @bogdan_u  Sorry, there are currently no relevant examples available. The closest MCXA153 example I found uses LPSPI_MasterTransferEDMALite() with eDMA, but the driver targets TDR/RDR via LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() , not the burst alias window. But i think you can try to use. typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR Harry

DRM099 应用笔记的相关补充材料 尊敬的各位， 我是一名电气工程专业的学生，我正在使用文档“基于MC56F8013的压缩机的无传感器PMSM矢量控制与滑模观测器”（文档编号DRM099）来学习永磁同步电机的滑模观测器。到目前为止，这份文件非常有用，我非常感谢恩智浦将其提供出来！ 文档中作者提到了一些函数，例如“PMSM_SL_DQSMOBemfSpedObservSclUniv32()”、“EstimProcessing()”，查看他们的代码对我来说非常有用。通过这种方式，我希望能够更好地理解 DRM099 中解释的概念，并希望能够解决在 dq 帧中实现和调整 SMO 的挑战。因此，如果要求不太过分的话，我想知道我是否可以查阅这些额外的文件和资料。您的任何分享都将不胜感激，并对我们大有帮助。 感谢您抽出宝贵时间并考虑我的请求！祝你今天过得愉快。 顺祝商祺！ 拉斐尔 Re: Additional materials related to DRM099 application note 你好@Rafael1 ， 感谢您的帖子。我认为以下信息正是您要找的： RDDSCPMSMVCSMO：基于MC56F8013的无传感器永磁同步电机压缩机矢量控制参考设计 https://www.nxp.com/search?keyword=pmsm_sensorlesscl&start=0 下载链接： https://www.nxp.com/webapp/Download?colCode=PMSM_SENSORLESSCL_DQHREL &appType=license&location=null 希望对您有所帮助。 BR 塞莱斯特 Re: Additional materials related to DRM099 application note 非常感谢你， @Celeste_Liu 下载并运行 .exe 文件后从文件中，我得到了带有滑模观察器的电机控制的 C 代码。这正是我想要的。 感谢您抽出宝贵时间并考虑我的请求！祝你今天过得愉快！ Re: Additional materials related to DRM099 application note 乐意效劳！如有任何新问题，欢迎发帖提问。

MPC5748G：尝试在用户模式下访问外围设备时发生 MachineCheck 异常 你好， 我将 OpenPicoRTOS 移植到 PowerPC 平台时遇到了问题。 尽管我已正确配置了 PBRIDGE，但每次尝试在用户模式下访问外围设备时，都会出现 MachineCheck 异常。 管理员模式运行良好，但这并不是我想要的，我想要用户/管理员模式管理（+MPU）并且能够在用户模式下访问外围设备。 我尝试了各种方法，但似乎都行不通，我不知道是我做错了什么，还是根本就做不到。 目前为了演示目的，我将所有程序都保持在管理模式下，以下是当前代码状态： - 我尝试配置 PBRIDGE： https://github.com/jnaulet/OpenPicoRTOS/blob/v1.11.x/arch/powerpc/e200z4/mach-mpc574x/startup.S - 已停用的用户模式（在 arch_save_first_context 中）： https://github.com/jnaulet/OpenPicoRTOS/blob/v1.11.x/arch/powerpc/e200z4/picoRTOS_portasm.S - 我用于调试此系统的完整演示： https://github.com/jnaulet/OpenPicoRTOS/tree/v1.11.x/demo/devkit-mpc5748g 非常感谢您的帮助。 亲切的问候。 Re: MPC5748G: MachineCheck exception hen trying to access peripherals in user mode 你好， 用户模式访问被拒绝的原因可能有多种： 很可能是 PBRIDGE 或 MPU 配置。 您可以开始检查以下内容： PBRIDGE PACR/OPACR 初始化。 所有外围设备插槽是否都已配置为供用户访问。 MPU区域定义涵盖： 0xFxxxxxxx 外围空间 读/写权限 管理员/用户属性。 RTOS 降至用户模式后的 MSR 值。 导致故障的确切外围设备地址。 MCSR/ESR/DEAR 在 IVOR1 入口处。 顺祝商祺！ Peter

S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected I am using S32K358 with FS2633. When I test only the FS2633 section (MCU removed), the RSTB is released (HIGH) and the 3.3 V rail is present. After assembling the MCU and all components, RSTB stays LOW, and the MCU does not boot. If I connect a JTAG debugger, RSTB goes HIGH, I can successfully program the MCU, and the application runs normally. However, once I disconnect the JTAG, RSTB goes LOW again and the MCU stops running. One observation is that the FS2633 RSTB output is a 3.3 V signal, while the S32K358 RESET line is pulled up to 5 V on my board. Despite this voltage difference, the system works correctly whenever the JTAG debugger is connected. Could this reset voltage level or the debugger be influencing the reset or power-up sequence? Could this issue be related to the power-up sequence, reset timing, FS2633 startup configuration, or debugger-related behavior? Has anyone experienced a similar issue or have suggestions for debugging? Re: S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected You'd better try to test by pulling up the FS2633 RSTB to 3.3 V and check whether this issue has or not.

DRM099アプリケーションノートに関連する追加資料 皆様、 私は電気工学を専攻する学生で、永久磁石同期機のスライディングモードオブザーバについて学ぶために、「MC56F8013を使用したコンプレッサ用センサレスPMSMベクトル制御（スライディングモードオブザーバ付き）」（文書番号DRM099）という文書を使用しています。これまでのところ、このドキュメントは非常に役立っており、NXPが提供してくれたことに本当に感謝しています! 文書の中で著者らは「PMSM_SL_DQSMOBemfSpedObservSclUniv32()」、「EstimProcessing()」といった関数について言及しており、それらのコードを確認することは私にとって非常に役立つだろう。このようにして、DRM099で説明されている概念をより深く理解し、dqフレームにおけるSMOの実装と調整という課題に取り組めることを期待しています。ですので、もし無理がなければ、これらの追加ファイルや資料にアクセスできないかと思いまして。どんなことでも共有していただけると大変ありがたいし、役に立ちます。 お時間を割いてご検討いただき、誠にありがとうございます！素敵な一日をお過ごしください。 よろしくお願いいたします。 ラファエル Re: Additional materials related to DRM099 application note こんにちは、 @Rafael1 さん。 投稿ありがとうございます。以下の情報が、あなたが探しているものだと思います。 RDDSCPMSMVCSMO:コンプレッサー向けセンサーレスPMSMベクトル制御リファレンスデザイン MC56F8013 https://www.nxp.com/search?keyword=pmsm_sensorlesscl&start=0 ダウンロードリンク： https://www.nxp.com/webapp/Download?colCode =PMSM_SENSORLESSCL_DQHREL&appType=license&location=null お役に立てば幸いです。 BR セレステ Re: Additional materials related to DRM099 application note 本当にありがとうございます、 @Celeste_Liu  .exeファイルをダウンロードして実行した後スライドモードのオブザーバーでモーター制御のCコードを入手できました。まさに私が探していたものだった。 お時間を割いていただき、ご検討いただきありがとうございます！良い１日を！ Re: Additional materials related to DRM099 application note お役に立てて嬉しいです！他に質問があれば、新しい投稿を作成してください。