Battery Management System - Overview 1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion 2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.   SorinIBancila_1-1784019970441.png 3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller. SorinIBancila_3-1784020100200.png The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior. 4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads 5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator SorinIBancila_2-1784020020513.png 6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT) 7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.

IMX8MPセカンダリイメージブート IMG_CNTN_SET1_OFFSETセカンダリイメージブート（RM 6.1.6.2）は、i.MX8MP上のECSPI（"SPI") NORブートで動作しますか、それともFlexSPI NOR（およびSD/eMMC）のみで動作しますか？表6-28では、「SPI」と「FlexSPI NOR」が別々のブートデバイスとして記載されており、セカンダリオフセットの有効値は「FlexSPI NORブートの場合」にのみ記載されています。 Re: IMX8MP secondary image boot こんにちは、 あなたの理解は間違っています。IMG_CNTN_SET1_OFFSETセカンダリイメージブートはSPIデバイスでも動作しますが、オフセットが異なります。 FlexSPI の有効な値は、0、1、2、3、4、5、6、および 7 です。 SPI の場合、ヒューズ値が 10 より大きい場合、セカンダリ ブートは無効になります。n = ヒューズ値が より大きい場合 10. • n == 0: オフセット = 4MB • n == 2: オフセット = 1MB • その他 & n <= 10 : オフセット = 1MB*2^n Oswalag_0-1782750547759.png Re: IMX8MP secondary image boot ありがとうございます。これでオフセットマッピングの問題が解決しました。i.MX8MPボード上で再現するために2つのフォローアップです(ECSPI2でNOR起動、OPEN/非HAB設定、ヒューズ読み取り2 1 = 0 → n=0 → 4MB): ROMがSPI NORのセカンダリイメージに切り替わるトリガーは何ですか?これは無効なプライマリブートヘッダーやイメージ解析失敗、それとも特定のHAB認証失敗なのでしょうか?つまり、セカンダリイメージブートはオープン（非セキュア）構成でも機能するのか、それともデバイスがHABで閉じられている場合にのみ機能するのか？ 同じリセット手順にフォールバックするのか、それとも電源のオンオフ／2回目のリセット（永続起動方式）が必要になるのか？ 4MBオフセットにあるセカンダリイメージは、別途構築されたブート可能なイメージ（そのオフセット用の独自のIVT/ブートデータ）である必要がありますか、それともプライマリイメージとバイト単位で同一のコピーで十分ですか？ Re: IMX8MP secondary image boot i.MX8MPがOPEN（SEC_CONFIG=open、非HAB）構成でECSPI（SPI）NORからブートする場合、IMG_CNTN_SET1_OFFSETセカンダリイメージブートの正確なトリガー条件は何ですか？ROMは無効または消去されたプライマリコンテナヘッダーのセカンダリイメージに切り替わるのか、それともHAB認証失敗時のみ(すなわち（閉鎖/セキュリティ保護された構成の場合のみ）？有効なセカンダリコピーが4MB（fuse n=0）にあり、プライマリヘッダーが消去され、ROMはオープン構成にフォールバックしません。

割り込みを有効にせずにDMAでLPI2Cペリフェラルを使うにはどうすればいいですか? こんにちは、 私は NXP S32K396 MCU を扱っており、 割り込みを有効にせずにeDMAを使ってLPI2Cマスタートランザクションを実行したいと考えています。私のプロジェクトでは LPI2C1ペリフェラルを使っています。 以下の割り込みが有効であれば、DMAを使ってLPI2Cの読み書きトランザクションを正常に実行できます: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn rkhw_0-1783969062532.png しかし、RTD LPI2C DMAの実装はこれらの割り込みに依存しているようです。 Lpi2c_Ip_MasterSendData()では、LPI2Cマスター割り込みは常にドライバによって有効化されます: rkhw_1-1783969133234.png さらに、Lpi2c_Ip_MasterTxDmaConfig() および Lpi2c_Ip_MasterRxDmaConfig() によって TX および RX 用に構成された DMA TCD は、常に DMA メジャーループ完了割り込みを有効にします。 Lpi2c_DmaTransferList[9u]. Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u]。値= 1U; また、別の関数であるLpi2c_Ip_MasterSendDataBlocking()では、LPI2C転送用のDMA TCDが設定されていないようです。 DMAを使ってLPI2Cの送受信トランザクション全体を行い、DMAを無効にし、eDMAチャネル割り込みを無効にLPI2C1_IRQnしたいと考えています。   可能であれば、NXPが LPI2CとDMAの両方の割り込みを無効にした状態でDMAを使用するLPI2CマスターTX/RXの例を提供していただけますか?   MCU:NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   どんなご支援でも大変ありがたく思います。どうぞよろしくお願いいたします！ 必要なら、プロジェクトを添付できます。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? こんにちは@rkhw 現在のドライバ実装では、「Lpi2c_Ip_MasterSendData()」は転送完了と状態処理のためにLPI2Cマスター割り込みとDMAメジャーループ完了割り込みの両方に依存しています。 したがって、割り込みを有効にしなければDMAを有効にすることはできません。RTDドライバーはこの使用をサポートしていません。

Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello NXP Team, I am bringing up a custom board based on the i.MX9596 processor with LPDDR5 memory using the i.MX OEI bootloader. I generated the DDR configuration for my custom board using MCUXpresso Config Tools version 26.3. The generated files are: lpddr5_timing.c lpddr5_config.ds peripherals.c peripherals.h pin_mux.c pin_mux.h In the OEI source under boards/mx95lp5/ddr, I found these files: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c I would like to confirm the correct integration procedure for a custom LPDDR5 board. Should the generated lpddr5_timing.c be used in place of MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c, with OEI_DDR_CONFIG updated to reference the new timing file? Is XIMX95LPD5EVK19_6400mbps_train_timing_a1.c a silicon-specific training file provided by NXP that should remain unchanged for a custom board? OEI uses the following DDR PHY firmware binaries: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin Can these same firmware binaries be reused on a custom LPDDR5 board as long as the firmware version matches the generated DDR timing configuration? Is the ECC-enabled timing file required only when LPDDR5 ECC is enabled? If ECC is not used on the custom board, is the normal timing file sufficient? Please let me know if any additional files need to be regenerated or modified when migrating from the EVK DDR configuration to a custom LPDDR5 board. Thank you. Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello, 1. Yes, you need to replace the MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c with your custom configuration. 2. That is a different configuration for that specific silicon revision, it can be used as a reference if is your case. If you are not using this configuration, you can leave it untouched. 3. Yes, those binaries can be reused for similar configurations and normal timing file sufficient if you are not using ECC. Best regards.

