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 :
#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
toggle quoted message
Show quoted text
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@...>>:
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@...>> 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@... <mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel