[参考译文] RTOS/TMS320C6654：中断：子例程执行前的时间

您好、Gildas、

我已将此内容转发给 RTOS GPIO 专家。 他们的反馈应发布在此处。

BR
Tsvetolin Shulev

您好！

我对 GPIO 4执行相同的测试、并测量200ns 和400ns 之间的时间。 (与 gpio18上的1.45 μ s µs)

我知道 gpio18使用 CIC 和 cpintc 调度程序、但如何解释这种差异？

此致

在我的原始代码中、Hwi 直接调用 Cpintc_dispatch。 我已经对它进行了修改、现在 Hwi 调用代码中的函数、该函数会切换 GPIO 并调用 CpintcDispatch

Hwi_handle_gpio18 = Hwi_create (hwi_gpio18、&Application：：：分派、&params、&EB)；

无效应用程序：：派单(UARg 参数)
｛
   DEBUG_IO3_ON；
   CpIntc_dispatch (arg)；
   DEBUG_IO3_OFF；
｝

µs、我可以看到、我在外部信号后输入了这个新的字体275ns、在第一级函数后、调度程序1.22 μ s 在我的实际中断例程调用中输入了这个新的字体。

我的问题与 RTOS GPIO 无关、而是与 CpIntc 有关。 µs CpIntc_Dispatch 花费1.22 μ s 来调用我的中断例程？

下面的屏幕截图显示了 khaki 中的 gpio18、在以淡蓝色进行 Cpintc_dispatch 调用之前、在以深蓝色进行 Cpintc_dispatch 调用之后

此致

吉尔达斯

这里是我们之前在该器件上使用的一些代码。

CpIntc_mapSysIntToHostInt (0、15、8)； //将系统中断15映射到主机中断8
CpIntc_dispatchPlug (15、&event15Fxn、15、true)； //系统中断的插入函数15.
CpIntc_enableHostInt (0、8)； //启用主机中断8
EventID = CpIntc_getEventId (8)； //获取主机中断8的事件 ID

Hwi_Params_init (params)；
params.arg = 8； //确保该值是主机中断号
Params.EventID = EventID； //确保这是主机中断的事件 ID
params.enableInt = true； //启用 Hwi
Hwi_create (4、&CpIntc_dispatch、&params、NULL)； //插入中断矢量4，确保此处的函数是 CpIntc_dispatch 


使用此处提供的指导： 
processors.wiki.ti.com/.../Configuring_Interrupts_on_Keystone_Devices 

您的大多数代码与配置相匹配、因此目前不清楚是什么导致抖动。 我知道您提到系统中没有其他中断、但您能否检查中断上的屏蔽选项。 我会将屏蔽选项显式设置为

Params.maskSetting = Hwi_MaskingOption_SELF； 或 params.maskSetting = MaskingOption_ALL；

我还希望我的同事 TI RTOS 开发团队提供有关 CpIntc_dispdtach 配置的意见和建议。

此致、

Rahul

您好！

我已经尝试了自己和所有配置、并获得了与昨天相同的结果。

我的中断是唯一的循环中断、所有其他中断都是永远不会发生的错误中断或仅在初始化时使用的中断、而不是在我进行测量时使用的中断。 不过、可以肯定的是、在系统完成初始化时、我添加了一个函数来禁用 GPIO 的所有中断。 我也没有看到任何变化。

我的系统使用 GPIO 的下降沿进行触发。 我尝试更改为上升、但仍然得到相同的结果。

此致

Gildas

您好！

我保留调用 Cpintc_Dispatch 的派单函数(有关详细信息、请参阅前面的文章)、并使用跟踪获取以下屏幕截图：

我看不到__ti_SysBIOS__detail，但在我的调度函数之前，它是 HWI 管理，在它是 CpIntc_dispatch 之后。

CpIntc_Dispatch 有956"其他停转"

您是否有任何更新？

Gildas

您的同事是否有任何回答？

您好、Gildas、

CpIntc_disp()是一个非常简单的函数。 仅仅是中断调度时间增加了~1.22us 就令人惊讶。 一些评论/建议...

 -如果将单个系统中断映射到主机中断，则 CpIntc_disp()函数的效率更高。 如果多个系统中断被映射、那么它必须循环通过系统中断状态寄存器、这些寄存器可以添加到周期中。

 -我假设您已启用缓存。 为了提高性能、您可以做的另一件事是将 SYS/BIOS 内核代码和数据放在 L2SRAM 中。 CpIntc_disp()函数需要执行几次内存读取，在 L2SRAM 中获取内核数据可能会有所帮助。

