[参考译文] TMS320F28.0049万C：GPIOs在调试之外表现不正确

您好，

您能否提供一些有关不当行为的详细信息？ 这是时间问题还是GPIO根本不切换？

如果您可以共享代码片段，以便在我们的最后重现该问题，这将很有帮助

此致，

Veena

您好，

很抱歉回复延迟，我只是找到了时间来整理我的代码以共享它(以下链接)：

https://drive.google.com/file/d/1P8HhEfuESSlfP0V-1Nh4TA1IJiq9QP-R/view?usp=sharing

该板(Amon其他)用于通过打开继电器为输出施加正确的电压，以将正确的输入连接到输出。 由于控制卡上没有足够的IOS，我们使用多路复用器对继电器进行编码以进行控制。

当没有选择电压时( SetVoltage(0)；这是此代码的唯一功能)，将选择多路复用器的未使用输出。 在所有其他情况下，将选择与所需电压对应的继电器。

在"调试模式"(即对控制卡编程，按"播放"并等待)中，我观察到电路的输出未连接到任何输入。

在"正常模式"(即只打开电路板电源)中，我观察到一个继电器闭合，并将输出连接到一个输入。 此外，闭合继电器/连接的输入并不总是相同：连续通电/测试/断电会产生不同的结果。 这意味着，在"正常模式"下，多路复用器的输入(即GPIO输出)与"调试模式"在某种程度上是随机的。

这种现象已在2个不同的继电器板上通过2个不同的controlCARD进行了验证。

正如你所能想象的，我觉得这非常让人担忧。

您好Adrien：

根据您的代码，我了解您正在设置和清除setVoltage函数中的几个GPIO。 您能否监控范围内的这些GPIO并验证GPIO输出是否不同？

我运行了您在controlCARD上共享的代码并 监控了引脚2,3,12,13,14。 在调试模式和独立模式下，我将输出视为0,0,0,1,1。

此致，

Veena

您好，Veena，

您对代码的使用绝对正确。 GPIO转到多路复用器(顺便说一下，TI参考)，而这些复用器又驱动继电器。

到目前为止，我们的观察基于继电器的状态，以及前面描述的奇怪的随机现象，假设GPIO行为正常(这似乎合理， 因为我们可以观察继电器状态与调试模式下发送的指令之间的完美相关性)。 但是，根据您的上一条评论，我去看了GPIOs，虽然一些谜题似乎已解决，但其中一些仍然非常开放。

以下是我的观察：在调试和正常模式下，GPIO处于正确的电平(0/1)，但它们的电压不正确(调试模式下为0-3.3V，正常模式下为1-3.3V)。 由于多路复用器的输入低电平为0.5V，且在正常模式下，GPIO仅为低电平1V，因此多路复用器未处于正确确定的状态，因此具有某种随机行为。  

因此，现在的问题是，为什么GPIO的低状态阻抗在正常和调试操作中可能不同。 我禁用了内部上拉功能，似乎没有达到目的。 所有这些GPIO都是ePWM，因此，如果我没记错的话，它们应该比其他GPIO具有两倍的驱动功率，如果这一点与较旧的部件没有变化的话(TMS320F2803x是这种情况，但我没有查看此部件的数据表)。  在controlCARD和多路复用器之间的路上没有组件或嘈杂的轨道，这些不需要大量电流，既不需要汇电流也不需要源电流。  

我将继续朝这个方向进行调查(非常感谢在这方面的指导)，但所有想法仍然非常受欢迎。  

此致，

Adrien

您好Adrien：

当我尝试设置中的代码时，我能够在两种情况下观察到0V和3.3V。 理想情况下，独立执行和调试执行之间应该没有任何区别。

我会让硬件专家帮您更好地解决问题。

此致，

Veena

您好，Veena，

事情变得越来越奇怪。

我试图继续解决这个问题，从一些测量开始...我得到了与昨天不同的结果。 设置中没有任何更改(只移动了位置，因为我昨天在家庭办公室)，代码中没有任何更改，但我没有测量相同的位置！

