This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具与软件:
我们发现、在软件运行时、一个联合体变量可能发生了意外更改。
有关的现象
tPFC_ctrl.bit.OnOff 是在 CpuToCla1MsgRAM 中定义的、并且会 发生意外更改。 代码不会 将0分配给 tPFC_ctrl.bit.OnOff、但会将高速更改为0、然后恢复为1。
我们使用 GPIO 观察 tpFC_ctrl.bit.OnOff、它将不定期地更改、每次在20us 内恢复。
问题
对于这个问题,我们找到了两种解决方法。
关闭 编译器优化(从3 ->关闭)。
2.use volatile 关键字、用于定义 tPFC_ctrl。
问题来了
为什么编译器优化会让此问题发生?
2.如何使用编译器优化级别来避免此类问题。
另一次尝试
尝试 在 Cla1ToCpuMsgRAM 中重新定义 tPFC_ctrl、问题就会消失。 这意味着只有 CPU 允许问题发生、而不是 CLA。
我们使用 const 关键字 定义 tPFC_ctrl、只能使用指针访问 tPFC_ctrl 、但问题仍然存在。
您好!
如果只指定为易失性、您能否确认其是否发生更改。 将优化保持在级别3。 您能否确认此联合体已分配给 CLA 和 CPU 均可访问的存储器。
此致、
Ozino
当在级别3进行优化时、将1.it 指定为易失性时不会更改
可以确认对 CLA 和 CPU 都可以访问的联合体。 (在 CpuToCla1MsgRAM 中定义的联合体,使 CPU 可以读取和 wirte , CLA 只能读取。
您好!
我来看看 CpuToCla1MsgRAM、然后会向您提供更多信息。
此致、
Ozino
您好!
您能否确认是否使用 tPFC_ctrl 在 CLA 或 CPU 上运行? GPIO 映射到 CPU 还是 CLA?
此致、
Ozino
1. tPFC_ctrl 将在 CPU 上读取或修改、并且只能在 CLA 上读取。
在 CPU.WE 上运行的 GPIO 观察函数。我们使用 TI lib 寄存器 来操作 GPIO、如(GpioDataRegs.GPACLEAR.bit.GPIO29 = 1;)。
对于2:实际上 、此代码用于功率控制、 tPFC_ctrl 将影响我们的控制 算法代码。 所以、我们首先会发现我们的机器毫无理由地关闭、然后我们使用 GPIO 来找到问题所在。
表示、如果观察 tPFC_ctrl 不影响 意外变化 现象。
您好!
您能否检查是否已执行此处详述的步骤:
确保正确共享数据。
此致、
Ozino
好的、我发现我们现在有一些问题。
我想知道如何 在 CPU 中使用 unsigned short 大小 ?
您好!
可以在《编译器用户指南》中找到有关 C 2000数据类型的更多信息。 请看表和第6.4节。
https://www.ti.com/lit/ug/spru514r/spru514r.pdf#page105
此致、
OZINO