[参考译文] TMS320F28069：将编译器从 TI v6.1.3升级到 TIv20.2.4.LTS 时、处理器停止

Andy、

编译器 v6.1.3可追溯到2013年3月。 两个编译器版本之间大约有8年的错误修复、优化和常规发展。 我认为我们无法轻松准确地找出可能导致行为差异的确切变化。 有时、较小的编译器错误甚至可以掩盖同样较小的工程配置问题。

如果需要精确定位、我建议对 一些存档的 CGT 版本进行实验 、以查看您是否可以识别产生问题的第一个 CGT 版本。 然后、可以更轻松地参考版本说明和缺陷列表以了解具体差异。

如果目标是使用更新的 LTS CGT 版本获得工程的工作版本、我们可以尝试帮助调试问题、就像调试正在开发的程序一样。

Tommy

Tommy、您好！

感谢您的回复。 我们实际上不想指出它为什么不能在旧编译器上工作。 我们可能需要帮助、以找到 使用 最新 LTS CGT 版本制作工程工作版本的解决方案。 您知道有人有类似的问题吗？ 除了降低中断速率之外、您对此问题有何建议？

Andy

Andy、

我不知道有任何关于类似问题的报告。 我将尝试帮助您使项目再次正常工作。 您能否提供更多背景信息？

您是使用基于 C28x 硬件的本机中断处理程序、还是拥有基于软件的自定义中断处理程序？

是否有意启用 TINT0以便预计分支到 TINT0_ISR()？ ISR 包含一个 for loop 陷阱、因此我可以了解 CPU 分支到它后为什么会卡在那里。 如果另一个中断无意中指向 TINT0_ISR()，它可能有助于在 ISR 中检查 PIECTRL 寄存器，以确认中断源和矢量表的内容。

就中断起搏而言、如果硬件可以跟上 v6.x 中的中断、则应该有一种方法可以跟上 v20.x 的发展 在进入和退出 ISR 时、切换 GPIO 可能有助于配置中断服务活动。 如果 CGT 版本之间的处理延迟或执行时间存在显著差异、则可能会指出 pragma 预期或优化级别存在差异。

Tommy

Tommy、

有两个 ADC 中断 ADCINT1和 ADCINT2用于对交流电压进行采样、每个中断都有一个时基周期(TBPRD) 10us。 ADCINT2的时基相位为周期的一半、即5us。 因此、这两个 INT 是惊人的5us。

有 HRCAP2_INT、并由脉冲的上升沿和下降沿触发以测量脉冲宽度。 如果有一个脉冲周期为30us 并且宽度为10us 进入这个 HRCAP、CPU 就会卡住(编译器 v6.1.3没有问题)。 该中断将执行一些宽度计算、因此需要一些执行时间。  

它还包括由 CTR_EQ_PRD 和 CTR_EQ_CMP 触发的 ECAP2_INT。 ECap2Regs.CAPx 基本上是上面提到的脉冲宽度和周期。 我相信这个中断例程很快就会退出、不会产生太大的影响。   

感谢有关检查 PIECTRL 寄存器和通过切换 GPIO 配置中断服务活动的建议。 我稍后会获取这些信息。

谢谢、

Andy

尊敬的 Andy：Tommy 是我们的办公室、但应能在下周周二回复。

Andy、

在最坏的情况下、中断触发器对齐可能需要4个 ISR (ADCINT1、ADCINT2、HRCAP2_INT 和 ECAP2_INT)才能在10us 内完成执行。 在90MHz 时、这大约是900个 CPU 周期。

如果为上下文切换和裕度保留大约15%的开销(任意)、则大约为750个周期。 使用 CPU 计时器测量 ISR 执行周期应该相当简单、以查看您是否在 Ballpark 中。

我是否正确地假设目标是在尽可能少的修改下备份和运行项目？ 如果是这样，我将尝试将我的建议限制在这一工作范围内。

Tommy

Tommy、您好！

ADCINT1和 ADCINT2每5us 触发一次、因为它们间隔为5us。  

我想说的目标是使用 最新编译 器获得工程的工作版本、并且尽可能少地进行修改。

谢谢、

Andy

Tommy、您好！

PIECTRL 寄存器显示了停留在 ISR 中的0x0D27的值。   

我通过切换 GPIO 测量了 ADCINTx 的执行时间。  在使用 v6.1.3和 TIv20.2.4.LTS 编译的项目上测量。 我注意到两者之间没有太多时间不同。 对于两个项目、时间在2.xus 至4.xus 之间变化。 偶尔见过6.xus。