最棒的

Ashish

您好！

要回答您的评论：

-我只有一个由主机中断产生的系统中断、我通过逐步执行 CpIntc_Dispatch 来确认这一点

-我已将所有 L1配置为高速缓存，没有 L2高速缓存。 SysBIOS 内核和数据位于 L2SRAM 中、但 DDR3中的堆除外

您能不能确认之前屏幕截图中的"其他失速"可以解释这一点。 如果是、如何解释这种失速？

Gildas

您好、Gildas、

我已请求硬件专家提示音、以评论 CINTC MMR 访问会停止多长时间。 同时、您是否可以尝试禁用 Hwi 自动嵌套支持？ 这将排除嵌套中断延迟中断处理的情况。

*。cfg

Hwi.dispatcherAutoNestingSupport = false； 

最棒的

Ashish

Ashish、您好！

在我的.cfg 文件中已禁用 Hwi 自动嵌套。

此致

Gildas

Ashish、

我的项目使用 gpio17、gpio18和 gpio19作为中断。 每个中断都链接到其主机中断(0、1、2)。

我在 CpIntc_mapSysIntToHostInt 的开头放置了一个断点、并显示 ti_sysbios_family_c66xx_CpIntc_Module_State_0_hostIntSysInt__A. 我发现在我第一次调用 CpIntc_mapSysIntToHostInt 时，索引0和1不包含0xFFFF。

我已经在这些地址放置了观察点、并且看到初始化值为0xFFFF、但是_call_stub ()更新了该值。 映射到我的解密后、我有0xFFFE、它是同一主机 int 上多个系统 int 的代码。

我假设 TI EDMA3驱动程序使用主机0和主机1、因为我在主机0中捕获 sys int 24、在主机1中捕获 sys int 16、19、20、21

我已经尝试将 gpio18链接到主机中断4而不是1、并获得更好的结果：

主 µs 现在介于320ns 和500ns 之间、但在此屏幕截图中、我仍然有少量时间介于520ns 和700ns 之间、随机时间大约为1.39 μ s

因此主时间现在是正确的(hwi + CpIntc 调度时间)、但随机值仍然是不可接受的。

[编辑]正如我在原始帖子中注意到的、使用编译器7.4.21而不是7.4.16删除随机时间、因此我测量的时间介于337到675ns 之间

提前感谢您的帮助

Gildas

您好！

现在、在解释例程执行之前、"固定"很长时间、我仍在尝试解释可能会随机延迟执行的抖动。

我怀疑高速缓存管理问题、但我尝试禁用 L1高速缓存、没有任何变化。

我添加了 hwi 挂钩。 如果我的 gpio18中断挂起、我的目标是签入结束挂钩。

void myEnd1 (hwi_handle hwi)
｛
   UArg arg；
   Hwi_funcPtr funcPtr；

   funcPtr = Hwi_getFunc (hwi、&arg)；
 
   if (0！=(IFR &(1 << hwi_gpio18)))
   ｛
       DEBUG_IO3_ON；
       Log_Error ("中断挂起：Hwi：0x%x、FuncPtr：0x%x (arg %d)、IFR：0x%x"、(int) hwi、(int) funcPtr、 ARG、 IFR)；
       DEBUG_IO3_OFF；
   ｝
｝

这给了我奇怪的结果：

中断挂起：Hwi：0x8e23b8、FuncPtr：0x40004000 (arg 1)、IFR：0x40

Hwi 对应于 ti_SysBIOS_family_c64p_Hwi_Object__table__V 的地址；IFR 对应于我的 gpio18中断；FuncPtr 指向未映射的地址。

我还发现主事件(GPIO4)具有与第二个事件(gpio18)相同的抖动；我之前错过了它、因为我在示波器上没有足够的时间

您对这些结果有何看法？

Gildas

您好！

在 Hwi 末挂钩中是否有方法知道当前中断？

谢谢

您好、Gildas、

下面是一个代码片段、展示了如何从 Hwi 结束挂钩中访问中断编号：

#define ti_SysBIOS_family_c64p_Hwi__internalaccess
#define ti_SysBIOS_family_c64p_Hwi_Module_State_ti_SysBIOS_family_c64p_Hwi_Module_State
#include 

func(){...

I = ti_sysbios_family_c64p_Hwi_Module__state__V.intNum;
…
…} 

请注意、上述代码访问内核的内部数据结构、该结构将来可能会改变。 因此、您只应将上述代码用于调试目的。

