S32K344 QSPI初期化において、SCLKが期待される値を生成しません。 私はS32K344 LQFP176を使用して、QSPI周辺機器にアクセスする製品を開発しています。FLASHへのアクセスではなく、通常のデバイスを使用するために、アプリケーション上でQSPIをLSPIのように動作させたいと考えています。 クロックツリーQSPI_SFCKを20MHzに設定し、関連するFLASHレジスタを無効にして、LUTテーブルを使用しました。デバッグ中にLUTが実行されていることは確認できましたが、SD0～SD3には超高速波形が表示されているにもかかわらず、QSPIのSCLKが生成されていません。このQSPIを使用して非FLASHデバイスにアクセスする方法を教えていただけないでしょうか？ Re: S32K344 QSPI Initializes SCLK不按我们希望出来 S32K344 QuadSPIモジュールは主にシリアルフラッシュメモリインターフェースとして意図されており、任意のQSPIペリフェラル向けの汎用LSPIのようなインターフェースとしては意図されていません。QSPI_SFCKクロック構成はQuadSPIモジュールのクロックソースを提供するだけであり、外部SCLKを自動的に生成するものではありません。外部SCKFA信号は、フラッシュ指向LUT/IPコマンドエンジンによって実行される有効なQuadSPIコマンドシーケンスの一部としてのみ生成されます。したがって、コネクテッドデバイスがフラッシュのようなコマンド/アドレス/データプロトコルを守っていなかったり、LUTシーケンスやピンの設定がそのようなトランザクションと一致しない場合、この動作はこのアプリケーションには適さない可能性があります。汎用外部デバイスでは、必要なプロトコルが実装できるならLSPIを使うべきです。QuadSPIを使用する場合、外部デバイスプロトコルはQuadSPIフラッシュスタイルのトランザクションモデルと互換性があり、LUTシーケンス、ピンマルチパキシング、チップセレクト、コマンド/アドレス/データフェーズ、IPコマンドトリガーを適切にチェックする必要があります。

S32K148EVB-Q176はUJA1132ではなくUJA1131と共に受領されました。 こんにちは、 最近、S32K148EVB-Q176という基板を購入しました。ドキュメントや設計図によると、UJA1132が付いていると思っていましたが、届いたボードにはUJA1131が付いていました。 そのため、UJA1132の機能を期待していたのに、LINインターフェースは1つしかありません。 これは普通のことなのかどうか、お聞きしたかっただけです。S32K148EVB-Q176には、異なるSBCを搭載した複数のバージョンが存在するのでしょうか？それとも、私が受け取ったボードが間違っていたのでしょうか？ ご回答をお待ちしています。 Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 こんにちは、@sousou54 さん。 ご報告ありがとうございます。この件は現在調査中です。 商品箱に貼られている大きな白いラベルの写真を教えていただけますか?このラベルの情報は、基板の製造詳細を特定するのに役立ちます。 ラベルに製品固有の情報が含まれている場合があるため、公開するのではなく、プライベートメッセージやサポートケース(サポート)を開くことで共有できます。 よろしくお願いします、 ジュリアン Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 こんにちは、@sousou54 さん。 念のためお知らせしますが、お送りいただいた写真を受け取りましたので、担当チームに転送いたしました。 返信をお待ちしています。ご理解とご協力ありがとうございます。 よろしくお願いします、 ジュリアン Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 こんにちは、 @sousou54 さん。 この件についての詳細は、NXPの担当者またはこのキットを購入した代理店までお問い合わせください。彼らは支援を提供できるはずだ。 よろしくお願いします、 ジュリアン

SAF85xx HSE 更新 SMR 你好，恩智浦、 当只有签名字节因代码内容变化而变化，但代码大小、起始地址、密钥、签名指针... 没有更改时，我们是否需要更新 SMR？ Re: SAF85xx HSE Update SMR 你好 SMR（安全内存区域）条目包含 HSE 用来验证应用程序映像的元数据。即使 大小保持不变 起始地址保持不变 密钥句柄保持不变 签名指针保持不变 ......对代码内容的任何修改都会产生不同的签名，HSE 必须验证新签名。 因此，必须使用更新的签名字节重写保存签名的 SMR 条目。 SMR 条目是经过身份验证的启动链的一部分；除非其相应的 SMR 条目反映了新的签名，否则 HSE 无法验证更新的二进制文件。 参考：Aptiv 有直接的恩智浦 FAE，请随时与他联系了解详情。 顺祝商祺！ Peter Re: SAF85xx HSE Update SMR 感谢您的回复 Re: SAF85xx HSE Update SMR 你好， 如果我刷入新的应用程序和新的签名（映射新的应用程序）呢？如果“代码大小、起始地址、密钥、指向签名的指针”没有改变，是否需要重新安装SMR？

i.MX95でCPU/GPU/VPUを無効にして消費電力を減らす方法 こんにちは、NXPさん。 当社は、i.MX95ベースのシステム全体の消費電力を削減する方法を模索しています。 以下の質問について、教えていただけますか? 不要なときに個々のCPUコアを完全にシャットダウンすることは可能ですか？ アプリケーションがGPUやVPUを使わない場合、完全に電源を切ることは可能でしょうか? CPU/GPU/VPUが不要なら、起動後にデフォルトで無効にしてさらに消費電力を減らすことは可能でしょうか?（デバイスツリーによる？） 最低限の電力消費を実現するための推奨ソフトウェア構成や参考資料はありますか? 私たちのBSPはYocto 5.2 / Linux 6.12.xをベースにしています。 ありがとうございます。 よろしくお願いいたします。 ショーン Linux Re: Reducing Power Consumption by Disabling CPU/GPU/VPU on i.MX95 ご質問は下記までお問い合わせください。 不要なときに個々のCPUコアを完全にシャットダウンすることは可能ですか？ A: はい、可能です。 アプリケーションがGPUやVPUを使わない場合、完全に電源を切ることは可能でしょうか? A:はい、使わないなら使ってください。 CPU/GPU/VPUが不要なら、起動後にデフォルトで無効にしてさらに消費電力を減らすことは可能でしょうか?（デバイスツリーによる？） A: はい、GPU/VPUスタイルのプラットフォームデバイスの場合、通常は該当デバイスツリーのnode status = "disabled"を設定するのが一般的な方法です。そのためLinuxはそのデバイスをレジスタやプローブにしません。 最低限の電力消費を実現するための推奨ソフトウェア構成や参考資料はありますか? A: AN14449 — i.MX 95 電力消費測定:測定された低消費電力ユースケース、BCU手順、DSM、Linuxサスペンド、BBSMの主要な参考資料です。 ご質問があれば、お気軽にお問い合わせください 素敵な一日をお過ごしください

HSE INSTALL S32K311 All the content below is copied from the attachment. S32DS version: S32DS.3.5_b220726_win32.x86_64 (1).exe RTD version: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 Support Package Version: SW32K3_S32DS_3.5.6_D2309.zip SBAF version: SBAF_S32K311_0_0_15_0 Bin file: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSE version: HSE_FW_S32K311_0_2_40_0 The bin file is s32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pink Use FULL_MEM No safe boot A problem currently encountered The program will get stuck here: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );`           Re: HSE INSTALL S32K311 This is supplementary printf information. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC configuration word -0x4039C02C: 0x00000000 Lifecycle-related information - 0x402AC200: 0x00000000 HSE Status: 0x00000000 I've looked up information online, and it seems the SBAF that comes with the chip doesn't recognize the HSE firmware I'm currently using. Re: HSE INSTALL S32K311 I suspect that SBAF failed to copy the HSE firmware from the flash memory to the HSE_NVM. If this is the problem, how should I resolve it? Re: HSE INSTALL S32K311 This is the data I printed. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSE Status: 0x00000000 HSE firmware not started (NVM empty or firmware corrupted) Re: HSE INSTALL S32K311 Hi @iiiddd  Could you please share the value of HSE_CONFIG_GPR3 (0x4039C028)? Bit 0 indicates whether the HSE Firmware is present. BR, VaneB Re: HSE INSTALL S32K311 The RTD library I'm using is called when writing UTEST. gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); The FLS_MAX_VIRTUAL_SECTOR definition will be used. My RTD library defaults to 135, but accessing the address 0x1B000000UL requires 136. Is the RTD library I'm using incompatible with HSE? Re: HSE INSTALL S32K311 Hi @iiiddd  The HSE_CONFIG_GPR3[0] bit is not set, which indicates that the HSE hardware is not present on the device. For reference, the following image shows an example of a linker file configured for the installation of the HSE FW FULL_MEM on an S32K311 device: Re: HSE INSTALL S32K311 When I was debugging, I found that there were data in the pflash corresponding to the hse firmware. Do you mean that sbaf failed to copy the firmware in the pflash to the hsenvm? If this is the problem, what might have caused it?

HSE設置 S32K311 以下の内容はすべて添付ファイルからコピーしたものです。 S32DS バージョン: S32DS.3.5_b220726_win32.x86_64(1).exe RTDバージョン: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 サポートパッケージ バージョン: SW32K3_S32DS_3.5.6_D2309.zip SBAFバージョン: SBAF_S32K311_0_0_15_0 ビン ファイル: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSEバージョン: HSE_FW_S32K311_0_2_40_0 バイナリファイルはs32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pinkです。 FULL_MEMを使用する セーフブートなし 現在発生している問題 プログラムはここで停止します: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );`           Re: HSE INSTALL S32K311 これは補足的なprintf情報です。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC構成ワード -0x4039C02C: 0x00000000 ライフサイクル関連情報 - 0x402AC200: 0x00000000 HSEステータス: 0x00000000 ネットで調べてみたところ、チップに付属しているSBAFは、私が現在使用しているHSEファームウェアを認識しないようです。 Re: HSE INSTALL S32K311 SBAFがHSEファームウェアをフラッシュメモリからHSE_NVMにコピーできなかったことが原因ではないかと疑っています。もしこれが原因であれば、どのように解決すればよいでしょうか？ Re: HSE INSTALL S32K311 これが私が印刷したデータです。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSEステータス: 0x00000000 HSEファームウェアが起動していません（NVMが空であるか、ファームウェアが破損しています） Re: HSE INSTALL S32K311 こんにちは@iiiddd HSE_CONFIG_GPR3(0x4039C028)の価値について教えていただけますか?ビット0は、HSEファームウェアが存在するかどうかを示します。 BR、VaneB Re: HSE INSTALL S32K311 私が使用しているRTDライブラリは、UTESTを作成する際に呼び出されます。 gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); FLS_MAX_VIRTUAL_SECTOR 定義が使用されます。私のRTDライブラリはデフォルトで135ですが、アドレス0x1B000000ULにアクセスするには136が必要です。私が使用しているRTDライブラリはHSEと互換性がないのでしょうか？ Re: HSE INSTALL S32K311 こんにちは@iiiddd HSE_CONFIG_GPR3[0]ビットが設定されていないということは、デバイスにHSEハードウェアが存在しないことを示しています。 参考までに、以下の画像は、S32K311 デバイスに HSE FW FULL_MEM をインストールするために構成されたリンカー ファイルの例を示しています。 Re: HSE INSTALL S32K311 デバッグ中に、pflashにhseファームウェアに対応するデータが存在することを発見しました。sbafがpflash内のファームウェアをhsenvmにコピーできなかったということですか？これが問題の原因だとすれば、何が原因だったのでしょうか？