执行 fls_Erase() 操作期间断电后，数据闪存损坏和 ECC 错误 我们发现，当由于断电/RESET情况导致Fls_Erase()操作中断时，数据闪存会发生损坏。系统重启后，受影响的数据闪存区域似乎已损坏。 AshokSubramani_1-1783921509927.png 在随后尝试使用Fls_Erase()恢复扇区时，当 Flash 驱动程序在执行擦除操作之前尝试访问受影响的地址范围时，会生成 ECC 错误。因此，擦除操作无法成功进行。 我们希望了解闪存控制器在此场景下的预期行为，并请求就以下几点提供指导： 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 目标设备： [MPC5746C] 软件栈： [AUTOSAR / 裸机] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation 你好， 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 是的，这是正确的做法。由于编程/擦除过程中断电，闪存中的数据将与 ECC 纠错码不匹配。 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是的。 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 不，这是硬件的永久性功能。 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 在这种情况下，您需要初始化（擦除）损坏的闪存块。一旦完成 ECC 纠错，闪存中的数据将与 ECC 纠错匹配，访问不会触发 ECC 错误。 有关闪存擦除步骤，请参阅参考手册： petervlna_0-1783927605596.png 顺祝商祺！ Peter

MCUXpresso Secure Provisioningツールを使用する場合、複数のRAMにコードを配置することはできません。 IMXRT1171 上で動作する私たちのプロジェクトは、SD カードから起動し、RAM 上で動作します。以前は、コードの大部分が ITC RAM に収まっており、開始アドレスを 0x3000 に変更し（サイズを -0x3000 小さく変更する）、MCUXpresso Secure Provisioning ツールで問題なく動作していました。しかし、ITC RAMが不足し始めたため、一部の機能を（リンカテンプレートを介して）OCRAMに移動する必要が生じました。この操作を行った後、MCUXpresso Secure Provisioningツールは、異なるメモリ領域にあるコードをサポートしていないというエラーメッセージを表示するようになりました。できればすべてをOCRAMに移動させたくなかったのですが、どうやらそうせざるを得ないようです。2つの異なるRAMに保存されたコードでツールを動作させるための、他に何か回避策はありますか？ よろしくお願いします！ -m Re: Cannot have code in multiple RAMs when using MCUXpresso Secure Provisioning tool こんにちは、 @nxp16 さん。 SPTからどのようなエラーメッセージが表示されているか、具体的に教えていただけますか？いずれにしても、私のおすすめは、i.MX RT1170のFlexRAM機能を利用して、ITC RAMのサイズをアプリケーションのニーズに合わせて調整することです。その方法を説明したアプリケーションノートはこちらです： AN12077：i.MX RT FlexRAMの使用 – アプリケーションノート BR、 エドウィン。 Re: Cannot have code in multiple RAMs when using MCUXpresso Secure Provisioning tool ITC RAMのサイズは最大256kを超えることはできません。FlexRAMは、その点では役に立ちません。残念ながら、具体的なエラーメッセージは覚えていません。この問題を回避するため、OCRAM1のみを使用し、ITC RAMは空にしておくようにしました。

