Cortex M3 从应用程序跳回引导加载程序并返回应用程序
Cortex M3 jump from application back to bootloader and back to application
我有一个引导加载程序和一个固件,从引导加载程序到固件的初始跳转就像一个魅力,但是当我有从应用程序跳回的场景时,做一些东西然后跳回我的应用程序。在那里我遇到了一些奇怪的问题,最终导致了一个严重的错误。如果我通过 IAR 的 __enable_interrupts() 激活中断,就会出现这个问题。
清除和重置所有正确的寄存器是什么?
我已将 MSP 和 PC 设置为 application/bootloader.
的开头
我不使用 NVIC_Systemreset 是必要的。
希望有人能帮我解决这个问题吗?
有一个关于引导程序的ST application note。
In addition to patterns described above, user can execute bootloader
by performing a jump to system memory from user code. Before jumping
to bootloader user must:
- Disable all peripheral clocks
- Disable used PLL
- Disable interrupts
- Clear pending interrupts
这就是当您激活中断时引导加载程序崩溃的原因。
编辑
为了解决@Clifford 的想法,STM32 系统引导加载程序退出并使用 go 命令跳转到主定义地址。这个地址应该是 reset vector 而不是 main,这样堆、栈和 FW 才能正确初始化。之后,您可以 system_reset 进入已知的硬件状态,或者您必须完全配置您在应用程序中使用的外围设备,因为它们在引导加载程序使用它们后未设置为重置状态。
Note: If you choose to execute the Go command, the peripheral
registers used by the bootloader are not initialized to their default
reset values before jumping to the user application. They should be
reconfigured in the user application if they are used. So, if the IWDG
is being used in the application, the IWDG prescaler value has to be
adapted to meet the requirements of the application (since the
prescaler was set to its maximum value). For some products, not all
reset values are set. For more information please refer to the known
limitations detailed for each product’s bootloader versions.
抱歉回复晚了。
经过更多调查,我发现了问题所在。
为了进一步说明我所做的事情,这里有一些你的评论中也提到的要点。
- 禁用所有外围设备
- 已禁用 PLL
- 禁用所有中断
- 清除所有挂起的中断
遗憾的是我忘了说我们使用的是 embOS。
这就是问题所在。有核心寄存器 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDBIBGJ.html
在控制寄存器中设置了一个位:SPSEL
如果该位设置为“1”,则 embOS 的正常运行会出现问题。
解决方法很简单:
__set_CONTROL(0x0);
当这被调用时,从 embOS 跳转到 Bootloader 并返回到 embOS 工作得很好。
我有一个引导加载程序和一个固件,从引导加载程序到固件的初始跳转就像一个魅力,但是当我有从应用程序跳回的场景时,做一些东西然后跳回我的应用程序。在那里我遇到了一些奇怪的问题,最终导致了一个严重的错误。如果我通过 IAR 的 __enable_interrupts() 激活中断,就会出现这个问题。
清除和重置所有正确的寄存器是什么? 我已将 MSP 和 PC 设置为 application/bootloader.
的开头我不使用 NVIC_Systemreset 是必要的。
希望有人能帮我解决这个问题吗?
有一个关于引导程序的ST application note。
In addition to patterns described above, user can execute bootloader by performing a jump to system memory from user code. Before jumping to bootloader user must:
- Disable all peripheral clocks
- Disable used PLL
- Disable interrupts
- Clear pending interrupts
这就是当您激活中断时引导加载程序崩溃的原因。
编辑
为了解决@Clifford 的想法,STM32 系统引导加载程序退出并使用 go 命令跳转到主定义地址。这个地址应该是 reset vector 而不是 main,这样堆、栈和 FW 才能正确初始化。之后,您可以 system_reset 进入已知的硬件状态,或者您必须完全配置您在应用程序中使用的外围设备,因为它们在引导加载程序使用它们后未设置为重置状态。
Note: If you choose to execute the Go command, the peripheral registers used by the bootloader are not initialized to their default reset values before jumping to the user application. They should be reconfigured in the user application if they are used. So, if the IWDG is being used in the application, the IWDG prescaler value has to be adapted to meet the requirements of the application (since the prescaler was set to its maximum value). For some products, not all reset values are set. For more information please refer to the known limitations detailed for each product’s bootloader versions.
抱歉回复晚了。
经过更多调查,我发现了问题所在。 为了进一步说明我所做的事情,这里有一些你的评论中也提到的要点。
- 禁用所有外围设备
- 已禁用 PLL
- 禁用所有中断
- 清除所有挂起的中断
遗憾的是我忘了说我们使用的是 embOS。 这就是问题所在。有核心寄存器 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDBIBGJ.html
在控制寄存器中设置了一个位:SPSEL 如果该位设置为“1”,则 embOS 的正常运行会出现问题。 解决方法很简单:
__set_CONTROL(0x0);
当这被调用时,从 embOS 跳转到 Bootloader 并返回到 embOS 工作得很好。