Reducing Power Consumption by Disabling CPU/GPU/VPU on i.MX95 Hi NXP, We are looking for ways to reduce the overall power consumption of our i.MX95-based system. Could you please help clarify the following questions? Is it possible to completely power down individual CPU cores when they are not required? Is it possible to completely power down the GPU and VPU if our application does not use them? If the CPU/ GPU / VPU is not required, is it possible to keep them disabled by default after boot to further reduce power consumption ? (by device-tree ?) Are there any recommended software configurations or reference documents for achieving the lowest possible power consumption? Our BSP is based on Yocto 5.2 / Linux 6.12.x. Thanks. Best Regards, Sean Linux Re: Reducing Power Consumption by Disabling CPU/GPU/VPU on i.MX95 For your questions: Is it possible to completely power down individual CPU cores when they are not required? A:Yes, you can. Is it possible to completely power down the GPU and VPU if our application does not use them? A:Yes if not use them. If the CPU/ GPU / VPU is not required, is it possible to keep them disabled by default after boot to further reduce power consumption ? (by device-tree ?) A:Yes, For GPU/VPU-style platform devices, yes, the normal approach is to set the relevant device tree node status = "disabled"; so Linux does not register/probe that device. Are there any recommended software configurations or reference documents for achieving the lowest possible power consumption? A:We have the AN14449 — i.MX 95 Power Consumption Measurement : primary reference for measured low-power use cases, BCU procedure, DSM, Linux suspend, and BBSM. Any questions contact us freely Wish you have a nice day

NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application We have created a sample application project and are using it as the bootloader. The actual application project is identical, with the only difference being the flash start address. The bootloader successfully jumps to the application, and the application starts executing. However, within the application, the xTaskCreate() function does not executed. Is there any additional configuration required when jumping from a bootloader to a FreeRTOS-based application? For example, are there any startup, interrupt, vector table, stack pointer, or scheduler-related configurations that must be performed before the application can create and execute FreeRTOS tasks? I referred the Unified bootloader Demo ticket from community. I didn't get the solution. Issue is only when we include FreeRTOS, without RTOS the application is working fine.  Its working for S32K344 not for NXPS32K358. Please let me know if any additional information is required. Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hi @Indhumathi, This "xTaskCreate() does not execute" is ambiguous and could mean different things. Can you check the following? 1. Execution never reaches xTaskCreate() The application starts, but something hangs or faults before the call. 2. xTaskCreate() is called but returns an error The function is called and returns an error, for example errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY. 3. Tasks are created, but the scheduler never runs them xTaskCreate() succeeds (returns pdPASS) and the tasks are created, but vTaskStartScheduler() is never called, fails, or SysTick/PendSV are not operating correctly after the bootloader jump. As a result, the tasks remain in the Ready state and never get CPU time. Also, is vApplicationMallocFailedHook() called? Which heap implementation are you using? What is the state of CM7_2? Is it running, held in reset, or started by the bootloader? Thank you, BR, Daniel Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Bootloader-to-Application Jump Code Used in Our Project: void Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t func; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;       for(i = 0; i < 10; i++)     {     S32_NVIC->ICER[i] = 0xFFFFFFFFU;     S32_NVIC->ICPR[i] = 0xFFFFFFFFU;     }     appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hello @Indhumathi, To narrow down the root cause, could you please verify whether the following interrupt handlers are actually being executed? SVC handler (vPortSVCHandler) — responsible for starting the first FreeRTOS task PendSV handler (vPortPendSVHandler) — responsible for context switching between tasks SysTick handler (vPortSysTickHandler / xPortSysTickHandler) — responsible for the FreeRTOS tick The simplest way to check is to place a breakpoint or a GPIO toggle at the entry of each handler in the application. Thank you, Regards, Daniel