S32K396的ETPU的例子 您好，我需要一个S32K396的RTD5.0.0用于S32DS3.5中生成的ETPU的demo，然后我想将它用于喷油功能，可以给我一个软件包和代码例子吗 Re: S32K396的ETPU的例子 嗨@大概， 实时驱动程序 (RTD)中已有 ETPU 和 S32K396 的示例： Julin_AragnM_0-1783962715540.png 此外，您可以在S32K3 - eTPU软件包中找到各种示例。它独立于RTD，这意味着可以使用任何版本，但是，eTPU软件仅使用特定的RTD 7.0.0版本进行了验证。版本，且无法保证与其他版本的兼容性。 此致， 朱利安

How to evaluate NPU tflite model on large dataset on MIMRT700 board? My question is as my tittle. I have tflite model, I converted to NPU tflite model. I checked that predictions from tflite model and NPU tflite model are different in some cases (not much). So I want to run evaluation NPU tflite model on the large dataset. Currently, I follow the sample tflm_cifar10_cm33_core0 to run inference NPU tflite model on  MIMRT700 and it works. But in this sample, we fixed image_data.h for static image (I do not use camera). I want to modify this sample for my new case "run evaluation NPU tflite model on the large dataset." I intend to use SD cards to save image and load it when inference as image_data.h. But I do not know where I can start I saw that MIMRT700 has 3 micro USB port: debug, eUSB and USB-OTG If you have any recommedation and suggestions, please share with me. If I manually run each image (build + flash), it will take much time. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz  Thank you for supporting me. The method with SD card is good. I am not good at hardware, so as my teamate's suggestion. How about this method that I mentioned above? Currently I follow step by steps to run inference with the sample tflm_cifar10_cm33_core0: - Copy image_data.h to sample - Click Build button - Click debug button, and click continue button to run inference. I discussed with my teammates and if I can run above via command line (build, and run inference) by using commands, so it is very good. Because if it works, I can create script to change image_data.h each time, build and run inference and get inference results back to PC. Do you have any comment on that? I mean that if NXP have guideline to build, flash and run sample tflm_cifar10_cm33_core0, I can customize easier. I am not good at hardware, so that I like this method (If NXP support this methods, I can create Python script to creata image_data.h each time, build, flash, run and get result back to PC, save to .csv file, e.t.c). I see other many vendors which support this method (build, flash and run, get result back to PC via command line). I think that NXP also supports this method. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? Hi @nnxxpp, The example uses the static-header approach, as you mentioned. However, establishing a pipeline that leverages mounting images via an SD card would be much more suitable for large datasets: Have the images pre-loaded on the SD card, then mount the SD card, open the image list, and for each image: - Read into an input buffer - Run NPU inference - Write result on a "results.csv" file We currently do not have a sample code that exemplifies this, but you can refer to both the tflm_cifar10_cm33_core0 that you are using, as well as sdcard_fatfs example from the SDK, which already handles the initialization and card mounting, and has all the available APIs for SD card usage. I suggest you run and understand the sdcard example, and test reading a binary image file. Then, add the sd card components to the tflm example and import the SD card initialization and FatFs code, and finally replace the static image_data.h input with a buffer containing image info read using f_read() from the SD card. Having the images already stored in the tensor format would ease the process and prevent the use of JPEG/PNG decoding. BR, Edwin. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? I want to add more information. Currently I follow step by steps to run inference with the sample tflm_cifar10_cm33_core0: - Copy image_data.h to sample - Click Build button - Click debug button, and click continue button to run inference. I discussed with my teammates and if I can run above via command line (build, and run inference) by using commands, so it is very good. Because if it works, I can create script to change image_data.h each time, build and run inference and get inference results back to PC. Do you have any comment on that? Thank you so much. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? I also saw that MIMRT700 has SD card, if I can easily locate images on SDcard on load image to tflm_cifar10_cm33_core0 and save inference results on SD card, so it is very good. But to be honest, I do know how to start. I am not good at hardware. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? Hi @nnxxpp, I understand. You can run MCUXpresso SDK projects from command line and automate the process using a script. Our SDK command-line flow uses west build, and flashing can be done with west flash -r linkserver. AN14700 specifically uses CLI to compile the project as described on part 8 of section "7.3 Run the converted model". So, a general application of a script to automate this process could: 1. copy new image_data.h 2.  build using west build 3. program using west flash 4. capture UART log Although not the "conventionally recommended method", this would definitely work as well for your application. BR, Edwin. Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz  Yes. Thank you so much.  I also investigated and followed this document, and I could flash an run program by using west. From here, I can build script to automate all processes. Before I used this command  west build -b mimxrt700evk examples/demo_apps/hello_world -- -Dcore_id=cm33_core0   I saw in the doc of AN14700, there is west build -p always examples/eiq_examples/tflm_label_image --toolchain armgcc --config flash_debug -b mimxrt700evk -Dcore_id=cm33_core0   I have a question about flag --  in the first command. What does it mean? and which flags I should to config when running NPU tflite model on mimxrt700evk?

