[参考译文] J784S4XEVM：J784S4 R5F 内核：由指令&quot 触发虚假中断；Svc 0x0&quot；

您好！

我想知道更多关于您的工作场景的细节吗?

您使用的是什么 MCU_Timer 实例、以及哪个内核？ 您如何注册中断线路？

您是否在使用示例？

此致

Tarun Mukesh

这是一种很简单的情况： 我将 MCU_TIMER0配置为使用 FreeRTOS 时每10ms 中断一次。

从 MCU_TIMER0寄存器中可以发现、溢出中断已启用；CFG_TLDR 已使用重新加载值进行编程、而 AR 位则启用了 ST 位；计时器正在正常运行。 这意味着计时器已正确配置并正常运行。

我已验证 MCU_TIMER0每10ms 正确中断一次；但该 MCU_TIMER0存在一个假中断、如上所示：

未设置 MCU_TIMER0中断标志、但 VIM 检测到 MCU_TIMER0中断、并  调用 MCU_TIMER0 ISR。 此中断由"Svc 0x0"指令触发、而不是由 MCU_TIMER0中断触发

您是否有一个 SDK 示例、其中 MCU_TIMER 与 FreeRTOS 配合使用？  我可以尝试从您的示例中重现它

下面是解释的相同屏幕截图

您好！

这是一种很简单的情况： 我将 MCU_TIMER0配置为使用 FreeRTOS 时每10ms 中断一次。

从 MCU_TIMER0寄存器中可以发现、溢出中断已启用；CFG_TLDR 已使用重新加载值进行编程、而 AR 位则启用了 ST 位；计时器正在正常运行。 这意味着计时器已正确配置并正常运行。

这很好,我 明白 ,但你在使用什么驱动程序是我的问题在这里? 是否要直接使用寄存器来写入 MCU_TIMER0？

您如何在 FreeRTOS 中注册 MCU_TIMER 的中断？ 必须碰巧中断注册才会触发 MCU_TIMER0 ISR  

可能的原因可能是矢量表损坏。  或 SVC 处理程序具有相同的  MCU_TIMER0 ISR 地址。  

我可以知道导致此 SVC 异常的原因吗? 由于它在10ms 时间内发生、因此可能存在嵌套中断。

我们在 SDK 中的 packages/ti/CSL/test/dmTimerUt 中提供裸机示例、但任何 FreeRTOS 均不提供。

此致

Tarun Mukesh

是的、我直接写入 MCU_TIMER 寄存器以配置中断并设置 VIM 以处理中断。 我不使用任何 TI API 或驱动程序。

FreeRTOS 操作系统执行指令"Svc 0x0"来触发 SVC 异常；操作系统上下文切换在 SVC 异常处理程序内部处理。 异常就是出于触发目的而触发的。  

我们需要针对 FreeRTOS 进行示例、因为 SVC 由 FreeRTOS 触发。

有一个任务切换测试示例、 ti/kernel/test/freertos/task_switch

该应用应该测试任务切换、但根据我的测试、执行不会在任务之间切换。 虽然任务列表中显示 FreeRTOS_MAIN 正在运行、但我在 ping_main ()和 pong_main 处放置了断点、但我没有发现这些断点命中

可以试试这个、看看任务是否正在交替的乒乓线程之间切换吗？

您好！

是的、我已经测试了此示例。 我在 ping_main 和 pong_main 中保留了断点、这两个中断对我都是如此。

我看到任务切换以及在 UART 控制台上打印日志

 PDK 中还有许多其他运行 FreeRTOS 的示例。

此致

Tarun Mukesh

您可以共享您的二进制文件吗？ 我想尝试您的 elf 文件。

谢谢

吉姆

Jim、您好！

您是否使用我之前提供的二进制文件进行了测试？

谢谢！

Neehar

我测试了二进制文件并在所处理的线程中显示了结果、它没有在 ping_main 和 pong_main 之间切换。 请检查我在同一主题中提供的屏幕截图

这更像是固件或硬件设置/配置问题。 它可能与 R5F 或内部硬件资源使用的固件或内存映射问题相关。  VIM 检测假中断、中断由硬件引起、不是由软件引起；软件无法使 VIM 锁存 MCU_timer0中断。

