本帖最后由 any012 于 2018-12-14 15:01 编辑 在学IAP升级。 我写的app程序是用HAL库写的,设置了IROM的起始地址及大小,在程序开始后也设置了中断向量表偏移地址。 用我同事写好的boot程序(标准库写的,可以跳转到标准库写的app程序),结果发现跳转不到app程序。 我又下载了个硬石的例程里的HAL库写的boot程序,修改了app跳转的地址,结果发现,能用。 比较了下这两个程序里关于app跳转的这部分,差不多的。那么,问题出在哪里? 是不是不能混着用?我在qq群里问了下,有的朋友回复说这样用过,能行。 ---------------------------------------------------------------------------------------- 另在hal库里设置中断向量表,到底应该在哪个位置?看原子的标准库教程,是在main函数一开始就设。 而看hal库的官方例程,是在HAL_Init()和SystemClock_Config()之后,有个注释说需要加,但已经在system_stm32f1xx.c里改了。
官方的例程和硬石的例程,都是在System_Init()里修改中断向量表的,这应该是在进入main()函数前完成的。 而官方例程里留有设置中断向量表的注释,是在main()函数里,HAL_Init()和SystemClock_Config()之后。 我按以上两种方法设了,分别试了下,结果还不一样... 在System_Init()里修改中断向量表的,或一进入main()函数就修改。则标准库编写的boot程序跳转不到hal库编写的app程序。 如果在HAL_Init()和SystemClock_Config()之后设置中断向量表,好像进入了app程序,但有些不对,我是用定时器定时来反转Led灯的,结果led灯亮灭的频率不稳定。 |
又有点进展,进来汇报一下。
我又重写了个简单的app程序,发现串口,led都正常。
和boot程序对比了下,发现,boot程序里用的是tim3并使能了中断,我原来的app程序没有用到tim3。而我后来实验的app程序用的是tim3并且使能了中断。则串口和led正常;
我把实验的app程序用的tim3改为tim6并使能中断。则app程序不正常;
app程序里使能了tim3但没有使能tim3中断,使能tim6中断,app程序不正常;
app程序里使能了tim3且使能了tim3中断,但没有添加TIM3的中断处理函数,tim6使能中断,app程序不正常;
app程序使能了tim3且使能中断且又中断处理函数,tim6使能中断,app正常运行;
app程序使能了tim3没有使能中断但有中断处理函数,tim6使能中断,app正常运行。
以上说的中断处理函数指的是:void TIM3_IRQHandler(void){};
猜测,boot程序里使能了Tim3中断,所以需要中断处理函数。虽然跳到app里了,但tim3仍会中断,因为没有中断处理函数,所以可能跳转到了错误的地方引起程序跑飞。
app程序里添加了中断处理函数,这可能就是个空函数,但中断后就不会跑飞了。
以上为个人猜测。
------------------------------------------------------------------------------------------
在boot程序里跳转前,关闭tim3中断。则app里不需要上述操作可正常运行。
总结:boot程序里打开的中断,要么在跳转前关掉,要么在app程序里有对应的中断处理程序。
-----------------------------------------------------------------------------------------------------------------
上次是先禁止TIM3中断,然后禁止TIM3,再清除TIM3的中断优先级。
现在又发现,直接禁止TIM3就可以。
评分
查看全部评分
评分
查看全部评分
以为只需要设置Irom和中断向量表偏移地址。
那么,还有哪些地方主要注意?
- APP程序要改向量表的OFFSET,这个在system_stm32f4xx.c的109行,改成如下形式。
- #define VECT_TAB_OFFSET 0x40000 /* 你的偏移量 */
你可以参考一下我写的程序(验证过了)评分
查看全部评分
原boot程序的时钟是8M的,而我写的程序默认是72M的,这是出错的主要原因。
把BOOT程序改成72M后,可以跳转到APP程序。
除此,跳转到APP程序后,APP运行也不正常。发现有这些不同,原BOOT程序有看门狗程序,还有些GPIO引脚和我的APP管脚冲突。比如我的APP用到的CAN是用的复用引脚,而这些引脚在BOOT里是用作SPI的默认引脚的。
修改了以上问题后,APP貌似能正常运转了,能看到板上的LED灯正常闪烁了。但是不知为何GPIOE对应的灯不亮,现在想想,也许还是CAN不能正常接收。
但进入到APP程序后,貌似不能正常响应CAN发送过去的命令了。
在BOOT程序里CAN能正常通信,也可以通过CAN更新APP程序。但一旦进入到APP程序里,CAN就不正常了...
在BOOT程序里,跳转到APP程序之前,关闭了CAN。然后在APP程序里重新初始化CAN的,也试了跳转之前不关闭CAN,跳转后CAN都不能正常工作。
现在BOOT程序的时钟也设到72M了,波特率设置和APP程序一样。但滤波器设置不一样。管脚都是重映射的,用的是PB8,PB9。还有个管脚接到了CAN收发器的STB管脚,不过上电后一直将该脚拉到低电平。
别的想不到有什么相关的设置了。
我觉得和nvic group设置没有关系吧,设置nvic group只是设置了中断响应的优先级。而各中断的地址是固定的。
BOOT程序里原有独立看门狗,我调试时给关掉了,现在又打开了。然后在APP程序里喂狗。
一开始都是接着CAN设备,和其它设备通讯,正常。
偶然一次发现,上电时如果不接其它CAN设备,则看门狗复位了。
逐条屏蔽语句,发现是APP函数里while(1)前的打开CAN中断接收这一语句引起的,屏蔽掉就可以了。
但是,如果不用IAP工程,APP程序直接正常执行,从0X80000000执行。则不屏蔽这句,也不会引起看门狗复位。APP程序里重新打开了独立看门狗。
总结下来就是,如果上电时,使能CAN中断接收后,如果有CAN接收中断产生,则程序能正常运行下去,否则不知卡在那里引起了独立看门狗复位。
到了app程序后,一旦开启了can,则立刻产生了sce中断(也不知道为何会产生),然后就跳转到了某个位置,程序跑飞。
在app程序里也使能can_sce中断并添加中断处理函数,问题解决。或者在boot里,跳转app前,也关闭can_sce中断。
我就配合boot程序写个app程序,为何会遇到这么多问题啊...