S32K312 的 ADC1_MA1 引脚可以用作 ADC 输入吗？ 您好，NXP团队， 我正在使用 S32K312 控制器，我想使用标记为ADC1_MA1的引脚来读取电位器电压。 我知道ADC1_MA1是ADC外部多路复用器的地址输出引脚。但是，我想确认一下SIUL2、ADC或引脚复用设置中是否有任何配置允许将此引脚用作普通的ADC模拟输入。 我的要求是连接一个电位器滑动电压，范围为 0 V 至 3.3 V，并通过 ADC1 读取该电压。 请您确认一下： ADC1_MA1是否与任何 ADC 输入通道/采样保持电路存在物理连接？ 能否通过软件将此引脚配置为ADC输入？ 如果不能用作 ADC 输入，当 PCB 设计时电位器已连接到该引脚时，是否有推荐的硬件变通方法？ 谢谢。 此致， 埃萨基 Re: Can ADC1_MA1 pin be used as ADC input on S32K312? 你好Esakki， ADC1_MA1 是ADC 多路复用器输出，是一个数字引脚，其方向为输出。该引脚的功能在“ S32K3 ADC 外部通道的使用”中进行了描述。 ADC1_MA1 引脚没有直接信号，不能用作 ADC 输入。只有在“直接信号”部分列出了 ADC 的引脚才能用作 ADC 输入。 PTB24 ADC1_MA[1] no Direct Signals.png PTB24 ADC1_MA[1] ADC Mux Output.png 遗憾的是，目前没有其他可靠的解决方案，建议修改硬件电路。 此致敬礼， Robin Re: Can ADC1_MA1 pin be used as ADC input on S32K312? 嗨@Robin_Shen ， 感谢您清晰的解释和确认。感谢您的支持。 此致， 埃萨基

S32 Design Studio for ARM v2.2许可延期 あなたは好,S32 Design Studio for ARM v2.2提示許可馬上到期,Activation Code:FAF2-FCC2-8A8E-87AC,麻烦延期,谢谢!

