[参考译文] TMS320F28069：在 CLA 代码中定义共用变量-第2部分

尊敬的 Luiz：

您可以共享代码段、了解如何定义.cla 文件和.c 文件中的变量？ 在这2种情况下、分配给它的地址可能会有所不同。 我怀疑这可能是由于某些硬件故障、CLA 在第二种情况下无法访问该地址。

此致、

Veena

您可以检查.map 文件以在这两种情况下获取变量的地址

您好、Veena：

感谢您的答复。
可疑变量是 Cla1ToCpuMsgRAM。 所以、是 CPU 无法访问 CLA 变量。 您是否认为此特定存储器段中存在硬件故障？  
您是否有任何建议的方法来 核实可疑情况？
如何检测此硬件故障？


下面是我如何在版本和生成的映射文件中定义它们。

e2e.ti.com/.../cla_2D00_issue_2D00_20230419.pptx



此致、
Luiz

是否可以将 DATA_SECTION pragma 替换为#pragma location (addr)、以强制地址到达指定位置。 因此在这两个选项中、地址保持不变。

此致、

Veena

强制地址位于特定位置的目的是检查该位置是否存在任何硬件故障、是否正确？
在这里、您可以看到、CLA_ADC_DATA_DCDC_Vout 使用了 V0中未检测到 CLA 问题的特定位置(0x14b8)、并且不存在问题。
因此，我仍然对如何实现这一目标感到困惑。

*另请注意、V1遵循 CLA 开发指南、介绍如何在 C 代码中定义共享变量。

此致、
Luiz

是的、务必确保该地址没有硬件故障。  

您是说 C 代码(右侧的那个)中定义的变量是有效的、而另一个有问题吗？

此致、

Veena  

不可以、右侧的图在访问 CLA_LPF_CTRL_DCDC_Vout 时存在问题。 此 V1版本定义了 C 代码中的变量。
我认为在 V0版本上访问同一地址(CLA_ADC_DATA_DCDC_Vout)或变量(在 CLA 代码中定义了共享变量)的同一变量(CLA_LPF_CTRL_DCDC_Vout)不存在任何问题。

此致、
Luiz

至于检查地址(0x14b8)处的硬件故障。 已确认在 V0版本中、地址由  CLA_ADC_DATA_DCDC_Vout 使用、我看不到任何问题。


此致、
Luiz

关于这一事项的最新情况
1. 此变量中的问题是间歇性的，只要复位后该值为零。 在执行电源复位之前、该位始终为零。
  如果在电源复位后该变量返回正常值、则它始终是正常的。 因此、我想检测变量 itsefl 并通过 CLA 软/硬复位来复位 CLA。

想法是否可行？

2.问题似乎与 CLA 变量的放置无关，因为我试图转移地址分配，问题仍然存在。

   CLA1_MSGRAMTEST      : origin = 0x001480, length = 0x000040
   CLA1_MSGRAMLOW       : origin = 0x0014C0, length = 0x000040
   CLA1_MSGRAMHIGH      : origin = 0x001500, length = 0x000080
   
   //variable of interest is in Cla1ToCpuMsgRAM
   //tried to shift from 0x1480 to 0x14C0
   Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW,   PAGE = 1
   CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH,  PAGE = 1

Unknown 说：

否，右边的那个在访问 CLA_LPF_Ctrl_DCDC_Vout 时出现问题。 此 V1版本定义了 C 代码中的变量。
[/报价]

这个问题只能在一个设备上产生，同一个应用程序可以在不同的设备上正常运行。

此致、

Veena

平均而言、这些症状发生在我们生产的板材中的10%上。 因此、我们必须停止我们的生产线。

在重新排列一些 CLA 共享变量(添加虚拟数据、移动地址)的过程中解决了这些 MCU 的问题、但之前正常运行的其他 MCU 现在仍然会遇到问题。

这个 CLA 共享变量在多个 MCU 上的不一致性正变得有问题。 我们无法在每次遇到新一批 MCU 问题时都继续更改固件。 我们如何确保 MCU 之间的一致性和可靠性、并尽可能降低未来遇到这些问题的可能性？

现在、我将尝试在前几秒检测到0值时使用 CLA 硬复位方法。

对此进行更新、 通过软件复位 CLA 和 CPU 不起作用。 我使用该寄存器复位 CLA Cla1Regs.mctl.bit.hardreset 和 CPU 的看门狗复位。

只有通过电源复位(关-开)才能获得正常值。 平均而言、CLA 问题会在10次上电中出现1次。

此致、
Luiz

Unknown 说：

平均症状发生在我们生产的板10%上

您能否确认它在所有电路板中运行的是完全相同的.out？

此致、

Veena

我们将对 TI 格式.txt 文件使用引导加载程序。 我们还添加了文件完整性检查、因此我可以确认它来自相同的输出文件。

此致、

Luiz

Unknown 说：

1.  只要复位后该值为零、该变量中的问题就会是间歇性的。 在执行电源复位之前、该位始终为零。
  如果在电源复位后该变量返回正常值、则它始终是正常的。 由此、我想检测变量 itsefl 并通过 CLA 软/硬复位来复位 CLA。

我不确定我是否理解这种说法。 上电复位时、RAM 存储器可能包含一些无用的值、直到应用程序将变量初始化为某个值。 您是说此初始化未生效吗？

复位后、您在哪个位置检查变量是否为0？

此致、

Veena

要添加、Cla1ToCpuMsgRAM 对于 CPU1是只读的。 如果变量 在 CPU1中进行初始化、写入将被忽略。 我认为 CLA 正在初始化这些变量。

此致、

Veena

关于电源复位、我曾提到过、因为问题是不一致的。 我们通过在板打开后在 GUI 上读取0值来注意到这个问题、它始终显示0值、而不仅仅是在初始化期间。 有时、当主板关闭后再重新打开时、此问题可能会消失。 一旦我们得到该值的正常读数、我们就可以说该值在导通期间是正常的。

为了添加说明、错误读数不限于初始化过程。 我知道 RAM 存储器在上电复位时可能会显示垃圾值、因此我一直在 MCU 完成初始化并在循环中运行后对变量进行监控。 我最近发现 CPU 正在从 CLA 读取一个值0x7F800000、这转换为无限浮点值。 可能是由于数据解析导致的、它在 GUI 上以某种方式显示为0值。

相关变量是 CLA 任务中 ADCresult 的滤波值。 我已经验证 ADCresult 值、滤波器常数和(n-1)值都是正常值。 但是、输出滤波器值遇到问题并返回0x7F800000、这转换为无穷大浮点值。 该值保持冻结在该值、 而其他正常变量会随着时间的推移而略有变化、因为 ADCresult 值不断变化。


此致、
Luiz

讨论正在 离线进行。