你(们)好
我们在 FreeRTOS (Cortex R、内核0)中遇到无法解释的抖动。
测量方法：
差异用于评估系统抖动。
简单示例、一项任务、2-5uS 内的抖动。 很好。
当我在软件中启用更多器件、再加上一些我无法解释的因素时、延迟似乎会增加。
不访问硬件。 低优先级任务定期唤醒、但不执行任何操作。
例如、 初始化网络代码和不初始化网络代码时的延迟存在很大差异。
如果没有初始化网络、在初始化网络的情况下、延迟/抖动为+/- 20us、但电缆断开(DMA 无中断)+/- 80us。
所有代码均从 DDR 运行、DDR 均被缓存。
高速缓存缺失可以解释这种行为吗？
有什么想法吗？
ISR 本身禁忌30-50 usec.
这意味着
在 main.c 文件中添加了以下回调函数：
void timerTickIsr(void *args)
{
//2 From timer ISR give a semaphore to high priority task
static uint32_t count =0;
BaseType_t doTaskSwitch = 0;
uint32_t current_count =0;
static uint32_t end_count =0;
static uint32_t StartCounter = 0;
uint32_t IsrCurrTime_us = 0;
uint32_t min_pos[LOOP_COUNT] = {0};
static uint32_t max_pos[LOOP_COUNT] = {0};
static uint32_t loop = 0;
static uint32_t min_jitter[LOOP_COUNT] = {0};
static uint32_t max_jitter[LOOP_COUNT]= {0};
//SemaphoreP_post(&gBinarySem);
current_count = CycleCounterP_getCount32();
xSemaphoreGiveFromISR( gSem, &doTaskSwitch); /* wake up task */
portYIELD_FROM_ISR( doTaskSwitch );
IsrCurrTime_us =( (current_count - end_count) / 800U );
if( IsrCurrTime_us < min_jitter[loop])
{
min_jitter[loop] = IsrCurrTime_us;
min_pos[loop] = count;
//MinJitter[count] = Jitter_CurrTime_us[count];
}
if( IsrCurrTime_us > max_jitter[loop])
{
max_jitter[loop] = IsrCurrTime_us;
max_pos[loop] = count;
//MaxJitter[count] = Jitter_CurrTime_us[count];
}
count++;
if(count >= SAMPLE_COUNT)
{
count = 0;
}
if(loop > LOOP_COUNT)
{
loop = 0;
count = 0;
}
end_count = current_count;
}
我的观察结果是、我们在125us 的间隔内收到了该回叫。
但是,我的情况是大约125us + 30us ?
此致
Ashwani
Rasty、您好！
我们一直在进行不同的实现和测试以减少抖动。 下面汇总了我们在不同的@10Mbps 至20Mbps 以太网速度(在释放模式下的 O3优化应用中)下测试的内容。
测试情况1 :在当前的 MCU+SDK 中,不应在轮询方法的 cpsw_enent_example 中调用 TX 和 RX ISR ,但这些函数仍在轮询实现中被调用。 一旦这个问题被解决、TX 和 RX ISR 函数就不再被调用、从而减少了中断和运行环境切换的数量。
下面是补丁。 因此、Tx 和 Rx 处理问题已经得到修复。
测试情况2： 我们已经确定了禁用全局中断的位置。 请查看以下详细信息：
在第一组重点功能中、我们实现了互斥量、然后以不同的速度对其进行验证。 我们注意到我们仍然有~10个使用的抖动。
我们禁用全局中断的 Total API：
我们 禁用 全局中断的第一组 API：
测试情况3： 我们也为下面的第二组函数实现了互斥量、但我们会看到因此而导致的以太网功能中断。 我们目前正在努力解决此问题、这应该会改善抖动。
我们禁用全局中断的第二组 API：
实施问题：您提到、使用补丁可以获得5-7us 的抖动。
1.您测试的以太网数据包速率是多少？
2.您测试过此补丁多少小时？ 我们可以在夜间测试中看到一些异常值。
3.释放模式还是调试模式?
修补程序详细信息：
此致、
Anil。
Rasty、您好！
我理解您的担忧。
实际上、 如果您在释放模式下进行相同的测试、则与调试模式相比、您获得的抖动值可能更少、因为发布模式是优化的代码。
目前、我们已对 TI Clang 编译器在发布模式下进行了测试。
该补丁中有两个修复程序。 一种方法是使用信标替换全局中断。
另一个在 轮询模式下运行以太网。 在这种情况下、您的 TX ISR 和 RX ISR 将不会命中。
在驱动程序中,我们已经禁用了 RX 和 TX ISR ,但不幸的是, TX ISR 正在进入当前的示例.
我们添加了以下补丁来禁用 TX ISR、这也需要在 MCU+SDK 中修复、也需要在 未来版本中进行修复。
进行编译、我们就会遇到非常奇怪的副作用因为在发行版中、如果使用 gcc
是否可以分享您在发布模式中遇到的问题、因为这些问题也应该在 GCC 编译器中解决？
此致、
Anil。
Rasty、您好！
我们没有卸载 ISR 工作、相反、我们已 更改为 在轮询模式下运行以太网示例。
要在轮询模式下运行以太网、我们已在以下提交中添加了补丁。
有关轮询模式的更多详细信息,请查看下面的提交和注释。
[报价 userid="359686" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1326858/am243x-freertos-jitter/5183312 #5183312"]我看到只有一(1)个路径用信标替换中断锁定、是否有另一个补丁可以减轻 ISR 的工作负担？
[报价]
目前、我们已对 TI Clang 编译器在发布模式下进行了测试。
该补丁中有两个修复程序。 一种方法是使用信标替换全局中断。
另一个在 轮询模式下运行以太网。 在这种情况下、您的 TX ISR 和 RX ISR 将不会命中。
在驱动程序中,我们已经禁用了 RX 和 TX ISR ,但不幸的是, TX ISR 正在进入当前的示例.
我们添加了以下补丁来禁用 TX ISR、这也需要在 MCU+SDK 中修复、也需要在 未来版本中进行修复。
[报价]如果使用版本编译、我们会看到奇怪/无法解释的崩溃。 最可能的情况是、这与外设存储器的无序访问(由于动态优化)有关。 [报价]是的,这也需要在我们的一方检查,我们目前给予优先减少抖动一旦我们得到预期的抖动值,然后我们最终可以在 GCC 编译器中工作。
此致、
Anil。
Rasty、您好！
[报价 userid="359686" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1326858/am243x-freertos-jitter/5184173 #5184173"]1. RX 路径是否也有类似的处理方法 (如 EnetDma_disableTxEvent(pInterface->HTX[txChIdIndex]->HCH)
[报价]在 MCU+SDK 中、该 RX 路径 已禁用。 它是从变量下的变量控制,再次,我们不需要单独为 RX
outArgs->disableEvent = true . 所以、我们没有禁用 Rx 路径。
请查看下面的补丁。
2.您所使用的 SDK 版本是什么?
[报价]我们还使用 MCU+SDK 09.00版本。
[报价 userid="359686" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1326858/am243x-freertos-jitter/5184173 #5184173"]3.真正的投票在哪里? 我是否需要添加轮询代码/任务？
[报价]不需要、它已添加到示例中。
以下任务用于轮询模式、您不需要创建新任务。
LwipifEnetApp_rxPacketTask
LwipifEnetApp_txPacketTask
Ashwani 提到,类似于 Rasty Patch 意味着,我们已经添加了下面的更改。
1.卸载 TX 和 RX ISR 在任务中根据标志工作。
2.为4个 UDMA API 实现信号量锁定
udma_queraw、udma_dequeraw、udma_eventAllocResource 和 udma_eventFreeResource
此致、
Anil
Rasty、您好！
下面是另一个更新。
我们在测试中看到了两个问题。
问题1. ： 在轮询模式下、抖动值最大为10usec、数据速率为10Mbps。
问题2. : 在轮询模式下、长期数据速率为10Mbps 时、抖动值最大为180usec。 (运行> 50 分钟)
对于上述问题、 我们对每个任务以及 ISR 进入和退出时间进行了分析。
我们发现、从任务到任务 切换 以及从 DDR 访问内存都造成了抖动。
在我们的分析中、 ISR 结束到 T3 (抖动)任务开始时间之间的延迟从5usec 到10usec 不等。
为降低延迟、我们已将 FreeRTOS 库添加到 MSRAM 中、并且在我们看到抖动差不多是平均值4.2use 后、将其添加到了一起
6usec 为峰值,在50000 * 50个样本中,每个样本在125usec 数据(10Mbps)和输出数据。
我已按如下所示更新了链接器命令文件。
完成下面的软件更改后、我们修复了这个问题 问题1.
对于下面的更改、几乎占用~40KB 的 MSRAM 存储器。
回答问题2 、我们已经看到任务3抖动任务缺失、实际上该任务应该达到大约125usec、但它没有达到125usec、并且我们没有找到该问题的根本原因、我们正在努力解决该问题。
请查看 Excel 工作表文档以供参考。
SECTIONS
{
-l "C:/ti/mcu_plus_sdk_am64x_09_00_00_35/source/kernel/freertos/lib/freertos.am64x.r5f.ti-arm-clang.release.lib" (.text)
-l "C:/ti/mcu_plus_sdk_am64x_09_00_00_35/source/kernel/freertos/lib/freertos.am64x.r5f.ti-arm-clang.release.lib" (.data)
-l "C:/ti/mcu_plus_sdk_am64x_09_00_00_35/source/kernel/freertos/lib/freertos.am64x.r5f.ti-arm-clang.release.lib" (.bss)
-l "C:/ti/mcu_plus_sdk_am64x_09_00_00_35/source/kernel/freertos/lib/freertos.am64x.r5f.ti-arm-clang.release.lib" (.rodata)
} > MSRAM {} palign(8)
e2e.ti.com/.../TestResults_5F00_withLoad.xlsx
此致、
Anil。