PN5190B1 becomes unresponsive on first RF field ON hi all, hope you can help me due we are out of ideas... We have a custom board with a PN5190B1HN/C121E (host: CC1352 MCU over SPI). A new production lot of ~100 units shows a ~75% failure rate: the device stops responding on SPI the moment the RF field is switched on for the first time, and only recovers after a VEN reset. Units from the previous lot (prototypes 5 pcs), same design and BOM, work correctly. We have ruled out antenna/matching, TX short, static supply, SYS3V brownout, chip FW and silicon lot with measurements. We are looking for the confirmed root cause, a possible silicon erratum, or an EEPROM/power configuration we may be missing. Hardware NFC frontend: PN5190B1HN/C121E — GetVersion reports HW=0x52, ROM=0x02, FW=0x0201. TX supply = internal TX_LDO. VUP_TX (pin 6) = 3.3 V (LDO input). VDDPA (pin 9) = TX_LDO output (decoupled to GND only). VBAT / VBATPWR = 3.3 V. Internal DC-DC not used (no BOOST_LX inductor fitted). Main rail SYS3V = 3.3 V from a TPS62840 buck (0.7 A max). 27.12 MHz crystal (Murata XRCGB27M120F3M00R0). DPC disabled. ULPCD (ultra-low-power card detection) used. VDDPA set to minimum (TX_LDO_VDDPA_HIGH/LOW, EE 0x06/0x07 = 0x00). Differential antenna TX1/TX2, EMC filter (L = 160 nH) + matching. Measured resonance ≈ 12.56 MHz (with no final metallic enviroment)(identical on good and bad units). Symptom (precise characterization) Full SPI works before field ON: SWITCH_MODE_NORMAL, GetVersion, GetDieId, EEPROM read/write all return SUCCESS (status 0x0000). On the first FieldOn (RF_ON) the host times out waiting for the field-on event. Immediately after, every SPI register read times out (reading CLIF_STATUS, SYSTEM_CONFIG, GetDieId all return a HAL IO timeout). The chip is completely unresponsive on SPI until a VEN reset. After a VEN reset the chip is healthy again (GetVersion OK), then FieldOn corrupts it again → endless retry loop. No RF field is radiated (NFC test LEDs do not light). Board draws ~20 mA and never returns to low power. Good vs bad units are identical in FW (0x0201), DIEID lot, EEPROM config, antenna (VNA) and DC resistances. The only difference is that bad units get corrupted on FieldOn. The host MCU stays alive during the hang (the I²C keypad expander keeps responding), so it is specifically the PN5190 that dies, not the whole board. Good vs bad current draw is identical up to ~2.7 s; at ~2.7 s the good unit completes and drops to low power, the bad unit stays stuck at ~20 mA. Ruled out (each with a measurement, not intuition) Hypothesis How it was excluded Antenna / matching / tuning miniVNA on 4 good + 4 bad units → indistinguishable: resonance good 12.565 MHz / bad 12.593 MHz, RL ≈ −9 dB, |Z| ≈ 24.7 Ω, SWR ≈ 2.08 on both TX short / overcurrent DC resistance TX1–TX2 ≈ 1.2 kΩ, TX1–GND ≈ TX2–GND ≈ 1.15 kΩ, identical good vs bad Static supply leak / decoupling Current draw identical good vs bad until ~2.7 s SYS3V brownout Measured stable at 3.3 V; added 47 µF bulk on all 3.3 V rails → no change, still fails Chip FW Updated a unit to the latest PN5190 firmware → still fails, same behaviour. (Untouched good and bad units both report FW 0x0201.) Silicon lot DIEID good 00000000 0DD0945E 5B38BDDC 892C0810 vs bad 00000000 0DD095A6 6938BDDC 892C0E64 — same prefix/lot structure TX driver amplitude Reduced CLIF_SS_TX1/2_RMCFG CW amplitude before FieldOn → no change TX_LDO overcurrent protection Disabled it via TX_LDO_CONFIG bit 11 (0xAE → 0xA6) → no change TX_LDO output capacitor Removed VDDPA output caps (4.7 µF + 100 pF) → no change EEPROM configuration (identical on good and bad units) DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC off, VUP = VBATPWR, ULPCD enabled) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (default) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (minimum, ≈ 1.5 V) DPC disabled Questions This matches the reported "PN5190 chip corruption during the first start / first RF field ON." Can you confirm the root cause and the definitive fix? (Note: flashing a unit with the latest PN5190 firmware did not resolve it — same failure.) Is there a silicon erratum for this lot / date code? We can provide the full DIEID and a photo of the chip marking. For our topology (internal TX_LDO, VUP_TX = 3.3 V, VDDPA = LDO output, DC-DC off, DPC off, ULPCD, VDDPA at the minimum 1.5 V): is this configuration valid? Is running VDDPA at the minimum a problem, and what is the correct EEPROM power configuration we should compare against (vs the PNEV5190B)? Is there a power-up sequencing requirement (VEN vs supply ramp) that would cause this if violated? Note: vs the previous (working) lot we moved VEN from an I²C expander output to a direct MCU GPIO, and the VEN pull-up is DNP, so VEN floats during host boot. With brownout, overcurrent, FW, silicon and antenna all excluded by measurement, what else in the RF_ON path can make the chip stop answering SPI until a VEN reset? Thanks in advance ,   Ignacio Re: PN5190B1 becomes unresponsive on first RF field ON Hello sir, There are no published known issues that can cause the RF Fiel ON command to hang the IC. Could you please clarify whether the issue was resolved on all affected PN5190 devices after updating the firmware and cloning the EEPROM contents? This information would help us better understand the scope of the problem. If the issue persists on some units, have you had the opportunity to perform an A/B comparison test between a working and a failing device? Such a test could help determine whether the root cause is related to the IC itself or to another element of the system. Regarding the lot tracking, could you please check with your distributor whether they can provide additional information about the production lot and manufacturing history of the affected components? Re: PN5190B1 becomes unresponsive on first RF field ON The puzzling part: working and failing units have the same firmware version (v2.01), the same silicon revision (B1), the same hardware, the same antenna tuning, and — after cloning — the same EEPROM content. Yet some work and most do not. Upgrading the PN5190 firmware to v2.0D fixes the failing units. We would like to understand why, and whether there is a known issue in v2.01.   1. Sympton: On a failing unit: Boot and initialization proceed normally. At the first RF Field ON, the chip draws no meaningful current, generates no RF field (verified with NFC-powered LED test cards — they do not light up), and stops responding on SPI entirely. The host reports IO_TIMEOUT. Soft Reset also fails (it needs an SPI response). Only a hardware reset / power cycle recovers the chip. It then works normally until the next RF Field ON, where it hangs again. Fully reproducible. Supply rail (3.3 V) stays stable throughout — no brownout. On the very first power-up in the life of a board, we observe a one-time ~600 mA event (0.62 A measured with a Nordic PPK2) that never occurs again on subsequent power-ups. Log from the NFC Cockpit on a failing unit: INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106 INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully. INFO:RfFieldControlService:RF On WARN:ABalDelegate:Waited for PIN_IRQ to go High. Timed out. ERROR:RfFieldControlService:Error 240,IO_TIMEOUT while during field on. Log from a working unit, same firmware, same setup: INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106 INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully. INFO:RfFieldControlService:RF On INFO:RfFieldControlService:RF Off ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33 2. TEST SETUP To rule out our own host firmware, we connected the production boards directly to a PNEV5190BP used as a USB↔SPI bridge, following the NXP Knowledge Base article “How to connect external PN5190 to PNEV5190BP Evaluation Board” (R5/R7 placed, R6 open; R20 placed; VBAT/VBAT_PWR/VUP jumpers removed; SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS, NFC_IRQ, NFC_VEN, GND wired to the external board). NFC Cockpit v9.0.0 PNEV5190BP with uC FW NNC_uC_VCOM_04.00.00 External board powered from a Nordic PPK2 at 3.3 V (allows current measurement) The failure reproduces identically with the NXP host and NXP software, so it is not caused by our host firmware. 3. What we ruled out (with measurements): Hypothesis How it was ruled out Supply collapse / brownout 3.3 V rail measured stable throughout Short circuit on TX DC resistance TX1-TX2, TX1-GND, TX2-GND identical on good and bad units (several kΩ) Leakage on PA decoupling Identical current consumption good vs bad until the field-on moment Antenna detuning / matching VNA measurement, 4 good + 4 bad units — see below Physical damage to the IC The chip recovers with a hardware reset and fails again reproducibly Our host firmware Reproduced with NFC Cockpit + PNEV5190BP PN5190 firmware version Both good and bad units are on v2.01, Hw B1 User EEPROM content Cloned the complete EEPROM of a good unit into a bad unit → still fails Difference: ~29 kHz (0.2%), within measurement noise. Confirmed on 8 boards. Antennas are indistinguishable. 4. THE EEPROM COMPARISION - one single byte We dumped the complete user EEPROM of a good unit and a bad unit, both on FW v2.01, and diffed them. Out of 648 parameters, exactly one differs: Region:  DPC_SETTINGS Param:   DPC_CONFIG Offset:  0x76 GOOD unit:  0x77 BAD  unit:  0x76 Everything else is byte-identical. This looked like the answer, especially given the precautionary note in RN00003: Do not disable the DPC and activate the RF field for ICs connected to antennas matched “Symmetric” (for example, customer development board antenna). Possible damage of the transmitter drivers due to overcurrent over a long period might occur. Our antenna is symmetric (differential TX1/TX2), and the one-time ~600 mA event on first power-up is consistent with an overcurrent condition. However, copying the byte does NOT fix the unit Test Result Write DPC_CONFIG = 0x77 to a bad unit (v2.01), verify readback, power cycle Still fails Load the complete EEPROM dump of a good unit into a bad unit (v2.01), power cycle Still fails Good unit, unmodified, v2.01 Works perfectly So DPC_CONFIG correlates with pass/fail but is not the cause. Whatever the real difference is, it is not in the user EEPROM area. 5.  what does fix it: secure firmware upgrade to V2.0D   Performing a Secure Firmware Upgrade with PN5190Firmware_2.0D.esfwu (LEDL folder, legacy download for B0/B1) makes the failing units work: Idle: ~33 mA RF Field ON: ~240 mA sustained, stable, LEDs light up Activate Layer3 returns ATQA 04 00, SAK 0x08, UID 04 8D 12 33 Verified working afterwards with our own product firmware Two units recovered this way so far, both fully functional. Side effect: PwrConfig is overwritten and causes overheating After the upgrade, EEPROM offset 0x0000 (PwrConfig) changes from 0x21 to 0xE4. With 0xE4: PwrConfig 0xE4 PwrConfig 0x21 (restored) Idle current ~290 mA ~33 mA Die temperature (PMU_TEMP_REG@0x5B) 100 °C 40 °C 290 mA at idle with no RF field, and the internal temperature sensor reading 100 °C (Tj max is 125 °C). We restore PwrConfig to 0x21 after every upgrade. Is 0xE4 the intended default for PwrConfig in v2.0D? This looks like it could be a problem for other users too. The 16 EEPROM parameters changed by the upgrade Parameter Offset Before (v2.01) After (v2.0D) PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 polarity 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 DigitalTBSignalIndex 0xCE9 0x00 0x9B DigitalTBSignalBit 0xCEA 0x00 0x04 AnalogTBSignal 0xCEB 0x00 0x78 Since cloning a good unit’s complete EEPROM into a bad unit does not fix it, the fix cannot be in these 16 bytes alone — something in the firmware code itself must be involved. 6. Die IDs All units are Hw B1, FW v2.01 as received: BAD  #1:  00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 BAD  #2:  00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 BAD  #3:  00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 GOOD #1:  00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. Questions Is there a known issue in FW v2.01 that can cause RF Field ON to hang the IC with no field generated and no SPI response? We note that DPC_CONFIG as a register was only introduced in v02.03 (per RN00003), and that v02.07→v02.08 and v02.08→v02.09 both contain DPC regulation fixes. Why do ~25% of units work and ~75% fail with identical firmware, silicon revision, hardware and EEPROM? Is there anything outside the user EEPROM area (factory trims, internal state) that could differ between units of the same lot? Can the Die IDs above be traced to different production lots or wafer batches? Is PwrConfig = 0xE4 the intended value after upgrading to v2.0D? It results in ~290 mA idle consumption and 100 °C die temperature on our design. Can PN5190 devices be ordered with a specific firmware version pre-programmed? Shipping with v2.01 while the tool itself warns it is obsolete has cost us a full production batch. Is upgrading to v2.0D before first power-up the recommended mitigation for the remaining ~80 unused units, to avoid the one-time 600 mA event entirely? Any guidance appreciated. 