我由应用程序和脚本附加、二进制文件位于 D：\cm-tda4vh_j784s4\test_1_cortex_r5f_mcu.elf；您可以运行脚本 D：\cm-tda4vh_j784s4\x_gel_to_cm\pdk_rtos_test\test_launch_freertos_r5.cm.elf 以将应用加载到电路板上。  该应用程序仅使用 RAM、无需闪存

我要求检查的原因是为了确认问题是否由我的硬件引起。

或者、闪存脚本中提供的固件版本不正确、您可以使用脚本加载  test_1_cortex_r5f_mcu.elf 并尝试。

要进行测试,请在函数 OEL_RTOS_fr_isr_common()中放置一个断点,并检查该例程是否在固定的周期内调用;在我的测试中,它大约在380us 和10ms 之间中断; 380us 中断是假中断,应该只每10ms 中断一次。 加上假中断模式是固定的、而不仅仅是短暂的

由于该问题与 MCU_TIMER 中断相关、因此我想在此处确认 MCU_TIMER 时钟。

在寄存器 CTRLMMR_WKUP_MCU_PLL_CLKSEL 中、 WK_PLL0CTRL0选择 HFOSC0_CLKOUT 作为输入源。  从下图中可以看出、 MCU_SYSCLK0为19.2MHz

从 MCU_CTRL_MMR0_CFG0下的寄存器 CFG0_MCU_TIMER0_CLKSEL 中、MCU_TIMER0 选择 MCU_SYSCLK0/4、即2.4MHz。 MCU_TIMER0是否在该低频率下运行？

我假设  MCU_SYSCLK0是 CPU 频率、它为1GHz、我的周期在此频率下计算。 正如我昨天演示的、我测试的频率似乎匹配为10ms。

我遵循了以下测试：如果我使用带有19.2MHz 的 MCU_SYSCLK0来配置中断周期、我不断得到380us 作为中断周期、与假 ISR 类似。   

内部固件中可能存在时钟映射问题？  与时钟冰箱问题类似、有些内部信道映射丢失了吗？

Jim、您好！

让我进一步研究这个错误的中断问题。

但是、我还有几个问题。

在您提供的寄存器转储中、它显示在 TIMER_IRQSTATUS_RAW 寄存器中设置了匹配的 IRQ 事件挂起位。 这与 IRQSTATUS_SET 和 IRQSTATUS_CLR 中设置的溢出标志位不一致。 您是否使用计时器匹配中断？

此外、我仍然不确定您看到的计时器周期。   您能否确认 您之前运行的 MCU_TIMERn_CLKSEL_clk_SEL[2：0]的值？ 是 HFOSC0还是 MCU_SYSCLK0？

鉴于默认情况下它为000、HFOSC0 在您同时使用的所有 TI EVM 上预计为19.2 MHz。 您在电路板上操作过这个吗？ 否则、它可能是24 MHz、25 MHz 或26 MHz。

预期周期应为(0xFFFFFFFF - TLDR + 1)/ HFOSC0 = 2500000 / 19200000  = 0.130s = 130ms。 此计算使用的是您提供的 TLDR 值。

但是、如果您使用 MCU_SYSCLK0且 MCU_TIMERn_CLKSEL_clk_SEL[2：0] 为001、则计时器时钟为 MCU_SYSCLK0/4、即250 MHz。 MCU_SYSCLK0为1000MHz 或1GHz。 这对应于您遇到的值 2500000 / 250000000 = 0.01s = 10ms。

是否多次操作 MCU_TIMERn_CLKSEL_clk_SEL[2：0]？

谢谢！

Neehar

假中断的寄存器和堆栈帧屏幕截图

寄存器和堆栈帧截屏以确保正确中断

MCU_timer0时钟不变。 它始终使用相同的时钟(MCU_SYSCLK0/4)。

只有在执行从中断返回后才会发生假中断；因为执行"Svc 0x0"是为了在中断后触发上下文切换