谢谢、

Andy

0x0D27映射到非法操作中断、该中断通常由无效指令引起：

您可以查看堆栈存储器来确定 ISR 上下文保存的返回地址。 这应该指向本地存储器段、该段包含导致非法陷阱的指令。 我有点模糊的是它将指向指令的确切地址还是被几个字抵消；它很明显、就像内存中需要指令的所有0或 FS 一样。

2-4 us 似乎是每5us 执行一次 ISR 的相当大的变化量。 是否了解变体的来源？

Andy、

检查非法指令的另一个地方是 RPC 地址。

Tommy

Tommy、您好！

当 CPU 暂停时、我检查了 RPC 地址。 它指向仅在加电时执行的初始化函数的某个位置。

我还尝试将堆栈大小从1.2k 增大到4k、但这没有帮助。  

Andy、

您能否检查 CPU 暂停时 SP 指针是否仍在有效的存储器范围内？ 我刚刚处理了另一个问题、即嵌套中断失控并导致 SP 溢出、最终导致 CPU 获取非法指令。

此问题能否在 controlCARD 或 LaunchPad 上重现？ 如果是、我们可能能够提供更多的实践帮助。

Tommy

堆栈被指定为以下位置：

RAMM0    ：origin = 0x000050、length = 0x000500

 堆栈        ：>RAMM0，   PAGE = 1

当 CPU 暂停时、SP 指向0x6E。 我认为它仍然指向有效内存。

我捕获到另一个 CPU 停止、PC = 0x00000000、SP = 0x808。 这对我来说似乎并不正常。

我尝试设置更高的优化级别(opt_level=3和 opt_for_speed=5)、以便使用编译器 TI v20.2.4.LTS 构建独立项目。 在没有 CPU 暂停问题的情况下、它工作正常。 为了使用编译器 v6.1.3编译工程、优化级别为 opt_level=off 和 opt_for_speed=2、并且在 CPU 停止的情况下工作。  

Andy、

我同意0x808处的 SP 看起来不正常。 我认为最常见的情况是溢出。 您能否澄清您是否正在使用嵌套中断(如此)？

优化级别是一个有趣的实验。 我通常认为 opt_level=off 是更可靠的设置。 如果问题与 ISR 的执行速度太慢、我认为较高的优化级别会有所帮助。 您是否看到优化的 ISR 执行时间更快或更一致？

CCS 允许 在文件级别进行不同的优化级别 、因此可以对 单个源文件进行 opt_level=off 实验、以查看您是否能够确定哪个文件受益于优化。 如果可以、则可以拆分各个函数、直到找到有问题的函数。

Tommy

Tommy、您好！

是的、使用嵌套中断。  

对于 opt_level=3和 opt_for_speed=5、尽管发生了 CPU 暂停、但发现了应用程序中断的一些功能。

已尝试创建一个单独的文件、并将  HRCAP2_INT 和 ADCINTx 移动到此文件中、并且仅在此 文件上设置 OPT_LEVEL=3和 OPT_for_speed=5。 然而、CPU 暂停仍然会发生。

Andy

Andy、

我认为使用 opt_level=off 进行调试是有道理的。

您可以在执行期间尝试记录 ISR 嵌套级别吗？

例如、声明 volatile UINT16的全局数组、其中每个数组元素充当系统中每个 ISR 的计数器。 在 ISR 中、在 EINT 被执行前递增计数器变量(抢占被启用)、在 DINT 被执行后递减计数器(挤占被禁用)。 在没有活动中断的情况下、计数器都应该为0。

当您最终处于 CPU 暂停状态时、您可以检查计数器值以查看嵌套是否已消失。

Tommy

Tommy、您好！

我创建了数组调用 iArray 来将计数器保存在 ADC 中断中、允许在那里嵌套中断。  伪代码如下所示。

CPU 停止后、数组中的所有值都为零。

_interrupt void SubSourceADCFastISR (void)
｛

//此处为局部变量初始化

  oldIER = IER；
  IER = M_INT12 | M_INT5；
  PieCtrlRegs.PIEACX.ALL = PIEACK_Group1；
  asm (" NOP")；  
  iArray[j]=iArray[j]++；
  EINT；

  IER = oldIER；

// 此处的中断过程

  Dint；

  iArray[j]= iArray[j]-;
  if (j<1000)
  ｛
   J++；
  ｝
  其他
  ｛
   J=0；
  ｝

