工具/软件:
大家好!
客户正在使用 MCU+ SDK 10.2和起点 empty_am261x-lp_r5fss0-0_freertos_ti-arm-clang 示例。
它们遇到了一个问题、即在电路板和驱动程序初始化函数之后、任务创建之前的初始化阶段使用 DebugP_LOG API 时、执行会卡住。 可以在任务函数中使用 DebugP_LOG API。
在创建任务之前是否有办法使用 DebugP_LOG API?
谢谢!
-- Gunter
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.
工具/软件:
大家好!
客户正在使用 MCU+ SDK 10.2和起点 empty_am261x-lp_r5fss0-0_freertos_ti-arm-clang 示例。
它们遇到了一个问题、即在电路板和驱动程序初始化函数之后、任务创建之前的初始化阶段使用 DebugP_LOG API 时、执行会卡住。 可以在任务函数中使用 DebugP_LOG API。
在创建任务之前是否有办法使用 DebugP_LOG API?
谢谢!
-- Gunter
您好、Vivek、
我 通过在 init 函数之后插入 DebugP_log 来重新测试了 empty_am261x-lp_r5fss0-0_freertos_ti-arm-clang 示例
int main(void) { /* init SOC specific modules */ System_init(); Board_init(); DebugP_log("After Board_init()!!\r\n"); /* This task is created at highest priority, it should create more tasks and then delete itself */ gMainTask = xTaskCreateStatic( freertos_main, /* Pointer to the function that implements the task. */ "freertos_main", /* Text name for the task. This is to facilitate debugging only. */ MAIN_TASK_SIZE, /* Stack depth in units of StackType_t typically uint32_t on 32b CPUs */ NULL, /* We are not using the task parameter. */ MAIN_TASK_PRI, /* task priority, 0 is lowest priority, configMAX_PRIORITIES-1 is highest */ gMainTaskStack, /* pointer to stack base */ &gMainTaskObj ); /* pointer to statically allocated task object memory */ configASSERT(gMainTask != NULL); ...
DebugP_LOG 正在正确打印。
After Board_init()!! All tests have passed!!
您能否在您这边进行测试?
谢谢!
-- Gunter
您好 Gunter、
是的、如果我只执行系统初始化和板初始化函数、它就可以工作:
//代码
system_init();
BOARD_INIT ();
DebugP_log (在任务创建之前的"\n[main.c]…\r\n");
但是、如果我执行以下代码、则不起作用:
//代码
system_init();
BOARD_INIT ();
drivers_open();
BOARD_DRIVERSOpen ();
DebugP_log (在任务创建之前的"\n[main.c]…\r\n");
如果没有打开驱动程序、我将无法访问外设。 您能告诉我我还需要采取哪些其他步骤吗?
此致、
Vivek
您好、Vivek、
以下代码也适用。
int main(void) { /* init SOC specific modules */ System_init(); Board_init(); DebugP_log("After Board_init()!!\r\n"); Drivers_open(); Board_driversOpen(); Board_driversClose(); Drivers_close(); DebugP_log("After Drivers_close()!!\r\n"); /* This task is created at highest priority, it should create more tasks and then delete itself */ gMainTask = xTaskCreateStatic( freertos_main, /* Pointer to the function that implements the task. */ "freertos_main", /* Text name for the task. This is to facilitate debugging only. */ MAIN_TASK_SIZE, /* Stack depth in units of StackType_t typically uint32_t on 32b CPUs */ NULL, /* We are not using the task parameter. */ MAIN_TASK_PRI, /* task priority, 0 is lowest priority, configMAX_PRIORITIES-1 is highest */ gMainTaskStack, /* pointer to stack base */ &gMainTaskObj ); /* pointer to statically allocated task object memory */ configASSERT(gMainTask != NULL); ...
[Cortex_R5_0] After Board_init()!! After Drivers_close()!!
但是、在 open 和 close 函数之间放置 DebugP_log 会导致断言。
此致、
-- Gunter
但在 open 和 close 函数之间放置 DebugP_log 会导致断言。
DebugP_LOG 具有三种输出方式:CCS 控制台、UART 或存储器转储。 您可以在 example.syscfg 中的 DebugP Log 选项中更改它。 对于实时环境、您希望使用存储器转储或 UART (如果 DebugP_LOG 调用频率不是过高)。 切勿使用 CCS 控制台、因为它侵入性非常高(禁用中断且速度缓慢)。 FreeRTOS 置为有效的原因是、中断会妨碍此处为 FREERTOS_MAIN 函数创建任务、随后会影响调度程序。
调用 Drivers_open()后、将出现 UART COM 端口日志。 在此之前、DebugP_LOG API 将在 CCS 控制台中记录(慢速、实际上不建议这样做)。
我还在想出一种不从 freeRTOS taskSwitchContext ()运行断言的方法。 我会回复更多调查结果。
此致、
Shaunak
在 FreeRTOS 和 NoRTOS 的情况下、 _DebugP_logZone ()的定义不同、信标和中断处理方式不同、
此时代码完全失败
根据当前系统的设计方式、这是函数调用堆栈
、
由于我们没有运行任何任务或 FreeRTOS 调度程序、因此系统稍后会在以下位置崩溃:
。
最终建议不是在调度器或 FreeRTOS 任务的上下文之外使用 DebugP_logs 来进行 FreeRTOS 构建。 它们将在内部使用 pxCurrentTCB 并依赖于其他操作系统功能(如内存和同步)、在正确的操作系统初始化之前使用这些功能将是不安全的。 在启动调度器之前触发任务相关操作的任何一般操作都将导致意外行为
此致、
Shaunak
您好、Vivek、
是的、这是一个合理的用例、在开始 FreeRTOS 任务之前、我看不到进行所有 HwIP 设置有任何问题。 只要不使用 RTOS 功能(例如 DebugP_log、ClockP_sleep、信标处理、RTOS 节拍相关操作等)、它不应导致断言或任何问题。
为什么当前具有平台设置任务的流程(初始化之后会产生实际应用的新任务)不可取?
此致、
Shaunak