Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
重複した変数宣言 私はLPC824ボードとダウンロードしたlpcxpresso824max_new_projectを使用して新しいプロジェクトに取り組んでいます。ビルド、ダウンロード、デバッグは問題なく完了しました。まず最初に、3桁の7セグメントLEDディスプレイを実装しようとしています。ペリフェラルに宣言を追加しました。そして、main.c に更新ルーチンがあります。ビルド時に、重複した変数宣言という2つのエラーが発生します。それらをコメントアウトすると、「未宣言の変数」というメッセージが表示されます。変数名を変更しても、同じ重複エラーが発生します。プロジェクト内のすべてのソースファイルを調べましたが、重複は見つかりませんでした。エラーメッセージの一つは次のとおりです。 /アプリケーション/MCUXpressoIDE_25.6.136/ide/plugins/com.nxp.mcuxpresso.tools.macosx_25.6.0.202501151204/tools/bin/../lib/gcc/arm-none-eabi/14.2.1/./../../../arm-none-eabi/bin/ld: ./source/ペリフェラル.o:/Users/julian/Documents/MCUXpressoIDE_25.6.136/workspace/lpcxpresso824max_new_project/Debug/../source/ペリフェラル.h:57: 'CA_LUT'の複数定義; ./source/main.o:/Users/julian/Documents/MCUXpressoIDE_25.6.136/workspace/lpcxpresso824max_new_project/Debug/../source/ペリフェラル.h:57: ここで最初に定義されました Re: Duplicate variable declarations こんにちは、 あなたのペリフェラルを教えていただけますか?ファイルとペリフェラルについて?または、CA_LUTの宣言をどのように追加したか説明してください。 main.cでどのように使ったのか教えていただけますかCA_LUT? どのファイル名に[#include "peripherals.h"】があるのか教えてください。それらのファイルのヘッダーはmain.cに含まれていますか? 敬具、ルイス Re: Duplicate variable declarations こんにちは、 ペリフェラルでCA_LUTを定義しているように、そうかもしれません。メインとペリフェラルの両方です。重複エラー「複数の定義」が発生するファイルを呼び出します。 宣言をペリフェラルにだけ加えるのを手伝っていただけますかCA_LUTペリフェラルの代わりに、そして再試行する。 ペリフェラルに同様の申告を他にも持っていますか?同じエラーが出ているのですか?もし持っているなら、ペリフェラル.c にも移動してください。 7セグメントを外部ペリフェラルと考えてください。 調査結果を教えてください。 よろしくお願いいたします。 Re: Duplicate variable declarations これはペリフェラルのエントリーです。どちらのエラーについても // 数字0~9のルックアップテーブル(0=オン、1=オフ) const uint32_t CA_LUT[10] = { //0: A、B、C、D、E、Fはオン、G、DPはオフ ~((1< // 1: B、Cはオン ~((1< // 2: A、B、D、E、Gがオン ~((1< // 3: A、B、C、D、Gがオン ~((1< // 4: B、C、F、Gがオン ~((1< // 5: A、C、D、F、Gがオン ~((1< // 6: A、C、D、E、F、Gがオン ~((1< // 7: A、B、Cはオンです ~((1< // 8: 全セグメントON (AG) ~((1< // 9: A、B、C、D、F、Gがオン ~((1< }; // 1桁目、2桁目、3桁目に印刷される現在の数値を保持するグローバル変数 volatile uint8_t display_buffer[3] = {1, 2, 3}; // 例: "123" と表示されます どちらのエラーもmain.cで使用されています。:- uint8_t numeric_value = display_buffer[current_digit]; uint32_t segment_pattern = CA_LUT[numeric_value]; #include "ペリフェラル" 以下のファイルにのみ出現します: - main.c、ペリフェラル、 先ほども言いましたが、私はCodeWarriorから来ているので、MCUXの知識はおそらく危険です(?????)。7セグメントディスプレイがペリフェラル(peripherals.h )かどうかはわかりませんc) またはピン数の宣言 (pin_mux.h)そしてc)、でもそれは後で解決できます。
查看全文
i.mx8M Plus 上的 wm8962 错误 我们正在设计基于 NXP i.MX 8M Plus (i.MX8MP) 处理器和 Wolfson WM8962 音频编解码器的定制电路板。我们目前正在将驱动程序移植到Linux 内核 5.4。以下是错误日志和我们的 DTS(设备树源)配置。 日志: [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS:   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ 根据我们的分析,当内核尝试初始化 imx-wm8962 机器驱动程序时,I2C 总线上的 WM8962 编解码器尚未完成探测/注册。WM8962 之后才会完成初始化。这种探针顺序不一致会导致驱动程序初始化失败并出现错误。 请问您能否帮忙分析一下这个问题,并提出解决此问题的建议? IMX8MPLUS音频软件 NXP_MICR Android Linux Re: wm8962 on i.mx8M Plus error 当编解码器或 SAI 平台设备未准备就绪时,返回 -EPROBE_DEFER 在你的 imx-wm8962.c 中探测路径,区分以下几种情况: 缺少/无效的 DT 句柄 → 实际错误,返回 -EINVAL; 句柄存在,但引用的设备尚未注册 → 依赖项未准备就绪,返回 -EPROBE_DEFER。 例如,从概念上讲: codec_np = of_parse_phandle(np, "audio-codec", 0); 如果 (!codec_np) { dev_err(&pdev->dev, "音频编解码器缺失或无效\n");         返回-EINVAL; } codec_dev = of_find_i2c_device_by_node(codec_np); 如果 (!codec_dev) { dev_info(&pdev->dev, "编解码器设备未就绪,延迟探测\n"); of_node_put(codec_np); 返回 -EPROBE_DEFER; } 同样适用于 CPU DAI / SAI 节点: cpu_np = of_parse_phandle(np, "audio-cpu", 0); 如果 (!cpu_np) { dev_err(&pdev->dev, "audio-cpu 缺失或无效\n");         返回-EINVAL; } cpu_pdev = of_find_device_by_node(cpu_np); 如果 (!cpu_pdev) { dev_info(&pdev->dev, "SAI 平台设备未就绪,延迟探测\n"); of_node_put(cpu_np); 返回 -EPROBE_DEFER; } 如果您保留当前的机器驱动程序,这是最直接的解决方法。 如果可用,请优先选择 Linux 5.4 fsl-asoc-card 路径。 对于 Linux 5.4 时代的 NXP 内核,compatible = "fsl,imx-audio-wm8962" 由 sound/soc/fsl/fsl-asoc-card.c 处理,其中显式地处理了 WM8962,包括编解码器 DAI 名称 "wm8962" 和 WM8962 时钟/FLL ID。还要验证 snd-soc-fsl-asoc-card.ko 是否已加载或已构建。 这意味着您应该避免让旧版/自定义 imx-wm8962 机器驱动程序和 fsl-asoc-card 尝试绑定同一个兼容字符串。推荐方法: 启用/使用 CONFIG_SND_SOC_FSL_ASOC_CARD; 确保您的声音节点使用兼容的 = "fsl,imx-audio-wm8962";  ; 除非您有意保留,否则请移除或禁用该兼容字符串的旧版/自定义 imx-wm8962 绑定。 确保DTS具有所需的SAI和编解码器DAI属性 您的编解码器节点大致符合预期形状:WM8962 的示例使用 compatible = "wlf,wm8962" 、 reg = <0x1a> 、 clocks、 supply properties 和 gpio-cfg。但是,请确认您的DTS中未显示的部件: &sai3 { #sound-dai-cells = <0>         pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>;         assigned-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT> assigned-clock-rates = <12288000>; /* 或板要求的 MCLK */         status = "okay"; }; 此外,编解码器通常还应公开以下内容: 编解码器:wm8962@1a { 兼容 = "wlf,wm8962"; reg =<0x1a> � #sound-dai-cells = <0> clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; 时钟名称 = "mclk"; …… }; 同时确保 reg_audio_pwr 引用的稳压器已定义、已启用,并且具有有效的电压范围。您的编解码器已被检测到,因此电源可能不是造成此特定错误的原因,但不良的电源或 MCLK 设置可能会导致以后的音频故障。 验证 MCLK 是否使能。 已知有一类 WM8962 启动问题,需要在音频机器驱动程序中启用编解码器 MCLK;据报道,在 imx_wm8962_probe() 中添加 clk_prepare_enable(codec_clk) 可以使 WM8962 音频工作。如果编解码器探测成功,但之后播放/捕获失败,请检查在编解码器初始化和流启动期间,SAI3 MCLK 是否实际存在于编解码器引脚上。 检查是否存在重复或冲突的声卡节点 确保只有一个活动的声音节点指向此编解码器/SAI 对,并且模型字符串是唯一的。在 NXP 社区调试中,还出现了类似的故障,即找不到编解码器平台设备,这与声卡命名/重复卡冲突有关。您的节点名称显示为 sound-wm8960-forenex,而兼容/型号为 WM8962;节点名称本身通常不起作用,但我建议您将其重命名以使其更清晰,并确认其他地方没有第二个已启用的 sound-wm8962 节点。 推荐的最短路径 如果可能,请使用适用于 Linux 5.4 的 fsl-asoc-card。 如果 WM8962 节点缺少 #sound-dai-cells = <0>;,请添加它。 确认 &sai3 已启用且已配置时钟/引脚控制。 如果保留自定义的 imx-wm8962 驱动程序,请修补失败的编解码器/CPU 查找路径,使其返回 -EPROBE_DEFER 而不是 -EINVAL。 确认 MCLK 已启用且存在。
查看全文
RTDのアップグレード時に予期せぬBSPの変更が発生する MCU:S32K148 144ピンパッケージ IDE:Windows 11 上の S32DS 3.6.6 RTOS: ベアメタル ドライバーモデル:非MCAL 既存プロジェクトをRTD v 3.0.0からQPL06にアップグレードした際、以下の変更が.mexに自動的に挿入されましたファイル(他にもあるが、他は平凡なものに思える) true 「enable_parallel_routing」は何をするものなのでしょうか? そして、「serdes」というタグが気になります。これはシリアライザー・デシリアライザーの略でしょうか?K148チップにはこの機能はありません。なぜこれが必要なのですか? Re: Unexpected BSP changes when upgrading RTD こんにちは、 @durga_choudhury さん、 S32DSの設定ツールは、S32Z、S32N、S32Gなど他のファミリ間で機能を共有しています。S32K MCUを選択すると、SERDESのシリアルライザー/デシリアライザーツール(DCD、IVT、QuadSPI、DDRなど)が無効化されているのがわかります。これはサポートされていないためです。 Julin_AragnM_0-1787152919605.pngJulin_AragnM_0-1787152919605.pngJulin_AragnM_0-1787152919605.png 構成enable_parallel_routing理由も同じです。「Project > Properties> S32 Configuration Tools > Enable Parallel Routing」から有効・無効にでき、Pinsツールを使ってファミリ間で共有されます。 Julin_AragnM_1-1787156448892.pngJulin_AragnM_1-1787156448892.pngJulin_AragnM_1-1787156448892.png ドキュメントでこれについての説明は見つかりませんでしたが、有効になると、ピンツールは信号ルーティング中に、同じ物理ピンを共有し、同じ設定値の同じポートレジスタに書き込みた場合にユーザーに促します。 このツールは、そのような信号をすべて同時に自動的にルーティングするかどうかを尋ねます。これを再現するには、S32K3でADCとWKPU信号共有設定値を設定することで再現できます。 Julin_AragnM_2-1787157425075.pngJulin_AragnM_2-1787157425075.pngJulin_AragnM_2-1787157425075.png 無効にすると、このプロンプトは表示されません。 よろしくお願いします、 ジュリアン Re: Unexpected BSP changes when upgrading RTD 最新情報をお知らせいただき、誠にありがとうございます。
查看全文
S32K344 FlexIO I2C DMA 你好, 我有一些关于S32K344上的FlexIO I2C DMA的问题,希望您能提供一些见解。 1. 当使用 FlexIO 模拟 I2C 时,Tx 长度设置为 尺寸 + 1。这是因为 “发送移位器在 SCL 引脚的最后一个下降沿加载一个额外的字” ? 1.png1.png1.png1.png 2.png2.png2.png2.png 2. 当使用DMA发送数据时, 主要循环计数 也设置为 大小 + 1。这是出于同样的原因吗?使用 DMA 时,所有传输的数据都来自 Master->TxData 。调用时 Flexio_I2c_Ip_MasterSendData ,应该 德州牛 长度为 大小 + 1 ,最后一个字节是否为 0xFF 或者 0x00 ? 3.png3.png3.png3.png 3. 用于接收数据, 主要循环计数 设置为 尺寸 – 1。这是为什么呢? 4. 我在 S32K344 上进行了测试,发现使用 DMA 进行 FlexIO I2C 接收数据时,接收到的数据比预期少一个字节。用示波器观察,最后一个字节的时钟信号只显示大约五六位波形。在 S32K312 上进行同样的测试没有问题。 S32K344 S32DS3.6.4 RTD700   BR, 杰森 Re: S32K344 FlexIO I2C DMA 嗨@Jason07 由于 FlexIO 不是专用的 I2C 外设,因此其实现需要额外的内部步骤才能正确完成 I2C 总线序列。 传输中的 Size + 1U 与 FlexIO 完成 I2C 帧序列所需的最终移位器负载有关。此次额外传输并不代表额外的有效载荷字节。相反,它被 FlexIO 硬件内部用于生成最终时钟脉冲,并将总线正确转换到传输结束状态。 接收端需要使用 1U 的尺寸,因为接收到的最后一个字节需要单独处理。这样,驱动程序就可以在正确的时间生成所需的 NACK 和 STOP 条件。 另外,请注意,使用 DMA 传输模式时,数据传输可能会受到缓存一致性问题的影响。为避免启用 数据缓存 时出现潜在问题,请确保用作 DMA TCD 源和目标的缓冲区分配在不可缓存的内存区域中。 调用 Flexio_I2c_Ip_MasterReceiveData() 函数时,无需增加 TRANSFER_SIZE 参数。驱动程序已经处理了接收序列所需的内部调整。 最后,在检查您的配置时,我注意到相同的 DMA 中断回调被分配给了两个 DMA 通道。根据 Flexio_I2c_Ip.c 中的描述,发送和接收应该使用不同的回调函数: FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() 用于 FlexIO 通道 0/1 TX FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() 用于 FlexIO 通道 0/1 RX BR,VaneB Re: S32K344 FlexIO I2C DMA 您好@VaneB 我找到了“单独处理最后一个接收到的字节”的代码。 然而,关于发送方面我还有一个疑问。使用中断驱动发送时,数据长度设置为 Size + 1。发送过程中,代码会检查是否是最后一个字节;如果是,则发送 0xFF 或 0x00。实际发送的数据长度仍然是 Size。但是,使用 DMA 发送时,DMA 会从发送缓冲区复制 Size + 1 个字节,并且在 Flexio_I2c_Ip_MasterEndDmaTransfer 函数中,也会将 0xFF 或 0x00 填充到 ShiftBuffer 中。这意味着实际发送的数据长度是 Size + 1,而不是 Size。这是为什么呢? 1.png1.png1.png 2.png2.png2.png 我已将附件项目中所有出现的 TRANSFER_SIZE + 1 修改为 TRANSFER_SIZE (8),并按说明修改了 DMA 中断回调。此外,我还禁用了 数据缓存。 在使用 DMA 进行 FlexIO I2C 发送时,我用示波器观察到,在 -Os 优化级别下,时钟信号正常,只有 8 个字节。然而,在 -O0 优化级别下,前 8 个字节的时钟信号正常,但在发送 ACK 之后,并没有按预期生成停止信号;相反,出现了一个额外的 1 位时钟脉冲。 3.jpg3.jpg3.jpg 对于通过 DMA 接收 FlexIO I2C 信号,LPI2C0 用作从设备发送 8 字节(0x10–0x17)。在 -O0 优化级别下,传输第 7 个字节时时钟信号异常,FlexIO 接收缓冲区仅包含 6 个字节(0x10–0x15)。 4.jpg4.jpg4.jpg 在 -Os 优化级别,传输第 8 个字节时时钟信号异常,FlexIO 接收缓冲区仅包含 7 个字节(0x10–0x16)。 5.jpg5.jpg5.jpg 以上所有问题均可可靠地重现。 Re: S32K344 FlexIO I2C DMA 嗨@Jason07 我认为关键在于 I2C 使用的是开漏信号传输: 逻辑 0 会主动将 SDA 拉低。 逻辑 1 释放 SDA,使上拉电阻将线路拉高。 由于 FlexIO 是一个可编程外设,而不是专用的 I2C 控制器,因此驱动程序必须通过控制加载到移位器中的位模式来生成 I2C 协议事件。 因此,最后的 0x00 和 0xFF 值不一定应被视为额外的有效载荷字节。相反,它们用于将 SDA 置于正确的状态以完成循环。 当 Master->SendStop == TRUE 时,驱动程序加载 0x00,强制 SDA 为低电平。当换挡器完成且 FlexIO 释放线路后,上拉电阻会使 SDA 变为高电平,而 SCL 已经为高电平,从而产生所需的停止条件(SDA:低电平 → 高电平,而 SCL 为高电平)。 当 Master>SendStop == FALSE 时,驱动程序加载 0xFF,这将保持 SDA 释放状态。上拉使 SDA 保持高电平,防止出现停止状态,并使总线准备好进行重复启动(SDA:高电平 → 低电平,而 SCL 为高电平)。 另外,我建议启用 DMA 优化模式。线程中提供了一个示例:示例 S32K344 FlexIO I2C 带 DMA 优化选项 S32DS 3.6.0 RTD 6.0.0 。 最后,您使用的是定制电路板还是EVB/FRDM?
查看全文
S32K344 FlexIO I2C DMA こんにちは、 S32K344のFlexIO I2C DMAに関していくつか質問がありますので、ご意見をいただければ幸いです。 1. FlexIOを使用してI2Cをエミュレートする場合、Txの長さは次のように設定されます。 サイズ+1 。これは 「送信シフターは、SCLピンの最後の立ち下がりエッジで追加のワードを1つロードします」 ? 1.png1.png1.png1.png 2.png2.png2.png2.png 2. DMAを使用してデータを送信する場合、 メジャーループ数 また、 サイズ + 1。これは同じ理由ですか? DMA を使用する場合、送信されるすべてのデータは Master->TxDataを呼び出すとき Flexio_I2c_Ip_MasterSendData 、 送信バッファ 長さは サイズ + 1 、最後のバイトは 0xFF または 0x00 ? 3.png3.png3.png3.png 3. データを受信するには、 メジャーループ数 設定されています サイズ – 1。なぜでしょうか? 4. S32K344でこれをテストしたところ、FlexIO I2CでDMAを使用してデータを受信すると、受信データが予想より1バイト少ないことがわかりました。オシロスコープで観測すると、最後のバイトのクロック信号には、わずか5~6ビット程度の波形しか見られない。S32K312での同じテストは問題なく動作します。 S32K344 S32DS3.6.4 RTD700   BR、 ジェイソン Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん FlexIOは専用のI2Cペリフェラルではないため、その実装にはI2Cバスシーケンスを正しく完成させるための追加の内部手順が必要です。 伝送における「サイズ + 1U」は、FlexIOがI2Cフレームシーケンスを完了するために必要な最終的なシフター負荷に関連しています。この追加転送は、追加のペイロードバイトを表すものではありません。その代わりに、FlexIOハードウェア内部で最終的なクロックパルスを生成し、バスを正しく転送終了状態に移行させるために使用されます。 受信時のサイズ指定(-1U)が必要なのは、最後に受信したバイトが個別に処理されるためです。これにより、運転者は必要なNACKおよびSTOP条件を適切なタイミングで生成できます。 また、DMA転送モードを使用する場合、データ転送はキャッシュの一貫性の問題によって影響を受ける可能性があることを考慮してください。Dキャッシュが有効になっている場合に発生する可能性のある問題を回避するため、DMA TCDの送信元および送信先として使用されるバッファは、キャッシュ不可能なメモリ領域に割り当てられていることを確認してください。 Flexio_I2c_Ip_MasterReceiveData() 関数を呼び出す際に、TRANSFER_SIZE パラメータを増やす必要はありません。ドライバーは受信シーケンスの必要な内部調整をすでに処理しています。 最後に、あなたの設定を確認していると、両方のDMAチャネルに同じDMA割り込みコールバックが割り当てられていることに気づきました。Flexio_I2c_Ip.cに記載されている説明によると、送信と受信には異なるコールバック関数を使用する必要があります。 FlexIOチャンネル0/1 TX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() FlexIOチャンネル0/1 RX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() BR、VaneB Re: S32K344 FlexIO I2C DMA こんにちは、@ VaneBさん 「最後に受信したバイトは個別に処理される」というコードを見つけました。 しかし、送信に関してまだ疑問があります。割り込み駆動送信を使用する場合、長さはサイズ+1に設定されます。送信時にコードはそれが最後のバイトかどうかをチェックします。もしそうなら、0xFFか0x00を送ります。実際に送信されるデータの長さは依然としてサイズです。しかしDMAで送信を行う場合、DMAは送信バッファからサイズ+1バイトをコピーし、Flexio_I2c_Ip_MasterEndDmaTransfer関数ではShiftBufferに0xFFまたは0x00も埋めます。つまり、実際に送信されるデータ長はサイズではなくサイズ+1です。なぜでしょうか? 1.png1.png1.png 2.png2.png2.png 添付のプロジェクト内のTRANSFER_SIZE + 1のすべての箇所をTRANSFER_SIZE (8)に変更し、説明されているとおりDMA割り込みコールバックも変更しました。また、Dキャッシュも無効にしました。 FlexIO I2C送信にDMAを使用する際、オシロスコープで観察したところ、-Os最適化レベルではクロック信号は8バイトのみで正常でした。しかし、-O0最適化レベルでは、最初の8バイトのクロックは正常でしたが、ACK送信後に期待どおりストップ信号が生成されず、代わりに1ビットの余分なクロックパルスが現れました。 3.jpg3.jpg3.jpg FlexIO I2C を DMA 経由で受信する場合、LPI2C0 はスレーブとして使用され、8 バイト (0x10~0x17) を送信します。-O0最適化レベルでは、7バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには6バイト(0x10~0x15)しか含まれません。 4.jpg4.jpg4.jpg -Os最適化レベルでは、8バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには7バイト(0x10~0x16)しか含まれません。 5.jpg5.jpg5.jpg 上記の問題はすべて確実に再現可能です。 Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん 重要な点は、I2Cがオープンドレイン信号方式を採用していることだと思います。 論理0はSDAを積極的にローに引き下げます。 論理値1はSDAを解放し、プルアップ抵抗によってラインがハイレベルに駆動される。 FlexIOは専用のI2Cコントローラではなくプログラム可能な周辺機器であるため、ドライバはシフターに読み込まれるビットパターンを制御してI2Cプロトコルイベントを生成しなければなりません。 このため、末尾の0x00と0xFFの値は、必ずしも追加のペイロードバイトとみなすべきではありません。むしろ、それらはSDAを適切な状態に配置し、ルーチンを完了させるために使用される。 Master->SendStop == TRUEの場合、ドライバーは0x00をロードし、SDAを強制的に低くなります。シフターの処理が完了し、FlexIOがラインを解放すると、プルアップによってSDAがハイになり、SCLは既にハイになっているため、必要な停止条件(SDA:LOW → HIGH、SCLはHIGH)が生成されます。 Master->SendStop == FALSEの場合、ドライバーは0xFFをロードし、SDAは解放されたままになります。プルアップによりSDAがハイレベルに維持され、停止状態が防止され、バスは繰り返し始動(SCLがハイレベルの間、SDA:ハイレベル→ローレベル)の準備が整います。 また、DMA最適化モードを有効にすることをお勧めします。例はスレッドにあります: S32K344 DMA Optimize オプション S32DS 3.6.0 RTD 6.0.0 を用いた FlexIO I2C の例。 最後に、カスタムボードを使用していますか、それともEVB/FRDMを使用していますか?
查看全文
i.mx8M Plus の wm8962 エラー NXP i.MX 8M Plus(i.MX8MP)プロセッサとWolfson WM8962オーディオコーデックをベースにカスタムボードを設計しています。現在、このドライバーをLinuxカーネル5.4に移植中です。以下に、エラーログとDTS(デバイスツリーソース)の設定を示します。 ログ: [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS:   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ 私たちの分析によれば、カーネルがimx-wm8962マシンドライバの初期化を試みる際、I2Cバス上のWM8962コーデックはまだプローブ/登録を完了していません。WM8962はその後になってようやく初期化を完了する。このプローブの順序不一致により、ドライバーの初期化がエラーで失敗します。 この問題を分析し、この行動を解決するための解決策を提案していただけませんか? IMX8MPLUSオーディオソフトウェア_NXP_MICR Android Linux Re: wm8962 on i.mx8M Plus error コーデックやSAIプラットフォームデバイスが準備できない場合は-EPROBE_DEFER返します imx-wm8962.c でプローブパス、以下を区別する: DT phandle が欠落/無効です → 実際のエラー、-EINVAL を返します。 phandle は存在しますが、参照されているデバイスがまだ登録されていません → 依存関係が準備できていないため、-EPROBE_DEFER を返します。 例えば、概念的には: codec_np = of_parse_phandle(np、「オーディオコーデック」、0); if (!codec_np) { dev_err(&pdev->dev、「オーディオ-codec missing またはinvalid\n」);         -EINVAL を返します。 } codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev) { dev_info(&pdev->dev, "codec device not ready, defer probe\n"); of_node_put(codec_np);         return -EPROBE_DEFER; } CPU DAI / SAIノードについても同様です。 cpu_np = of_parse_phandle(np、「audio-cpu」、0); if (!cpu_np) { dev_err(&pdev->dev、「audio-cpu missing or invalid\n」);         -EINVAL を返します。 } cpu_pdev = of_find_device_by_node(cpu_np); if (!cpu_pdev) { dev_info(&pdev->dev、「SAIプラットフォームデバイスは準備完了、プローブを延期\n」); of_node_put(cpu_np);         return -EPROBE_DEFER; } 現在のマシンドライバーを使い続けるなら、これが最も直接的な解決策です。 可能であればLinux 5.4のFSL-asoc-cardパスを推奨します Linux 5.4時代のNXPカーネルでは、互換=「fsl,imx-audio-wm8962」はsound/soc/fsl/fsl-asoc-card.cによって処理され、コーデックDAI名「wm8962」やWM8962クロック/FLL IDを含む明示的なWM8962処理が行われます。また、snd-soc-fsl-asoc-card.ko がロードされているか、組み込まれていることを確認してください。 つまり、レガシー/カスタムのimx-wm8962マシンドライバーとFSL-ASOC-cardの両方が同じ互換文字列をバインドしようとするのは避けるべきです。推奨されるアプローチ: CONFIG_SND_SOC_FSL_ASOC_CARD を有効化/使用する; サウンドノードがCompatible = "FSL,IMX-オーディオ-WM8962"; 意図的に維持する場合を除き、その互換性のある文字列のレガシー/カスタム imx-wm8962 バインディングを削除または無効にします。 DTSに必要なSAIとコーデックDAIプロパティが備わっていることを確認してください。 コーデックノードは概ね想定どおりの形状です。WM8962 の例では compatible = "wlf,wm8962"、reg =<0x1a> �、clocks、supply properties、gpio-cfg を使用します。ただし、DTSに表示されていない部品を確認してください。 &sai3 {      #sound-dai-cells = <0>;         pinctrl-names = "default";      pinctrl-0 = <&pinctrl_sai3>;         assignment-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assignment-clock-rates = <12288000>; /* またはボード指定のMCLK */ status = "オーケー"; }; また、コーデックは通常、以下の情報も公開する必要があります。 コーデック: wm8962@1a { 互換性 = "wlf,wm8962";      reg = <0x1a>;      #sound-dai-cells = <0>;      clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;      clock-names = "mclk";      ... }; また、reg_audio_pwr で参照されるレギュレータが定義され、有効になっており、有効な電圧範囲を持っていることを確認してください。コーデックが検出されているので、電源がこの特定のエラーの原因ではない可能性が高いですが、電源の不具合やMCLKの設定不良が後のオーディオ故障の原因になることがあります。 MCLKイネーブルメントの検証 WM8962のブリングアップ問題の中には、オーディオマシンドライバでコーデックMCLKを有効にする必要があることが知られています。imx_wm8962_probe()にclk_prepare_enable(codec_clk)を加えると、WM8962の音声が動作すると報告されています。コーデックのプローブが成功したにもかかわらず、その後の再生/キャプチャが失敗する場合は、コーデックの初期化時およびストリームの起動時に、SAI3 MCLKが実際にコーデックピンに存在していることを確認してください。 サウンドカードのノードに重複や競合がないか確認してください。 このコーデック/SAIペアをターゲットにしているアクティブなサウンドノードは1つだけ、モデル文字列が一意であることを確認しましょう。コーデックプラットフォームデバイスの見つかりに失敗した類似の失敗は、NXPコミュニティデバッグにおけるサウンドカード命名や重複カードの競合に関連していました。ノード名はsound-wm8960-forenexと表示されていますが、対応モデルはWM8962です。ノード名自体は通常機能しませんが、明確にするために名前を変更し、他に2つ目のSound-WM8962ノードがないか確認したほうがいいでしょう。 推奨される最小パス 可能であればLinux 5.4用にFSL-asoc-cardを使いましょう。 WM8962 ノードに #sound-dai-cells = <0> が追加されている場合は、追加してください。 &sai3 が有効になっており、clocks/pinctrl が設定されていることを確認してください。 カスタムのimx-wm8962ドライバーを維持する場合は、失敗したコーデックやCPUの検索パスを-EINVALではなく-EPROBE_DEFERにパッチしてください。 MCLKが有効になっており、存在していることを確認してください。
查看全文
wm8962 on i.mx8M Plus error We are designing our custom board based on the NXP i.MX 8M Plus (i.MX8MP) processor with the Wolfson WM8962 audio codec. We are currently porting the driver to the Linux kernel 5.4. Below are the error logs and our DTS (Device Tree Source) configuration. LOG: [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS:   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ Based on our analysis, when the kernel attempts to initialize the imx-wm8962 machine driver, the WM8962 codec on the I2C bus has not yet completed its probing/registration. The WM8962 only finishes its initialization afterward. This probe ordering discrepancy causes the driver initialization to fail with an error. Could you please help analyze this issue and suggest solutions to resolve this behavior? IMX8MPLUS AUDIO_SOFTWARE_NXP_MICR  Android Linux Re: wm8962 on i.mx8M Plus error Return -EPROBE_DEFER when the codec or SAI platform device is not ready In your imx-wm8962.c probe path, distinguish between: missing/invalid DT phandle → real error, return -EINVAL ; phandle exists, but referenced device is not registered yet → dependency not ready, return -EPROBE_DEFER . For example, conceptually: codec_np = of_parse_phandle(np, "audio-codec", 0); if (!codec_np) {         dev_err(&pdev->dev, "audio-codec missing or invalid\n");         return -EINVAL; } codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev) {         dev_info(&pdev->dev, "codec device not ready, defer probe\n");         of_node_put(codec_np);         return -EPROBE_DEFER; } Similarly for the CPU DAI / SAI node: cpu_np = of_parse_phandle(np, "audio-cpu", 0); if (!cpu_np) {         dev_err(&pdev->dev, "audio-cpu missing or invalid\n");         return -EINVAL; } cpu_pdev = of_find_device_by_node(cpu_np); if (!cpu_pdev) {         dev_info(&pdev->dev, "SAI platform device not ready, defer probe\n");         of_node_put(cpu_np);         return -EPROBE_DEFER; } This is the most direct fix if you keep your current machine driver. Prefer the Linux 5.4 fsl-asoc-card path if available For Linux 5.4-era NXP kernels, compatible = "fsl,imx-audio-wm8962" is handled by sound/soc/fsl/fsl-asoc-card.c , which has explicit WM8962 handling, including codec DAI name "wm8962" and WM8962 clock/FLL IDs . Also verify that snd-soc-fsl-asoc-card.ko is loaded or built in . That means you should avoid having both a legacy/custom imx-wm8962 machine driver and fsl-asoc-card trying to bind the same compatible string. Recommended approach: enable/use CONFIG_SND_SOC_FSL_ASOC_CARD ; ensure your sound node uses compatible = "fsl,imx-audio-wm8962"; ; remove or disable the legacy/custom imx-wm8962 binding for that compatible string, unless you intentionally maintain it. Make sure the DTS has the required SAI and codec DAI properties Your codec node is broadly in the expected shape: examples for WM8962 use compatible = "wlf,wm8962" , reg = <0x1a> , clocks , supply properties, and gpio-cfg . However, confirm the parts not shown in your DTS: &sai3 {         #sound-dai-cells = <0>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_sai3>;         assigned-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;         assigned-clock-rates = <12288000>; /* or board-required MCLK */         status = "okay"; }; And the codec should also normally expose: codec: wm8962@1a {         compatible = "wlf,wm8962";         reg = <0x1a>;         #sound-dai-cells = <0>;         clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;         clock-names = "mclk";         ... }; Also ensure the regulator referenced by reg_audio_pwr is defined, enabled, and has a valid voltage range. Your codec is being detected, so the supplies are probably not the cause of this specific error, but bad supply or MCLK setup can cause later audio failures. Verify MCLK enablement There is a known class of WM8962 bring-up issues where enabling the codec MCLK in the audio machine driver was required; adding clk_prepare_enable(codec_clk) in imx_wm8962_probe() was reported to make WM8962 audio work . If your codec probe succeeds but playback/capture later fails, check that SAI3 MCLK is actually present at the codec pin during codec initialization and stream startup. Check for duplicate or conflicting sound-card nodes Make sure only one active sound node targets this codec/SAI pair and that the model string is unique. A similar failure involving failed to find codec platform device was also associated with sound-card naming / duplicate-card conflicts in NXP community debugging . Your node name says sound-wm8960-forenex while the compatible/model are WM8962; the node name itself is not normally functional, but I would rename it for clarity and verify there is no second enabled sound-wm8962 node elsewhere. Recommended minimal path Use fsl-asoc-card for Linux 5.4 if possible. Add #sound-dai-cells = <0>; to the WM8962 node if missing. Confirm &sai3 is enabled and has clocks/pinctrl configured. If keeping your custom imx-wm8962 driver, patch the failed codec/CPU lookup paths to return -EPROBE_DEFER instead of -EINVAL . Confirm MCLK is enabled and present.
查看全文
FRDM-IMX95でWi-Fi接続を自動で行うスクリプトの書き方 (日本語ブログ) ​ 1. はじめに FRDM-IMX95のようなボードで開発を進めていると、起動後に毎回手作業でWi-Fiに接続するのが煩わしくなってきます。そこで、モジュールのロードからDHCPによるIPアドレス取得までを一気に行うシェルスクリプト connect_wifi.sh を用意すると便利です。 一見単純なタスクですが、組み込みLinux環境(特にNXPの *moal ドライバや、機能を絞った wpa_supplicant ビルド)では、デスクトップLinuxでは遭遇しないいくつかの落とし穴があります。ここでは、実際に動作するスクリプト(connect_wifi.sh)を1行ずつ解説しながら、それぞれの処理がなぜ必要なのかを説明します。 対象は、i.MX 8M / i.MX 93 / i.MX 95 などNXP SoC上でYoctoベースのLinuxを扱う開発者を想定しています。 *MOAL(MAC OS/A-kernel/OS-adaptor Layer)ドライバとは?  主にNXP Semiconductors(旧Marvell)製の無線LAN(Wi-Fi)チップセットにおいて、LinuxやAndroidなどのOS上で動作するOS依存型のホストドライバモジュールです。   <目次> 1. はじめに 2.  完成版スクリプト (connect_wifi.sh) 3. 各ブロックの解説 3.1 前提チェック — 静かに失敗させない 3.2 認証情報の読み込み — クオートという落とし穴 3.3 ドライバのロードとインターフェース起動 3.4 PSKをPBKDF2で計算 — wpa_passphraseを使わない理由 3.5 wpa_supplicant.conf の生成 — ctrl_interfaceを忘れない 3.6 wpa_supplicant の起動 — 既存プロセスの掃除 3.7 接続完了のポーリング — 固定sleepにしない 3.8 DHCPでIPアドレス取得 3.9 DNS設定 4. スクリプトの実行 5. まとめ 6. 関連情報   ​ 2.  完成版スクリプト (connect_wifi.sh) まずconnect_wifi.shの全体像を示します。以降のセクションで各ブロックを順に解説します。 #!/bin/bash set -uo pipefail readonly CRED_FILE="/etc/wifi/wifi.conf" readonly WPA_CONF="/etc/wpa_supplicant.conf" readonly IFACE="mlan0" # --- 1. 前提チェック --- if [[ ${EUID} -ne 0 ]]; then     echo "[ERROR] root権限で実行してください" >&2     exit 1 fi if [[ ! -f "${CRED_FILE}" ]]; then     echo "[ERROR] 認証情報ファイルが見つかりません: ${CRED_FILE}" >&2     exit 1 fi # --- 2. 認証情報の読み込み --- SSID=$(grep -E '^SSID=' "${CRED_FILE}" | cut -d= -f2-) PASSWORD=$(grep -E '^PASSWORD=' "${CRED_FILE}" | cut -d= -f2-) # 前後のクオートを防御的に除去 SSID="${SSID%\"}"; SSID="${SSID#\"}" SSID="${SSID%\'}"; SSID="${SSID#\'}" PASSWORD="${PASSWORD%\"}"; PASSWORD="${PASSWORD#\"}" PASSWORD="${PASSWORD%\'}"; PASSWORD="${PASSWORD#\'}" if [[ -z "${SSID}" || -z "${PASSWORD}" ]]; then     echo "[ERROR] SSID または PASSWORD が読み取れません" >&2     exit 1 fi echo "[OK] 認証情報を読み込みました (SSID=${SSID})" # --- 3. ドライバのロードとインターフェース起動 --- modprobe moal mod_para=nxp/wifi_mod_para.conf echo "[OK] モジュールをロードしました" ip link set "${IFACE}" up 2>/dev/null echo "[OK] ${IFACE} をupにしました" # --- 4. PSKをPBKDF2で計算 --- PSK_HEX=$(python3 -c " import sys, hashlib, binascii ssid = sys.argv[1] passphrase = sys.stdin.readline().rstrip('\n') psk = hashlib.pbkdf2_hmac('sha1', passphrase.encode(), ssid.encode(), 4096, 32) print(binascii.hexlify(psk).decode()) " "${SSID}" <<< "${PASSWORD}") unset PASSWORD if [[ -z "${PSK_HEX}" ]]; then     echo "[ERROR] PSKの計算に失敗しました" >&2     exit 1 fi # --- 5. wpa_supplicant.conf の生成 --- cat > "${WPA_CONF}" <<EOF ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 network={     ssid="${SSID}"     psk=${PSK_HEX} } EOF chmod 600 "${WPA_CONF}" # --- 6. wpa_supplicant の起動 --- pkill -f "wpa_supplicant.*${IFACE}" 2>/dev/null sleep 1 wpa_supplicant -B -i "${IFACE}" -c "${WPA_CONF}" if [[ $? -ne 0 ]]; then     echo "[ERROR] wpa_supplicantの起動に失敗しました" >&2     exit 1 fi echo "[OK] wpa_supplicantを起動しました" # --- 7. 接続完了のポーリング --- connected=0 for i in $(seq 1 20); do     state=$(wpa_cli -i "${IFACE}" status 2>/dev/null | grep ^wpa_state | cut -d= -f2)     echo "  [${i}/20] wpa_state=${state:-unknown}"     if [[ "${state}" == "COMPLETED" ]]; then         connected=1         break     fi     sleep 1 done if [[ ${connected} -eq 0 ]]; then     echo "[ERROR] Wi-Fi認証に失敗しました(タイムアウト)" >&2     exit 1 fi echo "[OK] Wi-Fi認証に成功しました" # --- 8. DHCPでIPアドレス取得 --- udhcpc -i "${IFACE}" -n -t 5 -T 3 if [[ $? -ne 0 ]]; then     echo "[ERROR] DHCPによるIPアドレス取得に失敗しました" >&2     exit 1 fi echo "[OK] DHCPでIPアドレスを取得しました" # --- 9. DNS設定 --- if ! grep -q "nameserver 8.8.8.8" /etc/resolv.conf 2>/dev/null; then     echo "nameserver 8.8.8.8" >> /etc/resolv.conf fi echo "=== 接続完了 ===" ip addr show "${IFACE}" 認証情報は、スクリプト本体とは分離した /etc/wifi/wifi.conf に置きます。 root@frdm-imx95:~# mkdir -p /etc/wifi root@frdm-imx95:~# cat > /etc/wifi/wifi.conf <<'EOF' SSID=exampleSSID PASSWORD=examplePassword EOF 認証情報は他のユーザーからアクセスできないよう、権限を変更しておきます。 root@frdm-imx95:~# chmod 600 /etc/wifi/wifi.conf   ​ 3. 各ブロックの解説 ​ 3.1 前提チェック — 静かに失敗させない set -uo pipefail '-u'オプション は未定義変数の参照をエラーにし、'-o pipefail' はパイプ内のいずれかのコマンドが失敗した場合に終了コードへ反映します。 なお、あえて '-e'(エラーで即終了)は付けていません。ネットワーク系のコマンドは「失敗しても後続の診断を続けたい」ケースが多く、'-e' があると失敗した瞬間に何のメッセージも出さずにスクリプトが終わってしまうためです。代わりに、各コマンドの直後で '$?' を明示的にチェックし、どの段階で失敗したかを '[OK]' / '[ERROR]' のログとして残す方針にしています。 root権限チェックと認証情報ファイルの存在チェックも、後続処理が意味不明なエラーで落ちる前に、原因を明確にして早期終了させるためのものです。 ​ 3.2 認証情報の読み込み — クオートという落とし穴 SSID=$(grep -E '^SSID=' "${CRED_FILE}" | cut -d= -f2-) 認証情報ファイルから 'SSID=' で始まる行を取り出し、'=' 以降を値として抽出します。'cut -d= -f2-' の '-f2-'(2フィールド目以降すべて)がポイントで、これによりパスワードに '=' が含まれていても正しく取り出せます。 続く4行のクオート除去が、実は本スクリプトで最も重要な防御処理です。 SSID="${SSID%\"}"; SSID="${SSID#\"}" これはbashのパラメータ展開で、'${var%\"}' が末尾のダブルクオート、'${var#\"}' が先頭のダブルクオートを除去します。 なぜ必要かというと、認証情報ファイルにうっかり 'SSID="exampleSSID"' とクオート付きで書いてしまった場合、'cut' はクオートも含めて値として取り込みます。その状態で後段の 'wpa_supplicant.conf' 生成時に 'ssid="${SSID}"' とさらにクオートを付けると、 ssid=""exampleSSID"" という二重クオートになります。'wpa_supplicant' のパーサーは外側の1組しか想定していないため、内側のクオートまでSSIDの一部として解釈してしまい、スキャン結果に存在するはずのAPとマッチしません。結果として 'wpa_state' が 'SCANNING' から一切進まないという、原因の分かりにくい症状になります。 この防御処理を入れておけば、認証情報ファイルの記法がクオートあり・なしのどちらでも正しく動作します。 ​ 3.3 ドライバのロードとインターフェース起動 modprobe moal mod_para=nxp/wifi_mod_para.conf ip link set "${IFACE}" up 2>/dev/null NXPのWi-Fiは 'moal' カーネルモジュールで提供され、'mod_para' でファームウェアの動作パラメータファイルを指定します。ロード後にインターフェース(ここでは 'mlan0')を明示的にupしておきます。 ​ 3.4 PSKをPBKDF2で計算 — wpa_passphraseを使わない理由 通常、WPA2-PSKの設定生成には 'wpa_passphrase' コマンドを使います。しかし組み込み環境では2つの問題に直面しました。 パスワードの露出です。'wpa_passphrase SSID PASSWORD' のように引数で渡すと、実行中に 'ps' コマンドや '/proc/ /cmdline ' から平文パスワードが見えてしまいます。 標準入力経由での動作不良です。露出を避けるため 'wpa_passphrase "$SSID" <<< "$PASSWORD"' とヒアストリングで渡すと、環境によっては次のエラーが出て空のファイルが生成されました。 reading passphrase from stdin tcgetattr: Inappropriate ioctl for device これは 'wpa_passphrase' が端末のエコーを制御しようと 'tcgetattr()' を呼ぶものの、標準入力が実端末(TTY)ではないために失敗し、その後のパスフレーズ読み込みも中断されるためです。 そこで、WPA2-PSKの鍵導出仕様をそのままpython3で実装しました。 psk = hashlib.pbkdf2_hmac('sha1', passphrase.encode(), ssid.encode(), 4096, 32) WPA2-PSKのPSKは、仕様上 PBKDF2-HMAC-SHA1(パスフレーズ, SSID, 4096回, 256bit) という決まった計算で導出されます。これを直接計算することで、'wpa_passphrase' のTTY依存を完全に回避できます。パスワードは引数ではなく 'sys.stdin' から受け取るため 'ps' にも露出しません。 unset PASSWORD 計算が終わったら、平文パスワードを保持する変数は速やかに破棄します。 ​ 3.5 wpa_supplicant.conf の生成 — ctrl_interfaceを忘れない cat > "${WPA_CONF}" <<EOF ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 network={     ssid="${SSID}"     psk=${PSK_HEX} } EOF このブロックで見落としやすいのが冒頭の `ctrl_interface` の指定です。 'wpa_cli' は '/var/run/wpa_supplicant/<インターフェース名>' というUNIXドメインソケット経由で 'wpa_supplicant' と通信します。このソケットは 'ctrl_interface' を設定ファイルに書かないと生成されません。これを忘れると、後段のポーリング('wpa_cli status')が次のエラーで動かず、実際には接続に成功していても状態を取得できないため「失敗」と誤判定してしまいます。 Failed to connect to non-global ctrl_ifname: mlan0  error: No such file or directory また、'psk=' 行の値('PSK_HEX')は16進のハッシュ値なのでクオートを付けません。クオートを付けると平文パスフレーズとして再解釈されてしまうため注意が必要です。一方 'ssid=' は文字列なのでクオートで囲みます。 生成後は 'chmod 600' で他ユーザーから読めないようにします。 ​ 3.6 wpa_supplicant の起動 — 既存プロセスの掃除 pkill -f "wpa_supplicant.*${IFACE}" 2>/dev/null sleep 1 wpa_supplicant -B -i "${IFACE}" -c "${WPA_CONF}" 再実行時に古い 'wpa_supplicant' プロセスが残っていると、新しいプロセスとソケットが競合したり、古い設定のまま動き続けたりします。起動前に 'pkill' で確実に掃除しておきます。'-B' はバックグラウンド実行を指定するオプションです。 デバッグ時にログをファイルへ出したくなりますが、ビルドによっては '-B'(バックグラウンド)と '-f'(ログファイル)を併用できないことがあります('-f' 未サポートのビルドでは引数解析に失敗し、ヘルプが表示されて起動しません)。その場合は次のようにシェルのリダイレクトを使います。 wpa_supplicant -dd -i "${IFACE}" -c "${WPA_CONF}" > /var/log/wpa_supplicant.log 2>&1 &   ​ 3.7 接続完了のポーリング — 固定sleepにしない for i in $(seq 1 20); do     state=$(wpa_cli -i "${IFACE}" status 2>/dev/null | grep ^wpa_state | cut -d= -f2)     echo "  [${i}/20] wpa_state=${state:-unknown}"     if [[ "${state}" == "COMPLETED" ]]; then         connected=1         break     fi     sleep 1 done 電波状況によって認証完了までの時間は変動するため、固定待機は「まだ繋がっていないのに次へ進む」「無駄に待ちすぎる」のどちらかになりがちです。 代わりに 'wpa_cli status' の 'wpa_state' を1秒間隔でポーリングし、'COMPLETED' になった時点で先へ進みます。各ステップで状態を出力しているので、認証がどのフェーズで止まっているか('SCANNING' / 'ASSOCIATING' / '4WAY_HANDSHAKE' など)がリアルタイムに見えるのも利点です。 'wpa_state' の正常な遷移は次のとおりです。 DISCONNECTED → SCANNING → AUTHENTICATING → ASSOCIATING → ASSOCIATED → 4WAY_HANDSHAKE → GROUP_HANDSHAKE → COMPLETED どこで止まるかによって原因の切り分けができます。'SCANNING' から進まなければAPが見つかっていない(SSID誤り、電波、バンド設定など)、'4WAY_HANDSHAKE' で 'WRONG_KEY' が出れば鍵(パスワードまたはSSID)の不一致、といった具合です。   ​ 3.8 DHCPでIPアドレス取得 udhcpc -i "${IFACE}" -n -t 5 -T 3 BusyBoxの 'udhcpc' (Micro DHCP Client) でIPアドレスを取得します。 オプションは、 '-n'(リース取得失敗時に終了) '-t 5'(リクエスト再送を最大5回) '-T 3'(再送間隔3秒) です。これらを指定しないと、DHCPサーバに到達できない環境でスクリプトが無限に待ち続けてしまうため、必ず入れておきます。 ​ 3.9 DNS設定 if ! grep -q "nameserver 8.8.8.8" /etc/resolv.conf 2>/dev/null; then     echo "nameserver 8.8.8.8" >> /etc/resolv.conf fi '/etc/resolv.conf' にフォールバック用のDNSサーバを追記します。既に同じ行があれば重複追記しないよう 'grep' でチェックしています。 なお、DHCP取得したDNS情報をネットワーク管理系(udhcpcのデフォルトスクリプトやsystemd-resolvedなど)が '/etc/resolv.conf' に書き込む構成では、手動追記が上書きされることがあります。固定DNSを確実に効かせたい場合は、udhcpc側のフックスクリプトで制御するのが本来は堅実です。   ​ 4. スクリプトの実行 作成したスクリプトに'chmod'コマンドで実行権限を付加し、実行します。 root@frdm-imx95:~# chmod +x connect_wifi.sh root@frdm-imx95:~# ./connect_wifi.sh ​ 5. まとめ FRDM-IMX95上でのWi-Fi自動接続スクリプトを題材に、組み込みLinux特有の注意点を解説しました。デスクトップLinuxでは意識する必要のない、次のようなポイントがつまずきどころになります。 'wpa_passphrase' はヒアストリング入力でTTYエラーになることがあり、PBKDF2の自前計算が確実 'wpa_supplicant.conf' に 'ctrl_interface' がないと 'wpa_cli' で状態を取得できない SSIDのクオートの二重化は 'SCANNING' から進まない原因になる SSIDはPSK計算の入力の一部であり、SSIDの誤りは鍵の不一致として現れる ビルドによっては '-B' と '-f' を併用できない 同様の課題に取り組まれている方の参考になれば幸いです。 ​ 6. 関連情報 i.MX FRDMボードの部屋 Yocto Linux BSPの利用方法 ~まとめページ~ (日本語ブログ) ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) FRDM-IMX95に搭載されているWi-Fiモジュールを、起動後に毎回手作業で接続するは非常に煩わしいです。そこで本記事では、起動時に自動でWi-Fi接続するための方法と、スクリプトの書き方例について紹介します。 同様のWi-Fiモジュールを搭載しているi.MXファミリの評価ボードにも流用できます。 (読了:20分) (作業時間: 10分) ※i.MX向けYocto Linuxをビルド、動作確認している前提 i.MX Processors 日本語ブログ
查看全文
MPC5748G 在 SJA1105SMBEVM 上:代码闪存读取的是返回地址而不是数据;RAM/外设正常 您好, 我有一块 SJA1105SMBEVM 评估板(MPC574xB/C/G + SJA1105P/Q/R/S 网关评估套件,通过 Digi-Key 购买,货号为 568-SJA1105SMBEVM-ND)。板载 MPC5748G 的代码闪存似乎无法正常工作。我希望对以下诊断进行核实,并在申请退货授权 (RMA) 之前了解是否有已记录的恢复程序。 症状 该主板自开箱以来从未运行过其出厂固件。“Alive” LED D3(AH1721 第 5.4 节)从未闪烁过,事实上,板上的任何 LED 都从未闪烁过。 使用 S32DS for Power Architecture v2.1 和 PEmicro USB Multilink Universal 对 sja1105smbevm_tc10example 示例项目进行编程时,程序无限期地卡在以下位置: 编程顺序为:擦除、空白检查、编程和验证 {default}     CMD>VC 验证目标文件 CRC-16 校验值是否与设备范围匹配……        块 00FA0000-00FA0003 ... 它始终停留在这一点上(观察超过 14 分钟)。请注意,00FA0000-00FA0003 只有 4 个字节(RCHW),而 CMD>VC 是在擦除之前运行的预检查,因此在会话的第一次闪存读取时就会失败。 已排除 - J6 跳线:板出厂时未安装跳线,因此稳压器在上电后约 21 秒关闭(AH1721 第 6.4 节)。用跳线连接引脚 2-3 固定。现在电路板可以无限期地保持通电状态。D3 依然纹丝不动。 - PEmicro 探针固件:配置为 ARM 而不是 Qorivva MPC5xxx / ST SPC5xxx。已使用 PEFirmwareConfig.exe 进行修正,现在固件版本为 11.52,架构正确。这确实解决了另一个“空白检查期间出错”对话框的问题,该问题不再出现,但并没有解决闪存读取失败的问题。 - 启动配置中已禁用半主机模式。 - 调试移位频率从 5000 降至 1000 KHz,复位延迟增加到 500 ms,JTAG 排线重新安装在 A 端口 / J10 上。 - 审查:PEmicro 报告没有审查,并正常进入在线调试模式。 使用 S32DS 旁路进行诊断 直接运行 pegdbserver_power_console.exe 并使用 powerpc-eabivle-gdb 探测内存。 连接正常: 检测到 P&E 接口 - Flash 版本 11.52 设备 IDCODE 为 $00000082 启动重置脚本 (s32e200_mpc574xg.mac)... 将 RAM 从 $40000000 初始化为 $400BFFFF。 RESET 脚本已完成。 检测到 MPC574xG 设备。 设备型号为mpc5748g。 模式为在线调试。 内存探测结果: === RAM 写入/读取 @ 0x40001000(写入 0xDEADBEEF) === 0x40001000: 0xdeadbeef <- 确定 === SIUL2 MIDR1 @ 0xFFFC0004 === 0xfffc0004: 0x57483020 0x42004700 <- PARTNUM 0x5748,正常 === 代码闪现 ===     0xfa0000:    0x00fa0000  0x00fa0004  0x00fa0008  0x00fa000c     0xfa0010:    0x00fa0010  0x00fa0014     0xf90000:    0x00f90000  0x00f90004  0x00f90008  0x00f9000c     0x1000000:   0x01000000  0x01000004 每个闪词都会被读取为它自己的地址。那不是数据,也不是擦除后的闪存读取到的 0xFFFFFFFF。RAM 写入/读取、外设读取和寄存器读取均正常工作。 测试的地址来自示例项目自身的链接器脚本(Project_Settings/Linker_Files/linker_flash.ld): flash_rchw:org = 0x00FA0000,len = 0x4 FLASH_BASE_ADDR = 0x01000000 SRAM_BASE_ADDR = 0x40000000 这似乎可以解释这两种症状。At RESET时,BAM 从硬件中的 0x00FA0000 获取 RCHW,没有调试器参与,读取到的是垃圾数据,找不到有效的启动头,因此永远不会启动应用程序代码。空白支票/CMD>VC 都是闪存读取操作,因此编程失败。 问题 针对处于这种状态的 MPC5748G,是否有已记录的恢复程序,例如无需事先读取闪存即可进行的大容量擦除或闪存控制器重新初始化?S32DS 总是先执行验证读取,而验证读取操作会导致程序卡住,因此我一直无法尝试进行裸擦除。如果使用独立组网 (SA) 工具(例如 PROGPPCNEXUS?)是正确的方法,请告知。 否则,这块电路板是否应该被视为有缺陷? 谢谢。 Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK 你好, 既然你能读取闪存,我估计这个设备没问题。 尝试加载一个简单的示例并进行调试。例如以下之一: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5-software-example-list/ta-p/1102445#MPC5748G 如果在上述任何位置均未找到启动头,则 BAF 确定 设备的生命周期状态。如果生命周期在 CUST_DELIV(客户) 交付)或 MCU 生产,它尝试串行启动。否则,启动失败。 BAF 发出破坏性重置 顺祝商祺! Peter Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK 无法读取闪存。 已下载 Example_MPC5748G_FlexCAN_RXFIFO_SDK303.zip,但该项目在 S32DS 中编译失败。 我用 Claude 搭建了一个简单的“闪烁”项目,该项目在内存中运行。程序加载到目标板上后运行正常。然后创建了一个调试配置文件,用于从闪存运行。启动过程停留在 98%。问题与“sja1105smbevm_tc10example”完全相同。调试启动时,尝试从闪存读取数据时卡住。控制台选项卡中的最后一条消息: 正在加载编程算法…… 完毕。 编程顺序为:擦除、空白检查、编程和验证 {default} CMD>VC 正在验证目标文件 CRC-16 校验值是否与设备范围匹配…… 区块 00FA0000-00FA0003 ... 克劳德总结道: 现在,在不打开芯片的情况下,你已经获得了相当全面的诊断结果: - ✅ 探针、JTAG、复位、SRAM、时钟、引脚复用器、GPIO、UART、FreeRTOS 调度、独立 RAM 执行——全部确认完全正常(包括脱离调试器运行) - ❌ 无论图像大小或内容如何,Flash 编程每次都会在完全相同的地址 (0x00FA0000) 处卡住。 - ❌ 并非安全/审查锁定(已通过 PEmicro 控制台直接排除——没有安全设备警告) 我的结论: 硬件有缺陷。返回。
查看全文
2KL[IW610] MURATA 模块的 USB 枚举问题 您好,NXP, 我们遇到 IW610 驱动程序与基于 Ambarella 处理器的 SBC [Ambarella CV75 EVK] 配合使用的问题。IW610 HW 是村田 2KL 模块,通过 USB 接口连接到主机。 [设备设置]: 客户(VVDN)在同一主机上通过Microchip公司的USB4216 USB集线器连接5G/LTE模块和2KL模块。 【问题】:启动时,2KL模块(IW610)可以被正确检测和枚举,但5G/LTE模块检测失败。如果仅将5G/LTE模块连接到系统并重启设备,则设备枚举正常。 当枚举 2KL 模块之后枚举其他 USB 设备时,就会出现此问题。在 2KL 枚举之前枚举的所有设备均工作正常。 附件为客户控制台日志和 WiFi/BT 驱动程序调试日志。 期待您的支持。 谢谢! 潘卡杰·桑特 Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE 你好@pankaj 好的,我这就查看你的日志。 顺祝商祺! 肖恩 Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE 嗨@shaun_wu , 这个问题与外部无线电共存无关,而是与通过 USB 进行设备枚举有关。 请您协助调查所提供的日志中出现的枚举问题。如果您需要更多日志文件,请与我们联系。 Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE 你好@pankaj 对于多无线芯片,我们提供外部共存接口来控制无线流量。您可以按照以下指南连接和配置共存系统: https://www.nxp.com/webapp/Download?colCode=AN14410&appType=license 顺祝商祺! 肖恩 Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE 你好@pankaj 我们注意到有客户向我们反映了同样的问题。印度SAE车队正在负责此事。00994762 | 案例 | Salesforce ,您可以通过此案例进行进一步讨论。 顺祝商祺! 肖恩
查看全文
i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) Board: FRDM-i.MX93 (imx93-11x11-lpddr4x-frdm) BSP: Linux 6.18.2, driver phy-fsl-imx9-dphy-rx.c (fsl,imx93-dphy-rx) Camera: custom 2-lane sensor behind MAX96717 / MAX96714 GMSL2 serdes Data rate: 200 Mbps per lane, 2 lanes, continuous clock (fixed by the camera, cannot be changed) PROBLEM The clock lane never enters high speed. No frames are captured. DPHY_RX_STATUS (0x4ae00000 + 0x48) stays at CLK_LANE_HS = 0. WHAT WORKS - GMSL2 link is locked. The deserializer reports VID_LOCK=1, PKT_DET=1, and its CSI-2 output is enabled. - We have scoped the clock lane at the SoC pins. The clock lane is driven, makes the LP-11 to HS transition, and runs continuously while streaming. - Both data lanes are alive and the i.MX93 is decoding them. Polling DPHY_STOPSTATE (offset 0x4c) in a tight kernel loop shows about 500 transitions per 15 ms on each data lane. That matches the per-line data bursts from the camera, so the D-PHY low-power receivers are working and are following the HS entry requests. - The media pipeline is configured and STREAMON is accepted. WHAT DOES NOT WORK - CLK_LANE_HS never becomes 1. We checked it 20000 times in a tight kernel loop, so even a very short pulse would have been seen. - No errors are reported anywhere. INT_ST_MAIN (0x0c), INT_ST_DPHY_FATAL (0xe0) and INT_ST_DPHY (0x110) all read 0x00000000. - 0 bytes are captured. REGISTER VALUES READ ON THE RUNNING BOARD - hsfreqrange = 0x03 (the 205 Mbps row, correct for 200 Mbps) - cfgclkfreqrange = 28 (the config clock is 24 MHz, so (24-17)*4 = 28) - DPHY_STOPSTATE = 0x00000003 when idle, both data lanes in stop state WHAT WE NOTICED IN THE DRIVER The i.MX93 Reference Manual (Rev 7, section 55.3.1) says the D-PHY start-up needs hsfreqrange, cfgclkfreqrange AND osc_freq_target[11:0] to be configured. It also gives a value for counter_for_des_en_config_if in Table 541. The i.MX93 config function in phy-fsl-imx9-dphy-rx.c (imx93_dphy_config) writes only hsfreqrange and cfgclkfreqrange. It does not write osc_freq_target or counter_for_des_en_config_if. QUESTIONS 1. On i.MX93, does osc_freq_target need to be programmed? If so, how should it be written? 2. If it does not, what is supposed to make the clock lane enter HS? 3. Is 200 Mbps with a continuous clock a supported configuration on the i.MX93 CSI-2 port? Thank you. Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) Hi @jjudk  How did you conduct the testing? I contacted our R&D colleagues, and they suggested no changes were needed. B.R Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) Hi @pengyong_zhang,   Your colleagues are right — no driver changes were needed. Closing this out.   Root cause was board-side: our MAX96714 deserializer had MIPI_PHY5 set to polarity-swapping all three CSI-2 output pairs including the clock. With the clock pair inverted, the LP entry presents to the i.MX93 as LP-11 -> LP-10 -> LP-00, which (per RM section 55.2.4.2.3) is a legal Escape/ULPS entry, rather than the HS request (which is LP-11 -> LP-01 -> LP-00). The PHY therefore correctly declined to enter HS and latched no error, since nothing illegal occurred — which is why every status register read clean.   Resetting the deserializer polarity, followed by a RST_MIPITX pulse, makes CLK_LANE_HS assert and produces byte-exact frames.    For the record: osc_freq_target and counter_for_des_en_config_if are not required on i.MX93 — the link runs with both unwritten. And 200 Mbps per lane with a continuous clock is fine on this port.   Apologies for the noise, and thanks for the quick reply.   Best regards
查看全文
RT117x RTC_XTAL(OSC_32K) test output pin Hello, Is there A way to test the frequency of RTC_XTAL(OSC_32K) in RT117x? I found one for 24MHz clock but not 32K in the clock tree in the reference manual. Kind regards, Marwan Re: RT117x RTC_XTAL(OSC_32K) test output pin Hi @Marwan, On the i.MX RT1170, you can route REF_CLK_32K to GPIO_AD_13 using ALT9, as mentioned in Table 11-1. Muxing Options of the i.MX RT1170 Processor Reference Manual. With this, you should be able to probe the 32.768 kHz clock directly with an oscilloscope. Best Regards, Pablo Re: RT117x RTC_XTAL(OSC_32K) test output pin Thanks for your support, I got confused with CCM_CLKO signals.
查看全文
i.MX93 MIPI CSI-2: クロックレーンが200MbpsでHSに進入しない(データレーンは正常) 基板:FRDM-i.MX93 (imx93-11x11-lpddr4x-frdm) BSP:Linux 6.18.2、ドライバー phy-fsl-imx9-dphy-rx.c (fsl, imx93-dphy-rx) カメラ:カスタム2レーンセンサーをMAX96717/MAX96714 GMSL2セルデス データレート:1レーンあたり200 Mbps、2レーン、連続クロック(固定 カメラは変更不可) 問題 時計車線は決して高速走行にはならない。フレームはキャプチャされませんでした。 DPHY_RX_STATUS (0x4ae00000 + 0x48) は CLK_LANE_HS = 0 のままです。 効果的な方法 - GMSL2リンクはロックされています。デシリアライザは、VID_LOCK=1、PKT_DET=1 を報告します。 また、CSI-2出力が有効になっています。 - SoCピンにおけるクロックレーンをスコープで解析しました。時計レーンは 駆動され、LP-11からHSへの移行を行い、連続運転する ストリーミング配信中。 - 両方のデータレーンは正常に動作しており、i.MX93がそれらをデコードしています。世論調査 タイトなカーネルループ内の DPHY_STOPSTATE (オフセット 0x4c) は約 500 を示しています 各データレーンにおける15ミリ秒あたりの遷移回数。これは1行あたりの料金と一致します カメラからのデータバーストが出るため、D-PHYの低出力レシーバは 勤務中で、高校の入学申請に従っています。 - メディアパイプラインの設定が完了し、STREAMONが受け入れられます。 うまくいかないこと - CLK_LANE_HS は決して 1 になりません。私たちは2万回もチェックしました カーネルループなので、非常に短いパルスでも見られたはずです。 - どこにもエラーは報告されていません。INT_ST_MAIN (0x0c) INT_ST_DPHY_FATAL (0xe0) と INT_ST_DPHY (0x110) はすべて読み取り 0x00000000。 - 0バイトがキャプチャされました。 ランニングボード上で読み取られるレジスタ値 - hsfreqrange = 0x03(205 Mbpsの行、200 Mbpsの正確) - cfgclkfreqrange = 28(設定クロックは24 MHz、つまり(24-17)*4 = 28) - DPHY_STOPSTATE = 0x00000003 アイドル時、両方のデータレーンが停止状態 ドライバに気づいたこと i.MX93リファレンス・マニュアル(Rev 7、セクション55.3.1)にはD-PHYと記載されています スタートアップにはHSFREQレンジ、CFGCLKFREQレンジ、そしてosc_freq_targetが必要[11:0] 設定されるべきです。また、counter_for_des_en_config_if の値も提供します。 表541を参照。 phy-fsl-imx9-dphy-rx.c の i.MX93 設定関数 (imx93_dphy_config) は hsfreqrange と cfgclkfreqrange のみを書き込みます。それ osc_freq_target または counter_for_des_en_config_if は書き込みません。 質問 1.i.MX93では、osc_freq_targetをプログラムする必要がありますか?もしそうなら、どのようにして 書くべきでしょうか? 2. もしそうでなければ、時計レーンがHSに入るのは何なのでしょうか? 3. 連続クロックで200 Mbpsがサポートされている構成ですか? i.MX93 CSI-2ポート? よろしくお願いします。 Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) こんにちは、 @jjudkさん どのようにテストを実施しましたか?R&Dの同僚に連絡したところ、変更は不要だと言われました。 B.R Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) こんにちは@pengyong_zhangさん   同僚の言う通り、ドライバーの変更は必要ありませんでした。 これで終わりにします。   根本原因は基板側にありました。当社のMAX96714デシリアライザでは、MIPI_PHY5の設定がクロックを含む3つのCSI-2出力ペアすべてを極性反転するようになっていました。クロックペアが反転すると、LPエントリはi.MX93に対してLP-11 -> LP-10 -> LP-00として提示されます。これは(RMセクション55.2.4.2.3によれば)HSリクエスト(LP-11 -> LP-01 -> LP-00)ではなく、有効なエスケープ/ULPSエントリです。したがって、PHYは正しくHSへの移行を拒否し、エラーをラッチしませんでした。不正な事象は発生しなかったため、すべてのステータスレジスタは正常値を示しました。   デシリアライザの極性をリセットし、続いてRST_MIPITXパルスを印加すると、CLK_LANE_HSがアサートされ、バイト単位の正確なフレームが生成される。   念のため申し添えますが、i.MX93ではosc_freq_targetとcounter_for_des_en_config_ifは不要です。どちらも書き込まれていなくてもリンクは動作します。このポートでは、連続クロックでレーンあたり200Mbpsの速度であれば問題ありません。   騒音で申し訳ありませんでした。迅速なご返信ありがとうございます。   よろしくお願いいたします。
查看全文
SJA1105SMBEVM のMPC5748G:コードフラッシュはデータではなく返元アドレスを読み取る;RAM/ペリフェラルは問題ありません こんにちは、 私はSJA1105SMBEVM評価ボード(MPC574xB/C/G + SJA1105P/Q/R/Sゲートウェイ評価キット、Digi-Key経由で568-SJA1105SMBEVM-NDとして購入)を持っています。オンボードのMPC5748Gのコードフラッシュが機能していないようです。下記の診断内容について妥当性を確認させていただきたいのと、RMA(返品承認)手続きを進める前に、文書化された回復手順が存在するかどうかを知りたいです。 兆候 この基板は開封以来、工場出荷時のファームウェアを一度も実行していません。「Alive」LED D3(AH1721セクション5.4)は一度も点滅したことがなく、実際、基板上のどのLEDも一度も点滅したことがない。 S32DS for Power Architecture v2.1とPEmicro USB Multilink Universalを使ったsja1105smbevm_tc10example例プロジェクトのプログラミングは、次の段階で無期限に止まります。 プログラミングの手順は、消去、空白チェック、プログラム、検証です(デフォルト)。     CMD>VC オブジェクトファイルのCRC-16をデバイス範囲と照合しています... ブロック 00FA0000-00FA0003 ... (14分以上観察した結果)この地点から先に進むことは決してない。00FA0000-00FA0003はわずか4バイト(RCHW)であり、CMD>VCは消去前に実行されるプリチェックなので、セッションの最初のフラッシュリードで失敗します。 既に除外済み - J6ジャンパー:ジャンパーが装着されていない基板が出荷されていたため、電源投入後約21秒でレギュレーターがシャットダウンしました(AH1721セクション6.4)。ピン2-3にジャンパー線を接続することで修正しました。基板はこれで無期限に電源供給され続ける。D3は相変わらず瞬きをしない。 - PEmicroプローブファームウェア:Qorivva MPC5xxx / ST SPC5xxxではなくARM向けに設定されました。PEFirmwareConfig.exeを使用して修正し、正しいアーキテクチャのファームウェア11.52になりました。これにより、別の「空白チェック中にエラーが発生しました」というダイアログは表示されなくなりましたが、フラッシュ読み取りエラーは解決されませんでした。 - 起動設定でセミホスティングが無効になっています。 - デバッグシフト周波数を5000kHzから1000kHzに下げ、リセット遅延を500msに上げ、JTAGリボンケーブルをポートA/J10に再接続しました。 - 検閲: PEmicro は検閲がないと報告し、正常にインサーキットデバッグモードに入ります。 S32DSバイパス時の診断 pegdbserver_power_console.exeを直接実行し、powerpc-eabivle-gdbを使用してメモリをプローブします。 接続は正常です。 P&Eインターフェース検出 - フラッシュバージョン11.52 デバイスIDコードは$00000082です リセットスクリプト(s32e200_mpc574xg.mac)を開始します...     $40000000から$400BFFFFまでのRAMを初期化しています。 リセットスクリプトが完了しました。 MPC574xG デバイスが検出されました。 デバイスはmpc5748gです。 モードはインサーキットデバッグです。 メモリプローブの結果: === RAM書き込み/読み出し @ 0x40001000 (0xDEADBEEFに書き込み) ===     0x40001000:  0xdeadbeef                                    <- OK     === SIUL2 MIDR1 @ 0xFFFC0004 ===     0xfffc0004:  0x57483020  0x42004700                        <- PARTNUM 0x5748、OK === コードフラッシュ ===     0xfa0000:    0x00fa0000  0x00fa0004  0x00fa0008  0x00fa000c     0xfa0010:    0x00fa0010  0x00fa0014     0xf90000:    0x00f90000  0x00f90004  0x00f90008  0x00f9000c     0x1000000:   0x01000000  0x01000004 フラッシュワードはそれぞれ、自身のアドレスとして読み上げられる。それはデータではなく、消去されたフラッシュメモリが読み取るであろう0xFFFFFFFFでもありません。RAMの書き込み/読み取り、ペリフェラルの読み取り、レジスタの読み取りはすべて正常に動作します。 テスト対象のアドレスは、サンプルプロジェクト自身のリンカースクリプト(Project_Settings/Linker_Files/linker_flash.ld)からのものです。     flash_rchw      : org = 0x00FA0000、len = 0x4 FLASH_BASE_ADDR = 0x01000000 SRAM_BASE_ADDR = 0x40000000 これは両方の症状を説明しているように思われる。リセット時、BAMはハードウェアのRchWを0x00FA0000から取得し、デバッガを使わずにゴミデータを読み込み、有効なブートヘッダーを見つけず、アプリケーションコードを起動しません。そしてブランクチェック/CMD>VCはどちらもフラッシュ読み取りなので、プログラミングは失敗します。 質問 この状態のMPC5748Gに対して、例えばマス消去やフラッシュコントローラの再初期化など、事前のフラッシュ読み取りを必要としない文書化された復旧手順はありますか?S32DSは常に最初に検証読み取りを行いますが、これがハングする操作なので、裸消去を試みることはできませんでした。スタンドアロンツール(PROGPPCNEXUSなど)が適切なアプローチであれば、ご教示ください。 そうでなければ、この基板は不良品として扱われるべきでしょうか? ありがとうございます。 Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK こんにちは、 フラッシュメモリを読み取れるということは、そのデバイスは正常だと思います。 簡単なサンプルを読み込んでデバッグしてみてください。例えば、以下のいずれかの例: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5-software-example-list/ta-p/1102445#MPC5748G 上記のいずれの場所にもブートヘッダーが見つからない場合、BAFは デバイスのライフサイクルステータス。ライフサイクルがCUST_DELIV(顧客)にある場合 Delivery)またはMCUプロダクションで、シリアルブートを試みます。そうでなければ、ブートは失敗しました。 そしてBAFは破壊的なリセットを発行する よろしくお願いいたします。 ピーター Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK Flashを読み取れません。 Example_MPC5748G_FlexCAN_RXFIFO_SDK303.zipをダウンロードしましたが、S32DSでコンパイルに失敗します。 Claudeを使って、RAM上で動作するシンプルな「点滅」プロジェクトをセットアップしました。それはターゲットボードにロードされ、問題なく動作しました。次に、フラッシュメモリから実行するためのデバッグ構成を作成しました。起動が98%で停止します。「sja1105smbevm_tc10example」と全く同じ問題です。デバッグ起動時にフラッシュメモリからの読み取り中にハングアップする。コンソールタブの最新メッセージ: プログラミングアルゴリズムを読み込んでいます... 終わり。 プログラミングの手順は、消去、空白チェック、プログラム、検証です。{default} CMD>VC オブジェクトファイルのCRC-16をデバイス範囲と照合しています... ブロック 00FA0000-00FA0003 ... クロードはこう結論づけた。 これでチップを開けずに得られる限りの詳細な診断が得られます: - ✅ プローブ、JTAG、リセット、SRAM、クロック、ピン多重化、GPIO、UART、FreeRTOSスケジューリング、スタンドアロンRAM実行など、すべて正常に動作することが確認されています(デバッガから独立して実行することも含む)。 - ❌ フラッシュプログラミングは、イメージのサイズや内容に関係なく、毎回まったく同じアドレス(0x00FA0000)でハングアップします。 - ❌ セキュリティや検閲ロックではない(PEmicroコンソールで直接除外 — セキュアデバイス警告なし) 私の結論: ハードウェアに不具合があります。戻ります。
查看全文
i.MX93 MIPI CSI-2:时钟通道在 200 Mbps 速率下始终无法进入高速模式(数据通道正常) 主板:FRDM-i.MX93 (imx93-11x11-lpddr4x-frdm) BSP:Linux 6.18.2,驱动程序 phy-fsl-imx9-dphy-rx.c (fsl,imx93-dphy-rx) 摄像头:MAX96717 / MAX96714 GMSL2 串行器/解串器后方的定制双车道传感器 数据速率:每通道 200 Mbps,2 条通道,连续时钟(由……固定) (摄像头,无法更改) 问题 时钟车道永远不会进入高速行驶状态。未捕获任何帧。 DPHY_RX_STATUS (0x4ae00000 + 0x48) 保持 CLK_LANE_HS = 0。 哪些方法有效 - GMSL2 链路已锁定。反序列化器报告 VID_LOCK=1,PKT_DET=1, 并且其 CSI-2 输出已启用。 - 我们已经对 SoC 引脚的时钟通道进行了测量。时钟车道是 驱动后,完成 LP-11 到 HS 的转换,并持续运行 直播时。 - 两条数据通道均已启用,i.MX93 正在解码它们。轮询 在紧凑的内核循环中,DPHY_STOPSTATE(偏移量 0x4c)显示大约 500 每条数据通道每 15 毫秒的转换次数。这与每行数据相符。 由于摄像头会发出数据突发,因此需要使用D-PHY低功耗接收器。 正在努力工作,并按照高中入学申请流程进行操作。 - 媒体管道已配置,STREAMON 已被接受。 哪些方法行不通? - CLK_LANE_HS 永远不会变为 1。我们在严密的环境下检查了20000次。 由于是内核循环,所以即使是很短的脉冲也会被检测到。 - 未报告任何错误。INT_ST_MAIN (0x0c) INT_ST_DPHY_FATAL (0xe0) 和 INT_ST_DPHY (0x110) 均被读取 0x00000000。 - 捕获到 0 字节。 读取仪表盘上的寄存器值 - hsfreqrange = 0x03(205 Mbps 行,更正为 200 Mbps) - cfgclkfreqrange = 28(配置时钟为 24 MHz,因此 (24-17)*4 = 28) - 当空闲时,DPHY_STOPSTATE = 0x00000003,两条数据通道均处于停止状态 我们注意到司机身上的一些特点 i.MX93 参考手册(修订版 7,第 55.3.1 节)指出 D-PHY 启动需要 hsfreqrange、cfgclkfreqrange 和 osc_freq_target[11:0] 待配置。它还为 counter_for_des_en_config_if 提供了一个值 见表541。 phy-fsl-imx9-dphy-rx.c 中的 i.MX93 配置函数 (imx93_dphy_config)仅写入 hsfreqrange 和 cfgclkfreqrange。它 不写入 osc_freq_target 或 counter_for_des_en_config_if。 问题 1.在 i.MX93 上,是否需要对 osc_freq_target 进行编程?如果是这样,该如何操作? 应该写下来吗? 2. 如果不是这样,是什么原因导致时钟通道进入高速通道? 3. 200 Mbps 的速率和连续时钟是否是受支持的配置? i.MX93 CSI-2 端口? 谢谢! Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) 嗨@jjudk 你们是如何进行测试的?我联系了我们的研发同事,他们认为无需进行任何更改。 B.R Re: i.MX93 MIPI CSI-2: clock lane never enters HS at 200 Mbps (data lanes OK) 嗨@pengyong_zhang ,   您的同事们说得对——无需更换驱动程序。此问题已解决。   根本原因是板载问题:我们的 MAX96714 解串器将 MIPI_PHY5 设置为交换所有三个 CSI-2 输出对(包括时钟)的极性。时钟对反转后,LP 条目在 i.MX93 中显示为 LP-11 -> LP-10 -> LP-00,这(根据 RM 第 55.2.4.2.3 节)是一个合法的 Escape/ULPS 条目,而不是 HS 请求(即 LP-11 -> LP-01 -> LP-00)。因此,PHY 正确地拒绝进入 HS 状态,并且没有锁存任何错误,因为没有发生任何非法事件——这就是为什么每个状态寄存器都读取正常。   重置解串器极性,然后发送一个 RST_MIPITX 脉冲,会使 CLK_LANE_HS 置位,并生成精确到字节的帧。   需要说明的是:在 i.MX93 上不需要 osc_freq_target 和 counter_for_des_en_config_if — 链接在未写入这两个参数的情况下运行。在这个端口上,每通道 200 Mbps 的速率,加上连续时钟,是可以接受的。   抱歉打扰了,感谢您的快速回复。   顺祝商祺!
查看全文
2KL[IW610] MURATAモジュールにおけるUSB列挙の問題 こんにちは、NXPさん。 AnbarellaプロセッサベースのSBC(Ambarella CV75 EVK)でIW610ドライバが動作する問題が発生しています。IW610ハードウェアは、USBインターフェースでホストに接続された村田2KLモジュールです。 [デバイス設定]: 構成は、顧客(VVDN)がMicrochipのUSB HUB-USB4216を介して同じホスト上で5G/LTEモジュール+2KLモジュールを使用しているというものです。 [問題]:起動時に2KLモジュール(IW610)は正しく検出・列挙されていますが、5G/LTEモジュールの検出が失敗しています。5G/LTEモジュールだけをシステムに接続した状態で再起動すると、正しく列挙されます。 この問題は、2KLモジュールの列挙後に他のUSBデバイスが列挙される際に発生します。2KL列挙前に列挙されたすべてのデバイスは正常に動作します。 添付は顧客のコンソールログとWiFi/BTドライバのデバッグログです。 皆さまのサポートを心よりお待ちしています。 ありがとうございます パンカジ・サント Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE こんにちは、 @pankaj さん。 はい、ログを確認させてください。 よろしくお願いいたします。 ショーン Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE こんにちは@shaun_wuさん この問題は、外部無線機器との共存とは関係なく、USB経由のデバイス列挙に関するものです。 提供されたログの列挙問題を調査するサポートはできますか?追加のログが必要な場合はお知らせください。 Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE こんにちは、 @pankaj さん。 複数無線チップの場合、無線通信を制御するための外部共存インターフェースを提供しています。共存環境の接続と設定については、以下のガイドを参照してください。 https://www.nxp.com/webapp/Download?colCode=AN14410&appType=license よろしくお願いいたします。 ショーン Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE こんにちは、 @pankaj さん。 同じ問題を報告しているお客様に気づきました。そして、インドのSAEチームがそれを担当しています。00994762 | CASE |Salesforceの皆さん、このケースを通じてさらに議論を進めてください。 よろしくお願いいたします。 ショーン
查看全文
MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK Hi, I have an SJA1105SMBEVM evaluation board (MPC574xB/C/G + SJA1105P/Q/R/S Gateway Evaluation Kit, purchased via Digi-Key as 568-SJA1105SMBEVM-ND). The onboard MPC5748G appears to have non-functional code flash. I would like a sanity check on the diagnosis below, and to know whether there is a documented recovery procedure before I pursue an RMA. SYMPTOM The board has never executed its factory firmware since unboxing. The "Alive" LED D3 (AH1721 section 5.4) has never blinked, and in fact no LED on the board has ever blinked. Programming the sja1105smbevm_tc10example example project with S32DS for Power Architecture v2.1 and a PEmicro USB Multilink Universal hangs indefinitely at:     Programming sequency is : erase, blank check, program, and verify {default}     CMD>VC     Verifying object file CRC-16 to device ranges ...        block 00FA0000-00FA0003 ... It never advances past this point (observed for more than 14 minutes). Note that 00FA0000-00FA0003 is only 4 bytes (the RCHW), and CMD>VC is a pre-check that runs before erase, so this is failing on the very first flash read of the session. ALREADY RULED OUT - J6 jumper: board shipped with no jumper installed, so the regulators shut down about 21 s after power-up (AH1721 section 6.4). Fixed with a jumper on pins 2-3. The board now stays powered indefinitely. D3 still never blinks. - PEmicro probe firmware: was configured for ARM rather than Qorivva MPC5xxx / ST SPC5xxx. Corrected with PEFirmwareConfig.exe, now firmware 11.52 with the correct architecture. This did resolve a separate "Error during blank check" dialog, which no longer occurs, but it did not resolve the flash read failure. - Semihosting disabled in the launch configuration. - Debug Shift Freq lowered from 5000 to 1000 KHz, reset delay raised to 500 ms, JTAG ribbon reseated on Port A / J10. - Censorship: PEmicro reports no censorship and enters In-Circuit Debug mode normally. DIAGNOSTICS WITH S32DS BYPASSED Driving pegdbserver_power_console.exe directly and probing memory with powerpc-eabivle-gdb. Connection is clean:     P&E Interface detected - Flash Version 11.52     Device IDCODE is $00000082     Starting reset script (s32e200_mpc574xg.mac) ...     Initializing RAM from $40000000 to $400BFFFF.     Reset script completed.     MPC574xG Device detected.     Device is mpc5748g.     Mode is In-Circuit Debug. Memory probe results:     === RAM write/readback @ 0x40001000 (wrote 0xDEADBEEF) ===     0x40001000:  0xdeadbeef                                    <- OK     === SIUL2 MIDR1 @ 0xFFFC0004 ===     0xfffc0004:  0x57483020  0x42004700                        <- PARTNUM 0x5748, OK     === code flash ===     0xfa0000:    0x00fa0000  0x00fa0004  0x00fa0008  0x00fa000c     0xfa0010:    0x00fa0010  0x00fa0014     0xf90000:    0x00f90000  0x00f90004  0x00f90008  0x00f9000c     0x1000000:   0x01000000  0x01000004 Every flash word reads back as its own address. That is not data, and not 0xFFFFFFFF as erased flash would read. RAM writes/reads, peripheral reads, and register reads all work correctly. The addresses tested are the ones from the example project's own linker script (Project_Settings/Linker_Files/linker_flash.ld):     flash_rchw      : org = 0x00FA0000, len = 0x4     FLASH_BASE_ADDR = 0x01000000     SRAM_BASE_ADDR  = 0x40000000 This appears to explain both symptoms. At reset the BAM fetches the RCHW from 0x00FA0000 in hardware, with no debugger involved, reads garbage, finds no valid boot header, and never starts application code. And blank check / CMD>VC are both flash reads, so programming fails. QUESTION Is there a documented recovery procedure for an MPC5748G in this state, for example a mass erase or flash controller re-initialization that does not require a preceding flash read? S32DS always performs the verify read first, which is the operation that hangs, so I have not been able to attempt a bare erase. If a standalone tool is the correct approach (PROGPPCNEXUS?), please advise. Otherwise, should this board be treated as defective? Thanks. Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK Hello, Since you are able to read flash, I expect that device is good. Try to load simple example and debug it. For example one of these: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5-software-example-list/ta-p/1102445#MPC5748G If no boot header is found in any of the locations mentioned above, the BAF determines the Life Cycle status of the device. If the Life Cycle is in CUST_DELIV (Customer Delivery) or MCU Production, it attempts a serial boot. Otherwise, the boot has failed and BAF issues a destructive reset Best regards, Peter Re: MPC5748G on SJA1105SMBEVM: code flash reads return address instead of data; RAM/peripherals OK Unable to read flash. Downloaded Example_MPC5748G_FlexCAN_RXFIFO_SDK303.zip, but the project fails to compile in S32DS. Used Claude to setup a simple "blinky" project that runs from RAM.  That loaded to the target board and ran just fine.  Then created a debug config to run from flash.  Launch stops at 98%.  Same exact issue as "sja1105smbevm_tc10example".  Debug launch hangs while trying to read from flash.  Last messages in console tab: Loading programming algorithm ... Done. Programming sequency is : erase, blank check, program, and verify {default} CMD>VC Verifying object file CRC-16 to device ranges ... block 00FA0000-00FA0003 ... Claude concludes: You now have about as thorough a diagnosis as you can get without opening the chip: - ✅ Probe, JTAG, reset, SRAM, clocks, pin mux, GPIO, UART, FreeRTOS scheduling, standalone RAM execution — all confirmed fully healthy (including running untethered from the debugger) - ❌ Flash programming hangs at the exact same address (0x00FA0000), every time, regardless of image size or content - ❌ Not a security/censorship lock (ruled out directly via PEmicro console — no secured-device warning) My conclusion: Hardware is defective. RETURNING.
查看全文
USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE Hi NXP, We have an issue with the IW610 DRIVER working with Ambarella processor-based SBC [Ambarella CV75 EVK]. The IW610 HW is the Murata 2KL Module which is connected to the host over USB interface.  [DEVICE SETUP]:  The setup is that the customer (VVDN) is using a 5G/LTE module + 2KL Module on the same host through a USB HUB -USB4216 from Microchip.  [ISSUE]: At boot up the 2KL MODULE (IW610) is detected and enumerated correctly, but the 5G/LTE module detection is failing.  If the device is rebooted  with the 5G/LTE modules only connected to the system it enumerates correctly.  The issue is seen whenever the other USB devices are getting enumerated post the enumeration of the 2KL module. All devices enumerated before the 2KL enumeration work correctly.  Attached is the customer console logs and WiFi/BT driver Debug logs. Looking forward to your support. Thanks, Pankaj Sant Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE Hello @pankaj  Sure let me check your logs. Best Regards Shaun Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE Hi @shaun_wu , The issue is not related to external radio co existence but with the device enumeration over USB. Can you support to investigate the enumeration issue with the provided logs. incase if you need additional logs kindly let us know. Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE Hello @pankaj  For multiple radio chip, we provide external coexistence interface to control radio traffic. You may follow the guide to connect and configure coexistence:  https://www.nxp.com/webapp/Download?colCode=AN14410&appType=license  Best Regards Shaun Re: USB ENUMERATION Issue with 2KL[IW610] MURATA MODULE Hello @pankaj  We notice we have customer report same issue to us. And India SAE team is handling it. 00994762 | Case | Salesforce, you may do further discussion via this case.  Best Regards Shaun
查看全文
16MHz external crystal not working on the S32K314HMS custom board Hi, I am facing an issue with an external crystal of 16MHz not working with S32K314HMS custom board. I am using a build created from S32 Design Studio for S32 Platform Version: 3.6.9 Build id: 260624. I am using raw code to test the board function, as shown below in main.c: #include /* Corrected Raw Hardware Register Addresses for S32K314 */ #define SIUL2_MSCR_PTB5 (*(volatile uint32_t*)(0x40290294U)) #define MC_CGM_CLKOUT_CNTRL (*(volatile uint32_t*)(0x402D4000U)) /* --- CORRECTED FXOSC REAL ADDRESSES --- */ #define FXOSC_CTRL_REG (*(volatile uint32_t*)(0x40288000U)) /* Corrected from 402D4000 */ #define FXOSC_STAT_REG (*(volatile uint32_t*)(0x40288004U)) /* Corrected from 402D4004 */ volatile uint32_t rawTimeoutCounter = 0; volatile uint32_t crystalStableResult = 0; int main(void) { /* 1. RAW PIN SETUP: Configure PTB5 as a High-Drive Output mapped to CLKOUT */ SIUL2_MSCR_PTB5 = (5U << 0) | (1U << 21) | (1U << 19); /* 2. RAW CLOCK ROUTING: Route the Raw FXOSC clock directly to the CLKOUT hardware block */ MC_CGM_CLKOUT_CNTRL = (1U << 24) | (0U << 16); /* Source = FXOSC_CLK, Divider = 1, Enable = 1 */ /* 3. RAW HARDWARE KICKSTART: Power on the External Crystal (FXOSC) analog circuitry */ FXOSC_CTRL_REG |= 0x01U; /* 4. NON-BLOCKING SOFTWARE POLL We read the raw hardware status register. If a crystal is physically oscillating, the status register will flip a hardware bit or report a non-zero value. */ for (rawTimeoutCounter = 0; rawTimeoutCounter < 800000U; rawTimeoutCounter++) { /* Check if the FXOSC status register reports it is locked and stable (Bit 31) */ if ((FXOSC_STAT_REG & 0x80000000U) != 0U) { crystalStableResult = 1; /* HW SUCCESS: Crystal is alive and shaking! */ break; } } /* 5. PASS / FAIL EVALUATION PADS */ if (crystalStableResult == 1) { /* --- CRYSTAL HARDWARE PASSED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for success */ } } else { /* --- CRYSTAL HARDWARE FAILED --- */ for (;;) { __asm("NOP"); /* Put a breakpoint here for a safe failure catch */ } } return 0; } I am attaching the board schematic for your reference. board_schematic.pngboard_schematic.pngboard_schematic.pngboard_schematic.png   Also attaching the .mex configuration for your reference. Re: 16MHz external crystal not working on the S32K314HMS custom board Hello @sksingh4476 , a 16 MHz crystal is within the supported FXOSC crystal frequency range for the S32K3 family, so the crystal frequency itself should not be the issue. However, from the raw code snippet it is not clear whether the complete FXOSC configuration is being applied. In particular, please check the FXOSC gain/transconductance setting (GM_SEL). In crystal mode, GM_SEL = 0000b should not be used, because this corresponds to zero transconductance and the oscillator may not start or become stable. Regarding the mex file: The generated clock initialization code must be called by the application. If the test code bypasses the generated RTD initialization and writes only a few registers manually, then all mandatory FXOSC settings, including GM_SEL, must also be configured manually. I would recommend first creating any standard S32DS/RTD example project and configuring the FXOSC through the Clock Configuration tool. Please verify whether the external crystal starts correctly with the generated RTD clock initialization code. This is a better baseline than starting directly with a minimal raw-register test, because the generated configuration should include all required FXOSC settings, including the oscillator mode and gain configuration. If the standard example works, you can then compare the generated FXOSC register values with your minimal code and gradually reduce the code to the smallest required sequence. If the standard example does not work either, then the next step should be to check the hardware side, especially the crystal parameters, ESR, load capacitors including PCB stray capacitance, layout around EXTAL/XTAL, and the gain margin calculation. The datasheet specifies the oscillator build-up condition using gmXOSC > 5 * gm_crit, so the selected crystal and external components should be verified against this requirement. Best regards, Pavel Re: 16MHz external crystal not working on the S32K314HMS custom board Hi PavelL, Thanks a lot for the quick response. I tried to find any example code from RTD but did not find one for the S32K314 MCU.  I tried calling the clock initialization function in my main function, but the crystal oscillator is still not working.  #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" int counter, accumulator = 0, limit_value = 1000000; void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } uint8_t Sys_GetCoreID(void) { return 0U; /* Force return Core 0 (Primary ARM Cortex-M7 Core) */ } FXOSC_CTRL, the value of GM_SEL is the default value 1100.  Please refer the attached clock configuration image for your reference. clock_config.pngclock_config.pngclock_config.png Also attached is the clock configuration file clockYaml for your reference.  We observed that another open source project can make the crystal work on the same board. Here is the code used in the main.c file. We observed that the clock configuration is almost the same as ours. I have attached the clock configuration for your reference. /* Including necessary configuration files. */ #include "Clock_Ip.h" #include "FreeRTOS.h" #include "task.h" #include "semphr.h" #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" //including uart+dma+interrupt files #include "Lpuart_Uart_Ip.h" #include "Lpuart_Uart_Ip_Irq.h" #include "string.h" #include "IntCtrl_Ip.h" #include "lpuart0.h" #include "Dma_Ip.h" #include "Dma_Ip_Irq.h" #include "CDD_Rm.h" #define LED_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 ) #define WELCOME_MSG_1 "hello world uart dma\r\n" void Led_Task( void *pvParameters ) { (void)pvParameters; for( ;; ) { Lpuart_Uart_Ip_SyncSend(LPUART_UART_IP_INSTANCE_USING_0, (const uint8 *)WELCOME_MSG_1, 20, 0XFFFF); Siul2_Dio_Ip_TogglePins(USER_LED0_PORT, (1 << USER_LED0_PIN)); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { /* Initialize Clock */ Clock_Ip_StatusType Status_Init_Clock = CLOCK_IP_ERROR; Status_Init_Clock = Clock_Ip_Init(Clock_Ip_aClockConfig); if (Status_Init_Clock != CLOCK_IP_SUCCESS) { while(1); /* Error during initialization. */ } /* Initialize all pins using the Port driver */ Siul2_Port_Ip_PortStatusType Status_Init_Port = SIUL2_PORT_ERROR; Status_Init_Port = Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals); if(Status_Init_Port != SIUL2_PORT_SUCCESS) { while(1); /* Error during initialization. */ } //Init Interrupt Control IntCtrl_Ip_Init(&IntCtrlConfig_0); //Init lpuart0 Lpuart_Uart_Ip_Init(LPUART_UART_IP_INSTANCE_USING_0, &Lpuart_Uart_Ip_xHwConfigPB_0); //DMA init Dma_Ip_Init(&Dma_Ip_Sa_xDmaInitPB); /* Initialize Rm driver for using DmaMux*/ Rm_Init(&Rm_Config); //turn of AsyncReceive of uart dma, this code must behind Rm_Init(&Rm_Config); Lpuart_Uart_Ip_AsyncReceive(LPUART_UART_IP_INSTANCE_USING_0, Lpuart0_Receive_Buffer, LPUART0_RECV_BUF_LEN); xTaskCreate( Led_Task , ( const char * const ) "Led_Task", configMINIMAL_STACK_SIZE, (void*)0, LED_TASK_PRIORITY, NULL ); vTaskStartScheduler(); for( ;; ); return 0; } I am wondering what clock configuration can make this difference.  Thanks, Sunil Re: 16MHz external crystal not working on the S32K314HMS custom board Hello @sksingh4476 , Thank you for the update and for sharing both configurations. I noticed an important difference between the two code examples. In the minimal test, only Clock_Ip_Init() is called, while the working project also calls Siul2_Port_Ip_Init() immediately afterwards. If you determine whether FXOSC is operating by observing the CLKOUT signal on an external pin, the corresponding SIUL2 pin must also be configured for the CLKOUT alternate function. Clock_Ip_Init() configures the clock tree, but it does not by itself configure the physical output pin. Could you please clarify how you currently determine that FXOSC is not working?   Best regards, Pavel
查看全文
RT117x RTC_XTAL(OSC_32K) 测试输出引脚 你好, RT117x中是否有办法测试RTC_XTAL(OSC_32K)的频率? 我在参考手册的时钟树中找到了 24MHz 时钟的,但没有找到 32K 时钟的。 此致敬礼, 马尔万 Re: RT117x RTC_XTAL(OSC_32K) test output pin 嗨@Marwan , 在 i.MX RT1170 上,您可以按照表 11-1 中所述,使用 ALT9 将 REF_CLK_32K 连接到 GPIO_AD_13。i.MX RT1170 处理器复用选项参考手册。 这样,你就可以用示波器直接探测 32.768 kHz 时钟了。 此致, 巴勃罗 Re: RT117x RTC_XTAL(OSC_32K) test output pin 感谢您的帮助,我对 CCM_CLKO 信号感到困惑。
查看全文