｝

Andy、

我更注重以下几个方面：

#define IARR_ADC1_NDX  0
#define IARR_ADC2_NDX  1.
#define IARR_HRCAP_NDX 2.
#define IARR_NUM_ISR   3.

易失性 uint16 iArray[IARR_NUM_ISR]；

_interrupt void ADC1_ISR (void)
｛
   //代码

   iArray[IARR_ADC1_NDX]++；
   EINT；

   //代码

   Dint；
   iArray[IARR_ADC1_NDX]--；

   //代码
｝

_interrupt void ADC2_ISR (void)
｛
   //代码

   iArray[IARR_ADC2_NDX]++；
   EINT；

   //代码

   Dint；
   iArray[IARR_ADC2_NDX]--；

   //代码
｝

Tommy

Tommy、您好！

我创建了用于 记录 ISR 嵌套级别的数组、如下所示。 这两个中断是唯一允许嵌套中断的中断。

SubSourceADCFastISR 的周期为5us、Timer0_ISR 的周期为 1ms。

我在调试模式下运行、并在程序停止后检查数组的值。

iArray[0]= 1

iArray[1]= 32

#define IARR_ADC1_NDX  0
#define IARR_ADC2_NDX  1.
#define IARR_NUM_ISR  2.

易失性 uint16 iArray[IARR_NUM_ISR]；

_interrupt void SubSourceADCFastISR (void)
｛

  //代码

  iArray[IARR_ADC1_NDX]++；
  EINT；

  //代码

  Dint；
  iArray[IARR_ADC1_NDX]--；

｝

//1ms 计时器中断

_interrupt void Timer0_ISR (void)
｛

  //代码

  iArray[IARR_ADC2_NDX]++；
  EINT；

  //代码

  Dint；
  iArray[IARR_ADC2_NDX]--；

｝

Tommy、您好！

尝试在 EINT 到 DINT 之间的 Timer0_ISR 中停止并恢复 Timer0。 它可以帮助解决此问题、并且没有 CPU 暂停。 但是、这将导致我们的应用中出现另一个问题。 我们有多个 F28069要运行、并且  所有 F28069中的 Timer0必须同步。 因此、停止和恢复 Timer0将中断同步。

此外、我们必须将 Timer0速率保持在1ms。

Andy  

Andy、

本实验很好地证明了 Timer0_ISR 执行时间(以及后续嵌套)是导致系统崩溃的主要原因。 您是否会碰巧知道 v6.1.3编译器的 Timer0_ISR 嵌套级别？

我想您有两种策略可供选择以解决该问题：

1. 尝试找出编译器之间代码生成的区别：
   • 是一些变量/函数放置在闪存中而不是 RAM 中(.map 文件可能有用)
   • 编译器之间是否存在相关性差异(例如：FPU 库位置或版本)
   • 生成的 ISR 代码是否有显著差异(尤其是 Timer0_ISR)？
2. 尝试进一步优化系统/代码、以便 Timer0_ISR 能够在1ms 内完成
   • 针对速度对特定函数进行文件级编译器优化
   • 手动优化速度代码： https://software-dl.ti.com/C2000/docs/optimization_guide/index.html
   • 使用 DMA 创建批处理 ADC 转换的缓冲区、以减少 CPU 参与的频率
   • 使用 CLA 来处理与 CPU 并行的任务

Tommy

Tommy、您好！

使用 v6.2.11和 v6.4.0编译了代码(5us ADCINT 速率)。

使用 v6.2.11编译(2015年2月05日发布)、运行时不会出现问题。

使用 v6.4.0编译(2014年11月19日发布)、CPU 暂停。

这两个版本之间是否存在任何重大差异以解决此问题？

不确定为什么 v6.4.0 (2014年11月19日)早于 v6.2.11 (2015年2月05日)发布。

谢谢、

Andy

Andy、

您能否仔细检查编译器版本号？ 我看不到它们的确切匹配...

您是指 v6.2.10还是 v6.4.11？

Tommy

Tommy、您好！

编译器版本为 v6.2.11和 v6.4.0。 我从下载了它  

http://software-dl.ti.com/codegen/non-esd/downloads/download_archive.htm

它们位于"6.2.x 版本"的第一个和"6.4.x 版本"的最后一个下。

谢谢、

Andy  

Andy、

我很高兴你能找到这个网站。 我不知道这是否对公众可见。