如何在MIMRT700板上使用大型数据集评估NPU tflite模型？ 我的问题如标题所示。 我有一个 tflite 模型，我把它转换成了 NPU tflite 模型。我检查发现，tflite 模型和 NPU tflite 模型的预测结果在某些情况下有所不同（但差别不大）。因此，我想在大数据集上运行 NPU tflite 模型评估。 目前，我按照示例tflm_cifar10_cm33_core0在 MIMRT700 上运行推理 NPU tflite 模型，并且运行正常。但在本示例中，我们针对静态图像修复了 image_data.h（我没有使用相机）。我想修改这个示例，以用于我的新案例“在大数据集上运行评估 NPU tflite 模型”。 我打算使用 SD 卡保存图像，并在推理时将其加载为 image_data.h。但我不知道该从何说起。 我看到MIMRT700有3个micro USB接口：调试接口、eUSB接口和USB-OTG接口。 如果您有任何建议或意见，请与我分享。如果我手动运行每个镜像（版本+刷写），那将非常耗时。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz 谢谢你支持我。 使用SD卡的方法很好。我不擅长硬件，所以采纳了我队友的建议。 我上面提到的这种方法怎么样？ 目前我正在按照以下步骤使用样本tflm_cifar10_cm33_core0 进行推理： -将 image_data.h 复制到样本 - 点击“版本”按钮 - 点击调试按钮，然后点击继续按钮运行推理。 我和我的队友讨论过，如果我可以通过命令行使用命令来运行上述操作（版本和运行推理），那就非常好了。因为如果可行，我可以编写脚本每次修改 image_data.h 文件，构建并运行推理程序，并将推理结果返回到电脑上。您对此有何看法？ 我的意思是，如果 NXP 有构建、烧录和运行示例tflm_cifar10_cm33_core0 的指南，我可以更容易地进行自定义。我不太擅长硬件，所以我喜欢这种方法（如果NXP支持这种方法，我可以编写Python脚本，每次生成image_data.h文件，进行编译、烧录、运行并将结果返回到PC，保存为.csv文件）。文件等）。我看到很多其他厂商也支持这种方法（版本、刷写和运行，通过命令行将结果返回到 PC）。我认为恩智浦也支持这种方法。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? 嗨@nnxxpp ， 正如您所提到的，该示例采用了静态头文件方法。然而，对于大型数据集而言，建立一个利用 SD 卡挂载图像的流程会更加合适： 将图片预先加载到 SD 卡上，然后挂载 SD 卡，打开图片列表，并对每张图片执行以下操作： - 读入输入缓冲区 - 运行 NPU 推理 - 将结果写入“results.csv”文件文件 我们目前还没有示例代码来说明这一点，但您可以参考您正在使用的 tflm_cifar10_cm33_core0，以及 SDK 中的 sdcard_fatfs 示例，该示例已经处理了初始化和卡挂载，并具有 SD 卡使用的所有可用 API。 我建议你运行并理解 sdcard 示例，并测试读取二进制图像文件。然后，将 SD 卡组件添加到 tflm 示例中，导入 SD 卡初始化和 FatFs 代码，最后替换静态的 image_data.h 文件。输入缓冲区，其中包含使用 f_read() 从 SD 卡读取的图像信息。 如果图像已经以张量格式存储，将简化处理过程，并避免使用 JPEG/PNG 解码。 BR， 埃德温。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? 我想补充更多信息。 目前我正在按照以下步骤使用样本tflm_cifar10_cm33_core0 进行推理： -将 image_data.h 复制到样本 - 点击“版本”按钮 - 点击调试按钮，然后点击继续按钮运行推理。 我和我的队友讨论过，如果我可以通过命令行使用命令来运行上述操作（版本和运行推理），那就非常好了。因为如果可行，我可以编写脚本每次修改 image_data.h 文件，构建并运行推理程序，并将推理结果返回到电脑上。您对此有何看法？太感谢了。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? 我还看到 MIMRT700 有 SD 卡，如果我能轻松地在 SD 卡上找到图像，并将图像加载到tflm_cifar10_cm33_core0并将推理结果保存到 SD 卡上，那就非常好了。 但说实话，我知道该如何开始。我不擅长硬件。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? 嗨@nnxxpp ， 我明白。 您可以从命令行运行 MCUXpresso SDK 项目，并使用脚本自动执行该过程。我们的 SDK 命令行流程使用 west build，可以使用 west flash -r linkserver 进行刷写。 AN14700 特别使用 CLI 来编译项目，如第 7.3 节第 8 部分所述。运行转换后的模型”。 因此，实现此过程自动化的通用脚本应用可以： 1. 复制新的 image_data.h 2. 使用西部建筑风格进行建造 3. 使用西闪卡编程 4. 捕获 UART 日志 虽然这不是“常规推荐方法”，但对于你的应用来说也绝对有效。 BR， 埃德温。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz 是的，非常感谢。 我还研究并按照这份文档操作，并且可以使用 west 刷写运行程序。从这里出发，我可以编写脚本来自动化所有流程。 在我使用这个命令之前 west build -b mimxrt700evk examples/demo_apps/hello_world -- -Dcore_id=cm33_core0   我在 AN14700 的文档中看到，有west build -p always examples/eiq_examples/tflm_label_image --toolchain armgcc --config flash_debug -b mimxrt700evk -Dcore_id=cm33_core0   我有一个关于标志的问题——在第一个命令中。这是什么意思？在mimxrt700evk 上运行 NPU tflite 模型时，我应该配置哪些标志？

Example of an ETPU based on S32K396 Hello, I need a demo of RTD 5.0.0 for S32K396 used in an ETPU generated by S32DS3.5. I want to use it for fuel injection functionality. Could you provide a software package and code examples? Re: S32K396的ETPU的例子 Hi @大概, There is an existing example for ETPU & S32K396 inside the Real-Time Drivers (RTD): Julin_AragnM_0-1783962715540.png Additionally, you can find various examples inside the S32K3 - eTPU SW package. It is independent from RTDs, meaning any version can be used, however, the eTPU SW has been validated only with the specific RTD 7.0.0 version, and compatibility with other versions cannot be guaranteed. Best regards, Julián

Cannot have code in multiple RAMs when using MCUXpresso Secure Provisioning tool Our project on the IMXRT1171 boots from SD card and runs from RAM.  Previously most of our code fit into ITC RAM, and MCUXpresso Secure Provisioning tool had no issue with it as long as we modified our start address to 0x3000 (and modified the size -0x3000 smaller).  However, we started running out of ITC RAM and had to move some functions (via linker templates) to OCRAM.  After doing this, MCUXpresso Secure Provisioning tool now complains that it does not support code in different memories.  I was hoping to avoid moving everything into OCRAM but it looks like that's what I'm going to have to do now.  Is there some other workaround to get the tool to work with code in two separate RAMs? Thanks! -m Re: Cannot have code in multiple RAMs when using MCUXpresso Secure Provisioning tool Hi @nxp16, Could you please specify what error you are getting from SPT? In any case, my recommendation would be to use the FlexRAM capabilities of the i.MX RT1170 to adjust the size of the ITC RAM to your application's needs. Here is an AppNote that explains how to do so: AN12077: Using the i.MX RT FlexRAM – Application Note BR, Edwin. Re: Cannot have code in multiple RAMs when using MCUXpresso Secure Provisioning tool You can't adjust the size of ITC RAM above its maximum 256k.  FlexRAM does not help with that.  Unfortunately, I don't recall what the specific error message is and to workaround the problem, I've moved on to just using only OCRAM1 instead and leaving ITC RAM empty.

Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation We are observing Data Flash corruption when a Fls_Erase() operation is interrupted due to a power abort/reset condition. After the system restarts, the affected Data Flash region appears corrupted. AshokSubramani_1-1783921509927.png During a subsequent attempt to recover the sector using Fls_Erase(), ECC errors are generated when the Flash driver tries to access the affected address range before performing the erase operation. As a result, the erase operation cannot proceed successfully. We would like to understand the expected behavior of the Flash controller in this scenario and request guidance on the following points: Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? Target Device: [MPC5746C] Software Stack: [AUTOSAR / Bare Metal] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation Hello, Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Yes, that is correct behavior. As data in flash will not match ECC syndromes in flash due to power loss during programming / erase process. Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Yes. Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? No. It is permanent HW feature. What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? You need to initialize (erase) the corrupted flash block in such case. Once done ECC syndrome will match the data in flash and access wont trigger ECC faults. For flash erase procedure please refer to reference manual: petervlna_0-1783927605596.png Best regards, Peter

