[参考译文] MSPM0G3518：MSPM0G3518：间歇性 ADC Vref 监控压降

尊敬的 Mohamed：
我认为您可能会遇到器件的 勘误表 ADC_ERR_06、我建议查看勘误表文档中提供的此行为的权变措施。

对于建议的采样保持时间、具体取决于您的应用。 我找到了这个主题、可以帮助您更好地了解选择不同采样保持时间背后的理念： https://electronics.stackexchange.com/questions/26329/what-is-the-purpose-of-adc-sampling-time

由于这些值似乎在勘误表之外、您能否分享有关 MSPM0 所附设置的更多详细信息？ 我需要这些信息来再次与我的团队内部核实。  

此致、

Diego Abad

尊敬的 Diego：

感谢您的快速答复并为我提供这些资源。
我已经研究了这两种可能性、但我的 ECU 中的数据似乎与这两个根本原因都不一致。
下面是我发现的:
采样时间 (SCOMP0)：
-我的 ADC 时钟在 32MHz 运行,我的 SCOMP0 被设置为 160 个时钟周期。
这将提供 5µs 的有效采样保持时间、该时间应大于内部电容器稳定所需的足够时间。
因此、我认为这不是 RC 时间常数问题。

2.勘误表 ADC_ERR_06：
-它指定错误导致固定的+/- 64 LSB 跳变。 不过、我的 ADC 压降要大得多。
预期读数为~1362。
读数通常降至~1210（~152LSB 偏差）。
在最坏的情况下、我已经发现它下降到~1038（~324 LSB 偏差）。

由于我的偏差是高度可变的并且明显大于 64LSB、因此与 ADC_ERR_06 中描述的固定 64 LSB 行为相矛盾。
此外、由于这是一个安全关键型 Vref 监控模块、因此通过实施软件平均来屏蔽 10-24%的可变压降、而无需了解真正的硬件根本原因会引发功能安全风险。

（注意：我还排除了 ADC_ERR_10 MEMRES 交换、因为我的其他有源 ADC 通道在 3400–4082 范围内运行）。

此致、
Mohamed

您好 François、

感谢您的支持。 以下是您问题的答案：

-这个问题已经在多个板上重现,所以我们排除了一个有缺陷的 MCU。

-不,时间是可变的。 虽然这通常需要 2-3 分钟、但我还观察到在下电上电后不到 2 分钟内出现了下降。

-我们的预期 ADC 代码是~1363 十进制。 我们的安全容差为 10%、这意味着 ADC 代码的可接受范围约为 1226 到 1499。
 我看到的压降 (~1210、有时会降至~1038) 远远超出此有效窗口。

-我们不使用 DMA、也不使用 ADC 的中断。 根据我们的 MCAL 配置 (ADC_Group_Polling 和  ADC_Trigg_SRC_SW)、ADC 完全由软件触发。
 我们有一个会触发组转换的循环操作系统任务（（IoHw Ab_Adc_Main 函数）。
 只需使用标准 AUTOSAR ADC.Group Adc_Read 读取数据、该 API 将原始 ADC 代码放入标准全局 RAM 数组中。
 因为这是循环任务中一种简单的轮询读取、所以我们不怀疑后台 DMA 或 ISR 存储器损坏。


此致、
Mohamed

尊敬的 Mohamed：

非常感谢您提供的全面答复。

为了排除软件问题、您能否配置模拟比较器及其 DAC、以便它检测低于 1226 的 ADC 代码或接近您阈值下限的任何值、因为模拟比较器的基准 DAC 是 8 位 DAC。 这将排除与 ADC 相关的任何问题、因为比较器在引脚电平获取模拟信号。

此致、
François μ s。

尊敬的 Mohamed：
您正在将 MCAL 软件用于该工程。 我将请求我们的 MCAL 团队成员介入以确定此问题的来源。
此致、
Diego Abad

尊敬的 Mohamed：

我的团队的调查仍在进行中、我想询问有关此问题的一些信息：
在这种情况下、ADC_ERR_10 很可能适用。 您能否告诉我、切换以下 GPIO 后是否发生了任何 ADC 代码增量： PA15、PA18、PA22 或 PA21？

此致、

Diego Abad

尊敬的 Mohamed：
进行跟进、以防您错过我之前的信息：

您能否告诉我、切换以下 GPIO 后是否发生了任何 ADC 代码增量： PA15、PA18、PA22 或 PA21？

此致、

Diego Abad

尊敬的 Diego：

为延误道歉！

是的、我们确实将 ADC_ERR_10 调查为一个潜在的根本原因、但数据和我们的硬件设置似乎与它不一致的原因有两个：
1、引脚用途（频率）：
勘误表中注意到 PA15、PA18、PA22 或 PA21 上的快速开关信号 (>12kHz) 会发生这种情况。
在我们的设计中、这些特定的引脚用于简单的开关测量。 它们不会输出高频 PWM 或在接近 12kHz 的任何频率下切换。