需要注意的另一点是、对于嵌套中断、intNum 将不正确、因为它将指向嵌套中断的编号、而不是当前运行的 ISR 的中断编号。 但在您的情况下、中断嵌套被禁用、因此无关紧要。

最棒的
Ashish

感谢您提供此代码。

我发现了生成随机长时的内容。 SYSBIOS 正在使用连接到 IRQ14的计时器。 我通过以下方式将其删除：

BIOS.clockEnabled = false；

这是一种恶性配置、因为我已经检查过我既没有使用定时器模块也没有使用时钟模块、但这个定时器在内核中。

现在、我们将介绍很长的时间和随机时间、但我仍有第二个"中断组" (在屏幕截图的红色圆圈中)要解释。 为什么很少有中断比其他中断花费大约200ns 的时间？

Gildas

有什么想法吗？

您好：

从 GEM 读取到 INTC MMR 的互连延迟估计为往返的72个 CPU 周期(地址输出和数据返回)。 假设器件以850MHz 运行、这将转换为~84ns 延迟。 同样、这仅从 GEM 主端口到 INTC IP 边界都是如此。  

Jian

您好！

我修改了用于测试的硬件和软件：
-我的源信号在 GPIO 4和 GPIO 18上发送
-在 Hwi_create 中注册了相同的子例程函数(因此对于 GPIO 18、我绕过 CpIntc 以直接访问清除 CIC sys int 的函数)
我生成了2个二进制文件，一个只在 GPIO 4上启用中断，另一个只在 GPIO 18上启用中断

对于记住、kaki 信号是我的中断源、而蓝色是我的子例程中的 ENTER (以无限持久性显示)

仅在 GPIO 4上启用中断：

仅在 GPIO 18上启用中断：

如何解释这种差异？ 这可能是因为：

- GPIO 16-31的硬件管理与 GPIO 0-15不同？

－如果事件来自 CIC，则 SYSBIOS HWI 有何差异？

－高速缓存管理？ (重新压缩更改映射、因此需要重新加载高速缓存)

只是一个精度。

之前的2个屏幕截图是使用相同的源代码获取的、其中包含已连接的中断的编号。

我比较了2个关联二进制文件的映射文件、它们是相同的。

TI 文档对于 GPIO 16-31用作中断的情况是错误的。 是否也可能存在可解释我的行为的硬件错误？

您好！

我已经添加了一个中断之间时间的测量值(基于 TCSL、tcsh)。 这使我能够检测到我的例程的呼叫何时被延迟、从而在出现问题时中断。

这是延迟中断情况下函数获取程序的屏幕截图：

(在 Hwi_INT6之前的 SYSBIOS 只是在中断之前显示的无效工件、而不是在 Hwi 上下文中)

要将之前的中断(在相同的 Profiller 跟踪中)与相同的缩放级别进行比较：

我保留注册到 hwi_create 的调度函数、只需调用 CpIntc_dispatch 即可区分 SYSBIOS 中的时间和 CpIntc 中的时间。 因此、丢失的时间在 SYSBIOS 中而不是在 CpIntc 中

失速溢出屏幕截图：

此致

您好！

我对 CCS V7分析器也是如此、它为我提供了 SYSBIOS 函数的详细信息：

当发生失速时、Trave 查看器会准确显示：

我希望通过这些信息、TI 可以告诉我发生了什么以及如何避免这种失速

吉尔达斯：

不确定您是否注意到在 c6655数据表中、GPIO4直接映射到 C66 CorePAC 主中断、而 GPIO18映射到 CIC0、那么 CIC0的输出映射到 CorePAC 事件。 如果您查看它们、数据表中将其称为 GPINT4和 GPINT18。

这仍然不能解释 GPINT18上的杂散延迟。 我不属于 SYSBIOS 例程的系列、但如果 GPI18正确映射到 CIC0、然后 CIC0映射到 CorePAC、您还是 Ashish 跟踪？

此致
Jian

此外、忘记询问、还请确认 CIC0的其他中断已屏蔽。
Jian

您好！

CIC 配置非常干净、具有唯一的中断、可优化派单时间。

我发现 Hwi_dispatchCore 需要存储在堆中的信息、而我的项目堆中的信息存储在 DDR3中。 一段时间的 DDR 访问会导致内核长时间停止。

Gildas

是的、我看到了堆配置上的另一个帖子。 让我们知道、一旦你将堆放入 L2、会发生什么情况。
尽管如此、不确定如何判断、为什么在没有杂散延迟的情况下为 GPINT4提供服务。
Jian