6,000枚の画像データセットでeIQツールキットのトレーニング時間を短縮するにはどうすればいいですか? 私はeIQ Toolkitを使って、約6,000枚の画像からなるデータセットで画像分類モデルを訓練しています。目標は 、800KB 未満のTensorFlow Lite(TFLite)モデルを生成し、 MCXN947上で動作させることです。 現在のトレーニング構成は以下の通りです: モデル:MobileNetV2 アルファ: 0.35 剪定：有効 出力形式: TFLite 問題は、トレーニングの完了にほぼ 24時間 かかることです。最終モデルサイズを800KB未満に抑えつつ、トレーニング時間を1〜2時間程度に短縮できるおすすめの設定や最適化があれば知りたいです。 同じような状況に直面した方はいらっしゃいますか？eIQツールキットには、モデルの精度を大きく損なわずにトレーニング時間を短縮したり、モデルサイズを大きく変えたりするベストプラクティスはありますか? 何かご提案があれば大変ありがたいです。ありがとう！ FRDMトレーニング MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? こんにちは、 @sivamankomb さん。 小規模なMobileNetV2-alpha-0.35の移行学習ジョブで、6,000枚以上の画像を24時間かけて実行することは、CPU上でトレーニングが行われている場合、入力サイズが大きい場合、エポックが多すぎる場合、強い動的拡張がある場合、またはトレーニング中ずっとプルノングやQATを行っている場合を除きます。 以下の点を参照できると思います。 CUDAとcuDNNがインストールされ、使用されていることを確認してください。 Harry_Zhang_0-1783936461198.png 許容できる精度を維持できる最小の入力解像度を使用してください。224×224を使用している場合は、まず128×128を試してみてください。 固定の長期トレーニングランではなく、低いエポックリミットと早期停止から始めましょう。 初期のトレーニングランでは剪定を無効にし、 展開にはINT8 TFLite量子化を使用します。 最初の速度最適化実行ではQATを避ける。 「強化なし」から始めましょう。 具体的な内容についてはeIQ Toolkitユーザーガイドを参照してください BR ハリー

How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? I am using the eIQ Toolkit to train an image classification model with a dataset of approximately 6,000 images. My target is to generate a TensorFlow Lite (TFLite) model that is smaller than 800 KB so that it can run on the MCXN947. My current training configuration is: Model: MobileNetV2 Alpha: 0.35 Pruning: Enabled Output format: TFLite The issue is that the training process takes nearly 24 hours to complete. I would like to know if there are any recommended settings or optimizations that can reduce the training time to around 1–2 hours while still keeping the final model size below 800 KB. Has anyone faced a similar situation? Are there any best practices in the eIQ Toolkit for reducing training time without significantly affecting model accuracy or increasing the model size? Any suggestions would be greatly appreciated. Thank you! FRDM-Training MCXN Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? Hi @sivamankomb  A 24-hour run for ~6,000 images is not expected for a small MobileNetV2-alpha-0.35 transfer-learning job unless training is running on CPU, using a large input size, too many epochs, heavy dynamic augmentation, or doing pruning/QAT throughout the full training run. I think you can refer to the following. Verify CUDA + cuDNN are installed and being used. Harry_Zhang_0-1783936461198.png Use the smallest input resolution that still gives acceptable accuracy; if you are at 224×224, try 128×128 first. Start with a low epoch limit plus early stopping, not a fixed long training run. Disable pruning for the initial training run; Use INT8 TFLite quantization for deployment; Avoid QAT in the first speed-optimized run; Start with “No Augments,”  You can refer to eIQ Toolkit User Guide for specific content BR Harry