S32K312 での Fat ファイルシステム統合 (RTD 6.0.0、非AUTOSAR、SPI SDカードドライバー) こんにちは、 私はRTD 6.0.0(Non-AUTOSAR Lpspi_Ipドライバー)を使ってS32K312 EVB上でSPI経由でSDカードドライバーを成功裏に実装しました。 以下の機能は既に動作しています。 SDカードの初期化（CMD0、CMD8、ACMD41、CMD58） シングルブロック読み取り（CMD17） 単一ブロック書き込み（CMD24） 複数ブロック読み取り（CMD18） 複数ブロック書き込み (CMD25) ドライバーはSDカードへのデータ書き込みと読み込みで確認済みです。 今は、ファイルを作成・書き込み・読み取れるようにFATファイルシステムのサポートを追加したいと考えています。 いくつか質問があります。 NXPはRTD 6.0.0(Non-AUTOSAR)を用いたS32K312向けにFatFs統合を提供したりサポートしたりしていますか?もしなければ、他のS32K3デバイスで参考にできるサポート例はありますか? NXPからFatFsをSDカードと統合するためのミドルウェアパッケージはありますか? 公式の例がない場合、Elm-Chan FatFsライブラリを統合し、必要なdiskio.cを実装することが推奨されるアプローチです。既存のSDカードドライバーを使ってインターフェースを操作するのですか? S32K3デバイスでのFATファイルシステム統合を示す参考プロジェクト、アプリケーションノート、または例リポジトリはありますか? 本番環境開発において、どの手法が推奨されるのか、少し迷っています。ご助言や参考資料などございましたら、大変ありがたく存じます。 よろしくお願いします。 Re: Fat Filesystem Integration on S32K312 (RTD 6.0.0, Non-AUTOSAR, SPI SD Card Driver) こんにちは、 @parvathitp 現在、このS32K312に対するFatFSの具体的なサポートはありません。S32K3ファミリ内では、FatFS統合はマイクロコントローラとSDカード間のハードウェアインターフェースを提供するuSDHC周辺機器を含むデバイスにのみ利用可能です。 これらのデバイスには、uSDHCドライバを通じてSDバスへのアクセスを簡素化し、FatFSとの統合を可能にするSDHCソフトウェアスタックが提供されています。 コミュニティスレッド「FatFsファイルシステムをKL26 SPI SDカードコードに移植する」で説明されているアプローチや概念は、実装に役立つ参考になるかもしれません。例はKL26デバイスをベースにしていますが、タイトルの通り、SDHC/uSDHC **ペリフェラル**を含まないデバイスにFatFSファイルシステムを移植する方法を説明しており、あなたの用途に似ています。 BR、VaneB

PN5190B1 在首次开启射频场时无响应 大家好，希望你们能帮帮我，我们已经黔驴技穷了…… 我们有一块定制板，上面有PN5190B1HN/C121E（主机：CC1352 MCU，通过SPI接口）。新生产的约 100 台设备出现约 75% 的故障率：设备在首次开启射频场时停止对 SPI 做出响应，只有在 VEN RESET 后才能恢复。上一批产品（原型 5 件），设计和物料清单相同，运行正常。我们通过测量排除了天线/匹配问题、发射机短路、静态电源问题、SYS3V 电压骤降、芯片固件和硅批次问题。我们正在寻找已确认的根本原因、可能的芯片缺陷，或者我们可能遗漏的 EEPROM/电源配置。 硬件 NFC 前端：PN5190B1HN/C121E — GetVersion 报告 HW=0x52，ROM=0x02，FW=0x0201。 TX 供电 = 内部 TX_LDO。VUP_TX（引脚 6）= 3.3 V（LDO 输入）。VDDPA（引脚 9）= TX_LDO 输出（仅与 GND 解耦）。VBAT / VBATPWR = 3.3 V。未使用内部 DC-DC（未安装 BOOST_LX 电感器）。 主电源轨 SYS3V = 3.3 V，由 TPS62840 降压器供电（最大 0.7 A）。 27.12 MHz 晶体（Murata XRCGB27M120F3M00R0）。 DPC已禁用。采用超低功耗卡检测（ULPCD）。VDDPA 设置为最小值（TX_LDO_VDDPA_HIGH/LOW，EE 0x06/0x07 = 0x00）。 差分天线 TX1/TX2，EMC 滤波器（L = 160 nH）+ 匹配。测得的谐振≈12.56 MHz（无最终金属环境）（好单元和坏单元相同）。 症状（精确描述） 在字段 ON 之前，完整的 SPI 功能正常：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROM 读/写操作全部返回成功（状态 0x0000）。 第一次触发 FieldOn (RF_ON) 事件时，主机等待场开启事件超时。随后，所有 SPI 寄存器读取操作均超时（读取 CLIF_STATUS、SYSTEM_CONFIG、GetDieId 均返回 HAL IO 超时）。在 VEN RESET 之前，芯片在 SPI 接口上完全没有响应。 VEN 重置后芯片恢复正常（GetVersion OK），然后 FieldOn 又会将其损坏 → 无限重试循环。 不会辐射射频场（NFC 测试 LED 灯不亮）。电路板消耗约 20 mA 电流，且不会回到低功耗状态。 好的单元和坏的单元在固件 (0x0201)、DIEID 批次、EEPROM 配置、天线 (VNA) 和直流电阻方面是相同的。唯一的区别是，在 FieldOn 上，损坏的单位会被损坏。 主机 MCU 在死机期间保持运行（I²C 键盘扩展器持续响应），因此是 PN5190 损坏，而不是整个电路板损坏。 好单元和坏单元的电流消耗在约 2.7 秒内相同；在约 2.7 秒时，好单元完成工作并降至低功率，坏单元则保持在约 20 mA。 已排除（每一项都经过测量，而非凭直觉） 假设：它是如何被排除的 天线/匹配/调谐 使用 4 台正常设备和 4 台故障设备进行 miniVNA 测试 → 结果无法区分：谐振频率正常设备为 12.565 MHz / 故障设备为 12.593 MHz，RL ≈ −9 dB，|Z| ≈ 24.7 Ω，两者的驻波比 (SWR) 均 ≈ 2.08。 TX短路/过流 直流电阻 TX1–TX2 ≈ 1.2 kΩ，TX1–GND ≈ TX2–GND ≈ 1.15 kΩ，相同质量的器件与劣质器件相同。 静态供水泄漏/解耦 电流消耗在约 2.7 秒之前，无论好坏，都相同。 SYS3V 电压骤降 经测试，在 3.3V 电压下稳定；在所有 3.3V 电源轨上添加了 47µF 电容 → 没有变化，仍然失败 芯片固件 将设备更新到最新的 PN5190 固件 → 仍然失败，情况相同。（未经改动的正常设备和故障设备都报告固件版本为 0x0201。） 硅片 DIEID 良好 00000000 0DD0945E 5B38BDDC 892C0810 与 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 前缀/批号结构相同 TX驱动器幅度 场开启前 CLIF_SS_TX1/2_RMCFG CW 幅度降低 → 无变化 TX_LDO 过流保护 通过 TX_LDO_CONFIG 位 11 禁用（0xAE → 0xA6）→ 无变化 TX_LDO 输出电容 移除 VDDPA 输出电容（4.7 µF + 100 pF）→ 无变化 EEPROM配置（正常单元和故障单元相同） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC 关闭，VUP = VBATPWR，ULPCD 启用) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (默认值) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小值，≈ 1.5 V) DPC 已禁用 问题 这与报告的“首次启动/首次开启射频场时PN5190芯片损坏”的情况相符。您能否确认根本原因和最终解决方案？（注：使用最新的PN5190固件刷新设备并未解决问题——故障依旧。） 该批次/日期代码是否有硅油勘误表？我们可以提供完整的芯片ID和芯片标记照片。 对于我们的拓扑结构（内部 TX_低压差线性稳压器(LDO)，VUP_TX = 3.3 V，VDDPA = 低压差线性稳压器(LDO) 输出，DC-DC 关闭，DPC 关闭，ULPCD，VDDPA 最低为 1.5 V）：此配置是否有效？以最低 VDDPA 运行是否有问题？我们应该与哪种正确的 EEPROM 电源配置进行比较（与 PNEV5190B 相比）？ 是否存在上电时序要求（VEN 与电源斜坡），如果违反该要求会导致这种情况？注意：与之前的（正常工作的）批次相比，我们将 VEN 从 I²C 扩展器输出移到了直接的 MCU GPIO，并且 VEN 上拉电阻为 DNP，因此 VEN 在主机启动期间处于浮空状态。 排除欠压、过流、固件、硅和天线等因素后，RF_ON 路径中还有什么因素会导致芯片停止响应 SPI 信号，直到 VEN RESET？ 提前感谢！   伊格纳西奥 Re: PN5190B1 becomes unresponsive on first RF field ON 令人费解的是：正常工作的单元和出现故障的单元具有相同的固件版本（v2.01）、相同的硅版本（B1）、相同的硬件、相同的天线调谐，并且在克隆后具有相同的 EEPROM 内容。然而，有些有效，大多数无效。 将 PN5190 固件升级到 v2.0D 可以修复故障单元。我们想了解原因，以及 v2.01 中是否存在已知问题。   1. 症状： 对于一台故障设备： 启动和初始化过程正常进行。 在第一个射频场开启时，芯片不会消耗任何有意义的电流，也不会产生射频场（已用 NFC 供电的 LED 测试卡验证——它们不会亮起），并且完全停止对 SPI 做出响应。 主机报告 IO_TIMEOUT 超时。软复位也失败了（它需要 SPI 响应）。 只有硬件重置/断电重启才能恢复芯片。之后它会正常工作，直到下一次射频场开启时，它又会再次卡住。完全可复现。 供电轨（3.3V）始终保持稳定——没有电压骤降。 在电路板的第一次上电时，我们观察到一次性的 ~600 mA 事件（使用 Nordic PPK2 测量为 0.62 A），此后在后续上电时再也没有发生过。 故障设备上的 NFC Cockpit 日志： 信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。 信息：射频场控制服务：射频开启 警告：ABalDelegate：等待 PIN_IRQ 变为高电平。超时。 错误：RfFieldControlService：字段开启期间发生错误 240，IO_TIMEOUT。 来自一台正常工作的设备（固件版本相同，配置相同）的日志： 信息：RFProtocolTuningService_PN5190：加载协议：RM_A_106 信息：TypeACardViewModel：RM_A_106 协议加载成功。 信息：射频场控制服务：射频开启 信息：射频场控制服务：射频关闭 ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33 2. 测试设置 为了排除我们自己的主机固件，我们按照 NXP 知识库文章“如何将外部 PN5190 连接到 PNEV5190BP 评估板”中的说明，将生产板直接连接到用作 USB↔SPI 桥接器的 PNEV5190BP（R5/R7 已放置，R6 开路；R20 已放置；VBAT/VBAT_PWR/VUP 跳线已移除；SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND 已连接到外部板）。 NFC Cockpit v9.0.0 PNEV5190BP，微控制器固件版本为 NNC_uC_VCOM_04.00.00 外部电路板由 Nordic PPK2 供电，电压为 3.3V（可进行电流测量） 使用 NXP 主机和 NXP 软件也会出现完全相同的故障，因此这不是由我们的主机固件引起的。 3. 我们排除的因素（通过测量）： 假设 它是如何被排除的 供应崩溃/断电 3.3V 电源轨测量结果始终稳定 TX短路 直流电阻 TX1-TX2、TX1-GND、TX2-GND 在正常单元和故障单元上相同（几千欧姆） PA解耦泄漏 在场启动之前，电流消耗在好坏两方面都相同 天线失谐/匹配 VNA测量，4个合格单元+4个不合格单元——见下文 集成电路受到物理损坏 芯片可通过硬件RESET恢复，但随后又会重复出现故障。 我们的主机固件 使用 NFC Cockpit + PNEV5190BP 进行复现 PN5190固件版本 好的和坏的单元都运行在 v2.01 版本，硬件 B1 上。 用户EEPROM内容 将正常单元的完整 EEPROM 克隆到故障单元中 → 仍然失败 差异：~29 kHz (0.2%)，在测量噪声范围内。已在 8 个电路板上确认。天线无法区分。 4. EEPROM 比较 - 单个字节 我们分别从一台运行固件版本为 v2.01 的正常设备和一台故障设备中提取了完整的用户 EEPROM，并比较了它们的差异。 648 个参数中，恰好有一个不同： 区域：DPC_SETTINGS 参数：DPC_CONFIG 偏移量：0x76 良好单元：0x77 错误单元：0x76 其他所有内容都字节完全相同。 这看起来像是答案，特别是考虑到 RN00003 中的预防措施说明： 不要禁用 DPC，并为连接到匹配“对称”天线的 IC 激活 RF 场（例如，客户开发板天线）。长时间过电流可能会导致发射器驱动器损坏。 我们的天线是对称的（差分 TX1/TX2），首次上电时出现的一次 ~600 mA 事件与过电流情况一致。 然而，复制字节并不能修复该单元。 测试 结果 向故障单元（v2.01）写入 DPC_CONFIG = 0x77，验证读取结果，然后断电重启 仍然失败 将正常单元的完整 EEPROM 转储加载到故障单元中（v2.01），然后断电重启 仍然失败 良好单元，未修改，版本 2.01 完美运行 因此，DPC_CONFIG 与通过/失败相关，但并非导致通过/失败的原因。无论真正的区别是什么，都不在用户 EEPROM 区域。 5. 解决方法：将固件安全升级到 V2.0D 版本   使用PN5190Firmware_2.0D.esfwu （LEDL 文件夹，B0/B1 的旧版下载）执行安全固件升级，可使故障设备恢复正常工作： 空闲状态：约 33 mA 射频场开启：持续稳定电流约 240 mA，LED 指示灯亮起 激活Layer3返回ATQA 04 00，SAK 0x08，UID 04 8D 12 33 经验证，使用我们自己的产品固件后可以正常工作。 目前已通过这种方式回收了两台设备，两台设备均功能完好。 副作用：PwrConfig 被覆盖，导致过热。 升级后，EEPROM 偏移量0x0000 ( PwrConfig ) 从0x21变为0xE4 。使用0xE4 ： PwrConfig 0xE4 PwrConfig 0x21（已恢复） 空载电流 约290毫安 约33毫安 芯片温度（ PMU_TEMP_REG@0x5B ） 100℃ 40°C 空闲时电流为 290 mA，无 RF场，内部温度传感器读数为 100 °C（Tj max 为 125 °C）。每次升级后，我们将PwrConfig恢复为0x21 。 0xE4是v2.0D 版本中 PwrConfig 的预期默认值吗？这看起来也可能是其他用户会遇到的问题。 升级更改了 16 个 EEPROM 参数。 参数 偏移量 之前（v2.01） （v2.0D）之后 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 极性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 数字TB信号指数 0xCE9 0x00 0x9B 数字TB信号比特 0xCEA 0x00 0x04 模拟TB信号 0xCEB 0x00 0x78 由于将正常单元的完整 EEPROM 克隆到故障单元中并不能解决问题，因此修复方法不可能仅仅依靠这 16 个字节——固件代码本身肯定存在一些问题。 6. 模具 ID 所有设备均为Hw B1，FW v2.01版本： 错误代码 #1：00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 错误代码 #2：00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 错误代码 #3：00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良好 #1：00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 问题 FW v2.01 中是否存在已知问题，会导致 RF 场开启时 IC 卡死，既没有产生场也没有 SPI 响应？我们注意到，DPC_CONFIG 寄存器仅在 v02.03 版本中引入（根据 RN00003），并且 v02.07→v02.08 和 v02.08→v02.09 都包含 DPC 法规修复。 为什么固件、芯片版本、硬件和 EEPROM 完全相同的情况下，约 25% 的设备可以正常工作，而约 75% 的设备却无法正常工作？除了用户 EEPROM 区域（出厂设置、内部状态）之外，同一批次的单元之间还有什么可能存在差异吗？ 上述芯片 ID 能否追溯到不同的生产批次或晶圆批次？ 升级到 v2.0D 后，PwrConfig = 0xE4 是否为预期值？我们的设计实现了约 290 mA 的空闲功耗和 100 °C 的芯片温度。 PN5190 设备可以订购预装特定固件版本的吗？尽管工具本身已发出版本 2.01 的警告，但我们仍然使用该版本进行发货，导致我们损失了一整批产品。 对于剩余的约 80 个未使用单元，建议在首次通电前升级到 v2.0D，以完全避免一次性 600 mA 事件的发生。 非常感谢您的指导。 Re: PN5190B1 becomes unresponsive on first RF field ON 您好，先生， 目前尚未发现任何已知的问题会导致 RF Fiel ON 命令使 IC 卡死。 更新固件并克隆 EEPROM 内容后，能否请您确认所有受影响的 PN5190 设备的问题是否都已解决？这些信息将有助于我们更好地了解问题的范围。 如果某些设备上仍然存在该问题，您是否有机会对正常工作的设备和出现故障的设备进行 A/B 对比测试？这样的测试可以帮助确定根本原因是集成电路本身还是系统的其他元件。 关于批次追踪，请您向代理商核实他们是否能提供有关受影响元器件的生产批次和制造历史的更多信息？

