This is the mail archive of the
mailing list for the eCos project.
Re: Cortex-M Vector Table Offset
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- Cc: eCos developers <ecos-devel at ecos dot sourceware dot org>
- Date: Fri, 31 Dec 2010 10:01:06 +0100
- Subject: Re: Cortex-M Vector Table Offset
- References: <4D11FF19.firstname.lastname@example.org> <D6050C555CC56940A7AF3265228302761394DC@mail2.STMIRV01.COM>
On 23.12.2010 19:12, Christophe Coutand wrote:
> 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
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
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
At the end of this year I wish all eCos developers Happy New 2011.
> -----Original Message-----
> From: email@example.com on behalf of Ilija Kocho
> Sent: Wed 12/22/2010 5:37 AM
> To: eCos developers
> Subject: Cortex-M Vector Table Offset
> 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
> 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
> 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
> 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