如何缩短 eIQ Toolkit 对包含 6000 张图像的数据集的训练时间？ 我正在使用 eIQ Toolkit 训练一个图像分类模型，数据集大约有 6,000 张图像。我的目标是生成一个小于800 KB的 TensorFlow Lite (TFLite) 模型，以便它可以在MCXN947上运行。 我目前的训练配置是： 型号：MobileNetV2 Alpha：0.35 修剪：已启用 输出格式：TFLite 问题在于，整个培训过程需要近24小时才能完成。我想知道是否有任何推荐的设置或优化方法，可以在将最终模型大小保持在800 KB以下的同时，将训练时间缩短到1-2 小时左右。 有人遇到过类似的情况吗？eIQ Toolkit 中是否有任何最佳实践可以在不显著影响模型准确率或增加模型大小的情况下减少训练时间？ 任何建议都将不胜感激。谢谢你！ FRDM 培训 MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? 嗨@sivamankomb 对于小型 MobileNetV2-alpha-0.35 迁移学习作业来说，除非训练是在 CPU 上运行、使用较大的输入规模、过多的 epoch、大量的动态增强，或者在整个训练过程中进行剪枝/QAT，否则预计不会出现 24 小时运行约 6,000 张图像的情况。 我认为你可以参考以下内容。 确认已安装并正在使用 CUDA + cuDNN。 Harry_Zhang_0-1783936461198.png 使用能够保证可接受精度的最小输入分辨率；如果您使用的是 224×224，请先尝试 128×128。 首先设定较低的训练轮数限制并提前停止，而不是进行固定的长时间训练。 初始训练运行禁用剪枝； 部署时使用 INT8 TFLite 量化； 在第一次速度优化运行中避免使用 QAT； 首先选择“无增强功能”， 具体内容请参阅 eIQ Toolkit 用户指南。 BR 哈里

iMXRT1052 カスタムファームウェアでキーブロブを生成しても、起動時に受け入れられません。 こんにちは、   署名済みの暗号化ブートローダーがあり、HABは有効になっていますが、シールはされていません。NXPのセキュアプロビジョニングツールを使ってフラッシュすると、問題なく動作します。同様に、FCB + パディング + 署名および暗号化されたブートローダー + キーブロブ（キーブロブはターミナルで次のコマンドを実行して生成されます）を連結すると、次のようになります。   blhost -t 5000 -u 0x15A2,0x0073 -j -- generate-key-blob "dek.bin" "blob.bin"   それも効果がある。しかし、デバッグセッション（キーブロブを生成するためだけに用いられる）でカスタムファームウェアを使用してこのプロセスを実行すると、生成されたブロブファイルが受け入れられず、ブートローダーの実行に失敗します。どちらのシナリオにおいても、DEKは変化しない。   両方とも.binファイルを生成しましたファイル間の違いは、ブロブオフセットアドレスのみである。   Secure Provisioning Toolが提供するflashloader.binと公開されているソースコード(MCUブート)との間に違いはありますか?   標準のフラッシュローダーは、このバージョンを報告します。 blhost -u 0x15A2,0x0073 -- get-property 1 Response status = 0 (0x0) Success. Response word 1 = 1258424320 (0x4b020800) Current Version = K2.8.0   bl_version.h に基づくと、ソースコードは一貫しているはずであり、Secure Provisioning Tool のバージョンは 25.09 です。   カスタムファームウェアはフラッシュローダーソースからのコードスニペット(特にbl_keyblob_dcp.cにあります)を使用しています。そして、すべての依存関係は同じソースから取得されます。この実装は内部でのみ使用されるため、ファームウェアからDEKを抽出することは問題ありません。   お時間をいただきありがとうございました。 🙂 Re: iMXRT1052 Generating key blob in custom firmware not accepted on boot. こんにちは、 @JordanSt さん。 あなたはiMXRT1052を使って以下のようにテストを行ったと理解してよろしいでしょうか？ 1. NXPのセキュアプロビジョニングツールからフラッシュローダーをロードし、以下のコマンドを使用してdek.binとblob.binを取得します。 blhost -t 5000 -u 0x15A2,0x0073 -j -- generate-key-blob "dek.bin" "blob.bin" 2. iMXRT1052でflashloaderのSDKデモのコードを使ってカスタムファームウェアを実行し、上記のコマンドでdek.binとblob.binを得ます。 3. 生成された dek.bin ファイルは同じですが、blob.bin ファイルは異なります。 私の理解が正しければ、ステップ2のSDKのフラッシュローダーは試しましたか?結果は同じだったのでしょうか? すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: iMXRT1052 Generating key blob in custom firmware not accepted on boot. こんにちは@Kan_Li ご支援ありがとうございます。 関連事項: 1. NXPのSecure Provisioning Toolからフラッシュローダーを読み込み、以下のコマンドでdek.binとblob.binを起動します - そうだ、鍵の塊を手に入れるために。 2. iMXRT1052でflashloaderのSDKデモのコードを使ってカスタムファームウェアを実行し、上記のコマンドでdek.binとblob.binを得ます。 - はい、しました。SDKのデモフラッシュローダーでテストしました。こちらもカスタムファームウェアです。 重要かどうかはわかりませんが、主な違いはSPTのフラッシュローダーは内部のSRAMから実行されるのに対し、カスタムファームウェアやSDKのデモはそうではなく、外部(搭載)SDRAM用に設定・構築されていることです。 3. 生成されたdek.binファイルは同じですが、blob.binファイルは異なります。 はい、どちらのシナリオでも使用される DEK は同じです (当然です)。生成されたキー ブロブを見ると、ヘッダーは同じで、bk セクションと dek セクションのみが異なり、mac セクションはすべてゼロです。 すてきな一日を 🙂 ヨルダン