.mexファイル内の警告ファイル （自動生成された）.mexファイル内プロジェクト用のファイルでは、各ペリフェラルは次のような内容です: 1.0.0 「説明」属性の文言に注目してください。他のペリフェラルについては状況が異なりますが、ほとんどの場合、警告やエラーメッセージのようなものです。プロジェクトは正常にコンパイルされ、実行されます。 関連して、『ペリフェラルビュー』から新しいソフトウェアコンポーネントを追加しようとすると、現在選択されていないペリフェラルが黄色い感嘆符でマークされています。添付のスクリーンショットをご覧ください。マウスカーソルをそれらの上に重ねると、「description」属性に表示されているのと同じメッセージが表示されます。しかし、私は問題なくそれらを追加できます。 これらの警告は何に関するものですか？ Re: Warning in the .mex file こんにちは、 @durga_choudhuryさん この警告はプロジェクトには影響しません。対応するドライバーがプロジェクトに追加または設定されていないことを示すだけです。したがって、お客様の現在の実装に機能的な影響は想定されません。 BR、VaneB

Makefile execution generated by MCUxpresso IDE Hi team, We have used MCUxpresso IDE and imported a sample SDK example for imxrt1170 eval board and built the project file. The MCUxpresso IDE itself has auto generated a makefile. So my query is how to execute this make file in my windows system without using MCUxpresso,like by using make all, make clean and make commands to generate the binary (.axf file here for MCUxpresso). I have even attached the Makefile also just for reference below. Re: Makefile execution generated by MCUxpresso IDE Hello, Windows user here. Using MCUXpresso's makefiles is all a matter of %PATH% variable. I found that the easiest way to run "make"  commands from the command line is to Ctrl-click on the project name in the bottom right-hand corner of the MCUXpresso IDE: This will open a terminal window in your project directory with  %PATH% properly set, so you can enter "make clean" and "make -j8 all" and similar commands. Of course, you can close the IDE and the terminal window stays open. You can also inspect the %PATH% variable. Set this path in any other terminal window and you can run make commands there as well.  Hope you can put this to good use. Best regards, Daniel Re: Makefile execution generated by MCUxpresso IDE The auto-generated make file (managed make) in Eclipse is not portable. You could use the make file in the SDK (non-IDE), or better, use CMake to have a portable build system. I'm using the approach described in https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/ to have both IDE, make and CMake for the builds. Re: Makefile execution generated by MCUxpresso IDE Hi @Jeevan ,   I think you can refer to the gcc project to build it in the SDK, as that also use the makefile without the IDE.  About the gcc build method, you can refer to the sdk document: SDK_2_14_0_MIMXRT1170-EVK\docs\Getting Started with MCUXpresso SDK for MIMXRT1170-EVK.pdf chapter 6 Run a demo using Arm® GCC You also can refer to my ubuntu build method document: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 Wish it helps you! If you still have question about it, please kindly let me know. Best Regards, Kerry