因此，今天，电压在正常操作中大致正确(低状态为0-100mV)，并且在多路复用器输入范围内。 但是，GPIO输出错误：I对于GPIO2,3,12,13,14 ，我得到的是0,0,0,0,0,0,0,1，而不是0,0,0,1,1。 调试操作中的级别正常。

我现在完全迷失了，我不知道如何前进。  

Adrien，

您是否有用于 将controlCARD插入的TMDSSEDOCK EVM？ 我真的觉得第一步应该是断开与设备的外部硬件连接。

删除所有内容后，我建议测试您的设备输出。  

如果您在设备通电之前为GPIO供电，则可能会导致闩锁状态。 如果您重新启动设备，则锁扣状态将被消除。 然后，如果在启动之前设备针脚仍接通电源，则在下一次通电时，可能会也可能不会再次发生这种情况。  

您是否还可以分享您实际连接到设备PIN的详细信息？

此致，
科迪  

Cody，

我有 一个TMDSHSECDOCK，但目前正在由一位同事使用。 我会看看是否可以借用。  

关于到引脚的连接，这是非常容易的：除了我所选的多路复用器之外，没有其他的了：

没有其他任何内容与这些GPIOs相关。  

为多路复用器提供的3.3V与控制器(controlCARD上具有自己的5V至3.3V LDO的MCU)不同。 由于GPIO仅连接至多路复用器的输入，因此rhere不应是从多路复用器的输入返回的任何电压，但这是可能的。 我会检查这方面，并告诉你。  

Cody，

下面是启动顺序的捕获

黄色代表5V，红色代表3.3V代表多路复用器，蓝色代表3.3V代表MCU，绿色代表GPIO15。

研究了所有连接到多路复用器的GPIO，它们的情况都是相同的：启动时电压不会超过0.5V。

这样的电压是否会导致您提到的闩锁？

我需要为多路复用器订购更多的LDO，以查看是否通过延迟其打开来解决问题。  

请注意，

Adrien

Adrien，

您是否能够在没有外部连接的情况下运行？

就其价值而言，我认为您不会遇到闩锁问题，但可能值得尝试将GPIO 15上的一小部分拉下来，看看情况是否会消失。 我没有发生锁扣的确切阈值，我曾询问我们是否在这里有一些指导，但可能只是您不应在启动前施加电压。

延迟多路复用器电压斜坡似乎是个好主意。 我看了mux的数据表，没有看到IO电流消耗数字，如果超过4mA，或者内部有很强的上拉，那么它可能会使GPIO缓冲器过载，但似乎也不是问题所在。

此致，
科迪

只要电流保持在我们ESD二极管的限值20mA以下，闩锁似乎就不是太大的问题。

此致，
科迪  

您好，Cody：

寻找合适的创业顺序让我陷入了疯狂的兔子之路。  

正如建议的那样，我增加了对GPIO的下拉，并延迟了Demux 3.3V的启动。 没有解决。

有一件事导致另一件事，我注意到我无法从MCU得到任何东西：所有GPIO都卡在0V。 我一直在寻找，发现如果我在初始配置中设置占空比，我可以得到一些PWM，但如果我在无限循环中设置占空比，我就不能得到！ 经过多次试验后，它似乎是来自计时器中断。

下面是最新的观察结果。 我有一个100kHz的计时器中断。 我将GPIO设置为在中断开始时高电平，在退出之前低电平。 在调试模式下，中断大约需要5us，这为其余的中断留出了大量时间。 在正常操作中，中断大约需要35US，因此，新的中断在前一个中断结束时立即开始，没有时间执行任何其他操作(包括为GPIO设置正确的值)。 如果我注释了大量的中断代码，则GPIO将采用正确的值，一切正常。  

我现在就在这里。 GPIO问题似乎只是实际问题的一个症状：中断代码在正常模式下比在调试模式下执行要花更多的时间，并且它会停止其他所有操作。 为什么在地球上代码需要不同的时间来执行...不是线索！

