问题： java.io.IOException：Script not found: ... Level：错误类型：工具错误 你好 对于恩智浦项目，我点击这个链接只是为了简单地使用示例，我完全遵循了但是 java 异常出现问题，想找到一些 MCAL 元器件和驱动程序来为 dio 或端口编写脚本，mcu... 找不到我的 codegenerator.js 的路径，但是，我的所有文件都在我的 eclispe 工作区 上，我花了 3 天时间试图解决这个问题，它非常复杂，我管理了我的驱动程序，检查了到 eclipse 的路径、 链接：https://nxp.gitbook.io/nxp-cup/2024-fall-2025-nxp-cup-bare-metal-drivers/s32k144-rtd-software-setup/rtd-software-packet-installation -我使用的是 S32DS 平台 3.5 更新版 3 -SW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_D2308_DS_Updatesite 请！如果有人能帮我，我找不到问题所在，也不想再过几天独自搜索而没有问题。 Re: Issue: java.io.IOException: Script not found: ... Level: Error Type: Tool pr 谢谢您！ Re: Issue: java.io.IOException: Script not found: ... Level: Error Type: Tool pr 我遇到了同样的问题，可以确认重命名元器件的文件以使其大小写与错误打印中的大小写相匹配可以解决问题。 在 Ubuntu 上，它们位于 ~/nxp/s32ds3.5/eclipse/mcu_data/components/platformsdk_s32K3/ Re: Issue: java.io.IOException: Script not found: ... Level: Error Type: Tool pr 嗨，@土星、 感谢您提供的信息和解决方法！ Re: Issue: java.io.IOException: Script not found: ... Level: Error Type: Tool pr 由于 Linux 操作系统的大小写敏感性，Linux 不支持 RTD。 要让 RTD 在 Linux 上运行，需要对文件夹进行一些更改：/nxp/s32ds.3.x/eclipse/mcu_data/Components 请阅读 "ReadmeToModifyTheRTD.txt"、我只对我的项目做了必要的改动，其他代码可能需要更多改动。好在我已经制作了 sh 文件，只需两步就能完成工作。 这只是我的看法：在 S32DS 进行代码编译和调试时，Linux 操作系统的运行速度要快得多。恩智浦应该正式支持它，包括 RTD ~ ，恩智浦的同事们，请在编码时注意字母的大小写敏感性。 Re: Issue: java.io.IOException: Script not found: ... Level: Error Type: Tool pr 嗨，@Raphael_Q78、 这可能是您的 RTD 安装出现了问题，您可以按照本指南进行尝试吗？ 方法：在 S32DS v3.5 中离线安装 S32K1 RTD 2.0.0 - NXP Community。 看了你的照片，似乎你使用的是 Linux 发行版，能确认一下你的操作系统吗？ 致以最诚挚的问候， Julián

S32 BSPの問題 S32GプロセッサにVxWorks 7.0オペレーティングシステムを導入済みかどうか、またはVxを起動できるBSPをお持ちかどうかお伺いしたいのですが。 Re: S32的BSP问题 こんにちは、 @YPKEJI12341 こんにちは 1. 現在、NXPがリリースしている公式BSPは開発およびテスト用にLinuxをベースとしており、Vxworksを直接サポートしていません。 2. 確かに、一部のお客様はS32GにVxWorksを導入されています。関連ソフトウェア情報については、Windriverのテクニカルサポートにお問い合わせください。 BR チェイン

KW47B42Z83AFTB 上的 RADE 错误（代码 1） - digital_key_car_anchor_cs_freertos 嗨，恩智浦支持团队、 我们在自定义 PCB 上使用 KW47B42Z83AFTB 作为 ECU（锚/车侧）和应答器（设备端）角色。 设置： - SDK：sdk_25_12_00_kw47b42z83xxxa-ECU（启动器/汽车锚点）：使用 digital_k ey_car_anchor_cs_freertos 闪存 ——转发器（反射器/设备）：使用 d igital_key_device_cs_ freertos 闪存——两款设备均采用自定义 PCB 设计 问题： 在启动器方面（ECU /汽车锚点），我们在信道探测过程中持续收到 RADE 错误代码 1。RTT 距离测量在两端都能正常运行，但是基于 Rade 的距离计算在启动器上失败。 问题： 1.当前的 SDK 是否支持 KW47B42Z83AFTB（无 LCE）上的 RADE 距离计算？ 2. 错误代码 1 是否表示需要 LCE 硬件但不存在，或者是否有可用的软件备用？ 3. app_preinclude.h 中是否有任何已知的配置标志？还是需要在非 LCE 变体上为 RADE 设置的 CS 配置文件层？ 请与我们联系，了解其他日志或配置文件是否有帮助。 致以最崇高的敬意 Christian BLE-NFC BLUETOOTH-BEACON Re: RADE Error (Code 1) on KW47B42Z83AFTB — digital_key_car_anchor_cs_freertos 你好 希望你一切顺利。使用不带 LCE 的集成电路版本有什么特殊原因吗？ 总之，我建议您查看 SDK 文档中的这一部分：启用 RADE v1 使用（非LCE） - MCUXpresso SDK 文档 顺祝商祺！ 里卡多