在前面的代码中、我在 TCLR 中启用了 CE 位。 即使启用比较模式、但不会启用匹配中断标志、因此不应触发匹配中断。 现在、我已禁用 CE 模式、仍具有相同的结果、并且在任何寄存器中都未设置匹配位

我仍然认为某些内部资源/内存映射可能没有正确完成。 是否有完整的参考手册告诉我们如何在使用 r5f 之前映射资源/内存？

以及 PLL 输出频率公式

下面是我的电路板中的 MAIN_PLL0的屏幕截图：

MAIN_SYSCLK0的结果为1GHz

我的计算正确吗？  您的 CFG_PLL0寄存器的寄存器转储是什么？

在文档 spruil1c.pdf 中、MCU_PLL 表标记为待定。  这部分现在是否已完成？

Jim、您好！

下面是解释的相同屏幕截图

 应用程序是否已更改？ IRQSTATUS_RAW 中的 MATCH 位与您之前的屏幕截图中相比似乎发生了变化。 您今天上午发送的屏幕截图中的注册信息看起来更正确。 运行任务切换示例时也为我设置了 CE 位、但是我担心匹配位的设置不是溢出。

Unknown 说：

是否有完整的参考手册告诉我们如何在使用 r5f 之前映射资源/内存？

您想要专门配置哪些资源/存储器？ 应用的运行位置一样吗？

下面是我的电路板中的 MAIN_PLL0的屏幕截图：

您仍在使用 MCU_TIMER0、是否正确？ 从下图中、您可以看到这是由 MCU_PLL_0控制的。 您需要检查 MCU_PLL_0寄存器、而不是 MAIN_PLL0。 如果您尝试查明 MCU_SYSCLK0为1GHz、我可以确认这一点。

在文档 spruil1c.pdf 中、MCU_PLL 表标记为待定。  这部分现在是否已完成？

有一个较新的文档 spruil1d.pdf、对于我们的 J721E 器件使用了这些 TRM。 您将需要下载 J784S4的 TRM、因为这是您所使用的器件。 最新的 TRM 中填充了该表。

谢谢！

Neehar

唯一的变化是在 MCU_TIMER 中断设置中、我为计时器启用了 CE (比较模式)和 AR (自动重新加载)位；现在我禁用了 CE、仅启用 AR。  在前面的屏幕截图中、即使 IRQSTATUS_RAW 也设置了比较位、但 IRQSTATUS_SET 未启用 TCAR_IT_FLAG、并且  IRQSTATUS 标志未 设置 TCAR_IT_FLAG、因此未发生比较匹配中断。

我仍在使用 MCU_TIMER0。

我确认 MCU_SYSCLK0为1GHZ

这对我来说更像是一个硬件问题。 VIM 检测到中断并且调用了 ISR 例程。 软件无法控制 VIM。 数据高速缓存已禁用。  

这可能是下面的情况吗?

1：发生 MCU_TIMER0中断

2：VIM 检测中断、调用 ISR

3：ISR 清除 IRQ 挂起位、确认中断、清除 MCU_timer0 IRQ 状态

4：偶数 ISR 确认中断、清除 IRQ 挂起位、但 VIM 存储器不及时刷新

5：SVC 0x0入侵触发 SVC、但 VIM 仍保持先前的 IRQ 状态、再次调用先前的 IRQ

可以使用任何指令来保证 VIM RAM 已刷新或强制更新？

我担心脚本中使用的固件或微代码缺少组件、或者需要启用但不启用某些门、或者主域中的某些时钟配置未正确填充到 MCU 域中。  如何验证我是否具有正确的固件或 r5f 所需的 pm 驱动程序以正常工作。  

我可能需要你们的帮助才能在你们这边进行测试。 我已上传二进制文件、请将 elf 加载到电路板(J784S4_EVM) 、并在 OEL_RTOS_fr_ISR_common  ()上放置   一个断点、或在0x41C081A8处设置断点(Lauterbach 命令：break.set R:0x41C081A8 /Program)、检查该 ISR 是否被调用两次(一次为380us、一次为10ms)；故障模式始终是一致的。  如果您无法重现我的 elf 的问题、这是我的电路板设置问题(包括 r5f 的固件)