MCUxpresso IDEによって生成されるMakefile実行 チームの皆さん、こんにちは。 MCUxpresso IDEを使い、imxrt1170評価ボードのサンプルSDKをインポートしてプロジェクトファイルを作成しました。 MCUxpresso IDE自体は自動でメイクファイルを生成しています。そこで質問ですが、MCUxpressoを使わずにWindowsシステムでこのmakeファイルをどう実行するか、例えばmake all、makeクリーン、そしてコマンドを作成してバイナリ(MCUxpresso用の.axfファイル)を生成する方法です。 参考までに、Makefileも以下に添付しました。 Re: Makefile execution generated by MCUxpresso IDE こんにちは、 Windowsユーザーです。MCUXpressoのmakeファイルの使い方は%PATH%マターです。 コマンドラインから「make」コマンドを実行する最も簡単な方法は、MCUXpresso IDEの右下にあるプロジェクト名をCtrlでクリックすることです。 これでプロジェクトディレクトリにターミナルウィンドウが開き、%PATH% が正しく設定されているので、「make clean」や「make -j8 all」などのコマンドを入力できます。 もちろん、IDEを閉じてもターミナルウィンドウは開いたままです。また、 %PATH% 変数も検査できます。このパスを他のターミナルウィンドウに設定すれば、そこでも「メイクコマンド」を実行できます。 この情報を有効に活用できることを願っています。 よろしくお願いします、 ダニエル Re: Makefile execution generated by MCUxpresso IDE Eclipseの自動生成メイクファイル(マネージドメイク)はポータブルではありません。SDKのmakeファイル(非IDE)を使うか、もっと良いのはCMakeを使ってポータブルビルドシステムを作る方法です。https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/ で説明したIDE、make、CMakeの両方をビルドに使う方法を使っています。 Re: Makefile execution generated by MCUxpresso IDE こんにちは、 @Jeevan さん。 SDKで構築するにはgccプロジェクトを参照できると思います。そちらもIDEなしでmakefileを使うからです。 gccビルド方法については、SDKのドキュメントを参照してください。 SDK_2_14_0_MIMXRT1170-EVK\docs\MCUXpresso SDK for MIMXRT1170-EVK.pdf 第6章 Arm® GCCを使ってデモを実行 また、私のUbuntuビルド方法のドキュメントも参照してください: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 お役に立てれば幸いです！ ご不明な点がございましたら、お気軽にお問い合わせください。 よろしくお願いいたします。 kerry

