Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
Add MCP to directly connect to CodeX for collaboration. Could you add an MCP to support direct use of CodeX or other agents to operate the IDE? The current method using Figma has Figma quota limitations, which is not very convenient.
查看全文
インターフェースを用いてキャッシュ位置へのフォールトインジェクションは、emcem で提供されます こんにちは、 @danielmartynek さん。 おはよう:-) キャッシュ位置への障害注入に関して質問があります。 キャッシュの位置に2ビットのフォルトを注入する必要がありますが、リファレンス・マニュアルに記載されている通り意味がよくわからず、私たちはNXP s32K394マイクロコントローラを使用しています。 キャッシュに障害を注入し、以下のような2ビットのエラーをキャッシュに取得するために、以下の関数を2回呼び出す必要があります。 もし私のやり方が間違っているなら、このインジェクションを行う例コードを教えていただけませんか?現在、私たちのプロジェクトではSAFパッケージを使っています。もしすでにこれらのフォールトインジェクションコードが存在するなら、SAFモジュールに提供されているメモリテストインターフェース(EIM)を使ってあらゆる種類のフォールトを注入するために参照すべきファイルを教えてください。 Re: Fault Injection to cache locations using an interface provide in emcem こんにちは、@Rudved_3366 さん。 この話題に関するあなたの2回目の投稿に返信しました: https://community.nxp.com/t5/S32K/Fault-Injection-to-cache-location-using-an-interface-provide-in/td-p/2419094 BR、ダニエル
查看全文
MCUXpresso 25.6: GDB infinite memory-read loop after Cortex-M0+ EXC_RETURN — workaround: backtrace l Environment IDE: MCUXpresso IDE 25.6 Debugger: GNU Arm GDB 15.2.90.20241130-git Toolchain: GNU Arm Toolchain 14.2.Rel1 Target: NXP LPC845, Arm Cortex-M0+ Debug probe: Onboard LPC-Link2 using LinkServer Host: Windows Problem GDB becomes unresponsive when debugging a Cortex-M0+ application that uses a synthetic exception stack frame to return from SysTick into Thread-mode code. The firmware executes an exception return using: bx lr with LR = 0xFFFFFFF9 (return to Thread mode using MSP). The synthetic exception frame contains a valid Thumb-mode destination PC and xPSR. The application operates on the physical target, but GDB becomes unresponsive after stopping at the destination function. Symptoms include: Variable hover inspection stops working. Memory views display ????????. GDB commands, including info threads, become unresponsive. The debug session generally requires termination and cleanup. The problem also occurs when using a hardware breakpoint at the destination rather than instruction-stepping across the exception return. Reproduction Start debugging the application normally. Stop immediately before the bx lr exception-return instruction. Place another breakpoint at the destination function, System(). Step across the exception return or continue to the destination breakpoint. GDB reaches the destination but subsequently becomes unresponsive. The failure is reproducible with the normal GDB configuration. Remote-protocol evidence Enabling remote-protocol tracing with: set logging file gdb-remote.log set logging overwrite on set logging enabled on set debug remote 1 reveals that GDB repeatedly performs the same sequence of remote memory reads: m1b4,4 -> 91010000 m1ba,4 -> 00000000 m1bc,4 -> 00000001 m1c0,4 -> f9ffffff m190,4 -> 07490868 This sequence repeats indefinitely. LinkServer acknowledges and responds successfully to the requests. The trace therefore does not indicate an ordinary communication timeout. Notably, the response at 0x1c0 contains 0xFFFFFFF9, the exception-return value. Confirmed workaround Entering the following command in GDB: set backtrace limit 1 prevents the observed failure in repeated testing. With this setting active: The debugger repeatedly crosses the same exception-return boundary. Both breakpoints function normally. Variable hover inspection works at the destination. The debug session remains responsive. The workaround also functions when placed in a GDB command file configured through: Debug Configurations → GDB Debugger → GDB command file No application or assembly modifications are necessary. Additional isolation The same target, debug probe, and IDE successfully debug conventional firmware. Calling the destination function without the synthetic exception-return shim also works. A conventional SysTick handler does not exhibit this failure. The problem appears specifically associated with GDB processing the execution state following the synthetic exception return. Expected behavior GDB should remain responsive after the exception return, permitting stepping, register inspection, memory inspection, and variable evaluation. If GDB cannot interpret the resulting stack frames, it should report an error or terminate unwinding rather than enter an indefinitely repeating memory-read sequence. Suspected cause The effectiveness of set backtrace limit 1 strongly suggests that GDB's ARM Cortex-M stack-frame unwinding or frame analysis is involved. The exact internal cause has not been established. Request Please investigate the interaction between GDB's ARM Cortex-M exception-frame handling and synthetic exception returns. In particular, determine why the debugger repeatedly reads the same target memory locations and whether frame unwinding can enter an unbounded loop. The workaround restores debugging functionality, but it restricts backtrace depth and should not be necessary for a valid exception-return sequence. Re: MCUXpresso 25.6: GDB infinite memory-read loop after Cortex-M0+ EXC_RETURN — workaround: backtra forgot the code clip: 0000015c : 15c: b4f0 push {r4, r5, r6, r7} 15e: 4640 mov r0, r8 160: 4649 mov r1, r9 162: 4652 mov r2, sl 164: 465b mov r3, fp 166: b40f push {r0, r1, r2, r3} 168: 4911 ldr r1, [pc, #68] @ (1b0 ) 16a: 6808 ldr r0, [r1, #0] 16c: 3001 adds r0, #1 16e: 6008 str r0, [r1, #0] 170: 2804 cmp r0, #4 172: dd03 ble.n 17c 174: f000 fa24 bl 5c0 178: f7ff ffcc bl 114 0000017c : 17c: 4d0d ldr r5, [pc, #52] @ (1b4 ) 17e: 4e0e ldr r6, [pc, #56] @ (1b8 ) 180: 4f0e ldr r7, [pc, #56] @ (1bc ) 182: b4ff push {r0, r1, r2, r3, r4, r5, r6, r7} 184: 480e ldr r0, [pc, #56] @ (1c0 ) 186: 4686 mov lr, r0 188: b500 push {lr} 18a: bd00 pop {pc}
查看全文
最新の電子商取引ライセンスは無効です。 Re: 最新的eb licesne无效 The error "ERROR: Processing プロセッシング (50019,41200,10246)" 通常、以下のいずれかの問題を示しています。 1.アクティベーションコードが無効になっているか、利用可能なライセンス数を使い果たしました。 2. アクティベーション応答ファイル(activation.xml)対象PCで生成されたアクティベーション要求ファイルと一致しません。 3. activation.xml ファイルは、Elektrobit の公式オフライン アクティベーション ポータルから生成されたものではありません。 オフラインでアクティベートしてみたら、うまくいきました。 Re: 最新的eb licesne无效 オフライン認証を使用している場合、これはエラーメッセージです。 Re: 最新的eb licesne无效 こんにちは、イーユアンさん 请告诉我特定错误信息,比如 EB Client License Administrator 1.5.1 は返されますか? アクティベーション コードを使用してアクティベートに成功しました。 よろしくお願いいたします ロビン
查看全文
Verify a csf header file is associated with a specific fit image. I have secure boot working and I understand roughly what Uboot is doing using esbc_validate. However, I'm trying to create an upgrade utility that verifies that a specific header file, generated with cst 2.x, is associated with a specific fit (kernel, dtbs, rootfs) image. Placing the csf security header at its correct offset, and placing the fit image at its offset works just fine for booting. However I want to verify those PRIOR to placing them in their respective locations.  I understand the public key is embedded in the csf so I have to extract that. I'm a little confused after that. I think I need to extract the RSA signature and use the extracted public key on that to get a hash, and somehow that hash is tied to the fit image, but its not simply a hash of the fit image? I've already managed to pull the SRKH from the blown fuses so I can compare that. At the moment Google/Gemini isn't being much help. Thoughts?  QorIQ LS1 Devices Re: Verify a csf header file is associated with a specific fit image. The signature is not just a hash of the FIT . For this secure-boot flow, it authenticates a SHA-256 digest of the CSF header, the image bytes specified by that header, the public key material, and the SG table if used. Validation also checks the key against the fused SRKH.  So, before installing either file , your utility must parse the candidate header, use its size and offset fields to select the correct bytes from the candidate FIT, calculate the digest over the complete signed data, and verify the extracted RSA signature with the validated public key. If verification passes, that header is associated with those authenticated FIT bytes. A FIT-only SHA-256 comparison will not work.
查看全文
Windows on MX95 Hi, Why can't I  see any information about  the MX95 on NXP's Windows IoT  web? https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/windows-10-11-iot-enterprise-for-i-mx-applications-processors:IMXWIN10IOT    Windows Re: Windows on MX95 Currently, i.MX95 is not listed among the supported devices/platforms on NXP's public Windows 10/11 IoT Enterprise BSP page, and no public i.MX95 Windows BSP is provided there.
查看全文
LS1043A maximum core temperature Hi, My LS1043AXE7QQB (105C rated) core (thermal diode reading) is running at 65C in normal operations of 25C ambiant. We have a production test of operating the system with ambiant temperature at 70C during 16h (once for each system). During this test, the core rises to 121C. We don't experience any problem and we are going to improve the thermal management to reduce that. What is the effect of operating the cpu over 105 for a short period and what would be the acceptable maximum core temp for 16h? Re: LS1043A maximum core temperature Hello, For the QorIQ Layerscape family (LS1043A, LS1046A, LX2160A — all share the same thermal rating framework): Parameter Value Source Maximum operating Tj 105°C Datasheet Absolute maximum / Storage Tstg 150°C (≤1008 h cumulative at 150°C) Datasheet Table — Absolute Maximum Ratings       The 105°C Tj(max) refers to the silicon junction temperature as measured by the internal thermal diode — which is exactly what your core temperature reading reflects. 2. Effect of Operating Above 105°C Official position from multiple support cases on the same processor family: "Operating above Tj(max) = 105°C risks device reliability degradation and is not a supported operating condition." "Exposing device to Absolute Maximum Ratings conditions for long periods of time may affect reliability or cause permanent damage." "The device must not operate at temperatures > 105°C." From a semiconductor physics standpoint, exceeding Tj(max) accelerates several well-known wearout mechanisms: Electromigration — metal interconnect migration, accelerates ~exponentially with temperature TDDB (Time-Dependent Dielectric Breakdown) — gate oxide degradation NBTI (Negative Bias Temperature Instability) — threshold voltage shift in PMOS Hot carrier injection — impacts transistor characteristics over time All of these follow Arrhenius kinetics: degradation rate roughly doubles every ~10°C above the qualification limit. At 121°C (16°C over the rated 105°C), degradation mechanisms run at approximately 3–4× the qualified rate. This does not cause immediate/catastrophic failure — the device will function — but it consumes lifetime reliability budget at an accelerated pace. The absence of observed failures during the test is expected: at 121°C, you are far below the 150°C storage temperature where physical damage occurs immediately. The impact is silent reliability erosion, not instant damage.   Regards
查看全文
LS1043Aの最大コア温度 こんにちは。私のLS1043AXE7QQB(定格105℃)のコア(サーマルダイオードの読み取り値)は、周囲温度25℃の通常動作時に65℃で動作しています。周囲温度70℃の環境でシステムを16時間稼働させる生産テストを実施しました(各システムにつき1回)。この試験中、中心部の温度は121℃まで上昇する。問題はなく、それを軽減するために熱マネジメントを改善していく予定です。CPUを105度以上で短時間動作させた場合の影響は何ですか?また、16時間動作させた場合の許容最大コア温度は何度ですか? Re: LS1043A maximum core temperature こんにちは、 QorIQ Layerscapeファミリ(LS1043A、LS1046A、LX2160A — すべて同じ熱評価フレームワークを共有しています): パラメータ バリュー 電源 最大動作温度Tj 105℃ データシート 絶対最大値 / ストレージTstg 150℃ (150℃での累積曝露時間が1008時間以下) データシート表 - 絶対最大定格       105℃のTj(max)は、内部サーマルダイオードによって測定されたシリコン接合部の温度を指しており、これはまさにコア温度の測定値が反映している値です。 2. 105℃以上での運転の影響 同じプロセッサファミリの複数のサポートケースからの公式見解: 「Tj(max) = 105℃を超える温度での動作は、デバイスの信頼性低下のリスクがあり、サポート対象外の動作条件です。 」 「機器を絶対最大定格の条件下に長時間さらすと、信頼性に影響を与えたり、永久的な損傷を引き起こしたりする可能性があります。 」 「この装置は105℃を超える温度では動作させてはならない。」 半導体物理学の観点から見ると、Tj(max)を超えると、いくつかのよく知られた劣化メカニズムが加速される。 エレクトロマイグレーション(金属配線の移動)は、温度の上昇に伴い指数関数的に加速する。 TDDB (時間依存型誘電破壊)—ゲート酸化膜の劣化 NBTI (負バイアス温度不安定性)— PMOSにおけるしきい値電圧の変動 ホットキャリア注入― トランジスタの特性に時間とともに影響を与える これらはすべてアレニウスの速度論に従います。つまり、劣化速度は、認定限界温度を約10℃超えるごとにほぼ倍増します。121℃(定格105℃より16℃高い)では、劣化メカニズムは認定速度の約3~4倍の速度で進行します。これは即座に壊滅的な故障を引き起こすわけではなく、デバイスは機能し続けるが、耐用年数における信頼性予算を加速的に消費することになる。 試験中に故障が観測されなかったのは当然のことです。121℃という温度は、物理的な損傷が即座に発生する保管温度である150℃をはるかに下回っています。その影響は、即座に損傷を与えるのではなく、静かに信頼性を低下させるという形で現れる。   よろしくお願いします。
查看全文
Windows on MX95 您好,为什么我在NXP的Windows IoT网站上看不到关于MX95的任何信息? https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/windows-10-11-iot-enterprise-for-i-mx-applications-processors:IMXWIN10IOT    Windows Re: Windows on MX95 目前,NXP 的公开 Windows 10/11 IoT 企业 电路板支持包 页面上并未列出 i.MX95 作为支持的设备/平台,也没有提供公开的 i.MX95 Windows 电路板支持包。
查看全文
MX95上のWindows こんにちは、なぜNXPのWindows IoTウェブ上でMX95に関する情報が全く見られないのですか? https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/windows-10-11-iot-enterprise-for-i-mx-applications-processors:IMXWIN10IOT    Windows Re: Windows on MX95 現在、i.MX95はNXPの公開Windows 10/11 IoT Enterprise BSPページでのサポートデバイス/プラットフォームにリストアップされておらず、公開のi.MX95 Windows BSPも提供されていません。
查看全文
LS1043A 最高核心温度 您好,我的 LS1043AXE7QQB(额定温度 105°C)核心(热二极管读数)在 25°C 的环境温度下正常运行时温度为 65°C。我们对系统进行了生产测试,在环境温度为 70 摄氏度的条件下运行 16 小时(每个系统一次)。在此测试过程中,核心温度升至 121 摄氏度。我们目前没有遇到任何问题,我们将改进散热管理以减少此类问题。CPU 短时间内运行温度超过 105 度会有什么影响?16 小时可接受的最高核心温度是多少? Re: LS1043A maximum core temperature 你好, 对于 QorIQ Layerscape 系列(LS1043A、LS1046A、LX2160A——均采用相同的热额定值框架): 参数 Value 源代码 最大工作温度 105 °C 数据手册 绝对最大值/存储温度 150°C (150°C下累计≤1008小时) 数据表表格——绝对最大额定值       105°C Tj(max) 指的是内部热二极管测量的硅结温度——这正是您的核心温度读数所反映的。 2. 高于105°C运行的影响 来自多个针对同一处理器系列的支持案例的官方立场: “在高于 Tj(max) = 105°C 的温度下运行会降低设备的可靠性,因此不被支持。 ” “长时间将设备暴露在绝对最大额定功率条件下可能会影响其可靠性或造成永久性损坏。 ” “该设备的工作温度不得高于 105°C。” 从半导体物理学的角度来看,超过 Tj(max) 会加速几种众所周知的损耗机制: 电迁移——金属互连线的迁移,随温度呈指数级加速 TDDB (时变介质击穿)——栅极氧化层退化 NBTI (负偏压温度不稳定性)——PMOS器件的阈值电压漂移 热载流子注入——随时间推移影响晶体管特性。 所有这些都遵循阿伦尼乌斯动力学:降解速率大约每高于合格限值 10°C 就翻一番。在 121°C(比额定温度 105°C 高 16°C)时,降解机制的运行速度约为合格速率的 3-4 倍。这不会导致立即/灾难性故障——设备仍可运行——但会加速消耗其使用寿命可靠性预算。 测试期间未观察到故障是意料之中的:在 121°C 时,远低于 150°C 的存储温度,在 150°C 时会立即发生物理损坏。这种影响表现为可靠性悄然下降,而不是瞬间损坏。   此致
查看全文
PaxデバイスAPDU NFCとMifare Ultralight C こんにちは、 私はPaxデバイスで開発中で、Mifare ULTRALIGHT C(MF0ICU2)を管理したいと考えています。 PaxデバイスはカスタムのPayDroid OSを使用しており、標準的なAndroidではありません。そのため、私はNFCのAndroidライブラリを持っていません。 IPCCをライブラリ経由で公開するNeptuneLiteAPIというものをインストールする必要があります。 まず、命名規則と標準規格について少し混乱しています。APIが話している内容: ISO14443 AまたはB 1、2、または3 M1カード 通常、Ultralight Cは14443 Type Aですが、このオプションではカードを読み取れず、「M1カード」オプションで読み取れます。M1カードとは何ですか?クラシック1kのことですか? ドキュメントにはAPDUを使い、この種の呼び出しを実行するコマンドを公開する必要があると書かれています カードの読み書き(M1機能付き)に成功し、ライブラリはカード対応の互換性モードを使うデフォルトの読み書き方法を公開します 今、認証を設定し、APDUコマンドを使ってチップにコマンドを送ろうとしています。 以下は私が使えるコードの簡略化です iPicc = getDal().getPicc(piccType); iPicc.open(); while(){ PiccCardInfo cardInfo = iPicc.detect(EDetectMode.ONLY_M); if(cardInfo!=null){ //Read : works byte[] page0=iPicc.m1Read((byte) 0); // Write : works iPicc.m1Write((byte)(13),hexStringToByteArray("AAAAAAAA000000000000000000000000")); } 執筆に関しては3つの方法があります。 byte[] :  isoCommand(byte cid, byte[] send) ApduRespInfo : isoCommandByApdu(バイト cid, ApduSendInfo apduSendInfo) byte[] cmdExchange(byte[] dataIn, int recvLen) これらの方法はすべてAPDUコマンドを求めます。 もし私の理解が正しければ、Mifare Ultralight CはAPDUを尊重していないのに、APDUしか方法がないということですか? あるウェブサイトで、「FF」クラスを使うとチップに直接指示を送れるとわかりました。 しかし、どのコマンドを送信すればいいのか分からず、いくつか試してみた。 エラーが発生しています(残念ながら、これらは標準的なものではなく、NeptuneLiteAPiです)。 センサーエリアに特定のカードが存在しない、またはカードが有効化されていないPICC#3(検索カードエラーではありません) PICC#97(予期せぬエラー) でも不思議なことに、カードの直前で検出され読み書きに成功しているので、カードはしっかり「コネクテッド」されているのです。 直接命令、APDU命令、CRC計算など、いくつかのコマンドを試しましたが、どれも機能しませんでした。 //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3004")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000A802")); // Avec CRC => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("300002A8")); // Avec CRC inversé => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.cmdExchange(CryptageUtils.hexStringToByteArray("3000A802"),17); // Card is not activated. PICC#3(not search card error) // byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30000000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff300000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff30000F")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("FFCA00000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3001")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) もしどなたか助けてくれたり、正しい道に導いていただけるなら、本当にありがたいです。 よろしくお願いいたします。 Re: Pax device APDU NFC & Mifare Ultralight C こんにちは@thibaut @Antoine1 @Erableto 、 この問題の解決策は見つかりましたか?私も同じ問題に直面しました。Mifare Ultralight EV1ではカウンターが読み取れません。主にcmdExchangeで試しましたが、NeptuneLiteライブラリの他の方法も試しましたが、PICC#3や#97のようなエラーが必ず出ます。 Re: Pax device APDU NFC & Mifare Ultralight C こんにちは@thibautと@Erableto 、 質問の答えは見つかりましたか? なぜなら、私たちも同じ問題を抱えているからです。 😊 よろしくお願いします。 Re: Pax device APDU NFC & Mifare Ultralight C こんにちは、ティボー。解決できましたか?私もあなたと同じことをしていますが、Mifare Classic 1kを使っていて、同じ問題を抱えています。私も助けを求めています。 進展があれば随時ご報告します。一緒にやり遂げられるといいな。 よろしくお願いします。
查看全文
Pax device APDU NFC & Mifare Ultralight C Hello, I'm developing on Pax device and I want to manage Mifare ULTRALIGHT C (MF0ICU2) Pax devices use a custom PayDroid OS and not a standard android, consequently, I don't have NFC android libraries.  I need to install something call NeptuneLiteAPI that expose IPCC via a library. First, I'm a little bit lost with naming convention & standard. Api is speaking about : ISO14443 A or B 1,2 or 3 M1 card Normally, Ultralight C is 14443 Type A, but I can't read my card with this option, I succeed to read with "M1 Card" option. What is a M1 card ? it it Classic 1k? Documentation mention that I need to use APDU and expose some command to execute this kind of call I succeed to read and write the card (with M1 function), the library expose default read/write method that use compatibility mode compatible with my card Now, i'm trying to configure authentication and to send some command to the chip, via the APDU command. Here is a simplication of the code I can use iPicc = getDal().getPicc(piccType); iPicc.open(); while(){ PiccCardInfo cardInfo = iPicc.detect(EDetectMode.ONLY_M); if(cardInfo!=null){ //Read : works byte[] page0=iPicc.m1Read((byte) 0); // Write : works iPicc.m1Write((byte)(13),hexStringToByteArray("AAAAAAAA000000000000000000000000")); } For writing, i have 3 methods: byte[] :  isoCommand(byte cid, byte[] send) ApduRespInfo : isoCommandByApdu(byte cid, ApduSendInfo apduSendInfo) byte[] cmdExchange(byte[] dataIn, int recvLen) All these method ask for an APDU command. if I understood well, Mifare Ultralight C does't respect APDU but APDU is the only way? And on some website, I found that using instruction class "FF", I can sent direct instruction to chip. But I'm lost in the command I need to send, and I try several. I have the error (unfortunatly, they are the one NeptuneLiteAPi and not a standard one). No specific card in sensing area, or card is not activated PICC#3(not search card error) PICC#97(unexpected error) But it's strange, I well detect the card just before and succeed to read/write, so the card is well "connected" I tried several commands (direct instruction, APDU instruction, CRC computation), nothing works. //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3004")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000A802")); // Avec CRC => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("300002A8")); // Avec CRC inversé => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.cmdExchange(CryptageUtils.hexStringToByteArray("3000A802"),17); // Card is not activated. PICC#3(not search card error) // byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30000000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff300000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff30000F")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("FFCA00000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3001")); // No specific card in sensing area, or card is not activated PICC#3(not search card error)  If anyone can well me or put me on the right way, I would really appreciate. Regards. Re: Pax device APDU NFC & Mifare Ultralight C Hello @thibaut @Antoine1 @Erableto, did you ever find a solution to this issue? I stumbled upon the same problem: I cannot read counters on a Mifare Ultralight EV1; I tried with cmdExchange mainly, but also with all other methods provided by NeptuneLite library, but I always get errors like PICC#3 or #97. Re: Pax device APDU NFC & Mifare Ultralight C Hello @thibaut and @Erableto, did you find the answer to your question? Because we have the same problem on our side. 😊 Regards. Re: Pax device APDU NFC & Mifare Ultralight C Hi Thibaut. Did you figure it out? I'm doing the same as you but with a Mifare Classic 1k and I have the same problems. I'm looking for help too. I will keep you posted with any progress I manage to make. I hope we can get this done together. Regards.
查看全文
Pax 设备 APDU NFC 和 Mifare Ultralight C 你好, 我正在开发 Pax 设备,并且想要管理Mifare ULTRALIGHT C (MF0ICU2) 卡。 Pax 设备使用定制的 PayDroid 操作系统,而不是标准的安卓系统,因此,我没有 NFC 安卓库。 我需要安装一个名为 NeptuneLiteAPI 的库,该库可以公开 IPCC。 首先,我对命名规则和标准有点困惑。API 指的是: ISO14443 A 或 B 1、2 或 3 M1卡 通常情况下,Ultralight C 是 14443 Type A,但我无法使用此选项读取我的卡,使用“M1 Card”选项可以成功读取。M1卡是什么?它是经典的1000K卡吗? 文档提到我需要使用 APDU 并公开一些命令来执行此类调用。 我成功地对卡进行了读写操作(使用 M1 函数),该库提供的默认读写方法使用了与我的卡兼容的兼容模式。 现在,我正在尝试配置身份验证,并通过 APDU 命令向芯片发送一些命令。 以下是我可以使用的代码的简化版本 iPicc = getDal().getPicc(piccType); iPicc.open(); while(){ PiccCardInfo cardInfo = iPicc.detect(EDetectMode.ONLY_M); if(cardInfo!=null){ //Read : works byte[] page0=iPicc.m1Read((byte) 0); // Write : works iPicc.m1Write((byte)(13),hexStringToByteArray("AAAAAAAA000000000000000000000000")); } 写作方面,我有三种方法: 字节[] : isoCommand(字节 cid, 字节[] send) ApduRespInfo : isoCommandByApdu(字节 cid, ApduSendInfo apduSendInfo) 字节[] cmdExchange(字节[] dataIn, int recvLen) 所有这些方法都需要 APDU 命令。 如果我理解正确的话,Mifare Ultralight C 不支持 APDU,但 APDU 却是唯一的传输方式? 我在一些网站上发现,使用指令类“FF”,可以直接向芯片发送指令。 但我不知道该发送什么命令,我尝试了好几个。 我遇到了错误(不幸的是,它们是 NeptuneLiteAPi 而不是标准版本)。 感应区域内未找到特定卡,或卡未激活 PICC#3(非搜索卡错误) PICC#97(意外错误) 但很奇怪,我之前明明能检测到这张卡,而且读写操作也成功了,所以这张卡应该是“连接正常”的。 我尝试了几个命令(直接指令、APDU 指令、CRC 计算),但都无效。 //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3004")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000")); // PICC#97(unexpected error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000A802")); // Avec CRC => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("300002A8")); // Avec CRC inversé => No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.cmdExchange(CryptageUtils.hexStringToByteArray("3000A802"),17); // Card is not activated. PICC#3(not search card error) // byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("30000000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff300000")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("ff30000F")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("FFCA00000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3000000004")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) //byte[] cmd2 = iPicc.isoCommand(cardInfo.getCID(), CryptageUtils.hexStringToByteArray("3001")); // No specific card in sensing area, or card is not activated PICC#3(not search card error) 如果有人能指点我一下或者给我指明正确的方向,我将不胜感激。 问候。 Re: Pax device APDU NFC & Mifare Ultralight C 你好@thibaut @Antoine1 @Erableto , 你找到解决这个问题的方法了吗?我也遇到了同样的问题:我无法读取 Mifare Ultralight EV1 上的计数器;我主要尝试使用 cmdExchange,但也尝试了 NeptuneLite 库提供的所有其他方法,但我总是收到类似 PICC#3 或 #97 的错误。 Re: Pax device APDU NFC & Mifare Ultralight C 你好@thibaut和@Erableto , 你找到问题的答案了吗? 因为我们这边也存在同样的问题。 😊 此致问候 Re: Pax device APDU NFC & Mifare Ultralight C 你好,Thibaut。你弄明白了吗?我和你做的一样,但我用的是 Mifare Classic 1k 卡,也遇到了同样的问题。我也需要帮助。 我会及时向您汇报任何进展。我希望我们能一起完成这件事。 此致问候
查看全文
FRDM i.MX 95 Pro Hands-On: NPU Inference with eIQ Neutron Introduction This hands-on video explains how to take a trained AI model and deploy it for NPU-accelerated inference using eIQ Neutron on the FRDM i.MX 95 PRO development board. YOLOv8n is used as the example model. The video covers the complete workflow, including host setup, model export, calibration, INT8 quantization, Neutron compilation, board deployment, benchmarking, and troubleshooting. By the End of This Training, You Will Be Able To Understand the main components of the eIQ Neutron-S hardware and software stack. Download and export a YOLOv8n model to TFLite. Quantize the model to INT8 for Neutron NPU execution. Compile the quantized model for the i.MX 95 target. Review compiler statistics and determine which operations are delegated to the NPU. Deploy the model, delegate, driver, and firmware to the board. Run CPU and NPU benchmarks. Compare inference latency and calculate the NPU speed-up. Hardware and Prerequisites Before starting the training, verify that you have the required development board, host system, network connection, model, calibration data, and software tools. Development Board FRDM i.MX 95 PRO development board. NXP BSP LF6.18.20 2.0.0. eIQ Neutron runtime compatible with Neutron SDK 3.2.1 or later. TensorFlow Lite 2.19.0 benchmark application. Ethernet or USB-CDC connectivity. SSH and SCP access to the board. Root access on the target system. Linux Host Computer Ubuntu 20.04 or Ubuntu 22.04 is recommended. Python 3.8 or later. Python virtual environment support. SSH and SCP command-line tools. Sufficient storage for the SDK, models, calibration images, and generated artifacts.     Watch the Complete Training Video Watch the video from beginning to end and execute the commands in the presented order. Each stage generates an artifact required by the next stage. (function() { var wrapper = document.getElementById('lia-vid-6406503147112w960h540r369'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)     Command Cheat Sheet The following commands are organized in execution order. Replace placeholders such as with the values for your environment. 1. Download and Configure the Neutron SDK # Extract the SDK archive unzip eiq-neutron-sdk-linux-3.2.1.zip # Enter the SDK directory cd eiq-neutron-sdk-linux-3.2.1 # Add the SDK tools to PATH for the current terminal export PATH="$PWD/bin:$PATH" # Optional: make the PATH configuration persistent echo 'export PATH="/path/to/eiq-neutron-sdk-linux-3.2.1/bin:$PATH"' >> ~/.bashrc # Reload the shell configuration source ~/.bashrc # Verify the SDK tools tflite-profiler --help tflite-quantizer --help neutron-compiler --help   2. Create the Python Environment # Create a Python virtual environment python3 -m venv .venv # Activate the virtual environment source .venv/bin/activate # Upgrade pip python3 -m pip install --upgrade pip # Install the required packages pip install generate-parameter-library-py \ ultralytics \ hf \ ai-edge-litert \ litert_torch \ numpy \ opencv-python   3. Download the YOLOv8n Model # Download the trained YOLOv8n weights hf download Ultralytics/YOLOv8 yolov8n.pt --local-dir . # Verify the downloaded model ls -lh yolov8n.pt   4. Export YOLOv8n to TFLite # Export the PyTorch model to TFLite yolo export model=yolov8n.pt format=tflite # Locate the generated TFLite model find . -name "*.tflite" -type f # Update the following commands if your exported # model uses a different file name or directory.   5. Download the COCO Calibration Dataset # Create a directory for the calibration dataset mkdir -p coco cd coco # Download the COCO training images wget --no-check-certificate \ http://images.cocodataset.org/zips/train2017.zip # Extract the images unzip train2017.zip # Return to the project directory cd .. # Verify the image directory find ./coco/train2017 -type f -name "*.jpg" | head   6. Create the Calibration Conversion Script Save the following script as jpg2bin.py . It converts the JPEG calibration images into raw binary tensors expected by the profiler. #!/usr/bin/env python3 import argparse import glob import os import random import cv2 import numpy as np def letterbox(image, new_shape=640, color=(114, 114, 114)): height, width = image.shape[:2] ratio = min(new_shape / height, new_shape / width) resized_height = int(round(height * ratio)) resized_width = int(round(width * ratio)) resized = cv2.resize( image, (resized_width, resized_height), interpolation=cv2.INTER_LINEAR, ) canvas = np.full( (new_shape, new_shape, 3), color, dtype=np.uint8, ) top = (new_shape - resized_height) // 2 left = (new_shape - resized_width) // 2 canvas[ top:top + resized_height, left:left + resized_width, ] = resized return canvas def main(): parser = argparse.ArgumentParser( description="Convert JPEG images to YOLOv8n calibration tensors." ) parser.add_argument( "--images", default="./coco/train2017", help="Directory containing the calibration JPEG images.", ) parser.add_argument( "--out", default="./calib_yolov8n", help="Output directory for the binary tensors.", ) parser.add_argument( "--num", type=int, default=1000, help="Maximum number of calibration images.", ) parser.add_argument( "--size", type=int, default=640, help="Model input width and height.", ) parser.add_argument( "--shuffle", action="store_true", help="Shuffle the image list before selecting images.", ) args = parser.parse_args() os.makedirs(args.out, exist_ok=True) files = sorted( glob.glob(os.path.join(args.images, "*.jpg")) ) if args.shuffle: random.seed(0) random.shuffle(files) files = files[:args.num] if not files: raise RuntimeError( f"No JPEG images were found in {args.images}" ) for index, file_path in enumerate(files): image = cv2.imread(file_path) if image is None: print(f"Skipping unreadable image: {file_path}") continue # Convert BGR to RGB. image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) # Letterbox resize to 640 x 640. image = letterbox(image, args.size) # Convert to float32 and normalize to [0, 1]. tensor = image.astype(np.float32) / 255.0 # Add batch dimension. # Final layout: 1 x 640 x 640 x 3, NHWC. tensor = np.expand_dims(tensor, axis=0) output_path = os.path.join( args.out, f"calib_{index:05d}.bin", ) tensor.tofile(output_path) print( f"Calibration tensors written to: {args.out}" ) if __name__ == "__main__": main() # Make the script executable chmod +x jpg2bin.py # Generate up to 1000 calibration tensors python3 jpg2bin.py \ --images ./coco/train2017 \ --out ./calib_yolov8n \ --num 1000 \ --size 640 \ --shuffle # Count the generated binary files find ./calib_yolov8n -type f -name "*.bin" | wc -l # Check the size of a generated tensor ls -lh ./calib_yolov8n | head   7. Inspect the TFLite Input and Output Tensors python3 - <<'PY' from ai_edge_litert.interpreter import Interpreter model_path = "yolov8n.tflite" interpreter = Interpreter(model_path=model_path) interpreter.allocate_tensors() print("Input details:") for tensor in interpreter.get_input_details(): print(tensor) print("\nOutput details:") for tensor in interpreter.get_output_details(): print(tensor) PY Record the exact input tensor name reported by the model. Replace serving_default_args_0 in the profiling command if your model uses a different name.   8. Profile the Floating-Point TFLite Model # Replace serving_default_args_0 if the model # reports a different input tensor name. tflite-profiler \ --input yolov8n.tflite \ --dataset serving_default_args_0,calib_yolov8n \ --output yolov8n_profile.csv # Verify that the profiling CSV was generated ls -lh yolov8n_profile.csv # Preview the beginning of the profile head yolov8n_profile.csv   9. Quantize the Model to INT8 # Generate the INT8 TFLite model tflite-quantizer \ --input yolov8n.tflite \ --profile yolov8n_profile.csv \ --output yolov8n_quant.tflite # Compare the model file sizes ls -lh yolov8n.tflite yolov8n_quant.tflite   10. Verify the Quantized Model python3 - <<'PY' from ai_edge_litert.interpreter import Interpreter model_path = "yolov8n_quant.tflite" interpreter = Interpreter(model_path=model_path) interpreter.allocate_tensors() print("Quantized input details:") for tensor in interpreter.get_input_details(): print("Name:", tensor["name"]) print("Shape:", tensor["shape"]) print("Data type:", tensor["dtype"]) print("Quantization:", tensor["quantization"]) print() print("Quantized output details:") for tensor in interpreter.get_output_details(): print("Name:", tensor["name"]) print("Shape:", tensor["shape"]) print("Data type:", tensor["dtype"]) print("Quantization:", tensor["quantization"]) print() PY   11. Compile the Model for the Neutron NPU # Compile the INT8 model for the i.MX 95 Neutron NPU neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron.tflite \ --target imx95 # Verify the generated model ls -lh yolov8n_neutron.tflite Generate Compiler Statistics # Generate compiler and delegation statistics neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron_stats.tflite \ --target imx95 \ --dump-statistics # Review the compiler output and record: # 1. Number of delegated nodes # 2. Number of CPU fallback nodes # 3. Unsupported operators # 4. Generated NeutronGraph partitions Create a Profiling Build # Compile a profiling-enabled model neutron-compiler \ --input yolov8n_quant.tflite \ --output yolov8n_neutron_prof.tflite \ --target imx95 \ --use-profiling # Verify all generated models ls -lh yolov8n_quant.tflite \ yolov8n_neutron.tflite \ yolov8n_neutron_prof.tflite   12. Configure the Board IP Address # Replace the example address with the board IP address export BOARD_IP="192.168.1.100" # Verify network connectivity ping -c 4 "$BOARD_IP" # Test the SSH connection ssh root@"$BOARD_IP"   13. Create the Deployment Directory # Create the working directory remotely ssh root@"$BOARD_IP" \ "mkdir -p /root/neutron_demo"   14. Copy Runtime Artifacts to the Board The driver, delegate, and firmware may already be included in the BSP. Copy them only when the required or matching versions are not already installed. # Copy the Neutron driver scp libNeutronDriver.so \ root@"$BOARD_IP":/lib/ # Copy the Neutron delegate scp libneutron_delegate.so \ root@"$BOARD_IP":/usr/lib/ # Copy the Neutron firmware scp NeutronFirmware.elf \ root@"$BOARD_IP":/lib/firmware/ # Copy the plain INT8 model for the CPU baseline scp yolov8n_quant.tflite \ root@"$BOARD_IP":/root/neutron_demo/ # Copy the Neutron-compiled model scp yolov8n_neutron.tflite \ root@"$BOARD_IP":/root/neutron_demo/ # Optional: copy the profiling-enabled model scp yolov8n_neutron_prof.tflite \ root@"$BOARD_IP":/root/neutron_demo/   15. Verify the Files on the Board # Connect to the board ssh root@"$BOARD_IP" # Enter the deployment directory cd /root/neutron_demo # Verify the models ls -lh /root/neutron_demo/ # Check the driver ls -lh /lib/libNeutronDriver.so # Check the delegate ls -lh /usr/lib/libneutron_delegate.so # Check the firmware ls -lh /lib/firmware/NeutronFirmware.elf # Refresh the shared-library cache ldconfig # Verify that the delegate is visible to the loader ldconfig -p | grep -i neutron   16. Check the BSP and Runtime Environment # Display the Linux distribution and BSP information cat /etc/os-release # Display the kernel version uname -a # Search for Neutron-related kernel messages dmesg | grep -i neutron # Search for firmware-related messages dmesg | grep -i firmware # Locate the TensorFlow Lite benchmark application find /usr/bin -name "benchmark_model*" -type f 2>/dev/null   17. Run the CPU Baseline cd /root/neutron_demo /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_quant.tflite \ --num_threads=4 \ --num_runs=50 Record the average inference latency, minimum latency, maximum latency, initialization time, and memory information reported by the benchmark.   18. Run the NPU Benchmark cd /root/neutron_demo /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so \ --num_runs=50 Confirm that the benchmark output reports that the external delegate was loaded and that one or more model partitions were delegated.   19. Save Benchmark Results # Save the CPU benchmark output /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_quant.tflite \ --num_threads=4 \ --num_runs=50 \ 2>&1 | tee cpu_benchmark.txt # Save the NPU benchmark output /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model \ --graph=yolov8n_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so \ --num_runs=50 \ 2>&1 | tee npu_benchmark.txt # Review the saved results cat cpu_benchmark.txt cat npu_benchmark.txt   20. Calculate the NPU Speed-Up Use the average latency reported by each benchmark: Speed-up = CPU average latency / NPU average latency Example: CPU average latency = 100 ms NPU average latency = 10 ms Speed-up = 100 / 10 Speed-up = 10x   Required Deployment Artifacts Artifact Example File Purpose Neutron driver libNeutronDriver.so Communicates with the Neutron firmware and passes model buffers, weights, kernels, and input or output data. Neutron delegate libneutron_delegate.so Connects TensorFlow Lite to the Neutron runtime and delegates supported NeutronGraph operations to the NPU. Neutron firmware NeutronFirmware.elf Runs on the dedicated RISC-V core and executes the generated Neutron microcode. Quantized TFLite model yolov8n_quant.tflite Provides the CPU baseline and serves as the input to the Neutron compiler. Neutron-compiled model yolov8n_neutron.tflite Contains NeutronGraph operations generated for NPU execution.   Troubleshooting Use the following table to identify common host, model, compilation, deployment, and runtime problems. Area Problem Possible Cause Recommended Solution Host setup SDK commands are not found. The SDK bin directory is not included in PATH . Run export PATH="$PWD/bin:$PATH" from the SDK directory. Add the absolute SDK path to ~/.bashrc if the configuration must persist. Python environment A required Python module cannot be imported. The virtual environment is not active or the package was installed in a different environment. Run source .venv/bin/activate . Verify the active interpreter with which python3 , and reinstall the missing dependency with pip install PACKAGE_NAME . Model export The expected yolov8n.tflite file cannot be found. The exporter created a subdirectory or used a different filename. Run find . -name "*.tflite" -type f . Update the following commands to use the actual exported model path. Calibration No calibration binary files are generated. The image directory is incorrect or does not contain JPEG files. Verify the directory with find ./coco/train2017 -name "*.jpg" | head . Pass the correct directory through the --images argument. Calibration The calibration tensor has the wrong shape or size. The resize, batch dimension, layout, or data type is incorrect. Confirm an NHWC tensor with shape 1 x 640 x 640 x 3 , RGB channel order, float32 data, and values normalized to [0, 1] . Calibration The quantized model produces inaccurate predictions. The calibration preprocessing differs from inference preprocessing. Verify letterbox resizing, padding color, RGB conversion, normalization, tensor layout, input size, and data type. Use representative images that match the intended application. Profiler The profiler reports an invalid or unknown input tensor. The tensor name in --dataset does not match the model input name. Inspect the model input details with the TFLite interpreter. Replace serving_default_args_0 with the exact name reported by the model. Profiler The profiler cannot read the calibration files. The dataset path is incorrect, the folder is empty, or the binary format does not match the input tensor. Verify the folder path, count the files, and confirm the expected number of bytes for each tensor. Quantization The quantized model still uses floating-point tensors. The model was not fully quantized or the generated profile is incomplete. Re-run profiling with valid calibration data. Inspect the input, output, and intermediate tensor data types before compiling the model. Compilation neutron-compiler fails. The input model is invalid, not INT8, or contains unsupported quantization parameters. Confirm that the input is the quantized TFLite model. Inspect its tensor types and quantization parameters, then run the compiler again with statistics enabled.   Conclusion Congratulations! You have completed the end-to-end workflow for deploying and running an AI model on the eIQ Neutron-S NPU integrated into the FRDM i.MX 95 PRO. Throughout this training, you learned how to prepare the Linux host environment, export YOLOv8n to TFLite, build a representative calibration dataset, quantize the model to INT8, and compile it for the i.MX 95 target. You also learned how to transfer the required runtime artifacts to the board and compare CPU and NPU inference performance. This workflow is not limited to YOLOv8n. You can use the same process as a starting point for deploying your own computer vision models. However, each model must be evaluated individually because input formats, preprocessing requirements, quantization behavior, and operator support may differ. Recommended Next Steps Validate the accuracy of the INT8 model against the original floating-point model. Review the compiler statistics to identify unsupported operations and CPU fallback sections. Measure end-to-end application performance, including preprocessing, inference, and post-processing. Test the workflow with your own model and a calibration dataset that represents your real application. Use a profiling-enabled build to identify the most expensive layers and potential performance bottlenecks. FRDM-IMX9 FRDM-Training Hands-On Training i.MX Application Processors
查看全文
求助:S32K312 上的 HSE 固件刷新 您好,NXP团队: 我目前正在研究S32K312上的HSE固件。我已经有了HSE固件的BIN文件,但我不知道如何正确地将其刷写到S32K312上。 我尝试使用 PEmicro 烧录 BIN 文件 ,但失败了。我还尝试 在 S32 Design Studio 中使用 IVT 配置 ,但当我选择 S32K312 时 ,它显示“不支持的处理器”。 我已经查阅了所有可用的示例和帖子,但我仍然卡在 HSE 固件刷写这一步。 请问能否提供在S32K312上刷入HSE BIN固件并使HSE正常运行的正确且最简短的步骤? 请具体指导我如何以及在哪里刷入 BIN 文件,以及刷入后需要做什么。 (我已将 Bin 文件打包在 Zip 文件中),请查收。 @nxp 谢谢,此致敬礼! 索赫尔·贾卡蒂 Re: Help Required: HSE Firmware Flashing on S32K312 嗨@Mohmedsohel 您是否已经查看过S32K3 MCU 通用 HSE 演示示例中提供的 S32K344_HSE_FW_INSTALL 演示? 另外,您提到您尝试使用 S32 配置工具中的 IVT 工具。但是,该工具不支持 S32K3 设备。对于 S32K3,可以直接在 S32DS 项目的“项目设置”→“启动代码”→“startup_cm7.s”下修改 IVT。 BR,VaneB
查看全文
Fault Injection to cache location using an interface provide in emcem Hello team, I have addition question to below query (what values to select as arguments for eMcem_setupinjectionChannel - NXP Community😞 I need to inject a 2-bit fault in Cache location but I'm not sure what it means as mentioned in the reference manual and we use NXP s32K394 microcontroller: I need to call below function 2 times to inject the faults in cache and get the 2-bit error in cache like below:  If I'm doing wrongly, could you please share the example code how to do this injection, and currently we are using SAF package in our project, so if there are already fault injection code exists for the these, please share which file I need to refer to inject all kind of faults using (EIM) for memory test interface which is provided in SAF module. Re: Fault Injection to cache location using an interface provide in emcem Hello @Rudved_3366, I haven’t found an example of this cache injection, but here it is in a nutshell: Before injecting the CM7_0 I-cache tag double-bit error, verify that the relevant I-cache error-bank entries (IEBRn) are available and unlocked. I tested it on S32K344, which I have on the bench, I injected:  if (eMcem_SetupInjectionChannel(EMCEM_EIM_CH_3, 1, 2 ) != (Std_ReturnType)E_OK) { while (1U); } if (eMcem_InjectFault(EMCEM_EIM_CH_3) != (Std_ReturnType)E_OK) { while (1U); } Then, in the handler, disable the EIM. void BusFault_Handler(void) { if(IP_EIM->EIMCR & EIM_EIMCR_GEIEN_MASK) { IP_EIM->EIMCR = EIM_EIMCR_GEIEN(0); } } NOTE that the recovery code (such as the vector table referenced by VTOR, the exception handler, and whatever the handler calls) must not be in a cacheable region, because we do not want the error to be injected again during recovery. Then, read the IEBR registers again and clear them by writing 0 to them. Call an API to invalidate the cache. Regards, Daniel Re: Fault Injection to cache location using an interface provide in emcem Hello @danielmartynek ,  can you please check above query also which is related to fault injection to cache address.
查看全文
FS65 - IO2 IO3 でロードダンプ機能を有効にする 私は現在、SBC FS65を使っています。リファレンス・マニュアルによると、IO2とIO3はロードダンプ耐性ではありません。IO0、IO4、IO5(外部保護付き)はロードダンプ耐性ですが、IO4とIO5は外部ICの監視に使われています。 これにより、点火やその他のウェイクアップソースなどの外部接続に使用できるのはIO0のみとなる。 IO2とIO3のロードダンプ防止を外部(IO5のように)で、外部ロードに接続できるかどうかを教えていただけますか? Re: FS65 - Enable load dump feature on IO2 IO3 こんにちは、サンディープさん。 IO2とIO3は論理レベルのローカル入力であり、ECUの外部に直接接続されることを想定していません。それらの絶対最大電圧範囲は-0.3Vから8Vのみです。 外部のウェイクアップ電源として使用する場合は、オートモーティブ用に認定された負荷ダンプ対応の入力コンディショニングまたはレベルシフト回路が別途必要となります。この回路は、IO2またはIO3の電圧が、すべての通常状態および過渡状態においてピンの定格範囲内に維持され、かつ指定された入力しきい値が満たされることを保証しなければなりません。 BR、トーマス Re: FS65 - Enable load dump feature on IO2 IO3 こんにちは、トーマスさん。 ご説明ありがとうございます。
查看全文
MCX W72 Product Lifecycle and EOL Inquiry Hello NXP Team, We are evaluating the MCX W72 / FRDM-MCXW72 for a new design and would like to request information regarding Current lifecycle status Expected longevity/availability period Any planned EOL or NRND status Existing PCN or EOL notifications Recommended successor devices, if applicable Please share any available lifecycle documentation. FRDM-Training Re: MCX W72 Product Lifecycle and EOL Inquiry Thank you for the clarification and detailed information regarding the MCX W72 product longevity and lifecycle status. Re: MCX W72 Product Lifecycle and EOL Inquiry Hello, hope you are doing well. The MCX W72 is included in NXP’s Product Longevity Program until 2040, and is the recommended product for new designs. This product follow NXP's standard Product Lifecycle: it is fully active today, and any future status change would be communicated through NXP's standard discontinuance notification process, all applicable NXP End of Life and Product Change Notification policies continue to apply. Best regards, Sofia.
查看全文
FS65 - Enable load dump feature on IO2 IO3 I am currently working with the SBC FS65. According to the reference manual, IO2 and IO3 are not load dump proof. While IO0, IO4, and IO5 (with external protection) are load dump proof, IO4 and IO5 are being used for external IC monitoring. This leaves only IO0 available for external connections, such as ignition or other wake-up sources. Could you please clarify if we can make IO2 and IO3 load dump proof externally (similar to IO5) so that external loads can be connected to them? Re: FS65 - Enable load dump feature on IO2 IO3 Hello Sandeep, IO2 and IO3 are logic-level local inputs and are not designed to be connected directly outside the ECU. Their absolute maximum voltage range is only −0.3V to 8V. If they must be used for an external wake-up source, a separate automotive-qualified, load-dump capable input-conditioning or level-shifting circuit would be required. This circuit must ensure that the voltage at IO2 or IO3 remains within the pin ratings under all normal and transient conditions and that the specified input thresholds are satisfied. BR, Tomas Re: FS65 - Enable load dump feature on IO2 IO3 Hi Tomas, Thanks for clarification.....
查看全文