Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
S32K312:WKUP中断未触发 我已将PTB2配置为WKUP输入引脚,并将WKUP 通道 8映射到 PTB2。WKUP 模块配置看起来正确;但是,WKUP 中断没有被触发。 之前,我将同一引脚配置为EIRQ输入,并且中断已成功触发,证实该引脚和外部信号功能正常。 问题: PTB2 配置为 WKUP 输入。 WKUP 8频道映射到PTB2。 未收到 WKUP 中断。 同样的硬件配置在 EIRQ 配置下可以正常工作。 请帮忙确定是否存在任何额外的 WKUP 配置要求、依赖项或已知限制,这些都可能导致无法生成中断。 Wkpu_Ip_Init(0U, &Wkpu_Ip_Config_PB); /* INT2:唤醒触发器。*/ Wkpu_Ip_EnableInterrupt(0, Wkpu_Ip_ChannelConfig_PB[2U].hwChannel); Wkpu_Ip_EnableNotification(Wkpu_Ip_ChannelConfig_PB[2U].hwChannel); Re: S32K312: WKUP Interrupt Not Triggering 嗨@DiaDev , S32K3 除了提供约 60 个外部唤醒源外,还提供了 4 个内部唤醒源,在配置通道时必须考虑这些内部唤醒源;这意味着,偏移量需增加 4: PTB2 是唤醒垫 [8],加上四个内部源,它将是通道 12。请更改此配置并测试 WKPU 是否被触发。 此致, 朱利安
查看全文
S32N55 HSE2 CRS 安全调试:SDC-600 TX FIFO 在传输 20 字节后停止 你好, 关于 CRS 功能域安全调试身份验证问题的后续讨论 之前的帖子中讨论过(“S32N55 HSE2 CRS 功能域身份验证”) “尚未完成”,我想报告一项新的、更具体的发现。 我认为这指出了问题的根源。单独发布此内容 建议。 设置: - S32N55、HSE2、CRS 功能域 (APP_CHALLENGE)、劳特巴赫 TRACE32 / SDC-600 - 认证流程:COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE (StartCmd) -> 接收挑战 -> 发送 ProofProvCmd (debugSignalMap(4B) + appChallengeAuth(16B) 通过 AES-CMAC) 发现: 发送 debugSignalMap(4B) + appChallengeAuth(16B) = 20 字节后 通过 ProofProvCmd 数据包获取主机 SDC-600 TX FIFO 状态的总数 寄存器(MU 基址 + 0xD2C 处的 bit[7:0])不再报告可用空间。 换句话说,HSE2 似乎停止消耗 SDC-600 通道的电量。 正好是这 20 字节的边界。主机的底层 Send() 例程 它在一个没有超时的忙等待循环中轮询此状态寄存器,因此 此处无限期封锁。 无论 16 字节之后是什么,这种行为都保持一致。 appChallengeAuth: - 是否添加额外的填充字节(以填充) debugAuthProof 联合体(转换为 32 字节)或者不再发送任何内容并继续 直接跳转到 FLAG_END,FIFO 停止在相同的 20 字节处进行数据清空。 观点。这表明问题不在于数据包长度/帧结构。 不匹配,但 HSE2 在以下情况下立即停止为该通道提供服务: 收到 16 字节的 appChallengeAuth。 问题: 这是 APP_CHALLENGE 流程的预期行为吗(例如,HSE2 是否如此) 在此处暂停,等待主机执行其他操作,然后才会继续。 继续排干河道),还是说这表明 到目前为止接收到的数据包内容(debugSignalMap 或 appChallengeAuth)在 HSE2 端被拒绝/格式错误? 供参考: - FSS 功能域 (FSS_CHALLENGE) 身份验证具有等效流程 使用相同的 Send() 函数成功完成(AUTHSTATUS=0xBBB)。 例行程序和 SDC-600 基座,发送 4B 信号映射 + 32B 响应 没问题。 - CRS 功能域 (APP_CHALLENGE) 目标 = HSE_DEBUG_DOMAIN_APP (0x1B), 已根据 hse_srv_debug_auth_protocol.h 进行确认。 能否提供一些关于 HSE2 在 APP_CHALLENGE 阶段的期望方面的指导? 非常感谢您的反馈。 谢谢, Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 陈银你好, 感谢您的指导和对剧本的审阅。 我们将等待您就剧本问题提供的详细反馈,并会 一旦修复程序准备就绪,请立即应用。 为了阐明我们目前相对于两阶段方法的立场。 您建议:我们报告的挂起问题(SDC-600 TX FIFO 不再存在) debugSignalMap + appChallengeAuth) 之后的排水操作恰好发生在 第一阶段结束——具体来说,就是在发送之后。 在能够继续之前,我们需要 hseDebugAuthorizeProofProvCmd_t hseDebugCardCmd_t 完全不存在。因此,我们尚未确认第一阶段。 端到端执行成功;序列目前停滞在 正是这一点,甚至在达到第二阶段(CardCmd)之前。 收到您的反馈后,我们将: 1. 将修改后的剧本应用到剧本中。 2. 按照分阶段的方法进行重新测试——记录响应 从 hseDebugCommStartCmd_t 到每个命令 单独检查 hseDebugAuthorizeProofProvCmd_t,并确认 在继续进行下一步之前,需要计算每一步的预期值。 3.只有在第一阶段完成后才能继续验证 hseDebugCardCmd_t。 已确认完成。 4. 请汇报更新后的日志。 再次感谢您一直以来的支持。 此致, 埃迪 Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 你好, @EddiePark 感谢你的帖子。 1. 我们已经审阅了您分享的原始剧本,发现存在一些问题,我会尽快将反馈意见发送给您。 在审查过程中,我们发现了一些问题,这些问题似乎与已记录的程序不符。因此,我建议仔细比较实际数据包交换与 HSE FW 接口注释中描述的要求。 2. 修复脚本中发现的问题后,进行测试并检查日志。 3. 如果问题仍然存在,我建议将调试过程分为两个阶段,以帮助隔离问题。 首先,验证从 hseDebugCommStartCmd_t 到 hseDebugAuthorizeProofProvCmd_t 的授权序列是否成功完成。记录每个命令的响应,并在进行下一阶段之前确认返回值是否符合预期。 第二阶段,重点关注 hseDebugCardCmd_t。根据 HSE FW 接口文档中提供的评论,我建议严格验证此步骤中涉及的所有数据包,并确认其内容和顺序与文档中规定的要求相符。 BR 陈银 Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 你好, @EddiePark 上周我也通过消息发送了它,因为你之前分享的剧本是通过私信发送的。您可以在消息框中查看。 给您带来的不便,敬请谅解。 BR 陈银 Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 陈音你好 感谢您之前对 CRS APP 功能域脚本审查的回复。我们衷心感谢您对两阶段调试方法的指导。 由于我们尚未收到您提到的详细剧本反馈(“我会尽快把反馈发给您”),因此我们想跟进并确认一下进度。 为了准备接收您的反馈,我们已经: 1. 我们增强了 crs_auth.cmm 脚本中的日志记录功能,以支持您建议的两阶段方法: - 第一阶段(CommStart → ProofProv):添加了逐步响应日志记录,并对每个命令(AUTH_MODE_REQ、APP_CHALLENGE、ProofProv)进行 PASS/FAIL 验证。 - 第二阶段(CardCmd):准备根据 HSE FW 接口文档验证数据包内容和顺序 2. 准备详细的执行日志,捕获以下内容: - 每个命令的响应字节 - 生命周期状态解码(OEM_OPEN 与 OEM_CLOSED) - 身份验证模式确认 - 挑战接收验证 - ProofProv 响应状态(目前观察到 HSE2 在 ProofProv 后保持静默,这与返回 0x4A4A4A4A 的 FSS 功能域不同) 鉴于我方客户(42dot)的交货日期临近,请问您能否就以下方面提供建议: 1. 详细剧本反馈的大概时间是什么时候? 2. 在等待您的反馈期间,我们应该重点关注数据包结构或命令序列的哪些具体方面? 我们仍致力于解决此事,并非常感谢任何进一步的指导。 感谢您一直以来的支持。 此致, Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 你好, @EddiePark 感谢您的回复。 关于您之前的问题: 1. 确认是否需要为APP功能域传输ProofProv? - 完全不要为 APP 发送 ProofProv(完全跳过 tx_response 调用)? - 或者发送证明文件但不等待回复(目前尝试过)? [备注]:第一阶段的ProofProv必须针对 APP 功能域发送。 2. ProofProv 之后脚本卡住的原因可能是什么?(如果仍然需要的话) [注释]: 在第 1 阶段发送 ProofProv 后,您应该读取 HSE FW 的响应,以检查调试过程是否正常工作(hseDebugAuthorizeProofProvResponse_t)。请确认该回复是否在预期之内。 BR 陈银 Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 您好, 平台:S32N55 (HSE2),通过 SDC600 / TRACE32 CMM 进行安全调试 功能域:APP(CRS) 认证模式:质询(AuthMode = 0) 我正在实现调试卡认证流程。挑战 -> 证明阶段正常工作:在 APP_CHALLENGE 之后,我收到一个 32 字节的挑战并进行计算。 appChallengeAuth = AES256-CMAC(key, challenge) // 16 字节 并将其发送到 hseDebugAuthorizeProofProvCmd_t。 我的问题与 CARD_REQUEST 阶段(hseDebugCardCmd_t / hseDebugCardInfo_t)有关。在我当前的脚本中,AuthTag 字段填充了与上面的 appChallengeAuth 相同的值(即根据接收到的挑战计算出的 CMAC)。信用卡验证失败。 我想确认一下信用卡请求中的 AuthTag 究竟需要签署的是什么: 1. 卡片 AuthTag 是否与 appChallengeAuth(对接收到的质询进行 CMAC 验证)的值相同? 或者 2. AuthTag 是否必须是基于 hseDebugCardInfo_t 结构(在同一请求中发送的卡信息)计算的单独 CMAC? 如果是(2),请您确认一下: - 进入 CMAC 的确切字节范围(包括整个结构体)。authKeyRef/保留密钥,或特定子集), - 当 numOfAllowedUids = 0 时,是否包含 uidList, - 用于 AES-CMAC 的 authScheme 值,以及它是否是签名数据的一部分, - 序列化结构的打包/字节序假设。 作为参考,我正在填充的结构如下: typedef struct { uint8_t authKeyRef; uint8_t reserved0[3U]; hseOid_t ownerId; // 16 字节 hseDebugCardAuthScheme_t authScheme; uint64_t enabledDebugDomainMap; // CRS = 位 22..26 -> 0x0000000007C00000 联盟 { hseDebugSignal_t debugDomainSignalList[HSE_MAX_NUM_OF_DEBUG_DOMAINS]; uint8_t reserved1[64U]; } debugDomainSignalList; uint8_t numOfAllowedUids; uint8_t reserved2[3U]; uint8_t uidList[HSE_MAX_UID_LIST_SIZE][HSE_UID_SIZE]; } hseDebugCardInfo_t; HSE FW API RM 似乎没有明确说明调试卡 AuthTag 是基于哪些数据计算的,所以我希望得到一个明确的答案。 谢谢! Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes 您好, 平台:S32N55 (HSE2),通过 SDC600 进行安全调试 (APBCOM @ DP:0x5BFF8000),由 TRACE32 CMM 驱动。 我已经为 FSS 功能域启用了安全调试身份验证(AUTHSTATUS = 0xBBB)。我现在使用完全相同的 SDC600 基本地址和相同的主机端 SEND 例程来启动 APP (CRS) 功能域,但我遇到了传输问题。 观察: - FSS 功能域:我可以通过 SDC600 传输 32 字节的有效载荷而不会出现任何停顿。 - APP(CRS)功能域:传输在正好 16 个字节后停止。 我的 SEND 例程将每个字节写入 TX 数据寄存器(基址+0xD20),并且在每次写入之前,都会等待 TX 状态寄存器(基址+0xD2C,低字节)的 FIFO 空闲空间: WHILE (Data.Long(&base+0xD2C) & 0x000000FF) == 0x00000000 ();等待 TX FIFO 空间 在 APP 功能域中,16 字节后,此状态将无限期地保持为 0(没有可用空间),即 HSE2 端似乎不会在 16 字节之后继续使用 TX FIFO。在 FSS 域上,相同的代码可以无停顿地传输 32 字节。 由于两个功能域的基本地址和 SEND 代码相同,因此这看起来像是 HSE2 何时/是否根据目标调试功能域清空 SDC600 RX(主机 TX)FIFO 存在差异。 问题: 1.什么因素决定了 HSE2 何时开始使用 APP(CRS) 功能域 的 SDC600 TX FIFO?是否存在必要的条件/握手(例如)读取 ProofProv 响应、状态位或 RX 使能)必须满足哪些条件,HSE2 才能在 APP 上消耗超过 16 字节? 2. FSS 和 APP 之间 SDC600 流控制/FIFO 消耗行为是否存在功能域差异? 3. 此设备上的 SDC600 TX FIFO 实际深度是多少?0xD2C[7:0] 是否是轮询“TX FIFO 空闲空间”的正确字段?应该使用哪一位? 4. 对于大于 APP 功能域 FIFO 深度的有效载荷,预期的主机发送序列是什么? 其他可能相关的背景信息: - 在 NOBLOCK 模式下发送 ProofProv (hseDebugAuthorizeProofProvCmd_t) 后,HSE2 确实返回了一个响应,我现在可以将其读取回来 (hseDebugAuthorizeProofProvResponse_t)。我读取到的 4 字节结果是 0x7A 0xB3 0x08 0x00 - 我也希望确认这是否表示 APP 功能域的 ProofProv 成功。 谢谢!
查看全文
FRDM-IMX95: SDカードから起動するとシリアル出力がない (プリインストールされたeMMCブートは正常に動作します) こんにちは、NXPコミュニティの皆さん、 私は機械工学と電気工学のバックグラウンドを持っていますが、複雑なシステムオンチップ(SoC)や組み込みオペレーティングシステムに深く取り組むのは今回が初めてです。 私のプロジェクトではFRDM-IMX95の開発ボードを使用しています。私の最終目標は、IPC(プロセス間通信)フレームワークを使用して、2つのオペレーティングシステムを並行して実行することです。 ボードは内部eMMCにプリインストールされたLinuxイメージを同梱していました。これは箱から出してすぐに完璧に動作し、ターミナルモニタープログラムでシリアル出力ログを完全に取得できます。 現在、公式の Starting Guide に従って、Windowsホストマシン上でUUU(Universal Update Utility)を使って標準のLinux BSPイメージをmicroSDカードにフラッシュしようとしています。 Windowsのコマンドプロンプトによると、UUUのフラッシュ処理は「SUCCESS」ステータスで完了します。私は以下の標準コマンドレイアウトを使用しました: ".\uuu.exe -b sd_all imx-boot-imx95-15x15-lpddr4x-frdm-sd.bin-flash_all imx-image-full-imx95evk.wic" 問題点:フラッシュに成功した後、ボードを電源を切り、物理的なブートスイッチをSDブートモードに設定し、SW1 [1:2]を11(オン/オン)に設定します。ボードの電源を入れ直しても、シリアルモニターは完全に空白のままです。テキスト出力やハードウェアの初期化は一切表示されません。 1. ブートチェーンの仕組みについて、私は根本的な誤解をしているのでしょうか?i.MX Linux ユーザーガイドによると、.wicはこのイメージには、ブートローダーイメージ(U-Boot)を含む、4つの必須要素すべてが含まれています。基本的なハードウェア構成ブロックはカードから読み込まれるはずなので、少なくとも最初のU-Boot SPLシーケンスがシリアルモニターに表示されるべきではないでしょうか? この特定のFRDMバリアントで初心者がよく注意する落とし穴、あるいは隠れたスイッチの要件について、何かアドバイスがあればぜひ教えてください! よろしくお願いいたします。 FRDMトレーニング Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly こんにちは、 現在、こちらでテストを行い、正確な手順をお伝えします。近日中に更新いたします。 Re: FRDM-IMX95: No Serial Output when Booting from SD Card (Pre-installed eMMC Boot Works Perfectly 調査していただき、またそちらでテストしていただき、ありがとうございます!ご協力ありがとうございます。今後のご報告をお待ちしております。
查看全文
CLI/ヘッドレス こんにちは!GUI Guider 2.0.0には、プロジェクトのCIビルドを自動化するためのCLI/ヘッドレスビルド機能はありますか?生成されたCファイルを自分のリポジトリで追跡したくはありません。 Re: CLI/Headless 私も知りたいです。 Re: CLI/Headless こんにちは、@nbarrett さん、 @znickerson さん、 GUI Guiderは、CIパイプラインから呼び出せるCLIやヘッドレスコード生成をネイティブにサポートしていません。 とはいえ、GUI Guider 2.0.0はCMakeとNinjaを利用して、GUI Guiderプロジェクトから生成されたコードをビルドおよびコンパイルし、フラッシュ可能な.binファイルを作成します。または.elfイメージを使えば、これらのツールを使ったスクリプトを作成すれば、このプロセスを自動化できるはずです。現時点では、これがどのように行われるのかのガイドやスクリプトの例はありませんが、GUI Guiderツールのビルド&コンパイルログを参照すると、GUI Guider 2.0.0がARMGCCベースのプロジェクトでどのように処理しているかを詳しく確認できます。 BR、 エドウィン。
查看全文
S32K312: WKUP割り込みがトリガーされない I have configured PTB2 as the WKUP input pin, and WKUP チャネル 8 はPTB2にマッピングされます。WKUPのモジュール構成は正しいようです。しかし、WKUPの割り込みはトリガーされていません。 以前、同じピンをEIRQ入力として設定したところ、割り込みが正常にトリガーされたため、ピンと外部信号が正しく機能していることが確認できました。 問題: PTB2はWKUPの入力として設定されています。 WKUPチャネル8はPTB2に割り当てられていました。 WKUP割り込みは受信されませんでした。 同じハードウェア構成で、EIRQ構成でも正しく動作します。 割り込みが生成されないようにする追加のWKUP設定要件、依存関係、または既知の制限があるかどうか、ご協力ください。 Wkpu_Ip_Init(0U, &Wkpu_Ip_Config_PB); /* INT2: ウェイクアップトリガー。*/ Wkpu_Ip_EnableInterrupt(0, Wkpu_Ip_ChannelConfig_PB[2U].hwChannel); Wkpu_Ip_EnableNotification(Wkpu_Ip_ChannelConfig_PB[2U].hwChannel); Re: S32K312: WKUP Interrupt Not Triggering こんにちは、 @DiaDev さん。 S32K3は~60の外部ウェイクアップに加え、4つの内部ウェイクアップソースも提供しており、チャネル設定時にこれらを考慮しなければなりません。これは、+4をオフセットとして加えることを意味します: PTB2はウェイクアップパッド[8]で、4つの内部ソースがチャネル 12となります。 この設定を変更して、WKPUがトリガーされるかどうかテストしてください。 よろしくお願いします、 ジュリアン
查看全文
CLI/Headless Hello! Does GUI Guider 2.0.0 have any CLI / Headless build features for automating some CI builds of my project? I'd rather not track generated c files in my repo. Re: CLI/Headless I would also like to know this please. Re: CLI/Headless Hi @nbarrett , @znickerson , GUI Guider does not natively support CLI or headless code generation that you could invoke from a CI pipeline. That said, GUI Guider 2.0.0 leverages CMake and Ninja to build and compile the code generated from the GUI Guider project into a flashable .bin or .elf image, so automating this process should be achievable by creating a script that uses these tools. We don't currently have any documented guide or script example of how this would be done, but you can reference the build and compile log from the GUI Guider tool to see in detail the process that GUI Guider 2.0.0 does on an ARMGCC based project. BR, Edwin.
查看全文
CLI/无头模式 您好!GUI Guider 2.0.0 是否有任何 CLI / 无头构建功能,可以用于自动化我项目中的一些 CI 版本?我不想在我的代码仓库中跟踪生成的 C 文件。 Re: CLI/Headless 我也想知道这一点。 Re: CLI/Headless 嗨@nbarrett , @znickerson , GUI Guider 本身并不支持 CLI 或无头代码生成,因此无法从 CI 管道中调用这些代码。 也就是说,GUI Guider 2.0.0 利用 CMake 和 Ninja 将 GUI Guider 项目生成的代码构建并编译成可刷写的 .bin 文件。或 .elf因此,通过创建使用这些工具的脚本,应该可以实现此过程的自动化。我们目前没有任何关于如何完成此操作的文档指南或脚本示例,但您可以参考 GUI Guider 工具的构建和编译日志,详细了解 GUI Guider 2.0.0 在基于 ARMGCC 的项目上执行的过程。 BR, 埃德温。
查看全文
IMX6Q U-BooT Hi, I have a custom camera with an IMX6q processor. I have working firmware on an old bootloader and an old kernel. I need to update the bootloader and kernel. But I can't get past the kernel loading stage. The UART log is always empty. Please help. Re: IMX6Q U-BooT Hello @CAT5000  Hope you are doing very well. Please specify the current BSP version and the new one. Also, your Software changes related to the UART where is defined for Console. Best regards, Salas. Re: IMX6Q U-BooT Working bootloader version U-Boot 2018.03 (Apr 22 2021 - 04:17:10 -0400) CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 30C Reset cause: POR Model: Freescale i.MX6 Quad SABER Smart Device Board Board: MX6-SabreSD Watchdog enabled DRAM: 2 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x21 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Card did not respond to voltage My board is a reference board with SabreSD I have all the schematics and data I'm not good at this kind of task, but I'd like to update the firmware to try out the new features. Re: IMX6Q U-BooT Hello! Actually, we have a guide for porting our processors to the last BSP version. Please take a look to the UG10165 (i.MX Porting Guide). There are described the changes that you need to do in U-boot. Also, if you have the Sabre board, you can simply download the last version Pre-compiled image from Embedded Linux for i.MX Applications Processors and flash to your board. Best regards,  Salas.
查看全文
EB tresos activation code failed i'm trying to use EBtresos for AUTOSAR, but i failed to activated. activation Code : 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. so i need the the other activate code to use the EBtresos. thank you. Re: EB tresos activation code failed Thank you for your patience. The internal team has updated the activation code on the webpage. Please click the link below to find the latest activation code: S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool -> EB tresos Studio 29.0.0  Re: EB tresos activation code failed Hi Sorry for the inconvenience we bring you! I have already reported this issue to the internal team, and I will let you know as soon as I receive their reply.   Best Regards, Robin Re: EB tresos activation code failed Hello, the activation code updated on the NXP website is still this: 7416-E905-5CC2-F20A. I tried to activate it today, but it still failed ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. Re: EB tresos activation code failed Please see my previous reply; the activation code has been updated. Please tell me which version of EBTresos page has not yet had its activation code modified so I can report it to the internal team for an update.
查看全文
Failed to send the pmic_set command in the DDR Tool. Hi, Currently, I am trying to adjust the BUCK6 output voltage of the PCA9450C in the DDR Tool, but I have run into an issue. I flashed the following commands onto the i.MX8M Plus board and confirmed that the PCA9450C is indeed connected to I2C1: memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x000001C6 # I2C1_SCL PAD memory set 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 After downloading the .ds file, the UART console responded with the following logs: PMIC is initialized in DDR script I2C_I2SR(0x30a2000c):0x81 bus is not ready Error: PMIC reg[0x1e] initilaization failed with value[0x11] When checking the I2C1 SCL and SDA lines with an oscilloscope, I observed that both lines are pulled low and latched. They only return to their default pulled-high state after a power cycle. Furthermore, I have verified that if I comment out the #sysparam commands, I can successfully observe the default PMIC initialization waveforms on the I2C bus, and the UART log correctly indicates that the PCA9450 has been detected. Re: Failed to send the pmic_set command in the DDR Tool. I have found the root cause. The IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) and IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) registers were not configured. I suggest adding this details to the application note for future reference. Thanks!" Re: Failed to send the pmic_set command in the DDR Tool. After commenting out #sysparam I used an oscilloscope to capture the default configurations that the i.MX8M Plus writes to the PCA9450C. The captured sequence is as follows: 0x25W, 0x00 0x25R, 0x31 0x25W, 0x0C, 0x29 0x25W, 0x11, 0x1C 0x25W, 0x12, 0x14 0x25W, 0x10, 0x59 0x25W, 0x1E, 0x14 Based on these findings, I appended these commands to the .ds file: # 2. IOMUX config. (SION=1, ODE=1, internal pull up) memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x00000176 # I2C1_SCL PAD memory set 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC address sysparam set pmic_set 0x0C29 # BUCK1&3 set to 0.85V, BUCK2 set to 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam set pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (DVS control through PMIC_STBY_REQ) sysparam set pmic_set 0x1E11 # BUCK6 set to 1.025V However, the UART console still gets stuck at this stage. Slightly different from before, it no longer throws any error messages, and just stops here: Download is complete Waiting for the target board boot... When checking the I2C1 SCL and SDA lines with an oscilloscope, the behavior remains the same as before: both lines are pulled low and latched, and they only return to their default pulled-high state after a power cycle. Re: Failed to send the pmic_set command in the DDR Tool. If you disable the pre-configured PMIC initialisation, you need to do everything by hand. On the i.MX 93 EVK board, the default PMIC I2C Bus is I2C2. To change it to I2C1, you need to set the right pinmux: Then you need to send the right commands: (example) Explanation of the commands: # Command Value Description 0 pmic_cfg 0x0025 I2C bus 1 (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) PMIC address 0x25 1 pmic_set 0x0C29 register=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS value=0x29 2 pmic_set 0x1118 register=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 value=0x18 3 pmic_set 0x1718 register=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 value=0x18 4 pmic_set 0x1428 register=0x14 Set VDDQ to 1.1V PCA9451_BUCK2OUT_DVS0 value=0x28 BUCK6 settings would be in registers 0x1D and 0x1E. Hope it helps, Bernhard. Re: Failed to send the pmic_set command in the DDR Tool. Oh yes, the famous DAISY register. Good catch!  When a custom configuration is selected, EVERYTHING needs to be set by hand. And you're right, the DAISY registers are not really in the focus when it comes to pin configurations. For the UART pin mux settings it appears in the ds for the RX signal, besides the  standard pin mux and pad settings. But for I2C the firmware is doing it as a default configuration in the background, you don't see the settings in the ds file. As a side note, for the i.MX 93, the DAISY chain register does not exist for I2C1 and I2C2, but it does for I2C3-8. I feed you input back into our tool group, this detail should be part of the User's Manual for the Config Tool. Alternatively, or in addition, the I2C interface settings should appear in the ds file. Regards, Bernhard.
查看全文
DDR 工具发送 pmic_set 命令失败。 您好, 目前,我正在尝试在 DDR Tool 中调整 PCA9450C 的 BUCK6 输出电压,但我遇到了一个问题。 我将以下命令烧录到 i.MX8M Plus 开发板上,并确认 PCA9450C 确实已连接到 I2C1: 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x000001C6 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x000001C6 # I2C1_SDA 焊盘 sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 下载完 .ds 文件后文件执行后,UART 控制台返回了以下日志: PMIC 在 DDR 脚本中初始化 I2C_I2SR(0x30a2000c):0x81 总线还没准备好 错误:PMIC 寄存器[0x1e]初始化失败,值为[0x11] 用示波器检查 I2C1 SCL 和 SDA 线时,我发现两条线都被拉低并锁存。只有在断电重启后,它们才会恢复到默认的高电平状态。 此外,我已经验证,如果我注释掉 #sysparam 命令,就可以在 I2C 总线上成功观察到默认的 PMIC 初始化波形,并且 UART 日志正确地表明 PCA9450 已被检测到。 Re: Failed to send the pmic_set command in the DDR Tool. 我找到了根本原因。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) 和 IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) 寄存器未配置。我建议将这些细节添加到应用笔记中,以供将来参考。谢谢!” Re: Failed to send the pmic_set command in the DDR Tool. 注释掉#sysparam后,我使用示波器捕获了 i.MX8M Plus 写入 PCA9450C 的默认配置。捕获到的序列如下: 0x25W,0x00 0x25R,0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 基于这些发现,我将这些命令添加到了 .ds 文件中。文件: # 2. IOMUX 配置。(SION=1,ODE=1,内部上拉) 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x00000176 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC 地址 sysparam set pmic_set 0x0C29 # 将 BUCK1 和 BUCK3 设置为 0.85V,将 BUCK2 设置为 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V 系统参数设置 pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59(通过 PMIC_STBY_REQ 进行 DVS 控制) sysparam set pmic_set 0x1E11 # BUCK6 设置为 1.025V 然而,UART 控制台仍然卡在这个阶段。与之前略有不同,它不再抛出任何错误信息,而是直接停止运行: 下载完成 等待目标板启动…… 使用示波器检查 I2C1 SCL 和 SDA 线时,其行为与之前相同:两条线都被拉低并锁定,只有在断电重启后才会恢复到默认的高电平状态。 Re: Failed to send the pmic_set command in the DDR Tool. 如果禁用预配置的 PMIC 初始化,则需要手动完成所有操作。 在i.MX 93 EVK板上,默认的 PMIC I2C 总线是 I2C 2。 要将其更改为 I2C 1,您需要设置正确的引脚复用: 然后你需要发送正确的命令:(例如) 命令说明: 数量 Command Value 说明 0 pmic_cfg 0x0025 I2C总线1 (0 代表 I2C1,1 代表 I2C2,2 代表 I2C3,3 代表 I2C4……) PMIC 地址 0x25 1 pmic_set 0x0C29 寄存器=0x0C BUCKxOUT_DVS0/1 预设降压电压1=0.8V,preset_buck2=0.7V,预设降压3=0.8VPCA9451_BUCK123_DVS 值=0x29 2 pmic_set 0x1118 寄存器=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 值=0x18 3 pmic_set 0x1718 寄存器=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 值=0x18 4 pmic_set 0x1428 寄存器=0x14 将 VDDQ 设置为 1.1V PCA9451_BUCK2OUT_DVS0 值=0x28 BUCK6 设置将位于寄存器 0x1D 和 0x1E 中。 希望对您有所帮助。 伯恩哈德。 Re: Failed to send the pmic_set command in the DDR Tool. 哦,对了,就是著名的DAISY收银机。抓得好! 选择自定义配置时,所有设置都需要手动完成。你说得对,在引脚配置方面,DAISY 寄存器并不是重点。对于 UART 引脚复用设置,除了标准的引脚复用和焊盘设置外,它还出现在 RX 信号的 ds 中。但对于 I2C,固件会在后台进行默认配置,您在 ds 文件中看不到这些设置。 顺便提一下,对于 i.MX 93,I2C1 和 I2C2 没有 DAISY 链寄存器,但 I2C3-8 有。 我会将您的反馈意见反馈给我们的工具组,这个细节应该包含在配置工具的用户手册中。或者,或者此外,I2C 接口设置应该出现在 ds 文件中。 问候, 伯恩哈德。
查看全文
eb tresos 许可证不能被允许(最大允许数量) 您好,我的 eb tresos 许可证有问题。 状态:4,正在创建请求 状态:5,请求已创建 状态:6,上下文已创建 状态:7,已连接到远程服务器 状态:8,请求已发送 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:10,等待回复 状态:9,正在轮询响应 状态:11,已完成 错误:flxActAppActivationSend (50040,41147,10248) 指定的数量超过了允许的最大数量(0)。 连接 FlexNet Operations Server 失败。 请更新许可证代码
查看全文
LS1046A DDR问题 LS1046A和BCM88270(交换芯片)通过pcie.3 x1 gen2连接(SD2_T/RX2_P/N),LS1046A使用4片K4AAG165WC-BCWE(无ecc), 目前的碰到的现象: 1.在bcm88270不向ls1046a通过pcie发送以太网数据包的情况下,使用stress ng和memtester程序测试内存都没有问题 2.在bcm88270向ls1046a通过pcie发送以太网数据包时,stress ng和memtester会出错 3.LS1046A通过pcie反复读写bcm88270寄存器或者表项(通过dma),没有问题。而且同时测试的stress ng也没问题。 Board Design Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: LS1046A DDR问题 由于单独测试stress ng和memtester正常, 证明DDR基本功能正常,  只有BCM88270发包时出错,说明错误是被PCIe流量触发的。 结合你给出的现象,可能原因概率排序: 40%  BCM88270 RX DMA地址越界/描述符错误 25%  PCIe RX方向SI问题(收包时暴露) 15%  PCIe Cache Coherent配置错误 10%  DDR SI问题(高带宽触发) 10%  电源完整性问题     第一种可能:PCIe DMA写坏了DDR(最高概率) 现象最符合:BCM88270发包  > PCIe DMA写入LS1046A内存 >  DMA地址错误或描述符错误 -> 覆盖了Memtester或Stress-ng使用的内存 -> 检测到内存错误 检查方法:查看DMA Buffer地址, 确认RX Descriptor, RX Buffer, SKB, DMA Pool 是否有越界。Linux下查看dma_alloc_coherent()返回地址,检查start,size,end是否有重叠。   memtester避开DMA区域,例如memtester 2M,观察DMA是否位于低端内存,如果避开DMA区域后不再报错,基本锁定DMA覆盖。   第二种可能:PCIe Cache Coherent配置错误 LS1046A是DPAA架构, PCIe DMA涉及CPU Cache, CCI-400, PCIe Controller, DDR, 如果BCM88270使用DMA写入DDR: 但驱动:dma_sync_single_for_cpu(), dma_sync_single_for_device() 处理错误,会造成:CPU看到旧数据, DMA写入新数据, 然后memcmp失败, memory test失败。 检查设备树,查看PCIe节点pcie@340000是否带dma-coherent; 如果配置错误,会导致随机内存错误。     第三种可能:PCIe接收方向SI问题 这里值得特别关注。你提到:PCIe.3 x1 Gen2,SD2_TX/RX2_P/N, 只有BCM88270 -> LS1046A发包时出错。而LS1046A -> BCM88270时DMA访问表项正常。 说明 PCIe RX方向更可疑。 PCIe寄存器访问:流量很小,即使BER较高也不容易暴露。  以太网收包:持续PCIe DMA TLP, 流量大几个数量级。此时:CRC重传, Replay,NAK,明显增加。 虽然PCIe理论有LCRC保护。但如果链路边缘化:可能导致:DMA timeout,描述符损坏,驱动异常,最终表现为:内存测试失败。   查看PCIe错误计数器: lspci -vv, 重点: CESta: Correctable Error; UESta: Uncorrectable Error; 查看:BadTLP, BadDLLP, ReplayNumRollover, ReceiverError是否增长。     第四种可能:DDR SI/PI边缘问题 虽然单独Stress正常,但仍不能完全排除。 原因:BCM88270发包时会增加: 1) PCIe SerDes功耗    增加:1V, 1.8V, AVDD_SERDES噪声。 2) DDR访问量剧增    正常测试: CPU<->DDR    现在变成: CPU,PCIe DMA, DDR Controller 同时工作,带宽显著提高。如果DDR裕量不足:开始出错。    验证方法:降低DDR频率,例如: 1600MT/s → 1333MT/s, 如果问题消失,基本锁定DDR SI/PI问题。    查看DDR ECC统计: 虽然无ECC,但可以uboot下用 md.l 读取DDR控制器状态寄存器,查看DDR_ERR_DETECT是否出现异常。     第五种可能:电源完整性问题 4片K4AAG165WC-BCWE容量较大。当 PCIe高速收包 + CPU Stress + DDR高带宽 同时发生,板上可能出现:VDD_DDR, VDD_SOC, VDD_CORE跌落。 重点测量: 示波器看VDD_DDR,VDD_SOC在故障时的纹波和瞬时跌落是否超标。特别是在BCM88270开始大流量发包瞬间。     第六种可能:PCIe与DDR走线串扰 LS1046A上:PCIe3和DDR4都属于高速接口,如果布局比较紧:PCIe RX, DDR DQ, DDR DQS存在平行长距离走线。 大流量PCIe时可能激发问题。这种现象非常符合:不发包 => 正常, 大发包 => DDR出错.     建议排查顺序: Step1: 抓PCIe错误: lspci -vv,看Receiver Error,Bad TLP,Replay,CRC Error是否持续增长。 Step2: 关闭网络驱动DMA收包。只保留PCIe读写寄存器,验证Stress是否仍正常。若正常,说明问题在RX DMA路径。 Step3: 在RX DMA Buffer前后加保护区,例如:0x5A5A5A5A,持续检查是否被覆盖。确认是否DMA越界。 Step4: 降PCIe速率,强制 Gen2 -> Gen1,如果故障消失,优先检查PCIe SI。 Step5: 降DDR频率,1600MT/s -> 1333MT/s,如果消失,优先检查DDR SI/PI。 Re: LS1046A DDR问题 问题已经解决,是BCM驱动问题,谢谢支持!
查看全文
LS1046A DDRに関する問題 LS1046AとBCM88270(スイッチチップ)は、PCIe.3 x1 Gen2(SD2_T/RX2_P/N)を介して接続されています。LS1046Aは、K4AAG165WC-BCWEチップ(ECCなし)を4個使用しています。 現在直面している状況: 1. BCM88270がPCIe経由でLS1046Aにイーサネットパケットを送信していない場合、stress ngとmemtesterを使用したメモリテストでは問題は検出されません。 2. BCM88270がPCIe経由でLS1046Aにイーサネットパケットを送信すると、`stress ng`と`memtester`でエラーが発生します。 3. LS1046Aは、PCIe(DMA経由)を介してBCM88270のレジスタまたはエントリへの読み書きを繰り返し実行しますが、問題なく動作します。さらに、同時に実施したストレステストでも問題は検出されませんでした。 ボードデザイン 通信および制御(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: LS1046A DDR问题 stress ngとmemtesterによる個別のテストは正常であったため、DDRの基本機能は正常であることが証明されました。唯一のエラーはBCM88270がパケットを送信した際に発生したものであり、このエラーはPCIeトラフィックによって引き起こされたことを示しています。 ご説明いただいた現象に基づき、考えられる原因の確率を順位付けすると以下のようになります。 40% BCM88270 RX DMA アドレス範囲外/ディスクリプタエラー 25% PCIe RX方向SIの問題(パケット受信時に顕在化) 15% PCIeキャッシュコヒーレント構成エラー DDR SI の問題が 10% 発生(高帯域幅が原因) 10%の電力整合性の問題     第一の可能性:PCIe DMAがDDRメモリを破損させた(最も可能性が高い)。 最もよく一致する現象: BCM88270 パケット送信 PCIe DMAによるLS1046Aメモリへの書き込み > DMAアドレスエラーまたはディスクリプタエラー -> MemtesterまたはStress-ngで使用されているメモリを上書きしています -> メモリエラーが検出されました 検査方法:DMAバッファアドレスを確認し、RXディスクリプタ、RXバッファ、SKB、およびDMAプールが範囲外になっていないか確認します。Linuxでは、dma_alloc_coherent()の戻りアドレスを確認し、開始アドレス、サイズ、および終了アドレスが重複していないか確認します。   memtester(例えばmemtester 2M)を使用してDMA領域を回避してください。DMAが低位メモリ領域に位置しているかどうかを確認してください。DMA領域を回避した後にエラーが報告されなくなった場合、DMAの上書きは基本的にロックされています。   2つ目の可能性は、PCIeキャッシュコヒーレント構成エラーです。 LS1046AはDPAAアーキテクチャを採用しています。PCIe DMAには、CPUキャッシュ、CCI-400、PCIeコントローラ、およびDDRが関与します。BCM88270がDMAを使用してDDRに書き込む場合: しかし、ドライバ`dma_sync_single_for_cpu()`と`dma_sync_single_for_device()`が正しく処理されない場合、CPUは古いデータを参照し、DMAは新しいデータを書き込み、その結果`memcmp`と`memory test`が失敗します。 デバイスツリーを確認して、PCIeノードpcie@340000にdma-coherentが設定されているかどうかを確認してください。設定が正しくない場合、ランダムメモリエラーが発生します。     3つ目の可能性:PCIe受信方向SIの問題 これは特に注意を払うべき点です。PCIe.3 x1 Gen2、SD2_TX/RX2_P/Nの場合、BCM88270からLS1046Aにパケットを送信する場合にのみエラーが発生するとおっしゃっていましたが、LS1046AからBCM88270へのDMAアクセステーブルのエントリは正常です。 これは、PCIe RX方向の方がより疑わしいことを示唆している。 PCIeレジスタアクセス:トラフィックは非常に少なく、BERが高くても容易には露出しない。 イーサネットパケットの受信:PCIe DMA TLPが継続的に動作し、トラフィック量が数桁増加します。このとき、CRC再送信、リプレイ、およびNAK(ネットワークアドレス変換)が大幅に増加します。 PCIeは理論的にはLCRC保護機能を備えているものの、リンクが不安定になると、DMAタイムアウト、ディスクリプタの破損、ドライバの異常、そして最終的にはメモリテストの失敗につながる可能性がある。   PCIeエラーカウンタを確認するには、`lspci -vv`を実行し、CESta: 訂正可能なエラー、UESta: 訂正不可能なエラーに注意してください。また、BadTLP、BadDLLP、ReplayNumRollover、およびReceiverErrorが増加していないかどうかも確認してください。     4つ目の可能性:DDR SI/PIエッジ問題 ストレスレベル自体は正常範囲内ではあるものの、完全に否定することはできない。 理由:BCM88270がパケットを送信すると、以下の値が増加します。 1) PCIe SerDesの消費電力 追加:1V、1.8V、AVDD_SERDESノイズ。 2) DDRアクセス量が急増 通常テスト:CPU <-> DDR 現在では、CPU、PCIe DMA、DDRコントローラが同時に動作するため、帯域幅が大幅に向上しています。DDRの容量が不足すると、エラーが発生し始めます。 検証方法:DDRの周波数を下げてください。例えば、1600MT/s → 1333MT/s。問題が解消すれば、基本的にはDDRのSI/PIの問題です。 DDR ECC 統計を確認するには: ECC はありませんが、uboot の md.l を使用して DDR コントローラ ステータス レジスタを読み取り、DDR_ERR_DETECT が異常かどうかを確認できます。     5つ目の可能性:電源の完全性の問題 4つのK4AAG165WC-BCWEチップは比較的大きな容量を持っています。高速PCIeパケット受信、CPU負荷、高DDR帯域幅が同時に発生すると、ボード上でVDD_DDR、VDD_SOC、VDD_COREの電圧降下が発生する可能性があります。 重要な測定項目:オシロスコープを使用して、障害発生時にVDD_DDRおよびVDD_SOCのリプルと過渡電圧降下が制限値を超えていないかを確認します。特に、BCM88270が大量のパケットを送信し始める瞬間に注意してください。     6つ目の可能性:PCIeとDDRのトレースクロストーク LS1046Aでは、PCIe3とDDR4はどちらも高速インターフェースです。レイアウトがタイトな場合、PCIe RX、DDR DQ、DDR DQSは並列の長距離配線となっています。 大量のPCIeトラフィックは問題を引き起こす可能性があります。この現象は、パケットが送信されない場合、正常に動作し、パケット量が多い場合、DDRエラーが発生するというパターンとよく一致します。     調査の推奨順序: ステップ 1: PCIe エラーをキャプチャします: lspci -vv を使用して、レシーバー エラー、Bad TLP、リプレイ、および CRC エラーが継続的に増加しているかどうかを確認します。 ステップ2:ネットワークドライバのDMAパケット受信を無効にします。PCIeの読み書きレジスタのみを有効にしたまま、Stressが正しく動作するかどうかを確認します。正しく動作する場合は、RX DMAパスに問題があります。 ステップ3:RX DMAバッファの前後に保護ゾーンを追加します(例:0x5A5A5A5A)。そして、それらが上書きされていないかどうかを継続的にチェックします。DMAが制限を超えていないか確認します。 ステップ4:PCIeの速度を下げ、Gen2からGen1に強制的に切り替えます。これで不具合が解消された場合は、まずPCIe SIを確認してください。 ステップ5:DDR周波数を1600MT/sから1333MT/sに下げます。問題が解消された場合は、まずDDR SI/PIを確認してください。 Re: LS1046A DDR问题 問題は解決しました。BCMドライバーの問題でした。ご協力ありがとうございました!
查看全文
DDRツールでpmic_setコマンドの送信に失敗しました。 こんにちは、 現在、DDR ToolでPCA9450CのBUCK6出力電圧を調整しようとしていますが、問題が発生しました。 以下のコマンドをi.MX8M Plusボードに書き込み、PCA9450Cが確かにI2C1に接続されていることを確認しました: メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x000001C6 # I2C1_SCL PAD メモリセット 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 .dsファイルをダウンロードした後ファイルに対して、UARTコンソールは以下のログを出力しました。 PMICはDDRスクリプトで初期化されます I2C_I2SR(0x30a2000c):0x81 バスはまだ準備ができていません エラー: PMIC reg[0x1e] の初期化が値[0x11]で失敗しました オシロスコープでI2C1のSCLとSDAラインをチェックしたところ、両方のラインがプルダウンされてラッチされていることが確認できました。それらは電源を再投入した後にのみ、デフォルトのプルアップ状態に戻ります。 さらに、#sysparam コマンドをコメントアウトすると、I2Cバス上のデフォルトのPMIC初期化波形を正常に観察でき、UARTログもPCA9450が検出されたことを正しく示しています。 Re: Failed to send the pmic_set command in the DDR Tool. 根本原因を突き止めました。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) および IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) レジスタが設定されていません。この詳細は将来の参考のためにアプリケーションノートに添付することをお勧めします。ありがとう!" Re: Failed to send the pmic_set command in the DDR Tool. #sysparamをコメントアウトした後、オシロスコープを使用して、i.MX8M Plus が PCA9450C に書き込むデフォルト設定をキャプチャしました。キャプチャされたシーケンスは以下のとおりです。 0x25W、0x00 0x25R、0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 これらの調査結果に基づき、私は.dsファイルに以下のコマンドを追加しました。ファイル: # 2. IOMUX 設定。(SION=1、ODE=1、内部プルアップ) メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x00000176 # I2C1_SCL PAD メモリセット 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMICアドレス sysparam set pmic_set 0x0C29 # BUCK1&3を0.85Vに設定、BUCK2を0.9Vに設定 sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam セット pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (PMIC_STBY_REQ を介した DVS 制御) sysparam set pmic_set 0x1E11 # BUCK6 を 1.025V に設定 しかし、UARTコンソールはこの段階で依然として停止してしまう。以前とは少し異なり、エラーメッセージは表示されなくなり、ここで停止します。 ダウンロードが完了しました ターゲットボードの起動を待っています... オシロスコープでI2C1のSCL線とSDA線をチェックしたところ、動作は以前と同じで、両方の線ともプルダウンされてラッチされており、電源を入れ直した後にのみデフォルトのプルアップ状態に戻ります。 Re: Failed to send the pmic_set command in the DDR Tool. 事前設定されたPMIC初期化を無効にすると、すべて手動で行う必要があります。 i.MX 93 EVKボードでは、デフォルトのPMIC I2CバスはI2C2です。 I2C 1に変更するには、適切なピンマルチプレクサを設定する必要があります。 次に、適切なコマンドを送信する必要があります。(例) コマンドの説明: 件 コマンド バリュー 説明 0 pmic_cfg 0x0025 I2Cバス1 (0はI2C1、1はI2C2、2はI2C3、3はI2C4…) PMICアドレス0x25 1 pmic_set 0x0C29 レジスタ=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V、preset_buck2=0.7V、preset_buck3=0.8VPCA9451_BUCK123_DVS 値=0x29 2 pmic_set 0x1118 レジスタ=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 値=0x18 3 pmic_set 0x1718 レジスタ=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 値=0x18 4 pmic_set 0x1428 レジスタ=0x14 VDDQを1.1Vに設定 PCA9451_BUCK2OUT_DVS0値=0x28 BUCK6の設定は、レジスタ0x1Dと0x1Eに格納されます。 お役に立てば幸いです。 ベルンハルト。 Re: Failed to send the pmic_set command in the DDR Tool. ああ、そうそう、あの有名なDAISYレジスターですね。よく気づいたね! カスタム設定を選択した場合、すべてを手動で設定する必要があります。おっしゃる通り、ピン構成に関しては、DAISYレジスタはあまり重要視されません。UARTピン多重化設定については、標準のピン多重化設定とパッド設定に加えて、RX信号のdsに表示されます。しかし、I2Cに関してはファームウェアがバックグラウンドでデフォルト設定として処理するため、dsファイルに設定内容は表示されません。 補足として、i.MX 93の場合、I2C1とI2C2にはDAISYチェーンレジスタは存在しませんが、I2C3~8には存在します。 この詳細はツールグループにフィードバックします。この詳細は設定ツールのユーザーマニュアルの一部になるべきです。あるいは、または追加して、I2Cインターフェースの設定がdsファイルに表示されるはずです。 よろしくお願いいたします。 ベルンハルト。
查看全文
LS1046A DDR Issues The LS1046A and BCM88270 (switch chip) are connected via PCIe.3 x1 Gen2 (SD2_T/RX2_P/N). The LS1046A uses four K4AAG165WC-BCWE chips (without ECC). The current situation encountered: 1. When the BCM88270 is not sending Ethernet packets to the LS1046A via PCIe, memory tests using stress ng and memtester show no problems. 2. When the BCM88270 sends Ethernet packets to the LS1046A via PCIe, `stress ng` and `memtester` will encounter errors. 3. The LS1046A repeatedly reads and writes to the BCM88270 registers or entries via PCIe (through DMA) without any problems. Furthermore, stress testing at the same time also showed no issues. Board Design Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: LS1046A DDR问题 Since individual tests of stress ng and memtester were normal, it proves that the basic functions of DDR are normal. The only error occurred when BCM88270 sent packets, indicating that the error was triggered by PCIe traffic. Based on the phenomena you described, the probabilities of the possible causes are ranked as follows: 40% BCM88270 RX DMA address out of bounds/descriptor error 25% PCIe RX direction SI issue (exposed during packet reception) 15% PCIe Cache Coherent Configuration Error 10% DDR SI issue (triggered by high bandwidth) 10% power integrity issues     First possibility: The PCIe DMA corrupted the DDR memory (highest probability). The phenomenon most closely matches: BCM88270 packet sending PCIe DMA write to LS1046A memory > DMA address error or descriptor error -> Overwriting memory used by Memtester or Stress-ng -> Memory error detected Inspection method: Check the DMA buffer address to confirm whether RX Descriptor, RX Buffer, SKB, and DMA Pool are out of bounds. On Linux, check the return address of dma_alloc_coherent() to check if start, size, and end overlap.   Avoid DMA regions using memtester, for example, memtester 2M. Observe whether the DMA is located in low memory. If no more errors are reported after avoiding the DMA region, the DMA overwriting is basically locked.   The second possibility is a PCIe Cache Coherent configuration error. The LS1046A uses a DPAA architecture. PCIe DMA involves the CPU cache, CCI-400, PCIe controller, and DDR. If the BCM88270 uses DMA to write to DDR: However, errors in the driver's `dma_sync_single_for_cpu()` and `dma_sync_single_for_device()` functions can cause the CPU to see old data, the DMA to write new data, and then `memcmp` and `memory test` to fail. Check the device tree to see if the PCIe node pcie@340000 has dma-coherent; if the configuration is incorrect, it will cause random memory errors.     The third possibility: PCIe receive direction SI problem This deserves special attention. You mentioned that for PCIe.3 x1 Gen2, SD2_TX/RX2_P/N, the error only occurs when sending packets from BCM88270 to LS1046A. However, the DMA access table entries are normal when LS1046A -> BCM88270. This suggests that the PCIe RX direction is more suspicious. PCIe register access: traffic is very small, and it is not easily exposed even if the BER is high. Ethernet packet reception: Continuous PCIe DMA TLP, traffic volume is several orders of magnitude higher. At this time: CRC retransmission, replay, and NAK (Network Address Translation) increase significantly. Although PCIe theoretically has LCRC protection, if the link becomes marginalized, it may lead to: DMA timeout, descriptor corruption, driver anomalies, and ultimately, memory test failures.   To check the PCIe error counters: `lspci -vv`, pay attention to: CESta: Correctable Error; UESta: Uncorrectable Error; check if BadTLP, BadDLLP, ReplayNumRollover, and ReceiverError are increasing.     The fourth possibility: DDR SI/PI edge problem Although the stress level is normal on its own, it cannot be completely ruled out. Reason: When BCM88270 sends packets, it will increase the following: 1) PCIe SerDes power consumption Added: 1V, 1.8V, AVDD_SERDES noise. 2) DDR access volume surged Normal test: CPU <-> DDR Now, the CPU, PCIe DMA, and DDR controller work simultaneously, significantly increasing bandwidth. If DDR capacity is insufficient, errors will begin to occur. Verification method: Reduce the DDR frequency, for example: 1600MT/s → 1333MT/s. If the problem disappears, it is basically a DDR SI/PI issue. To check DDR ECC statistics: Although there is no ECC, you can use md.l in uboot to read the DDR controller status register and check if DDR_ERR_DETECT is abnormal.     Fifth possibility: Power integrity issue The four K4AAG165WC-BCWE chips have a relatively large capacity. When high-speed PCIe packet reception, CPU stress, and high DDR bandwidth occur simultaneously, the following may occur on the board: VDD_DDR, VDD_SOC, and VDD_CORE drops. Key measurements: Use an oscilloscope to check if the ripple and transient voltage drop of VDD_DDR and VDD_SOC exceed the limits during a fault. Pay special attention to the moment when the BCM88270 starts sending large amounts of packets.     Sixth possibility: PCIe and DDR trace crosstalk On the LS1046A: PCIe3 and DDR4 are both high-speed interfaces. If the layout is tight: PCIe RX, DDR DQ, and DDR DQS have parallel long-distance traces. High-volume PCIe traffic may trigger issues. This phenomenon closely matches the pattern: no packets sent => normal operation, high packet volume => DDR error.     Suggested order of investigation: Step 1: Capture PCIe errors: use lspci -vv to check if Receiver Error, Bad TLP, Replay, and CRC Error are continuously increasing. Step 2: Disable network driver DMA packet reception. Only keep the PCIe read/write registers enabled and verify if Stress is still working correctly. If it is, the problem lies in the RX DMA path. Step 3: Add protection zones before and after the RX DMA Buffer, for example: 0x5A5A5A5A, and continuously check if they are overwritten. Confirm whether the DMA has exceeded the limit. Step 4: Reduce the PCIe speed and force Gen2 -> Gen1. If the fault disappears, check the PCIe SI first. Step 5: Reduce DDR frequency, 1600MT/s -> 1333MT/s. If the problem disappears, first check DDR SI/PI. Re: LS1046A DDR问题 The problem has been resolved; it was a BCM driver issue. Thank you for your support!
查看全文
eb tresos license can not be allowed(maximum quantity allowed) hello, there is eb tresos license problem. Status: 4, Creating request Status: 5, Request created Status: 6, Context created Status: 7, Connected to remote server Status: 8, Request Sent Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 11, Done ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. please update license code
查看全文
IMX6Q U-Boot こんにちは、私はIMX6qプロセッサを搭載したカスタムカメラを持っています。 古いブートローダーと古いカーネル上で動作するファームウェアを持っています。 ブートローダーとカーネルをアップデートする必要があります。 しかし、カーネルの読み込み段階を突破できません。 UARTログは常に空です。 助けてください。 Re: IMX6Q U-BooT こんにちは、 @CAT5000さん。 お元気でお過ごしのことと思います。 現在のBSPバージョンと新しいBSPバージョンを指定してください。 また、コンソールで定義されているUARTに関連するソフトウェアの変更もあります。 よろしくお願いいたします。 サラス。 Re: IMX6Q U-BooT こんにちは! 実は、プロセッサを最後のBSPバージョンに移植するためのガイドがあります。 UG10165 (i.MXポーティングガイド)をご覧ください。 U-bootで行う必要のある変更点について説明します。 また、Sabreボードをお持ちなら、Embedded Linux for i.MXアプリケーション・プロセッサ から最終版の事前コンパイル済みイメージをダウンロードして、ボードにフラッシュするだけで済みます。 よろしくお願いします、 サラス。 Re: IMX6Q U-BooT 動作するブートローダーバージョン U-Boot 2018.03 (2021年4月22日 04:17:10 -0400) CPU:Freescale i.MX6Q rev1.3 996 MHz(動作周波数は792 MHz) CPU:オートモーティブ温度グレード(-40°Cから125°C)で30°Cに対応 リセット原因:POR(POR) モデル:Freescale i.MX6 クアッドSABERスマートデバイスボード ボード:MX6-SabreSD ウォッチドッグ有効 DRAM:2 GiB PMIC:PFUZE100!DEV_ID=0x10 REV_ID=0x21 MMC: FSL_SDHC: 0、FSL_SDHC: 1、FSL_SDHC: 2 MMCから環境を読み込んでいます... カードが電圧に反応しませんでした 私のボードはSabreSDを搭載したリファレンスボードです。 回路図とデータは全て揃っています 私はこういう作業は得意ではないのですが、新機能を試すためにファームウェアをアップデートしたいと思っています。
查看全文
EB tresosのアクティベーションコードが失敗しました AUTOSARでEBtresosを使おうとしているのですが、アクティベートできませんでした。 アクティベーションコード: 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) 指定された数量が許容最大数量 (0) を超えています。 FlexNet Operations Serverへの接続に失敗しました。 だからEBtresosを使うにはもう一つのアクティベートコードが必要です。 どうもありがとうございます。 Re: EB tresos activation code failed ご辛抱いただきありがとうございます。 社内チームがウェブページ上のアクティベーションコードを更新しました。 最新の認証コードを確認するには、以下のリンクをクリックしてください。 S32K3 標準ソフトウェア - > オートモーティブ SW - EB tresos Studio / AUTOSAR 設定ツール - > EB tresos Studio 29.0.0 Re: EB tresos activation code failed ハイ ご迷惑をおかけして申し訳ございません! この件については既に社内チームに報告済みです。返信があり次第、ご連絡いたします。   よろしくお願いいたします ロビン Re: EB tresos activation code failed こんにちは。NXPのウェブサイトで更新されたアクティベーションコードは、引き続き7416-E905-5CC2-F20Aです。今日アクティベートしようとしたのですが、やはり失敗しました。 ERROR: flxActAppActivationSend (50040,41147,10248) 指定された数量が許容最大数量 (0) を超えています。 FlexNet Operations Serverへの接続に失敗しました。 Re: EB tresos activation code failed 前回の返信をご覧ください。アクティベーションコードが更新されました。 EBTresosページのアクティベーションコードがまだ変更されていないバージョンを教えてください。内部チームに報告して更新を依頼します。
查看全文
EB Tresos激活码失败 我尝试使用 EBtresos for AUTOSAR,但是激活失败了。 激活码: 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) 指定的数量超过最大允许数量 (0)。 连接 FlexNet Operations Server 失败。 所以我需要另一个激活码才能使用 EBtresos。 谢谢! Re: EB tresos activation code failed 感谢您的耐心等待。 内部团队已更新网页上的激活码。 请点击下方链接查找最新激活码: S32K3 标准软件-> 汽车软件 - EB tresos Studio / AUTOSAR 配置工具 -> EB tresos Studio 29.0.0 Re: EB tresos activation code failed HI 给您带来的不便,我们深表歉意! 我已经将此问题报告给了内部团队,一旦收到他们的回复,我会立即通知您。   此致敬礼, Robin Re: EB tresos activation code failed 您好,NXP 网站上更新的激活码仍然是:7416-E905-5CC2-F20A。我今天尝试激活它,但仍然失败了。 ERROR: flxActAppActivationSend (50040,41147,10248) 指定的数量超过最大允许数量 (0)。 连接 FlexNet Operations Server 失败。 Re: EB tresos activation code failed 请查看我之前的回复;激活码已更新。 请告诉我哪个版本的 EBTresos 页面激活码尚未被修改,以便我向内部团队报告并进行更新。
查看全文