Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
Timer triggers DMA transfer Hello, I'm currently working with an MCXN947 microcontroller. I'm trying to trigger a DMA transfer into a sample buffer via a CTIMER match interrupt. The idea is to write into the sample buffer the state of a GPIO register (specifically the input values of some pins) via DMA at every x timer intervals (specifically every 10 us). I can confirm that my GPIO pin is correctly configured as an input. I can confirm that my timer is working correctly and triggering a match at every 10 us. I can confirm that my DMA transfers are working correctly because the buffer gets filled up with values. I can confirm that the source address (GPIO PDIR reg) is correctly set in the DMA configuration. I can confirm that my destination address is also correctly set in the DMA configuration as it is always in between the start and end address of my buffer (meaning it increments and wraps around correctly). But for some reason, the wrong values are being copied into the buffer. I can see in my debugger that the value of the register I'm trying to transfer is 0x00020000 (pin 17 is high, the rest are low). However, my buffer is only being filled with 0s. It's a uint32_t type buffer of 512 elements initialized all at 0xFF. As the DMA transfers increment, the whole buffer progressively gets filled with 0x0 and not the expected value of 0x00020000 (which never changes - pin 17 is always high). Do you have any idea what causes this? Or if I'm possibly missing something? Here are my driver configurations: Timer: CTIMER0 kCTIMER_Match_1 CTIMER0_IRQn (triggering callback on interrupt is optional but I use it in my code for debugging purposes) DMA: DMA0 kDma0RequestMuxCtimer0M1 kINPUTMUX_Ctimer0M1ToDma0Ch8Ena EDMA_0_CH8_IRQn (triggering callback on interrupt is optional but I use it in my code for debugging purposes) GPIO: GPIO3 PORT3 Pin 17 Here are the states of the registers right before I start sampling reg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.png reg_port3.pngreg_port3.pngreg_port3.pngreg_port3.pngreg_port3.png reg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.png reg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.png reg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.png reg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.png             MCXN Re: Timer triggers DMA transfer Hello @jabitbe2_jcplc  Could you please share your project with us? I would like to try to reproduce the issue and investigate it on my side. Thank you. Best Regards, Alice Re: Timer triggers DMA transfer Hello, Due to IP I cannot send you my whole project. However, I can give you a c file that contains my setup in a little application. The GPIO, DMA and TIMER configurations are the same I have on my side. The file is in attachment. Re: Timer triggers DMA transfer Hello @jabitbe2_jcplc  The MCXN947 supports TrustZone and security attribution control. If the access originates from a security domain that does not match the pin's security configuration, read and write operations to the corresponding GPIO registers may be ineffective. Could you please verify whether the GPIO3 Pin 17 corresponding bit is configured to allow Non-Secure access and test again? If the bit is currently configured as Secure-only, the unexpected GPIO behavior may be related to the TrustZone security settings. Thank you. BR Alice
記事全体を表示
iMX8M Plus CC 控制器 嗨, 我们正在基于 iMX8M plus 处理器和定制载板开发定制的 SOM。为此,我们需要支持带 ID 引脚的 USB1 OTG 功能。我们从 GPIO1_IO4 获取了 ID 引脚。 由于电路板空间限制和 ID 引脚要求,我们计划在我们的设计中使用HD3SS3220IRNH - TI(带差分多路复用的 CC 控制器) 。 请确认 i.mx8m plus 是否支持 HD3SS3220IRNH 作为 OTG 设备。具体来说,就刷机而言,这个控制器是否受支持? Re: iMX8M Plus CC Controller 嗨@Zhiming_Liu 请问您能否推荐其他经过测试且支持 ID 引脚的 CC 控制器? Re: iMX8M Plus CC Controller 你好@govind18 i.MX 8M Plus 可以配置到系统设计中,与 TI HD3SS3220 配合使用,实现双角色 USB Type-C 端口;但是,该设备并非 NXP 的 EVK 官方验证或支持的 Type-C 控制器。GPIO1_IO4 可用作 Uboot/Linux 中的 USB ID,并且不影响 UUU 编程。建议将 HD3SS3220 在开机时默认配置为 UFP/Sink。 此致, 志明
記事全体を表示
S32k344 MBIST LBIST 我正在 Green Hills 的一个项目中实施 S32k344 BIST。由于我不使用 Tresos 或 NXP DS,所以我使用的是源代码形式的 SW32K3_SPD_1.0.6_D2512。我能够导入大部分 bist 函数,但有一些我不确定的定义(到处都找不到它们)。请问有人能回答以下问题吗? 1. 当 S32k344 处于锁定步进模式时,我可以运行 LBIST MBIST 吗? 2. 我通过检查代码猜测以下定义是否正确? #define BIST_MBIST_0 1U #define BIST_MBIST_1 2U #define BIST_MBIST_2 3U #define BIST_MBIST_3 4U #define BIST_MBIST_4 5U #define BIST_MBIST_5 6U #define BIST_MBIST_6 7U #define BIST_MBIST_7 8U #define BIST_MBIST_8 9U #define BIST_MBIST_9 10U #define BIST_MBIST_10 11U #define BIST_LBIST_0 0U 我使用的配置数据如下: static const BIST_CHANNEL_CONFIG_TYPE BistConfig[BIST_SAFETYBOOTCFG_NB] = { { (BIST_CHANNEL_TYPE)BIST_MBIST_0, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_1)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_1, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_2)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_2, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_3)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_3, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_4)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_4, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_5)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_5, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_6)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_6, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_7)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_7, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_8)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_8, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_9)) }, //#endif { (BIST_CHANNEL_TYPE)BIST_MBIST_9, (BIST_CONTROL_TYPE)((0x80100000U) | BIST_MBIST_PTR_VAL(BIST_MBIST_10)) }, { (BIST_CHANNEL_TYPE)BIST_MBIST_10, (BIST_CONTROL_TYPE)(0x00100000U) }, { (BIST_CHANNEL_TYPE)BIST_LBIST_0, (BIST_CONTROL_TYPE)((0x00001108U) | BIST_LBIST_PTR_VAL(BIST_NIL)) } }; Re: S32k344 MBIST LBIST 你好, 1. 当 S32k344 处于锁定步进模式时,我可以运行 LBIST MBIST 吗? 是的。S32K344 锁步架构不会阻止 STCU2 LBIST/MBIST 的执行。BIST 机制是设备功能安全基础设施的一部分,旨在测试由 STCU2 管理的逻辑和存储器。The S32K3 功能安全 Manual explicitly lists both lockstep and STCU2 LBIST/MBIST as safety mechanisms of the 设备. 2. 我通过检查代码猜测以下定义是否正确? 对于 S32K344 来说,这些数值基本正确,但从功能安全角度来看,在功能安全启动配置中包含 MBIST_10 (HSE_ROM) 并非必需,建议直接使用经过验证的 SPD 配置。 顺祝商祺! Peter Re: S32k344 MBIST LBIST 彼得 非常感谢您的回复。我这几天一直被BIST测试问题困扰着。我正在使用 S32k344 白板进行测试,代码是用 Green Hills Multi IDE rev 8.1 版本 的。安全靴自检未通过。我确信核心和外设都满足最大时钟频率要求。我的核心时钟频率为 160MHz,来自外部晶振 16MHz 和 PLL,AIPS_PLAT_CLK 为 80MHz,AIPS_SLOW_CLK 为 40MHz,DCM_CLK 为 40MHz,LBIST_CLK 为 40MHz,QSPI_MEM_CLK 为 160MHz。当设备从 BIST 运行复位时,出现以下错误:DES 寄存器为 0x00408175,一些保留位被设置,FES 寄存器为 0x2000(这没有意义)。请问您能否回答以下问题? 1. 对于上面提到的所有时钟信号,是否应该通过 MC_CGM->MUX_0_DC_x 寄存器启用它们?我正在获得 信息相互矛盾,目前这些功能已启用。 2. 在参考手册的 STCU2 章节中,有这样一段话:“在 EMAC 时间戳存储器上运行 MBIST 时,应适当配置 MC_CGM.MUX_9_DC_0[DIV],以确保 EMAC_CLK_TS 至少是 AIPS_SLOW_CLK 频率的 1.5 倍。”那是不是意味着我必须配置时钟并在 MC_CGM->MUX_9_DC_0 寄存器中启用它? 3. 如果我想查看 SW32K3_SPD_1.0.6_D2512 软件包中的示例代码 S32_SPD_Demo,我猜我需要安装最新的 NXP Design Studio,将 spd zip 文件作为更新站点导入,还需要 RTD 软件包,是这样吗? 4. 我认为 MBIST 10 是 HSE_RAMS,MBIST 11 是 HSE_ROMS,请参阅 SPD 文档文件夹中的下表。 MBIST BIST ID BIST实例名称 RESET 功能域 安全靴 功能安全诊断 0 SYS0_RAMS 主要 ü ü 1 SYS1_RAMS 主要 ü ü 2 DMA_TCD_RAM 主要 ü ü 3 CM7_0_TOP 主要 ü ü 4 CM7_1_TOP 主要 ü ü 5 FLEX_CAN_RAMS 主要 ü ü 6 QSPI_PERI_RAMS 主要 ü ü 7 EMAC_TSN_RAM 主要 ü ü 8 EMAC_RAMS 主要 ü ü 9 b03_ETF_RAMS 主要 ü ü 10 HSE_RAMS 主要 ü ü 11 HSE_ROMS 主要   ü Re: S32k344 MBIST LBIST 我的问题有了新的进展,在我启用 STCU_RUNSW_REG 中的第 8 位和第 9 位以使用 PLL 之后,我一直看到 DES 寄存器为 0x11,FES 寄存器为 0x10。bist_get_exec_status(BIST_SAFETYBOOT_CFG) 返回值为 NOT RUN (0x03)。BIST ERR_STAT 寄存器中没有任何内容,END 标志也没有设置。FCCU NCF_S0 寄存器中的第 2 位已设置。BIST 似乎没有启动,但我确实看到了 RESET。我通过写入另一侧银行的闪存来捕获寄存器设置。 Re: S32k344 MBIST LBIST 我检查了所有可能的时钟,我相信它们是正确的。我还将寄存器中的配置数据与 NXP studio spd 示例项目中的值进行了比较,它们也是正确的。一条新信息。系统从 BIST RESET 后,我在 DCMROD3 寄存器中看到值 0x18。我该如何解决这个错误?谢谢。 XRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.pngXRen_Parker_0-1788544110794.png Re: S32k344 MBIST LBIST 你好, STCU 自检序列正在进入并到达 ST_DONE RESET 阶段。但是,STCU 还报告了一个不可恢复的故障 (STCU_URF),这就解释了为什么 SAF BIST 驱动程序随后报告 BIST_NORUN。因此,问题似乎是 STCU 执行/配置失败,而不是 BIST 从未触发信号的情况。 在 S32K3 上,同时看到破坏性复位和功能性复位指示通常表明您正在查看复位历史记录,而不是当前的复位源。 既然你在移植软件,我建议先从仅进行 MBIST 测试开始,看看它是否能从 PLL 源通过。 另外,我建议你再检查一下测试的时钟设置。 顺祝商祺! Peter Re: S32k344 MBIST LBIST 你好, 在 S32K344 上,RCCU 报告锁步不匹配,并且当连接到调试器时,经常会出现与 RCCU 相关的故障,而这些故障在独立执行中永远不会发生。 如果您按照示例中的设置进行操作,您将看到完整的 BIST(内置自测试)。 示例已测试,默认情况下完全可用。 但是您的端口报告 URF 故障,这说明并非所有部件都相同。 查阅STCU文档,用户可以设置指向测试的指针。 54.9.4 STCU2 配置 (CFG) petervlna_0-1788766597312.pngpetervlna_0-1788766597312.png 您可以先尝试减少测试用例,然后慢慢添加更多测试用例。 在 MBIST 和 LBIST 控制寄存器中,您可以设置哪个测试将是最后一个: petervlna_1-1788766735386.pngpetervlna_1-1788766735386.png 例如,通过指向 CFG 寄存器中的某个位置,您可以执行单个 MBIST 分区: petervlna_2-1788766853581.pngpetervlna_2-1788766853581.png petervlna_3-1788766973925.pngpetervlna_3-1788766973925.png 顺祝商祺! Peter
記事全体を表示
SE050 セキュアエレメントと i.MX 8M PlusおよびYocto Linuxとの統合 チームの皆さん、こんにちは。 私は8M Plus EVKとNXP SE050セキュアエレメント i.MX 使っています。SE050をLinuxで動かしたいと思っています。i.MX プラットフォーム用のYoctoビルドシステムを使って。 SE050を8M PlusおよびYoctoと統合・テストするための統合・移植ドキュメント、アプリケーションノート、または参考実装 i.MX 教えていただけますか? NXPのPlug & Trustミドルウェアリポジトリに出会い、i.MX6ULとi.MX8MQのLinuxサポートについて言及しています: https://github.com/NXP/plug-and-trust また、既存の実装が i.MX 8M Plusで直接利用できるのか、それとも特にI²CインターフェースやYocto統合に関してプラットフォーム固有の移植が必要なのかも知りたいです。 ありがとう、 ローハン SE050 Re: SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux こんにちは、 @rohannathi さん。 Plug & TrustミドルウェアのGitHubミニパッケージは Linux向けのサブセットです。nxp.com/se050 のフルパッケージは、例、ツール、完全なドキュメントを含むため、開発に推奨されます。 i.MX 8M Plusは既存の iMXLinux ホストターゲットと完全に互換性があり、i.MXファミリ特有の移植は不要です。 NXPのリファレンス設計であるNavQPlus(8MPNAVQ)は、同じ i.MX 8M Plus SoC(i.MX 8M Plus EVKと同じSOM)をベースにし、オンボードのSE050セキュア要素とYocto LinuxおよびROS2イネーブルメントを備えています。これはSE050 + i.MX 8M Plus + Yoctoの最も近いハードウェアリファレンスであり、そのBSP/Yoctoレイヤー構成は直接的なガイドとして利用できます。 詳細については、 https://community.nxp.com/t5/Secure-Authentication-Knowledge/Integrating-EdgeLock-SE05X-to-FRDM-IMX91/ta-p/2138152を参照してください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------
記事全体を表示
请问能否提供LS1021AXE7KQB的引脚延迟? 你好, 目前,我正在为我的板设计PCB。对于 DDR4 接口的关键时序要求,我需要补偿 PCB 上 LS1021AXE7KQB 封装的引脚延迟差异。所以,请问您能否提供LS1021AXE7KQB的引脚延迟信息? 提前感谢! 顺祝商祺! 杰森 QorIQ LS1设备 Re: Could you please provide me the pin delay of LS1021AXE7KQB? DDR4接口所有内部芯片到焊盘的连接线在封装内长度均匹配,因此布局走线长度的调整工作只需在处理器引脚和同步动态随机存取存储器(SDRAM)引脚之间进行即可。由于设计方法不需要提供具体的封装延迟值,因此没有提供这些值。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 嗨,一平 对于LS1021A 的 DDR4 接口,是否需要在 PCB 封装中补偿引脚延迟差异? 提前感谢! 顺祝商祺! 杰森 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 所请求的文件属于 NXP 机密专有信息,只能在签署保密协议 (NDA) 后提供。   你和恩智浦签过保密协议吗?如果可以,请您提供保密协议副本或保密协议编号?   您可以从https://www.nxp.com/webapp-signup/ndaReqForm签署新的保密协议。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 向AE团队询问了所需信息。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 您好, 欢迎任何回复! 提前感谢! 顺祝商祺! 杰森 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 请为您的新问题创建一个新主题帖好吗? 谢谢。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? 嗨,一平: 收到了,非常感谢!!! 对了,我还有个问题。LS1021A 的 eTSEC1 和 eTSEC3 将配置为 RGMII 模式以驱动 PHY。但是我的电路板尺寸很大,我担心PCB上过长的走线会导致RGMII接口(每个数据信号250Mbps)的驱动能力不足。请提供 RGMII 接口的布线约束,特别是基于常用 FR-4 PCB(Dk 4.2~4.4)的 PCB 上的走线长度,自由度为 0.022)?因为我在恩智浦的网站上找不到任何关于PCB设计方面的考虑因素。此外,AN4878_设计检查清单仅显示原理图的设计要求。 提前感谢! 顺祝商祺! 杰森
記事全体を表示
リップルによってVDDが下限値を下回った場合のP2020デバイスの状態/動作 リップルなどでVDDが下限電圧を下回った場合のP2020プロセッサの状態や挙動について知りたいです。 P2020ハードウェア仕様書(文書番号:P2020EC)の表3「推奨動作条件」によると、VDD、AVDD_xxxx、SVDD_SRDS、XVDD_SRDSの推奨値は「1.05 ± 50 mV」です。つまり、下限電圧は1.00Vであるということです。 リップル電圧の下限が指定された最低電圧1.00Vを下回った場合、P2020のデバイスの状態や挙動について教えていただけますか? (例えば、VDDの中心電圧が1.01Vであっても、リップル電圧の下限値は0.99V(1.00V未満)になる。) VDDの中心電圧が1.00V以上であれば、デバイスの正常な動作に問題はありませんか?リップル電圧があっても、動作不良や損傷のリスクはありますか? お知らせ下さい。 事前に感謝いたします。 Re: P2020 device status/behavior if VDD falls below lower limit due to ripple こんにちは、   P2020ハードウェア仕様書(文書番号:P2020EC)の表3では、VDD、AVDD_xxxx、SVDD_SRDS、およびXVDD_SRDSが1.05±50mVと規定されており、これは有効な動作範囲が1.00V(最小)から1.10V(最大)であることを意味します。これは推奨される動作条件であり、絶対的な最大定格ではありません。 重要な点は、規定されている最小電圧1.00Vは、デバイスのピンにおける瞬時電圧に適用されるものであり、DC中心点のみに適用されるものではないということです。リップルはデバイスが実際に受ける電圧の一部であり、デバイスは規定の範囲内でのみテストおよび特性評価されます。 リップル電圧が1.00Vを下回った場合のリスク 中心(DC)電圧が1.00V以上であっても、リップルトラフが1.00Vを下回ると、推奨動作条件外の動作となります。NXPのこの点に関する立場は、QorIQおよび関連プロセッサファミリ全体で一貫して述べています。 機能的・運用上のリスク:VDDが一時的に最小値を下回ると、プロセッサ内部のロジックが十分な駆動強度やタイミング余裕を持っていない可能性があります。これは以下のように現れることがあります: 命令の実行が間違っています データ破損(例:メモリ比較エラー) 重要なタイミングパスにおける予測不可能な動作 関連するQorIQプロセッサ(P1013)を使った直近のNXPケースでは、「[デバイス]を[限界に近い電圧]で動作させると機能上の問題が発生するリスクがあります。なぜなら、この値はお客様の設定設定ポイントを表すからです。通常の電圧許容範囲、リップル、または過渡的な挙動により、電圧がこのレベルを超えたり、下回ったりする可能性があります。」 「中心電圧 ≥ 1.00 V」という条件は不十分です。デバイスは供給電圧を「平均化」しません。デジタルロジックは瞬時電圧に基づいて動作する。リップルの谷間(例えば、あなたの例では0.99V)の間は、たとえスイッチングサイクルのほんの一部であっても、デバイスは実際に仕様を下回る動作をしています。これにより内部フリップフロップでセットアップやホールドタイム違反が発生し、機能エラーを引き起こすことがあります。 小さな短時間の変動では、永続的な損傷は想定されません。小さなリップル変動(例えば、一般的なスイッチング周波数で最小値より10mV低い場合)では、デバイスに永続的な物理的損傷が発生する可能性は低いです。電圧は依然として絶対最大定格の下限値を十分に上回っています。しかし、機能的正確性は保証されておらず、NXPはこの条件下での動作をサポートしたり特徴付けしたりしていません。 信頼性/耐久性:特にP2020の場合、電圧範囲の下限付近で動作させる方が(上限付近で動作させるよりも)、一般的には最大電圧を超えて動作させるよりも長期的な信頼性の問題は少ない。ただし、仕様外の条件下での繰り返しまたは継続的な動作は推奨もサポートもされません。 NXPの標準ガイダンスは、複数のQorIQおよび関連するプロセッササポートケースで確認されており、以下の通りです。 「仕様外の機器の使用は推奨もサポートもされていません。」 通常の動作時、デバイスのピンにおける電圧波形全体(リップルを含む)は、規定の1.00V~1.10Vの範囲内に収まっていなければならない。   よろしくお願いします。
記事全体を表示
EMI/EMC適合証明書および試験報告書 チームの皆さん、こんにちは。 下記の15W受信キットがEMI/EMC準拠かどうか、確認していただけませんか? 部品番号:WPR1500-HV 説明 - 高電圧ワイヤレス充電レシーバ よろしくお願いいたします。 パース・バヴサル Re: EMI EMC Compliance certificate and test report こんにちは、セレステさん。 ご返信ありがとうございます。 検査結果と検査結果の共有を手伝っていただけませんか?そこで、このEVKに対して基本的なEMI/EMCテストが行われているかを確認します。 よろしくお願いいたします。 パース・バヴサル Re: EMI EMC Compliance certificate and test report こんにちは、 @P907 さん。 投稿ありがとうございます。このEVKは主に評価用であり、CE規格に準拠するための基本的なEMI/EMC試験に合格する必要があります。一般的に、当社のソリューションと市販の一般的なソリューションの間に大きな違いはありません。 お役に立てば幸いです。 BR セレステ Re: EMI EMC Compliance certificate and test report こんにちは、 @P907 さん。 もちろん、あなたと共有できます。ただし、これらの資料はコミュニティなどの公開プラットフォームでの共有には適していません。後ほど、プライベートメールでお送りします。受信トレイをこまめに確認してください。 よろしくお願いいたします。 セレステ Re: EMI EMC Compliance certificate and test report こんにちは、セレステさん。 ご依頼いただいたEVMのEMI/EMC試験報告書をご共有いただきありがとうございます。 よろしくお願いいたします。 パース・バヴサル
記事全体を表示
SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux Hi Team, I am working with  i.MX 8M Plus EVK and an NXP SE050 Secure Element. I would like to get the SE050 up and running with Linux using the Yocto build system for the i.MX platform. Could you please share any available integration/porting documentation, application notes, or reference implementations for integrating and testing the SE050 with i.MX 8M Plus and Yocto? I came across the NXP Plug & Trust middleware repository, which mentions Linux support for i.MX6UL and i.MX8MQ: https://github.com/NXP/plug-and-trust I would also like to understand whether this existing implementation can be directly used with i.MX 8M Plus, or if any platform specific porting is required, particularly for the I²C interface and Yocto integration. Thanks, Rohan SE050 Re: SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux Hi @rohannathi , The Plug & Trust middleware GitHub mini-package is a subset for Linux use; the full package at nxp.com/se050 is recommended for development as it includes examples, tools, and complete documentation. The i.MX 8M Plus is fully compatible with the existing iMXLinux host target — no i.MX-family-specific porting is needed. There is an NXP reference design — the NavQPlus (8MPNAVQ) — that is based on the same i.MX 8M Plus SoC (identical SOM to the i.MX 8M Plus EVK) and features an onboard SE050 secure element, with Yocto Linux and ROS2 enablement. This is the closest available hardware reference for SE050 + i.MX 8M Plus + Yocto, and its BSP/Yocto layer configuration can be used as a direct guide. You may refer to https://community.nxp.com/t5/Secure-Authentication-Knowledge/Integrating-EdgeLock-SE05X-to-FRDM-IMX91/ta-p/2138152 for more details. Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示
LS1021AXE7KQBのピンディレイを教えていただけますか? こんにちは、 現在、私は自分の基板用のプリント基板を設計しています。DDR4インターフェースの重要なタイミング要件のために、PCB上のLS1021AXE7KQBパッケージのピン遅延差を補正する必要があります。ですので、LS1021AXE7KQBのピンディレイ情報を教えていただけますか? よろしくお願いいたします! よろしくお願いいたします! ジェイソン QorIQ LS1デバイス Re: Could you please provide me the pin delay of LS1021AXE7KQB? DDR4インターフェースの内部ダイからパッドへの配線はすべてパッケージ内で長さがマッチングされているため、レイアウトトレース長のタスクはプロセッサとSDRAMのピン間で行われます。設計アプローチには必要ないため、具体的なパッケージ遅延値は提供されませんでした。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? こんにちは、イーピン LS1021AのDDR4インターフェースの場合、PCBのパッケージ内のピン遅延差を補正する必要がありますか? よろしくお願いいたします! よろしくお願いいたします! ジェイソン Re: Could you please provide me the pin delay of LS1021AXE7KQB? 要求された文書はNXP機密所有のものであり、秘密保持契約(NDA)の下でのみ提供可能です。   NXPと秘密保持契約(NDA)を締結しましたか?はいの場合、NDAのコピーまたはNDA番号をご提供いただけますでしょうか?   新しいNDAを歌うこともできます https://www.nxp.com/webapp-signup/ndaReqForm Re: Could you please provide me the pin delay of LS1021AXE7KQB? AEチームに必要な情報を依頼しました。 Re: Could you please provide me the pin delay of LS1021AXE7KQB? こんにちは、 どんなご意見でも歓迎いたします! よろしくお願いいたします! よろしくお願いいたします! ジェイソン Re: Could you please provide me the pin delay of LS1021AXE7KQB? こんにちは、イーピン: 入手できました、本当にありがとうございます! ところで、もう一つ質問があります。LS1021AのeTSEC1およびeTSEC3は、ドライバーPHYに対してRGMIIモードとして設定されます。しかし、私の基板のサイズが非常に大きいため、PCBのトレースが長すぎるとRGMIIインターフェース(1回あたり250Mbps)のドライブ能力が不足するのではと心配しています。RGMIIインターフェースのルート制約、特に一般的なFR-4 PCB(Dk 4.2~4.4)に基づくPCB上のトレース長について教えていただけますか。Df 0.022)?なぜなら、NXPのウェブサイトでPCB設計に関する考慮事項が見つからないからです。また、チェックリストAN4878_Design回路図の設計要件のみを表示します。 よろしくお願いいたします! よろしくお願いいたします! ジェイソン Re: Could you please provide me the pin delay of LS1021AXE7KQB? 新しい質問のために新しいスレッドを作ってもらえますか? ありがとうございます。
記事全体を表示
lpc4078 eeprom page erase clarification required I'm using an LPC4078 and MCUXpresso and experimenting with storing values in Eeprom. I want to write a few bytes in the middle of a page without clearing the whole page. Looking in the datasheet, it says that after writing the data to be written int he page register, it still has to be programmed into non-volatile memeory and that is done with the erase/program operation. Does the Erase/Program operation erase the whole page or just the area of the page I have new data for, and how does it know? - the address setting for Erase/Program ignores the 6 lsbs so it only knows the page. The UM10562.pdf isn't explicitly clear on this matter. Thanks Alex Re: lpc4078 eeprom page erase clarification required I attach a workspace with the mentioned project in it. I ran it on an LPC4078 using a lpc-link2 debugger. (I couldn't be bothered to get semihosting to work, so I used breakpoints and inspected the data) Re: lpc4078 eeprom page erase clarification required Hello @alex_conway  For LPC4078 EEPROM, the minimum erase/program unit is one page (64 bytes). Therefore, each erase/program operation will erase the entire page. If you want to write only a few bytes, please first read the whole page, then modify the required bytes, and finally perform an erase/program operation on the page. You can test this on your side.   Thank you.   BR Alice Re: lpc4078 eeprom page erase clarification required Hi Alice, My experiments demonstrate otherwise: I wrote a small program using the lpc_board_ea_devkin_4088 library and the periph_eeprom demo project to start me up. I erase a page of Eeprom and read it back. To my surprise the results are all '\0' instead of 0xFF Then I write 'ABCDEFG\0' to address 0 in that page and read the page back. I receive 'ABCDEFG\0' Then I write 'ABCDEFG\0' to address 7 in that page and read the page back. I receive 'ABCDEFGABCDEFG\0' This is all as expected except for two things: 1. after erasing the eeprom reads 0 2. looking at the implementation of Chip_EEPROM_Write() is can seem no read-modify-erase-write sequence. There is only Chip_EEPROM_WritePageRegister followed by Chip_EEPROM_EraseProgramPag. This is why I asked the question. Thanks Alex Re: lpc4078 eeprom page erase clarification required I've got semihosting to work after adding a newline to all my printf strings! Also clearer evidence of everything I have said: Erasing sets Eeprom to 0x00 The code does not perform a read-modify-erase-write sequence, just erase-write. The LPC4078 seems to only erase the locations that are written to when erasing. I would really like clarification on this. Thanks Alex Re: lpc4078 eeprom page erase clarification required Despite "Escalating" whatever that means, there has been no further response from NXP on this. I still need clarification.  Re: lpc4078 eeprom page erase clarification required Hi @alex_conway  Thanks for your reply, and I apologize for the delayed response. Unfortunately, our community script was previously broken, so customer replies did not trigger case update notifications in our internal system. I sincerely apologize for the delay. Regarding the EEPROM on the LPC4078, according to the User Manual, all communication with the actual EEPROM block is performed through a 64-byte page buffer. Therefore, please make sure your EEPROM operations follow the requirements described in the User Manual. Alice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.png Alice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.png At this point, we cannot determine whether there is an issue unless the EEPROM is being accessed according to these requirements. Thank you. BR Alice Re: lpc4078 eeprom page erase clarification required Hi Alice, I'm using the functions in eeprom_17xx_40xx.h and eeprom_17xx_40xx.c (provided by NXP and included in the project I attached) The Chip_EEPROM_Write() function calls the Chip_EEPROM_WritePageRegister() function followed by Chip_EEPROM_EraseProgramPage() The Chip_EEPROM_WritePageRegister()function sets the EEPROM Address using the Chip_EEPROM_SetAddr() function which takes care of shifting and blanking the lower 6 bits. Then the data bytes are written to the EEPROM write data register (WDATA) using the Chip_EEPROM_WriteData() function The Chip_EEPROM_EraseProgramPage() uses the Chip_EEPROM_SetAddr() function to set the page address, anables the erase/page-program bit and waits for programming to finish. I cannot see any code that reads the exisitng EEPROM data in the page to perform a page-read-modify-write. However, as demonstrated in my project, It appears that the EEPROM page erase does not erase the whole page, but only erases at the addresses with new data loaded into the write data register. Thanks Alex
記事全体を表示
RT1172 LT8918 LCDパラレル LCDIFV2 小型層 + 背景アンダーラン 残念ながら、このLCDにはmipi出力を直接接続できないのでLT8918が追加されていますが、問題は起きていないようです。テストパターンはそのデバイス上で正常に実行され、デバッグログにも同期と基本設定の合格が示されています。 しかし、出力に問題が生じます。現在私が持っているコードは、800x1280の画面の中央にある非常にシンプルな小さなメモリバッファ(128x256)のためのものです。実際の出力画面を見る必要はないが、非常に歪んでいるように見える。また、印刷された診断情報には、DMAが1行分の書き込みに必要なデータを十分な速さで取得できていないかのように、アンダーランエラーが多数表示されます。 私はLCDやNXPレジスタの専門家ではありません。どこかで何か愚かな間違いを犯しているのだろうか?不確実な要素は山ほどある。SRAM_OC1は実際にはかなり遅いのでしょうか?タイミングを正しく調整するために、AXIまたはDMAの設定があるのかもしれません。MPUコードでキャッシュしないように設定を変更しましたが、それも間違いかもしれません。残念ながら、デフォルト領域とncache領域の違いは分かりません。他にも考慮すべき点はたくさんあります。例えば、ストライド長を、より小さい128ピクセルのレイヤー0サイズではなく、800ピクセルの行全体に変更してみました。RGBピクセルクロックはMIPIバイトクロックよりも遅いが、MIPIはRGBの24本の並列接続ではなく2本のラインを使用しているため、いずれにしてもMIPIの方がはるかに高速であると予想される。 また、レイヤー0領域をこれほど小さくしている理由は、SDRAMにエラーが発生する可能性があるからです。この不確実性を避けるために、これをより小さなコントロールされた部分に縮小していますが、ここでも何が問題なのか正確には見つけられません。 ここまで来られたのは素晴らしいことだが、これ以上進歩するために何をすればいいのか分からないのは非常に歯がゆい。背景の単色表示はすべて問題なく動作し、テストパターンはきれいな形のバーの領域を作るので、本当の"LCD"の問題ではないと思います。むしろRAMバッファの読み取りやLCDIFv2がパラレル出力に割り当てているのがタイミングの問題のように見えます。 これをどうやってデバッグすればいいですか?ありがとう。 Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun いくつか試してみたところ、少なくとも印刷された診断結果を見る限り、アンダーランエラーのない安定した出力が得られているようです。主な変更点は最初のものだと思いますが、その他の変更点は実際にはもう少し複雑です。しかし、分かりやすくするために列挙しておきます。この設定はまだRGB888のままで、アルファレイヤー描画の実験のために変更したくありません。というのも、まだそれほど良い状態ではないからです。 1. ピクセルクロックを大幅に遅くし、リフレッシュレートを15Hzに近い値にする。DMAには作業のための余分な時間があるのかもしれない?でも、おっしゃる通り、OCRAMは高速なはずです。MPUの設定で、その領域もNCACHE領域として設定しています。 2. 使用されている色は黒と白のみです。緑色の背景を試すと、緑色がRGBパターンにシフトされて毎行(1バイトずれ?)という問題が発生します。 3. RAMレイヤー0の幅を高さ256に合わせるために256に変更します。実際、128の高さでも問題ありませんが、この丸太は256で、ストライドも768に変わるのがわかります。 4. 玄関ポーチと裏庭のビデオ設定がかなり大きくなっています。これが主な原因ではないと思います。もっと速い速度でこれらの設定も試してみましたが、あまり効果はありませんでした。データシートによると、Hfp + Hbp + Hs の最大値は任意の値に設定できますが、ここで合計200を超える値を設定する理由はあるのでしょうか?縦位置設定は、合計で250に制限されています。 とにかく、面白い話です!技術的には、LCDのデータシートには最低22Hzで動作させる必要があると記載されていますが、白い部分にちらつきは見られません。もっと速く走らせたいです。 RT1172のDMAについては全く気にしていなかったのですが、動作速度を上げたり、優先度を上げたりするために何かできることはありますか?LCDIFv2には、これに関する他の設定はありますか?特にOCRAMは本来とても速いはずなのに、こんなに遅くしたのにこんな効果が出たのは驚きです。 Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun 右。本当にありがとうございました!もっと色々なことを試してみましょう。こちらが別のログです。 私はRGB888にこだわりたかったのです。ARGB8888の方がこの用途に適している理由は何かありますか?いつかアルファ版を試してみようかな。 CTRLDESCL5: 0xD8000260 リファレンスマニュアルで確認したところ、BPP設定はビット27〜24で、その「8」はRGB888にうまく入力したことを示しています。最後のバイトは無関係に見え、アルファ設定は無害にずれているように見える。 画面出力は異なって見えるが、修正されていない。もしかしたら改善されたのかも?包み込むようなデザインは健在だが、以前ほど攻撃的な印象ではない。 ピクセルクロックの速度を上げる実験もしてみましたが、効果があるのか悪いのかは分かりません。 もっと動画設定を変えてみることはできますか?25%のHsync設定はここではかなり強力だと思っていたのですが、考えてみれば、これまでこのような設定をしたことがなかったのです。どのような要素が、その場所を特に優れたものにするのでしょうか?Vsyncも関係ありますか?LT8918ブリッジもこれらの設定入力が必要ですが、それも管理できます。入力する数字は推測するしかないのでしょうか? ドライバーはJD9365DA-H3です。参考になれば。タッチスクリーンが付いているという奇妙なパッケージもありますが、私は特に問題ありません。 Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun こんにちは、 @davidpspeedtech さん。 最新情報ありがとうございます!しかし、問題は、設定の一部に一貫性がないことです。 0xD9000260 → ハードウェアにラッチされたフォーマットはARGB8888(32ビット/ピクセル)です。 したがって、stride = 384(=128×3, RGB888)を設定しても、ハードウェアは1行あたり128×4 = 512バイト/行→ずれを取り出し、バッファを越えて読み込み、アンダーランします。 毎回ストライドまたはBPPマクロのみを変更しましたが、ハードウェアは実際には .pixelFormat に従い、ARGB8888のままでした。4つの値は決して一貫していませんでした。 それらをすべて32ビットARGB8888またはRGB888として一度に統一してください。   #define SMALL_LAYER_0_BPP 4U #define SMALL_LAYER_0_STRIDE (SMALL_LAYER_0_WIDTH * 4) /* = 512 */ uint8_t smallLayer0_Buffer0[256][512]; .pixelFormat = kLCDIFV2_PixelFormatARGB8888、 .strideBytes = SMALL_LAYER_0_STRIDE, /* 512、3200ではありません */   CTRLDESCL3 は現在 0x200 (512) を読み取っているはずです。32ビットフレームバッファと24ピンRGB888出力は独立しているため、24ピンリンクに3バイトバッファは必要ありません。 また、これら3回線はeLCDIFビット定義を使用しています。LCDIFv2にはRUNビットがなく、これが制御状態を乱すことがあります。   LCDIFV2->CTRL &= ~LCDIF_CTRL_SFTRST_MASK; LCDIFV2->CTRL &= ~LCDIF_CTRL_CLKGATE_MASK; LCDIFV2->CTRL |= LCDIF_CTRL_RUN_MASK;   Gavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.png 標準APIのみを使用して操作してください。 その他の点について確認させてください。 ストライドは画面幅ではなく、RAMバッファ幅に基づいて計算されます。これは正しいです。 背景色はレジスタ生成(メモリフェッチなし)であるため安定しており、出力パスが正常であることが証明され、障害がレイヤーフェッチパスにあることが特定されます。 原色と二次色の間でカラーバッファがちらつく現象(「まるでバイトが失われたかのよう」)は、まさにアンダーランによってバイトが失われていることが原因です。フォーマットが統一されれば、この現象は解消されるはずです。 帯域幅はボトルネックではない(OCRAM、128幅)。それでもアンダーランが解消されない場合は、ピクセルクロックを下げるか、HBP/HFPを上げて確認してください。 Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun いや、それでは解決しない。実際、ストライドがRGB888の場合は128*3でも、ARGB8888の場合は800*4に設定して画面全体をRAMに収めようとしても、出力は画面の端で歪みが生じる点でかなり似ており、アンダーランエラーが発生します。ファイル内のテキストだけでなく、さまざまな設定を試してみました! #define SMALL_LAYER_0_HEIGHT 256U #define SMALL_LAYER_0_WIDTH 128U #define SMALL_LAYER_0_BPP 3U /* RGB888 */ #define SMALL_LAYER_0_STRIDE (SMALL_LAYER_0_WIDTH*SMALL_LAYER_0_BPP) /*384*/ ~デバッグ出力~ CTRLDESCL3: 0x 180 (ピッチ/ストライド = 384バイト) これもまたうまくいかない。 でも、レイヤー0のストライド設定はRAMバッファ幅に基づいて本来ならLCD画面幅ではなく、右? LT8918へのインターフェースは24ピンのパラレル接続なので、本来RGB888であるべきです。DMAか何かが処理速度に追いついていないのではないかと心配になることもありますが、これはバッファサイズが小さいためSRAM_OC1が不足している状態です。おそらくRGB565も、最上位ビットがRGBピンで正しく出力できるので、似たような出力を持つかもしれません。モノクローム作品にも挑戦してみようかな。 サンプルコードを見ると、RGB888のBPPを3ではなく4に設定している箇所があり、他にも間違いを犯している可能性があります。 「背景領域」を別のレイヤーに配置し、別のメモリにバッファリングする必要があるのでしょうか?背景設定が正しく機能し、設定した単色で出力色が安定している点が気に入っています。白色以外のRAMバッファを使った実験では、画面が原色(RGB)と二次色の間でちらつくことがあり、まるで個々のバイトが失われたかのような現象が見られる。 Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun こんにちは、 @davidpspeedtech さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます! ご提供いただいた添付ファイルを確認しましたが、一部の設定を調整する必要があるかもしれません。 CTRLDESCL3: 0x00000C80 (ピッチ/ストライド = 3200バイト) #define SMALL_LAYER_0_BPP 3U /* RGB888 */ #define SMALL_LAYER_0_STRIDE (128 * 3) /* = 384 バイト */ uint8_t smallLayer0_Buffer0[256][384]; --> CTRLDESCL3にプログラムしたピッチ(3200バイト)は実際のバッファレイアウトと一致しません。バッファはRGB888で128×256なので、各行は128×3=384バイトです。   PITCH = 3200の場合、LCDIFv2は1行あたり3200バイト進み、384バイトではなく、各行ごとに有効なデータを大きく超えて到達します。このたった一つの不一致が、ご覧になっている両方の症状を引き起こすのに十分です。各行の開始アドレスが間違っていると画像が歪んだりずれたりし、各行で約8倍もの(しかも無効な)データがフェッチされると出力FIFOが不足し、アンダーランエラーが発生します。   レイヤー記述子をバッファと整合させてください。 CTRLDESCL3 (PITCH) = 384 (0x180)、つまりSMALL_LAYER_0_STRIDE = 128 * 3。 バッファのベースアドレスは64バイト境界にアラインされます。キャッシュ不可のままにするか(現在の設定は正しいです)、表示前にDキャッシュをクリアしてください。 よろしくお願いします、 ギャビン Re: RT1172 LT8918 LCD parallel LCDIFV2 small layer + background underrun こんにちは、 @davidpspeedtech さん。 記述子は自己整合的になりました: CTRLDESCL5=0xD8000260 (BPP=8=RGB888)、CTRLDESCL3=0x300=768=256×3。おっしゃる通りです。 しかし、根本的な不一致は依然として存在しており、低いクロック周波数によって覆い隠されているだけである。「行ごとに色が変わる、まるで1バイトが失われたかのようだ」という証拠は、メモリダンプがすべて 0xFFFFFFFF であり、センターピクセルが1ピクセルを単一の32ビットワードとして読み取っていることです。つまり、ハードウェアが3バイトをフェッチしている間も、コンテンツは依然として32ビット/ピクセルです。白は各バイトに0xFFされるため隠れています。緑は1行あたりにドリフトします。 ピクセルクロックを下げるとアンダーランは解消されますが、それはOCRAMが遅いからではありません(OCRAMは高速であり、オンチップメモリがボトルネックではありません)。アンダーランは、AXIマスターとしてのLCDIFv2のフェッチスループットに依存します。リフレッシュを~13.5 Hz(18.85 MHz÷ 1000×1400)に下げ、取っ取り要求を3〜4×減らしたので止まりますが、これはパネルの最低限値より低いです。 アンダーランせずに速く走るには、以下の方法が役立つかもしれません。 エンドツーエンドに切り替えARGB8888: .pixelFormat=ARGB8888 、BPP=4、stride=256×4=1024、バッファは4バイト/ピクセルで、ピクセル書き込みコードが32ビットワードを書き込むことを確認してください。理由は2つあります。(a)既存の32ビットコンテンツと一致するため、緑色の問題を修正できます。(b)RMノートに記載されているRGB888はバス上で長さ15のバーストを発行しますが(効率が悪く、アンダーランが発生しやすい)、ARGB8888は32ビットにアラインされ、長さ16のクリーンなバーストを使用します。緑色のダンプで確認してください。行ごとにずれがなく、きれいな繰り返しになっているはずです。 LCDIFv2のb_clk(クロックのルート)を上げて、ピクセルクロックを22Hz以上に復元してください。これが速度を上げるための正しい方法であり、クロックを下げることではありません。LCDIFv2はeDMAを使用しないため、「DMA優先度の上昇」は適用されません。利用可能なレバーはb_clk、バースト長、未処理リクエスト数、そしてTHRES動的優先度閾値です。 JD9365DA-H3パネルのデータシートに記載されているタイミング値を使用し(推測しないでください)、LT8918の入力タイミングをそれに合わせてください。~200の水平ブランキングでも問題ありません。ブランキングが大きいとアンダーランが緩和されますが、htotalが上がり(より高いピクセルクロックが必要)、トレードオフとなります。ルート修正は高いb_clkです。Vsync/垂直ポーチはパネルと一致させる必要がありますが、ラインごとのアンダーランにはほとんど影響しません。 よろしくお願いします、 ギャビン
記事全体を表示
S32K314 HSE設置に関する問題 助けてください!公式デモプロジェクトをベースにHSEファームウェアインストーラを作成しましたが、2回リセットした後、HSEインストールアドレス0x007E0000にデータがありません。これはHSEのインストールが失敗したということでしょうか?S32のバージョンは3.6.8で、チップは...S32K314、RTDバージョン7.0.1 1131_0-1788767775138.png1131_0-1788767775138.png これはldファイルです。 1131_1-1788767805874.png1131_1-1788767805874.png これは書き換えられたIVTベクトルです。 1131_2-1788767830677.png1131_2-1788767830677.png 1131_3-1788767849116.png1131_3-1788767849116.png 1131_4-1788767872384.png1131_4-1788767872384.png 最後に、HSEインストールデモプロジェクトを添付しました。 回复: S32K314 HSE 安装问题 @VaneBこんにちは ご提案に従ってリンカー ファイルを修正し、ivt.c ファイルのすべてのエントリをコメントアウトしました。プログラムを 2 回再起動した後、デバッグ モードで status = Hse_Ip_GetHseStatus(0u) の状態を確認しました。ステータス値は 1001 0110 0000 でしたが、9 番目のビットが 0 だったので、HSE が正常にインストールされなかったことを示しています。さらに、バージョン情報も取得できませんでした。srvResponse = Hse_Ip_ServiceRequest(0u, u8MuChannel, &request, &pHseSrvDesc) の戻り値は 0xaa55a11e です。 次のように 1131_1-1788838145743.png1131_1-1788838145743.png 1131_2-1788838165453.png1131_2-1788838165453.png 1131_3-1788838180700.png1131_3-1788838180700.png 1131_4-1788838213520.png1131_4-1788838213520.png Re: S32K314 HSE 安装问题 こんにちは@杨工1131 いくつか気づいた点があります。 リンカファイル内のコメントによると、HSEファームウェアはブロック0に配置されるべきです。しかし、現在HSE_BINARYに割り当てられているアドレスはブロック1に属しています。次のように設定する必要があります HSE_BINARY (R) : ORIGIN = 0x00400000 PFlash領域はブロック1から開始する必要があります。 int_pflash : ORIGIN = 0x00500000, LENGTH = 0x00300000 - __HSE_CODE_SIZE /* 4096KB - __HSE_CODE_SIZE (sBAF + HSE) */ 提案として、ハードコードされたアドレスを使う代わりに、HSE_FW_ADDR を次のように定義することができます。 #define HSE_FW_ADDR (__HSE_BIN_START) 別途ivt.cファイルを作成する必要はありません。画像ベクトルテーブル構造は、 Project_Settings → Startup_Code → startup_cm7.sで既に定義されています。 IVTに関しては、S32K3xxリファレンス・マニュアル改訂版12のセクション32.5.3を参照すると、CM7_2開始住所の後に続く記述は以下の通りです。 .long 0xffffffff /* Offset 0x20: Reserved */ .long LC_CONFIG_ADDR /* Offset 0x24: Lifecycle configuration pointer */ .long CM7_3_VTOR_ADDR /* Offset 0x28: CM7_3 Start address */ .long HSE_FW_ADDR /* Offset 0x2C: Reserved */ コードについては、例と同じ構造を使っているので、その部分で問題はないと思います。 BR、VaneB
記事全体を表示
S9KEAZN64AMLH FIT値の確認 本プロジェクトでは、MCU S9KEAZN64AMLHを選定しました。車両メーカーは、下図に示すようなチップの適合パラメータを必要とします。ご確認の上、ご返信をお願いいたします。サポートありがとうございます。 mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value こんにちは、 @mengfanpeng さん、 投稿ありがとうございます。 この情報は、公共の場で共有するのに適していません。後ほど、プライベートメールでお送りします。 BR セレステ Re: Confirmation of S9KEAZN64AMLH FIT value 自動車用半導体半導体でFIT(Failures In Time)パラメータの要請(例えばNXP S9KEAZN64AMLH(Kinetis EAシリーズ、ARM Cortex-M0+)に対応する場合、NXPのような半導体メーカーは通常、標準部品データシート内で生のFITレートを直接公開しません。代わりに、これらの信頼性指標は業界標準(例えばAEC-Q100)によって管理され、NXP製品品質報告書(PQR)、AEC-Q100資格報告書、特定のお客様品質要求書(PQA)などの公式文書を通じて提供されます。 Re: Confirmation of S9KEAZN64AMLH FIT value FITは一般的なテストデータであり、NXPが社内で所有しています。OEMから関連データのリクエストがあった場合、そのデータはテスト環境に限定されているため、あくまで参考情報としてのみ提供されます。
記事全体を表示
P2020 device status/behavior if VDD falls below lower limit due to ripple I would like to know about status/behavior of P2020 processor in case VDD falls below lower limit voltage due to ripple etc. According to Table 3. Recommended Operating Conditions in P2020 Hardware Spec (Doc#: P2020EC), the recommended value for VDD, AVDD_xxxx, SVDD_SRDS and XVDD_SRDS is “1.05 ± 50 mV”. It means that the lower limit voltage is 1.00 V. Could you please let me know about possible P2020 device status/behavior if the lower limit of the ripple voltage falls below the specified minimum voltage of 1.00V ?  (For instance, center voltage of VDD = 1.01V, but the lower side of the ripple voltage goes 0.99V (below 1.00V)) Is there no problem for proper operation of the device if center voltage of VDD keeps higher or equal to 1.00V ? Will there be any operation/damage risks even with ripple voltage ? Please advise. Thank you in advance. Re: P2020 device status/behavior if VDD falls below lower limit due to ripple Hello,   The P2020 Hardware Spec (Doc#: P2020EC) Table 3 specifies VDD, AVDD_xxxx, SVDD_SRDS, and XVDD_SRDS as 1.05 ± 50 mV, meaning the valid operating range is 1.00 V (min) to 1.10 V (max). This is a Recommended Operating Condition, not an Absolute Maximum Rating. The critical point is: the specified minimum voltage of 1.00 V applies to the instantaneous voltage at the device pins — not just the DC center point. Ripple is part of the actual voltage the device sees, and the device is tested and characterized only within the specified range. Risks When Ripple Dips Below 1.00 V Even if the center (DC) voltage is at or above 1.00 V, allowing the ripple trough to fall below 1.00 V constitutes operation outside the Recommended Operating Conditions. NXP's position on this, consistent across QorIQ and related processor families, is: Functional/Operational Risk: When VDD momentarily drops below the minimum, the processor's internal logic may not have sufficient drive strength or timing margin to operate correctly. This can manifest as: Incorrect instruction execution Data corruption (e.g., memory miscompare errors) Unpredictable behavior in critical timing paths A directly analogous NXP case involving a related QorIQ processor (P1013) confirmed: "There is a potential risk of functional issues when running [the device] at [a voltage near the limit], as this value represents the customer's configured set point. Normal voltage tolerance, ripple, or transient behavior could result in the voltage exceeding [or falling below] this level." The "Center Voltage ≥ 1.00 V" Argument Is Not Sufficient: The device does not "average" the supply voltage. Digital logic operates on instantaneous voltage. During the ripple trough (e.g., 0.99 V in your example), the device is genuinely operating below spec, even if only for a fraction of a switching cycle. This can cause setup/hold time violations in internal flip-flops, leading to functional errors. No Permanent Damage Expected for Small, Brief Excursions: For a small ripple excursion (e.g., 10 mV below the minimum, at typical switching frequencies), permanent physical damage to the device is unlikely — the voltage is still well above the absolute maximum ratings floor. However, functional correctness is not guaranteed, and NXP does not support or characterize operation in this condition. Reliability/Longevity: For the P2020 specifically, operating at the lower edge of the voltage range (rather than above it) is generally less of a long-term reliability concern than operating above the maximum. However, repeated or sustained operation outside spec is neither recommended nor supported. NXP's standard guidance, confirmed across multiple QorIQ and related processor support cases, is: "Operating devices outside of specification is neither recommended nor supported." The entire voltage waveform — including ripple — must remain within the specified 1.00 V to 1.10 V window at the device pins during normal operation.   Regards
記事全体を表示
Deadtime Correction Hi NXP Community, I am looking for some clarification regarding the PWM-X deadtime correction feature. From the documentation, I understand that PWM-X can modify the PWM pulses based on the current/load condition. However, I am not clear about how the PWM pattern is generated and how the required feedback signal is connected and routed. In my application, the switches and current-sensing circuitry are external to the MCU: Is the sensed current signal expected to be connected directly to an MCU pin? Or should it first go through LPCMP and then be internally routed to PWM-X through TRGMUX or another internal connection? What is the expected signal path and configuration for this feature? I have attached an image from the NXP reference design/documentation showing the slightly decaying output waveform obtained across the load. What I am particularly trying to understand is the PWM pulse pattern used to generate this waveform. The waveform shown in the reference design is the resulting waveform at the load/power stage. However, the PWM signal generated by the MCU will pass through the gate driver and switching stage, so the PWM signal itself will not have the same shape as the waveform shown. PWM-X generated pulses → gate driver/power stage → resulting waveform across the load Specifically, I would like to understand how PWM-X determines the pulse width/duty cycle and timing required to obtain the shown output waveform, including how the deadtime correction is applied. Is there any reference design, application note, example code, or reference software where this PWM-X feature is implemented? An example showing the PWM configuration, pulse pattern, pin configuration, internal signal routing, and required external circuitry would be very helpful. FlexPWM Synchronization I also have a question regarding FlexPWM synchronization. Can the synchronization signal be generated internally by another peripheral, or does it have to originate from an external MCU pin? For example, can a signal generated by eMIOS be internally routed to the FlexPWM synchronization input? Any example or clarification regarding the internal routing/configuration would be very helpful. Thanks in advance. Best regards, Ganesh
記事全体を表示
P2020 设备在纹波导致 VDD 低于下限时的状态/行为 我想了解当 VDD 由于纹波等原因降至下限电压以下时,P2020 处理器的状态/行为。 根据 P2020 硬件规范(文档编号:P2020EC)中的表 3. 推荐工作条件,VDD、AVDD_xxxx、SVDD_SRDS 和 XVDD_SRDS 的推荐值为“1.05 ± 50 mV”。这意味着下限电压为 1.00 V。 请问当纹波电压下限低于规定的最小电压1.00V时,P2020设备可能出现的状态/行为是什么? (例如,VDD 的中心电压为 1.01V,但纹波电压的下限为 0.99V(低于 1.00V)) 如果VDD中心电压保持在1.00V或更高,这是否会影响设备的正常工作?即使存在纹波电压,是否也会有操作/损坏风险? 请指教。 提前谢谢您。 Re: P2020 device status/behavior if VDD falls below lower limit due to ripple 你好,   P2020 硬件规范(文档编号:P2020EC)表 3 将 VDD、AVDD_xxxx、SVDD_SRDS 和 XVDD_SRDS 指定为 1.05 ± 50 mV,这意味着有效工作范围为 1.00 V(最小值)至 1.10 V(最大值)。这是推荐运行条件,并非绝对最大额定值。 关键在于:规定的最小电压 1.00V 适用于器件引脚的瞬时电压,而不仅仅是直流中心点。纹波是设备实际电压的一部分,设备的测试和特性分析仅在规定的范围内进行。 当 Ripple 跌破 1.00 V 时的风险 即使中心(直流)电压达到或超过 1.00 V,允许纹波谷值低于 1.00 V 也构成在推荐工作条件之外的操作。恩智浦半导体(NXP)对此的立场,在QorIQ及相关处理器系列中是一致的: 功能/运行风险:当 VDD 瞬间低于最低值时,处理器的内部逻辑可能没有足够的驱动强度或时序裕量来正常工作。这可能表现为: 指令执行错误 数据损坏(例如,内存比较错误) 关键时序路径中出现不可预测的行为 NXP 的一个直接类似的案例涉及一款相关的 QorIQ 处理器 (P1013),该案例证实: “当[该设备]在[接近极限电压]下运行时,存在出现功能问题的潜在风险,因为该值代表客户配置的设定点。正常的电压容差、纹波或瞬态行为都可能导致电压超过[或低于]该水平。” “中心电压≥1.00V”的论点并不充分:该设备不会对电源电压进行“平均”。数字逻辑电路依靠瞬时电压运行。在纹波谷(例如,您示例中的 0.99 V)期间,即使只是开关周期的一小部分,该器件也确实在低于规格的条件下运行。这会导致内部触发器建立/保持时间违例,从而导致功能错误。 对于小幅、短暂的波动,预计不会造成永久性损坏:对于小幅纹波波动(例如,在典型开关频率下,低于最小值 10 mV),不太可能对器件造成永久性物理损坏——电压仍然远高于绝对最大额定值下限。但是,功能正确性无法保证,NXP 不支持或描述在这种情况下运行的情况。 可靠性/寿命:对于 P2020 而言,在电压范围的下限(而不是上限)运行通常比在上限以上运行的可靠性问题要小。但是,不建议也不支持在超出规格范围的情况下反复或持续操作。 NXP 的标准指导原则(已在多个 QorIQ 及相关处理器支持案例中得到证实)是: “不建议也不支持在规格范围外操作设备。” 在正常工作期间,器件引脚上的整个电压波形(包括纹波)必须保持在规定的 1.00 V 至 1.10 V 范围内。   此致
記事全体を表示
Confirmation of S9KEAZN64AMLH FIT value The project has selected MCU  S9KEAZN64AMLH. Now, the vehicle manufacturer requires the chip FIT parameters, as shown in the figure below. Please help confirm and reply. Thank you for your support. mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value Hello @mengfanpeng , Thanks for your post. This information is not suitable for sharing in a public community. I will send it to you via private email shortly. BR Celeste Re: Confirmation of S9KEAZN64AMLH FIT value FIT is general test data and own by NXP internally. If OEM request related data,it is just for reference since the data is limited to test enviroment. Re: Confirmation of S9KEAZN64AMLH FIT value When dealing with automotive semiconductor requests for FIT (Failures In Time) parameters—such as for the NXP S9KEAZN64AMLH (Kinetis EA series, ARM Cortex-M0+)—semiconductor manufacturers like NXP typically do not publish raw FIT rates directly inside standard component datasheets. Instead, these reliability metrics are governed by industry standards (like AEC-Q100) and are provided via official documents such as NXP Product Quality Reports (PQRs), AEC-Q100 qualification reports, or specific customer quality requests (PQAs).
記事全体を表示
lpc4078 EEPROMページ消去に関する説明が必要 私はLPC4078とMCUXpressoを使用して、EEPROMに値を保存する実験を行っています。 ページ全体を消去せずに、ページの中央に数バイトのデータを書き込みたい。 データシートを見ると、ページレジスタに書き込むデータを書き込んだ後、さらに不揮発性メモリにプログラムする必要があり、それは消去/プログラム操作によって行われると記載されている。 消去/プログラム操作は、ページ全体を消去するのか、それとも新しいデータが格納されているページ領域だけを消去するのか、また、どのようにしてそれを判断するのか?- 消去/プログラム用のアドレス設定では、6 つの lsb が無視されるため、ページのみが認識されます。 UM10562.pdfには、このマターについて明確な記載はありません。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required 該当プロジェクトを含むワークスペースを添付します。LPC4078上でlpc-link2デバッガを使って実行しました。 (セミホスティングを動作させるのが面倒だったので、ブレークポイントを使ってデータを検査しました。) Re: lpc4078 eeprom page erase clarification required こんにちは、 @alex_conway さん。 LPC4078 EEPROMの場合、最小消去/書き込み単位は1ページ(64バイト)です。したがって、消去/プログラム操作を行うたびに、ページ全体が消去されます。数バイトだけ書き込みたい場合は、まずページ全体を読み込み、次に必要なバイトを変更し、最後にページに対して消去/書き込み操作を実行してください。そちら側でもテストしてみてください。   よろしくお願いします。   BR アリス Re: lpc4078 eeprom page erase clarification required こんにちは、アリスさん。 私の実験結果はそれとは異なることを示している。 まずは手始めに、lpc_board_ea_devkin_4088ライブラリとperiph_eepromデモプロジェクトを使って小さなプログラムを作成しました。 EEPROMの1ページを消去して、それを読み戻します。驚いたことに、結果は0xFFではなくすべて'\0'だった。 次に、そのページのアドレス0に「ABCDEFG\0」を書き込み、ページを読み戻します。「ABCDEFG\0」を受け取ります 次に、そのページのアドレス7に「ABCDEFG\0」を書き込み、ページを読み戻します。「ABCDEFGABCDEFG\0」を受け取ります これはすべて予想通りだったが、2点だけ例外があった。 1. EEPROMを消去した後、0を読み取る 2. Chip_EEPROM_Write() の実装を見ると、読み出し-変更-消去-書き込みのシーケンスがないように見えます。Chip_EEPROM_WritePageRegister と Chip_EEPROM_EraseProgramPag があるだけです。 だから私はこの質問をしたのです。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required printf文字列にすべて改行を追加したら、セミホスティングがうまく動作するようになりました!また、私が言ったことすべてをより明確に裏付ける証拠もあります。 消去するとEEPROMが0x00に設定されます このコードは、読み取り→変更→消去→書き込みのシーケンスを実行せず、消去→書き込みのみを実行します。 LPC4078は、消去時に書き込みが行われた場所のみを消去するようです。 この点について、ぜひとも明確な説明をいただきたいです。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required 「エスカレーション」という言葉が何を意味するにせよ、NXPからはこれに関してそれ以上の回答は得られていない。 まだ確認が必要です。 Re: lpc4078 eeprom page erase clarification required こんにちは、 @alex_conway さん。 ご返信ありがとうございます。返信が遅くなり申し訳ありません。 残念ながら、以前はコミュニティスクリプトが壊れていたため、お客様からの返信が内部システムでのCASE更新通知を発生させませんでした。遅れてしまい、誠に申し訳ございません。 LPC4078上のEEPROMに関しては、ユーザーマニュアルによると、実際のEEPROMブロックとの通信はすべて64バイトのページバッファを通じて行われます。したがって、EEPROM運用がユーザーマニュアルに記載された要件に従うことを必ず確認してください。 Alice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.pngアリス_ヤン_1-1788510957201.png Alice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.pngアリス_ヤン_0-1788510947469.png 現時点では、EEPROMがこれらの要件に従ってアクセスされない限り、問題があるかどうか判断できません。 よろしくお願いします。 BR アリス Re: lpc4078 eeprom page erase clarification required こんにちは、アリスさん。 私はeeprom_17xx_40xx.hの関数を使用しています。および eeprom_17xx_40xx.c(NXP社提供、添付プロジェクトに含まれています) Chip_EEPROM_Write() 関数は、Chip_EEPROM_WritePageRegister() 関数を呼び出し、続いて Chip_EEPROM_EraseProgramPage() 関数を呼び出します。 Chip_EEPROM_WritePageRegister()関数は、下位6ビットのシフトとブランキングを処理するChip_EEPROM_SetAddr()関数を使用してEEPROMアドレスを設定します。 次に、Chip_EEPROM_WriteData() 関数を使用して、データバイトが EEPROM 書き込みデータレジスタ (WDATA) に書き込まれます。 Chip_EEPROM_EraseProgramPage() 関数は、Chip_EEPROM_SetAddr() 関数を使用してページ アドレスを設定し、消去/ページ プログラム ビットを有効にして、プログラミングが完了するまで待機します。 ページ内の既存のEEPROMデータを読み込んでページを読み取って、ページを読み書き・修正・書き込みを行うコードは見当たりません。 しかし、私のプロジェクトで実証したように、EEPROMページの消去はページ全体を消去するのではなく、書き込みデータレジスタに新しいデータがロードされたアドレスのみを消去するようです。 よろしくお願いします。 アレックス
記事全体を表示
确认 S9KEAZN64AMLH FIT 值 该项目选择了 MCU S9KEAZN64AMLH。现在,车辆制造商需要芯片的 FIT 参数,如下图所示。请帮忙确认并回复。感谢您的支持。 mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value 你好@mengfanpeng , 感谢你的帖子。 这些信息不适合在公共社区分享。我稍后会通过私人邮件发送给你。 BR 塞莱斯特 Re: Confirmation of S9KEAZN64AMLH FIT value 在处理汽车半导体对 FIT(故障率)参数的要求时——例如 NXP S9KEAZN64AMLH(Kinetis EA 系列,ARM Cortex-M0+)——像 NXP 这样的半导体制造商通常不会在标准元器件数据手册中直接发布原始 FIT 率。相反,这些可靠性指标受行业标准(如 AEC-Q100)的约束,并通过官方文件(如 NXP 产品质量报告 (PQR)、AEC-Q100 认证报告或特定客户质量要求 (PQA))提供。 Re: Confirmation of S9KEAZN64AMLH FIT value FIT 是通用测试数据,归 NXP 内部所有。如果OEM厂商要求提供相关数据,由于数据仅限于测试环境,因此仅供参考。
記事全体を表示
S32K314 HSE 安装问题 求助!我参考官方演示项目编写了HSE固件安装程序,但执行两次复位后,HSE安装地址0x007E0000处没有任何数据。这是否意味着HSE安装失败了?S32 版本为 3.6.8,芯片为 S32K314,RTD 版本为 7.0.1 1131_0-1788767775138.png1131_0-1788767775138.png 这是 ld 文件 1131_1-1788767805874.png1131_1-1788767805874.png 这是重写后的IVT向量 1131_2-1788767830677.png1131_2-1788767830677.png 1131_3-1788767849116.png1131_3-1788767849116.png 1131_4-1788767872384.png1131_4-1788767872384.png 最后,我附上我的 HSE 安装的demo项目。 回复: S32K314 HSE 安装问题 @VaneB 你好 我根据你的建议修改修改了链接器文件,并将ivt.c文件全部注释掉,重新启动程序两次过后,通过调试模式观察status = Hse_Ip_GetHseStatus(0u)的状态status的值 1001 0110 0000,但是第9位为0,说明HSE并未安装成功?而且获取不到任何版本信息,srvResponse = Hse_Ip_ServiceRequest(0u, u8MuChannel, &request, &pHseSrvDesc),srvResponse 的返回值为0xaa55a11e; 如下 1131_1-1788838145743.png1131_1-1788838145743.png 1131_2-1788838165453.png1131_2-1788838165453.png 1131_3-1788838180700.png1131_3-1788838180700.png 1131_4-1788838213520.png1131_4-1788838213520.png Re: S32K314 HSE 安装问题 嗨@杨工1131 我有几点看法: 根据链接器文件中的注释,HSE 固件应该放在 Block 0 中。但是,当前分配给 HSE_BINARY 的地址属于 Block 1。应该配置为 HSE_BINARY (R) : ORIGIN = 0x00400000 PFlash 区域应从 Block 1 开始: int_pflash : ORIGIN = 0x00500000, LENGTH = 0x00300000 - __HSE_CODE_SIZE /* 4096KB - __HSE_CODE_SIZE (sBAF + HSE) */ 建议不要使用硬编码地址,而是将 HSE_FW_ADDR 定义为: #define HSE_FW_ADDR (__HSE_BIN_START) 无需创建单独的 ivt.c 文件。图像矢量表结构已在Project_Settings → Startup_Code → startup_cm7.s中定义。 关于 IVT,如果您参考 S32K3xx 参考手册第 12 版第 32.5.3 节,CM7_2 起始地址之后的条目如下: .long 0xffffffff /* Offset 0x20: Reserved */ .long LC_CONFIG_ADDR /* Offset 0x24: Lifecycle configuration pointer */ .long CM7_3_VTOR_ADDR /* Offset 0x28: CM7_3 Start address */ .long HSE_FW_ADDR /* Offset 0x2C: Reserved */ 关于代码,我看到你使用了与示例相同的结构,所以我认为这部分不会有任何问题。 BR,VaneB
記事全体を表示