使用RT-Thread5.0.2版本,正点原子探索者F407开发板(V2.6),使用stm32f407-atk-explorer的bsp,MCU型号是STM32F407ZET6。
同样的代码在另外的开发板+JLink环境下正常运行,今天换了另外一块开发板(同型号不同批次),使用的STLink,发现系统无法启动,串口打印内核版本号后系统表现为卡死。
进入调试环境下后,手动暂停CPU,发现CPU运行在0x1fff0000段,是STM32的原厂DFU,是正常情况下不应该进入的地址。
从Reset_Handler开始单步跟踪,发现问题。
在rtthread_startup函数中,最后会调用rt_system_scheduler_start启动调度器;在确定接下来应该执行的任务后,调用rt_hw_context_switch_to触发PendSV。
理应在这时应该进入PendSV,并在PendSV中切换到相关Thread,脱离前期运行状态。
此时,相关用来屏蔽中断的寄存器位已经全部取消。
并且,PendSV也的确进入了Pend状态;
但是并未进入PendSV_Handler,而是继续往下执行到了“never goes here”的地方,并通过bx lr,回到了rtthread_startup函数。(在上上图,可看到LR是0x0804f6b1,即rtthread_startup的末尾)
此时的SP是0x20001d80,读取后发现附近都是空的,都是0,因此pop pc后,CPU跳转到了0x0,并进入了STM32的DFU模式。
疑问:为什么相关寄存器都正常的前提下,CPU就是不进中断呢?没有思路了,发到这里向各位大神求助。。
有没有可能硬件是残次品…来自小白的疑问
你用的时钟时外部时钟还是内部时钟,如果时外部时钟的话,切换到内部时钟试试
@没有认真
我觉得应该不会吧,芯片这种东西,特别是CPU,要么就是一整个都坏,很难说只坏某一个部分。
@miandain_7
这个确实有可能。
可惜多重复上电几次之后,这个问题莫名奇妙不出现了,再怎么按复位,程序都可以正常运行了。很奇怪,不知道为什么我老是遇到这种玄学问题。
有进展了会回来更新哈。