6.4.x 比6.2.x 引入了许多性能增强功能、因此6.4.x 初始版本与6.2.x bugfix 版本之间可能存在重叠。

您是否能够在没有中断嵌套的情况下分析 ISR 的执行时间、以查看这两个编译器之间是否存在明显差异？

如果您能够将感兴趣的领域缩小到可以作为 编译器测试案例提交到 CCS 论坛的单个函数(或代码片段)、则编译器团队可以更轻松地提供帮助。

Tommy

Tommy、您好！

如果没有中断嵌套、应用程序将无法工作。  

对于代码片段、我插入了三个 INT 例程。 请告诉我它是否足够好。

谢谢、

Andy

// HRCAP2 INT, interrupted by a pulse which has 10us on time and 20us off time
__interrupt void TimeMonitorPulse(void)
{

	if(HRCap2Regs.HCIFR.bit.RISE)
	{
		// Code
	}
	else if(HRCap2Regs.HCIFR.bit.FALL)
	{
		// Code
	}
	else if(HRCap2Regs.HCIFR.bit.COUNTEROVF)
	{
		// Code
	}

	// Code
	
	EALLOW;
	HRCap2Regs.HCICLR.all = 0x1F;
	PieCtrlRegs.PIEACK.all = PIEACK_GROUP4;
	EDIS;

}

// 5us ADC INT
__interrupt void SubSourceADCFastISR(void)
{
	DINT;

	unsigned int oldIER;

	oldIER = IER;
	// allow XINT3 and HRCAP4 to interrupt
	IER = M_INT12 | M_INT5;
	PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;
	asm(" NOP"); //Wait for PIEACK to exit the pipeline
	EINT;

	if(1 == AdcRegs.ADCINTFLG.bit.ADCINT1)
	{
		// grab reading from AdcResult.ADCRESULTx
		AdcRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;		//Clear ADCINT1 flag reinitialize for next SOC
	}
	if(1 == AdcRegs.ADCINTFLG.bit.ADCINT2)
	{
		// grab reading from AdcResult.ADCRESULTx
		AdcRegs.ADCINTFLGCLR.bit.ADCINT2 = 1;		//Clear ADCINT2 flag reinitialize for next SOC
	}

	// Code
	
	IER = oldIER;

	DINT;
}


// 1ms Timer0 INT
__interrupt void SubSourceSafetyAndChannelStateSlowISR()
{
	// manage interrupts to allow select ones to interrupt SlowISR
	oldIER = IER;
	// always allow INT1 (ADC) and INT11 (CLA) and HRCAP4 to interrupt and timer 1
	IER = M_INT1 | M_INT5 | M_INT13;
	// only allow INT4 (ECAP2) to interrupt if it's already enabled
	if(oldIER & M_INT4)
		IER |= M_INT4;
	PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;
	asm(" NOP"); //Wait for PIEACK to exit the pipeline
	EINT;


	// Code

	IER = oldIER;

    DINT;
}

Tommy、

我附加了两个屏幕截图、即在1ms 计时器0 INT 中切换 GPIO。 高电平时间表示中断的执行时间。 第一个是在运行使用 v6.2.11编译的代码时捕获的。 在 CPU 暂停之前运行使用 v6.4.0编译的代码时捕获第二个。 在第二个屏幕快照中、我看到一些高电平时间长于1ms。  

谢谢、

Andy  

Andy、

编译器团队只关心代码生成方面的特定差异、因此、整体应用程序是否正常工作与它们无关。

我看到编译器之间 TIMER0 ISR 执行时间相差约20us。 这应该足够好、以便开始。

Tommy

Tommy、您好！

您是否仍然希望我提供代码片段？ 请指导我提供代码片段、其中显示了代码生成方面的具体差异。

谢谢、

Andy

Andy、

此时、您将需要直接在 CCS E2E 论坛上与编译器团队互动。

他们很可能会要求您使用 这些指令提交编译器测试用例。

Tommy

电源 我在8月16日之前不在办公室。

Tommy、

我应该在 https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum?上开始一个新问题

链接 http://software-dl.ti.com/ccs/esd/documents/sdto_cgt_How-to-Submit-a-Compiler-Test-Case.html 也不起作用。 您可以再次向我发送指令吗？

谢谢

Andy

Andy、

是的、请在 CCS 论坛中开始一个新问题、并告知他们您看到编译器版本之间的执行时间不同。 它们将能够帮助进行调试。

奇怪的是、您无法看到指令。 我要附上 PDF 捕获。

Tommy