PN5190B1最初のRFフィールドONで反応しなくなります 皆さんこんにちは、もうアイデアが尽きてしまったので助けていただけると嬉しいです... PN5190B1HN/C121E(ホスト:CC1352 MCU over SPI)を搭載したカスタムボードを持っています。新生産ロット(約100台)では、約75%の故障率が示されています。RFフィールドが初めてオンになった瞬間にSPIで応答しなくなり、VENリセット後にのみ回復します。前のロットのユニット(プロトタイプ5個)は同じデザインとBOMで正常に動作します。測定結果から、アンテナ/マッチング、送信機のショート、静的電源、SYS3Vの電圧低下、チップのファームウェア、シリコンロットの問題は除外しました。我々は、確認済みの根本原因、考えられるシリコンの不具合、または見落としている可能性のあるEEPROM/電源構成を探しています。 ハードウェア NFCフロントエンド：PN5190B1HN/C121E — GetVersionレポートによると、HW=0x52、ROM=0x02、FW=0x0201です。 TX電源＝内部TX_LDO。VUP_TX（ピン6）= 3.3V（LDO入力）。VDDPA（ピン9）＝TX_LDO出力（GNDのみにデカップリング）。VBAT / VBATPWR = 3.3 V。内部DC-DCコンバータは使用されていません（BOOST_LXインダクタは取り付けられていません）。 メインレールSYS3V = TPS62840降圧コンバータ（最大0.7A）からの3.3V。 27.12 MHz水晶発振子（村田製作所製 XRCGB27M120F3M00R0）。 DPCは無効になっています。ULPCD（超低消費電力カード検出）を使用。VDDPAを最小値に設定（TX_LDO_VDDPA_HIGH/LOW、EE 0x06/0x07 = 0x00）。 差動アンテナTX1/TX2、EMCフィルタ（L = 160 nH）+整合回路。測定された共振周波数は約12.56MHz（最終的な金属環境なし）（良品と不良品で同一）。 症状（詳細な特徴） フィールドONの前にフルSPIが動作します：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROMの読み書きはすべてSUCCESS（ステータス0x0000）を返します。 最初のFieldOn(RF_ON)では、ホストがフィールドオンイベントを待つためにタイムアウトします。その直後、すべてのSPIレジスタの読み取りがタイムアウトします（CLIF_STATUS、SYSTEM_CONFIG、GetDieIdの読み取りはすべてHAL IOタイムアウトを返します）。VENリセットを行うまで、このチップはSPIに対して全く反応しません。 VENリセット後、チップは再び正常になります（GetVersion OK）。その後、FieldOnが再びチップを破損させ、無限リトライループが発生します。 RFフィールドは放射されません(NFCテストLEDは点灯しません)。基板は約20mAの電流を消費し、低電力状態に戻ることはありません。 良品と不良品は、ファームウェア（0x0201）、DIEIDロット、EEPROM構成、アンテナ（VNA）、およびDC抵抗において同一である。唯一の違いは、FieldOnでは不良ユニットが破損してしまう点です。 ホストMCUはハング中も生き続けます(I²Cキーパッドエキスパンダーが応答し続けます)。つまり、故障するのは基板全体ではなくPN5190側です。 正常ユニットと不良ユニットの電流消費量は約2.7秒までは同一ですが、約2.7秒で正常ユニットは処理を完了して低電力に低下し、不良ユニットは約20mAのままになります。 除外された項目（それぞれ直感ではなく、測定に基づいて） 仮説 除外された経緯 アンテナ／マッチング／チューニング miniVNAを4つの良品ユニットと4つの不良品ユニットで測定したところ、両者は区別がつかなかった。共振周波数は良品12.565MHz、不良品12.593MHz、RL ≈ −9dB、|Z| ≈ 24.7Ω、SWR ≈ 2.08（いずれも同じ値）。 TX短絡/過電流 直流抵抗 TX1–TX2 ≈ 1.2 kΩ、TX1–GND ≈ TX2–GND ≈ 1.15 kΩ、良品と不良品で同一 静電気による電源漏れ／デカップリング 電流消費量は、約2.7秒までは正常と異常で同じである。 SYS3V電圧低下 3.3Vで安定して測定。3.3Vレールすべてに47μFのバルクコンデンサを追加→変化なし、依然として故障。 チップFW ユニットを最新のPN5190ファームウェアにアップデートしましたが、依然として失敗し、同じ動作を示します。（未処理の良品と不良品の両方で、ファームウェアコード0x0201が報告される。） シリコンロット DIEID 正常 00000000 0DD0945E 5B38BDDC 892C0810 対 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 同じプレフィックス/ロット構造 TXドライバ振幅 FieldOn前のCLIF_SS_TX1/2_RMCFG CW振幅の減少 → 変更なし TX_LDO過電流保護 TX_LDO_CONFIGビット11（0xAE → 0xA6）で無効化しましたが、変化はありませんでした。 TX_LDO出力コンデンサ VDDPA出力コンデンサ（4.7 µF + 100 pF）を取り外した → 変化なし EEPROM構成（良品と不良品で同一） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DCオフ、VUP = VBATPWR、ULPCD有効) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (デフォルト) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小値、約 1.5 V) DPCが無効になっています 質問 これは報告された「最初の起動時/最初のRFフィールドオン時にPN5190チップ破損」と一致します。根本原因と最終的な解決策を確認できますか?(注:最新のPN5190ファームウェアをフラッシュしても解決しませんでした — 同じ失敗です。) このロット／日付コードに対応するシリコンに関する訂正情報はありますか？完全なDIEIDとチップの刻印の写真も提供できます。 当社のトポロジー（内部TX_LDO、VUP_TX = 3.3 V、VDDPA = LDO出力、DC-DCオフ、DPCオフ、ULPCD、VDDPA最小1.5 V）において、この構成は有効でしょうか？VDDPAを最低限の電圧で動作させることは問題でしょうか？また、比較対象となる正しいEEPROM電源構成（PNEV5190Bとの比較）は何でしょうか？ 電源投入順序に関する要件（VENとサプライランプのどちらを優先するかなど）があり、それが満たされない場合にこのような問題が発生するのでしょうか？注:前の(動作中の)ロットと比べて、VENはI²Cエクスパンダ出力から直接MCU GPIOに移し、VENプルアップはDNPなので、ホスト起動時にVENは浮動します。 ブラウンアウト、過電流、FW、シリコン、アンテナがすべて測定で除外されている中で、VENリセットまでチップがSPIに応答しなくなるRF_ON経路の他に何があるのでしょうか? よろしくお願いいたします。   イグナシオ Re: PN5190B1 becomes unresponsive on first RF field ON お世話になります。 RF Fiel ONコマンドがICをハングさせる既知の問題は公表されていません。 ファームウェアの更新とEEPROMの内容をクローンした後、すべての影響を受けたPN5190デバイスで問題が解決したのか、教えていただけますか?この情報は、問題の範囲をよりよく理解するのに役立つだろう。 一部の端末で問題が継続する場合、正常に動作する端末と不具合のある端末との間でA/B比較テストを実施する機会はありましたか？このような検査は、根本原因がIC自体に関連しているのか、それともシステムの他の要素に関連しているのかを判断するのに役立ちます。 ロット追跡についてですが、代理店に製造ロットや影響を受けた部品の製造履歴について追加情報を提供できるか確認していただけますか? Re: PN5190B1 becomes unresponsive on first RF field ON 不可解な点は、正常に動作するユニットと故障するユニットが、同じファームウェアバージョン（v2.01）、同じシリコンリビジョン（B1）、同じハードウェア、同じアンテナチューニング、そしてクローン作成後には同じEEPROMの内容を持っていることだ。しかし、うまくいくものもあれば、ほとんどはうまくいかない。 PN5190のファームウェアをv2.0Dにアップグレードすることで、不具合のあるユニットの問題が解決します。その理由と、v2.01に既知の問題があるかどうかを知りたいです。   1. 症状: 故障したユニットについて： 起動と初期化は正常に完了します。 最初のRFフィールドオン時には、チップは意味のある電流を引きず、RFフィールドを発生させません(NFC電源のLEDテストカードで確認済みで点灯しません)、SPIでは完全に反応しなくなります。 ホストがIO_TIMEOUTを報告しました。ソフトリセットも失敗します（SPI応答が必要です）。 チップを復旧させるには、ハードウェアリセットまたは電源の再投入のみが必要です。その後は次のRFフィールドオンまで正常に動作しますが、そこでまたフリーズします。完全に再現可能。 電源電圧（3.3V）は終始安定しており、電圧低下は発生しません。 ボードの寿命で初めての電源アップ時に、一度きりの~600 mA(北欧PPK2で測定した0.62A)のイベントが観測されますが、その後のパワーアップでは二度と発生しません。 故障したユニットのNFCコックピットからのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。 情報:RfFieldControlService:RFオン 警告:代表:PIN_IRQが高くなるのを待っていた。タイムアウトしました。 エラー:RfFieldControlService:フィールドオン中にエラー240、IO_TIMEOUTが発生しました。 正常に動作しているユニット（ファームウェア、設定は同じ）からのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。 情報:RfFieldControlService:RFオン 情報:RfFieldControlService:RF Off(RF オフ) ATQA 04 00 / SAK 0x08 / UID 04 8D12 33 2. テストセットアップ 自社のホストファームウェアを除外するため、NXPのナレッジベース記事「 外部PN5190を評価ボードPNEV5190BPに接続 する方法」(R5/R7設置、R6開)に従い、本番ボードをUSB↔SPIブリッジとして使うPNEV5190BPに直接接続しました。R20入賞;VBAT/VBAT_PWR/VUPジャンパーは撤去されました。SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND、外部ボードに配線)。 NFC Cockpit v9.0.0 PNEV5190BP with MCU FW NNC_uC_VCOM_04.00.00 外部基板はNordic PPK2から3.3Vで給電される（電流測定が可能）。 この故障はNXPホストとNXPソフトウェアの両方で再現されているため、ホストファームウェアが原因ではありません。 3．除外した項目（測定値付き）： 仮説 どのようにして除外されたのか 供給崩壊／停電 3.3Vレールは全体を通して安定して測定されました 送信機の短絡 良品と不良品の直流抵抗値（TX1-TX2間、TX1-GND間、TX2-GND間）は同一（数kΩ） PAデカップリングにおけるリーク 現場投入の瞬間までは、電流消費量は同じで、良い場合も悪い場合もある。 アンテナの同調ずれ／マッチング VNA測定、良品4台＋不良品4台 — 下記参照 ICへの物理的損傷 チップはハードウェアリセットで復旧するが、その後再び再現可能な形で故障する。 ホストファームウェア NFC Cockpit + PNEV5190BPを使用して再現 PN5190ファームウェアバージョン 良品と不良品の両方がv2.01、Hw B1にあります ユーザーEEPROMコンテンツ 正常なユニットのEEPROM全体を不良ユニットにクローンしたが、それでも失敗する。 差：約29kHz（0.2％）、測定ノイズの範囲内。8つの掲示板で確認済み。アンテナは区別がつかない。 4. EEPROMの比較 - 1バイト 良いユニットと悪いユニットの両方のユーザーEEPROMを完全にFW v2.01でダンプし、それらをファレンジしました。 648個のパラメータのうち、正確に1つだけ異なる。 地域: DPC_SETTINGS パラメータ: DPC_CONFIG オフセット: 0x76 良品ユニット: 0x77 不良ユニット: 0x76 それ以外の部分はすべてバイト単位で同一です。 これは答えのように思えた。特にRN00003の注意書きを考慮すると尚更だ。 「対称」アンテナに接続されたIC(例:カスタマー開発ボードアンテナ)では、DPCを無効化せずRFフィールドを有効化しないでください。長期間にわたる過電流による送信機ドライバーの損傷が起こる可能性があります。 当社のアンテナは対称型(差動TX1/TX2)で、最初の電源を入れた時の一度きりの~600 mAの現象は過電流状態と一致しています。 しかし、バイトをコピーしてもユニットは修復されません テスト 結果 不良ユニットにDPC_CONFIG = 0x77を書き込み（v2.01）、読み出し結果を確認し、電源を再投入する。 それでも失敗する 正常ユニットの完全なEEPROMダンプを不良ユニットにロードし（v2.01）、電源を再投入する それでも失敗する 良好なユニット、未改造、v2.01 完璧に動作します つまり、DPC_CONFIG合格・不合格と関連していますが、原因ではありません。本当の違いが何であれ、それはユーザーのEEPROM領域には含まれていません。 5. 解決策：ファームウェアをV2.0Dに安全にアップグレードする   PN5190Firmware_2.0D.esfwu （LEDLフォルダ、B0/B1用レガシーダウンロード）を使用してセキュアファームウェアアップグレードを実行すると、不具合のあるユニットが正常に動作するようになります。 アイドル時：約33mA RFフィールドオン:~240 mA持続、安定、LED点灯 Layer3 をアクティブにすると、ATQA 04 00、SAK 0x08、UID 04 8D 12 33 が返されます。 自社製品ファームウェアで動作を確認しました これまでに2ユニットがこの方法で回収されており、どちらも完全に機能しています。 副作用：PwrConfigが上書きされ、過熱を引き起こす。 アップグレード後、EEPROMオフセット0x0000 （ PwrConfig ）は0x21から0xE4に変更されます。0xE4の場合： PwrConfig 0xE4 PwrConfig 0x21 (復元済み) アイドル電流 約290mA 約33mA ダイ温度（ PMU_TEMP_REG@0x5B ） 100℃ 40 °C アイドル時は290 mAでRFフィールドなし、内部温度センサーは100°C(最大Tjは125°C)を読み取ります。アップグレード後には毎回PwrConfigを0x21に復元します。 0xE4は、v2.0DにおけるPwrConfigのデフォルト値として意図されているのでしょうか？これは他のユーザーにとっても問題になりそうです。 アップグレードによって変更された16個のEEPROMパラメータ パラメータ オフセット 以前のバージョン（v2.01） (v2.0D) 後 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 極性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 デジタルTBシグナルインデックス 0xCE9 0x00 0x9B デジタルTB信号ビット 0xCEA 0x00 0x04 AnalogTBSignal 0xCEB 0x00 0x78 良いユニットの完全なEEPROMを不良ユニットにクローンしても直らないため、この16バイトだけでは解決できず、ファームウェアコード自体に何かが関与しているはずです。 6. ダイID 全てのユニットは、受領時の状態のままハードウェアB1、ファームウェアv2.01です。 不良品 #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 不良品 #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 不良品 #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良品 #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 質問 FW v2.01で、RF Field ONがフィールドもSPI応答もないままICがハングしてしまう既知の問題はありますか?DPC_CONFIGレジスタはv02.03で初めて導入された（RN00003による）こと、そしてv02.07→v02.08とv02.08→v02.09の両方にDPC制御の修正が含まれていることに注意してください。 ファームウェア、シリコンリビジョン、ハードウェア、EEPROMがすべて同じであるにもかかわらず、なぜ約25%のユニットは正常に動作し、約75%は動作しないのでしょうか？ユーザーEEPROMの範囲外(工場出荷時のトリムや内部状態)で、同じロットのユニット間で異なるものはありますか? 上記のダイIDは異なる生産ロットやウェハーバッチに特定できますか? v2.0Dにアップグレードした後、PwrConfig = 0xE4という値は意図された値ですか？その結果、当社の設計ではアイドル消費量~290 mA、ダイ温度100°Cとなります。 PN5190デバイスは特定のファームウェアバージョンを事前にプログラムした状態で注文できますか?ツール自体がバージョン2.01が旧バージョンであることを警告しているにもかかわらず、バージョン2.01で出荷したため、生産バッチ全体が無駄になってしまいました。 残りの80~0ユニットの未使用ユニットに対して、一度きりの600 mAイベントを完全に回避するために、最初の電源アップ前にv2.0Dにアップグレードすることが推奨される緩和策でしょうか? アドバイスをいただければ幸いです。

.mex 文件中的警告文件 在（自动生成的）.mex 文件中项目文件中，每个外设的内容大致如下： 1.0.0 请注意“描述”属性中的措辞。对于其他外围设备，情况各不相同，但几乎总是会显示警告或错误消息之类的信息。项目编译和运行都没问题。 另外，如果我尝试从“外围设备视图”添加新的软件组件，所有当前未选择的外围设备都会被标记为黄色感叹号，请参见附件屏幕截图。如果我将鼠标悬停在它们上面，就会得到与“描述”属性中显示的相同的消息。但我添加它们没有任何问题。 这些警告是关于什么的？ Re: Warning in the .mex file 你好@durga_choudhury 此警告不会影响您的项目。这仅表明项目中尚未添加或配置相应的驱动程序。因此，预计不会对您当前的实现造成任何功能影响。 BR，VaneB

