STMicroelectronics / STM32CubeL0

STM32Cube MCU Full Package for the STM32L0 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
103 stars 57 forks source link

Allow VECT_TAB_OFFSET to be overridden externally (IDE or Makefile) #10

Open pieterconradie opened 3 years ago

pieterconradie commented 3 years ago

It is useful to allow VECT_TAB_OFFSET to be overridden externally in the IDE or Makefile. This allows the Vector Table Offset to be at 0 for a debug build and the Vector Table Offset to be moved for a release build that has to accommodate a bootloader.

IMPORTANT INFORMATION

Contributor License Agreement (CLA)

RKOUSTM commented 3 years ago

Hi @pieterconradie,

Thank you for your suggestion and contribution. A fix for this code below: https://github.com/STMicroelectronics/STM32CubeL0/blob/8b26821a5b4831fc85df5c450c81568a744a1027/Drivers/CMSIS/Device/ST/STM32L0xx/Source/Templates/system_stm32l0xx.c#L80-L85

will be published as soon in in future release (STM32L0Cube V1.12.0) looks like the following:

+ #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 */

Thank you again for your contribution.

With regards,

pieterconradie commented 3 years ago

@RKOUSTM Thanks for attending to the pull request so quickly :)

I am probably missing something but I can not see from the solution above how VECT_TAB_OFFSET can be overridden(?). In both cases above it is #defined as 0x00000000U

Should it not be:

#ifndef VECT_TAB_OFFSET
#define VECT_TAB_OFFSET 0x00000000U
#endif

Thanks in advance, Pieter

RKOUSTM commented 3 years ago

Hi @pieterconradie,

Thank you for your contribution. The vector table is updated by a generic preprocessor directive USER_VECT_TAB_ADDRESS to mention if we are on FLASH or SRAM, and if we want to apply an offset. Offset being a multiple of fixed value depending on Arm processor architecture. The vector table will be kept at address 0x00 which correspond to automatic remap of boot address selected. On any STM32 target, vector table is set to 0x00u which is always the right default address as

  1. there is always a memory remap between boot address and @0x00
  2. for dual core, CPU2 is booting on boot @ + SBRV register offset.

Thank you again for your contribution.

With regards,

fpistm commented 3 years ago

I've the same concern than @pieterconradie https://github.com/STMicroelectronics/STM32CubeF4/issues/30#issuecomment-705998451

RKOUSTM commented 3 years ago

Hi @pieterconradie,

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

Thank you again for having reported.

With regards,

ALABSTM commented 2 years ago

See also STM32CubeF4#30.

ALABSTM commented 2 years ago

See also STM32CubeF4#64.

ALABSTM commented 2 years ago

ST Internal Reference: 116475

ALABSTM commented 2 years ago

Hi @pieterconradie,

I hope you are fine. We reopened the point as the current implementation does not address the requirement to be able to redefine VECT_TAB_OFFSET without the need to manually edit the system_stm32l0xx.c file.

We will get back to you as soon as we get feedback from our development teams.

With regards,