Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Neil Armstrong

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 :

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 ?


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" <>
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.


2017-08-25 14:24 GMT+02:00 Maciej Dębski < <>>:


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: <>

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>

-static inline void relocate_vector_table(void) { /* do nothing */ }
+static inline void relocate_vector_table(void)
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+ size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+ memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
#elif defined(CONFIG_ARMV7_M)
#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 < <>> wrote:


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? <>

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 mailing list

Join to automatically receive all group messages.