Warning in the .mex file In the (autogenerated) .mex file for a project, each peripheral reads something like this: 1.0.0 Notice the verbiage in the "description" attribute. For other peripheral this varies, but it is almost always something like a warning or an error message. The project compiles and runs fine. Also related, if I try to add a new software component from the 'Peripherals view', all the currently unselected peripherals are marked with yellow exclamations, please see the attached screen shot. If I hover the mouse over them, I get the same message shown in the "description" attribute. Yet I am able to add them without any issues. What are those warnings about? Re: Warning in the .mex file Hi @durga_choudhury  This warning does not affect your project. It is only an indication that the corresponding driver has not been added or configured in the project. Therefore, no functional impact on your current implementation is expected. BR, VaneB

由 MCUxpresso IDE 生成的 Makefile 执行 大家好， 我们使用了 MCUxpresso IDE，导入了 imxrt1170 评估板的示例 SDK，并构建了项目文件。 MCUxpresso IDE 本身已自动生成了 Makefile 文件。所以我的问题是，如何在不使用 MCUxpresso 的情况下，在我的 Windows 系统中执行此 make 文件，例如使用 make all、make clean 和 make 命令来生成二进制文件（MCUxpresso 使用的是 .axf 文件）。 我还附上了 Makefile 文件，供您参考。 Re: Makefile execution generated by MCUxpresso IDE 你好， 我是Windows用户。使用MCUXpresso 的 makefiles 完全取决于%PATH%变量。 我发现从命令行运行“ make ”命令的最简单方法是按住Ctrl键并单击MCUXpresso IDE右下角的项目名称： 这将在您的项目目录中打开一个终端窗口，并将%PATH%正确设置，以便您可以输入“ make clean ”和“ make -j8 all ”以及类似的命令。 当然，您可以关闭 IDE，终端窗口仍会保持打开状态。您还可以检查%PATH%变量。在任何其他终端窗口中设置此路径，您也可以在那里运行 make 命令。 希望你能好好利用它。 此致， 丹尼尔 Re: Makefile execution generated by MCUxpresso IDE Eclipse 中自动生成的 make 文件（托管 make）不具备可移植性。您可以使用 SDK（非 IDE）中的 make 文件，或者更好的选择是使用 CMake 来获得一个可移植的构建系统。我正在使用https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/中描述的方法，以便同时使用 IDE、make 和 CMake 进行构建。 Re: Makefile execution generated by MCUxpresso IDE 嗨@Jeevan ， 我认为你可以参考 gcc 项目在 SDK 中构建它，因为它也使用 makefile，而无需 IDE。 关于gcc版本方法，您可以参考SDK文档： SDK_2_14_0_MIMXRT1170-EVK\docs\MIMXRT1170-EVK MCUXpresso SDK 入门指南.pdf 第六章 使用 Arm ® GCC 运行演示 您还可以参考我的 Ubuntu 版本方法文档： https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 希望对您有所帮助！ 如果您还有任何疑问，请随时告诉我。 顺祝商祺！ kerry

imx8mmini sai1 max sample rates hi     sai1 connect a codecs support sample rates 768khz/32bit. SAI1-RX0 connect codec_DOUT. have no data with 768khz/32bit and L/R channels to read.but SAI1-TXFS/SAI1-TXC could output 768khz/49.152Mhz. read L/R channels with 768khz/16bit and 384khz/32bit is ok.kernel version 6.1.36. thanks. Re: imx8mmini sai1 max sample rates about codecs dts as below: run arecord cmd with "-f S32_LE -r 384000 -c 2 -d 1 test.wav" or "-f S16_LE -r 786000 -c 2 -d 1 test.wav" is ok. but run with "-f S32_LE -r 768000 -c 2 -d 1 test.wav",test.wav is NULL. Re: imx8mmini sai1 max sample rates Hello, Could you please share your device tree configuration? Which CODEC are you using? Best regards. Re: imx8mmini sai1 max sample rates Hello, If you are getting errors related to the sample rate, could be caused by clock source since it is not able to generate the necessary frequency for that sample rate. Sometimes, is needed to use a dedicated clock source such as an external clock to get an specific sample rate. Best regards. Re: imx8mmini sai1 max sample rates when read with 768kHz 32bit x 2 channel,SAI1_TXFS/SAI1_TXC output is ok(768khz/49.152Mhz),The codec data output pin (connect to SAI1_RX0)has data output when checked with an oscilloscope.Is it possible that imx8mmini sdma is not worKing? Re: imx8mmini sai1 max sample rates Hello, Do you get underflow or overflow errors during testing? Best regards. Re: imx8mmini sai1 max sample rates get kernel print errors during testing as below: [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) Re: imx8mmini sai1 max sample rates Hello, Please share your dmesg: dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" With that error log the issue could be caused by an overrun, please try to increase period and buffer size, for example: arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav Best regards. Re: imx8mmini sai1 max sample rates hi JorgeCas:  thanks for your reply. the same error when  increase period and buffer size. ------------------------------------ root@mx8mm:/tmp# arecord -v -D hw:0,0 -f S16_LE -r 768000 -c 2 -d 1 test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 768000 Hz, Stereo Hardware PCM card 0 'pcmdev-audio' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 768000 exact rate : 768000 (768000/1) msbits : 16 buffer_size : 131064 period_size : 16383 period_time : 21332 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 16383 period_event : 0 start_threshold : 1 stop_threshold : 131064 silence_threshold: 0 silence_size : 0 boundary : 9222809086901354496 appl_ptr : 0 hw_ptr : 0 root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 3072044 Jul 22 22:09 test.wav root@mx8mm:/tmp# arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo arecord: pcm_read:2221: read error: Input/output error root@mx8mm:/tmp# dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000b8400000, size 1 MiB [ 0.000000] OF: reserved mem: initialized node vdevbuffer@b8400000, compatible id shared-dma-pool [ 0.000000] DMA [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] DMA32 empty [ 0.000000] Policy zone: DMA [ 0.043871] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations [ 0.044176] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.044364] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.105243] iommu: DMA domain TLB invalidation policy: strict mode [ 0.195002] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 0.195018] imx-sdma 302c0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 0.199761] mxs-dma 33000000.dma-controller: initialized [ 1.996379] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA [ 2.786360] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA [ 8.812860] imx-sdma 302c0000.dma-controller: firmware found. [ 8.818748] imx-sdma 30bd0000.dma-controller: firmware found. [ 8.825901] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 91.326700] [857] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 91.326722] [857] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 91.326728] [857] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 91.326734] [857] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 91.342776] [857] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 2 for freq 24576000Hz based on clock 49152000Hz [ 91.342784] [857] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=2, deviation =0 [ 91.343315] [857] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 113.965788] [861] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 113.965809] [861] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 113.965816] [861] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 113.965822] [861] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 113.977610] [861] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 1 for freq 49152000Hz based on clock 49152000Hz [ 113.977618] [861] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=1, deviation =0 [ 113.978149] [861] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 124.127055] [861] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 44 Jul 22 22:09 test.wav root@mx8mm:/tmp#

S32K312 上的 Fat 文件系统集成（RTD 6.0.0，非AUTOSAR、SPI SD卡驱动程序） 您好， 我已经成功地在 S32K312 EVB 上使用 RTD 6.0.0（非 AUTOSAR Lpspi_Ip 驱动程序）实现了通过 SPI 的 SD 卡驱动程序。 以下功能已实现： SD卡初始化（CMD0、CMD8、ACMD41、CMD58） 单块读取（CMD17） 单块写入（CMD24） 多块读取（CMD18） 多块写入（CMD25） 已通过向 SD 卡写入数据并成功读取数据验证了驱动程序。 现在我想添加对 FAT 文件系统的支持，以便在 PC 上创建、写入和读取文件。 我有几个问题： NXP 是否为使用 RTD 6.0.0（非 AUTOSAR）的 S32K312 提供或支持 FatFs 集成？如果没有，是否有其他 S32K3 设备的示例可供参考？ NXP是否有任何中间件软件包可以将FatFs与SD卡集成？ 如果没有官方示例，建议的方法是集成 Elm-Chan FatFs 库并实现所需的 diskio.c 函数。使用我现有的SD卡驱动程序进行接口？ 是否有任何参考项目、应用笔记或示例库演示了在 S32K3 设备上集成 FAT 文件系统？ 我有点困惑，不知道哪种方法更适合产品开发。任何指导或参考资料都将不胜感激。 谢谢！ Re: Fat Filesystem Integration on S32K312 (RTD 6.0.0, Non-AUTOSAR, SPI SD Card Driver) 嗨@parvathitp 目前 S32K312 尚不支持 FatFS 文件系统。在 S32K3 系列中，FatFS 集成仅适用于包含 uSDHC 外设的设备，该外设提供微控制器和 SD 卡之间的硬件接口。 对于这些设备，我们提供了一个 SDHC 软件栈，通过 uSDHC 驱动程序简化对 SD 总线的访问，并实现与 FatFS 的集成。 社区帖子“将 FatFs 文件系统移植到 KL26 SPI SD 卡代码”中描述的方法和概念可能对您的实现有所帮助。虽然该示例基于 KL26 设备，但正如标题所示，它描述了如何将 FatFS 文件系统移植到不包含 SDHC/uSDHC 外围设备的设备上，这与您的用例类似。 BR，VaneB