Fls_Erase() 操作中の電源中断後のデータフラッシュ破損および ECC エラー 電源の中断/リセットによってFls_Erase()操作が中断された場合、データフラッシュの破損が発生することを確認しています。システムを再起動すると、影響を受けたデータフラッシュ領域が破損しているように見える。 AshokSubramani_1-1783921509927.png その後、セクターを Fls_Erase()で復旧しようとする際、フラッシュドライバが消去操作を行う前に影響を受けたアドレス範囲にアクセスしようとした際にECCエラーが発生します。その結果、消去作業は成功裏に進められません。 このシナリオにおけるフラッシュコントローラの期待される挙動を理解し、以下の点についての指針をお願いしたいと思います。 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ ターゲット装置: [MPC5746C] ソフトウェアスタック: [AUTOSAR / ベアメタル] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation こんにちは、 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ はい、それは正しい行動です。フラッシュメモリ内のデータは、プログラミング／消去処理中の電源喪失により、フラッシュメモリ内のECC症候群と一致しなくなります。 このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? はい。 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? いいえ。これは恒久的なハードウェア機能です。 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ その場合は破損したフラッシュブロックを初期化(消去)する必要があります。一度実行すると、ECC症候群はフラッシュのデータと一致し、アクセスによってECCの故障が起きません。 フラッシュ消去の手順については、リファレンス・マニュアルをご参照ください: petervlna_0-1783927605596.png よろしくお願いいたします。 ピーター

IMX8MP 辅助映像启动 IMG_CNTN_SET1_OFFSET 辅助映像启动（RM 6.1.6.2）是否适用于 i.MX8MP 上的 ECSPI（“SPI”）或非 启动，还是仅适用于 FlexSPI 或非（和 SD/eMMC）？表 6-28 将“SPI”和“FlexSPI NOR”列为单独的引导设备，并且仅针对“FlexSPI NOR 启动”说明了辅助偏移有效值。 Re: IMX8MP secondary image boot 你好， 你的理解有误， IMG_CNTN_SET1_OFFSET 辅助镜像启动也适用于 SPI 设备，只是偏移量不同： FlexSPI 的有效值为：0、1、2、3、4、5、6 和 7 对于 SPI 模式，如果熔丝位大于 10，则禁用辅助启动；n = 熔丝位大于 10. • n == 0：偏移量 = 4MB • 当 n == 2 时：偏移量 = 1MB • 其他情况且 n <= 10：偏移量 = 1MB*2^n Oswalag_0-1782750547759.png Re: IMX8MP secondary image boot 谢谢——这下偏移映射的问题就清楚了。我们需要进行两项后续操作，以便在我们的 i.MX8MP 板上重现该问题（在 ECSPI2 上启动或非，开放/非 HAB 配置，熔丝读取 2 1 = 0 → n=0 → 4 MB）： 是什么触发信号 ROM 在 SPI 或非接口上切换到辅助映像？是无效的主启动头/镜像解析失败，还是具体的 HAB 认证失败？换句话说，辅助映像启动在开放（非安全）配置下是否有效，还是仅在设备 HAB 关闭时才有效？ 它会恢复到之前的RESET状态，还是需要断电重启/第二次RESET（持久启动方式）？ 4 MB 偏移处的辅助映像必须是单独版本的可启动映像（具有该偏移处的独立虚拟映像/启动数据），还是主映像的字节相同副本就足够了？ Re: IMX8MP secondary image boot 在 OPEN (SEC_CONFIG=open, non-HAB) 配置下，i.MX8MP 从 ECSPI (SPI) NOR 启动时，IMG_CNTN_SET1_OFFSET 辅助映像启动的确切触发条件是什么？ROM 是否会在主容器头无效/被擦除时切换到辅助镜像，还是仅在 HAB 身份验证失败时才会切换到辅助镜像（例如，当主容器头无效/被擦除时）？仅在封闭/安全配置下？我们有一个 4MB 的有效辅助副本（熔丝 n=0），擦除了主头，并且 ROM 不会回退到开放配置。