ICODE SLIX2 独创性签名 恩智浦社区你好， 我正在使用 RC663 ISO 15693 阅读器 在嵌入式 MCU（GD32F303CC、ARM Cortex-M4）上实现 AN11350 中描述的 ICODE SLIX2 原创性签名验证。 已成功从标签中读取签名（通过 命令 0xBD 为 32 字节），但是 ECDSA 验证总是失败。 如能说明正确的哈希值/信息格式，我将不胜感激。 ───────────────── 硬件 & 软件 ─────────────────── ── 读者：恩智浦 RC663 标签：恩智浦 ICODE SLIX2 (SL2S2602) 曲线：secp128r1（由 32 字节签名 = r|s 确认，每个 16 字节）ECC 库：easy-ecc (https://github.com/jestan/easy-ecc) 使用 ECC_CURVE = secp128r1 (ECC_BYTES = 16) MCU 编译：GD32F303CC（ARM Cortex-M4，无操作系统） ─────────────── READ_SIGNATURE 命令 (0xBD) ────────────── 请求帧（11 字节，ISO 15693 寻址模式）： FLAGS = 0x22 (高数据速率 | 地址标志) CMD = 0xBD (READ_SIGNATURE，恩智浦自定义命令) MFG_CODE = 0x04 (恩智浦集成电路制造商代码 — 0xA0–0xDF 范围必需) UID = 8 字节（已寻址） 响应（33 字节）： FLAGS = 0x00 (无错误) SIG = 32 字节 通过与 对相同标签的 proxmark3 扫描进行比较，32 字节签名和 UID 已确认正确。 ──────────────────公钥 ────────────────── ── 33 字节 公钥：048878a2a2a2d3eec3eec336b4f261a082bd71f9be11c4e2e2e896648b32efa59cea6e59f0 使用 seca6e59f0 p128r1 压缩公钥（17 字节）：0x02、0x88、0x78、0xA2、0xA2、0xD3、0xEE、0xC3、0x36、0xB4、0xF2、0x61、0xA0、0x82、0xBD、0x71（前缀 = 0x02 因为 y 坐标的 LS B 是奇数）) 标签供应商已确认公钥正确无误。 ──────────────────────── RC663 缓冲区中的 UID 字节顺序 ───────────────────────────────────── ISO 15693 首先传输 UID LSB。 RC663 按接收顺序填充接收缓冲区，因此： UID [0] = 收到的第一个字节 = 64 位 UID 的 LSB UID [7] = 收到的最后一个字节 = 0xE0（MSB，固定 ISO 15693 前缀） 示例标签 UID（显示/大端顺序）：E0 04 01 A2 B3 C4 D5 E6 缓冲区内容：UID [] = {E6、D5、C5、C6 4、B3、A2、01、04、E0} ─────────────────────────────────────────────────────────────────────────── ─────────────────────── AN11350 表示签名是通过 UID 计算的，但没有明确规定：1. 用作 ECDSA 消息的 UID 的字节顺序 （大端显示顺序与从标签收到的 LSB 优先顺序对比）2。 如何使用 8 字节 UID 进行零填充以填充完整的 128 位哈希字段 我在下面尝试了所有四种合理的组合 — 全部返回验证 失败： 选项 A：高 8 字节哈希中的 UID 原始（LSB-First），低 8 字节哈 希 = {UID [0]，UID [1]，...，UID [7]，0，0，0，0，0，0，0，0，0，0，0，0} 选项 B：高 8 字节中的 UID 反向（大端），低 8 字节 哈希值为零 = {UID [7]，UID [6]，...，UID [0]，0，0，0，0，0，0，0} 选项 C：高 8 字节为零，低 8 字节哈希中的 UID 原始（LSB-first）= {0，0, 0, 0, 0, 0 , 0, 0, UID [0], UID [1],..., UID [7]} 选项 😧 高 8 字节为零，低 8 字节哈希值中的 UID 反向（大端）= {0、0、0、0、0、0、0、0、0、0、UID [7]、UID [6]、...、UID [0]} 在 easy-ecc 中，ecc_bytes2native () 将 16 字节 哈希缓冲区视为大端 128 位整数： p_native [1]（高 64 位字）← 哈希 [0.. 7] p_native [0]（低 64 位字）← 哈希 [8.. 15] ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── sig); /* 0 = 失败，1 = 通过 */ ─────────────────────────────────────────

RW612 GAU GPADC0 — inconsistent / non-monotonic readings on a high-impedance source Setup MCU: NXP RW612 on a Murata 2FR module Software: Zephyr RTOS (GAU ADC driver adc_mcux_gau_adc) ADC: GAU_GPADC0, base 0x40038000, channel 3 (single-ended) on GPIO_45 Use case: battery voltage monitoring, 22 V to 29 V range Voltage divider on the analog input Vbat ──[R1 = 243 kΩ]──┬──[R2 = 10 kΩ]── GND │ GPIO_45 / ADC0_CH3 Thevenin source impedance: ~9.6 kΩ Expected pad voltage at Vbat = 25 V → 988 mV Vbat range 22–29 V → pad range 869–1146 mV (well within Vref headroom) Zephyr device-tree configuration &adc0 { status = "okay"; /delete-property/ nxp,input-buffer; /* try to disable INBUF via DT */ channel@3 { reg = <3>; zephyr,gain = "ADC_GAIN_1"; zephyr,reference = "ADC_REF_INTERNAL"; /* maps to VREF_SEL=01 (1.2V) */ zephyr,vref-mv = <1200>; zephyr,acquisition-time = ; zephyr,resolution = <12>; zephyr,input-positive = ; }; }; Application-level configuration static struct adc_channel_cfg channel_cfg = { .gain = ADC_GAIN_1, .reference = ADC_REF_INTERNAL, .acquisition_time = ADC_ACQ_TIME_DEFAULT, .channel_id = 3, .input_positive = 3, /* GAU_ADC_CH3 */ }; static int16_t adc_buffer; static struct adc_sequence adc_seq = { .channels = BIT(3), .buffer = &adc_buffer, .buffer_size = sizeof(adc_buffer), .resolution = 12, .calibrate = true, .oversampling = 4, /* 16x HW averaging */ }; What I had to fix manually to get any sensible reading at all These are issues we encountered and worked around — listed here in case any of them point to a real bug or a misuse: 1. INBUF_EN was never actually being cleared The Zephyr driver does not propagate /delete-property/ nxp,input-buffer; from the DT into the hardware on this SoC, so we cleared ADC_REG_ANA[14] directly: /* GAU_GPADC0 base 0x40038000, ADC_REG_ANA at offset 0x10 */ volatile uint32_t *p = (volatile uint32_t *)0x40038010; *p &= ~(1U << 14); /* clear INBUF_EN */ Without this, the input buffer biases the high-impedance divider and gives a systematic offset. 2. GPIO_45 default pad pull-up biases the divider node by ~200 mV At reset, SOCCIU_PAD_PU_PD_EN2 (offset 0x78 of SOCCTRL non-secure base 0x45001000) had bits [27:26] = 01 → ~100 kΩ pull-up to VDDIO active on GPIO_45. On a 9.6 kΩ Thevenin source this offsets Vadc by ~200 mV. The nxp,mci-io-mux Zephyr pinctrl driver does not expose a bias-disable property for analog pins, so we clear the bits manually at boot: /* Clear GPIO_45 pad pull (PAD_PU_PD_EN2 bits [27:26]) */ volatile uint32_t *p = (volatile uint32_t *)0x45001078; *p &= ~(0x3U << 26); After this, the multimeter at the pad reads exactly Vbat × 10 / 253 (within ~2 %, consistent with resistor tolerance), so the divider itself and the pad biasing are now clean. 3. Settling / always-on divider For diagnostic purposes, the divider is now permanently powered (instead of being switched via a MOSFET) so settling is not an issue. The pad voltage is verified stable with a multimeter before each ADC sample. Verified register state at the time of measurement GAU_GPADC0 (0x40038000): ADC_REG_ANA [0x40038010] = 0x0000A810 → INBUF_EN=0, VREF_SEL=01 (1.2 V), INBUF_GAIN=01, INBUF_CHOP_EN=1, ADC_CHOP_EN=1, RES_SEL=00 (12-bit) ADC_REG_CONFIG [0x40038014] = 0x00000000 MCI_IO_MUX (0x40004000): GPIO_GRP0 [0x40004030] = 0x001C1C02 GPIO_GRP1 [0x40004034] = 0x201EDBD8 SOCCIU PAD_PU_PD_EN2: [0x45001078] = 0x01152400 → GPIO_45 PU/PD bits = 00 (no pull) What I tried before posting All combinations below were tested with the divider permanently powered, multimeter confirming the analog input is the steady-state expected value: Knob Values tried Effect on RAW VREF_SEL (reference) 1.2 V (01) → 1.8 V (00) RAW scales by ~1.2/1.8 as expected, but the mismatch with the multimeter persists with the same factor INBUF_GAIN (gain) gain=1 (01), gain=0.5 (00), gain=2 (10) No effect — suggests INBUF_GAIN does nothing while INBUF_EN=0 BYPASS_WARMUP / WARMUP_TIME 0 (bypass) up to 32 (max) cycles No measurable effect on RAW ADC_CHOP_EN & INBUF_CHOP_EN both ON, both OFF No effect Zephyr .calibrate true / false No effect   The remaining issue Even with everything above looking correct, RAW does not track the input voltage in a sensible way. Sequence of measurements (Vbat fed by a stable bench supply, divider verified by multimeter at each point): Vbat (V) Pad (multimeter, mV) Pad expected = Vbat·10/253 (mV) RAW from adc_read() 22 848 869 1682 24 928 949 1708 26 1007 1028 2413 28 1084 1107 1745 29 1122 1146 1860 The multimeter column is monotonic and matches divider theory within ~2 %. The RAW column is non-monotonic (jumps to 2413 at 26 V, then down to 1745 at 28 V). Even ignoring the 2413 outlier, ΔRAW between 22 V and 28 V is only +63 LSB for +236 mV at the pad. With Vref = 1.2 V at 12-bit, expected ΔRAW ≈ 805 LSB. So the apparent gain is roughly 0.08× of theoretical — clearly wrong. Earlier individual readings at single set-points had given RAW ≈ 2415 at Vbat ≈ 25 V (multimeter pad ≈ 990 mV), which would imply effective Vref ≈ 1.68 V instead of the configured 1.2 V — also unexplained.   My questions Is there any front-end attenuator or fixed gain on the GAU GPADC single-ended input path that is always active when INBUF_EN = 0, regardless of INBUF_GAIN? The ratio I'm seeing (~0.6 to 0.7×) is independent of VREF_SEL and INBUF_GAIN. Is INBUF_EN = 0 (direct sampling) actually a supported / characterized mode for single-ended measurements on RW612, or is it only valid for differential mode? The reference manual implies the input buffer should normally be enabled, but enabling it makes high-impedance sources unusable due to bias current. What is the maximum recommended source impedance for ADC0_CH3 in single-ended direct-sampling mode? Is 9.6 kΩ Thevenin acceptable or is an external buffer required? Is GPIO_45 a "special" channel (it can also carry EXT_VREF for external reference) — does the EXT_VREF analog path stay connected even when VREF_SEL = 01 (internal 1.2 V), and could it be loading the input? Are there any known errata or chopper-related artifacts on the GAU GPADC for high-impedance, low-frequency DC inputs? Thanks! Re: RW612 GAU GPADC0 — inconsistent / non-monotonic readings on a high-impedance source Hello @_arthur_, hope you are doing well. Would you please confirm in which Zephyr version have you done these tests? Regarding the Zephyr version, there is now available the release of Zephyr 4.4.0 of our downstream repository, would you please confirm if the behavior that you are observing is also present in this version? Additionally, have you been doing these tests on a custom application? Or is it from a repository example?

EIS BMSを構築したい EIS BMSを構築したい。秘密保持契約（NDA）以外でICとデータシートを入手する方法はないのでしょうか？これは個人的な研究目的です。 私は現在、韓国の忠南国立大学で修士号と博士号の取得を目指している学生です。 現在、BMSのハードウェア設計とファームウェアに関する包括的な研究を行っており、既存のICをNXP製のICに交換し、EIS機能を組み込みたいと考えています。 大学がNXPと秘密保持契約（NDA）を結んでいるかどうかは分かりませんし、それを確認する方法も知りません。私は普段DigiKeyからしか商品を購入しないので、このような情報を入手しようとしたのは今回が初めてです。もしご迷惑をおかけしたようでしたら、お詫び申し上げます。 #BMA7418 EIS BCC #BMA8420 EIS BCC #TAA3033 #FS26 PMIC もし可能であれば、各ICのリファレンスファームウェアのソースコードも入手できますか？ 貴社資料の中から[ホワイトペーパー]-EISがバッテリーシステムを廃止する、を拝見した後、ご連絡させていただきました。 Re: I want to build an EIS BMS パーク様、 大学がNDA（秘密保持契約）に署名しているかどうか不明な場合は、こちらから新しいチケットを作成してください。当社のNDA担当者が確認し、まだNDAが締結されておらず、お客様が署名を希望される場合は、その手続きについてご案内いたします。 関連するドキュメント、ハードウェア、ソフトウェアなどは、通常、製品ページで入手できます。以下のリンクをご確認ください。 BMA7418 、 BMA8420 、 TAA3033 、 FS26 。 文書は通常、機密情報として「安全な場所」セクションに分類されており、有効な秘密保持契約（NDA）を締結することでダウンロードできます。 ソフトウェアについては、各リンク先のソフトウェアセクションまでスクロールしてください。 ダウンロードオプションをクリックしてください。ソフトウェアドライバのページに移動します。 敬具、 ヨゼフ

S32K324向けHSE FW API統合 私たちは、HSE-FWがインストールされているボード上でアプリケーションを実行したいと考えています。 当社のアプリは、HSE-FWがインストールされていなくても正常に動作します。しかし、HSE-FWをインストールした後、デバッガーエラーが発生し、ハードフォルトに移行します。HSE_FWがMCUにインストールされた状態でアプリケーションを実行するために、アプリケーション側でどのような処理が必要なのかを知りたいです。 この件に関する情報が記載されている文書やリンクがあれば、ぜひ共有してください。 ありがとうございます アニル Re: HSE FW API integration for S32K324 HSE FW「HSE_FW_S32K3XX_0_2_1_0」をインストールしました。 RTDバージョン：4.0.0.202401161212 アプリを起動した後、例外の詳細が表示されたエラー画面が表示されます。添付のスクリーンショットをご覧ください。 よろしくお願いいたします。 アニル Re: HSE FW API integration for S32K324 こんにちは、 インストールされているHSEのバージョンとインストール方法をお知らせください。どのRTDバージョンを使用していますか？ リセット状態からデバッガーに接続して、レジスタの状態を確認し、障害の原因となったリセット箇所を特定できますか？ よろしくお願いいたします。 ジョン

RW612 GAU GPADC0 — 高インピーダンス源での不整合/非単調な読み取り値 設定 MCU ：村田製作所製2FRモジュール上のNXP RW612 ソフトウェア：Zephyr RTOS（GAU ADCドライバ adc_mcux_gau_adc） ADC ：GAU_GPADC0、ベース0x40038000、 GPIO_45上のチャネル3（シングルエンド） 使用例：バッテリー電圧監視（22V～29Vの範囲） アナログ入力の分圧回路 Vbat ──[R1 = 243 kΩ]──┬──[R2 = 10 kΩ]── GND │ GPIO_45 / ADC0_CH3 テブナンインピーダンス：約9.6 kΩ Vbat = 25 Vにおけるパッド電圧の予測値 → 988 mV Vbat範囲：22～29V → パッド範囲：869～1146mV（Vrefの余裕範囲内） Zephyrデバイスツリー構成 &adc0 { status = "okay"; /delete-property/ nxp,input-buffer; /* try to disable INBUF via DT */ channel@3 { reg = <3>; zephyr,gain = "ADC_GAIN_1"; zephyr,reference = "ADC_REF_INTERNAL"; /* maps to VREF_SEL=01 (1.2V) */ zephyr,vref-mv = <1200>; zephyr,acquisition-time = ; zephyr,resolution = <12>; zephyr,input-positive = ; }; }; アプリケーションレベルの設定 static struct adc_channel_cfg channel_cfg = { .gain = ADC_GAIN_1, .reference = ADC_REF_INTERNAL, .acquisition_time = ADC_ACQ_TIME_DEFAULT, .channel_id = 3, .input_positive = 3, /* GAU_ADC_CH3 */ }; static int16_t adc_buffer; static struct adc_sequence adc_seq = { .channels = BIT(3), .buffer = &adc_buffer, .buffer_size = sizeof(adc_buffer), .resolution = 12, .calibrate = true, .oversampling = 4, /* 16x HW averaging */ }; まともな読み取り値を得るために手動で修正しなければならなかったこと 以下は、私たちが遭遇し、対処した問題点です。万が一、これらの問題が実際のバグや誤用を示している場合に備えて、ここに記載しておきます。 1. INBUF_ENは実際にはクリアされていませんでした Zephyrドライバは、このSoC上でDTから/delete-property/ nxp,入力バッファ;をハードウェアに伝播しないため、ADC_REG_ANA[14]を直接クリアしました。 /* GAU_GPADC0 base 0x40038000, ADC_REG_ANA at offset 0x10 */ volatile uint32_t *p = (volatile uint32_t *)0x40038010; *p &= ~(1U << 14); /* clear INBUF_EN */ これがないと、入力バッファが高インピーダンス分圧器にバイアスをかけ、系統的なオフセットが生じる。 2. GPIO_45のデフォルトパッドプルアップにより、分圧ノードは約200mVのバイアスがかかります。 リセット時、SOCCIU_PAD_PU_PD_EN2 (SOCCTRL 非セキュアベース 0x45001000 のオフセット 0x78) のビット [27:26] = 01 → GPIO_45 で VDDIO への約 100 kΩ のプルアップが有効になっていました。9.6 kΩのテブナン電源では、これによりVadcは約200 mVオフセットされます。 nxp,mci-io-mux Zephyr pinctrlドライバはアナログピンのバイアス無効化プロパティを公開していないため、起動時に手動でビットをクリアします。 /* Clear GPIO_45 pad pull (PAD_PU_PD_EN2 bits [27:26]) */ volatile uint32_t *p = (volatile uint32_t *)0x45001078; *p &= ~(0x3U << 26); この後、パッド上のマルチメーターは正確にVbat × 10 / 253（抵抗器の許容誤差の範囲内で約2%以内）を示すため、分圧器自体とパッドバイアスは正常であることがわかります。 3. 設定/常時表示の仕切り 診断目的のため、分圧器は（MOSFETを介してスイッチングされるのではなく）常時電源供給されているため、安定化の問題は発生しません。各ADCサンプリングの前に、マルチメーターを使用してパッド電圧が安定していることを確認します。 測定時のレジスタの状態を確認済み GAU_GPADC0 (0x40038000): ADC_REG_ANA [0x40038010] = 0x0000A810 → INBUF_EN=0, VREF_SEL=01 (1.2 V), INBUF_GAIN=01, INBUF_CHOP_EN=1, ADC_CHOP_EN=1, RES_SEL=00 (12-bit) ADC_REG_CONFIG [0x40038014] = 0x00000000 MCI_IO_MUX (0x40004000): GPIO_GRP0 [0x40004030] = 0x001C1C02 GPIO_GRP1 [0x40004034] = 0x201EDBD8 SOCCIU PAD_PU_PD_EN2: [0x45001078] = 0x01152400 → GPIO_45 PU/PD bits = 00 (no pull) 投稿前に試したこと 以下のすべての組み合わせは、分圧器に常時電源を供給した状態でテストされ、マルチメーターによってアナログ入力が定常状態の期待値であることを確認しました。 ノブの値を試した結果、RAWに及ぼす影響 VREF_SEL（参照） 1.2 V (01) → 1.8 V (00) RAW値は予想通り約1.2/1.8倍にスケーリングされるが、マルチメーターとの不一致は同じ係数で解消されない。 INBUF_GAIN（ゲイン） ゲイン=1 (01)、ゲイン=0.5 (00)、ゲイン=2 (10) 効果なし— INBUF_EN=0 の場合、INBUF_GAIN は何も作用しないことを示唆しています。 バイパス_ウォームアップ / ウォームアップ時間 0（バイパス）～最大32サイクル RAWには測定可能な影響なし ADC_CHOP_EN および INBUF_CHOP_EN 両方ともオン、両方ともオフ 無効 Zephyr .calibrate 真／偽 無効   残りの問題 上記すべてが正しそうに見えても、RAWは入力電圧を適切に追跡しません。測定シーケンス（Vbatは安定したベンチ電源から供給され、各ポイントでマルチメーターにより分圧器が検証されている）： Vbat (V) パッド（マルチメーター、mV） パッドの期待値 = Vbat·10/253 (mV) adc_read() からのRAWデータ 22 848 869 1682 24 928 949 1708 26 1007 1028 2413 28 1084 1107 1745 29 1122 1146 1860 マルチメーターの列は単調であり、除算理論と約2%以内の誤差で一致する。 RAW列は単調増加ではない（26Vで2413まで上昇し、その後28Vで1745まで低下する）。 2413の外れ値を無視しても、22Vと28Vの間のΔRAWは、パッドで+236mVの場合、わずか+63LSBです。Vref = 1.2 V、12ビットの場合、予想されるΔRAW ≈ 805 LSB。つまり、見かけ上の利得は理論値の約0.08倍ということになるが、これは明らかに間違っている。 以前の個々の設定値での測定値では、Vbat ≈ 25 V (マルチメーターパッド ≈ 990 mV) で RAW ≈ 2415 という値が得られており、これは設定値の 1.2 V ではなく、実効 Vref ≈ 1.68 V であることを示唆しているが、これも説明がつかない。   私の質問 GAU GPADCのシングルエンド入力パスには、INBUF_EN = 0の場合、INBUF_GAINの値に関係なく常にアクティブになるフロントエンド アッテネータまたは固定ゲインはありますか？私が確認した比率（約0.6～0.7倍）は、VREF_SELとINBUF_GAINとは無関係です。 INBUF_EN = 0（直接サンプリング）は、RW612のシングルエンド測定において実際にサポート／特性化されたモードなのでしょうか、それとも差動モードでのみ有効なのでしょうか？リファレンスマニュアルでは、入力バッファは通常有効にしておくべきだと示唆されているが、有効にするとバイアス電流のために高インピーダンスのソースが使用できなくなる。 シングルエンド直接サンプリングモードにおけるADC0_CH3の推奨最大ソースインピーダンスはどれくらいですか？9.6 kΩのテブナンインピーダンスは許容範囲内でしょうか、それとも外部バッファが必要でしょうか？ GPIO_45は「特別な」チャネルですか（外部参照用のEXT_VREFも伝送できます）？VREF_SEL = 01（内部1.2V）の場合でもEXT_VREFアナログパスは接続されたままで、入力に負荷をかけている可能性がありますか？ 高インピーダンス・低周波DC入力に対応するGAU GPADCに、既知の不具合やチョッパー関連のアーティファクトはありますか？ よろしくお願いします！ Re: RW612 GAU GPADC0 — inconsistent / non-monotonic readings on a high-impedance source こんにちは、 @_arthur_ さん。お元気でお過ごしでしょうか。 これらのテストはどのZephyrバージョンで実施されたか、確認させていただけますでしょうか？Zephyrのバージョンに関してですが、弊社のダウンストリームリポジトリにZephyr 4.4.0がリリースされました。お客様が観察されている現象は、このバージョンでも発生するかどうかご確認いただけますでしょうか？ さらに、これらのテストはカスタムアプリケーションで実施しましたか？それとも、リポジトリの例から引用したものでしょうか？

Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board I am trying to interface HDMI to CSI2 convertor module from waveshare based on Toshiba IC TC358743. I am using yocto project to build image $ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-frdm source imx-setup-release.sh -b frdm_sources_whinlatter and i have selected the driver using this command bitbake -c menuconfig /virtual/kernel and it is reflecting in the .config file also CONFIG_VIDEO_TC358743=y CONFIG_VIDEO_TC358743_CEC=y and i have modified the dts file accordingly here i am attaching the dts file for your reference. But i couldnt able to communicate with the IC even for i2cdetect -y 1 it is not locking (UU) to 0x0F address. but i can able to see the device address in i2c1. What i am missing in dts file or in driver selection? Linux Multimedia Yocto Project Re: Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board we don't have official verified code for this, the link I sent to you shared the dts settings, you can compare with your own, to check if you miss something Re: Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board Getting page not found error for the solution mentioned in this query. Is there any official support page to resolve this query? Re: Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board pls refer to the link as below, to check if you set correctly or not https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-%E7%A7%BB%E6%A4%8Dtc358743%E5%88%86%E8%BE%A8%E7%8E%87%E8%B0%83%E6%95%B4%E9%97%AE%E9%A2%98/m-p/1631189 Re: Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board This Issue is resolved but i am facing one more regarding video pipeline from CSI2 to HDMI using Gstremer, i couldnt able to understand whether its the dts issue or something else. here i am attaching response log from the device for your reference. and the dts file, root@imx8mp-lpddr4-frdm:~# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- UU 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@imx8mp-lpddr4-frdm:~# v4l2-ctl --list-devices (): /dev/v4l-subdev0 FSL Capture Media Device (platform:32c00000.bus:camera): /dev/media0 mxc-isi_v1 (platform:32e00000.isi:cap_devic): /dev/video3 mxc-isi-m2m_v1 (platform:32e00000.isi:m2m_devic): /dev/video2 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@imx8mp-lpddr4-frdm:~# v4l2-ctl -d /dev/v4l-subdev1 --query-dv-timings Active width: 1280 Active height: 720 Total width: 1650 Total height: 750 Frame format: progressive Polarities: -vsync -hsync Pixelclock: 74250000 Hz (60.00 frames per second) Horizontal frontporch: 0 Horizontal sync: 370 Horizontal backporch: 0 Vertical frontporch: 0 Vertical sync: 30 Vertical backporch: 0 Standards: Flags: root@imx8mp-lpddr4-frdm:~# v4l2-ctl -d /dev/v4l-subdev1 --set-dv-bt-timings query BT timings set root@imx8mp-lpddr4-frdm:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info platform:32c00000.bus:camera hw revision 0x0 driver version 6.18.2 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 pad0: SINK <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: SINK pad2: SINK pad3: SINK pad4: SINK pad5: SINK pad6: SINK pad7: SINK pad8: SINK pad9: SINK pad10: SINK pad11: SINK pad12: SOURCE -> "mxc_isi.0.capture":0 [ENABLED] pad13: SOURCE pad14: SOURCE pad15: SINK - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: SINK <- "tc358743 1-000f":0 [ENABLED,IMMUTABLE] pad1: SINK pad2: SINK pad3: SINK pad4: SOURCE -> "mxc_isi.0":0 [ENABLED] pad5: SOURCE pad6: SOURCE pad7: SOURCE - entity 31: tc358743 1-000f (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SOURCE [stream:0 fmt:RGB888_1X24/1280x720 field:none colorspace:srgb] [dv.caps:BT.656/1120 min:640x350@13000000 max:1920x1200@165000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced- blanking,custom] [dv.detect:BT.656/1120 1280x720p60 (1650x750) stds: flags:] [dv.current:BT.656/1120 1280x720p60 (1650x750) stds: flags:] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@imx8mp-lpddr4-frdm:~# gst-launch-1.0 v4l2src device=/dev/video3 num-buffers=10 ! \ > video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1 ! \ > fakesink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory. Additional debug info: /usr/src/debug/gstreamer1.0-plugins-good/1.26.6.imx/sys/v4l2/gstv4l2src.c(957): gst_v4l2src_decide_allocation (): /GstPipeline:pipel ine0/GstV4l2Src:v4l2src0: Buffer pool activation failed Execution ended after 0:00:00.025120625 Setting pipeline to NULL ... ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: /usr/src/debug/gstreamer1.0/1.26.6.imx/libs/gst/base/gstbasesrc.c(3187): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l 2src0: streaming stopped, reason not-negotiated (-4) Freeing pipeline ... and i am not seeing anything on external display also (Connected over HDMI) Re: Iterfacing HDMI-CSI convertor module TC358743 with i.MX8MP- FRDM board pls refer to the chapter 7.3.9 Camera preview of linux user guide, you need to use media-ctl to create a connection https://www.nxp.com/docs/en/user-guide/UG10163.pdf

PN7462 GPIO出力読み取りの問題（phhalPcr_GetGpioVal()使用時） チームの皆さん、こんにちは。 私はPN7462を使用しており、phhalPcr_GetGpioVal()を使用して出力として構成されたLED GPIOピンを読み取ろうとしています。 uint8_t val = 0; phhalPcr_GetGpioVal(LED_RED, &val); しかし、LED出力がHIGHの場合でも、APIは常に0を返します。 phhalPcr_GetGpioVal() は入力パッドの状態を読み取るだけの関数ですか？ PN7462の出力GPIOピンの状態や出力ラッチ値を読み取るための他のAPIはありますか？ よろしくお願いいたします。 開発ボード Re: PN7462 GPIO Output Read Issue Using phhalPcr_GetGpioVal() こんにちは、 @uday_gowda さん PN7642_MCUXpresso_SDK_02-15-006_PUB\boards\pnev7642fama\driver_examples\gpt の例を参照してください。そこにあなたが求めている答えがあります。 Re: PN7462 GPIO Output Read Issue Using phhalPcr_GetGpioVal() 参考資料をありがとうございます。 私はSDK NxpNfcRdLib_PN7462_v07.14.00_Pubを使用してPN7462AUを使用しています。 提示されたサンプル領域を確認しましたが、そこにもLEDに対するGPIO書き込み操作しかなく、GPIO出力読み出し操作は見当たりませんでした。 PN7462の出力GPIOの状態を読み取るためのAPIが存在するかどうか確認していただけますか？ Re: PN7462 GPIO Output Read Issue Using phhalPcr_GetGpioVal() こんにちは、 @uday_gowda さん 次のような方法を試してみてはいかがでしょうか。

RDDRONE-BMS772开发板 我想知道如果利用这个板子进行电池的测试实验时，能不能设计电池的充放电工况，比如恒流恒压充电或者HPPC、UDDS等动态工况。 Re: RDDRONE-BMS772开发板 那个是charger里面检测设置的不是BMS这边的功能

MCXW236BIHNARチップ電源設計 こんにちは、NXPさん。 MCXW236BIHNARの電源設計回路図を添付しました。設計が適切で、チップが正常に動作するのに十分かどうか、ご確認いただけますでしょうか？ よろしくお願いします、 シャキール・サラム ボード設計

バカラで本当に勝者は多いのでしょうか？カスタマーサービス（15708835568）までお問い合わせください。

AI音声認識とオンデバイスLLMは、組み込みシステムにおける次の大きな変革となるのか？ 近年のデバイス内AIやリアルタイム音声インターフェースへの取り組みの高まりにより、私たちは生成型AIの新たな段階、つまりクラウドへの依存度が低く、エッジネイティブな段階に入りつつあるように感じられます。 最近私が気づいたいくつかの傾向： デバイス内LLM（プライバシー保護と低レイテンシ）への需要の高まり AI音声エージェントの台頭により、従来のUIフローが置き換えられつつある。 組み込みハードウェア向け効率的なモデル最適化（量子化、蒸留）への注力 インダストリアルおよびオートモーティブ用途向けのオフライン対応AIシステムへの関心の高まり これは興味深い疑問を提起する。 👉 私たちは、APIに頼るのではなく、すべてのデバイスが独自の「ローカルAIブレイン」を持つ未来に向かっているのだろうか？ 開発の観点から見ると、この変化は些細なことではない。これには以下が含まれます。 パフォーマンスを損なうことなくモデルを圧縮する ハードウェアを考慮したAIアーキテクチャ設計 エッジとクラウドのインテリジェンスのシームレスな統合 私は生成型AI開発サービス、特に実世界での展開（デモだけでなく）に最適化されたカスタムAIモデルの構築に深く携わってきましたが、私が考える最大の課題はモデルを構築することではなく、それを本番環境で使いやすく、効率的で、拡張性のあるものにすることです。 このコミュニティの皆さんの意見を聞きたいです。 デバイス上のLLMやエッジAIを試していますか？ これまでで最大のボトルネックは何でしたか？パフォーマンス、コスト、それともシステム統合でしょうか？ クラウドベースのGenAIが今後も主流であり続けると思いますか、それともエッジコンピューティングが取って代わると思いますか？ ぜひ意見交換や実体験を共有したいです。

IPTVGreatが2026年最高のIPTVである理由とは？ 2026年最高のIPTVをお探しですか？IPTVGreatは、14万以上のライブTVチャネルと10万以上の映画やシリーズを素晴らしい4K品質で提供するプレミアムな選択肢として際立っています。7年以上にわたる信頼の実績を持つこの製品は、高度なフリーズ防止技術によって、スムーズでバッファリングのないストリーミング体験を提供します。 ライブスポーツやPPVイベントから、Netflixスタイルの番組、70カ国以上からの国際チャンネルまで、IPTVGreatは手頃な価格のサブスクリプションで全てを提供します。スマートテレビ、Android、iOS、Firestick、PCなど、あらゆるデバイスで動作します。 信頼性、豊富なコンテンツ、そして最高のパフォーマンスを求めるなら、IPTVGreatは2026年のベストIPTVの有力候補です。 アクセス先： https://iptvgreat.store/ Re: Why is IPTVGreat the Best IPTV 2026? IPTVGreatは、 14万以上のライブチャネル、 10万以上の4K映画とシリーズ、そして7年以上の信頼できるサービスを提供し、 2026年のベストIPTVとして有力な選択肢です。凍結防止テクノロジにより、スマートテレビ、Firestick、Android、iOS、PCなど、あらゆるデバイスでスムーズでバッファリングのないストリーミングを実現します。スポーツ、映画、そして世界のエンターテイメントを一つのサブスクリプションで楽しめる、確かな選択肢です。 👉 IPTVGreat をご覧ください Re: Why is IPTVGreat the Best IPTV 2026? 🚀 2026年最高のIPTVをお探しですか？IPTVGreatは、14万以上のライブTVチャンネル、10万以上の映画やシリーズ、そしてパワフルな4K画質で、素晴らしいストリーミング体験を提供します。ライブスポーツやPPVイベントから国際的なエンターテイメントまで、すべてが手頃な価格のIPTVサブスクリプションで利用可能です。 バッファリングが一切なく、あらゆるデバイスにサポートしているIPTVGreatは、世界中のIPTVユーザーにとって人気の選択肢になりつつあります。 🔥📺 🌐 アクセス先： https://iptvgreat.store/ Re: Why is IPTVGreat the Best IPTV 2026? 🔥 IPTVGreatは、2026年のベストIPTVの有力候補の一つであることは間違いありません！14万以上のライブチャネル、10万以上の映画やシリーズ、そして非常にスムーズな4Kストリーミングを備えたこのサービスは、世界中のスポーツファンやエンターテイメント愛好家にとって最適な選択肢です。 ⚽📺 バッファリングが全く発生しないパフォーマンスと膨大な国際コンテンツライブラリにより、IPTVGreatは他のIPTVプロバイダーとは一線を画しています。2026年にプレミアムIPTVサービスを探している人にとって、間違いなくチェックする価値のあるサービスです。 🌐 今すぐアクセス： https://iptvgreat.store/

ライノス - 発売日は？ こんにちは、Yoctoの新しいリリースが間もなく登場しますが、wrynoseをサポートするmeta-qoriq BSPはいつ頃リリースされる予定ですか？コードベースを凍結する前に、新しいリリースに切り替えられるかどうかを計画する必要があります。 Re: Wrynose - relase date? こんにちは、 NXPは 現在、 yocto - sdk マニフェスト での meta-qoriqの 使用 を含め 、 Layerscape/QorIQ ワークフロー 向けの Kirkstone 、 Mickledore 、 Scarthgap などの リリース を 文書化/サポートしています 。 NXPは 、 一部 のコンポーネントの アップグレード に関して 、 リリース 予定日 が 確定し た 際に、 その 旨 を 公表すること があり ます 。例えば 、 meta-qoriq の ATF アップデートは 6.12.20-2.0.0-25Q2 に 予定されて いる と 記載され ています 。 したがって、 計画 に関する 回答 は 、 meta-qoriq BSP の Wrynose サポート に関する 検証済みの 公開 スケジュール は あり ませ ん 。コード凍結の 決定が その サポート の 実装 に 依存する 場合 、 入手可能な ドキュメント では 、 それが 予定通り に 利用可能 に なる と想定すること は でき ません。 よろしくお願いします。   よろしくお願いします。

ThriveCartクーポンコード（44%オフ）$550生涯割引 Thrivecartの割引で44%オフをゲットしよう ThriveCartの 購入をお得にするため の有効なクーポンコードをお探しですか ？まさにぴったりの場所です。ThriveCartは、 生涯利用権 を提供する数少ないSaaSツールの1つです。 つまり、一度購入すれば、月額料金なしで永久に利用できます。 ThriveCart Proの永久ライセンスが75%オフ！ ThriveCart Proプランが75%オフ！しかも永久アクセス権付き。他のプラットフォームで月額料金を払い続けるよりも、このお得なプランなら初期費用を大幅に節約できます。アフィリエイトトラッキング、アップセル、バンプオファー、カスタムチェックアウトページといった高度な機能を、月額料金なしで永久にご利用いただけます。 ThriveCartの500ドル割引プロモーションコード 新規ユーザーは、このオファーを利用することで、ThriveCartのスタンダードパッケージを500ドル割引で利用できます。このプランでは、モバイルフレンドリーなペイメント機能や30種類以上のペイメントシステムとの連携機能を維持しつつ、初期費用を大幅に削減できます。 ThriveCartの50%オフクーポンコード（プロアカウント限定） ThriveCart Proアカウントを50%割引で入手し、月額料金なしで生涯アクセス権を一度支払うだけで、無制限の商品、無制限の取引、ワンクリックアップセル、オーダーバンプ、アフィリエイトトラッキング、詳細な売上レポートなどの強力な機能を利用できます。年間料金を請求するプラットフォームと比較して、数百ドルも節約できます。 ThriveCart生涯クーポンコード（プロプラン）（690ドル節約） ThriveCartの生涯クーポンコードを使ってProプランを契約すると、690ドル節約でき、Standardプランのすべての機能に加え、本格的な販売者向けの高度なツールも利用できます。これには、アフィリエイト管理、購読者維持機能、高度な自動化機能、顧客ポータル、そしてコースのホスティングと販売のためのThriveCart Learn+へのフルアクセスが含まれます。これらすべては、一度限りのペイメントで済み、継続的な費用は一切かかりません。これにより、コンバージョン率を高め、プラットフォームのコストを削減し、より多くの利益を確保できます。 ThriveCartプロモーションコード - 495ドル割引 ThriveCartのプロモーションコード（495ドル割引） を利用すれば 、スタンダードプランを1回限りの支払いで入手でき、月額料金が永久に無料になります。このプランには、無制限の商品、販売ファネル、チェックアウトページ、そして生涯無料のアップデートが含まれており、オンライン販売者は通常の価格のほんの一部でフル機能を利用でき、継続的な費用をかけずにビジネスを成長させることができます。 ThriveCartのブラックフライデークーポンで250ドル割引 ThriveCartのブラックフライデー・フラッシュセール期間中は、250ドルの割引が適用され、生涯で最もお得な価格で購入できます。この期間限定のキャンペーンは、メールや提携サイトを通じてよく宣伝されており、販売者は強力な販売ツールへの生涯アクセス権を、継続的な料金なしで取得できます。 ThriveCart ブラックフライデー クーポンコード - 60%オフ ThriveCartのブラックフライデーセール2025期間中は、スタンダードプランとプロプランの両方で最大60%オフとなり、生涯有効な一括ペイメントで、強力なチェックアウトツール、高度なオートメーション、無制限の製品登録、そして販売、定期購入、アフィリエイトマネジメントのすべてに、月額料金なしでアクセスできます。 ThriveCartの30日間無料トライアルオファー ThriveCartは無料トライアルを提供していませんが、30日間の返金保証により、すべての機能をリスクなしで試すことができます。さらに現在、90%オフの割引クーポンを利用すれば、Proプランを最大450ドル節約でき、月額料金なしで生涯フルアクセスが可能になります。 ThriveCart生涯利用プラン – 2026年までのお得な割引（継続料金は一切かかりません） これは、 ThriveCartのクーポンコードの中でも最高の特典です。ThriveCartの永久アクセス権が手に入ります。一度支払えば、ThriveCart Standardを永久に利用できます。月額料金、年間更新料、決済手数料以外の取引ごとの手数料は一切かかりません。 価格設定： ThriveCart スタンダード生涯プラン： 495ドル（一括払い） ThriveCart Pro ライフタイムライセンス（Proアップグレード付き）： 690ドル（一括払い） このサービスがお得な理由：同等の機能を備えたSaaS型ショッピングカートツール（SamCart、CartFlows Pro、WooCommerce＋拡張機能など）は、年間588ドル～1,188ドルのサブスクリプション料金がかかります。ThriveCartの生涯価格は、3年間で同等のサブスクリプションと比較して1,200ドル～3,000ドル以上節約できます。 ThriveCart Proアップグレードクーポン – フルProバンドルがお得に ThriveCart Proへのアップグレードでは、Standard版に加えて、アフィリエイト管理、クライアント利用権限、売上税の自動計算、インテリジェントな事業予測、カスタムドメインサポートなど、強力な機能が追加されます。Proへのアップグレードは、Standard版の永久ライセンス価格に195ドルを追加することでご利用いただけます。 ThriveCart Proの合計価格：690ドル（一括払い）（スタンダード版495ドル＋プロ版195ドル） サブスクリプション型サービスとの比較： ThriveCart Pro（月額690ドル）は、アフィリエイトシステムを備えた同等のサブスクリプション型カートツールと比較して、5年間で2,250ドル～5,250ドルの節約になります。 ThriveCart Learn+ クーポン – コースプラットフォームが無料 ThriveCartには、StandardおよびProの永久ライセンスすべてにThriveCart Learn （フル機能のLMS/コースプラットフォーム）が無料で付属しており、 ThriveCart ProにはThriveCart Learn+ （段階的なコンテンツ配信、コース修了証明書、高度な学生管理などの高度なコース機能）が無料で付属しています。 これにより、実質的にTeachableやKajabiの代替サービスを無料で利用でき、ThriveCartの1回限りの支払いに含まれています。 Learn+の価値：同等のコースプラットフォームは月額39ドル～199ドルです。ThriveCartの生涯契約にLearn+をバンドルすることで、年間500ドル～2,400ドル相当の価値が加わります。 アフィリエイトパートナー経由のThriveCart割引 – 検証済みのボーナス特典 ThriveCartは、従来の割引クーポンコードは提供していません。その代わりに、一部の提携パートナーが、標準の生涯利用料金に加えて、 ThriveCart限定の割引ボーナスを提供しています。これらのボーナスには通常、すぐに使えるファネルテンプレート、マスタークラスへのアクセス、または200ドルから1,000ドル相当の個別オンボーディングコールなどが含まれます。 【期限切れ】ThriveCart ブラックフライデー 2025 – ボーナスバンドルオファー ThriveCartの2025年ブラックフライデーキャンペーンでは、新規の生涯購入者向けに、追加テンプレート、トレーニング、延長サポートアクセスなどの限定ボーナスバンドルが提供されました。標準価格である495ドル／690ドルの生涯利用料は変更ありませんが、ボーナスパッケージは提供されなくなりました。2026年のプレビューについては、下記の季節限定セールセクションをご覧ください。 ThriveCartのクーポンコードを入手する方法は？ ThriveCartの割引 を適用して 購入を完了するには、以下の5つの手順に従ってください。 ステップ1：上記で選択した特典の横にある「今すぐ申し込む」ボタンをクリックしてください。これにより、ThriveCartの公式チェックアウトページ、または提携パートナーのチェックアウトページが開きます。このページには、セッションに関連付けられた利用可能なボーナス特典が表示されます。 ステップ2：プランを選択してください。スタンダードプランかプロプランのどちらかです。ThriveCartのチェックアウトページで、スタンダードの永久ライセンス（495ドル）を選択するか、プロプランへのアップグレード（195ドル追加）を選択して、合計690ドルのプロプランバンドルをご利用ください。アフィリエイトマネジメントシステムを使用する場合や、売上税の自動計算が必要な場合は、プロプランへの追加投資に見合う価値があります。 ステップ3：ボーナス特典を確認してください。アフィリエイトパートナーのリンクから購入された場合、関連するボーナスパッケージは購入確認メールに記載されています。チェックアウト後にボーナスを受け取るための手順をご確認ください。 ステップ4：お支払い情報を入力してください。ThriveCartではクレジットカードとPayPalをご利用いただけます。定期的な請求はなく、お支払いは1回限りです。取引を完了する前に、合計金額（495ドルまたは690ドル）が正しいことをご確認ください。 ステップ5：ThriveCartアカウントにアクセスします。購入後数分以内に、ログイン手順が記載されたウェルカムメールが届きます。ThriveCartダッシュボードはすぐに利用可能になります。決済処理業者（Stripe、PayPal、またはApple Pay）を接続し、最初の製品を登録して販売を開始しましょう。 プロからのアドバイス： ThriveCartには無料トライアルはありません。プラットフォームには30日間の返金保証があり、これはリスクなしで評価できる期間として機能します。この期間を利用して、チェックアウトページを完全に設定し、支払いフローをテストし、保証期間が終了する前にThriveCartがビジネスに適していることを確認してください。 2026年におけるThriveCartの料金はいくらですか？ 詳細価格比較：ThriveCartとサブスクリプション代替サービス プラットフォーム ThriveCart スタンダード ThriveCart Pro SamCart（スケール） CartFlows Pro カジャビ 価格設定モデル 1回限りの料金495ドル 1回限りの料金690ドル 年間588ドル 年間299ドル 年間1,188ドル 1年目の費用 495ドル 690ドル 588ドル 299ドル 1,188ドル 3年目の費用（合計） 495ドル 690ドル 1,764ドル 897ドル 3,564ドル 5年目の費用（合計） 495ドル 690ドル 2,940ドル 1,495ドル 5,940ドル 生涯節約額 vs SamCart — — 2,445ドル節約できました — — アフィリエイト管理 ✓（プロ） ✓ ✓（スケール） ✗ ✓ コースプラットフォーム ✓ 無料（学習） ✓ 無料（Learn+） ✗ ✗ ✓ 一括ペイメント ✓ ✓ ✗ ✗ ✗ 価格は2026年の料金を反映しています。サブスクリプションプラットフォームの料金は年間請求料金です。 ThriveCart StandardとPro - どちらを選ぶべきか？ ThriveCart Standard（495ドルの一括払い）は、チームアフィリエイトプログラムなしでデジタル製品、物理製品、サービス、またはサブスクリプションを販売する個人クリエイターや小規模ビジネスオーナーに最適な選択肢です。無制限の製品、無制限のファネル、A/Bスプリットテスト、ワンクリックアップセル、オーダーバンプ、埋め込み可能なチェックアウト、StripeとPayPalの統合、そしてThriveCart Learn（組み込みのコースプラットフォーム）が含まれています。 ThriveCart Pro（一括払い690ドル - 495ドル + 195ドルのアップグレード）は、以下のような機能が必要な場合に最適な選択肢です。自社製品を宣伝するアフィリエイトを募集・管理するための組み込みアフィリエイトプログラム、自動売上税計算（Taxjarとの連携）、クライアント使用権限（クライアントのビジネスでThriveCartを実行）、インテリジェントなビジネス予測と収益予測、そして、段階的なスケジュール設定、修了証、高度な学生進捗状況追跡などの高度なコース機能を備えたThriveCart Learn+。 結論：ビジネスのどの段階であれアフィリエイトプログラムを構築する予定があるなら、最初からProプランを選ぶべきです。195ドルの追加料金は十分に正当化されます。TapfiliateやRewardfulのような単体のアフィリエイト管理プラットフォームは月額59ドルから199ドルかかるため、Proプランへのアップグレード費用は、別途ツールを用意する必要がなくなることで30日以内に元が取れます。 ThriveCartは学生割引や非営利団体割引を提供していますか？ ThriveCartは、正式な学生割引プログラムや非営利団体向けの料金プランを提供していません。しかし、ThriveCartでの購入にかかる実質的なコストを削減する方法はいくつかあります。 生涯契約が実質的な割引： ThriveCartが提供する最大の割引は、495ドルの1回限りの価格設定そのものです。初めてデジタル製品ビジネスや副収入源を構築しようとしている学生にとって、月額料金がかからないということは、ThriveCartが最初の数件の販売が行われた瞬間から手頃な価格になることを意味します。これは、収益に関係なく月額49ドルから99ドルを請求するサブスクリプションプラットフォームとは異なります。 アフィリエイトパートナー特典：認証済みのアフィリエイトパートナー（このページにあるリンクなど）経由で購入すると、テンプレート、トレーニング、コンサルティングなど、200ドルから1,000ドル相当のボーナスパッケージが手に入ることがよくあります。これにより、定価を下げることなく追加価値が提供されるため、実質的なコストを削減できます。 事業経費／税控除：ほとんどの国では、ThriveCartは事業用ソフトウェア経費として認められ、全額税控除の対象となります。自営業のクリエイターや小規模事業主の場合、495ドルのThriveCartライセンスの税引き後費用は、所得税率に応じて300ドルから375ドルになることが多く、学生だけでなく誰にとっても大きな実質的な割引となります。 ThriveCart クーポンコード インド: ThriveCart は世界共通で USD で $495/$690 で販売されています。ThriveCart を購入するインドのユーザーは、このプラットフォームが国際クレジットカード/デビットカードと PayPal に対応していることに注意してください。どちらもインドの銀行で広く利用可能です。為替レートの変動により、USD での定期購読が高額になる可能性があるため、この一括払いモデルはインドの起業家にとって特に有利です。$495 の一括払いにより、将来の USD/INR の変動に関係なく、費用が永久に固定されます。 ThriveCartとは何ですか？2026年時点で、それは価値のあることだろうか？ ThriveCartは、デジタル製品クリエイター、コース販売者、コーチ、コンサルタント、オンラインビジネスオーナー向けに特化して構築された、ホスティング型のショッピングカートおよび決済プラットフォームです。ジョシュ・バートレットによって設立され、2016年にサービスを開始したThriveCartは、5万社以上のオンライン販売業者をユーザーベースとして、年間数億ドル規模の売上を処理している。 ShopifyやWooCommerceといった一般的なeコマースプラットフォームは主に実店舗での商品リテール向けに構築されていますが、ThriveCartはコンバージョン率の高いデジタル商品のチェックアウトに特化して設計されています。ワンクリックアップセル、注文特典、定期購入マネジメント、アフィリエイトトラッキング、そしてあらゆるウェブサイト、ランディングページ、ファネルに直接埋め込めるチェックアウトフォームなど、多彩な機能を備えています。 ThriveCartの主な機能は以下のとおりです。 商品数と販売ファネル数は無制限で、決済処理業者の標準料金以外に販売ごとの取引手数料は一切かかりません。決済ページ、見出し、価格設定に関するA/Bテスト。ワンクリックでアップセルとダウンセルが可能。平均注文額を増加させる注文特典。購読およびペイメントプランのマネジメント（督促（自動的なペイメント不履行回収）を含む）。ActiveCampaign、ConvertKit、Drip、Mailchimp、Zapier、Teachable、Thinkific、WordPressなど、30以上のツールと直接連携できます。さらに、ThriveCart Learnコースプラットフォームが内蔵されており、追加費用なしでフル機能のLMS（学習管理システム）を利用できます。 ThriveCartは以下のような方に最適です。 ThriveCartは、コース、電子書籍、会員制サービス、テンプレート、ソフトウェア、コーチングプログラム、代行サービスなどを販売するデジタル製品クリエイターにとって最適なプラットフォームです。これは、毎月のSaaS料金の支払いにうんざりしていて、カートのインフラストラクチャを完全に所有したいと考えているクリエイターに特に適しています。ThriveCart Proのアフィリエイト管理システムは、製品ローンチとパートナー主導の販売のためのワンストップソリューションを提供します。 ThriveCartの欠点： ThriveCartは、大型の物理製品のeコマースには最適ではありません。在庫管理、配送連携、複数SKUの小売においては、Shopifyの方が優れたツールです。ThriveCartのダッシュボードデザインは機能的ではあるものの、SamCartのような新しい競合製品と比べると、視覚的な洗練度は劣る。また、無料トライアルがないため、新規ユーザーは30日間の返金期間を利用して自分に合うかどうかを判断しなければなりません。これは寛大な措置ではありますが、無料プランを提供しているプラットフォームと比べると、わずかながら不便さを感じる点です。 2026年になっても、それだけの価値はあるのだろうか？ 12か月以上オンラインで販売を計画しているデジタル製品クリエイターにとって、495ドル～690ドルの買い切り価格のThriveCartは、SamCart（年間588ドル以上）、Kajabi（年間1,188ドル以上）、あるいはカート、アフィリエイトシステム、コースプラットフォームを個別に構築した場合の合計コストと比較すると、ほぼ間違いなく価値があります。計算は簡単です。同等の機能を備えたサブスクリプション型の代替サービスと比較すると、生涯契約は初年度で元が取れます。ThriveCartの生涯クーポンを現在の価格で入手すれば、将来の値上げから永久に保護されます。 結論：ThriveCartのお得なクーポンコードを入手しよう（2026年版） 現在入手可能なThriveCartの最もお得なクーポンコードは、生涯アクセス権のプランです。スタンダードプランは495ドル、プロプランは690ドルで、月額料金は一切かかりません。デジタル製品クリエイター、コース販売者、オンラインビジネスオーナーにとって、これは2026年に利用できる最も経済的に健全な決済プラットフォームへの投資と言えるでしょう。 ThriveCartと同等の機能を備えたサブスクリプションツールで、3～5年の期間で見てこれより低価格なものはありません。組み込みのアフィリエイトシステム（Pro）、無料コースプラットフォーム（Learn+）、そして取引手数料無料のモデルにより、あらゆる規模のビジネスにおいて魅力的な収益性を実現しています。 初めてのデジタル商品のためのフル機能搭載カートが必要な場合でも、既に確立されたビジネスのための強力なアフィリエイトプラットフォームが必要な場合でも、 ThriveCartの生涯利用プランは、毎月の購読料が一切発生しないため、毎月お得に利用できる割引です。価格が変更される前に、上の「生涯利用権を申し込む」ボタンをクリックして、2026年の価格を確定しましょう。 ThriveCartクーポンコードに関するよくある質問 ThriveCartの495ドルの価格から割引を受けられるクーポンコードはありますか？ ThriveCartは、月額制SaaSプラットフォームのように割引率を示すクーポンコードを一般に公開していません。ThriveCart の割引は 、生涯利用料金（Standardプランは495ドル、Proプランは690ドル）そのものによって実現されており、これはサブスクリプション方式の代替サービスと比較して永続的な節約となります。一部のアフィリエイトパートナーは、標準価格に加えてボーナスパッケージ（テンプレート、トレーニング、コンサルティングなど）を提供しており、定価を下げることなく付加価値を高めています。これらのボーナス特典は、 従来の意味での ThriveCartクーポン に最も近いものと言えるでしょう。 ThriveCartは無料トライアルを提供していますか？ いいえ。ThriveCartは無料トライアルを提供していません。その代わりに、すべての購入に対して30日間の返金保証が付いています。購入後30日以内に何らかの理由でご満足いただけない場合は、理由を問わず全額返金を請求できます。つまり、購入のリスクは30日間の無料トライアルと同等ですが、支払い情報を事前に入力する必要がある点が異なります。返金手続きを開始するには、購入後30日以内にThriveCartサポートにお問い合わせください。 ThriveCart StandardとThriveCart Proの違いは何ですか？ ThriveCart Standard（495ドルの一括払い）には、デジタル製品、サブスクリプション、物理製品をオンラインで販売するために必要な機能がすべて含まれています。製品数無制限、ファネル、A/Bテスト、アップセル、オーダーバンプ、ThriveCart Learnなどが利用できます。ThriveCart Pro （690ドルの一括払い、Standardに195ドルのアップグレードを追加）には、組み込みのアフィリエイト管理システム、売上税の自動計算、クライアントの使用権限、インテリジェントな収益予測、高度なコース機能を備えたThriveCart Learn+が追加されます。アフィリエイトプログラムを運営したり、パートナー経由で販売したりする予定がある場合は、Proが最適な選択肢です。195ドルのアップグレードは、スタンドアロンのアフィリエイトプラットフォームと比較して、最初の1か月以内に元が取れます。 ThriveCartの永久ライセンスの価格は値上がりするのでしょうか？ ThriveCartは、495ドルの生涯利用権は永続的なものではなく、いずれはサブスクリプション料金に移行すると複数回公言しています。この変更の時期は発表されておらず、2020年以降何度も延期されていますが、そのリスクは現実のものです。現在のThriveCartクーポンコードの価格は495ドルで、2018年から安定しています。早めに購入すれば、将来の価格変更に関わらず、現在の価格で生涯アクセスを確保できます。 インドでThriveCartは利用できますか？ はい。ThriveCartはインドを含む世界中のユーザーが利用できます。このプラットフォームは、国際クレジットカードおよびデビットカード（Visa、Mastercard）とPayPalに対応しており、いずれもインドの主要銀行のほとんどを通じてインドの購入者が利用できます。ThriveCartは米ドルで請求を行い、495ドル/690ドルの1回限りの支払いは、単一の国際取引として処理されます。インドのデジタル起業家にとって、ThriveCartの1回限りの料金モデルは特に有利です。なぜなら、INR/USD為替レートによって変動する継続的なUSDの購読料が不要になるからです。 ThriveCartは、Razorpayのようなインドの決済ゲートウェイと連携できますか？ ThriveCartは現在、決済処理業者としてStripe、PayPal、Apple Payをサポートしています。RazorpayはThriveCartに決済処理業者として標準で統合されていません。インドの販売者は、ThriveCartを通じてお客様からペイメントを受け取る際に、Stripe India（インドの企業が利用可能）またはPayPalを利用できます。お客様が主にUPIまたはネットバンキングで支払いを行うインドの販売者にとっては、30日間の返金期間中にこれを検討してみる価値があります。

缺少 VISLANDS30_IV_SRCID_SYS_MEM_PROT_FAULT 处理程序函数 你好， ，请查找以下 AMDGPU 中断， #define VISLANDS30_IV_SRCID_SYS_PAGE_INV_FAULT 0x0000008c /* 140 */ #define VISLANDS30_IV_SRCID_SYS_MEM_PROT_FAULT 0x0000008d /* 141 */ #define VISLANDS30_IV_SRCID_SEM_PAGE_INV_FAULT 0x00000090 /* 144 */ #define VISLANDS30_IV_SRCID_SEM_MEM_PROT_FAULT 0x00000091 /* 145 */ #define VISLANDS30_IV_SRCID_GFX_PAGE_INV_FAULT 0x00000092 /* 146 */ #define VISLANDS30_IV_SRCID_GFX_MEM_PROT_FAULT 0x00000093 /* 147 */ 在 i.MX95 上加载 AMDGPU 驱动程序时，我收到了未注册的中断，即 140 和 141，但 AMDGPU 驱动程序不会处理这些中断，而 146 和 147 则会单独处理。 Re: VISLANDS30_IV_SRCID_SYS_MEM_PROT_FAULT Handler function missing 你好 这是因为头文件中的这些中断（140、141）属于系统/互连功能域，而不是 GPU 虚拟机，因为在处理虚拟机故障的驱动程序的 gmc_v8_ 0.c 模块中实现的 146 和 147。

MPC5744P CPU crash under certain conditions, but unknown cause Hello We are implementing an automotive application with the MPC5744P (MAPBGA257 package, 1N15P cut), which is integrated along with a MC33908 SBC. Compiler is S32DS 2.1 , -O1 optimization. We have been able to reproduce this in 3 different product units, so we hope it is not a faulty silicon. This has been the workflow so far: The application development has been uneventful up to now. Adding a certain quantity of code causes, under certain conditions the core to hang completely. - First and foremost, the SBC reset conditions are checked while reproducing the issue: Reset line does not toggle to low, which means that the SBC does not induce a reset due to abnormal function. So, we focus on the MPC core. - The application has been instrumented with TRACE32 (Lauterbach Powerdebug Pro), and once the condition is reached, a DEBUG PORT FAIL condition arises. Using the reset detection capability, we are able to get to the trace information. The application crashes after a function returning a UINT8_T variable with value equal to 1. This translates to assigning 1 to R3, and then SE_BLR.  - IVORs from 0 to 32 are properly instrumented with branch-to-self instructions (except IVOR4 which jumps to the ISR prologue), so no IVOR trap is taking place. - After verifying that the problem can be reproduced in the same address, a breakpoint is set into that address to check system status before the crash. The system halts at the breakpoint. LR register is OK, stack is normal, everything OK.  - Then, single execution steps are taken to reproduce the crash, with no success. The program steps successfully through the normal flow. - But, if at any time, program flow is restored (no more stepping), the application crashes after some milliseconds (!!) - Checking the trace dump again, we see that it is the same function but with different return value. In a different session, it can even be another different function. - Adding a UINT8_T global spy variable to the function, changes the memory address the crash takes place. - Changing a significative amount of code in a totally unrelated place of the application can eliminate that behavior. As you see, it is very unreliable, and we have no clue of where to continue diagnosing this problem. Attaching code would be of little to no use, as the conditions to provoke this error are very particular, and the failure point, as you see, changes depending on unknown factors. PS: Our problem is similar to this: https://community.nxp.com/t5/MPC5xxx/Lauterbach-reports-MPC5602D-is-in-state-running-reset-what-does/td-p/589249 except that we are able to trace the execution up to the failing point. SWT is disabled on startup, by the way. How is it that the CPU does not arrive to an IVORx exception? Re: MPC5744P CPU crash under certain conditions, but unknown cause I recognize this thread is 4 years old...but I seem to be experiencing the same issue described in this thread, but with the MPC5777c device.  We are also using the MC33908 SBC.  With our CPU reset issue, we have been observing the external reset line not toggling low, getting "debug port fail" in TRACE32 when the fault condition occurs, observe a similar instruction set leading to the failure (return a value to function and then SE_BLR), see TRACE32 affecting the reset, etc etc.  The similarities are quite striking.  It looks like the CPU just stops processing. Was a solution to this issue ever discovered? Re: MPC5744P CPU crash under certain conditions, but unknown cause Hello, don't worry,I have opened a support ticked due to inactivity. I hope we can come up with a solution soon because the application is not reliable right now, unless 100% code coverage testing is done after any minor software change (as minor as adding a 1-byte global debug variable). You will understand that this is not a bearable development workflow. Re: MPC5744P CPU crash under certain conditions, but unknown cause I am apologizing for not hearing from me. I am currently out of office due to family reason. Yes, please create a ticket for this if there is no other response. Thanks for understanding. Re: MPC5744P CPU crash under certain conditions, but unknown cause Due to the lack of response, should I open a support ticket? Re: MPC5744P CPU crash under certain conditions, but unknown cause Further information. We have disabled manually DMA transfers and interrupts and provoked synthetically the issue (by manually setting the conditions for that).  The crash still happens, so we can discard DMA and interrupt influence. Also, if we put a hardware breakpoint in the conflicting line (where the crash happens), it breaks, and stepping is OK. But if we put a software breakpoint, the crash still happens (it does not break). Re: MPC5744P CPU crash under certain conditions, but unknown cause In further testing, I have found out that adding a SINGLE global variable to the system eliminates that crashing behavior. What we can't assure at the moment is that the issue doesn't arise in other conditions. I am really puzzled with this issue, and for the lack of answers I guess it's not a very common one. Mostly, the fact that even the Lauterbach Powerdebug Pro system is unable to shed any light on this issue, providing any single bit of information on CPU registers in order to pinpoint the causing event. Re: MPC5744P CPU crash under certain conditions, but unknown cause Hello Do you have any other advice for this issue?  Thank you Re: MPC5744P CPU crash under certain conditions, but unknown cause The problem persists. So far, Flash timing has been adjusted in PFCR1 as per datasheet values. MC_RGM DES and FES registers have been checked out, and no functional/destructive reset takes place. We have been able to create conditions for a 100% reproducible failure. When stepping through the instruction before the crash (using a breakpoint), there is no crash. But if you enter in free-running mode, the system crashes, and checking the trace report, the crash happens in that instruction in which we breaked before. Do you have any other idea we can try? Thank you Re: MPC5744P CPU crash under certain conditions, but unknown cause Thank you for your response. Have you measured RESET signal bu scope? Has MCU been reset? RESET signal has been measured during the reproducible incident that provokes this failure. The RESET signal is always high, so no external RESET takes place. According your description you says debugger affect the behavior in the meaning the fault does no happen. Also basically you said behavior is unpredictable but repeatable. Yes, basically if you break into the exact point that the system hangs, you can step through instructions with success. However, when leaving stepping mode and running continuously, the system hangs into that exact point. Also keep in mind that altering the software (adding variables, adding code) may, or may not, change the point where the system hang takes place. But once changed, this hang is 100% reproducible.  I would at first check you clocking configuration. In the datasheet section 3.16.3 you have defined prescribed number of flash wait states. Check 2.9.1 System clock frequency limitations Also there is several errata that woul be needed top check: ERR010639 ERR010640 ERR011073 https://www.nxp.com/docs/en/errata/MPC5744P_1N65H.pdf https://www.nxp.com/docs/en/errata/MPC5744P_1N15P.pdf The system has been working thousands of hours under different conditions and this condition has never showed up. Certain software revisions provoke this behavior. Which would be the relationship with the clocking configuration and the flash wait states? Just asking, to look into those hypothesis. Regarding the clocking, this issue happens in a known situation long time after power up. The erratas you mention seem to be related to power up, right?  The thing that puzzles me most, is that the system does NOT hang into any known exception handler. The debugger detects the core as halted/off/reset, and there is no visible symptom to this: right before the core hangs, the LR is OK, the Stack Pointer is well behind the stack size.  I also checked the software version against the E200 branch checker software, and it is ok regarding that. Checking out with my colleagues, we have found out that we previously have experienced this in the MPC5744P QFP144 version, years ago. So it is not just to this BGA257 1N15P part. I don't know how to proceed, seriously. I will look into your suggestions, but any additional hint is gratefully accepted!. PS: The clock mode entry code, executed at startup: /* Enable All Modes */ MC_ME.ME.R = 0x000005E2; /* Peripheral ON in every run mode */ MC_ME.RUN_PC[0].R = 0x000000FE; /******************** Configure XOSC for DRUN **********************/ /* Enable EXT OSC First */ XOSC.CTL.B.OSCM = 0x1; /* Change OSC mode to LCP (Loop Controlled Pierce Mode) */ XOSC.CTL.B.EOCV = 0x80; /* Set the End of Count Value for when to check stabilization. */ /* Enable XOSC in DRUN mode and select as SYS_CLK */ MC_ME.DRUN_MC.R = 0x00130031; /* RE enter the DRUM mode, to update the configuration */ MC_ME.MCTL.R = 0x30005AF0; /* Mode & Key */ MC_ME.MCTL.R = 0x3000A50F; /* Mode & Key inverted */ while(MC_ME.GS.B.S_MTRANS == 1); /* Wait for mode entry to complete */ while(MC_ME.GS.B.S_CURRENT_MODE != 0x3); /* Check DRUN mode has been entered */ while(!MC_ME.GS.B.S_XOSC); /* Wait for clock to stabilise */ /******************** PLL0, PLL1 **********************/ /* Route XOSC to PLL1 */ MC_CGM.AC4_SC.B.SELCTL = 1; /* Route XOSC PLL0 */ MC_CGM.AC3_SC.B.SELCTL = 1; /* Configure PLL0 Dividers for 160 MHz fPLL0_VCO = (fPLL0_ref x PLL0DV[MFD] x 2)/PLL0DV[PREDIV] = 40MHz x 8 x 2 / 1 = 640 MHz fPLL0_PHI = fPLL0_ref x PLL0DV[MFD] / (PLL0DV[PREDIV] x PLL0DV[RFDPHI] = 40MHz x 8 / (1 x 2) = 160 MHz fPLL0_PHI1 = fPLL0_ref x PLL0DV[MFD] / (PLL0DV[PREDIV] x PLL0DV[RFDPHI1]) = 40MHz x 8 / (1 x 😎 = 40 MHz */ PLLDIG.PLL0DV.B.RFDPHI1 = 8; PLLDIG.PLL0DV.B.RFDPHI = 2; PLLDIG.PLL0DV.B.PREDIV = 1; PLLDIG.PLL0DV.B.MFD = 8; /* Configure PLL1 Dividers for 200 MHz fPLL1_VCO = fPLL1_REF x (PLL1DV[MFD] + PLL1FD[FRCDIV]/2^12) = 40MHz x 20 + 0 = 800 MHz fPLL1_PHI = fPLL1_REF * ( (PLL1DV[MFD] + PLL1FD[FRCDIV]/2^12) / (2 x PLL1DV[RFDPHI]) ) = 40MHz x (20 + 0) / (2 x 2) = 200 MHz */ PLLDIG.PLL1DV.B.RFDPHI = 2; PLLDIG.PLL1DV.B.MFD = 20; /* Enable PLL0/PLL1 in DRUN mode and set PLL1 as SYS_CLK */ MC_ME.DRUN_MC.R = 0x001300F4; /******************** Configure Clock Dividers **********************/ SIUL2.MSCR[22].R = 0x22800001; /* Configure CLK_OUT (B6) */ //MC_CGM.AC6_SC.B.SELCTL = 0; /* source AC6 is internal RCOSC */ //MC_CGM.AC6_SC.B.SELCTL = 2; /* source AC6 is PLL0 PHI */ //MC_CGM.AC6_SC.B.SELCTL = 1; /* source AC6 is XOSC */ MC_CGM.AC6_SC.B.SELCTL = 4; /* source AC6 is PLL1 PHI */ MC_CGM.AC6_DC0.R = 0x80090000; /* Aux clock select 6 divider 0 --> div by 10 (CLK_OUT) */ MC_CGM.AC0_SC.B.SELCTL = 2; /* source AC0 is PLL0 PHI */ MC_CGM.AC0_DC0.R = 0x80000000; /* Aux clock select 0 divider 0 --> div by 1 (MOTC_CLK) */ MC_CGM.AC0_DC1.R = 0x80070000; /* Aux clock select 0 divider 1 --> div by 8 (SWG_CLK) */ MC_CGM.AC0_DC2.R = 0x80010000; /* Aux clock select 0 divider 2 --> div by 2 (ADC_CLK) */ MC_CGM.AC1_DC0.R = 0x80010000; /* Aux clock select 1 divider 0 --> div by 4 (FRAY_PLL_CLK) */ MC_CGM.AC1_DC1.R = 0x80030000; /* Aux clock select 1 divider 1 --> div by 4 (SENT_CLK) */ MC_CGM.AC2_DC0.R = 0x80030000; /* Aux clock select 2 divider 0 --> div by 4 (CAN_PLL_CLK) */ MC_CGM.SC_DC0.R = 0x80030000; //80070000 div by 8, 25mhz /* 80030000 Sys clock select divider 0 --> div by 4 (PBRIDGEx_CLK) -> DSPI clock = 50MHz, PIT clock = 50 MHz */ /******************** Start the core **********************/ /* Main and checker cores running in RUN3:0, DRUN, SAFE, TEST modes */ MC_ME.CCTL0.R = 0x00FE; /* Set PRAM controller WS to 1 since running SYS_CLK as PLL1 (200 MHz) */ PRAMC.PRCR1.B.FT_DIS = 1; /******************** Perform mode change **********************/ /* Mode change re-enter the DRUN mode, to start cores, clock tree & PLL1 */ MC_ME.MCTL.R = 0x30005AF0; /* Mode & Key */ MC_ME.MCTL.R = 0x3000A50F; /* Mode & Key inverted */ while(MC_ME.GS.B.S_MTRANS == 1); /* Wait for mode entry complete */ while(MC_ME.GS.B.S_CURRENT_MODE != 0x3); /* Check DRUN mode entered */ PS 2: Can the PFCR1 register values affect to this hang issue? Before the hang, the software is not performing any FLASH write. Re: MPC5744P CPU crash under certain conditions, but unknown cause Have you measured RESET signal bu scope? Has MCU been reset? According your description you says debugger affect the behavior in the meaning the fault does no happen. Also basically you said behavior is unpredictable but repeatable. I would at first check you clocking configuration. In the datasheet section 3.16.3 you have defined prescribed number of flash wait states. Check 2.9.1 System clock frequency limitations Also there is several errata that woul be needed top check: ERR010639 ERR010640 ERR011073 https://www.nxp.com/docs/en/errata/MPC5744P_1N65H.pdf https://www.nxp.com/docs/en/errata/MPC5744P_1N15P.pdf

flexbuilder lsdk2108 支持 SERDES1 协议 0x3333 您好， 我们在自定义主板中使用 LS1046A，图像是使用 flexbuild lsdk2108 编译的，我们的设计与 ARDB 开发套件类似。SERDES1 支持两个 10G 端口和两个 1G 端口，不使用 SERDES2。 我们已经根据我们的自定义主板编译了图像，一切正常，10G 端口 (xgmii) 和 1G 端口 (sgmii) 都运行正常。在我们的一个应用中，我们希望将两个 10G 端口都用作 1G 端口。为此，我们更改了 rcw、uboot 和 linux dts 文件。随函附上这些文件以供参考。 编译和主板启动后，我们可以看到 Linux 日志仍在寻找 10G 端口，而 ubuntu 文件系统没有显示 fm1-mac1 和 fm1-mac2 端口。附上启动日志以供参考。 从启动日志中可以明显看出，我们缺少了一些需要更改的内容。在这方面，要求支持需要修改哪些文件才能满足我们的要求。 谢谢& Regards-- 纳古尔瓦利-赛亚德 Re: flexbuilder lsdk2108 support for SERDES1 protocol 0x3333 您好， 感谢您的回复。按照建议，在 rcw、u-boot 和 linux dts 文件中进行更改。从所附的上一个日志文件中可以看到，初始信息显示如下。 "ETH0：FM1-MAC1，ETH1：FM1-MAC2，ETH2：FM1-MAC3，ETH3：FM1-MAC4，ETH4：FM1-MAC5，ETH5：FM1-MAC6 " 更改 u-boot dts 文件后，出现 fm1-mac1 和 fm1-mac2。请建议我们需要对 eth.c 文件做哪些修改。 此外，是否还需要修改任何其他文件。 谢谢& Regards-- 纳古尔瓦利-赛亚德 Re: flexbuilder lsdk2108 support for SERDES1 protocol 0x3333 你好 是的--对于 LS1046A，将两个 10G SerDes1 端口改为 1G 并不仅仅是 Linux DTS 变动。你需要对齐所有三层：RCW、U-Boot 主板以太网修复和 Linux DTS。如果 Linux 仍在探测 10G 端口，而 fm1-mac1 / fm1-mac2 没有出现，那么最有可能的问题是 U-Boot 在 Linux 启动之前仍在 DT 中禁用这些 MAC 节点 要使两个 LS1046A 10G 端口用作 1G 端口，必须将 RCW 更改为 SGMII 协议，例如 0x3333 ，更新 U-Boot eth.c 以使其不会禁用这些 MAC 节点，并更新 Linux DTS，以便使用正确的 PHY 或固定链路配置将这些端口描述为 sgmii。 此致问候 Re: flexbuilder lsdk2108 support for SERDES1 protocol 0x3333 您好， 我们按照建议修改了 rcw、eth.c、uboot dts 和 linux dts。现在我们可以枚举 Linux 启动后的 fm1-mac1 和 fm1-mac2 端口（附上以供参考）。 但我们无法通过这些端口进行数据通信。 还附上了日志文件以供参考。 请审查这些修改意见，并就需要做哪些修改提出进一步建议。 谢谢 -- 纳古尔瓦利-赛亚德