Hi Maciej, Bobby,

Could test the following patch ?

If it works, it's the correct way to handle this situation, and should be included in the stm32f0 support patchset.


--><---------------------------------------------------------------------------

diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index 1382379..57e0e92 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -26,12 +26,25 @@

 #ifdef CONFIG_ARMV6_M

+/**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ *       This functions is a hook before the vector memory relocation to
+ *       ensure the mapped memory is correct.
+ */
+void __weak relocate_vector_memory(void)
+{
+       /* Nothing to do by default */
+}
+
 #define VECTOR_ADDRESS 0
 static inline void relocate_vector_table(void)
 {
 #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
     !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
        size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+
+       relocate_vector_memory();
+
        memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
 #endif
 }
diff --git a/arch/arm/soc/st_stm32/stm32f0/soc.c b/arch/arm/soc/st_stm32/stm32f0/soc.c
index 727c348..2c056c2 100644
--- a/arch/arm/soc/st_stm32/stm32f0/soc.c
+++ b/arch/arm/soc/st_stm32/stm32f0/soc.c
@@ -17,6 +17,16 @@
 #include <cortex_m/exc.h>

 /**
+ * @brief On Cortex-M0 platforms, the Vector Base address cannot be changed.
+ *       This functions is a hook before the vector memory relocation to
+ *       ensure the mapped memory is correct.
+ */
+void relocate_vector_memory(void)
+{
+       LL_SYSCFG_SetRemapMemory(LL_SYSCFG_REMAP_SRAM);
+}
+
+/**
  * @brief This function configures the source of stm32cube time base.
  *        Cube HAL expects a 1ms tick which matches with k_uptime_get_32.
  *        Tick interrupt priority is not used
--

Thanks,
Neil

On 09/11/2017 02:35 PM, Neil Armstrong wrote:
> Hi All,
>
> On STM32F0 SoCs, the forst 32K cam be remapped to an internal SRAM, but this must be done *before* the relocate_vector_table() call.
>
> I will push a patch to add a relocate hook for Cortex-M0 platforms to use the LL LL_SYSCFG_SetRemapMemory() call before the vector table relocating.
>
> Neil
>
> On 09/11/2017 12:06 PM, Neil Armstrong wrote:
>> Hi All,
>>
>> I have some concern about this commit eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 (arm: armv6-m: Support relocating vector table).
>>
>> On STM32, flash is not at address 0, but can be relocated like sram spi-flash, external nand, ..., but should be when booting from flash, but this code is totally erroneous !
>>
>> The #if is bogus :
>> #if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>
>> And it doesn't take in account what is actually mapped at address 0 !
>>
>> On STM32, we can consider if we boot on XIP the flash is mapped on 0, so no need to relocate vectors, but indeed it can be remapped later.
>>
>> @Bobby : I think this relocate should be disabled instead if avoiding copy when the values are the same.
>>
>> @kumar, erwan : should it be handled with a config disabling the relocation on stm32 ?
>>
>> Neil
>>
>> On 09/03/2017 07:22 PM, b0661 wrote:
>>> Hello Maciej,
>>>
>>> I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.
>>>
>>> The commit "arch: arm: core: fix vector table relocate write to flash"
>>> https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314 <https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314>
>>> works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).
>>>
>>> I do not have a board that needs the relocation. So this is untested for such boards.
>>> Nevertheless the commit passes my local sanity check.
>>>
>>> If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.
>>>
>>> Bobby
>>>
>>>
>>> 2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@... <mailto:maciej.debski@rndity.com>>:
>>>
>>>     Gentlemen,
>>>
>>>     thank you for your quick responses!
>>>
>>>     As I wanted to provide more info and debug output, I accidentally found the issue.
>>>     This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.
>>>
>>>     Here is the commit:
>>>     https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8 <https://github.com/zephyrproject-rtos/zephyr/commit/eb48a0a73c11c2a9cd4c3c91864ca4e0cf52dae8>
>>>
>>>     And here are the specific changes causing problem:
>>>
>>>     diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
>>>     index d23dd8b..1382379 100644
>>>     --- a/arch/arm/core/cortex_m/prep_c.c
>>>     +++ b/arch/arm/core/cortex_m/prep_c.c
>>>     @@ -22,9 +22,20 @@
>>>      #include <linker/linker-defs.h>
>>>      #include <nano_internal.h>
>>>      #include <arch/arm/cortex_m/cmsis.h>
>>>     +#include <string.h>
>>>
>>>      #ifdef CONFIG_ARMV6_M
>>>     -static inline void relocate_vector_table(void) { /* do nothing */ }
>>>     +
>>>     +#define VECTOR_ADDRESS 0
>>>     +static inline void relocate_vector_table(void)
>>>     +{
>>>     +#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
>>>     +    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
>>>     +       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
>>>     +       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
>>>     +#endif
>>>     +}
>>>     +
>>>      #elif defined(CONFIG_ARMV7_M)
>>>      #ifdef CONFIG_XIP
>>>      #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \
>>>
>>>
>>>     When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
>>>     What should I do now? How to report it properly?
>>>
>>>     Thank you!
>>>
>>>     Yours faithfully,
>>>     Maciej Dębski
>>>
>>>
>>>
>>>
>>>     On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@... <mailto:maciej.debski@rndity.com>> wrote:
>>>
>>>         Hello,
>>>
>>>         I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.
>>>
>>>         I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.
>>>
>>>         I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
>>>         After checking the code over and over, I think I need help!
>>>
>>>         I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?
>>>
>>>         https://github.com/zephyrproject-rtos/zephyr/pull/1103 <https://github.com/zephyrproject-rtos/zephyr/pull/1103>
>>>
>>>         This is my pull request. I would focus on dts/arm and include/dt-bindings.
>>>
>>>         Yours faithfully,
>>>         Maciej Dębski
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Zephyr-devel mailing list
>>>     Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
>>>     https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@lists.zephyrproject.org
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>>>
>>
>