IAR开发STM32 BOOT + APP 的便捷方式

最近要开发BOOT+APP的方式，进行固件升级。

使用IAR，基于STM32F072.

之前调试烧写都是分开来，最后合并一个文件烧写。

最近发现IAR可以在调试的时候，直接调试BOOT或者APP，很是便捷。

具体请参考IAR官方NOTE：https://www.iar.com/support/tech-notes/general/creating-a-bootloader-for-cortex-m/

复制如下：

Technical Note 160822

Targets:

ARM

---

Component:

General

---

Updated:

2016/9/19 14:02

Introduction

This Technical Note provides guidelines on how to create a bootloader using IAR Embedded Workbench for ARM. Most of the recommendations in the Technical Note are general, although the example project is for a Cortex-M microprocessor (specifically STMicroelectronics STM32L152VB).

Discussion

When creating a bootloader, there are some things to consider regarding project setup, and the execution handover from the bootloader to the application. See the example project for STM32L152VBand follow the considerations below. Note that for clarity, this Technical Note does NOT describe how to perform a “live update” (IAP – in application programming) of the application, or how to configure communication interfaces, although this is a common feature in bootloaders.

General considerations

• Create separate projects – one for the bootloader and one for the application. The two projects can be placed in the same workspace. By keeping the projects separate, you make sure that code and library functions are not being shared between the bootloader and the application.
  

• Check the flash memory block size (the smallest erasable unit of the flash memory). The divide between the bootloader and application must be on a flash block boundary, otherwise you risk erasing parts of the application or bootloader when you replace one of them.
   
• Any hardware initialization should normally only be performed once, most often by the bootloader. Make sure that the application does not re-initialize the hardware unless that is what you want.
   
• Before the bootloader hands over execution to the application, make sure to:

1. 1. Disable interrupts – to avoid unexpected interrupts during application startup.
   2. Configure/reset the stack pointer – so that the application’s stack memory is not already used up by the bootloader.
   3. Configure the VTOR register – so that interrupts are handled by the application – not the bootloader.
      

Debugging considerations

Debugging the bootloader and the application at the same time is possible, but can be tricky, for example because they both contain a main function. To make the debugger aware of the two applications, choose Project > Options > Debugger > Images to load debug information from the other project’s ELF output file.

Make sure that the option Run to main is disabled on the Debugger Setup page, to avoid any confusion about which of the main functions to run to (the main function in the bootloader or the mainfunction in the application).

After downloading, the debugger will by default start execution at the address specified in the symbol called __vector_table. When you debug the bootloader and the application at the same time, the following message might be displayed:

To guide the debugger to the correct __vector_table symbol, you can explicitly specify where the bootloader’s vector table is located. Choose Project > Options > Debugger > Extra Options and specify:

 --drv_vector_table_base=0x08000000

When you are debugging, use the View > Images window to select the application currently in scope, to avoid problems with conflicting symbol names in the two applications.

When single-stepping over the actual jump from the bootloader to the application, remember to change the currently loaded debug info (in the Images window).

Flash writing considerations

To download the application and bootloader to flash memory, there are many alternatives. Because the bootloader and application are placed in separate projects, they can be downloaded individually from each project. As an alternative, you can download them both to flash memory at the same time, for example by using the linker to include an application binary in the bootloader project (or vice versa). Choose Project > Options > Linker > Input to accomplish this.

In the linker configuration file, the application binary is placed in flash memory with:

place at address mem: app_vector { readonly section .APP };

See the example project for more details. The project can be tested using the C-SPY Simulator driver or on a STM32 target device, using I-jet.

Conclusion

When you create a bootloader, you must consider a few things concerning project structure and the actual jump from the bootloader into the application. This Technical Note aims to serve as a general guideline for creating a bootloader using IAR Embedded Workbench for ARM. To get more information about debugger windows, options and the __vector_table symbol, choose Help > C-SPY Debugging Guide. For examples on how to write to flash memory from an application, choose Help > Information Center > Example Projects for your specific device.

 

 

 

大意有两点：1、要想把两个文件合并在一起，需要改.icf文件，配置linker->input。

2、调试时，Debugger->Images指定.out调试文件，设定好image偏移地址。

 

一开始没有搞清楚，发现仅仅设置Debugger->Images是不能把文件下进去的，结果去现场升级程序，差点闹尴尬。现在算是搞清楚这两点了。