manual:ports:armcm3_stm32
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
manual:ports:armcm3_stm32 [2018/01/25 08:50] voorburg [Vector table location] |
manual:ports:armcm3_stm32 [2019/08/09 11:58] voorburg |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== ARM Cortex-M3 for STM32F1xx ====== | ====== ARM Cortex-M3 for STM32F1xx ====== | ||
| - | |||
| - | |||
| ===== Vector table location ===== | ===== Vector table location ===== | ||
| The bootloader itself occupies the location where normally the user program's vector table is located. The vector table in the user program therefore needs to be relocated. The bootloader implementation is such that the user program's vector table must be located at address 0x08002000 instead of the standard 0x08000000. | The bootloader itself occupies the location where normally the user program's vector table is located. The vector table in the user program therefore needs to be relocated. The bootloader implementation is such that the user program's vector table must be located at address 0x08002000 instead of the standard 0x08000000. | ||
| - | |||
| - | |||
| The vector table relocation can be achieved by changing the ROM start address in the linker descriptor file. Refer to the demo program for an example. | The vector table relocation can be achieved by changing the ROM start address in the linker descriptor file. Refer to the demo program for an example. | ||
| - | |||
| - | |||
| {{:manual:ports:stm32_linker_script_prog.gif?|}} | {{:manual:ports:stm32_linker_script_prog.gif?|}} | ||
| - | |||
| - | |||
| Note that the space needed by the bootloader could be different than 0x2000 (8 kbyte), depending on the selected communication interface and compiler. The demo programs are working examples that you can refer to, to determine the exact vector table relocation. | Note that the space needed by the bootloader could be different than 0x2000 (8 kbyte), depending on the selected communication interface and compiler. The demo programs are working examples that you can refer to, to determine the exact vector table relocation. | ||
| - | |||
| - | |||
| Because the bootloader remaps the base address of the interrupt vector table, make sure that your program's initialization routine does not set it back to its original location. This is the case if you use function SystemInit() from ST's driver library. To correct this you need to remove the following lines from function SystemInit(): | Because the bootloader remaps the base address of the interrupt vector table, make sure that your program's initialization routine does not set it back to its original location. This is the case if you use function SystemInit() from ST's driver library. To correct this you need to remove the following lines from function SystemInit(): | ||
| - | |||
| - | |||
| <code> | <code> | ||
| Line 38: | Line 26: | ||
| </code> | </code> | ||
| - | |||
| - | |||
| - | |||
| - | |||
| ===== Checksum location ===== | ===== Checksum location ===== | ||
| Line 50: | Line 34: | ||
| The user program must reserve space for this 32-bit checksum value. To reserve this space, simply enter one extra dummy entry into the interrupt vector table. This reserves space for the checksum at memory address: flash base address + flash reserved for bootloader + FLASH_VECTOR_TABLE_CS_OFFSET. Refer to the demo program for an example. | The user program must reserve space for this 32-bit checksum value. To reserve this space, simply enter one extra dummy entry into the interrupt vector table. This reserves space for the checksum at memory address: flash base address + flash reserved for bootloader + FLASH_VECTOR_TABLE_CS_OFFSET. Refer to the demo program for an example. | ||
| - | |||
| {{:manual:ports:stm32_checksum_reservation.gif? |}} | {{:manual:ports:stm32_checksum_reservation.gif? |}} | ||
| - | |||
| - | |||
| ===== Stackpointer initialization ===== | ===== Stackpointer initialization ===== | ||
| On the ARM Cortex-M3 the first entry into the vector table holds the initialization value for the stackpointer, which is automatically loaded into the CPU's stackpointer register upon reset. | On the ARM Cortex-M3 the first entry into the vector table holds the initialization value for the stackpointer, which is automatically loaded into the CPU's stackpointer register upon reset. | ||
| - | |||
| - | |||
| After reset, the bootloader gets started first and, if a valid user program is present, it is the bootloaders responsibility to start the user program. This unfortunately means that the automatic initialization of the CPU's stackpointer register does not work for the user program. The user program therefore needs to explicitly set the initial value of the CPU's stackpointer register in the reset interrupt service routine. Refer to the demo program for an example. | After reset, the bootloader gets started first and, if a valid user program is present, it is the bootloaders responsibility to start the user program. This unfortunately means that the automatic initialization of the CPU's stackpointer register does not work for the user program. The user program therefore needs to explicitly set the initial value of the CPU's stackpointer register in the reset interrupt service routine. Refer to the demo program for an example. | ||
| - | |||
| - | |||
| {{:manual:ports:stm32_stackpointer_init.gif? |}} | {{:manual:ports:stm32_stackpointer_init.gif? |}} | ||
| - | |||
manual/ports/armcm3_stm32.txt ยท Last modified: 2022/11/07 11:27 by voorburg
Page Tools