e2e.ti.com/.../test_5F00_binary.zip

另一个有助于调试的问题是、我在 GTC CNTCR 寄存器中启用了 GTC CNTCR_HDBG 位、但当我在调试器中停止程序时 GTC 计数器仍在增加。 我假设有一个类似的映射、如 MCU_TIMER 冻结位。 您能告诉我在调试期间添加什么脚本来停止 GTC 计数吗？

Jim、您好！

感谢您确认这一点。

我担心脚本中使用的固件或微代码缺少组件、或者需要启用但不启用某些门、或者主域中的某些时钟配置未正确填充到 MCU 域中。  如何验证我是否具有正确的固件或 r5f 所需的 pm 驱动程序以正常工作。  

我可能需要你们的帮助才能在你们这边进行测试。 我已上传二进制文件、请将 elf 加载到电路板(J784S4_EVM) 、并在 OEL_RTOS_fr_ISR_common  ()上放置   一个断点、或在0x41C081A8处设置断点(Lauterbach 命令：break.set R:0x41C081A8 /Program)、检查该 ISR 是否被调用两次(一次为380us、一次为10ms)；故障模式始终是一致的。  如果您无法重现我的 elf 的问题、这是我的电路板设置问题(包括 r5f 的固件)

是的、我会用您的二进制文件进行测试、然后回复给您。 我将使用我们的 GEL 脚本在 CCS 上进行测试、还将与我们的 Lauterbach 专家进行测试(因为这将与您的设置相同)、看看我们是否可以复制您的问题。 如果我能够复制、调试将会容易得多。 我将介绍您的代码、看看固件或时钟配置中是否缺少任何组件。  

我还需要就此再次与 Lauterbach 专家核实。 他不在办公室,但我将看到他明天是否可以帮助这件事。

感谢您的耐心。

谢谢！

Neehar

如果我在指令"Svc 0x0"处放置一个断点、那么这个问题就不再存在了。 我每次执行都获得正确的周期

从我清除中断状态到执行指令"Svc 0x0"、大约为380us。 VIM 不更新由软件写入的寄存器值。 由软件写入的寄存器值被 VIM 截取的时间不超过380us。

我想我可能会弄清楚这个问题。 我的代码中存在序列问题： 我先清除 VIM 中断状态、然后清除定时器中断状态。  因此、在 VIM 内的 IRQ 状态清除是不可靠的、这是因为定时器 IRQ 状态仍然打开。 我切换了顺序、首先清除定时器 IRQ 状态、然后清除 VIM IRQ 状态、这样看起来就开始工作了。 我开始获取持续中断周期。 我将继续进行更多测试并让您知道。

谢谢、请继续处理 GTC 调试停止位问题

Jim、您好！

感谢此次更新、我很高兴听到您现在能够看到一致的中断周期。 我将等待进一步测试的结果。

Unknown 说：

请跟进 GTC 调试停止位问题

我可以请求您就此问题创建新主题吗？ 你也可以在新主题中标记我。 此问题偏离了主题主题的标题、让 E2E 问题跟踪变得更容易。

谢谢！

Neehar

但我仍然有一个问题：为什么 SVC excption 导致了假 IRQ？  IRQ 的优先级高于 SVC 异常？  

我为 GTC 创建了一个新主题。 它不能用于标记人员、下面是链接： (+) J784S4XEVM：GTC 旋转时间与配置的频率不匹配-处理器论坛-处理器- TI E2E 支持论坛

Jim、您好！

Unknown 说：

但我仍有一个问题：为什么 SVC excption 导致了假 IRQ？  IRQ 的优先级高于 SVC 异常？  [报价]

我目前正在对此进行研究、并将在本周采取后续行动。

Unknown 说：

我为 GTC 创建了一个新主题。 它不能用于标记人员、下面是链接： (+) J784S4XEVM：GTC 旋转时间与配置的频率不匹配-处理器论坛-处理器- TI E2E 支持论坛

此外、我已就此主题提供了回复、并将等待您的回复。

谢谢！

Neehar

[/quote]