回复：calonyu 发表于 2020-5-7 22:35现在系统跑起来了，最终发现是由于 gcc编译器的优化等级设置不正确导致的。为了防止代码被优化，我设置的优化等级是-O0，然而正是这个导致了系统一直没正常运行起来根因是移植时使用的LiteOS版本问题。最新移植的LiteOS内核，其一些关键函数已经加上了O1优化属性。比如：arch/arm/arm-m/cortex-m4/los_sr.c:179:__attribute__((optimize("O1")))arch/arm/arm-m/src/los_hwi.c:209:__attribute__((optimize("O1")))arch/arm/arm-m/src/los_hwi.c:256:__attribute__((optimize("O1")))而我最初移植的内核是没有这三处注释的。__attribute__((optimize("O1")))修饰的分别是VOID LOS_SrIdleTaskProcess()LOS_HwiCreate(HWI_HANDLE_T uwHwiNum,                                 HWI_PRIOR_T usHwiPrio,                                 HWI_MODE_T usMode,                                 HWI_PROC_FUNC pfnHandler,                                 HWI_ARG_T uwArg)    3. LOS_HwiDelete(HWI_HANDLE_T uwHwiNum)

现在系统跑起来了，最终发现是由于 gcc编译器的优化等级设置不正确导致的。为了防止代码被优化，我设置的优化等级是-O0，然而正是这个导致了系统一直没正常运行起来。我把优化等级改成-O1以上后，系统正常运行了。但是暂时不明白为什么这样，因为从以往开发经验考量，调试代码时为了防止断点打不进去都是选择不优化。

回复：Jasonchenbj 发表于 2020-5-7 20:19g_ullTickCount 改成32位系统还是没跑起来，所以不是 g_ullTickCount 的问题。这个根因是我printf打印g_ullTickCount 变量时使用的是 ld%， ld%只能打印32位类型值，打印64位类型值时由于溢出导致打印出的值一直固定不变，让我误以为g_ullTickCount 未自增。而且因为 osTickHandler 是中断函数，所以不应该加printf，这会导致系统异常以致任务无法正常调用。

回复：Jasonchenbj 发表于 2020-5-7 17:53 那是程序没执行到  g_ullTickCount++ 就退出了？还是  g_ullTickCount 这个变量没有被分配systick中断一直在执行，就是变量无法调用。自己定义了一个64位的变量，初始化为0也没用。改成32位就好了

回复：Jasonchenbj 发表于 2020-5-6 21:50 这里面，Ubuntu中是不是有不一样的地方？uint64位 全局变量 g_ullTickCount++ 无法进行修改

回复：Jasonchenbj 发表于 2020-5-6 20:50 从LOS_Start()函数代码分析，走起。查看哪些错误原因说明，一般都会有简单的错误原因说明。我用的STM32F1系列的板子上，LOS_Start()里面的错LOS_StartToRun（）已经正常执行了，最后的汇编指令 bx R6也跳转了，R6的地址是 osTaskEntry。查了下，现在是osTimesliceCheck（）执行了10次后就挂了，osTimesliceCheck（）是SysTick_Handler（）调用的。现在没思路了，我同样的时钟配置跑裸机没问题的。

回复：Jasonchenbj 发表于 2020-5-6 20:50 从LOS_Start()函数代码分析，走起。查看哪些错误原因说明，一般都会有简单的错误原因说明。我用的STM32F1系列的板子上，LOS_Start()里面的错LOS_StartToRun（）liteOS源码里提供了gcc的版本，我已经更换了。

楼主问题解决了没有，我使用同系列芯片遇到了一样的问题。