Cortex-M Vector Table Offset

Cortex-M Vector Table Offset

[Ilija Kocho]

Hello

In a course of porting eCos to Cortex-M based devices, other than STM32,
an issue occurs that must be addressed.

The problem (In following discussion I refer to ROM start-up configuration):

In current Cortex-M port the Vector Table Offset is fixed (VTOR set) by
architecture port to 0x20000000 (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM
defined in hal/cortexm/arch/<version>/include/hal_io.h). This is the
place where it should be expected but on some devices this is not possible:

The example is NXP LPC 17xx family that has no RAM in Data (SRAM)
partition (i.e. at 0x20000000). Instead SRAM is located within Code
partition at address 0x10000000.

Proposed solution:

Define Vector Table base (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM) in the
variant with override option for the platform: respective var_io.h
and/or plf_io.h.

Also there is apparent dependence between
CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM and devices' memory configuration(s)
so we could consider some shared defines with pkgconf files and/or CDL.
This could provide flexibility useful for some other devices such as
Freescale Kinetis family.

Patch(es) should be easy and harmless. I could produce ones after
discussion.

For the end I have one question: What is use of
CYGARC_REG_NVIC_VTOR_TBLOFF(0) (hal/cortexm/arch/current/src/hal_misc.c)

Best regards
Ilija

Re: Cortex-M Vector Table Offset

[Ilija Kocho]

On 23.12.2010 19:12, Christophe Coutand wrote:
>
> Hi,
>
> Allowing the variant to overwrite CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM
> seems the way to go.
>

That's what I have done so far by introducing conditional #define in the
arch. I would also consider removing CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM
with appropriate patch to current STM32 variant.

> Maybe the idea was to have
> CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM equal to the SRAM base and
> CYGARC_REG_NVIC_VTOR_TBLOFF to fine tune the offset. I think it is
> enough to have a patch that make it possible to redefine
> CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM.
>

RegardingCYGARC_REG_NVIC_VTOR_TBLOFF it would be good to hear author's
rationale. Is it some code used during Cortex-M port development or is
placed to meet some Cortex-M features not implemented in current
implementations? Can we omit it?

>
> It is up to the variant/platform to propagate any CDL definition down to
> CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM and the memory layout so no patch for
> the existing code is required?
>

It is possible to put CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM in var_io.h or
in CDL. However hal_io.h must be patched with /#if !defined
CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM/ condition.

var_io.h would be better (simple) choice for devices with "fixed" SRAM
position/configuration, such as LPC17xx and CDL seem to give some
flexibility for devices like Kinetis.

In the mean time, other similar issues have occurred since my first
post, I would present them and propose solution(s) in the context of
variant port(s).

At the end of this year I wish all eCos developers Happy New 2011.

Ilija

>
> Christophe
>
>
> -----Original Message-----
> From: ecos-devel-owner@ecos.sourceware.org on behalf of Ilija Kocho
> Sent: Wed 12/22/2010 5:37 AM
> To: eCos developers
> Subject: Cortex-M Vector Table Offset
>
> Hello
>
> In a course of porting eCos to Cortex-M based devices, other than STM32,
> an issue occurs that must be addressed.
>
> The problem (In following discussion I refer to ROM start-up
> configuration):
>
> In current Cortex-M port the Vector Table Offset is fixed (VTOR set) by
> architecture port to 0x20000000 (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM
> defined in hal/cortexm/arch/<version>/include/hal_io.h). This is the
> place where it should be expected but on some devices this is not
> possible:
>
> The example is NXP LPC 17xx family that has no RAM in Data (SRAM)
> partition (i.e. at 0x20000000). Instead SRAM is located within Code
> partition at address 0x10000000.
>
> Proposed solution:
>
> Define Vector Table base (CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM) in the
> variant with override option for the platform: respective var_io.h
> and/or plf_io.h.
>
> Also there is apparent dependence between
> CYGARC_REG_NVIC_VTOR_TBLBASE_SRAM and devices' memory configuration(s)
> so we could consider some shared defines with pkgconf files and/or CDL.
> This could provide flexibility useful for some other devices such as
> Freescale Kinetis family.
>
> Patch(es) should be easy and harmless. I could produce ones after
> discussion.
>
> For the end I have one question: What is use of
> CYGARC_REG_NVIC_VTOR_TBLOFF(0) (hal/cortexm/arch/current/src/hal_misc.c)
>
> Best regards
> Ilija
>
>