2. ADCMEMRES 交换值：
勘误表介绍了 ADCMEMRES 交换。 我的所有其他有源 ADC 通道都在 3400–4082 范围内运行。
如果发生交换、我会预计 Vref 通道（通常~1363）会跳至 3000。 相反、我们看到一个大的下拉电阻降至~1210（很少~1038）。
除非 ADC_ERR_10 中提到的转换时钟损坏可能会导致读数严重截断（而不是干净的交换）、否则我们认为此勘误表不是问题根源。

MCAL 团队是否有机会查看我之前提供的 ADC_PBcfg.c 和 IoHw Ab_Adc 轮询配置、以排除软件/寄存器轮询问题？

此致、
Mohamed Abdelfatah

尊敬的 Mohamed：
MCAL 尚未对这两个文件发表评论、但 ADC 团队目前正在调查这是否可能是硬件问题。 我也会推送他回顾 MCAL 工具。

此致、

Diego Abad

尊敬的 Mohamed：
关于 ADC_ERR_10、您能否确认在捕捉错误值时遇到的问题是否每当发生在之前提到的任何引脚切换时（不需要是高频信号）？

此致、

Diego Abad  

尊敬的 Diego：

实际上、当我捕获到错误的值（下降到~1210 或~1038）时、这些特定的开关引脚 (PA15、PA18、PA21、PA22) 是完全静态且不会改变的。

我还回顾了我们的硬件和 MCAL 配置：

• 在我们的软件Port配置中、内部拉电阻器被禁用 (PORT_PIN_PULLTYPE_NONE)。

• 但是、在我们的物理 PCB 上、每个模拟开关线路都有专用的外部硬件上拉电阻 (430Ω 连接至 3.3V) 以及一个连接至接地的 10nF 滤波电容器。

因此、我认为这些引脚不是悬空的、会拾取 MCU 可能会解读为快速切换的高频噪声。

此致、
Mohamed

尊敬的 Mohamed：
感谢您的澄清。 我有几个后续问题：

PA13 是否也与提到的其他引脚 (PA15、PA18、PA21、PA22) 相同？ 您能不能在出现问题时告诉我此引脚的状态？
2.您能否分享针对此 ADC 读数的设计原理图？ 我希望更好地了解系统、以便重现此问题。  
3.受此问题影响的电路板有多少? “是不是全部都忘了?“  
4.能否提供存在问题的 MSPM0 器件的批号（丝印编号）？
5.如果有电路板不受此问题的影响、您能否将 MSPM0 从非错误电路板换用至错误电路板、然后查看器件是否有问题？

此致、

Diego Abad

尊敬的 Diego：

感谢您继续对此进行研究。 以下是您后续问题的答案：

1.是的、PA13（在我们的设计中映射到 ADC0_9 / Right_IN_4_A_MC）是完全相同的情况。
它连接到一个相同的开关检测电路、该电路具有一个 430Ω 硬件上拉电阻和一个 10nF 滤波电容器。
每当发生压降问题时、PA13 也会完全静态且未被按下。

2.相关示意图上载在下面所附的驱动链路中。

3.我已经测试了 2 块板,它们也有同样的问题。

4、批号：MSPM0G3518Q TI 549C AT4T 64（我还附上了 MCU 的照片）

5、由于我们制造的每块板目前都出现了这一问题、因此遗憾的是、我们没有“已知良好“板。

请告诉我 MCAL 团队是否也对软件轮询配置有任何反馈意见！

此致、

Mohamed

https://drive.google.com/drive/folders/11FbrEqg3HfFbeBVT93sKnFXKHhwLvcpu?usp=sharing

尊敬的 Mohamed：
感谢您分享信息和驱动器链接。 请授予我访问权限、这样我和我的团队就可以查看系统和原理图。 我有一些后续问题、我想再次确认：

1.大跳是否总是在下侧,即,总是低于预期?
2. 什么是连接到 ADC 输入的输入网络（什么是板载电阻和电容）? （可能在原理图中。 看到它后，我应该能够找到）
3.根据 ADC_PBcfg.c 文件、禁用重复模式。 是这样吗？ 此外、ADC 是否设置为自动进入断电模式、您的应用使用哪种低功耗模式？

4.我的团队建议检查 ADC MEMCTL_y 寄存器的 VRSEL 位是否设置为 VDDA_VREFM (011b)、而不是 VDDA_VSSA (000b)。 请告诉我它是否设置为 VDDA_VREFM；如果没有、请将其设置为 VDDA_VSSA 并查看问题是否仍然存在。  

我仍然没有收到关于您分享的.c 文件的反馈。 我将再次询问我的团队。  

此致、

Diego Abad

尊敬的 Diego：

感谢您和您的团队对此进行深入研究。
我刚刚授予您访问驱动器链接的权限、以便您查看原理图。

以下是您问题的答案：

