* Cortex-M Vector Table Offset
@ 2010-12-22 13:37 Ilija Kocho
[not found] ` <D6050C555CC56940A7AF3265228302761394DC@mail2.STMIRV01.COM>
0 siblings, 1 reply; 2+ messages in thread
From: Ilija Kocho @ 2010-12-22 13:37 UTC (permalink / raw)
To: eCos developers
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Cortex-M Vector Table Offset
[not found] ` <D6050C555CC56940A7AF3265228302761394DC@mail2.STMIRV01.COM>
@ 2010-12-31 9:01 ` Ilija Kocho
0 siblings, 0 replies; 2+ messages in thread
From: Ilija Kocho @ 2010-12-31 9:01 UTC (permalink / raw)
Cc: eCos developers
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
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-12-31 9:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-22 13:37 Cortex-M Vector Table Offset Ilija Kocho
[not found] ` <D6050C555CC56940A7AF3265228302761394DC@mail2.STMIRV01.COM>
2010-12-31 9:01 ` Ilija Kocho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).