Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
T1024 QorIQ 裸机 电路板支持包。,适用于 CodeWarrior PA10.5 我们需要与 CodeWarrior Power Architecture v10.5 相匹配的官方 QorIQ T10xx 裸机 电路板支持包软件包。 必填内容: 1. 为 T1024 提供完整的裸机启动 电路板支持包。 2. RCW、RESET、L1/L2 缓存、DDR、中断、PCIe 底层驱动程序源 3. CodeWarrior PA10.5 固定项目模板 4. T10xx RDB 板的参考,引用裸机演示项目 背景: 我们正在使用 CodeWarrior PA10.5 在 T1024 上开发裸机固件,LSDK 2.0 Linux SDK 仅提供 U-启动 和 Linux 源代码,缺少官方的 CodeWarrior 裸机 电路板支持包。请提供电路板支持包。官方存档或下载链接。 谢谢。 Re: T1024 QorIQ Bare-Metal BSP for CodeWarrior PA10.5 我们没有适用于 T1024 平台的裸机电路板支持包。。 您可能需要其他平台上的 NetComm 软件作为参考,引用。 https://www.nxp.com.cn/products/processors-and-microcontrollers/power-architecture/qoriq-communication-processors/p-series/netcomm-software-resources:NetComm_Software
View full article
Yocto Linux 电路板支持包。 的支持期限 你好, 请问您能否提供以下方面的信息? 我们计划使用 NXP 提供的 Yocto Linux 电路板支持包。开发基于 i.MX 8M Plus 的板 请问您能否回答以下关于电路板支持包。的问题 1. 电路板支持包。版本发布后多久会提供更新? 2. 当新的 Yocto LTS 版本发布时,电路板支持包。通常需要多长时间才能更新以整合新的 Yocto LTS 版本? 3. 我们了解到,可以通过“电路板支持包。 生命周期维护:保持 Linux ® 电路板支持包。 安全”获得网络安全更新。 请问您能否与我们联系: - 可获得的最长支持期限,以及 这项服务的大概费用是多少? 感谢您的支持。 我们期待您的回复。 顺祝商祺!
View full article
S32ds license expired 2107-4B0B-EBCA-A774  S32 Design Studio for ARM v2.2 申请延长激活时间 申请延长激活 Re: S32ds license expired Hi,  your S32DS license has been extended. Please activate S32DS again with your old code. 
View full article
S32G274 Wake-up abnormality Hi NXP team, Project background: We have two S32G274 chips placed on the same board, referred to as chip1 and chip2. chip2 serves as a backup for chip1 — that is, when chip1 fails, chip2 takes over its functions. Problem description: Both S32G chips enter sleep state according to the command: the MCU enters Standby, and the PMIC enters Standby. They can be woken up via CAN or via KL15. During one particular test, we found that chip1 woke up normally and operated correctly, but chip2 did not work properly. By measuring the PMIC voltages, we found that the PMIC output 3.3V, 1.8V, 1.1V and 5V, so the PMIC supply voltages were normal. However, there was no output on chip2's serial port, meaning it had not entered the A-core. At the time we suspected it was stuck in the bootloader stage. We then measured the chip temperatures: chip1 was 50°C, while chip2 was 40°C. To determine where chip2 was getting stuck, we recovered chip2 by cutting the main power and powering it back on, and performed the following tests: Halting chip2 with a while(1) loop when loading the A-core — the chip temperature was 45°C. Halting chip2 with a while(1) loop before clock initialization — the chip temperature was 42°C. Keeping chip2 permanently in reset state by continuously shorting the reset pin — the chip temperature was 40°C, which matches the temperature observed during the fault. Problem summary: We suspect that chip2's wake-up function is behaving abnormally, causing chip2 to remain stuck in a reset state. However, the exact root cause is still unclear. Could you please help us analyze the possible causes and advise on how to further debug this issue? Looking forward to your reply. Best regards, Chenyin Re: S32G274 Wake-up abnormality Hi Joey, Thank you for your prompt response. Please find our answers to your questions below: Question 1: The issue where Chip2 cannot be woken up is a very low-probability problem. We have been running for nearly a year and have only encountered this single case, so it is difficult to reproduce. Question 2: Both Chip1 and Chip2 are woken up via CAN messages. The code logic for Chip1 and Chip2 is consistent, with possible differences only in the main logic execution and the failover handling part. Question 3: The Standby entry process is as follows: The M-core notifies the A-core via IPCF. The A-core executes the shutdown procedure. The A-core sends a command to the PMIC to enter Standby. The M-core enters Standby mode. Please let us know if you need any additional information or logs for further analysis. Looking forward to your reply. Best regards Re: S32G274 Wake-up abnormality Hi,Jerry_cao Could you please provide more information? 1. The phenomenon that Chip 2 cannot be awakened only occurred in your work. Can it be reproduced? 2. Are both Chip 1 and Chip 2 awakened together through KL15? 3. What are your Standby and wake-up processes? Are both the M core and the A core involved? Does M core turn off A core first, and then M core enters Standby? BR Joey Re: S32G274 Wake-up abnormality Hi,Jerry_cao Thank you for your reply and detail information. 1.Regarding the situation where Chip2 failed to wake up, Has the M core been awakened, and does the A core have any logs? did obtain any useful information on chip?  2.Is failure within the normal operating range of the chip? 3. Is this only the one board that has this problem? Do other boards have this problem? The temperature test might not be sufficient for analyzing the problem. It suggests that you could try implementing an automated testing method to see if the issue can be reproduced again. BR Joey Re: S32G274 Wake-up abnormality Hi Joey, Thank you for your continued support. After further investigation, we have identified the root cause: the issue is related to the external watchdog (GPT driver) feeding operation. Current findings: If the external watchdog is disabled at the very beginning of the code, the Standby entry and wake-up works correctly without any issues. If the external watchdog is disabled only before entering Standby (while it runs normally during the main logic), the problem still reproduces. This indicates that the watchdog feeding operation interferes with the Standby entry timing. Our current hypothesis is that the command sent to the PMIC to enter Standby may be disrupted by the watchdog feeding operation, causing a timing violation that prevents the device from entering Standby correctly. Questions: Could you please help analyze whether the watchdog feeding operation (GPT driver) could affect the timing of the PMIC Standby entry command? Is there a specific sequence or timing requirement for the PMIC Standby entry command that we should follow? Are there any known timing constraints between the watchdog peripheral and the PMIC standby entry sequence on the S32G platform? Looking forward to your reply. Best regards Re: S32G274 Wake-up abnormality Hi,Jerry_cao Do you mean that you suspect that the Chip2 SOC has entered Standby mode, but the PMIC failed to enter Standby mode properly, thus resulting in a failure to wake up?  I will help you to see if there is any time or sequence limit on the Standby command and watchdog, and I will reply to you when there is any progress. Also, you can refer to this AN12880 to check relevant information. https://www.nxp.com.cn/webapp/Download?colCode=AN12880&lang_cd=zh BR Joey
View full article
MC9S08QG8 我下载了 CodeWarrior(经典 IDE)v6.3,但是无法安装。我用的是Windows 11系统。请问如何才能找到适用于mc9s08qg8的编译器? Re: MC9S08QG8 你好, CodeWarrior v6.3 与 Windows 11 不兼容;要在 Windows 11 中使用 CodeWarrior,请更新至 v11.1。我查找 MC9S08QG8 设备,并且该设备在此版本中可用,以便使用该编译器。 您可以从此链接下载: CodeWarrior ® for MCUs (Eclipse IDE) 11.1 此致敬礼,路易斯
View full article
AAOS 15 用户切换在 i.MX8QM 多显示器设置中崩溃 各位团队成员,大家好! 我们在 i.MX8QuadMax 板 上 运行 Android Automotive OS 15(AAOS 15), 采用多显示器设置( 主 显示器 + 乘客 显示器) 。 我们发现 用户 切换过程 中 默认 的 汽车 启动 器 存在 问题 : 系统 正常 启动 , 主 显示屏 和 乘客 显示屏 上 均 显示 启动 器 。 当 从 当前 用户 切换 到 新 用户 或 访客 用户 时 , 主 显示屏 和 乘客 显示屏 都会 崩溃 并 变得 无法 使用 。 用户 切换 后, 该 问题 始终 可以 重现 。 我们 想 知道 : 在 i.MX8QM 多 显示器 系统 中 , AAOS 15 是否 存在 与 用户切换 相关 的 已知 问题 ? 用户 切换 期间, 乘客 显示屏 的 处理 是否 需要 任何 额外 的 配置 ? 我们 应该 收集 哪些 日志 或 调试 信息 来 进一步 分析 此 问题? 任何建议或指导都将不胜感激。 谢谢。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup 嗨@AldoG , 谢谢你的解释。   我们 正在 使用 NXP i.MX8QM MEK 板 和 NXP 电路板支持包 。由于 此 问题 与 Android Automotive 相关 , 请问 我们 应该 通过 哪个 支持 渠道 或 论坛 提出 与 AAOS 相关 的 问题 ? 谢谢。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup 你好, 你使用的是NXP MEK开发板吗? 如果是,您使用的是NXP 电路板支持包。吗? 请注意,我们不提供 Android Automotive 的支持,但如果我们的 电路板支持包。 版本出现问题,我们可以提供帮助。 此致敬礼/Saludos, 阿尔多。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup 嗨@AldoG , 谢谢你的回复。我 已 附上 完整的 logcat 日志 、 重现 步骤 以及 我们为实现多显示器功能所做的更改。 重现步骤: 在 i.MX8QM 上 启动 AAOS 15 ,并 启用 中央 和 乘客 显示屏 。 打开 乘客 显示屏 上的 用户 设置 。 在 乘客 显示屏 上 创建 或 切换 到 新 用户 /访客 用户 。 用户 切换 期间 , com.android.car.carlauncher 崩溃 并显示以下错误信息:   android.view.WindowManager$InvalidDisplayException: 无法添加窗口——找不到指定的显示器。 从日志 来看 ,用户 切换 后, CarLauncher 似乎正在尝试在 不再 可用 的 显示器 或 显示 映射 无效 的 显示器上恢复运行 。 请问 您 能否 提供以下建议: 在 i.MX8QM 上, AAOS 15 多 用户/多 显示器 场景 中 是否 存在 已知 问题 ? 在用户切换期间,哪个 元器件 负责 分配 显示 内容 (OccupantZone、 CarUserService、 TaskDisplayArea 或 WindowManager)? 对于 在 辅助 显示器 上 启动 启动器 , 是否 存在 与 MUMD (多用户 多显示器) 支持 相关的 已知 要求 或 补丁 ? 是否 有 任何 建议 的 调试 信息 需要 收集 , 以 确定 用户 切换 后 显示 失效 的 原因 ?
View full article
MC9S08QG8 CodeWarrior(classic IDE)v6.3をダウンロードしましたが、インストールできません。私はWindows 11を使用しています。mc9s08qg8用のコンパイラはどうやって入手できますか? Re: MC9S08QG8 こんにちは、 CodeWarrior v6.3はWindows 11と互換性がありません。Windows 11でCodeWarriorを使用するには、v11.1にアップデートしてください。MC9S08QG8 デバイスを探したところ、このバージョンでコンパイラを使用するために利用可能でした。 こちらのリンクからダウンロードできます: CodeWarrior® for MCUS (Eclipse IDE) 11.1 敬具、ルイス
View full article
AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hello Team, We are running Android Automotive OS 15 (AAOS 15) on the i.MX8QuadMax board with a multi-display setup (Main Display + Passenger Display). We are observing an issue with the default Car Launcher during user switching: System boots normally and the launcher is displayed on both main and passenger displays. When switching from the current user to a new user or guest user, both the main display and passenger display crash and become unusable. The issue is consistently reproducible after user switching. We would like to know: Is there any known issue related to user switching in AAOS 15 on i.MX8QM multi-display systems? Are there any additional configurations required for passenger display handling during user switch? What logs or debug information should we collect to further analyze this issue? Any suggestions or guidance would be appreciated. Thanks. Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hi @AldoG, Thanks for the clarification.   We are using the NXP i.MX8QM MEK board with NXP BSP. Since this issue is related to Android Automotive, could you please let us know the correct support channel or forum where we should raise our AAOS-related questions? Thank you. Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hello, Are you using NXP MEK board? If yes, you are using NXP BSP? Please note that we do not support Android Automotive we can provide asistance if issues are found on our BSP release. Best regards/Saludos, Aldo. Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hi @AldoG, Thank you for the response. I have attached the full logcat,the reproduction steps.and changes we made to bring multi displays. Reproduction Steps: Boot AAOS 15 on i.MX8QM with center and passenger displays enabled. Open User Settings on the passenger display. Create or switch to a new user/guest user on the passenger display. During the user switch, com.android.car.carlauncher crashes with:   android.view.WindowManager$InvalidDisplayException: Unable to add window -- the specified display can not be found From the log, it appears that CarLauncher is trying to resume on a display that is no longer available or has an invalid display mapping after the user switch. Could you please advise: Whether this is a known issue in AAOS 15 multi-user/multi-display scenarios on i.MX8QM? Which component is responsible for assigning the display during user switching (OccupantZone, CarUserService, TaskDisplayArea, or WindowManager)? Are there any known requirements or patches related to MUMD (Multi-User Multi-Display) support for launcher launching on secondary displays? Is there any recommended debug information we should collect to identify why the display becomes invalid after the user switch?
View full article
asoc-simple-card: カーネル6.18.xへのアップグレード後に解析エラーが発生 こんにちは、 以下は、カーネル6.6.52用の私の動作するDTです。 / { codec: max98357a@0{ compatible = "maxim,max98357a"; #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&sdmode_en>; sdmode-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; status = "okay"; }; sound { compatible = "simple-audio-card"; simple-audio-card,name = "SAI3 MAX98357A"; simple-audio-card,format = "i2s"; simple-audio-card,widgets = "Speaker","Speakers"; simple-audio-card,routing = "Speakers","Speaker"; simple-audio-card,bitclock-master = <&cpu_dai>; simple-audio-card,frame-master = <&cpu_dai>; cpu_dai: simple-audio-card,cpu { sound-dai = <&sai3>; clocks = <&clk IMX8MP_CLK_SAI3>; clock-names = "mclk"; //system-clock-frequency = <&clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; dai-tdm-slot-num = <2>; dai-tdm-slot-width = <32>; }; codec_dai: simple-audio-card,codec { sound-dai = <&codec>; //clocks = <&clk IMX8MP_CLK_SAI3>; }; }; }; &sai3{ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>; #sound-dai-cells = <0>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; assigned-clocks = <&clk IMX8MP_CLK_SAI3>, <&clk IMX8MP_AUDIO_PLL1>, <&clk IMX8MP_AUDIO_PLL2>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>, <&clk IMX8MP_AUDIO_PLL1_OUT>; // Try common MCLK rates that divide well to 48 kHz multiples // Option A: 24.576 MHz (very common for MAX98357A + 48 kHz) assigned-clock-rates = <24576000>, // PLL2 for 48 kHz <22579200>; // PLL1 for 44.1 kHz // Option B (if 44.1 kHz needed later): use PLL1 + 22579200 //assigned-clock-rates = <22579200>; fsl,sai-asynchronous; fsl,sai-mclk-direction-output; status = "okay"; }; カーネルを6.18.20に変更した後、SAI3がプローブされず、サウンドカードが認識されなくなりました。 ブートログには以下の通りです: プラットフォームサウンド:ディファードプローブ 保留中:asoc-simple-card: parse error カーネル6.6.52から6.18.xへの変更で、DT構文にはどのような変更がありますか?関連する情報は何も見つかりませんでした。構文解析エラーをどう調査すればいいですか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x こんにちは、 DMESGのログを共有していただけますか? よろしくお願いいたします。 Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x こんにちは、ホルヘさん。 dmesgログと実行中のデバイスツリー(./dtc -I fs -O dts /proc/device-tree > /tmp/running.dts)添付。 Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x こんにちは、 私は一歩前進した。カーネル設定オプションCONFIG_IMX_AIPSTZ=yを有効にした後、サウンドカードデバイスが使用可能になりました。 sai3ノードはaips5のサブノードであるため、デバイスツリーでaips5も有効にする必要がありました。 &aips5 { status = "okay"; }; 次のようなエラーメッセージが表示されました。 [ 13.081746] fsl-sai 30c30000.sai: ASoC error (-110): at snd_soc_dai_hw_params() on sai-tx-rx [ 13.090223] sai-tx-rx-HiFi: ASoC error (-110): at __soc_pcm_hw_params() on sai-tx-rx-HiFi speaker-test -c 2 -r 48000 -t sine 2>&1 | head -20 [ 31.368187] fsl-sai 30c30000.sai: ASoC error (-110): at snd_soc_dai_hw_params() on sai-tx-rx [ 31.376682] sai-tx-rx-HiFi: ASoC error (-110): at __soc_pcm_hw_params() on sai-tx-rx-HiFi Unable to set hw params for playback: Connection timed out speaker-test 1.2.11 Playback device is default Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 24 to 131072 Period size range from 12 to 16383 Periods = 4 Setting of hwparams failed: Connection timed out Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x 了解しました。音声は正常に動作しています。 私のカーネル設定: CONFIG_SND_IMX_SOC=m CONFIG_SND_IMX_SOC=m CONFIG_SND_SOC_FSL_SAI=m CONFIG_SND_SOC_FSL_UTILS=m CONFIG_IMX_AIPSTZ=y デバイスツリーの部分: /{ codec: max98357a@0{ compatible = "maxim,max98357a"; #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&sdmode_en>; sdmode-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; status = "okay"; }; sound { compatible = "simple-audio-card"; status = "okay"; simple-audio-card,name = "SAI3 MAX98357A"; simple-audio-card,format = "i2s"; simple-audio-card,widgets = "Speaker", "Speaker Ext"; simple-audio-card,routing = "Speaker Ext", "Speaker"; simple-audio-card,bitclock-master = <&cpu_dai>; simple-audio-card,frame-master = <&cpu_dai>; cpu_dai: simple-audio-card,cpu { sound-dai = <&sai3>; clocks = <&clk IMX8MP_CLK_SAI3>; clock-names = "mclk"; //system-clock-frequency = <&clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; dai-tdm-slot-num = <2>; dai-tdm-slot-width = <32>; }; codec_dai: simple-audio-card,codec { sound-dai = <&codec>; }; }; }; &sdma2 { status = "okay"; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin"; }; &aips5 { status = "okay"; }; &audio_blk_ctrl { status = "okay"; assigned-clocks = <&clk IMX8MP_AUDIO_PLL1>, <&clk IMX8MP_AUDIO_PLL2>; assigned-clock-rates = <393216000>, <361267200>; }; &sai3{ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>; #sound-dai-cells = <0>; assigned-clocks = <&clk IMX8MP_CLK_SAI3>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK2>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK3>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3"; dmas = <&sdma2 4 2 0>, <&sdma2 5 2 0>; dma-names = "rx", "tx"; fsl,sai-asynchronous; fsl,sai-mclk-direction-output; status = "okay"; }; デバイスツリーのベースはimx8mp.dtsiです。
View full article
S32dsライセンスの有効期限が切れました 2107-4B0B-EBCA-A774 ARM v2.2用S32デザインスタジオ 申請延長激活時間 申请延長激活 Re: S32ds license expired こんにちは、 お客様のS32DSライセンスが延長されました。以前のコードを使用して、S32DSを再度有効化してください。
View full article
FS26 低压差线性稳压器(LDO) 关闭问题 Hello 我使用的是 FS26 和 S32K358。 我使用 FS26 的 VLDO2 作为 MCU 的电源,使用 FS26 的 VLDO1 作为 CAN 收发器的电源。 当 MCU 处于 CAN 通信状态时,FS26 的 VLDO 会关闭,从而切断 MCU 的电源。 (这种情况随机发生,大约每 1 至 8 小时发生一次。) 只有当 FS26 的电源被切断再恢复后,VLDO 才能恢复正常工作。 这个问题出现在所有电路板上,而不仅仅是单个电路板上,而且当 CAN 通信未进行时不会出现此问题。 问题发生时的状态如下: Vpre 6V O VDIG 1.6VO VBOS 5V O VLDO2 X VLDO1 X VCORE X DFS已通过OTP禁用。 我想了解 FS26 目前的状况以及导致这种情况发生的原因。 Re: FS26 LDO Off Issue 你好kjy106906 再会! 监视程序是否已启用? 以下各项的值是多少: FS_STATES FS_GRL_FLAGS FS_OVUV_REG_STATUS M_REG_FLG 故障发生后立即出现 M_STATUS 吗? 你检查过FS26是否显示任何UV或OV标志吗? 另外,能否分享一下您的 M_STATUS? 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: FS26 LDO Off Issue @RafaR 感谢您的回复。 遗憾的是,MCU 已从 SBC 获得电源,但由于 VLDO 已关闭,因此无法进行通信。 必须切断并重新接通电路板电源,MCU才能正常工作。 监视窗口是无限的。 Re: FS26 LDO Off Issue 你好 kjy106906 再会! 看起来 FS26 模拟前端仍然通电,但为系统供电的内部电源树已被禁用。 一种可能的解释是,在受监测的调节器(VCORE、VLDO1、VLDO2)中检测到了故障,并且配置的反应禁用了调节器输出。FS26 文档表明,根据配置的故障响应设置,调节器在发生故障后可以保持禁用状态。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: FS26 LDO Off Issue db16122_0-1785211448726.png 请参考PMIC初始化过程进行调试。AN13431 NXP 针对 TI TMS570 系列 MCU 的 PMIC 解决方案应该会有所帮助。 Re: FS26 LDO Off Issue 谢谢 @RafaR 这是一个重要的问题,所以我希望您能回复。 我想确切地了解 FS26 的状态以及它失败的原因。 问题发生时,我使用外部工具读取了寄存器。 FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MIRRORCMD:0x1c]W:0x001d; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MIRRORDATA:0x1d]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [ID_VOTP:0x1D]R:0x00 FS26 [FS_WDW_DURATION:0x0b]W:0xd08b; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_NOT_WDW_DURATION:0x0c]W:0x2f74; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_FLG:0x07]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_MSK:0x08]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_FLG:0x05]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_MSK:0x06]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_FLG:0x03]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_MSK:0x04]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_FLG:0x09]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_MSK:0x0a]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_STATUS:0x02]R:0x5020; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_FLG:0x0b]R:0x0005; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_MSK:0x0c]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_OVUV_REG_STATUS:0x10]R:0x1544; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_INTB_MASK:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY1:0x14]R:0x03c3; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY2:0x15]R:0x0010; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_1:0x12]R:0xf000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_GRL_FLAGS:0x00]R:0x5000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_DEVICEID:0x00]R:0x65d8; CRC[MOSI:0x00; MISO:0x00] FS26 [M_PROGID:0x01]R:0x0105; CRC[MOSI:0x00; MISO:0x00] FS26 [M_STATUS:0x02]R:0x5020; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_FLG:0x03]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_MSK:0x04]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_FLG:0x05]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_MSK:0x06]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_FLG:0x07]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_MSK:0x08]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_FLG:0x09]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_MSK:0x0a]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_FLG:0x0b]R:0x0005; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_MSK:0x0c]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_SYS_CFG:0x0d]R:0x0001; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_CFG:0x0e]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_CFG:0x0f]R:0x0002; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_CFG:0x10]R:0x0202; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_CTRL1:0x11]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_AMUX_CTRL:0x13]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG1:0x14]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG2:0x15]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG3:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CTRL:0x17]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MEMORY0:0x18]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MEMORY1:0x19]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_GRL_FLAGS:0x00]R:0x5000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_WDW_DURATION:0x0b]R:0xd08b; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_NOT_WDW_DURATION:0x0c]R:0x2144; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_WD_TOKEN:0x0e]R:0x5ab2; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_ABIST_ON_DEMAND:0x0f]R:0x0040; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_OVUV_REG_STATUS:0x10]R:0x1544; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_1:0x12]R:0xf000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_2:0x13]R:0x035f; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY1:0x14]R:0x03c3; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY2:0x15]R:0x0010; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_INTB_MASK:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_LP_REQ:0x18]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_LDT_LPSEL:0x19]R:0x0000; CRC[MOSI:0x00; MISO:0x00] 当出现问题时,我会附上波形图。 kjy106906_0-1785205262839.png 蓝色 VSUP / 红色 VBOS / 绿色 RSTB / 黄色 VDIG kjy106906_1-1785205354126.png 蓝色 VSUP / 红色 VPre / 绿色 Vcore / 黄色 RSTB
View full article
LPC5516 SRAM I am using the LPC5516 chip. I want to write the chip program into SRAM using the SWD protocol and run it. However, it was discovered that the program was not written to SRAM. I have read the chip's IDCODE through SWD and completed some initializations, such as halting the kernel. After writing the program to 0x04000000 and reading back at that address, it was found that the data read was 0. Through the example code, I enabled some AHB SRAM clocks using the SWD protocol, such as: SYSCON->AHBCLKCTRLSET[0] = SYSCON_AHBCLKCTRL0_SRAM_CTRL1_MASK | SYSCON_AHBCLKCTRL0_SRAM_CTRL2_MASK; However, after executing the above program, the program readback value written to SRAM is still 0. Could you please help analyze the reasons for this situation? LPC551X-S1X Re: LPC5516 SRAM 1. I have try to write 0x20000000 with my hex, same as write 0x4000000 2. I have compare the JLINK  SWD waveforms, I can't understand the  waveforms, it‘s Weird ,before set 0xE000EDF0, it send something with ack error, and then set 0xE000EDF0 with 0xA05F0003, then read 0xE000EDF0, the value is 0x03030003。 my SWD waveforms is read the chip IDCODE, and then init the chip, when i set 0xE000EDF0 with 0xA05F0003, read back is 0x0. Could you please give me a Jlink script? i want to know what is send before enter debug mode. before enter debug mode, What needs to be enabled for this chip? or some register need to set? JLINK.png err.png     Re: LPC5516 SRAM Hello @1123HENRY  1) Please try programming the SRAM at address 0x20000000 instead of the SRAMX region at 0x04000000. 2) Please use MCUXpresso IDE or LinkFlash with an external debugger to program the SRAM, capture the SWD signals/waveforms, and compare them with the waveforms observed in your programmer.  BR Alice Re: LPC5516 SRAM I used my own chip to send SWD instructions to debug the LPC5516 chip. I attempted to write to the 0xE000EDF0 register, trying to enable debugging, but it didn't work. Then, I attempted to write to the SRAM, but found that the write operation failed. It seems that the device did not enter the debugging mode. test1.png test2.png   test3.png test4.png      Re: LPC5516 SRAM more error log to share? Re: LPC5516 SRAM Hi @1123HENRY  Please have a look at the thread below, as it may be helpful. Restricted SWD access - NXP Community BR Alice
View full article
imx93 cannot load elf in mcimx93evk_ethosu_apps (sdk2.14) I need try sdk2.14 demo: mcimx93evk_ethosu_apps after the elf is get .I load this elf to m33. it failed:                         remoteproc remoteproc0: Registered carveout doesn't fit da request [ 236.970879] rproc-virtio: probe of rproc-virtio.1.auto failed with error -12 [ 236.984471] remoteproc remoteproc0: Registered carveout doesn't fit da request [ 236.992036] rproc-virtio: probe of rproc-virtio.2.auto failed with error -12 I donnot know what happen. Re: imx93 cannot load elf in mcimx93evk_ethosu_apps (sdk2.14) Hi @bighero77, Thank you for contacting NXP Support. According to the README file, the application required for your use case is ethosu_apps_rpmsg, not ethosu_apps. README extract: 4. Test process --------------- 4.1 Example ethosu_apps_rpmsg is built as .out or .elf and installed in rootfs. In Linux command line, user can run the following command to do inference for the model. #./inference_runner -d /dev/ethosu0 -n mobilenet_v1_1.0_224_pb_int8_vela.tflite -i stopwatch.bmp -l labels.txt -o output_data_detection -t 1080000000 When the examples runs, the log and inference result would be seen on the terminal as below. Send Ping Send version request Send capabilities request Capabilities: version_status:1 version:{ major=0, minor=0, patch=0 } product:{ major=6, minor=0, patch=0 } architecture:{ major=1, minor=0, patch=6 } driver:{ major=0, minor=16, patch=0 } macs_per_cc:8 cmd_stream_version:0 custom_dma:false Create network Create inference Wait for inferences Inference status: success Detected: jinrikisha, confidence:70 Detected: horse cart, confidence:70 Detected: academic gown, confidence:70 Detected: howler monkey, confidence:70 For other demos, such as face recognition, please refer to the user manual. 4.2 Example ethous_apps is built as .bin. In U-Boot prompt, user can run the following command to do inference for the conv2d op model. u-boot=> tftp 0x80000000 ethosu_apps.bin;cp.b 0x80000000 0x201e0000 0x20000;bootaux 0x201e0000 0 When the example runs, the log and inference result would be seen on the terminal as below. Initialize Arm Ethos-U Inference status: success Based on the documentation, if your goal is to run inference from Linux using /dev/ethosu0, then ethosu_apps_rpmsg is the correct application to use. Best regards, Alejandro Garcia
View full article
Windows 10/11 IoT EnterpriseのIMX95LPD5EVK-19サポートおよびインストール手順 NXPチームの皆様、こんにちは。 弊社では、以下の詳細を含むNXP i.MX95 19mm×19mm評価キットをご用意しております。 EVK: IMX95LPD5EVK-19 幅木マーキング:IMX95LPD5BB-19 REV B 想定されるインストール対象: オンボードeMMC このボードにWindows 10/11 IoT Enterprise ARM64 、できればWindows 10/11 IoT Enterprise LTSC 2024をインストールしたいと考えています。 Windows 11 IoT EnterpriseがIMX95LPD5EVK-19でサポートされているか確認していただけますか? 対応されている場合は、公式のBSP、必要なソフトウェアパッケージ、そしてWindowsをオンボードeMMCにインストールするための参考資料として完全なインストールまたはフラッシュ手順を共有してください。 私たちは特に、IMX95LPD5EVK-19用の公式かつ基板検証済みのガイドを探しています。 ありがとう。 よろしくお願いいたします。 ジャシム Windows 10 IoT Enterprise Re: Windows 10/11 IoT Enterprise support and installation procedure for IMX95LPD5EVK-19 @yipingwangさん、確認していただきありがとうございます。 現在、IMX95LPD5EVK-19 用の Windows 10/11 IoT Enterprise BSP やボード検証済みのインストール手順は公開されておらず、公式にサポートされているものもないことを理解しています。 FUTUREのi.MX95サポートについては、NXPのWindows IoT BSPリリースページを注視していきましょう。 ありがとう。 Re: Windows 10/11 IoT Enterprise support and installation procedure for IMX95LPD5EVK-19 現時点では、IMX95LPD5EVK-19 用の、一般公開されている、または公式に文書化された Windows 10/11 IoT Enterprise BSP は見つかりません。現在のNXPのWindows IoTサポートページおよびMicrosoft Windows IoTサポートマトリックスには、i.MX8ファミリーデバイスおよびi.MX93 EVKのサポートが記載されていますが、i.MX95 EVKは記載されていません。したがって、現時点ではIMX95LPD5EVK-19向けの公式Windowsインストール手順、BSPパッケージ、ボード検証済みのフラッシュガイドを提供することはできません。もしNXPを通じてi.MX95のWindowsサポートが利用可能になる場合、NXPのWindows IoT BSPリリースページおよび付随するリリースノートで公開される見込みです。 https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/windows-10-11-iot-enterprise-for-i-mx-applications-processors:IMXWIN10IOT
View full article
広告モデル こんにちは MRFE6VS25NR1のADSモデルをダウンロードしましたが、このエラーで動作しませんでした モデルFSL_MRFE6VS25N_FET2。FET2M1'(ファイル『C:/Users/hadih/OneDrive/Desktop/NXP/MRFE6VS25N_Level1_Rev1_DK//circuit/models/fsl_MRFE6VS25N_pkg_netlists.net』で定義)31行目付近):`FSLRFPK_FET2_v1`は未定義のプリミティブデバイスです。 壊れていますか? これは要素ページです https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/1-8-2000-mhz-25-w-50-v-wideband-rf-power-ldmos-transistors:MRFE6VS25N Re: ads model こんにちは、hadi3000さん。 良い一日! これは、単一の製品モデルを使う前にRF高出力モデルキットを取り付けていないことのようです。 https://www.nxp.com/products/rf/rf-high-power-models/models-for-ads-keysight-advanced-design-system:RF_HIGH_POWER_MODELS_KEYSIGHT 私たちのモデルは二つの部分で構成されています: RF高出力モデルキット 製品モデル設計キット デバイスのシミュレーションには、両方の部品が必要です。 すでに高出力モデルキットをインストールしている場合は、「 トラブルシューティングADSInstallation Problems 」を確認し、FSL_TECH_INCLUDE要素が最上層回路に存在しているか確認してください。 また、よくある設置エラーのセクションもこちらでご覧いただけます。 https://www.nxp.com/docs/en/companyinformation/OVERVIEW_MDL_ADS_DESIGN_KIT.pdf この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。
View full article
Linux QBMan QMan driver safe_copy_dqrr The Linux SDK for QorIQ processors includes qman_high.c in the driver staging tree. This includes the function safe_copy_dqrr(), which the comments say is ensuring reads reach QBMan in order and //preventing a WRAP transaction to be seen by the QBMan//. I presume this is referring to an AXI WRAP burst transaction, rather than anything to do with the DQRR index wrap. Can anyone explain why this is problem that needs to be made safe? Thanks in advance. QorIQ LS1 Devices Re: Linux QBMan QMan driver safe_copy_dqrr Hello, Yes — the comment is most plausibly about a bus/cache-line WRAP transaction , not the DQRR producer/consumer index wrapping. The reason it needs to be “safe” is that a DQRR entry is not ordinary RAM. It is a QBMan portal structure whose contents are produced by QMan, possibly stashed into the CPU cache, and consumed by software using the valid bit in the VERB byte . The DPAA manuals state that even though QMan updates a DQRR entry atomically, a GPP core’s reads may not observe all bytes of the entry changing at the same time; software must ensure the VERB byte containing the valid bit is loaded before the rest of the DQRR entry. So safe_copy_dqrr() is trying to avoid this unsafe pattern: CPU wants to copy DQRR entry -> compiler/CPU/cache subsystem turns that into a burst or cache-line fill -> transaction reaches QBMan as a WRAP-style read -> QBMan/interconnect may see/read beats in an order different from the logical field order -> software may observe a valid VERB byte associated with stale or not-yet-visible entry data That matters because the valid bit is the synchronization point. With DQRR entry stashing enabled, the documentation specifically warns that DQRR.PI can be updated before the associated DQRR entry stash arrives in the processor cache, creating a race; therefore software should use the valid bit in the DQRR entries, not DQRR.PI , to detect production. The valid bit itself is an alternating-polarity bit that toggles each time the ring wraps from the last entry back to entry 0.   Regards Re: Linux QBMan QMan driver safe_copy_dqrr Thanks for you reply. If I understand correctly, with DQRR stashing disabled the CPU read of a DQRR entry (after a cache invalidation and memory barrier) triggers a cache line fill but this can be "broken" by a AXI wrap burst transaction while the DQRR entry is being updated? I'm using LS1046A RDB and can see no reference to this behaviour in NXP manuals. Is it documented somewhere? I'm looking for a reference to justify this safe copy function. With DQRR stashing enabled, QMan writes the DQRR entry to cache. Is this subject to the same issue? Thanks again for your help.
View full article
IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error Hi, When using the LPSPI EDMA transfer API, sometimes when my callback is called from the SDK (when EDMA is complete), if I look at the LPSPI SR register, about one in 5-10 times it has the REF bit set (Read error flag / overflow).  My SPI clock is running at 500Khz.  I'm not really sure why I'm  getting this SPI RX overflow as the SPI clock is nowhere near fast enough to cause DMA to not be able to keep up.  Is there any way I can troubleshoot this and has anyone else seen this problem?  The data always looks correct even when I get the overflow (I zero my buffer between each transfer, so I know it's not old stale data I'm looking at).  I'm doing simultaneous TX/RX using the transfer API, and doing the transfer every 4ms.  There shouldn't be any issues with timing. Thanks, -m Re: IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error Hi @nxp16 , Thank you so much for your interest in our products and for using our community. SR[REF] indicates a receive FIFO overflow. If this flag is really set during a transfer, the recommended recovery is to stop the transfer, empty the RX FIFO, clear REF, and restart the transfer. However, at 500 kHz, this does not look like a normal DMA bandwidth issue, assuming the RX EDMA channel is already prepared/enabled before the SPI clocks start. Since the received data is still correct, I suggest first check whether REF is a stale flag or is being set by the transfer start/stop sequence. For troubleshooting, please try the below: 1. Clear SR[REF] before starting each new transfer. 2. Make sure RX DMA is enabled before TX starts generating clocks. 3. Check whether LPSPI is disabled/re-enabled between transfers. If yes, apply the applicable errata workaround: clear REF after enabling LPSPI, or reset LPSPI before re-enabling. mayliu1_0-1784877413675.png Wish it helps you Best Regards May Re: IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error The errata mentions two workarounds, clearing the bit in SR, and resetting the peripheral.  Unfortunately, the errata seems to be incorrect about the first one as the SDK already does that and it doesn't workaround the problem.  Unfortunately, for me, resetting the peripheral is not an option as I would have to reconfigure everything afterward (it clears ALL registers).  For now, I'm going to assume that if DMA completed successfully and we get a REF error, then it's a false error and I'll just ignore it. Thanks, -m Re: IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error Unfortunately, the SDK is disabling and enabling the LPSPI peripheral between transfers and I have no control over that. Thanks, -m Re: IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error Hi @Mike_M3 ,  Please check whether LPSPI is disabled and re-enabled between transfers. If yes, avoiding this sequence would be preferable. If disable/re-enable is required, please follow the documented workaround. After clearing REF, please verify the RX FIFO state and the received data before starting the next transfer, and log/count this condition for further debug. Best Regards, May Re: IMXRT1172 LPSPI with EDMA random intermittent SPI SR = REF error Thanks for the update. The SDK may disable/re-enable LPSPI internally, but the application should still ensure that the previous LPSPI bus transfer has completed before starting the next transfer. The EDMA callback only indicates DMA completion. If the next transfer is started immediately from the EDMA callback while SR[MBF] is still set or SR[TCF] is not set, the SDK may enter the next transfer setup while LPSPI is not fully idle. Please wait for SR[TCF]=1 or SR[MBF]=0 before submitting the next LPSPI EDMA transfer. 
View full article
MCUX 25.6.136、newlib-nano、& swprintf 未定義 MCUX 25.6.136でswprintfへの未定義参照が発生しています。& newlib-nano。newlibも試してみましたが、結果は同じでした。 いろいろ調べてみたところ、newlib-nano/newlib に上流の問題が見つかりました。https: //sourceware.org/pipermail/newlib/2024/021012.html NXPが私の推測を裏付けてくれるか気になっています。Newlib-nanoのバンドル版にもこの問題があるのではないかと。もしそうなら、newlib-nano/newlibの新しいバージョンを取り入れて修正する案は考えられていますか? - コナー Re: MCUX 25.6.136, newlib-nano, & swprintf undefined こんにちは、 @Condyさん ご質問ありがとうございます。 問題を再現するための簡単なプロジェクトを送っていただけませんか?ありがとう。 BR アリス Re: MCUX 25.6.136, newlib-nano, & swprintf undefined ここに2つのプロジェクトがあります。 - MCUXv11.9.1.2170からの1つswprintfが定義されており、プロジェクトがコンパイルされる場所。(1064) - MCUXv25.6.136からの1つswprintfが未定義で、プロジェクトがコンパイルされない場合。(1166)
View full article
MCUX 25.6.136, newlib-nano, & swprintf undefined I'm experiencing an undefined reference to swprintf with  MCUX 25.6.136 & newlib-nano. I've tried newlib as well and same result.  After some digging I've found an upstream issue with newlib-nano/newlib: https://sourceware.org/pipermail/newlib/2024/021012.html  I'm wondering if NXP can corroborate my guess that the bundled version of newlib-nano contains this issue. If that's the case Is a fix via incorporating a newer version of newlib-nano/newlib on the agenda? - Connor Re: MCUX 25.6.136, newlib-nano, & swprintf undefined Here's 2 projects. - One from MCUXv11.9.1.2170 where swprintf is defined and the project compiles. (1064) - One from MCUXv25.6.136 where swprintf is undefined and the project doesn't compile. (1166) Re: MCUX 25.6.136, newlib-nano, & swprintf undefined Hello @Condy  Thanks for your question.  Could you please send a simple project to reproduce the issue. Thank you. BR Alice
View full article
i.MX 8M Mini SAI: BCLKが停止する前にI2Cコーデック制御を実行する場所(PREEMPT_RT) We are developing a system using an i.MX 8M Mini connected to an external audio codec (controlled via I2C) through SAI (I2S), running a kernel with the PREEMPT_RT configuration. We need to perform codec operations (I2C) before the I2S BCLK stops. Where would be the best place to insert this I2C handling? Re: i.MX 8M Mini SAI: Where to perform I2C codec control before BCLK stops (PREEMPT_RT) 最適な場所:FSL-SAI CPU DAIトリガー(STOP)が実行される前にASoCの停止パスに「必須実行」操作を配置してください。できればコーデック/コンポーネントのストップトリガーコールバック、またはCPUのDAI停止前に注文されたマシン-ドライバリンク/コンポーネントトリガーコールバックとして。 なぜか:8M Mini i.MX NXP fsl_sai_trigger()はFIFO DMA要求や割り込みを無効にし、その後fsl_sai_config_disable()を呼び出してFSL_SAI_CSR_TEREをクリアし、現在のフレームが完成するまで待つことで処理SNDRV_PCM_TRIGGER_STOP。マスターモードではSAIブロックをリセットします。それは、SAIによって生成されたBCLKが停止/無効化される時点です。i.MX8MM SAIドライバーはDAI操作で.trigger = fsl_sai_trigger、.hw_free = fsl_sai_hw_freeとして登録されているhw_freeため、「BCLKが停止する前に」という要件はすでに遅すぎます。 ボード固有のBSPハックでない限り、fsl_sai_trigger()の中にコーデックI2Cを直接追加することは避けるべきです。汎用CPU-DAIドライバーを1つのコーデック/ボードポリシーに結合させます。Linux/NXP ASoCの分割は、コーデック制御I/Oをコーデックドライバに、CPUインターフェース制御をプラットフォーム/CPU DAIドライバに保持することを意図しています。NXPのドキュメントでは、I2Cを経由したコーデック制御I/OをASoC DAI操作を通じてエクスポートするコーデック・ドライバ機能として説明しています。 2つの実用的な実装パターン: コーデック DAI .trigger() /コンポーネント .trigger() STOP 用 SNDRV_PCM_TRIGGER_STOP / SUSPEND / PAUSE_PUSH にコーデックレジスタ書き込みを追加します。 このコールバックが CPU DAI fsl_sai_trigger(STOP の前に実行されるようにしてください。 現在のASoCでは、デフォルトのストップオーダーはDAI -> コンポーネント->リンクであり、DAIの反復はCPUのDAIの次にコーデックDAIなので、CPUのDAIが先の場合はコーデックDAIトリガーが遅すぎる可能性があります。 コンポーネントトリガーを使い、保持/デフォルト停止順序を保持すると、コンポーネント停止はリンクコールバックの前、DAI後はデフォルト順序でのみ実行されます。あるいは、カーネルが対応しているならDAIリンクのtrigger_stop順序を適切に設定することもできます。 マシンドライバー snd_soc_ops.trigger()/ リンクトリガー 停止コマンド用に、マシンドライバの.trigger()にボード固有のコーデックI2Cシーケンスを入れます。 ASoCトリガーのご注文を使い、リンクレベルのストップがDAIストップの前に実行されるようにします。カーネルは、停止順序 Component -> DAI -> Link として文書化された SND_SOC_TRIGGER_ORDER_LDC を公開し、デフォルトの停止順序は DAI -> Component -> Link です。選択したコールバックを fsl_sai_trigger(STOP) の前に配置するように順序を選択してください。 シーケンスが一般的なコーデックの動作ではなく、ボード/システムのポリシーである場合、ここが最もクリーンな場所となることが多い。 重要なPREEMPT_RT:通常のI2C転送はタスクコンテキスト操作であり、カーネルI2Cのドキュメントによると、I2Cプロトコル操作はタスクコンテキストでのみ使用可能であり、特別な遅延シャットダウンケース向けにオプションのアトミック転送フックが用意されています。したがって、PCM/ASoCパスが非アトミックとして構成され、カーネル内でコールバックコンテキストが検証されている場合を除き、アトミックPCMトリガーパスからブロッキングI2Cを実行しないでください。トリガーパスがアトミックな場合は、より安全なアーキテクチャを使用してください。コーデックの状態を早めに準備するか、BCLKを連続/ゲート状態に後から維持するか、CPU DAIトリガーで生のI2Cを実行するのではなく、スリープ可能な順序付きストップパスに操作を移動してください。
View full article