STMicroelectronics / STM32CubeF4

STM32Cube MCU Full Package for the STM32F4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
831 stars 410 forks source link

template file system_stm32f4xx.c should support userdefined location of vectortable #30

Closed theadib closed 3 years ago

theadib commented 4 years ago

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

Describe the bug A clear and concise description of what the bug is. template file system_stm32f4xx.c should support userdefined location of vectortable using a custom bootloader requires to move the default location of the vector table. in the file system_stm32f4xx.c that is copied by the program generator is the needed settings for the move of the vector table. But the user can not control this behaviour by compiler command arguments in the defines section at the beginning of the file line 92ff the lines: / #define VECT_TAB_SRAM /

define VECT_TAB_OFFSET 0x00 /*!< Vector Table base offset field.

                               This value must be a multiple of 0x200. */

/**/

have to be changed to / #define VECT_TAB_SRAM /

if !defined(VECT_TAB_OFFSET)

define VECT_TAB_OFFSET 0x00 /*!< Vector Table base offset field.

                               This value must be a multiple of 0x200. */

endif

/**/

So the user can control the define from compiler command arguments. This allows targets for bootloader or plain memory layout.

All the existing code will not break.

How To Reproduce

  1. Indicate the global behavior of your application project.

  2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

  3. The use case that generates the problem.

  4. How we can reproduce the problem.

Additional context If you have a first analysis or patch correction, thank you to share your proposal.

Screenshots If applicable, add screenshots to help explain your problem.

RKOUSTM commented 4 years ago

Hi @theadib,

Thank you for this report. You request will be forwarded to our development teams. We will be back to you as soon as we get feedback.

Thank you for your patience and thank you again for your contribution.

With regards,

RKOUSTM commented 3 years ago

Hi @theadib,

Thank you for your contribution. Our development teams confirmed the issue you pointed out. The fix below will be available in the next release.

+ #if defined(USER_VECT_TAB_ADDRESS)
/* #define VECT_TAB_SRAM */
+ #if defined(VECT_TAB_SRAM)
+ #define VECT_TAB_BASE_ADDRESS   SRAM_BASE       /*!< Vector Table base address field.
+                                                    This value must be a multiple of 0x200. */
+ #define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
+                                                    This value must be a multiple of 0x200. */
+ #else
+ #define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
+                                                     This value must be a multiple of 0x200. */
+ #define VECT_TAB_OFFSET         0x00000000U     /*!< Vector Table base offset field.
+                                                    This value must be a multiple of 0x200. */
+ #endif /* VECT_TAB_SRAM */
+ #endif /* USER_VECT_TAB_ADDRESS */

I hope this answer helps. If you have no other question about this subject, I think this issue can be closed.

With regards,

RKOUSTM commented 3 years ago

ST Internal Reference: 76137

fpistm commented 3 years ago

Hi @RKOUSTM

In STM32duino, it is possible to redefine VECT_TAB_OFFSET to use a bootloader. In a general way Bootloader is stored at the beginning of the FLASH, in that case the VECT_TAB_OFFSET is set to the SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; where offset is set after the BL.

With the USER_VECT_TAB_ADDRESS I don't understand how we can properly set it as the VECT_TAB_OFFSET is always 0. This only allow to set it to SRAM or FLASH.

RKOUSTM commented 3 years ago

Hi @fpistm,

Thank you for your contribution. The above fix is proposed to mention if we are on FLASH or SRAM, and if we want to apply a different Offset value, as in the STM32WL, the following:

/* #define VECT_TAB_SRAM */
#if defined(VECT_TAB_SRAM)
#define VECT_TAB_BASE_ADDRESS   SRAM2_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x100. */
#define VECT_TAB_OFFSET         0x00008000U     /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x100. */
#else
#define VECT_TAB_BASE_ADDRESS   FLASH_BASE      /*!< Vector Table base address field.
                                                     This value must be a multiple of 0x100. */
#define VECT_TAB_OFFSET         0x00020000U        /*!< Vector Table base offset field.
                                                     This value must be a multiple of 0x100. */
#endif

Thank you again for your contribution.

With regards,

fpistm commented 3 years ago

Thanks for the feedback @RKOUSTM But I think the OP request concern the VECT_TAB_OFFSET not if we are on FLASH or SRAM. Anyway you answered my question and will update STM32duino to also be able to redefine VECT_TAB_OFFSET

RKOUSTM commented 3 years ago

Hi @theadib,

I hope you are fine. The issue you reported has been fixed in the frame of version v1.26.0 of the STM32CubeF4 published recently on GitHub.

Thank you again for having reported.

With regards,

theadib commented 3 years ago

please ST the register holding the vector address should be written as part of the startup code in any case. not only when USER_ADDRESS is defined.

SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;