Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
Kinetis(KW3x/4x)オートモーティブ用パワープロファイルツール このページは、Kinetis(KW35/KW38/KW45/KW47)パワープロファイルツール用 オートモーティブに特化しています。 これにより、オートモーティブ アプリケーション(キーフォブ/スマートフォブ、アンカー)での消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、以下の用途に特化した3つの電源プロファイルツールが含まれています。 KW35/36製品用のBluetooth LEをスタンドアロンで使用。 Bluetooth LEはKW37/38/39製品用のスタンドアロン対応です。 KW45/KW47製品用のBluetooth LEをスタンドアロンで使用。 スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ) スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ)    1. KW35/36 Bluetooth LE 電力プロファイリングスタンドアロン:  2. KW37/38/39 Bluetooth LE 電力プロファイリングスタンドアロン:  このツールには、AnchorとKeyfob/スマートフォンの消費電力を大まかに推定するための3つの異なるユースケースが含まれています。 1- CCCモバイル電話が車にコネクテッドされ、パケットを交換して車のドアを解除する 2- 車にコネクテッドされたパケットを継続的に交換するSCAキーフォブ 3- CCCスマートフォンが車にコネクテッドされ、パケットを継続的に交換する:2行モード 3. KW45/KW47 Bluetooth LE 電力プロファイリングスタンドアロン: AN13230 Kinetis KW45 Bluetooth LE 消費電力分析 AN14554 Kinetis KW47 Bluetooth LE パワープロファイル解析release.pdf 4. スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ)パワープロファイリング 5. スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ)パワープロファイリング id:ワイヤレス・コネクティビティ [開始日: 2026年7月31日]
View full article
S32K344 HSE_ActivatePassiveBlock 後のAB-Swap車載起動失敗;ファームウェアはJ-Link Staでのみ起動します プラットフォーム:ABスワップ方式S32K344。ファームウェアイメージは、アクティブブロックとパッシブブロックにそれぞれ別々に格納されています。観察結果:HSE_ActivatePassiveBlock()を実行してアクティブ/パッシブパーティションを交換した後、完全な電源サイクルを実行しても、ファームウェアの自動起動はトリガーされません。ファームウェアはJ-Linkが接続され、デバッガから「アプリケーションの開始」がトリガーされた場合にのみ正常に動作します。誰か根本原因を説明し、推奨される対処法を教えていただけませんか? Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、 @HQZ パッシブパーティションに有効なイメージが存在することを確認しましたか?電源投入後にリセットせずに実行中のターゲットにデバッガーを接続すると、どのような現象が観察されますか?デバイスはJTAGリカバリーモードに入りましたか?あるいは、デバッガでデバイスをリセットしてから、アプリケーションのエントリーポイントに到達したかを確認することもできます。 デバイスがアドレス0x2040012Cで無限ループに陥っている場合、JTAGリカバリモードに入ったことを示しています。これはIVTの設定やIVTの整合性に問題がある可能性もあります。 また、パッシブパーティション内のイメージは、アクティブパーティションのアドレス空間(つまり、0x00400000から始まるアドレス空間)から実行されるようにリンクされていますか? 最後に、セキュアブートを使用していますか? よろしくお願いいたします。 ルーカス
View full article
Kinetis MCX Wxx (MCX W71/72 & MCX W23) Power Profile Tools for IIoT This page is dedicated to the Kinetis MCX Wx (MCX W71/72 & MCX W23) Power Profile Tools for IIoT. It will help you to estimate the power consumption in your application (Automotive, IIoT, Trackers/Tags and Continuous Glucose Monitoring [CGM]) and evaluate the battery life time of your solution. This page contains 4 dedicated power profile tools for: Bluetooth LE for the MCX W71/MCX W72 product in standalone. Bluetooth LE for the MCX W23 product in standalone. 802.15.4 Matter ICD SIT & LIT and ZED for the MCX W71 & W72 product in standalone. Aliro Doorlock application (BLE MCX W72/UWB/NFC/Motor) 1. MCX W71 / MCX W72 Bluetooth LE power profiling: AN14389 MCX W71 Bluetooth LE Power Consumption Analysis AN14739 MCX W72 Bluetooth LE Power profile analysis.pdf 2. MCX W23 Bluetooth LE power profiling AN14659: MCX W23 Bluetooth Low Energy Power Consumption Analysis | NXP Semiconductors 3. 802.15.4 Matter ICD SIT & LIT and ZED MCX W71/W72 Power profiling AN14841 MCX W72 802.15.4 Matter and Zigbee Power profile analysis.pdf 4. Doorlock application (BLE/UWB/NFC/Motor)
View full article
CONFIG_FIT_CIPHER=y alone causes hab_status Hello Support, CONFIG_FIT_CIPHER=y alone causes hab_status to report HAB_INV_SIGNATURE/HAB_INV_ASSERTION on i.MX8M Plus EVK (OPEN mode) Board: i.MX8MP LPDDR4 EVK, OPEN/unfused (HAB Configuration: 0xf0, HAB State: 0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB signing: working correctly otherwise — CST-signed imx-boot (SPL CSF + FIT CSF), custom build-time task that verifies the CSF tag byte at both embed offsets and fails the build on any mismatch (always passes) I have a clean baseline where hab_status reports "No HAB Events Found!" on this board with my normal HAB-signed imx-boot. I recently added kernel FIT image signing + AES-256 encryption (a separate mechanism from HAB — U-Boot's own bootm verifying/decrypting a signed kernel FIT, keys embedded in u-boot.dtb, unrelated to SRK fuses). After enabling this, hab_status started reporting 4 events every boot: HAB Configuration: 0xf0, HAB State: 0x66 HAB Event 1: STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB Event 2: STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB Event 3: STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HAB Event 4: STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY I methodically bisected this with isolated rebuild+reflash tests, one variable at a time, confirmed on real hardware: 1. Baseline (existing HAB-signed imx-boot, no kernel-FIT work): 0 events 2. Full kernel-FIT feature enabled (FIT pubkey/AES-key DTB embedding + my own cmd/bootm.c patch + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000): 4 events 3. Disabled FIT pubkey/AES-key DTB embedding alone: events still present, identical 4. Also removed my cmd/bootm.c patch: events still present, identical 5. Removed CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000 entirely (true pre-kernel-FIT baseline): 0 events, clean 6. Added back only CONFIG_SYS_BOOTM_LEN=0x8000000 (no CONFIG_FIT_CIPHER): 0 events, clean The issue is isolated precisely to CONFIG_FIT_CIPHER=y — nothing else (my bootm.c patch, FIT pubkey/AES-key DTB embedding, CONFIG_SYS_BOOTM_LEN) matters alone or combined; only CONFIG_FIT_CIPHER=y flips hab_status from 0 events to these 4. I double-checked that my own CSF computation is not the problem: my build-time signing task verifies the CSF tag byte at both embed offsets immediately after signing and fails the build on any mismatch — every build, with or without CONFIG_FIT_CIPHER, passes cleanly, and the computed SLD hab block address/FIT CSF offset are byte-identical across all test builds regardless of this config. My best guess is CAAM Job Ring contention — CONFIG_FIT_CIPHER pulls in CONFIG_AES (no separate backend symbol needed on this U-Boot version), and this SoC's runtime dmesg confirms CAAM is genuinely used for AES/SHA elsewhere. The closest relevant documentation I found is doc/imx/habv4/guides/mx8m_secure_boot.txt's note about HAB pre-v4.4.0 locking Job Ring/DECO master ID registers in closed config, but that doesn't directly describe this OPEN-mode, CONFIG_FIT_CIPHER-specific case. Questions: 1. Is this a known interaction between CONFIG_FIT_CIPHER and HABv4 CSF authentication on i.MX8M Plus? Is it CAAM-resource-related, or something else (e.g., compiled binary size/layout shifting a FIT CSF component boundary in a way my own self-check doesn't catch, since it verifies against the offset I computed, not what the ROM independently derives)? 2. Is CONFIG_FIT_CIPHER known-safe to combine with HABv4 CSF signing on this SoC at all, or is this a real limitation? 3. Are there any pointers to the correct CAAM Job Ring allocation/unlock sequence if that turns out to be the root cause? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status Posting this as solved in case it saves someone else the bisection — credit to [https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756] for the actual fix, which applied directly once I found it. Symptom: clean baseline (hab_status reports "No HAB Events Found!") with our normal HAB-signed imx-boot. After enabling CONFIG_FIT_CIPHER=y (to support U-Boot decrypting an AES-256-encrypted kernel FIT image — a separate mechanism from HAB, unrelated to SRK fuses), hab_status started reporting 4 events every boot: 2× HAB_INV_ASSERTION, 2× HAB_INV_SIGNATURE. Bisection: isolated every variable we'd changed, one at a time, rebuild+reflash+hab_status on real hardware each time — down to CONFIG_FIT_CIPHER=y alone (disabling FIT pubkey/AES-key DTB embedding, removing an unrelated cmd/bootm.c patch, keeping/dropping CONFIG_SYS_BOOTM_LEN — none of those mattered; only CONFIG_FIT_CIPHER did). Root cause + fix: we build imx-boot via a custom Yocto task porting the manual HAB-signing workflow (parse SPL IVT, compute FIT component blocks via print_fit_hab.sh, sign with CST) into an automatic build step. That task assumed the DTB copy left in the build staging dir by mkimage_imx8's own build was already correctly 16-byte-aligned — not guaranteed for every config. CONFIG_FIT_CIPHER changes U-Boot proper's compiled DTB size, landing it on a non-aligned size in our case. A misaligned DTB silently shifts every subsequent FIT component boundary print_fit_hab.sh computes,so CST signs the wrong byte range. Our own build-time self-check (CSF tag byte present at the offset we computed) still passed cleanly every time — it wasn't checking against the ROM's independently correct notion of the boundary. Only real hardware caught it. Fix, mirroring what worked in the other thread: explicitly run pad_image.sh (imx-mkimage's own script) on the DTB immediately before computing FIT component blocks, rather than trusting the staging directory's existing state. Confirmed genuinely padded (not a no-op), and hab_status is clean again with the full feature enabled.
View full article
TDA8954TH 音声出力なし こんにちは! 低音が出ないスピーカー(Mackie Thump12など)をいくつか持っています。出力ICのTDA8954THと10Ωの抵抗器を交換しました。全く音がしない。このICで他に問題が発生している方はいらっしゃいますか? 私はAliExpressで異なる販売者から3つのICを注文しました。 よろしくお願いいたします。 ヨハネス Re: TDA8954TH no sound output こんにちは、ヨハネスさん。 このTDA8954THは旧製品であり、現在は生産中でなく、技術サポートも提供していません。もしかしたら、使っている他の方が助けてくれるかもしれません。   BRs、トーマス
View full article
LPC55s28 PN5190 NFC Read Library porting Hello Community, hello NXP-Team I'm looking for LPC55S28 ↔ PN5190 connection details (Host SW + DAL / BAL layer) I already have the PN5190 NFC Reader Library and would like to connect the LPC55S28 MCU to the PN5190 NFC frontend. I have reviewed the article “Using NFC Reader Library with LPC55S69”, but I am looking specifically for an LPC55S28‑compatible setup. Questions Is there an existing DAL/BAL (Driver Abstraction Layer) implementation for connecting the LPC55S28 to the PN5190? Has anyone successfully connected LPC55xx (LPC55S16 / LPC55S28 / LPC55S69) to a PN5190 using the NFC Reader Library? Is there a ready solution, reference project, or recommended starting point for the LPC55S28 + PN5190 combination? If not, is the LPC55S69 guide the correct and closest reference to follow for porting? Thank you! Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora, Thank you for your response. The guides you referenced are already much more helpful than what I initially found on the NXP website, so thank you for pointing them out. While reviewing these guides, I noticed that many of them include preconfigured folders or ready-to-use packages for specific processors or boards. These packages typically integrate the NFC Reader Library together with the control processor setup and, in some cases, DiscoveryLoop examples, which makes it much easier to get started. Would it be possible to provide a similar reference package or project (for example, importable into MCUXpresso) for the LPC55S28 + PN5190 combination, or at least for the closest supported LPC55xx configuration? Having such a project as a starting point would be extremely helpful for porting and validation. Thank you in advance for your support. Best regards, Radoslaw Tomasik Re: LPC55s28 PN5190 NFC Read Library porting Hello @RadoslawTomasik My apologies, there is no specific documentation or guide for PN5190 + LPC55S28. However, as you mention, you can refer to the following guides: - Using NFC Reader Library with LPC55S69 - NFC Reader Library Porting FRDM_K64F - NFC Reader Library Porting to i.MX RT1050 - NXP Community Those guides can be a good starting point. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting Hi, Unfortunately, there is no reference project for this specific setup. The NFC Reader Library for PN5190 includes support for LPC1769 and Kinetis K82; support for any other Host MCU must be implemented by the user. When you mention that linking the NFC Reader Libraries is no longer possible, does it mean that you are getting an error message when trying to link the folders? What is the procedure you are following? You should be able to link the folder by following the steps listed in NFC Reader Library Porting FRDM_K64F, "Link the NFC Reader Library" section. Also, linked resources should appear in Project Properties > Resource > Linked Resources. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting @EduardoZamora  When following the guide below: https://community.nxp.com/t5/NFC-Knowledge-Base/NFC-Reader-Library-Porting-FRDM-K64F/ta-p/1117798 I am able to successfully perform the described steps: Add the NFC Reader Libraries Create a project for LPC55Sxx Copy the DiscoveryLoop files into the LPC project However, when performing the same steps for PN5190 (using NxpNfcRdLib_PN5190_v07.14.00_Pub), I am able to: Add the libraries Create the LPC55Sxx project but when attempting to copy the DiscoveryLoop files, I encounter the following error: Problem occurred while copying resources. Cannot create linked resource. Could you please check this on your side and let me know whether this is a known limitation, or if there is a recommended workaround for PN5190 with LPC55Sxx? Thank you for your support. Best regards, Radoslaw Tomasik Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora , As a follow-up, I found that the original “Cannot create linked resource” error was caused by an excessively long file path. After shortening the path, this specific issue was resolved. However, a related problem still persists when adding the NFC Reader Libraries to the workspace with the “Copy projects into workspace” option enabled (see attached screenshot). Several documents (e.g. AN13425) explicitly recommend not selecting this option. When I follow this recommendation, copying the DiscoveryLoop files into the LPC55Sxx project works correctly. The downside is that, in this case, linking the NFC Reader Libraries is no longer possible, because the workspace does not contain any NFC example projects. As a result, it is not possible to link the following folders from NfcrdlibEx1_BasicDiscoveryLoop into the lpc55sxx_basic_discovery_loop project: DAL NxpNfcRdLib phOsal intfs Could you please advise whether this is a known limitation for PN5190 with LPC55Sxx, or if there is a recommended workaround? Also, is a preconfigured LPC55Sxx + PN5190 project available, similar to those referenced in other NFC Reader Library guides? Best regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hi, Could you please kindly clarify what you mean with "the DAL and intfs folders are part of the DiscoveryLoop example and cannot be linked independently"? You should not face any restriction when trying to link these folders to your project. You can either copy the folders to the workspace and link them or link the folders directly from the path where the Library was extracted; how they are shown in the project structure may depend on the method used. Relevant paths that need to be included are shown in "Add include paths" section from NFC Reader Library Porting FRDM_K64F after linking the folders. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora , thank you for your reply and for the clarification. I understand that there is no reference project for the LPC55S28 + PN5190 combination, and I am prepared to implement the SPI DAL myself. My intention is to follow the NFC Reader Library Porting FRDM_K64F procedure as closely as possible, but I am encountering some differences when working with the PN5190 package. Here is the current status and the open questions: Importing an LPC55S28 SDK example (e.g. hello_world) works without any issues. Link the NFC Reader Library: The NxpNfcRdLib and phOsal folders can be linked to the LPC55S28 project and are visible under Project Properties → Resource → Linked Resources. However, these linked folders do not appear in the project structure as shown in the porting guide. The DAL and intfs folders are part of the DiscoveryLoop example and cannot be linked independently. Should these folders be copied from the DiscoveryLoop project into the LPC55S28 project instead of being linked? If so, which parts are considered platform-specific and expected to be modified by the user? Include paths can be configured manually, but it is unclear: Which include directories should be taken from the NxpNfcRdLib / phOsal libraries Which ones should come from the DiscoveryLoop example Since the libraries differ depending on the host MCU, and the integration procedure seems to vary from project to project, I would appreciate your guidance on the recommended setup for this configuration. This is fully within NXP platforms; I already have both evaluation boards connected and would like to proceed with basic driver and connection tests. Best regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hi Eduardo, thank you for your reply. To clarify what I meant: the issue is how the DiscoveryLoop example project is structured and imported. When importing the DiscoveryLoop project into MCUXpresso, it cannot be added to the workspace using the “Copy files into workspace” option. As a result, the project remains outside the MCU workspace directory and the DAL and intfs folders are therefore not visible within the workspace file system. Because of this, they cannot be linked independently in a practical way, as described in the FRDM_K64F porting guide. Due to this, I proceeded with a manual port: Copied the required DAL, intfs, NxpNfcRdLib, and phOsal folders directly into the LPC55S28 project so that they are fully visible in the project structure. Manually added all required include paths, preprocessor symbols, and source locations. Modified the DAL implementation to match the LPC55S16/LPC55S28 platform (SPI, GPIO, IRQ handling, timing, etc.). With this approach, the project builds and the structure is now consistent and transparent inside the MCU workspace. Regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hello, Thank you for your reply! It's greatly appreciated. I'm using the LPC55S69-EVK  + PNEV5190BP. I have downloaded the latest NxpNfcRdLib (NxpNfcRdLib_PN5190_v07.16.00_PUB) and SDK (SDK_26_06_00_LPCXpresso55S69) from the website. At first I imported the DiscoveryLoop example from the NxpNfcLib made for the K82F microcontroller. This was not a great success because there are a lot of micrcocontroller specific settings that were interfering with that process.  I then found the LPC porting guide mentioned earlier in this thread. This was also not a success because the SDK and Nfc lib versions were basically too old to properly use. I then did what you already mentioned. I imported the lpcxpresso55s69_lpc_gpio_led_output_cm33_core0 example from the newest SDK and added the DAL, intfs, NxpNfcRdLib, and phOsal folders directly to the project. Then I configured the paths, preprocessor and source locations. The I added the missing SDK components. I tried to modify the DAL but because there were quite a few differences between the DAL that worked for the old Nfc lib and the new lib I was not able to pull this off. It actually compiles but it gets stuck in the hardfault handler on the SPI_MasterInit function caled bij phbalReg_Init().  I think this is mostly because I'm quite new to using NXP products. I'll include a zip file of the project. Maybe there are things that I did wrong or maybe I missed something. Re: LPC55s28 PN5190 NFC Read Library porting Hello, Were you able to figure out how the library can be ported? I keep getting stuck at rewriting the DAL because the SDK and NFC-library structure were changed quite significantly. I tried to base my code of off this guide with included source code . However this NFC-library version does not include the PN5190 drivers. When the PN5190 was added quite a few significant changes were added to the library which causes a lot of errors when I tried to just replace the NfcRdLib, phOsal and intfs folders. I also ran into a couple of errors that were caused by the newer SDK version so I basically don't really know what to do now. Especially because the recommended guides 1 & 2 are not up-to-date anymore. Thanks in advance!  Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, Are you using the same hardware combination (LPC55xx + PN5190)? Basically, you can use the existing porting guides as a reference, even though there is no official LPC55S28 + PN5190 project. I would recommend downloading the latest NxpNfcRdLib_PN5190 package and importing it into MCUXpresso. As a starting point, create a new project from an LPC55xx SDK example (for example, hello_world) and port the NFC Reader Library manually. The approach that worked for me was: Copy the DAL, intfs, NxpNfcRdLib, and phOsal folders directly into the LPC55S28 project so everything is part of the project structure. Manually configure all required include paths, preprocessor symbols, and source locations. Rewrite the DAL for the LPC55xx platform (SPI, GPIO, IRQ handling, timing, etc.). Enable any missing MCU drivers through Manage SDK Components in MCUXpresso and adapt the DAL to use those drivers. Regarding the drivers you mentioned as missing: which ones are they exactly? If you can list the missing modules or post the compiler errors, it will be much easier to identify what still needs to be ported. The errors caused by the newer SDK may also depend on the exact LPC device and SDK version you're using. I would first verify that you're using the latest SDK available for your MCU from NXP and make sure it matches the version expected by your project. From your description I can only make an educated guess, but if you can share: the exact LPC55xx device, the SDK version, the NFC Reader Library version, and a few of the compilation errors, I'd be happy to help identify the required changes. I went through a similar manual port, so I may be able to point you in the right direction. I hope this helps you move a bit further. Re: LPC55s28 PN5190 NFC Read Library porting EDIT: I managed to "fix" this error by adding uint32_t flags instead of void to the definitions of PH_DRIVER_LPC_TIMER_IRQ_HANDLER. Still doesn't work though Re: LPC55s28 PN5190 NFC Read Library porting Thank you very much. I'm not entirely sure how I should configure the pin_mux and clocks. I did it via the pin configuration tool though but I'm not sure if I have done it correctly. But I also don't quite understand why I would have to do it like this because these settings seem to be overwritten in the phbalReg_LpcOpenSpi.c file anyway.  I did find out that in phbalReg_Init(), I think it was, I needed to change the way the clock frequency was selected because this had been changed some time ago.  I then was able to compile and download the code to the microcontroller. However, nothing works except the debug text :(. I took a look at your code however, I ran into more problems. The library version I have expects the interrupt handler to be like this: PH_DRIVER_LPC_TIMER_IRQ_HANDLER(uint32_t flags); while literally every example I have found thus far uses your define: PH_DRIVER_LPC_TIMER_IRQ_HANDLER(void); This results in the following error:  ../DAL/src/LPCOpen/phDriver_LPCOpen.c:42:47: error: initialization of 'void (*)(uint32_t)' {aka 'void (*)(unsigned int)'} from incompatible pointer type 'void (*)(void)' [-Wincompatible-pointer-types] 42 | ctimer_callback_t ctimer_callback_table[] = { PH_DRIVER_LPC_TIMER_IRQ_HANDLER, NULL, NULL, NULL, NULL, NULL, NULL, NULL}; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your help has been very helpful thus far. Would it be possible to include the phDriver_LPCOpen.c file or a zip of the entire project? Thanks in advance! Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, From your description, the first thing I would double-check is your pin configuration (pin_mux) and verify that the correct Flexcomm instance is configured for SPI. A mismatch there can easily cause the code to end up in the HardFault handler during SPI_MasterInit(). Additionally, make sure that the spi_master_config structure is properly initialized before calling SPI_MasterInit(). It's also worth reviewing the Exchange function to ensure that both the WRITE and READ phases are implemented correctly, as the newer Reader Library expects slightly different behavior than the older versions. I've attached my files for reference. They may help you compare your implementation with a working example, but I can't guarantee they'll work without modification since they were created for a different setup. Hopefully this points you in the right direction. Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, Yes, you need to configure the ports using the MCUXpresso Config Tools (Pins/Clock Configurator). The DAL assumes that the MCU peripherals are configured correctly, so those settings are not completely replaced by phbalReg_LpcOpenSpi.c. I've attached my pin_mux files and the LPCOpen sources for reference. Please keep in mind that this is reference code only. The project was never fully tested or finalized, so I can't guarantee it will work out of the box. I think there's still quite a bit of debugging ahead before everything works correctly. Unfortunately, I won't be available for about the next two weeks, so I probably won't be able to respond to any further questions until then. Good luck with the porting, and I hope the attached files help you move forward.
View full article
无法为 i.MX95 Neutron NPU 编译 YOLOv8/YOLO11 TFLite 模型 您好,NXP支持团队, 我们正在使用Neutron SDK v3.1.3在FRDM i.MX95平台上评估目标检测功能。并且无法生成与 NPU 兼容的模型。Neutron 变流器成功加载了模型,但报告称0 个算子映射到 Neutron NPU 。 环境 目标板:FRDM i.MX95 Neutron SDK:3.1.3 Ultralytics:已使用 YOLO11 和 YOLOv8 进行测试 eIQ 工具包:用于 ONNX 到 TFLite 的转换 型号:定制单类钉子检测器 训练司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 导出命令 $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml 我们还测试了另一种工作流程: 导出 PyTorch → ONNX 使用 NXP eIQ 工具包将 ONNX 转换为 INT8 TFLite 使用 Neutron SDK 编译时,两种工作流程都产生了相同的结果。   中子汇编 〜/下载/eiq-neutron-sdk-linux-3.1.3/bin/neutron-变流器--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   变流器输出 变流器报告: 导入后运算符:341 优化后的运算符数:367 已转换运算符:0 操作员转换率:0 / 367 中子图数量:0 警告: 警告:图中所有运算符均未映射到 Neutron。 警告:转换后的模型与输入模型相同,因为没有将任何算符映射到 Neutron。 警告:图表中包含不支持的 FLOAT 运算符!这会导致转化率低。 更多信息 我们观察到以下情况也存在同样的现象: YOLO11 YOLOv8 直接 Ultralytics TFLite 导出 ONNX → eIQ 工具包 → INT8 TFLite 所有生成的 TFLite 模型都导致 Neutron 编译器映射 0 个算符。 问题 Neutron 编译器是否正式支持 i.MX95 的 YOLOv8 或 YOLO11 目标检测模型? 对于目标平台为 i.MX95 NPU 的 YOLO 模型,是否有推荐的导出流程? 当前 Neutron SDK (v3.1.3) 是否存在任何已知限制?关于YOLO检测头? NXP 是否提供可在 i.MX95 NPU 上成功编译的 YOLOv8/YOLO11 参考模型? 启用运算符映射是否需要额外的编译器选项或预处理步骤? 我们非常希望获得任何与 i.MX95 Neutron NPU 兼容的指导、推荐工作流程或参考模型。 谢谢! Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 谢谢你的回复。​​ 我想咨询一下是否有标准程序可用于在IM X95板上进行模型的训练、导出和部署。​​​​​​​​​​​ 由于我们目前拥有ARA2 ,我们正在寻求充分利用其功能并定制我们的模型。我们将在NXP技术日上进行演示,如果您能在这方面提供帮助,我们将不胜感激。​​​​​​​​​​​ 感谢您的帮助。​​ Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在 imx95 主板上尝试了 eIQ 模型库中的 yolo8m 模型,使用了 LF 2026 Q2 版本镜像。内核版本为 6.18.20,使用 Neutron SDK 3.1.2,运行正常。     您可以先尝试以下方法: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so 更多信息请参阅 README 文件eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo 此外,您还可以附加转换/编译的模型和详细日志。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 根据变流器日志,首先要解决的问题是生成的 TFLite 模型仍然包含 FLOAT 运算符: 警告:图表中包含不受支持的浮点运算符! 对于 i.MX95 Neutron,中子变流器的输入必须是 TFLite 模型,其算符和量化格式与 Neutron 编译器兼容。具体来说,i.MX95 中子流需要量化的 TFLite 和对称的 int8 权重。如果模型在 Ultralytics 导出或 ONNX 到 TFLite 转换后仍然包含 FLOAT 运算符/张量,则变流器可能无法创建任何 Neutron 兼容的子图,这与报告的结果一致: 已转换运算符:0 中子图数量:0 YOLOv8 已在 i.MX95 上进行过一些流程的评估,但对于任意 Ultralytics 导出,不应假定完全端到端的 YOLOv8/YOLO11 卸载。根据导出的 TFLite 图,模型可能只有一部分会转换为 NeutronGraph,而不支持的操作符将保留在 CPU 上。因此,建议的下一步是检查/分析生成的 TFLite 模型并确认: 该图已完全量化。 没有浮动操作商。 权重是对称的int8, 输入/输出张量类型兼容,或者如果适用,可以使用 Neutron 变流器 uint8 到 int8 选项进行转换。 除非 SDK 确认支持确切的操作符,否则 YOLO 后处理(例如解码/NMS)将保留在 NPU 图之外。 另外,请确保板上的 Neutron 变流器版本和 Neutron 运行时/固件/委托来自同一个兼容的 SDK/电路板支持包 版本。 建议采用 NXP/eIQ 转换路径: PyTorch -> ONNX(静态输入形状) -> NXP/eIQ 量化(使用代表性校准数据) -> 量化后的 TFLite -> 中子变流器 --target imx95 如果模型具有 uint8 输入/输出张量,请同时进行以下测试: --将输入的 uint8 转换为 int8 --convert-outputs-uint8-to-int8 如果移除浮点运算符后,转换结果仍然显示 0 个已映射运算符,请分享: - 完整的 中子变流器 日志,如有详细/分析输出,请提供。 - TFLite 操作员列表, - 张量数据类型和量化参数, - FRDM i.MX95 板上确切的 电路板支持包/运行时 Neutron 代理/固件版本, - YOLO 检测头是否包含 NMS 或 TFLite 图中的其他后处理。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 在我的测试中,我没有自己训练或导出模型。我使用了 eIQ 模型库中预先生成的 YOLOv8 模型,并验证了它在 i.MX95 平台上运行。 我实际使用的唯一命令是: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 以该模型为例: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite 对于定制模型,NXP 推荐的流程如下: PyTorch ↓ ONNX(静态输入形状) ↓ eIQ 工具包 ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ 量化 TFLite ↓ 中子变流器 --target imx95 由于您的模型报告: 纯文本 已转换运算符:0 中子图数量:0 警告:图表中包含不支持的 FLOAT 运算符! 我怀疑您生成的 TFLite 图在结构上与 eIQ 模型库参考模型不同。我首先建议做的是比较这两个型号的以下方面: 输入/输出张量类型(INT8 与 UINT8) 浮式经营者的存在 图内的解码/NMS层 Netron/TFLite 分析器报告的运营商列表 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 你好 我运行的是 ubuntu 24.04,但是 eiq_toolkit 仅适用于 20.04.03 版本。 如何使用 eiqToolkit 和使用 eIQ Toolkit 进行量化 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 请问您是如何将 yolov8m_full_integer_quant.tflite 转换为能够在 imx95 NPU 上运行的? 以下步骤和环境设置数据(主机)将对我们非常有帮助。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推荐的端到端工作流程 模型训练(PC) 使用您偏好的框架进行训练: Ultralytics YOLOv8 PyTorch Tensorflow ONNX原生工作流 对于目标检测,NXP 已经在 eIQ 模型库中提供了 YOLO 参考配方,包括 YOLOv8 目标检测模型。[github.com] ,[github.com] 示例: shell yolo 检测训练 \ model=yolov8n.pt \ data=dataset.yaml imgsz=640 \ epochs=100 ` 导出到 ONNX NXP 通常建议在量化和部署之前使用 ONNX 作为交换格式。 yolo 导出 \ model=best.pt \ format=onnx Neutron 启用演示文稿明确描述了基于以下流程的说明: 纯文本 PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ 中子变流器 而不是直接从训练工件中寻找部署目标。 使用 eIQ 工具包进行量化 Neutron 工作流程文档建议使用 eIQ Toolkit 量化工具: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c 输入:: `` 其次是: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite 显示更多行 该流程在 i.MX95 Neutron 实现材料中有明确记录。 为 i.MX95 Neutron NPU 编译 中子变流器 --target imx95 \ --输入 model_int8.tflite \ --输出 model_neutron.tflite Neutron 变流器创建 Neutron 特有的图分区,这些分区可以卸载到 NPU 上。 验证转化率 NPU 部署成功后,应报告类似以下内容: 转换的操作员数量 > 0 中子图数量 > 0 如果你看到: 已转换运算符:0 中子图数量:0 那么该模型就没有被NPU加速。 你目前的问题就属于这一类。 部署在 FRDM-i.MX95 上 使用 TensorFlow Lite 和 Neutron 委托运行: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` 或 ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX 机器学习用户指南将Neutron Delegate定义为 i.MX95 TensorFlow Lite 模型的加速机制。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于 eIQ Toolkit 已在 Ubuntu 20.04 上验证过,因此最安全的方法是: Docker 在 Ubuntu 24.04 主机上运行 Ubuntu 20.04 容器: docker run -it --name eiq \ ubuntu:20.04 /bin/bash 然后,在容器内安装所需的依赖项和 eIQ Toolkit。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 使用 eIQ Toolkit (onnx2quant) 转换自定义 YOLOv8 ONNX 模型时,无法保留置信度输出。 概述 NXP团队您好, 我正在尝试使用 eIQ Toolkit 在 FRDM i.MX95 上部署自定义 YOLOv8 单类目标检测模型。 整个转换流程运行成功,但在 onnx2quant 之后,置信度输出全部变为零,而边界框输出仍然有效。 环境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX 运行时 1.21.1 - TensorFlow 2.21 - 中子变流器 3.1.3 - 目标:FRDM i.MX95(tflite_runtime 2.19 + Neutron delegate) 转换管道 1. 火车 yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. 导出 ONNX yolo export model=best.pt format=onnx opset=13 3. 验证 ONNX 输入:(1,3,640,640) 输出:(1,5,8400) ONNX 运行时推理: 置信度通道最大值 = 0.773 4. 生成校准数据集 形状:(1,3,640,640) 数据类型:float32 范围:0.0 - 1.0 5. 量化 onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx 同时测试了: onnx2quant 最佳.onnx -u 两者产生的结果相同。 6. 验证量化的 ONNX 输出:(1,5,8400) 边界框通道仍然有效。 信心: 最小值 = 0 最大值 = 0 平均值 = 0 解码检测结果 = 0 7. 转换为 TFLite 格式 onnx2tflite best_quant.onnx -o best.tflite 8. 为 Neutron 编译 neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite 编译成功。 操作员转化率:278 / 325 (85.5%) 已展开调查 已核实: • PyTorch 模型有效 • ONNX 导出工作 • ONNX 运行时推理功能正常 • 校准数据集正确 • 真实校准和随机校准产生相同的结果 • TFLite 重现量化的 ONNX 输出 • Neutron 可以重现 TFLite 的输出 该问题首次出现于以下情况: ONNX ↓ onnx2quant ↓ 量化 ONNX(置信度变为零) 补充观察 恩智浦参考模型: 输入:(1,640,640,3) INT8 输出:(1,84,8400) INT8 我转换后的模型: 输入:(1,3,640,640) FLOAT32 输出:(1,5,8400) FLOAT32 对于自定义 YOLOv8 模型,是否有推荐的导出或量化工作流程,能够保留置信度输出? 对于输出为 (1,5,8400) 的模型,这可能是 onnx2quant 的一个限制或错误吗? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 与AE团队讨论。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240 的端到端性能是否已经过评估?数据手册中提到了两个矢量核心,可以执行诸如 sigmoid 和 NMS 之类的后处理操作。编译器能否将 NMS 操作映射到向量核心? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 抱歉耽搁了。我正在尝试重现转换工作流程。 现在有一个问题,为什么转换后的模型的数据类型是 FLOAT32?你试过转换成 INT8 类型吗?Neutron NPU 需要 INT8 类型作为输入数据。我在其他模型转换中也遇到过类似的错误,根本原因是数据类型错误。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 由于对 YOLOv8 的输出张量应用了完全 INT8 量化( inference_output_type=tf.int8 )这一根本限制,置信度输出丢失了。 YOLOv8 将边界框坐标和置信度分数打包成形状为 (1, 5, 8400) 的单个输出张量。bbox 值具有较大的动态范围(~640 像素),而置信度得分在 ~0 到 1 的范围内。当整个输出张量共享一个量化尺度时,该尺度主要由较大的边界框值(~640)构成,只剩下一个整数级别的一小部分来表示整个置信范围(~1)。因此,经过 INT8 量化后,所有置信值实际上都被四舍五入为零。 推荐解决方案 而不是通过  onnx2quant ,直接从您训练好的数据中导出 INT8 TFLite。  .pt  使用 Ultralytics 建模,然后将其输入到  neutron-变流器 : # 直接导出 INT8 TFLite 数据(校准使用您的训练数据集) yolo export model=best.pt \ format=liter \ imgsz=640 \ 量化=8 data=dataset.yaml 分数=0.1 #为Neutron 编译(未更改) neutron-变流器 --target imx95 --input best_int8.tflite --output best_neutron.tflite 请确保输入和输出数据类型为 np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale, inp_zp = inp_d[ "量化" ] out_d = out_ds[0] out_scale, out_zp = out_d[ "量化" ] print(f " 输入数据类型={inp_d['dtype']} 形状={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 输出 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 根据形状确定输入格式 in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] 或 [1,640,640,3] 如果in_shape[1] == 3: # NCHW src=img_nchw 别的: # NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ “索引” ],src_int8) 别的: interp.set_tensor(inp_d[ “索引” ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# 如果 out_d[ "dtype" ] == np.int8,则可能是 int8 或 float32: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale 别的: dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 归一化 # 将边界框重新缩放回像素坐标以便显示 BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 您好,我尝试了您分享的命令…… 但是中子变流器无法转换模型…… 请查收附件日志,供您参考,引用。
View full article
LX2160A get MP key failed Hi NXP, We are building LX2160A secure boot system based on LLDP and verifying MP key function. Install and start up the secure boot system on our LX2160A board are OK and so we think ITS bit value is 1, but get "Device is not initiated" error after execute "mp_app -p" command. Do you have any advice to check this issue ? Thank you, Jeffrey  Re: LX2160A get MP key failed Did customer follow LLDP document section 6.4.4?   Such as Run tee-supplicant & command from the Linux prompt. Depending on the Linux kernel version used insmod securekeydev.ko from right folder Please also let customer enable kernel printk when run 'mp_app', and share their log. echo 8 > /proc/sys/kernel/printk dmesg Re: LX2160A get MP key failed Hi yipingwang, Yes, we start tee-supplicant and load securekeydev.ko before execute mp_app command. The following is dmesg information. Jeffrey Re: LX2160A get MP key failed Please refer to the following update from the AE team. From customer's feedback, I can see "error: caam_submit_mp_get_pub_key_op: submit_job", it indicates send job to SEC failed. Please ask customer do below test in their Linux system, 1. run xtest, to see any error report? 2. please run "modprobe caam" to install caam module for LX2160, if install module failed, please update modules compatible with your kernel version. 3. If also report error, apply below patch to check SEC return result to identify the error type, and share their full log. diff --git a/securekeydev/securekey_caam.c b/securekeydev/securekey_caam.c index b82acd3..d657742 100644 --- a/securekeydev/securekey_caam.c +++ b/securekeydev/securekey_caam.c @@ -59,12 +59,14 @@ static int submit_job(struct device *jrdev, uint32_t *desc) /* Call caam_jr_enqueue function for Enqueue a job descriptor head. */ ret = caam_jr_enqueue(jrdev, desc, caam_op_done, NULL); + pr_err("caam_jr_enqueue ret (%d)\n", ret); if (!ret) wait_for_completion_interruptible(&comp); else return ret; ret = job_comp_status; + pr_err("job_comp_status ret (%d)\n", ret); return ret; } Regards, Re: LX2160A get MP key failed About your comments, 1. run xtest, to see any error report? Please refer to attached xtest log. 2. please run "modprobe caam" to install caam module for LX2160, if install module failed, please update modules compatible with your kernel version. We built caam module in kernel already. 3. If also report error, apply below patch to check SEC return result to identify the error type, and share their full log. The dmesg about caam and mp_app return as below.   Thank you. Re: LX2160A get MP key failed 1. Please make sure caam job ring work well in Linux kernel, please run below command to check caam jr interrupt increase or not root@localhost:~# cat /proc/interrupts | grep jr 378: 41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 172 Level 8010000.jr 379: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 173 Level 8020000.jr 380: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 174 Level fsl-jr0 root@localhost:~# root@localhost:~# root@localhost:~# dd if=/dev/hwrng of=/tmp/random.dat bs=1 count=16 16+0 records in 16+0 records out 16 bytes copied, 0.000420759 s, 38.0 kB/s root@localhost:~# root@localhost:~# root@localhost:~# cat /proc/interrupts | grep jr 378: 42 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 172 Level 8010000.jr 379: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 173 Level 8020000.jr 380: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 174 Level fsl-jr0 root@localhost:~# 2. In submit_job() the called function caam_jr_enqueue() return (-EINPROGRESS = -115) on success. Please try apply below patch to check caam enqueue return result. https://github.com/nxp-qoriq/linux/commit/4d370a1036958d7df9f1492c345b4984a4eba7f6#diff-8acc41c534456288daba59a125ddb3f779635dc493ff4888545adbf1dd0a17c1R327 diff --git a/securekeydev/securekey_caam.c b/securekeydev/securekey_caam.c index b82acd3..808e8da 100644 --- a/securekeydev/securekey_caam.c +++ b/securekeydev/securekey_caam.c @@ -59,12 +59,14 @@ static int submit_job(struct device *jrdev, uint32_t *desc) /* Call caam_jr_enqueue function for Enqueue a job descriptor head. */ ret = caam_jr_enqueue(jrdev, desc, caam_op_done, NULL); - if (!ret) + pr_err("caam_jr_enqueue ret (%d)\n", ret); + if (ret == -EINPROGRESS) wait_for_completion_interruptible(&comp); else return ret; ret = job_comp_status; + pr_err("job_comp_status ret (%d)\n", ret); return ret; } Re: LX2160A get MP key failed 1. Please make sure caam job ring work well in Linux kernel, please run below command to check caam jr interrupt increase or not Ans: Yes 2. In submit_job() the called function caam_jr_enqueue() return (-EINPROGRESS = -115) on success. Please try apply below patch to check caam enqueue return result. Ans: Our system uses Linux kernel v5.15.71-rt51 and it seems need not do any additional patches. 3. In addition, after run mp_app -p command, the process stops at wait_for_completion_interruptible() and it is waiting the return so far.    
View full article
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.     You can try it firstly by: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Sorry for the delay. I am trying to reproduce the conversion workflow.  One question for now, why the converted model's data type is FLOAT32? Have you tried to convert to INT8? The Neutron NPU requires the INT8 type as input data. I met the similar error on other models conversion and the root cause is the data type. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU The confidence output is lost due to a fundamental limitation of full INT8 quantization ( inference_output_type=tf.int8 ) applied to YOLOv8's output tensor. YOLOv8 packs bounding box coordinates and confidence scores into a single output tensor of shape  (1, 5, 8400) . The bbox values have a large dynamic range (~640 pixels), while the confidence scores are in the range of ~0 to 1. When the entire output tensor shares a single quantization scale, that scale is dominated by the large bbox values (~640), leaving only a fraction of one integer level to represent the entire confidence range (~1). As a result, all confidence values are effectively rounded to zero after INT8 quantization. Recommended Solution Instead of going through  onnx2quant , export INT8 TFLite directly from your trained  .pt  model using Ultralytics, then feed it into  neutron-converter : # Export INT8 TFLite directly (calibration uses your training dataset) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # Compile for Neutron (unchanged) neutron-converter --target imx95 --input best_int8.tflite --output best_neutron.tflite For the input and output data type, please ensure they are np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors() inp_d  = interp.get_input_details()[0] out_ds = interp.get_output_details() inp_scale, inp_zp = inp_d["quantization"] out_d = out_ds[0] out_scale, out_zp = out_d["quantization"] print(f"  Input  dtype={inp_d['dtype']}  shape={inp_d['shape'].tolist()}"       f"  quant=(scale={inp_scale:.6f}, zp={inp_zp})") print(f"  Output dtype={out_d['dtype']}  shape={out_d['shape'].tolist()}"       f"  quant=(scale={out_scale:.6f}, zp={out_zp})")# Determine input format from shape in_shape = inp_d["shape"].tolist()   # [1,3,640,640] or [1,640,640,3] if in_shape[1] == 3:     # NCHW     src=img_nchw else:     # NHWC     src=img_nhwcif inp_d["dtype"] == np.int8:     src_int8 = np.clip(np.round(src / inp_scale + inp_zp), -128, 127).astype(np.int8)     interp.set_tensor(inp_d["index"], src_int8) else:     interp.set_tensor(inp_d["index"], src.astype(np.float32))interp.invoke() raw_out = interp.get_tensor(out_d["index"])  # may be int8 or float32if out_d["dtype"] == np.int8:     dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale else:     dq_out = raw_out.astype(np.float32)dq_out = dq_out[0]   # (5, 8400) normalized# Rescale bbox back to pixel coords for display BBOX_SCALE = 640.0 tfl_bbox = dq_out[:4] * BBOX_SCALE   # (4, 8400) tfl_conf = dq_out[4]                  # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi Tried the commands you shared... But neutron-converter is failing to convert the model... please find the log attached for your reference
View full article
Kinetis MCX Wxx(MCX W71/72 和 MCX W23)工业物联网电源我的工具 本页面专用于 Kinetis MCX Wx(MCX W71/72 和 MCX W23)工业物联网电源我的工具。 它将帮助您估算应用(汽车、工业物联网、追踪器/标签和连续血糖监测 [CGM])中的功耗,并评估解决方案的电池寿命。 此页面包含 4 个专用的电源配置文件工具,分别用于: MCX W71/MCX W72 产品独立组网 \(SA\)蓝牙低功耗 (Bluetooth LE) 功能。 MCX W23 产品独立组网 (SA)的蓝牙低功耗 (Bluetooth LE)。 802.15.4 Matter ICD SIT & LIT 和 ZED 用于 MCX W71 & W72 产品的独立组网 \(SA\)。 Aliro 门锁应用(BLE MCX W72/UWB/NFC/电机) 1. MCX W71 / MCX W72 蓝牙低功耗功率配置文件: AN14389 MCX W71 蓝牙低功耗功耗分析 AN14739 MCX W72 蓝牙低功耗功率我的分析.pdf 2. MCX W23 蓝牙低功耗功率配置文件 AN14659:MCX W23 低功耗蓝牙功耗分析 | 恩智浦半导体 3. 802.15.4 Matter ICD SIT & LIT 和 ZED MCX W71/W72 功率分析 AN14841 MCX W72 802.15.4 物质和 Zigbee 功率我的分析.pdf 4.门锁应用(BLE/UWB/NFC/Motor)
View full article
TDA8954TH no sound output Hello! I have several speakers (Mackie Thump12) with no bass output. I changed the output IC TDA8954TH and the 10R resistors. No sound at all. Does anybody else have problems with this IC? I ordered 3 ICs from different sellers on ALI Express. Best regards, Johannes Re: TDA8954TH no sound output Hello Johannes, The TDA8954TH is a legacy product that is no longer in production and we no longer provide technical support for this device. Perhaps someone else who uses it could help.   BRs, Tomas
View full article
FreeMaster Over CAN on interrupt fail to compile in polling mode I try to change those 3 mico for enabling polling mode from code generated from  "FreeMaster over CAN" and "s32k3xx_fm_over_can_s32ct"  FMSTR_SHORT_INTR, FMSTR_POLL_DRIVEN, and FMSTR_DEBUG_TX but end with compiling failed, reason is that transfer feature freemaster over can from "s32k3xx_fm_over_can_s32ct"  reply on interrupt, but if motor control case using many irq like least 10khz fast task and bctu and hall , wagtch dog, freemaster received no response from controllewr k312, polling mode is necessary. how to enable those 3 micros and open polling mode for "s32k3xx_fm_over_can_s32ct"  Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Communication modes are mutually exclusive options. That's exactly what the error message means. FreeMASTER Driver routine may require a significative processing time and those 3 settings try to help developers to balance the execution depending on use case as follows: FMSTR_POLL_DRIVEN - FreeMASTER routine is executed entirely in the FMSTR_Poll function - developers decides when it is called but has to make sure that it is invoked at such frequency that allows FreeMASTER to keep up with the communication speed FMSTR_LONG_INTR - FreeMASTER routine is executed entirely in the FMSTR_CanIIsr function - deveopers forces the system to executed it by assigning a higher priority (I assume this one was used as it fits best in case of big number of interrupts) FMSTR_SHORT_INTR - is a mix of the previous two: the communication is happening in the interrupt handler (FMSTR_CanIsr), but the processing - in (FMSTR_Poll) I think what you want to try is the last one (combination of polling + interrupt). Still, while the interrupt may guarantee that the CAN frames will be read, the board may not reply on time if FMSTR_Poll is not invoked frequently enough (due to interrupts with higher priority). As a result - FreeMASTER desktop tool will show timeout errors. The developer has to make sure that the system can allocate sufficient time for FreeMASTER Driver routines in compute intensive applications. Hope it clarifies FreeMASTER's communication modes. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I did try before using same setting as you: for example,  I changed FMSTR_POLL_DRIVEN as 1 (was 0.as interrupt mode) // Select interrupt or poll-driven serial communication #define FMSTR_LONG_INTR 1 // Complete message processing in interrupt #define FMSTR_SHORT_INTR 0 // Queuing done in interrupt #define FMSTR_POLL_DRIVEN 1/*0 */ 7 error: mainly because of #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !(FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* mismatch in interrupt modes, only one can be selected */ #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN #endif  3 error happen above for compile ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ one is not enough, but two even all also failed. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, To enable Polling mode you need to update the following macros: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 only one out of those 3 should be set to 1, overwise the code won't compile. Regarding FMSTR_DEBUG_TX - this is a debug macro that is meant to verify the TX line. Combined with previous definitions this one: #define FMSTR_DEBUG_TX 1 will instruct FreeMASTER Driver to continuously send a debug frame (note: this helps you inspecting the TX line and you won't be able to connect to the board using FreeMASTER tool while this functionality is enabled). Could you share your compilation error logs ? As far as I know, s32k3xx_fm_over_can_s32ct example is implemented by Model-Based Design Toolbox (MBDT) team. If you develop your application using Simulink, it may require updating block configuration instead of manual code changes. In this case, MBDT developers can provide better assistance for your use case through the dedicated MBDT community. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, I would try to troubleshoot the FMSTR_LONG_INTR mode, considering it is the only mode that works, even if only for a short time. The things I would look into are: Can you inspect the CAN bus with a logic analyzer and check whether the CAN messages are no longer being sent from the board, or if they are being sent but become corrupted? How many variables are you reading on the PC side? The number of variables is directly proportional to the amount of data exchanged between the PC tool and the board. If possible, I would start with a few variables and gradually increase the number to see when it breaks. Is the CAN instance used by any routines other than the FreeMASTER Driver? Did you start with a MATLAB/Simulink model or an S32 Design Studio example application? Depending on the original source, the FreeMASTER CAN driver implementation may differ. If possible, please attach the source files (they should be named freemaster_s32_flexcan.h and freemaster_s32_flexcan.c). Re: FreeMaster Over CAN on interrupt fail to compile in polling mode thanks for clarification, yes, combination of polling + interrupt is my target. restate issue: target k312 fail to send response after freeamster running a while. now feedback is following: interrupt mode: freemaster working, issue shown above, FMSTR_LONG_INTR only polling mode: compile,, freemaster not working ,  FMSTR_POLL_DRIVEN even if remove error message on freemaster_private.h:326:2: mixed: freemaster working, can compile  but traffic issue remain , all three of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN set as 1 and removing error message on freemaster_private.h:326:2: now I justify :Could be my CAN driver issue. which information do you need if your can provide further support? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1, I used peakcan view to monitor message flow, yes, CAN messages are no longer being sent from the board when freeamster smoothly working, message flashing very fast; when freeamaster freeze, CAN message sent from S32k312minEVB stopped apparently  but message read from freemaster still visible and slow; 2, totally less 20 variables, but amount is much smaller than demon fm project s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3.CAN instance solely used by freemaster; you are right,  our BSW use RTD ,to implement FM over CAN,  flexcan_43 and flexcan_ipw  layer from DEMON s32k3xx_fm_over_can_s32ct MCAL driver are integrated. but still working with issue above. by the way, due to CAN IP layer limit, our can driver can accept standard msg ID, so freeamster configue setting : send standard, receeive extension. please find atatched 4 files I have, which are close to you. do you need all CAN IP configure files? actually all 43/ipw configure same as demon s32k3xx_fm_over_can_s32ct. You can also directly email me. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, Unfortunately, I did not find any attachments on the this thread, but I got those files from MBDT and it indeed differs from the our team's implementation. Could you try replacing MBDT implementation with our version (see attachments - those correspond to freemaster_s32k3xx_can.c and freemaster_s32k3xx_can.h). One inconsistency I noticed is the CAN interrupt handler signature: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); vs void FMSTR_CanIsr(void); Assuming CAN details (such as buffer IDs) are defined in freemaster_cfg.h we do not need them in the handler. We also use RTD (low hardware layer) and  your configuration should not change. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I fail to upload files request, how to upload files into this thread Re: FreeMaster Over CAN on interrupt fail to compile in polling mode except request help to find any function to reset CAN read buffer, I  also suspect one change made for MBD CAN driver code Can_43_FLEXCAN_Ipw.c where, function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer are forced to memcpy to transfer when I integrate MBD MCAL CAN driver into RTD NON-MCAL driver. if no manual transfer, Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer fail to read all can information when using RTD NON-MCAL CAN driver. original MBD DEMON s32k3xx_fm_over_can_s32ct dont need manual transfer, because demon use MCAL CAN 43 driver. is any way to avoid manual trasnfer in function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() if it cause Freemaster issue? or manual reset buffer via some function you know? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig->Can_u8ControllerID][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode feedback: thanks for supply rtd version freemaster driver code, I did replace MBD version function FMSTR_CanIsr(*,*,*..*) in mcal driver freemaster_s32k3xx_can  by FMSTR_CanIsr() in rtd driver  freemaster_can_flexcan. integration and run, Freemaster fail to connect with s32k312MINEVB. I start to debug when freemaster freeze when S32K312N=MINEVB fail to send out message, I found out sw in status of busy to read, which cause unfinished CAN read ,indirectly cause can sent delay unlimited; is any functions to manually clear buffer for read like reset if buffer are full?
View full article
S32K388 TCP/IP stack 5.0.0 not working Hi @PavelL, I was able to run the example TCP/IP stack example project previously with the following configuration: • S32KDS version 3.6.5 • RTD (Real-Time Drivers) version 7.0.0 • TCP/IP Stack version 4.0.0 However, after upgrading to the following versions and did the same setup procedure, it is not working: • S32KDS version 3.6.8 • RTD (Real-Time Drivers) version 7.0.1 • TCP/IP Stack version 5.0.0 I have attached my project. Thanks for the help again. Re: S32K388 TCP/IP stack 5.0.0 not working Hello @James_Zhang_SE , I need time for investigation. I'll do my best to reply within this week. Thank you for your understanding. Best regards, Pavel Re: S32K388 TCP/IP stack 5.0.0 not working Hello @James_Zhang_SE , I apologize for delayed response caused by my workload. The root cause is EthIf_Cfg.c , as we've already discussed in this thread S32K388 tcpip stack 4.0.0 missing lwip folder while compiling The example is working now on my S32K388EVB-Q289. Anyway, I did lots of changes in your project but the most critical is the EthIf_Cfg file. All modified files can be found in the attached zip. You may check the changes by yourself. Please notice that provided code is without any warranty. Once you replace files by the patch, please do not forget to do Update Code. Best regards, Pavel
View full article
MCU-Link - Linkserver - Injection of unwanted cyclecounts at performance tests Hello there, First of all: everything written is from a claude agent, because everything I make is done inside an obsidian Repo and it is faster to let the agent write 🙂  I am doing cycle-accurate timing measurements on an FRDM-MCXN947 for my master's thesis, where I compare the scheduling overhead of some real-time operating systems. Every number I report is a difference of two DWT->CYCCNT reads, so the measurement has to be repeatable down to the single cycle. It is not, and after a fairly long investigation I have narrowed the cause down to one mechanism that I cannot confirm from the documentation. I would like to ask whether my explanation is actually correct, because if it is wrong then I have excluded everything else and have no candidate left. The short version of the question: while a debug session is open, LinkServer periodically reads DHCSR and CPACR to find out whether the core has halted. Both of these are SCS registers inside the private peripheral bus, so the access is serviced inside the core and never appears on the code bus or the system bus. My assumption is that such an access nevertheless competes with the core's own instruction fetches and data accesses somewhere inside the core, and that this is what costs my measurement a few cycles every time a poll lands inside the measured window. Is that assumption right? Setup The board is an FRDM-MCXN947 and I am using core0 only, at 150 MHz for the real measurements and at 12 MHz for a control experiment described further down. I debug through the on-board MCU-Link with LinkServer, which speaks CMSIS-DAP v2 over USB bulk, and I have tried SWD wire clocks of both 50 and 500. The launch configuration passes --no-rtos and --semihost-port=-1, and liveWatch is disabled, so the IDE should not be reading anything from the target while the core runs. The code under test executes from RAM at 0x2000_0000, which means it is fetched over the system bus. Caches and RAM ECC are off. There is a second, separate variation in how the image gets into RAM: for most of the work the probe simply loads it there, but for one experiment I stored the image in flash and copy it into RAM during startup, because an image that only exists in RAM cannot start without a probe to load it in the first place. That distinction matters only for that one experiment, and I mention it now so the setup is unambiguous later. The thing being measured is an empty counting loop, executed a given number of times and timed by reading CYCCNT before and after. I repeat each measurement 64 times. Problem Running the identical measurement twice does not give the identical answer. On the empty loop the 64 values spread over three to six cycles, and on real application code roughly nine out of a hundred thousand iterations come out one to ten cycles above all the others. The deviations only ever go upward, never downward, and the minimum value is perfectly stable and reproducible. What was most informative is that the spread grows with the length of the measurement window rather than being a fixed cost per measurement call, which already rules out a constant overhead somewhere in my instrumentation. Here is the full sweep. Each cell is 64 measurements of the empty loop; "outliers" counts how many of the 64 came out above the first one, and min and max are given as cycles above the loop's clean value. Core Loop count SWD 50: outliers min max SWD 500: outliers min max Core F loops outliers per 64 MEasurements min jitter count max jitter count outliers/64mea. min jitter max jitter 12 MHz 100 0 +13 +13 0 +13 +13   1 000 4 +13 +15 7 +13 +16   10 000 24 +13 +16 18 +13 +17   100 000 55 +13 +23 57 +13 +22   1 000 000 56 +40 +69 59 +45 +102 150 MHz 100 0 +13 +13 0 +13 +13   1 000 0 +13 +13 1 +13 +15   10 000 4 +13 +15 3 +13 +15   100 000 13 +13 +15 16 +13 +17   1 000 000 53 +13 +20 60 +13 +25 Three things come out of this table. First, the constant +13 is not part of the problem. It shows up as the minimum in every cell that has not saturated, at both core clocks and at both wire speeds, and it is simply the loop prologue plus the CYCCNT read itself. Because it is independent of both the core clock and the probe, it is a fixed bias that I subtract, and everything above +13 is what I am actually chasing. Second, and this is the important one, the disturbance follows wall-clock time and not the number of cycles executed. If you compare the two clocks at the same loop count, there are consistently more outliers at 12 MHz than at 150 MHz: four against zero and seven against one at a thousand iterations, twenty-four against four and eighteen against three at ten thousand, fifty-five against thirteen and fifty-seven against sixteen at a hundred thousand. The instruction stream is identical in both cases and therefore executes the same number of cycles, and the only thing that differs is that the 12 MHz run takes 12.5 times longer in real time. Third, the SWD wire clock makes no difference at all. Across the ten matched pairs above the counts scatter in both directions and stay within counting noise, so a tenfold change in wire rate leaves them alone. Whatever sets the pace, it is not the wire. Excluded as root cause I want to be upfront that a lot of this was ruled out by actually reading the relevant register back from the target with the session open, rather than by assuming that the reset default still held. On the SoC side, CPU1, eDMA0, eDMA1 and the SmartDMA are all disabled, RAM ECC is off and the code cache is off, so nothing else is contending for memory. On the trace side, ITM is disabled, no stimulus port is enabled, timestamps are off, the stall-for-trace bit is clear and ETM is off, which means nothing is generating trace packets and therefore nothing can be stalling in order to deliver them. Within the DWT, PC sampling is off, exception trace is off, all the event counters are off, the watchpoint comparators are unused, and the performance monitor is off. TRCENA is of course set, but it has to be set in both the disturbed and the undisturbed case because CYCCNT depends on it, so it cannot be the difference between them. Interrupts and exceptions are out on grounds of size alone. Any exception on this core costs somewhere between twenty-five and fifty cycles, and my deviations are one to ten. There is no small version of an exception, so the entire class is excluded regardless of what the interrupt masks say. Breakpoints are out for a similar reason: an FPB comparator costs nothing until it matches, and when it matches it halts the core rather than delaying it slightly. The code under test is out because of a control experiment. An empty loop contains no data-dependent work whatsoever and therefore cannot vary on its own, and it varies anyway. So the cause is in the platform, not in what I am measuring. That left debugger memory reads as by far the most promising explanation, and I would like to explain why I dropped it, because it is the mechanism most people would reasonably suspect. A debug read of SRAM does leave the core and would genuinely fight the core for the bus port, so the mechanism would work perfectly. The trouble is that it does not happen. Every read the IDE performs travels as a GDB m packet, and in the gdbserver log there is not a single packet between the $vCont;c that starts execution and the host interrupt thirty-two seconds later. Every memory read in that log sits after the halt, which is just the IDE filling its views once the core has stopped. The same argument disposes of the even more attractive theory that the debugger is reading CYCCNT itself, which would contend with my measurement directly: that would also appear as an m packet, and it does not, and liveWatch is disabled anyway. What it seems to be To separate the probe from the session I ran the identical binary with the probe physically plugged in but with no debug session open. This is the experiment that needed the flash-to-RAM copy at startup I mentioned earlier, since a RAM-only image has no way to get loaded without a probe. The probe stayed connected for both runs, so the only difference between them was whether a session was attached. Without a debug session the jitter is gone. Same binary, same clock, same boot path. So it is not the probe being connected, and it is not the build: a probe that is merely attached but issuing no transactions costs nothing, and attaching a session brings the jitter back. At that point I had a disturbance that is definitely caused by the session, that is paced by real time rather than by the core clock, and for which I had eliminated every mechanism I could think of. To find out what LinkServer sends while the core is running, I captured the MCU-Link's CMSIS-DAP bulk endpoints with USBPcap and Wireshark. Two DAP_Transfer requests repeat continuously, roughly every fifty milliseconds. I should immediately qualify that number. The polling does not look like a fixed timer, because the host appears to send the next request only after the previous response has come back, which makes the interval at least partly event-driven — host turnaround plus USB latency plus whatever delay the host inserts of its own accord. So fifty milliseconds is an order-of-magnitude figure for how often it repeats, not a period I would want to quote, and it also means I cannot cleanly reason backwards from the rate. The first request reads DHCSR and CPACR together. On the wire it is 05 00 06 08 00 00 00 00 05 f0 ed 00 e0 0f 08 00 00 00 00 05 88 ed 00 e0 0f, which decodes as: # Req Decode Data Target access 1 08 DP write SELECT 0x00000000 none (DP-internal) 2 05 AP write TAR 0xE000EDF0 (DHCSR) none (AP-internal) 3 0f AP read DRW — 1 read, PPB 4 08 DP write SELECT 0x00000000 none (DP-internal) 5 05 AP write TAR 0xE000ED88 (CPACR) none (AP-internal) 6 0f AP read DRW — 1 read, PPB The answers were DHCSR = 0x01100001, meaning the core is running with secure debug enabled and instructions retiring, and CPACR = 0x00F00003, meaning the FPU is fully accessible. The second request is 05 00 03 08 00 00 00 00 05 f0 ed 00 e0 0f, which is just the first half of the above and asks only whether the core has halted, without the FPU check. So the entire traffic reaching the target during my measurement window is two PPB reads, or one in the case of the shorter request. The SELECT and TAR writes produce no target access at all, since they are internal to the DP and the AP respectively, and only the two DRW reads actually go anywhere. I checked the transfer count against the data-word count and confirmed a direct value-to-register mapping with no posted-read shift on this adapter, so I am confident about which value belongs to which address. Both addresses are SCS registers inside the PPB, and neither appears on the SoC bus matrix. There is no SRAM access anywhere in this, and there is no access to the core register file either, since nothing goes through the DCRSR/DCRDR keyhole, which would require the core to be halted first. For completeness: a separate seventy-one-transfer dump of S0 to S31 and FPSCR does appear in the capture, but only at a moment when the core was halted at a stopAtSymbol breakpoint, not during the run. My guess is that CPACR is bundled with DHCSR precisely so that the adapter already knows whether the floating-point registers are live at the instant the core does halt. Assumption to check:  What I currently believe is happening is this. The request enters the core through the D-AHB debug port and is then arbitrated by the core's internal interconnect against the core's own instruction fetches and data accesses. Being resolved inside the core does not put the access on a path that is disjoint from execution; it still meets execution at a shared internal stage. The core holds priority, so in the normal case the debug access waits and the core carries on unaffected. The residual cost appears only when a debug beat is already in flight and cannot be preempted, in which case the core has to wait for that beat to finish. That wait would be exactly what I observe: a few cycles, always upward, and only on the fraction of measurement windows that a poll happens to fall inside. Questions: Is the mechanism I described above actually correct? Does a DAP-originated read of a PPB or SCS register such as DHCSR or CPACR, arriving over the D-AHB debug port, contend with the running core's own accesses inside the M33 in a way that can stall it by a small number of cycles? Or is the debug port genuinely disjoint from the execution path for PPB targets, in which case I have excluded everything and am still missing the real cause? Is this documented anywhere? I have the Cortex-M33 TRM (100230_0100_07_en) and can see the D-AHB and the internal interconnect in it, but I have not found any statement about what a debug access to core-internal PPB space costs while the core is running. A pointer to the right section, or to anything MCXN947-specific about how the DAP is integrated on this part, would help me a great deal. Would CYCCNT even see such a stall? In other words, is the core genuinely held up, so that these are real execution cycles that CYCCNT counts, rather than CYCCNT being perturbed by some other route? Is there any way to slow down or disable the halt-state poll in LinkServer? That would give me the clean confirmation I am after: change the poll rate and see whether the outlier rate follows. I have not been able to find a setting for it, and anything that reduces or stops the periodic DHCSR read while the core runs would work for this test. If the mechanism is real, is measuring with no session attached simply the correct practice for cycle-accurate work on this part? That is what I do now, and where a session is unavoidable I fall back on taking the minimum across many windows and reporting how many deviated and by how much. I would like to know whether that is the accepted answer, or whether there is a supported way to measure cleanly with a live session. Core and Memory Development Board
View full article
i.MX95 Neutron NPU用にYOLOv8/YOLO11 TFLiteモデルをコンパイルできません こんにちは、NXPサポートチームの皆さん、 私たちはNeutron SDK v3.1.3を用いてFRDM i.MX95プラットフォーム上の物体検出を評価していますまた、NPU互換モデルを生成できません。Neutronコンバータはモデルを正常にロードしますが、 Neutron NPUに割り当てられたオペレーターは0個と報告します。 環境 対象ボード:FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: YOLO11とYOLOv8の両方でテスト済み eIQツールキット:ONNXからTFLiteへの変換に使用 モデル:カスタムの単一クラスペグ検出器 トレーニング司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=モデル \ name=peg_detector_v8 エクスポートコマンド $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml また、別のワークフローもテストしました。 PyTorchをエクスポート → ONNX NXP eIQツールキットを使用してONNXをINT8 TFLiteに変換する Neutron SDKでコンパイルした場合、両方のワークフローは同じ結果を生み出しました。   Neutron コンパイル ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   コンバータ出力 コンバーターは次のように報告しています: インポート後のオペレーター数:341 最適化後の演算子数:367 変換された演算子: 0 オペレーター変換率:0 / 367 Number of Neutron graphs: 0 警告: 警告:グラフの演算子はニュートロンにマッピングされていません。 警告:変換されたモデルは入力モデルと同じで、演算子が中性子にマッピングされていないためです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています!これによりコンバージョン率が低くなることがあります。 その他の情報 以下のケースでも同様の挙動が観察されました。 YOLO11 YOLOv8 ダイレクトUltralytics TFLiteエクスポート ONNX → eIQ ツールキット → INT8 TFLite 生成されたすべてのTFLiteモデルは、Neutronコンパイラによって 0演算子をマッピング します。 質問 YOLOv8またはYOLO11のオブジェクト検出モデルは、i.MX95用のNeutronコンパイラで公式にサポートされているのでしょうか? i.MX95 NPUをターゲットにしたYOLOモデル向けの推奨エクスポートパイプラインはありますか? 現在のNeutron SDK(v3.1.3)には既知の制限はありますか?YOLO検出ヘッドに関してですか? NXPはi.MX95 NPU向けに正常にコンパイルできるリファレンスYOLOv8/YOLO11モデルを提供していますか? 演算子マッピングを有効にするために、追加のコンパイラオプションや前処理手順が必要ですか? i.MX95 Neutron NPUで動作することが知られているガイダンス、推奨ワークフロー、または参照モデルがあればぜひ教えていただけるとありがたいです。 よろしくお願いします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU そして、あなたの人生を本当に大切にしてください。 もし本当に 、私がこのゲームを望むなら、私はこのゲームを L に x x 95 でイノシシd. 私たちは今、AR A2 を手に入れたので、そのキャパビリのつながりと 、あなたたちの兄弟の絆を活用します。 私たちはNXで実際にデモを作ったことがあるし、あなたはこのマットで最初に知られるだろうと、もっと早くアプリに報告されるだろう. あなたの LPに感謝します。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Model zooのyolo8mモデルをimx95ボードで試し、LF 2026年Q2リリースイメージを使いました。カーネルバージョンはNeutron SDK 3.1.2を使用して6.18.2です。うまくいく。     まずは以下から試してみることもできます: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-Smart.imx95.tflite --external_delegate_path=/USR/LIB/libneutron_delegate.so 詳細はREADMEのeiq-model-zoo/tasks/ビジョン/object-detection/yolov8を参照してください。NXP/eiq-model-zoo さらに、モデルやコンプリエーションの詳細なログを添付することもできます。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU コンバーターログに基づくと、最初に解決すべき問題は、生成されたTFLiteモデルに依然としてFLOAT演算子が含まれていることです。 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! i.MX95 Neutronの場合、ニュートロンコンバータへの入力は、演算子と量子化フォーマットがNeutronコンパイラと互換性のあるTFLiteモデルでなければなりません。特に、i.MX95中性子流は量子化されたTFLiteと対称int8重みを期待しています。UltralyticsエクスポートやONNXからTFLiteへの変換後もモデルにFLOAT演算子/テンソルが残っている場合、コンバーターは報告された結果と整合するNeutron互換の部分グラフを作成できない可能性があります。 変換された演算子: 0 中性子グラフの数:0 YOLOv8はi.MX95上で一部のフローにおいて評価されていますが、任意のUltralyticsエクスポートにおいて、エンドツーエンドのYOLOv8/YOLO11オフロードが完全に実現されるとは限りません。エクスポートされたTFLiteグラフによっては、モデルの一部のみがNeutronGraphに変換され、サポートされていない演算子はCPU上に残ります。したがって、次の推奨ステップは生成されたTFLiteモデルを検査・プロファイリングし、以下のことを確認することです: グラフは完全に量子化されており、 FLOAT演算子はありません。 重みは対称な int8、 入出力テンソルタイプは互換性があり、該当する場合はNeutron変換器のuint8からint8への変換オプションで変換されます。 デコードやNMSなどのYOLO後処理は、SDKで正確な演算子がサポートされていることが確認されない限り、NPUグラフの外に保管されます。 また、Neutron-Converter版とボード上のNeutronランタイム/ファームウェア/デリゲートが同じ互換性のあるSDK/BSPリリースから来ていることも確認してください。 推奨される手順として、NXP/eIQ変換パスをお試しください。 PyTorch -> 静的入力形状のONNX -> 代表的な較正データを用いたNXP/eIQ量子化 ->量子化されたTFLite -> Neutron-converter --ターゲットIMX95 モデルにuint8の入力/出力テンソルがある場合は、以下もテストしてください: --入力値をuint8からint8に変換 --出力をuint8からint8に変換 FLOAT演算子を削除した後も変換結果にマッピングされた演算子が0と表示される場合は、以下の情報を共有してください。 - 詳細/プロファイリング出力を含む完全な中性子変換ログ - TFLiteオペレーターリスト、 - テンソルデータ型と量子化パラメータ、 - FRDM i.MX95ボード上のBSP/実行時Neutronデリゲート/ファームウェアバージョンの正確なバージョン、 - YOLO検出ヘッドにNMSやその他の後処理が含まれているかどうか。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 私のテストでは、 自分でトレーニングもエクスポートもしていません。eIQ Model Zooのプリ生成されたYOLOv8モデルを使い、i.MX95プラットフォームで動作することを確認しました。 私が実際に使用したコマンドはこれだけです。 ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 モデルでは: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite カスタムモデルの場合、推奨されるNXPフローは以下の通りです: PyTorch ↓ ONNX(静的入力形状) ↓ eIQツールキット ONNX2Quant ↓ eIQツールキット ONNX2TFLite ↓ 量子化されたTFLite ↓ Neutron-converter --ターゲットIMX95 あなたのモデルが報告しているので: プレーンテキスト 変換された演算子: 0 Number of Neutron graphs: 0 警告:グラフにはサポートされていない浮動小数点演算子が含まれています! あなたの生成されたTFLiteグラフは、eIQ Model Zooの参照モデルとは構造的に異なるのではないかと推測しています。まず最初におすすめしたいのは、以下の2つのモデルを比較することです: 入力/出力テンソル型(INT8 vs UINT8) FLOAT演算子の存在 グラフ内のデコード/NMSレイヤー Netron / TFLiteアナライザーによって報告されたオペレーターリスト Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推奨されるエンドツーエンドのワークフロー モデルトレーニング(PC) お好みのフレームワークを使用してトレーニングしてください。 ウルトラリティクス YOLOv8 PyTorch テンソルフロー ONNXネイティブワークフロー 物体検出に関しては、NXPはすでにeIQモデルズーでYOLO参照レシピを提供しており、YOLOv8オブジェクト検出モデルも含まれています。[github.com] 、[github.com] 例: シェル YOLO検出トレーニング model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ エポック数=100 ` ONNX形式でエクスポート NXPは一般的に、量子化および展開の前に、交換フォーマットとしてONNXを使用することを推奨しています。 YOLOエクスポート model=best.pt \ フォーマット=onnx Neutron イネーブルメントのプレゼンテーションは、以下に基づくフローを明示的に記述しています: プレーンテキスト PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ Neutron コンバータ 訓練アーティファクトから直接展開を狙うのではなく、 eIQツールキットを使用した量子化 Neutronのワークフロードキュメントでは、eIQ Toolkitの量子化ユーティリティの使用を推奨しています: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: 「 に続く: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite もっと行を表示 この流れはi.MX95 Neutron イネーブルメント材料に明示的に記録されています。 i.MX95 Neutron NPU用にコンパイル Neutron-converter \ --ターゲット imx95 \ --input model_int8.tflite \ --出力 model_neutron.tflite ニュートロンコンバーターは、NPUにオフロードできるNeutron特有のグラフパーティションを作成します。 コンバージョン率の検証 NPUのデプロイが成功すると、以下のようなレポートが表示されます。 変換されたオペレーターの数 > 0 Number of Neutron graphs > 0 次のような場合: 変換された演算子: 0 Number of Neutron graphs: 0 この場合、モデルはNPUによって加速されていません。 あなたの抱えている問題は、このカテゴリーに該当します。 FRDM-i.MX95に展開する TensorFlow LiteでNeutronデリゲートを使い実行します: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 または ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX Machine Learning User Guideでは、 Neutron Delegate がi.MX95 TensorFlow Liteモデルの加速機構として特定されています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU yolov8m_full_integer_quant.tfliteをどのように変換してIMX95のNPUで動作させたのか教えてもらえますか? 手順に従って環境設定データ(HOST)を経て...私たちにとって大いに助けになるでしょう。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは 私はUbuntu 24.04を使用していますが、eiq_toolkitは20.04.03でのみ利用可能です。 eiqToolkitとeIQ Toolkitを使った量子化の使い方 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ ToolkitはUbuntu 20.04で検証済みであるため、最も安全な方法は以下のとおりです。 Docker Ubuntu 24.04ホスト上でUbuntu 20.04コンテナを実行します。 docker run -it --name eiq \ ubuntu:20.04 /bin/bash 次に、コンテナ内に必要な依存関係とeIQ Toolkitをインストールします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Toolkit(onnx2quant)を使ってカスタムYOLOv8 ONNXモデルを変換する際に信頼度を維持できない 概要 こんにちは、NXPチームの皆さん、 私はfdm i.MX95上でeIQ Toolkitを使ってカスタムYOLOv8単一クラスオブジェクト検出モデルを展開しようとしています。 変換パイプライン全体は正常に実行されますが、onnx2quant の後、信頼度出力がすべてゼロになり、バウンディングボックス出力は有効なままです。 環境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX ランタイム 1.21.1 - テンソルフロー 2.21 - Neutron-コンバータ 3.1.3 - ターゲット:FRDM i.MX95(tflite_runtime 2.19+Neutronデリゲート) 変換パイプライン 1. 列車 Yolo Detect Train Model=yolov8N.pt data=dataset.yaml imgsz=640 epochs=50 2. ONNXのエクスポート Yolo export model=best.pt format=onnx opset=13 3. ONNXの検証 入力:(1,3,640,640) 出力:(1,5,8400) ONNXランタイム推論: 信頼チャネル最大値 = 0.773 4. キャリブレーションデータセットの生成 形状:(1,3,640,640) dtype : float32 範囲:0.0 - 1.0 5. 量子化 onnx2quant best.onnx -c "images;キャリブレーション/画像」 -o best_quant.onnx また、以下の項目もテストしました。 onnx2quant best.onnx -u どちらも同じ結果を生み出す。 6. 量子化されたONNXの検証 出力:(1,5,8400) バウンディングボックスチャネルは有効のままです。 自信: 最小値 = 0 最大値 = 0 平均 = 0 デコードされた検出数 = 0 7. TFLite形式に変換する onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron Neutron-converter --ターゲット IMX95 --入力 best.tflite --出力 best_neutron.tflite コンパイルに成功しました。 オペレーター変換率:278 / 325 (85.5%) 調査実施 検証済み: • PyTorchモデルの動作 • ONNX輸出作品 • ONNXランタイム推論の動作 • キャリブレーションデータセットは正確です • 実数およびランダムキャリブレーションで同一の結果が得られます • TFLiteは量子化されたONNX出力を再現します • NeutronはTFLite出力を再現します この問題は以下以下に初めて現れます: ONNX ↓ onnx2quant ↓ 量子化されたONNX(信頼度がゼロになる) 追加の観察 NXPの参照モデル: 入力:(1,640,640,3) INT8 出力:(1,84,8400)INT8 私の改造モデル: 入力:(1,3,640,640) FLOAT32 出力:(1,5,8400) FLOAT32 カスタムYOLOv8モデルの信頼度を保つ推奨されるエクスポートや量子化のワークフローはありますか? これは、(1,5,8400)出力を持つモデルのonnx2quantの制限やバグでしょうか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU AEチームと話し合っています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240のエンドツーエンド評価は実施されましたか?データシートには、シグモイドやNMSなどの後処理操作を実行できる2つのベクターコアが記載されています。コンパイラはNMSの操作をベクターコアにマッピングできますか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU YOLOv8の出力テンソルに適用される完全なINT8量子化( inference_output_type=tf.int8 )の根本的な制限により、信頼度出力が失われます。 YOLOv8 は、境界ボックスの座標と信頼度スコアを (1, 5, 8400) の形状の単一の出力テンソルにパックします。bboxの値は広いダイナミックレンジ(約640ピクセル)を持ち、信頼度スコアは約0から1の範囲にあります。出力テンソル全体が単一の量子化スケールを共有する場合、そのスケールは大きなbbox値(約640)によって支配され、信頼区間全体(約1)を表すために1つの整数レベルのごく一部しか残されません。その結果、INT8量子化後、すべての信頼度値は実質的にゼロに丸められます。 推奨される解決策   onnx2quant を通す代わりに、Ultralyticsを使って訓練した  .pt  モデルからINT8 TFLiteを直接エクスポートし、それを  neutron-converter に入力します: # INT8 TFLite 直接エクスポート(キャリブレーションはトレーニングデータセットを使用) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # ニュートロン 用 にコンパイル(変更なし) ニュートロンコンバーター --target imx95 --input best_int8.tflite --output best_neutron.tflite 入力および出力データの型は、np.int8であることを確認してください。 interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale、inp_zp = inp_d[ "quantization" ] out_d = out_ds[0] out_scale、out_zp = out_d[ "quantization" ] print(f " 入力 dtype={inp_d['dtype']} shape={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 出力 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 形状から入力フォーマットを決定します in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] または [1,640,640,3] in_shape[1] == 3 の場合: #NCHW src=img_nchw それ以外: #NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ "インデックス" ],src_int8) それ以外: interp.set_tensor(inp_d[ "インデックス" ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# int8 または float32 の可能性があります if out_d[ "dtype" ] == np.int8: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale それ以外: dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 正規化 # 表示用にバウンディングボックスをピクセル座標に再スケーリング BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 遅れてごめんなさい。変換ワークフローを再現しようとしています。 今のところ一つ質問ですが、なぜ変換されたモデルのデータ型がFLOAT32なのか?INT8形式への変換を試してみましたか?ニュートロンNPUはINT8型を入力データとして必要とします。他のモデルの変換でも似たエラーに遭遇しましたが、根本原因はデータ型にあります。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは、あなたが共有してくれたコマンドを試しました... しかしNeutron変換器はモデルの変換に失敗している... 参照用に添付のログをご覧ください
View full article
FreeMaster Over CAN on interrupt on 轮询模式 编译失败 我尝试修改“FreeMaster over CAN”和“s32k3xx_fm_over_can_s32ct”生成的代码,以启用轮询模式。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN和FMSTR_DEBUG_TX 但最终编译失败,原因是传输功能 freemaster 通过 can 从“s32k3xx_fm_over_can_s32ct”响应中断,但如果电机控制情况使用许多 irq,例如至少 10khz 的快速任务以及 bctu 和 hall、wagtch dog,freemaster 没有收到来自控制器 k312 的响应,因此需要轮询模式。 如何启用这 3 个微控制器并为“s32k3xx_fm_over_can_s32ct”打开轮询模式? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 沟通方式是互斥的选项。错误信息的意思正是如此。 FreeMASTER 驱动程序例程可能需要较长的处理时间,以下 3 个设置旨在帮助开发人员根据不同的使用场景平衡执行时间: FMSTR_POLL_DRIVEN - FreeMASTER 例程完全在 FMSTR_Poll 函数中执行 - 开发人员可以决定何时调用该例程,但必须确保其调用频率足以使 FreeMASTER 跟上通信速度。 FMSTR_LONG_INTR - FreeMASTER 例程完全在 FMSTR_CanIIsr 函数中执行 - 开发人员通过分配更高的优先级强制系统执行它(我假设之所以使用这个优先级,是因为它最适合处理大量中断的情况)。 FMSTR_SHORT_INTR 是前两者的混合体:通信发生在中断处理程序 (FMSTR_CanIsr) 中,但处理发生在 (FMSTR_Poll) 中。 我认为你想尝试的是最后一种方法(轮询+中断的组合)。虽然中断可以保证读取 CAN 帧,但如果 FMSTR_Poll 没有被足够频繁地调用(由于优先级更高的中断),则电路板可能无法及时响应。因此,FreeMASTER桌面工具将显示超时错误。 开发人员必须确保系统能够为计算密集型应用程序中的 FreeMASTER 驱动程序例程分配足够的时间。 希望这能帮助大家了解 FreeMASTER 的通信模式。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我之前也尝试过使用和你一样的设置: 例如,我将FMSTR_POLL_DRIVEN 改为 1(之前为 0,表示中断模式)。 // 选择中断驱动或轮询驱动的串行通信 #define FMSTR_LONG_INTR 1 // 在中断中完成消息处理 #define FMSTR_SHORT_INTR 0 //中断中完成排队 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7. 错误:主要原因是 #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN )) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN )) || \ ( FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !( FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* 中断模式不匹配,只能选择一种 */ #错误您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 #endif 上述编译过程中出现了 3 个错误。 ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ 一个不够,两个也都失败了。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 要启用轮询模式,您需要更新以下宏: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 这 3 个参数中只能有一个设置为 1,否则代码将无法编译。 关于FMSTR_DEBUG_TX - 这是一个用于验证 TX 线的调试宏。结合之前的定义,得出以下定义: #define FMSTR_DEBUG_TX 1 将指示 FreeMASTER 驱动程序持续发送调试帧(注意:这有助于您检查 TX 线,但启用此功能后,您将无法使用 FreeMASTER 工具连接到电路板)。 能否分享一下编译错误日志? 据我所知, s32k3xx_fm_over_can_s32ct 示例是由基于模型的设计工具箱 (MBDT)团队实现的。如果您使用 Simulink 开发应用程序,则可能需要更新模块配置,而不是手动修改代码。在这种情况下,MBDT 开发人员可以通过专用的 MBDT社区为您的用例提供更好的帮助。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 我会尝试排查FMSTR_LONG_INTR模式的问题,因为它是唯一有效的模式,即使只能维持很短的时间。我会调查以下几个方面: 您能否使用逻辑分析仪检查 CAN 总线,并确认 CAN 消息是否不再从电路板发送,或者是否正在发送但已损坏? 在PC端,你读取了多少个变量?变量的数量与PC工具和板之间交换的数据量成正比。如果可能的话,我会先从几个变量开始,然后逐渐增加变量的数量,看看什么时候会出问题。 除了 FreeMASTER 驱动程序之外,还有其他程序使用 CAN 实例吗? 您是从 MATLAB/Simulink 模型还是 S32 Design Studio 示例应用程序开始的?根据原始来源的不同,FreeMASTER CAN 驱动程序的实现方式可能会有所不同。 如果可以,请附上源文件(它们应该命名为freemaster_s32_flexcan.h和freemaster_s32_flexcan.c )。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 感谢你的澄清,是的,我的目标是轮询+中断相结合。 重述问题:目标 k312 在 FreeAmster 运行一段时间后无法发送响应。 以下是反馈意见: 中断模式:freemaster 工作正常,问题如上所述,仅限 FMSTR_LONG_INTR 轮询模式:编译,freemaster 无法工作,即使移除 freemaster_private.h:326:2 中的 FMSTR_POLL_DRIVEN 错误消息: 混合:freemaster 可以运行,可以编译,但流量问题仍然存在,FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 这三个值都设置为 1,并移除 freemaster_private.h:326:2 处的错误消息: 现在我推断:可能是我的 CAN 驱动程序问题。 如果您可以提供进一步的支持,您需要哪些信息? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1、我使用 PeakCan View 来监控消息流, 是的,板不再发送CAN消息了。 Freemaster 运行正常时,消息闪烁非常快;Freemaster 死机时,从 S32k312minEVB 发送的 CAN 消息明显停止,但从 Freemaster 读取的消息仍然可见且速度很慢; 2,总共少于 20 个变量,但数量远小于 demon fm 项目 s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3. CAN 实例仅供 freemaster 使用; 您说得对,我们的 BSW 使用 RTD 来实现 CAN 上的 FM,集成了 DEMON s32k3xx_fm_over_can_s32ct MCAL 驱动程序中的 flexcan_43 和 flexcan_ipw 层。但上述问题仍在解决中。 顺便说一下,由于 CAN IP 层限制,我们的 can 驱动程序可以接受标准消息 ID,所以 freeamster 配置设置:发送标准,接收扩展。 请查收附件中的 4 个文件,它们与您关系密切。 您需要所有 CAN IP 配置文件吗?实际上所有 43/ipw 配置都与 demon s32k3xx_fm_over_can_s32ct 相同。 您也可以直接给我发邮件。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 很遗憾,我没有在这个帖子里找到任何附件,但我从 MBDT 获取了这些文件,它确实与我们团队的实现方式不同。 您能否尝试将 MBDT 实现替换为我们的版本(请参阅附件 - 这些文件对应于freemaster_s32k3xx_can.c和freemaster_s32k3xx_can.h )? 我注意到的一个不一致之处在于 CAN 中断处理程序的签名: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 对比 void FMSTR_CanIsr(void); 假设 CAN 详细信息(例如缓冲区 ID)已在freemaster_cfg.h中定义我们不需要在处理程序中使用它们。我们也使用 RTD(底层硬件层),您的配置不应更改。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我上传文件请求失败,请问如何将文件上传到这个帖子? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 除了请求帮助查找重置 CAN 读取缓冲区的任何功能之外, 我还怀疑MBD CAN驱动程序代码Can_43_FLEXCAN_Ipw.c中做了一处修改。 其中,函数 当我将 MBD MCAL CAN 驱动程序形容功能时作“内置”,形容器件时作“集成”到 RTD NON-MCAL 驱动程序中时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 被强制使用 memcpy 进行传输。 如果没有手动传输,使用 RTD NON-MCAL CAN 驱动程序时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 将无法读取所有 CAN 信息。 原版 MBD DEMON s32k3xx_fm_over_can_s32ct 不需要手动传输,因为 demon 使用的是 MCAL CAN 43 驱动程序。 如果手动传输会导致 Freemaster 问题,有没有办法避免在函数 Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() 中进行手动传输? 或者通过你知道的某个功能手动RESET缓冲区? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 反馈:感谢您提供RTD版本的FreeMaster驱动程序代码, 我用 rtd 驱动程序 freemaster_can_flexcan 中的 FMSTR_CanIsr() 替换了 mcal 驱动程序 freemaster_s32k3xx_can 中的 MBD 版本函数 FMSTR_CanIsr(*,*,*..*)。 集成和运行,Freemaster 无法连接到 s32k312MINEVB。 当 S32K312N=MINEVB 无法发送消息时,freemaster 冻结,我开始调试,发现软件处于忙于读取状态,导致 CAN 读取未完成,间接导致 CAN 发送延迟无限长; 是否有类似缓冲区满时RESET读取操作的手动清除缓冲区的功能?
View full article
CONFIG_FIT_CIPHER=y のみで hab_status が発生します サポートの皆さん、こんにちは。 CONFIG_FIT_CIPHER=yのみを設定すると、i.MX8M Plus EVK (OPENモード) でhab_statusがHAB_INV_SIGNATURE/HAB_INV_ASSERTIONを報告する。 ボード:i.MX8MP LPDDR4 EVK、オープン/非フューズ(HAB構成:0xf0、HAB状態:0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB署名:それ以外は正しく動作する — CST署名imx-boot(SPL CSF + FIT CSF)、両方の埋め込みオフセットでCSFタグバイトを検証し、不一致があればビルド失敗(必ず合格)するカスタムビルドタイムタスク 通常のHAB署名済みimx-bootでhab_status「HABイベント情報 Found!」と報告するというクリーンなベースラインがあります。最近、カーネルFITイメージ署名+AES-256暗号化を追加しました(HABとは別の仕組みで、U-Boot独自のbootmが署名済みカーネルFITの検証・復号を行い、鍵はu-boot.dtbに埋め込まれています)。SRKヒューズとは無関係です。これを有効にした後、hab_status毎回の起動で4つのイベント情報を報告し始めました: HAB 構成:0xf0、HAB 状態:0x66 HABイベント情報1:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報2:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報3:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HABイベント情報4:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY 私は、実際のハードウェアで確認しながら、一度に1つの変数ずつ、独立した再構築+再フラッシュテストを実施して、この問題を体系的に二分しました。 1. ベースライン(既存のHAB署名imx-boot、カーネルFIT作業なし):イベント情報0 2. 完全なカーネルFIT機能を有効にし(FIT pubkey/AESキーDTB埋め込み+私自身のcmd/bootm.cパッチ + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000):4つのイベント情報 3. FIT pubkey/AESキーDTB埋め込みのみ無効化:イベント情報が依然存在し、同一 4. また、私のコマンド/bootm.cも削除しましたパッチ:イベント情報は依然として存在し、同一です 5. CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000を完全に除去(真のプレカーネルFITベースライン):イベント情報0、クリーン 6. 復活は CONFIG_SYS_BOOTM_LEN=0x8000000(CONFIG_FIT_CIPHERなし):0イベント情報、クリーン 問題は正確には CONFIG_FIT_CIPHER=y に限定されており、他の要因は関係ありません (私の bootm.c)パッチ、FIT pubkey/AESキーのDTB埋め込み、CONFIG_SYS_BOOTM_LEN)単独または組み合わせでマター;CONFIG_FIT_CIPHER=yだけが0イベント情報からこの4 hab_statusに切り替わります。 私自身の CSF 計算に問題がないことを二重に確認しました。私のビルド時の署名タスクは、署名直後に両方の埋め込みオフセットの CSF タグバイトを検証し、不一致があればビルドを失敗させます。CONFIG_FIT_CIPHER の有無にかかわらず、すべてのビルドは正常にパスし、この構成に関係なく、計算された SLD hab ブロック アドレス/FIT CSF オフセットはすべてのテストビルドでバイト単位で同一です。 私の推測ではCAAMジョブリングの競合が原因です。CONFIG_FIT_CIPHER CONFIG_AESを引く(このU-Bootバージョンでは別のバックエンドシンボルは不要です)、このSoCのランタイムDMESGはCAAMが他のAES/SHAで実際に使われていることを確認しています。私が見つけた最も関連性の高いドキュメントは、doc/imx/habv4/guides/mx8m_secure_boot.txtですv4.4.0以前のHABがクローズド設定でジョブリング/DECOマスターIDレジスタをロックする点に注意が必要ですが、これはこのオープンモードのCONFIG_FIT_CIPHER特有のケースを直接説明しているわけではありません。 質問: 1.i.MX8M Plus上のCONFIG_FIT_CIPHERとHABv4のCSF認証の間に既知のやり取りがあるのでしょうか?これはCAAMリソースに関連する問題でしょうか、それとも別の問題でしょうか(例えば、コンパイルされたバイナリのサイズやレイアウトによってFIT CSFコンポーネントの境界がずれてしまい、私の自己チェックでは検出できないようなずれが生じているなど。自己チェックはROMが独自に導出したオフセットではなく、私が計算したオフセットに対して検証を行うため)。 2. このSoC上では、CONFIG_FIT_CIPHERをHABv4 CSF署名と組み合わせても安全性が確認できるのでしょうか、それともこれは実際の制限事項なのでしょうか? 3. もしそれが根本原因だった場合、正しいCAAMジョブリングの割り当て/ロック解除手順を示すヒントはありますか? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 解決済みとして投稿します。誰かが二分を省く助けになるCASEからです。実際の修正は[https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756]に感謝します。私が見つけた直後に直接適用されました。 症状:通常のHAB署名済みimxブートで、hab_status "HABイベント情報なし!"と報告するベースラインはクリーンです。CONFIG_FIT_CIPHER=yを有効にして(AES-256で暗号化されたカーネルFITイメージをU-Bootで復号するU-Bootをサポートするためで、HABとは別の仕組みでSRKヒューズとは無関係)、hab_statusは毎回のブートで4つのイベント情報(2× HAB_INV_ASSERTION、2× HAB_INV_SIGNATURE)を報告し始めました。 二分割:変更した変数を一つずつ分離し、実際のハードウェアで毎回リビルド+リフラッシュ+hab_statusを行いCONFIG_FIT_CIPHERました。(FIT pubkey/AESキーのDTB埋め込みを無効にし、無関係なcmd/bootm.cを削除)まで変更しましたパッチや保持・落CONFIG_SYS_BOOTM_LEN――どれもマターではありませんでした。CONFIG_FIT_CIPHERだけがそうした)。 根本原因+修正:手動HAB署名ワークフローを移植したカスタムYoctoタスクでimx-bootを構築しました(SPL IVTを解析し、print_fit_hab.shでFITコンポーネントブロックを計算します。CSTで署名して自動ビルドステップに組み込む。そのタスクは、mkimage_imx8 自身のビルドによってビルドステージング ディレクトリに残された DTB コピーが既に正しく 16 バイト境界にアラインされていることを前提としていましたが、すべての構成で保証されているわけではありません。CONFIG_FIT_CIPHER U-Boot本体のコンパイルされたDTBサイズを変更し、私たちの場合は非アラインサイズに設定します。ずれたDTBは計算print_fit_hab.shすべてのFITコンポーネント境界を静かにシフトするため、CSTは誤ったバイト範囲に符号化します。我々が独自に構築時に行う自己チェック(計算したオフセットにCSFタグバイトが存在するかどうかの確認)は毎回問題なく合格していた。これはROMが独自に正しく定義する境界値と照合していたわけではなかった。本物のハードウェアだけがそれを捉えた。 修正:他のThreadでうまくいったことをミラーリングします。つまり、FITコンポーネントブロックを計算する直前にDTB上で明示的にpad_image.sh(imx-mkimage独自のスクリプト)を実行し、ステージングディレクトリの既存状態を信頼するのではなく、実際にパディングされていたこと(何もしない操作ではなかったこと)が確認され、hab_statusは再びクリーンな状態になり、フル機能が有効になりました。
View full article
TDA8954TH 无声音输出 您好! 我有几个音箱(Mackie Thump12),但它们没有低音输出。我更换了输出集成电路 TDA8954TH 和 10R 电阻。完全没有声音。还有其他人遇到过这款集成电路的问题吗? 我在速卖通上从不同的卖家那里订购了3个集成电路。 顺祝商祺! 约翰内斯 Re: TDA8954TH no sound output 你好,约翰内斯, TDA8954TH是一款已停产的旧产品,我们不再为此设备提供技术支持。或许其他使用者可以提供帮助。   BRs,托马斯
View full article
S32K388 TCP/IP 协议栈 5.0.0 无法正常工作 嗨@PavelL , 我之前使用以下配置成功运行了 TCP/IP 协议栈示例项目: • S32KDS 版本 3.6.5 • RTD(实时驱动程序)版本 7.0.0 • TCP/IP协议栈版本4.0.0 但是,升级到以下版本并执行相同的设置步骤后,却无法正常工作: • S32KDS 版本 3.6.8 • RTD(实时驱动程序)版本 7.0.1 • TCP/IP协议栈版本5.0.0 我已附上我的项目。再次感谢你的帮助。 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE , 我需要时间进行调查。我会尽力在本周内回复。 感谢您的理解。 顺祝商祺! 帕维尔 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE , 由于工作繁忙,回复有所延迟,敬请谅解。 根本原因是 EthIf_Cfg.c正如我们之前在这个帖子中讨论过的,S32K388 TCP/IP 堆栈 4.0.0 在编译时缺少 lwip 文件夹 该示例现在在我的 S32K388EVB-Q289 上运行正常。 总之,我对你的项目做了很多修改,但最关键的是 EthIf_Cfg 文件。所有修改后的文件都可以在附件的压缩包中找到。您可以自行查看更改。 请注意,所提供的代码不提供任何担保。 用补丁替换文件后,请不要忘记执行代码更新。 顺祝商祺! 帕维尔
View full article
Kinetis (KW3x/4x) Power Profile Tools for Automotive This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47) Power Profile Tools for Automotive. It will help you to estimate the power consumption in your Automotive application (keyfob/smartfob & anchor) and evaluate the battery life time of your solution. This page contains 3 dedicated power profile tools for: Bluetooth LE for the KW35/36 products in standalone. Bluetooth LE for the KW37/38/39 products in standalone. Bluetooth LE for the KW45/KW47 products in standalone. SmartFob application (BLE/KW45; UWB Ranger4; SE; motion sensor) SmartFob application (BLE/KW47; UWB Ranger5; SE; motion sensor)    1. KW35/36 Bluetooth LE power profiling standalone:  2. KW37/38/39 Bluetooth LE power profiling standalone:  This tool includes 3 different use cases to get a rough estimation of the Anchor and Keyfob/Smartphone power consumptions:    1- CCC mobile phone connected to the car and exchange packets to unlock the door of the car    2- SCA Keyfob connected to the car and exchange packets continuously    3- CCC Smartphone connected to the car and exchange packets continuously : 2 row modes 3. KW45/KW47 Bluetooth LE power profiling standalone: AN13230 Kinetis KW45 Bluetooth LE Power Consumption Analysis AN14554 Kinetis KW47 Bluetooth LE Power profile analysis release.pdf 4. SmartFob application (BLE/KW45; UWB Ranger4; SE; motion sensor) power profiling 5. SmartFob application (BLE/KW47; UWB Ranger5; SE; motion sensor) power profiling id:wireless-connectivity [start:July 31 2026]
View full article