1.是的,它总是一个滴。 我们的标称预期读数为~1363。 异常读数始终较低、通常降至~1210、有时降至~1038。 它绝不会跳至高于标称范围。

对于该特定的 Vref 监视器、我们会读取硬件通道 15 (.hwChannelId = 15u)、这是一个内部测量通道。 您可以在我刚才提供的原理图中查看我们其他通道的外部开关检测输入。

是的、我可以在 ADC_PBcfg.c 中确认.repeatMode = ADC12_repeat_mode_disabled 且.convMode = ADC_CONV_MODE_OneShot。
关于电源模式：在此测试过程中、我们的 ECU 应用仍处于活动模式。 我们不会明确命令 ADC 在循环软件轮询触发条件之间进入断电状态、除非 MCAL 在 Adc_Read 集团序列期间底层处理自动断电。

4.在我们生成的 ADC_PBcfg.c 中、该通道的电压基准明确配置为.voltageReference = ADC12_VRSEL_VDDA。
假设 MCAL 正确地将 ADC12_VRSEL_VDDA 转换为 VDDA_VSSA (000b) 寄存器值。 MCAL 团队能否验证 MCAL 是否存在 MCAL 意外写入 VDDA_VREFM (011b) 的已知问题？

期待了解 MCAL 团队在.c 文件方面的发现！

此致、
Mohamed

尊敬的 Mohamed：

我这边还有一个问题、为什么信道 15 1.08V 读取的值是多少？

我的团队查看了您发送的.c 文件、似乎没有明显的问题。 他们现在将尝试在设置中重现问题。 我会在收到更新时通知您。

此致、

Diego Abad  

尊敬的 Diego：

我们测量的是硬件通道 15、它是内部电源/电池监测器、而不是静态 VREF。

由于电源监控器将 VDD 除以 3、因此我们的 3.3V 电源在 ADC 处产生大约~1.1V 的电压、这在数学上与我们的标称 ADC 代码~1362 相匹配。

但是、核心错误仍然存在：此内部电池监控器读数降至~1210 (0.97V) 或~1038 (0.83V)。

是否存在可在运行时断开 VDD /3 电阻分压器或使其下降的已知问题、稳定期或内部节能机制？ 由于我们依靠这个内部通道进行安全诊断、因此我们需要了解内部节点电压为什么会下降。

此致、
Mohamed

尊敬的 Mohamed：

我认为在 稳定周期方面存在已知问题、或者在运行时断开 VDD /3 电阻分压器或使其下降的内部节能机制没有问题。 该问题可能与地面问题有关（尽管我们仍在评估它。）

我的团队确认、您提供的文件在我们当前版本的 MCAL 中运行正常、即无法复制问题。 此外、我们确认了电流配置会将 ADC12_VRSEL_VDDA 设置为 VDDA_VSSA (000b) 寄存器值。 我们有关于问题如何发生的一些后续问题：

1.调试时是否发生问题、即使用 PA19 和 PA20 作为 SWDIO 和 SWCLK 时？ 如果删除了调试器、该问题是否也会发生？

2.您的团队使用哪个版本的 MCAL？

此致、

Diego Abad

尊敬的 Diego：

感谢您发送编修。 下面是我这边有关您问题的更新信息：

• 当调试器处于主动连接状态时会出现问题。  我们使用 IDE 的实时监视窗口来捕获电压突然下降到~1210/1038。 并且 我们没有让 MCU 进入睡眠状态。 我们的 FreeRTOS 空闲挂钩仅执行标准后台任务（存储器栈和安全检查）、不会调用WFI或转换到低功耗状态。

• 所使用的 ADC 插件取自 MCAL 版本“MCAL MSPM0_00.02.05.00“。

请告诉我、您的团队是否需要在故障状态期间进行任何特定的寄存器转储、以帮助进行复制！

此致、
Mohamed

尊敬的 Diego：

请将我的巨大感谢传递给您的团队。 这是一个奇妙的问题、作为串扰/噪声注入问题是完全合理的。

我通过将 iSYSTEM 调试器中的 SWD 移位时钟降低到 500kHz、测试了您的软件权变措施、但读数仍然下降。 我们当前 PCB 布局上的噪声耦合似乎太严重、无法通过软件缓解、可能会因您的团队指出的细长 VCORE 迹线而加剧。

为了确认您的理论、我编写了一项无头测试、该测试在 ADC 降至阈值以下时会切换 GPIO 引脚（通过逻辑分析仪进行监测）。 我刷写了该电路板并使用了远程测试架来物理断开 SWD 电缆与调试接头的连接。

在物理断开调试器的情况下、ADC 读数完全稳定、逻辑分析仪绝不会触发。

这证实了 SWD 串扰是导致该问题的唯一原因。

再次感谢您坚持不懈地跟踪此问题。 您可以继续、将此 TT 标记为已解决！

此致、
Mohamed

您好、Mohamed、感谢您的反馈。  

 Diego Abad Sajamin :为这个发现感到骄傲！