This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CCS/TMS320C6457:DSPBIOS 5.33.06调度程序问题

Guru**** 1454530 points
Other Parts Discussed in Thread: TMS320C6457
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/948716/ccs-tms320c6457-dspbios-5-33-06-scheduler-problem

器件型号:TMS320C6457

工具/软件:Code Composer Studio

所有开发人员都好、

我的应用程序在具有 DSPBIOS 5.33.06和编译器 v.6.1-20的 TMS320C6457上运行时出现问题。 任务调度程序、swi 和 hwi 有时似乎做得不对。

可能我缺少一些东西,做了一些错误的事情,即使我检查了有关 HWI_disable() HWI_RESTORE ()调用 SWI_POST 的限制,等等...

我在某些情况 下看到(使用日志消息进行跟踪)、如果我从 HWI 服务例程中发布 SWI、那么它不是在 HWI 完成后运行 SWI、而是在完成之前启动。

为了解释我观察到的内容:

Hwi 开始-> SWI_POST -> SWI 启动--> SWI 结束--> HWI 恢复--> HWI 结束

而不是我所期望的:

Hwi 开始-> SWI_POST -> HWI 结束-> SWI 启动--> SWI 结束

在执行重复性测试时、应用程序运行后会出现这种行为。 当它开始失败时、我可以在许多 HWI-SWI POST 情况下观察到它...

我知道、这些信息不是很好、没有什么答案... 无论如何、也许有人遇到过类似的问题... 我可以说、我已经检查了我的代码、以查看我是否进行了一些非法操作

调用(例如、禁用中断时的任何 SWI_POST 或不后跟 HWI_RESTORE (oldcsr)的任何 HWI_DISABLE)、但我找不到任何错误。

可以帮帮我吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Domenico、

    与 SWI 相比、HWI 具有更高的优先级、因此您的预期行为是正确的。 是否确定 HWI 正在恢复、并且它不会由于 CAM 输入的新中断而触发。 您在 HWI 中使用的序列是什么?您正在使用全局禁用执行 POST 然后重新启用中断来解除中断?

    理想情况下、没有应该挤占 HWI 的线程。 您是在 UIA 还是其他可视化工具中检查调度程序行为、还是如何确定后跟调度程序的序列。

    此致、

    Rahul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Rahul、您好、感谢您的回答!

    我会尝试回答您的问题。 是的、我非常确定在禁用 HWI 时不执行开机自检。 自从 DSPBIOS 用户指南警告该非法程序以来、这是我检查的第一件事。 关于我用于跟踪事件序列的方法、我调用了一个宏、该宏在循环无符号整型缓冲器中写入不同的代码。 这是为了标记程序已运行的不同的有效点。 写入例程是一个非常简单的代码:

    #define WriteDebugStatus (data) oldcsr = HWI_disable ();\
    writedebugstatus (data);\
    HWI_restore (oldcsr);
    
    void writedebugstatus (unsigned int data)
    {
    extern int DebugPnt;
    extern unsigned int DebugVect[_MAX_DEBUG_LENG];
    
    gDebugPNG=%
    
    )= Debug_Debug =%;Debug_Debug =_Debug = 1;Debug_Debug =_Debug + Debug_Debug 

    其中 oldcsr 是在调用 HWI 中定义的本地无符号 int 变量。

    因此、调用代码将执行以下操作:

    unsigned int oldcsr;
    WriteDebugStatus( some int value ); 

    例如、在测试运行一段时间后、请参阅 DebugVect[]中的以下结果:

    [2569]0x00000011       
    [2570]   0x40000001   
    [2571]   0x40000000   
    [2572]   0x00000010   
    [2573]0x00000011       
    [2574]   0x40000001   
    [2575]   0x40000000    
    [2576]0x00000010      

    代码0x00000011是 HWI 的输入。

    代码0x40000001是从 HWI 发出的 SWI 中的输入

    代码0x40000000是从 HWI 发出的 SWI 的退出

    代码0x00000010是从 HWI 退出(与在其开始处标记为0x00000011的代码相同)

    因此、这是一种非常奇怪的行为。 我认为调度程序因我所做的事情而损坏... 但我不能意识到我所犯的错误

    最诚挚的问候 Rahul!

     


     

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    没有人不得不面对这个问题?  我是否可能是唯一遇到此调度程序奇怪行为的人?

    我补充说、我已在固件中检查是否存在任何非法调用(即禁用中断时为 SWI_POST、或在中断时为 SWI_DISABLE、SWI_ENABLE)

    禁用)。 我没有发现任何非法呼叫。 somone 能否建议什么可以使调度程序产生这些错误?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Domenico、

    DSP BIOS 内核是一个已使用了10年以上的内核、它至少比我们目前积极支持的 TI RTOS 内核落后3代、因此有关 DSP BIOS 的专业知识有点少。

    我建议查看集成在支持 DSP BIOS 的较旧 CCS 版本中的 RTA 和 ROV 工具、以便对调度程序进行一些可视化、从而了解这种行为并找出其根本原因。 我还会检查是否有任何导致代码跳转或导致此行为的堆栈溢出或状况。

    此致、

    Rahul

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    最后我想我发现了问题!

    我有一个函数、我从该函数中调用了 SWI_raisepri 和 SWI_restorepri DSPBIOS API。

    通常、此函数是从 SWI 上下文调用的、但我发现有一个任务偶尔可以调用相同的函数。 在 DSPBIOS API 可调用性表中、清晰地标记了这2个函数不能从任务上下文调用。

    因此、我已经解决了在任务内部发布新 SWI 的问题、该 SWI 调用了该函数。

    TI 团队、您能告诉我、如果您考虑检查 SWI_raisepri 和 SWI_restorepri 的源代码、如果从任务中调用这些 API、则预期会出现这种行为吗?

    我的意思是、我可以放心、这是我问题的真正根源、我没有遇到一些副作用...

    最棒的餐厅!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我仍在等待 TI 专家关于 SWI_raisepri 和 SWI_restorepri 的反馈...