当然，任何想法都值得高度赞赏。  

Adrien，

设置XCLK并验证您的时钟速度，因为您遇到计时问题。(我不期望这是错误的，但它是一个良好的基本级别检查)

其次，在连接调试器和不连接调试器的情况下，指令将执行完全相同的周期数。 如果花费的时间更长，我希望它通过您的ISR代码采用不同的分支。 您的ISR有多复杂？ 通常，您会希望它尽量简短。首先，我会调试该代码，然后可能会对代码块进行注释，以了解问题可能出在哪里。

此致，
科迪  

Cody，

我已经检查了XCLK，它在两种模式之间没有变化。  我还测量到 PWM输出在两种情况下的频率相同。 此外，内部时钟的问题不会也会降低计时器的频率，因此在2个中断之间保持相同数量的指令“空闲”吗？

此中断只是数据收集中断。 它会重复非常相似的代码行~20次：  

if(GPADATn == 1) {Variable_n |= IO_MaskSet;} else {variable_n &= IO_MaskClear;}

其目的是保留每个GPIO的16个连续值，并且仅在所有样本相同的情况下(变量= 0x0000或0xFFFF)才起作用。  

由于我不对主板执行任何操作，包括输入信号，仅调试，电源循环，比较，代码在两种模式下通过不同分支是很奇怪的。  

此外，如果我将中断简化至如下的极端，问题仍然存在：  

interrupt void TimerInt(void)
{
	GpioDataRegs.GPASET.bit.GPIO25 = 1;

	GpioDataRegs.GPACLEAR.bit.GPIO25 = 1;
	
	PieCtrlRegs.PIEACK.bit.ACK1 = 1;
	return;
}

使用此代码时，示波器在GPIO25上读取100kHz脉冲，0.7 % 占空比处于调试状态，3.1 % 占空比处于正常操作状态。 不幸的是，这与这个问题是一致的。

正常模式和调试模式之间是否有任何其他区别？ 可能在RAM中工作，而不是在闪存中工作？  

您好，Cody：

CCS是否可能更新某些监视(变量，内存...)，这可能会干扰ISR的执行？

此致，
François。

Adrien，  

是的，这就是为什么我没想到这是您的问题。 我刚才只是在解释清楚。  

28.0049万/4021252#4021252"]此外402.1252万此外，402.1252万，内部时钟不会出现问题，因此可以减少相同数目的定时器的频率。

您是否使用memcopy将函数移动到RAM？ 您是否从闪存执行？ 由于预取和等待状态，这将显著降低执行速度。

Francois，

我在连接CCS的情况下运行的代码实际上比独立代码要快，所以我不觉得这是问题。 我希望CCS干扰会减慢执行速度。

此致，
科迪

您好，Cody：

一切都从闪存运行。 以前有一些旧零件(F2802x和F2803x)的示例，说明如何将函数复制到RAM， 但是我 打开的六个示例中我没有找到任何一个(我发现的文档非常不清楚。例如 ，本文中的所有链接 都被破坏了，使其毫无用处)。 我没有想到这可能是一个问题，从RAM运行代码的收益当时并不是那么大：速度仅为20 30 % ，不是目前情况下的3-4倍。  

也就是说，只有当代码在调试中从RAM运行时，它才是相关的。 如果在两种情况下都是从闪存运行，则问题应该出在其它地方。 在调试过程中，代码是否从RAM运行？

Adrien，

您必须查看链接程序命令文件，以查看代码执行位置。 如果将构建配置更改为"flash"，则在使用flash时，您可以看到可以使用memcpy。 查看我们示例的Device.c文件。 由于ifdef的原因，这仅在闪存构建配置中使用。

当然，如果您的代码不在ramfuns部分，则不会被复制。

最后，是的，我们示例的“调试”配置会耗尽RAM，但您可以查看RAM链接器命令文件以了解有关该配置的更多详细信息！

Reards，
科迪