[ECOS] ecos-3.0 current stm32 bug?

[ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

Hi all

I have a firmware split into two parts:
 1. a "bootloader"
 2. a "application"

I now need to move from Windows (cygwin) development environment to Linux development environment and at the same time use the current ecos version (i.e. what I get when I clone the ecos mercurial repository) instead of the "original" (back in 2009) ecos-3.0 version.

The situation is now as follows:
 1. I download (to my stm32 device) the Linux/ecos-current built "bootloader"
 2. I download (to my stm32 device) the Linux/ecos-current built "application"
 3. I start the application and in line 187 of file 'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to 'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr' function!

To analyze the problem I then:
 4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built "bootloader"
 5. Still having the Linux/ecos-current built "application"
 6. And in line 187 (of the above mentioned file) it branches (as it should) to 'hal_switch_state_vsr' and the application is starting up and running fine!

Who can give me a hint about
 * what has been changed in ecos-current cortexm stm32 that could cause this problem
 * or what else I could analyze to find out why ecos-current (built on Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin I also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric)

Regards
Philipp

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Sergei Gavrikov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2584 bytes --]

On Wed, 24 Aug 2011, Philipp Meier wrote:

> Hi all
> 
> I have a firmware split into two parts:
>  1. a "bootloader"
>  2. a "application"
> 
> I now need to move from Windows (cygwin) development environment to
> Linux development environment and at the same time use the current
> ecos version (i.e. what I get when I clone the ecos mercurial
> repository) instead of the "original" (back in 2009) ecos-3.0 version.
> 
> The situation is now as follows:
>  1. I download (to my stm32 device) the Linux/ecos-current built
>  "bootloader"
>  2. I download (to my stm32 device) the Linux/ecos-current built
>  "application"
>  3. I start the application and in line 187 of file
>  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to
>  'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr'
>  function!
> 
> To analyze the problem I then:
>  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
>  "bootloader"
>  5. Still having the Linux/ecos-current built "application"
>  6. And in line 187 (of the above mentioned file) it branches (as it
>  should) to 'hal_switch_state_vsr' and the application is starting up
>  and running fine!
> 
> Who can give me a hint about
>  * what has been changed in ecos-current cortexm stm32 that could
>  cause this problem

Hi Philipp,

I think you can use Mercurial for that

% hg tags | grep v3
ecos-v3_0-branchpoint           2821:b5a12bb6a634

% hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch | less -FRSX

or (may be)

% hg log --patch -r ecos-v3_0-branchpoint:tip \
	packages/hal/cortexm/arch/current/src/hal_misc.c | less -FRSX

etc.

>  * or what else I could analyze to find out why ecos-current (built on
>  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin I
>  also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric)
 
Also you would check the Linux build for ecos-3.0 codebase

# get old (working) code
% hg update ecos-v3_0-branchpoint

Rebuild your loader and application under Linux and try it (use fresh
directories for builds). After all do not forget up-to-date eCos HG
repository (hg update default).

Feel free to submit a bug report (if you'll find something) via eCos
Bugzilla System http://bugs.ecos.sourceware.org/


Sergei

> Regards
> Philipp
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

-------- Original-Nachricht --------
> Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> An: Philipp Meier <pme.neratec@gmx.ch>
> CC: ecos-discuss@ecos.sourceware.org
> Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?

> On Wed, 24 Aug 2011, Philipp Meier wrote:
> 
> > Hi all
> > 
> > I have a firmware split into two parts:
> >  1. a "bootloader"
> >  2. a "application"
> > 
> > I now need to move from Windows (cygwin) development environment to
> > Linux development environment and at the same time use the current
> > ecos version (i.e. what I get when I clone the ecos mercurial
> > repository) instead of the "original" (back in 2009) ecos-3.0 version.
> > 
> > The situation is now as follows:
> >  1. I download (to my stm32 device) the Linux/ecos-current built
> >  "bootloader"
> >  2. I download (to my stm32 device) the Linux/ecos-current built
> >  "application"
> >  3. I start the application and in line 187 of file
> >  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to
> >  'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr'
> >  function!
> > 
> > To analyze the problem I then:
> >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
> >  "bootloader"
> >  5. Still having the Linux/ecos-current built "application"
> >  6. And in line 187 (of the above mentioned file) it branches (as it
> >  should) to 'hal_switch_state_vsr' and the application is starting up
> >  and running fine!
> > 
> > Who can give me a hint about
> >  * what has been changed in ecos-current cortexm stm32 that could
> >  cause this problem
> 
> Hi Philipp,
> 
> I think you can use Mercurial for that
> 
> % hg tags | grep v3
> ecos-v3_0-branchpoint           2821:b5a12bb6a634
> 
> % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch | less
> -FRSX
> 
> or (may be)
> 
> % hg log --patch -r ecos-v3_0-branchpoint:tip \
> 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -FRSX
> 
> etc.
> 
> >  * or what else I could analyze to find out why ecos-current (built on
> >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin I
> >  also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric)
>  
> Also you would check the Linux build for ecos-3.0 codebase
> 
> # get old (working) code
> % hg update ecos-v3_0-branchpoint
> 
> Rebuild your loader and application under Linux and try it (use fresh
> directories for builds). After all do not forget up-to-date eCos HG
> repository (hg update default).
> 
> Feel free to submit a bug report (if you'll find something) via eCos
> Bugzilla System http://bugs.ecos.sourceware.org/
> 
> 
> Sergei
> 
> > Regards
> > Philipp

Hello Sergei and others

Thanks a lot for your tips about how to find out the differences between the versions.

I now went a step back and built (under Linux) my "bootloader" and my "application" under Linux using the same ecos sources and configuration files as when I built them under Windows/cygwin.

Therefore - I wanted to see if the problem comes from building under Linux, or from changes in the ecos stm32 parts (or any other ecos parts).

But - I have the same problem as described above; i.e. the problem must be somehow in my Linux toolchain?

Therefore my question now is:
Can anybody give me some background information about how the "__asm__ volatile( "swi" )" statement in line 188 of packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187 in packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-current) is interpreted on stm32? What could be the reason that it does not jumps to "hal_switch_state_vsr" but instead jumps to "hal_default_exception_vsr"?

The lines where the different behaviour is look like this:
hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] = (CYG_ADDRESS)hal_switch_state_vsr;

__asm__ volatile( "swi" );

...

In the good case these leads to a jump/branch to hal_switch_state_vsr and in the bad case it jumps/branches to hal_default_exception_vsr and therefore my application does not starts up.

Thanks for any help.

Philipp
-- 
P.S.: Sorry Sergei - I did not mean to reply directly to you but like this to the mailing list.
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] ecos-3.0 current stm32 bug?

[Christophe Coutand]

Both the bootloader and the application are ROM startup type? 

What about the address of the hal_vsr_table in the bootloader and application?

Christophe

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> Sent: 24. august 2011 16:11
> To: ecos discuss
> Subject: Re: [ECOS] ecos-3.0 current stm32 bug?
> 
> -------- Original-Nachricht --------
> > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> > Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> > An: Philipp Meier <pme.neratec@gmx.ch>
> > CC: ecos-discuss@ecos.sourceware.org
> > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?
> 
> > On Wed, 24 Aug 2011, Philipp Meier wrote:
> >
> > > Hi all
> > >
> > > I have a firmware split into two parts:
> > >  1. a "bootloader"
> > >  2. a "application"
> > >
> > > I now need to move from Windows (cygwin) development environment to
> > > Linux development environment and at the same time use the current
> > > ecos version (i.e. what I get when I clone the ecos mercurial
> > > repository) instead of the "original" (back in 2009) ecos-3.0
> version.
> > >
> > > The situation is now as follows:
> > >  1. I download (to my stm32 device) the Linux/ecos-current built
> > >  "bootloader"
> > >  2. I download (to my stm32 device) the Linux/ecos-current built
> > >  "application"
> > >  3. I start the application and in line 187 of file
> > >  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to
> > >  'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr'
> > >  function!
> > >
> > > To analyze the problem I then:
> > >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
> > >  "bootloader"
> > >  5. Still having the Linux/ecos-current built "application"
> > >  6. And in line 187 (of the above mentioned file) it branches (as
> it
> > >  should) to 'hal_switch_state_vsr' and the application is starting
> up
> > >  and running fine!
> > >
> > > Who can give me a hint about
> > >  * what has been changed in ecos-current cortexm stm32 that could
> > >  cause this problem
> >
> > Hi Philipp,
> >
> > I think you can use Mercurial for that
> >
> > % hg tags | grep v3
> > ecos-v3_0-branchpoint           2821:b5a12bb6a634
> >
> > % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch |
> less
> > -FRSX
> >
> > or (may be)
> >
> > % hg log --patch -r ecos-v3_0-branchpoint:tip \
> > 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -FRSX
> >
> > etc.
> >
> > >  * or what else I could analyze to find out why ecos-current (built
> on
> > >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin
> I
> > >  also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric)
> >
> > Also you would check the Linux build for ecos-3.0 codebase
> >
> > # get old (working) code
> > % hg update ecos-v3_0-branchpoint
> >
> > Rebuild your loader and application under Linux and try it (use fresh
> > directories for builds). After all do not forget up-to-date eCos HG
> > repository (hg update default).
> >
> > Feel free to submit a bug report (if you'll find something) via eCos
> > Bugzilla System http://bugs.ecos.sourceware.org/
> >
> >
> > Sergei
> >
> > > Regards
> > > Philipp
> 
> Hello Sergei and others
> 
> Thanks a lot for your tips about how to find out the differences
> between the versions.
> 
> I now went a step back and built (under Linux) my "bootloader" and my
> "application" under Linux using the same ecos sources and configuration
> files as when I built them under Windows/cygwin.
> 
> Therefore - I wanted to see if the problem comes from building under
> Linux, or from changes in the ecos stm32 parts (or any other ecos
> parts).
> 
> But - I have the same problem as described above; i.e. the problem must
> be somehow in my Linux toolchain?
> 
> Therefore my question now is:
> Can anybody give me some background information about how the "__asm__
> volatile( "swi" )" statement in line 188 of
> packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187 in
> packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-
> current) is interpreted on stm32? What could be the reason that it does
> not jumps to "hal_switch_state_vsr" but instead jumps to
> "hal_default_exception_vsr"?
> 
> The lines where the different behaviour is look like this:
> hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] =
> (CYG_ADDRESS)hal_switch_state_vsr;
> 
> __asm__ volatile( "swi" );
> 
> ...
> 
> In the good case these leads to a jump/branch to hal_switch_state_vsr
> and in the bad case it jumps/branches to hal_default_exception_vsr and
> therefore my application does not starts up.
> 
> Thanks for any help.
> 
> Philipp
> --
> P.S.: Sorry Sergei - I did not mean to reply directly to you but like
> this to the mailing list.
> --
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> 
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: RE: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

Hello Christophe,

Yes - both are ROM startup type. The bootloader without offset (i.e. offset 0x0), the application with offset 0x40000.

In the bootloader elf file hal_vsr_table is 20000000 and the same is true for the application.

GDB debug output when debugging the startup of the application:

Bad case (Linux built bootloader):
----------------------------------
(gdb) print /fx hal_vsr_table
$1 = {0x441c4c08, 0x61232301, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
  0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075 <repeats 61 times>}
(gdb) print /fx &hal_vsr_table
$2 = 0x20000000

Good case (Cygwin built bootloader):
----------------------------------
(gdb) print /fx hal_vsr_table
$1 = {0x4024f8df, 0xf04f4d09, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
  0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075 <repeats 61 times>}
(gdb) print /fx &hal_vsr_table
$2 = 0x20000000

Cheers
Philipp

-------- Original-Nachricht --------
> Datum: Wed, 24 Aug 2011 07:22:53 -0700
> Von: "Christophe Coutand" <ccoutand@stmi.com>
> An: "Philipp Meier" <pme.neratec@gmx.ch>, "ecos discuss" <ecos-discuss@ecos.sourceware.org>
> Betreff: RE: [ECOS] ecos-3.0 current stm32 bug?

> Both the bootloader and the application are ROM startup type? 
> 
> What about the address of the hal_vsr_table in the bootloader and
> application?
> 
> Christophe
> 
> > -----Original Message-----
> > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > Sent: 24. august 2011 16:11
> > To: ecos discuss
> > Subject: Re: [ECOS] ecos-3.0 current stm32 bug?
> > 
> > -------- Original-Nachricht --------
> > > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> > > Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> > > An: Philipp Meier <pme.neratec@gmx.ch>
> > > CC: ecos-discuss@ecos.sourceware.org
> > > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?
> > 
> > > On Wed, 24 Aug 2011, Philipp Meier wrote:
> > >
> > > > Hi all
> > > >
> > > > I have a firmware split into two parts:
> > > >  1. a "bootloader"
> > > >  2. a "application"
> > > >
> > > > I now need to move from Windows (cygwin) development environment to
> > > > Linux development environment and at the same time use the current
> > > > ecos version (i.e. what I get when I clone the ecos mercurial
> > > > repository) instead of the "original" (back in 2009) ecos-3.0
> > version.
> > > >
> > > > The situation is now as follows:
> > > >  1. I download (to my stm32 device) the Linux/ecos-current built
> > > >  "bootloader"
> > > >  2. I download (to my stm32 device) the Linux/ecos-current built
> > > >  "application"
> > > >  3. I start the application and in line 187 of file
> > > >  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching to
> > > >  'hal_switch_state_vsr' it branches to 'hal_default_exception_vsr'
> > > >  function!
> > > >
> > > > To analyze the problem I then:
> > > >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
> > > >  "bootloader"
> > > >  5. Still having the Linux/ecos-current built "application"
> > > >  6. And in line 187 (of the above mentioned file) it branches (as
> > it
> > > >  should) to 'hal_switch_state_vsr' and the application is starting
> > up
> > > >  and running fine!
> > > >
> > > > Who can give me a hint about
> > > >  * what has been changed in ecos-current cortexm stm32 that could
> > > >  cause this problem
> > >
> > > Hi Philipp,
> > >
> > > I think you can use Mercurial for that
> > >
> > > % hg tags | grep v3
> > > ecos-v3_0-branchpoint           2821:b5a12bb6a634
> > >
> > > % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch |
> > less
> > > -FRSX
> > >
> > > or (may be)
> > >
> > > % hg log --patch -r ecos-v3_0-branchpoint:tip \
> > > 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -FRSX
> > >
> > > etc.
> > >
> > > >  * or what else I could analyze to find out why ecos-current (built
> > on
> > > >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under cygwin
> > I
> > > >  also used the arm-eabi-gcc version 4.3.2 pre-built by eCosCentric)
> > >
> > > Also you would check the Linux build for ecos-3.0 codebase
> > >
> > > # get old (working) code
> > > % hg update ecos-v3_0-branchpoint
> > >
> > > Rebuild your loader and application under Linux and try it (use fresh
> > > directories for builds). After all do not forget up-to-date eCos HG
> > > repository (hg update default).
> > >
> > > Feel free to submit a bug report (if you'll find something) via eCos
> > > Bugzilla System http://bugs.ecos.sourceware.org/
> > >
> > >
> > > Sergei
> > >
> > > > Regards
> > > > Philipp
> > 
> > Hello Sergei and others
> > 
> > Thanks a lot for your tips about how to find out the differences
> > between the versions.
> > 
> > I now went a step back and built (under Linux) my "bootloader" and my
> > "application" under Linux using the same ecos sources and configuration
> > files as when I built them under Windows/cygwin.
> > 
> > Therefore - I wanted to see if the problem comes from building under
> > Linux, or from changes in the ecos stm32 parts (or any other ecos
> > parts).
> > 
> > But - I have the same problem as described above; i.e. the problem must
> > be somehow in my Linux toolchain?
> > 
> > Therefore my question now is:
> > Can anybody give me some background information about how the "__asm__
> > volatile( "swi" )" statement in line 188 of
> > packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187 in
> > packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-
> > current) is interpreted on stm32? What could be the reason that it does
> > not jumps to "hal_switch_state_vsr" but instead jumps to
> > "hal_default_exception_vsr"?
> > 
> > The lines where the different behaviour is look like this:
> > hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] =
> > (CYG_ADDRESS)hal_switch_state_vsr;
> > 
> > __asm__ volatile( "swi" );
> > 
> > ...
> > 
> > In the good case these leads to a jump/branch to hal_switch_state_vsr
> > and in the bad case it jumps/branches to hal_default_exception_vsr and
> > therefore my application does not starts up.
> > 
> > Thanks for any help.
> > 
> > Philipp
> > --
> > P.S.: Sorry Sergei - I did not mean to reply directly to you but like
> > this to the mailing list.
> > --
> > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > 
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > 
> > --
> > Before posting, please read the FAQ:
> > http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: RE: [ECOS] ecos-3.0 current stm32 bug?

[Christophe Coutand]

What about setting a breakpoint in hal_switch_state_vsr? Is it the SWI instruction that triggers the exception or is it the execution of the hal_switch_state_vsr routine?

Christophe

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> Sent: 24. august 2011 16:58
> To: ecos-discuss@ecos.sourceware.org
> Subject: Re: RE: [ECOS] ecos-3.0 current stm32 bug?
> 
> Hello Christophe,
> 
> Yes - both are ROM startup type. The bootloader without offset (i.e.
> offset 0x0), the application with offset 0x40000.
> 
> In the bootloader elf file hal_vsr_table is 20000000 and the same is
> true for the application.
> 
> GDB debug output when debugging the startup of the application:
> 
> Bad case (Linux built bootloader):
> ----------------------------------
> (gdb) print /fx hal_vsr_table
> $1 = {0x441c4c08, 0x61232301, 0x8040043, 0x8040043, 0x8040043,
> 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
>   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> <repeats 61 times>}
> (gdb) print /fx &hal_vsr_table
> $2 = 0x20000000
> 
> Good case (Cygwin built bootloader):
> ----------------------------------
> (gdb) print /fx hal_vsr_table
> $1 = {0x4024f8df, 0xf04f4d09, 0x8040043, 0x8040043, 0x8040043,
> 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
>   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> <repeats 61 times>}
> (gdb) print /fx &hal_vsr_table
> $2 = 0x20000000
> 
> Cheers
> Philipp
> 
> -------- Original-Nachricht --------
> > Datum: Wed, 24 Aug 2011 07:22:53 -0700
> > Von: "Christophe Coutand" <ccoutand@stmi.com>
> > An: "Philipp Meier" <pme.neratec@gmx.ch>, "ecos discuss" <ecos-
> discuss@ecos.sourceware.org>
> > Betreff: RE: [ECOS] ecos-3.0 current stm32 bug?
> 
> > Both the bootloader and the application are ROM startup type?
> >
> > What about the address of the hal_vsr_table in the bootloader and
> > application?
> >
> > Christophe
> >
> > > -----Original Message-----
> > > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > > Sent: 24. august 2011 16:11
> > > To: ecos discuss
> > > Subject: Re: [ECOS] ecos-3.0 current stm32 bug?
> > >
> > > -------- Original-Nachricht --------
> > > > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> > > > Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> > > > An: Philipp Meier <pme.neratec@gmx.ch>
> > > > CC: ecos-discuss@ecos.sourceware.org
> > > > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?
> > >
> > > > On Wed, 24 Aug 2011, Philipp Meier wrote:
> > > >
> > > > > Hi all
> > > > >
> > > > > I have a firmware split into two parts:
> > > > >  1. a "bootloader"
> > > > >  2. a "application"
> > > > >
> > > > > I now need to move from Windows (cygwin) development
> environment to
> > > > > Linux development environment and at the same time use the
> current
> > > > > ecos version (i.e. what I get when I clone the ecos mercurial
> > > > > repository) instead of the "original" (back in 2009) ecos-3.0
> > > version.
> > > > >
> > > > > The situation is now as follows:
> > > > >  1. I download (to my stm32 device) the Linux/ecos-current
> built
> > > > >  "bootloader"
> > > > >  2. I download (to my stm32 device) the Linux/ecos-current
> built
> > > > >  "application"
> > > > >  3. I start the application and in line 187 of file
> > > > >  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching
> to
> > > > >  'hal_switch_state_vsr' it branches to
> 'hal_default_exception_vsr'
> > > > >  function!
> > > > >
> > > > > To analyze the problem I then:
> > > > >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
> > > > >  "bootloader"
> > > > >  5. Still having the Linux/ecos-current built "application"
> > > > >  6. And in line 187 (of the above mentioned file) it branches
> (as
> > > it
> > > > >  should) to 'hal_switch_state_vsr' and the application is
> starting
> > > up
> > > > >  and running fine!
> > > > >
> > > > > Who can give me a hint about
> > > > >  * what has been changed in ecos-current cortexm stm32 that
> could
> > > > >  cause this problem
> > > >
> > > > Hi Philipp,
> > > >
> > > > I think you can use Mercurial for that
> > > >
> > > > % hg tags | grep v3
> > > > ecos-v3_0-branchpoint           2821:b5a12bb6a634
> > > >
> > > > % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch |
> > > less
> > > > -FRSX
> > > >
> > > > or (may be)
> > > >
> > > > % hg log --patch -r ecos-v3_0-branchpoint:tip \
> > > > 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -
> FRSX
> > > >
> > > > etc.
> > > >
> > > > >  * or what else I could analyze to find out why ecos-current
> (built
> > > on
> > > > >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under
> cygwin
> > > I
> > > > >  also used the arm-eabi-gcc version 4.3.2 pre-built by
> eCosCentric)
> > > >
> > > > Also you would check the Linux build for ecos-3.0 codebase
> > > >
> > > > # get old (working) code
> > > > % hg update ecos-v3_0-branchpoint
> > > >
> > > > Rebuild your loader and application under Linux and try it (use
> fresh
> > > > directories for builds). After all do not forget up-to-date eCos
> HG
> > > > repository (hg update default).
> > > >
> > > > Feel free to submit a bug report (if you'll find something) via
> eCos
> > > > Bugzilla System http://bugs.ecos.sourceware.org/
> > > >
> > > >
> > > > Sergei
> > > >
> > > > > Regards
> > > > > Philipp
> > >
> > > Hello Sergei and others
> > >
> > > Thanks a lot for your tips about how to find out the differences
> > > between the versions.
> > >
> > > I now went a step back and built (under Linux) my "bootloader" and
> my
> > > "application" under Linux using the same ecos sources and
> configuration
> > > files as when I built them under Windows/cygwin.
> > >
> > > Therefore - I wanted to see if the problem comes from building
> under
> > > Linux, or from changes in the ecos stm32 parts (or any other ecos
> > > parts).
> > >
> > > But - I have the same problem as described above; i.e. the problem
> must
> > > be somehow in my Linux toolchain?
> > >
> > > Therefore my question now is:
> > > Can anybody give me some background information about how the
> "__asm__
> > > volatile( "swi" )" statement in line 188 of
> > > packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187
> in
> > > packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-
> > > current) is interpreted on stm32? What could be the reason that it
> does
> > > not jumps to "hal_switch_state_vsr" but instead jumps to
> > > "hal_default_exception_vsr"?
> > >
> > > The lines where the different behaviour is look like this:
> > > hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] =
> > > (CYG_ADDRESS)hal_switch_state_vsr;
> > >
> > > __asm__ volatile( "swi" );
> > >
> > > ...
> > >
> > > In the good case these leads to a jump/branch to
> hal_switch_state_vsr
> > > and in the bad case it jumps/branches to hal_default_exception_vsr
> and
> > > therefore my application does not starts up.
> > >
> > > Thanks for any help.
> > >
> > > Philipp
> > > --
> > > P.S.: Sorry Sergei - I did not mean to reply directly to you but
> like
> > > this to the mailing list.
> > > --
> > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > >
> > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > >
> > > --
> > > Before posting, please read the FAQ:
> > > http://ecos.sourceware.org/fom/ecos
> > > and search the list archive: http://ecos.sourceware.org/ml/ecos-
> discuss
> >
> 
> --
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> 
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Sergei Gavrikov]

On Wed, 24 Aug 2011, Philipp Meier wrote:

[snip]

> I now went a step back and built (under Linux) my "bootloader" and my
> "application" under Linux using the same ecos sources and
> configuration files as when I built them under Windows/cygwin.
> 
> Therefore - I wanted to see if the problem comes from building under
> Linux, or from changes in the ecos stm32 parts (or any other ecos
> parts).
> 
> But - I have the same problem as described above; i.e. the problem
> must be somehow in my Linux toolchain?

In any case, ask. Maybe you have installed more arm-eabi toolchains,
i.e. and from another vendor, e.g. from CodeSourcery, etc. Check it,
please, check your PATH variable

  % which arm-eabi-gcc
  % echo $PATH
  % $(which arm-eabi-gcc) --version

also

  % echo $ECOS_REPOSITORY
  % ecosconfig --version

also (you told about HG tree)

  % hg status -R $ECOS_REPOSITORY/..

It would be nice to be sure that you use the right tools.


Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: RE: RE: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

Hello Christophe

it is the SWI instruction ("svc 0" in disassem code) that triggers the exception (therefore breakpoint in hal_switch_state_vsr is never reached).

Where does the SWI instruction get's it's information about where to jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I have 0x8040025 which is the address for hal_switch_state_vsr - and yet it does not jumps to 0x8040025 but instead to 0x8040042 (hal_default_exception_vsr).

Any idea about the reason for this behaviour?

Cheers Philipp

-------- Original-Nachricht --------
> Datum: Wed, 24 Aug 2011 09:40:02 -0700
> Von: "Christophe Coutand" <ccoutand@stmi.com>
> An: "Philipp Meier" <pme.neratec@gmx.ch>, ecos-discuss@ecos.sourceware.org
> Betreff: RE: RE: [ECOS] ecos-3.0 current stm32 bug?

> What about setting a breakpoint in hal_switch_state_vsr? Is it the SWI
> instruction that triggers the exception or is it the execution of the
> hal_switch_state_vsr routine?
> 
> Christophe
> 
> > -----Original Message-----
> > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > Sent: 24. august 2011 16:58
> > To: ecos-discuss@ecos.sourceware.org
> > Subject: Re: RE: [ECOS] ecos-3.0 current stm32 bug?
> > 
> > Hello Christophe,
> > 
> > Yes - both are ROM startup type. The bootloader without offset (i.e.
> > offset 0x0), the application with offset 0x40000.
> > 
> > In the bootloader elf file hal_vsr_table is 20000000 and the same is
> > true for the application.
> > 
> > GDB debug output when debugging the startup of the application:
> > 
> > Bad case (Linux built bootloader):
> > ----------------------------------
> > (gdb) print /fx hal_vsr_table
> > $1 = {0x441c4c08, 0x61232301, 0x8040043, 0x8040043, 0x8040043,
> > 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
> >   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> > <repeats 61 times>}
> > (gdb) print /fx &hal_vsr_table
> > $2 = 0x20000000
> > 
> > Good case (Cygwin built bootloader):
> > ----------------------------------
> > (gdb) print /fx hal_vsr_table
> > $1 = {0x4024f8df, 0xf04f4d09, 0x8040043, 0x8040043, 0x8040043,
> > 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
> >   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> > <repeats 61 times>}
> > (gdb) print /fx &hal_vsr_table
> > $2 = 0x20000000
> > 
> > Cheers
> > Philipp
> > 
> > -------- Original-Nachricht --------
> > > Datum: Wed, 24 Aug 2011 07:22:53 -0700
> > > Von: "Christophe Coutand" <ccoutand@stmi.com>
> > > An: "Philipp Meier" <pme.neratec@gmx.ch>, "ecos discuss" <ecos-
> > discuss@ecos.sourceware.org>
> > > Betreff: RE: [ECOS] ecos-3.0 current stm32 bug?
> > 
> > > Both the bootloader and the application are ROM startup type?
> > >
> > > What about the address of the hal_vsr_table in the bootloader and
> > > application?
> > >
> > > Christophe
> > >
> > > > -----Original Message-----
> > > > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > > > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > > > Sent: 24. august 2011 16:11
> > > > To: ecos discuss
> > > > Subject: Re: [ECOS] ecos-3.0 current stm32 bug?
> > > >
> > > > -------- Original-Nachricht --------
> > > > > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> > > > > Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> > > > > An: Philipp Meier <pme.neratec@gmx.ch>
> > > > > CC: ecos-discuss@ecos.sourceware.org
> > > > > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?
> > > >
> > > > > On Wed, 24 Aug 2011, Philipp Meier wrote:
> > > > >
> > > > > > Hi all
> > > > > >
> > > > > > I have a firmware split into two parts:
> > > > > >  1. a "bootloader"
> > > > > >  2. a "application"
> > > > > >
> > > > > > I now need to move from Windows (cygwin) development
> > environment to
> > > > > > Linux development environment and at the same time use the
> > current
> > > > > > ecos version (i.e. what I get when I clone the ecos mercurial
> > > > > > repository) instead of the "original" (back in 2009) ecos-3.0
> > > > version.
> > > > > >
> > > > > > The situation is now as follows:
> > > > > >  1. I download (to my stm32 device) the Linux/ecos-current
> > built
> > > > > >  "bootloader"
> > > > > >  2. I download (to my stm32 device) the Linux/ecos-current
> > built
> > > > > >  "application"
> > > > > >  3. I start the application and in line 187 of file
> > > > > >  'hal/cortexm/arch/current/src/hal_msic.c' instead of branching
> > to
> > > > > >  'hal_switch_state_vsr' it branches to
> > 'hal_default_exception_vsr'
> > > > > >  function!
> > > > > >
> > > > > > To analyze the problem I then:
> > > > > >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0 built
> > > > > >  "bootloader"
> > > > > >  5. Still having the Linux/ecos-current built "application"
> > > > > >  6. And in line 187 (of the above mentioned file) it branches
> > (as
> > > > it
> > > > > >  should) to 'hal_switch_state_vsr' and the application is
> > starting
> > > > up
> > > > > >  and running fine!
> > > > > >
> > > > > > Who can give me a hint about
> > > > > >  * what has been changed in ecos-current cortexm stm32 that
> > could
> > > > > >  cause this problem
> > > > >
> > > > > Hi Philipp,
> > > > >
> > > > > I think you can use Mercurial for that
> > > > >
> > > > > % hg tags | grep v3
> > > > > ecos-v3_0-branchpoint           2821:b5a12bb6a634
> > > > >
> > > > > % hg log -r ecos-v3_0-branchpoint:tip packages/hal/cortexm/arch |
> > > > less
> > > > > -FRSX
> > > > >
> > > > > or (may be)
> > > > >
> > > > > % hg log --patch -r ecos-v3_0-branchpoint:tip \
> > > > > 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -
> > FRSX
> > > > >
> > > > > etc.
> > > > >
> > > > > >  * or what else I could analyze to find out why ecos-current
> > (built
> > > > on
> > > > > >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw); under
> > cygwin
> > > > I
> > > > > >  also used the arm-eabi-gcc version 4.3.2 pre-built by
> > eCosCentric)
> > > > >
> > > > > Also you would check the Linux build for ecos-3.0 codebase
> > > > >
> > > > > # get old (working) code
> > > > > % hg update ecos-v3_0-branchpoint
> > > > >
> > > > > Rebuild your loader and application under Linux and try it (use
> > fresh
> > > > > directories for builds). After all do not forget up-to-date eCos
> > HG
> > > > > repository (hg update default).
> > > > >
> > > > > Feel free to submit a bug report (if you'll find something) via
> > eCos
> > > > > Bugzilla System http://bugs.ecos.sourceware.org/
> > > > >
> > > > >
> > > > > Sergei
> > > > >
> > > > > > Regards
> > > > > > Philipp
> > > >
> > > > Hello Sergei and others
> > > >
> > > > Thanks a lot for your tips about how to find out the differences
> > > > between the versions.
> > > >
> > > > I now went a step back and built (under Linux) my "bootloader" and
> > my
> > > > "application" under Linux using the same ecos sources and
> > configuration
> > > > files as when I built them under Windows/cygwin.
> > > >
> > > > Therefore - I wanted to see if the problem comes from building
> > under
> > > > Linux, or from changes in the ecos stm32 parts (or any other ecos
> > > > parts).
> > > >
> > > > But - I have the same problem as described above; i.e. the problem
> > must
> > > > be somehow in my Linux toolchain?
> > > >
> > > > Therefore my question now is:
> > > > Can anybody give me some background information about how the
> > "__asm__
> > > > volatile( "swi" )" statement in line 188 of
> > > > packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line 187
> > in
> > > > packages/hal/cortexm/arch/current/src/hal_misc.c when using ecos-
> > > > current) is interpreted on stm32? What could be the reason that it
> > does
> > > > not jumps to "hal_switch_state_vsr" but instead jumps to
> > > > "hal_default_exception_vsr"?
> > > >
> > > > The lines where the different behaviour is look like this:
> > > > hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] =
> > > > (CYG_ADDRESS)hal_switch_state_vsr;
> > > >
> > > > __asm__ volatile( "swi" );
> > > >
> > > > ...
> > > >
> > > > In the good case these leads to a jump/branch to
> > hal_switch_state_vsr
> > > > and in the bad case it jumps/branches to hal_default_exception_vsr
> > and
> > > > therefore my application does not starts up.
> > > >
> > > > Thanks for any help.
> > > >
> > > > Philipp
> > > > --
> > > > P.S.: Sorry Sergei - I did not mean to reply directly to you but
> > like
> > > > this to the mailing list.
> > > > --
> > > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > > >
> > > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > > >
> > > > --
> > > > Before posting, please read the FAQ:
> > > > http://ecos.sourceware.org/fom/ecos
> > > > and search the list archive: http://ecos.sourceware.org/ml/ecos-
> > discuss
> > >
> > 
> > --
> > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > 
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > 
> > --
> > Before posting, please read the FAQ:
> > http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

Hello Sergei

% $(which arm-eabi-gcc) --version
arm-eabi-gcc (eCosCentrc GNU tools 4.3.2-sw) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.

This is the good version, isn't it?

ECOS_REPOSITORY
I have the problem with ecos-3.0 and with ecos-current version (I have both installed).

Cheers
Philipp

-------- Original-Nachricht --------
> Datum: Wed, 24 Aug 2011 21:54:35 +0300 (EEST)
> Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> An: Philipp Meier <pme.neratec@gmx.ch>
> CC: ecos discuss <ecos-discuss@ecos.sourceware.org>
> Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?

> On Wed, 24 Aug 2011, Philipp Meier wrote:
> 
> [snip]
> 
> > I now went a step back and built (under Linux) my "bootloader" and my
> > "application" under Linux using the same ecos sources and
> > configuration files as when I built them under Windows/cygwin.
> > 
> > Therefore - I wanted to see if the problem comes from building under
> > Linux, or from changes in the ecos stm32 parts (or any other ecos
> > parts).
> > 
> > But - I have the same problem as described above; i.e. the problem
> > must be somehow in my Linux toolchain?
> 
> In any case, ask. Maybe you have installed more arm-eabi toolchains,
> i.e. and from another vendor, e.g. from CodeSourcery, etc. Check it,
> please, check your PATH variable
> 
>   % which arm-eabi-gcc
>   % echo $PATH
>   % $(which arm-eabi-gcc) --version
> 
> also
> 
>   % echo $ECOS_REPOSITORY
>   % ecosconfig --version
> 
> also (you told about HG tree)
> 
>   % hg status -R $ECOS_REPOSITORY/..
> 
> It would be nice to be sure that you use the right tools.
> 
> 
> Sergei

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

On 08/24/2011 08:54 PM, Sergei Gavrikov wrote:
> On Wed, 24 Aug 2011, Philipp Meier wrote:
>
> [snip]
>
>> I now went a step back and built (under Linux) my "bootloader" and ...
>> must be somehow in my Linux toolchain?
> In any case, ask. Maybe you have installed more arm-eabi toolchains,
> i.e. and from another vendor, e.g. from CodeSourcery, etc. Check it,
> please, check your PATH variable
>
>    % which arm-eabi-gcc
>    % echo $PATH
>    % $(which arm-eabi-gcc) --version
arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
> also
>
>    % echo $ECOS_REPOSITORY
>    % ecosconfig --version
$ ecosconfig --version
ecosconfig 3.0 (Mar 27 2009 09:12:53)
Copyright (c) 2002-2009 Free Software Foundation, Inc.

When I am in the debugger I see the ecos-3.0 path 
(packages/hal/cortexm/arch/v3_0/src/hal_misc.c)
> also (you told about HG tree)
>
>    % hg status -R $ECOS_REPOSITORY/..
> It would be nice to be sure that you use the right tools.
Are these the right tools/versions?
>
> Sergei
>
Philipp


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: RE: RE: [ECOS] ecos-3.0 current stm32 bug?

[Christophe Coutand]

Try to word align hal_switch_state_vsr (currently you have 0x8040025) and see what happens. Also can you post the dissembled version to understand why hal_switch_state_vsr is placed like that.

Christophe

> -----Original Message-----
> From: Philipp Meier [mailto:pme.neratec@gmx.ch]
> Sent: 25. august 2011 10:49
> To: Christophe Coutand; ecos-discuss@ecos.sourceware.org
> Subject: Re: RE: RE: [ECOS] ecos-3.0 current stm32 bug?
> 
> Hello Christophe
> 
> it is the SWI instruction ("svc 0" in disassem code) that triggers the
> exception (therefore breakpoint in hal_switch_state_vsr is never
> reached).
> 
> Where does the SWI instruction get's it's information about where to
> jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I
> have 0x8040025 which is the address for hal_switch_state_vsr - and yet
> it does not jumps to 0x8040025 but instead to 0x8040042
> (hal_default_exception_vsr).
> 
> Any idea about the reason for this behaviour?
> 
> Cheers Philipp
> 
> -------- Original-Nachricht --------
> > Datum: Wed, 24 Aug 2011 09:40:02 -0700
> > Von: "Christophe Coutand" <ccoutand@stmi.com>
> > An: "Philipp Meier" <pme.neratec@gmx.ch>, ecos-
> discuss@ecos.sourceware.org
> > Betreff: RE: RE: [ECOS] ecos-3.0 current stm32 bug?
> 
> > What about setting a breakpoint in hal_switch_state_vsr? Is it the
> SWI
> > instruction that triggers the exception or is it the execution of the
> > hal_switch_state_vsr routine?
> >
> > Christophe
> >
> > > -----Original Message-----
> > > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > > Sent: 24. august 2011 16:58
> > > To: ecos-discuss@ecos.sourceware.org
> > > Subject: Re: RE: [ECOS] ecos-3.0 current stm32 bug?
> > >
> > > Hello Christophe,
> > >
> > > Yes - both are ROM startup type. The bootloader without offset
> (i.e.
> > > offset 0x0), the application with offset 0x40000.
> > >
> > > In the bootloader elf file hal_vsr_table is 20000000 and the same
> is
> > > true for the application.
> > >
> > > GDB debug output when debugging the startup of the application:
> > >
> > > Bad case (Linux built bootloader):
> > > ----------------------------------
> > > (gdb) print /fx hal_vsr_table
> > > $1 = {0x441c4c08, 0x61232301, 0x8040043, 0x8040043, 0x8040043,
> > > 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
> > >   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> > > <repeats 61 times>}
> > > (gdb) print /fx &hal_vsr_table
> > > $2 = 0x20000000
> > >
> > > Good case (Cygwin built bootloader):
> > > ----------------------------------
> > > (gdb) print /fx hal_vsr_table
> > > $1 = {0x4024f8df, 0xf04f4d09, 0x8040043, 0x8040043, 0x8040043,
> > > 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
> > >   0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
> > > <repeats 61 times>}
> > > (gdb) print /fx &hal_vsr_table
> > > $2 = 0x20000000
> > >
> > > Cheers
> > > Philipp
> > >
> > > -------- Original-Nachricht --------
> > > > Datum: Wed, 24 Aug 2011 07:22:53 -0700
> > > > Von: "Christophe Coutand" <ccoutand@stmi.com>
> > > > An: "Philipp Meier" <pme.neratec@gmx.ch>, "ecos discuss" <ecos-
> > > discuss@ecos.sourceware.org>
> > > > Betreff: RE: [ECOS] ecos-3.0 current stm32 bug?
> > >
> > > > Both the bootloader and the application are ROM startup type?
> > > >
> > > > What about the address of the hal_vsr_table in the bootloader and
> > > > application?
> > > >
> > > > Christophe
> > > >
> > > > > -----Original Message-----
> > > > > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-
> discuss-
> > > > > owner@ecos.sourceware.org] On Behalf Of Philipp Meier
> > > > > Sent: 24. august 2011 16:11
> > > > > To: ecos discuss
> > > > > Subject: Re: [ECOS] ecos-3.0 current stm32 bug?
> > > > >
> > > > > -------- Original-Nachricht --------
> > > > > > Datum: Wed, 24 Aug 2011 14:35:15 +0300 (EEST)
> > > > > > Von: Sergei Gavrikov <sergei.gavrikov@gmail.com>
> > > > > > An: Philipp Meier <pme.neratec@gmx.ch>
> > > > > > CC: ecos-discuss@ecos.sourceware.org
> > > > > > Betreff: Re: [ECOS] ecos-3.0 current stm32 bug?
> > > > >
> > > > > > On Wed, 24 Aug 2011, Philipp Meier wrote:
> > > > > >
> > > > > > > Hi all
> > > > > > >
> > > > > > > I have a firmware split into two parts:
> > > > > > >  1. a "bootloader"
> > > > > > >  2. a "application"
> > > > > > >
> > > > > > > I now need to move from Windows (cygwin) development
> > > environment to
> > > > > > > Linux development environment and at the same time use the
> > > current
> > > > > > > ecos version (i.e. what I get when I clone the ecos
> mercurial
> > > > > > > repository) instead of the "original" (back in 2009) ecos-
> 3.0
> > > > > version.
> > > > > > >
> > > > > > > The situation is now as follows:
> > > > > > >  1. I download (to my stm32 device) the Linux/ecos-current
> > > built
> > > > > > >  "bootloader"
> > > > > > >  2. I download (to my stm32 device) the Linux/ecos-current
> > > built
> > > > > > >  "application"
> > > > > > >  3. I start the application and in line 187 of file
> > > > > > >  'hal/cortexm/arch/current/src/hal_msic.c' instead of
> branching
> > > to
> > > > > > >  'hal_switch_state_vsr' it branches to
> > > 'hal_default_exception_vsr'
> > > > > > >  function!
> > > > > > >
> > > > > > > To analyze the problem I then:
> > > > > > >  4. Downloaded (to my stm32 device) the cyginw/ecos-3.0
> built
> > > > > > >  "bootloader"
> > > > > > >  5. Still having the Linux/ecos-current built "application"
> > > > > > >  6. And in line 187 (of the above mentioned file) it
> branches
> > > (as
> > > > > it
> > > > > > >  should) to 'hal_switch_state_vsr' and the application is
> > > starting
> > > > > up
> > > > > > >  and running fine!
> > > > > > >
> > > > > > > Who can give me a hint about
> > > > > > >  * what has been changed in ecos-current cortexm stm32 that
> > > could
> > > > > > >  cause this problem
> > > > > >
> > > > > > Hi Philipp,
> > > > > >
> > > > > > I think you can use Mercurial for that
> > > > > >
> > > > > > % hg tags | grep v3
> > > > > > ecos-v3_0-branchpoint           2821:b5a12bb6a634
> > > > > >
> > > > > > % hg log -r ecos-v3_0-branchpoint:tip
> packages/hal/cortexm/arch |
> > > > > less
> > > > > > -FRSX
> > > > > >
> > > > > > or (may be)
> > > > > >
> > > > > > % hg log --patch -r ecos-v3_0-branchpoint:tip \
> > > > > > 	packages/hal/cortexm/arch/current/src/hal_misc.c | less -
> > > FRSX
> > > > > >
> > > > > > etc.
> > > > > >
> > > > > > >  * or what else I could analyze to find out why ecos-
> current
> > > (built
> > > > > on
> > > > > > >  Linux, arm-eabi-gcc (eCosCentric GNU tools 4.3.2-sw);
> under
> > > cygwin
> > > > > I
> > > > > > >  also used the arm-eabi-gcc version 4.3.2 pre-built by
> > > eCosCentric)
> > > > > >
> > > > > > Also you would check the Linux build for ecos-3.0 codebase
> > > > > >
> > > > > > # get old (working) code
> > > > > > % hg update ecos-v3_0-branchpoint
> > > > > >
> > > > > > Rebuild your loader and application under Linux and try it
> (use
> > > fresh
> > > > > > directories for builds). After all do not forget up-to-date
> eCos
> > > HG
> > > > > > repository (hg update default).
> > > > > >
> > > > > > Feel free to submit a bug report (if you'll find something)
> via
> > > eCos
> > > > > > Bugzilla System http://bugs.ecos.sourceware.org/
> > > > > >
> > > > > >
> > > > > > Sergei
> > > > > >
> > > > > > > Regards
> > > > > > > Philipp
> > > > >
> > > > > Hello Sergei and others
> > > > >
> > > > > Thanks a lot for your tips about how to find out the
> differences
> > > > > between the versions.
> > > > >
> > > > > I now went a step back and built (under Linux) my "bootloader"
> and
> > > my
> > > > > "application" under Linux using the same ecos sources and
> > > configuration
> > > > > files as when I built them under Windows/cygwin.
> > > > >
> > > > > Therefore - I wanted to see if the problem comes from building
> > > under
> > > > > Linux, or from changes in the ecos stm32 parts (or any other
> ecos
> > > > > parts).
> > > > >
> > > > > But - I have the same problem as described above; i.e. the
> problem
> > > must
> > > > > be somehow in my Linux toolchain?
> > > > >
> > > > > Therefore my question now is:
> > > > > Can anybody give me some background information about how the
> > > "__asm__
> > > > > volatile( "swi" )" statement in line 188 of
> > > > > packages/hal/cortexm/arch/v3_0/src/hal_misc.c (or "swi 0" line
> 187
> > > in
> > > > > packages/hal/cortexm/arch/current/src/hal_misc.c when using
> ecos-
> > > > > current) is interpreted on stm32? What could be the reason that
> it
> > > does
> > > > > not jumps to "hal_switch_state_vsr" but instead jumps to
> > > > > "hal_default_exception_vsr"?
> > > > >
> > > > > The lines where the different behaviour is look like this:
> > > > > hal_vsr_table[CYGNUM_HAL_VECTOR_SERVICE] =
> > > > > (CYG_ADDRESS)hal_switch_state_vsr;
> > > > >
> > > > > __asm__ volatile( "swi" );
> > > > >
> > > > > ...
> > > > >
> > > > > In the good case these leads to a jump/branch to
> > > hal_switch_state_vsr
> > > > > and in the bad case it jumps/branches to
> hal_default_exception_vsr
> > > and
> > > > > therefore my application does not starts up.
> > > > >
> > > > > Thanks for any help.
> > > > >
> > > > > Philipp
> > > > > --
> > > > > P.S.: Sorry Sergei - I did not mean to reply directly to you
> but
> > > like
> > > > > this to the mailing list.
> > > > > --
> > > > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-
> Garantie!
> > > > >
> > > > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > > > >
> > > > > --
> > > > > Before posting, please read the FAQ:
> > > > > http://ecos.sourceware.org/fom/ecos
> > > > > and search the list archive:
> http://ecos.sourceware.org/ml/ecos-
> > > discuss
> > > >
> > >
> > > --
> > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> > >
> > > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > >
> > > --
> > > Before posting, please read the FAQ:
> > > http://ecos.sourceware.org/fom/ecos
> > > and search the list archive: http://ecos.sourceware.org/ml/ecos-
> discuss
> >
> 
> --
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
> 
> Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

0x8040025 is only the entry in the hal_vsr_table[11] (seems to always be 
the real address + 1). I.e.

(gdb) print /fx hal_vsr_table[11]
$6 = 0x8040025
(gdb) print hal_switch_state_vsr
$4 = {<text variable, no debug info>} 0x8040024 <hal_switch_state_vsr>

Philipp

On 08/25/2011 11:33 AM, Christophe Coutand wrote:
> Try to word align hal_switch_state_vsr (currently you have 0x8040025) and see what happens. Also can you post the dissembled version to understand why hal_switch_state_vsr is placed like that.
>
> Christophe
>
>> -----Original Message-----
>> From: Philipp Meier [mailto:pme.neratec@gmx.ch]
>> Sent: 25. august 2011 10:49
>> To: Christophe Coutand; ecos-discuss@ecos.sourceware.org
>> Subject: Re: RE: RE: [ECOS] ecos-3.0 current stm32 bug?
>>
>> Hello Christophe
>>
>> it is the SWI instruction ("svc 0" in disassem code) that triggers the
>> exception (therefore breakpoint in hal_switch_state_vsr is never
>> reached).
>>
>> Where does the SWI instruction get's it's information about where to
>> jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I
>> have 0x8040025 which is the address for hal_switch_state_vsr - and yet
>> it does not jumps to 0x8040025 but instead to 0x8040042
>> (hal_default_exception_vsr).
>>
>> Any idea about the reason for this behaviour?
>>
>> Cheers Philipp
>>
>> -------- Original-Nachricht --------
>>> Datum: Wed, 24 Aug 2011 09:40:02 -0700
>>> Von: "Christophe Coutand"<ccoutand@stmi.com>
>>> An: "Philipp Meier"<pme.neratec@gmx.ch>, ecos-
>> discuss@ecos.sourceware.org
>>> Betreff: RE: RE: [ECOS] ecos-3.0 current stm32 bug?
>>> What about setting a breakpoint in hal_switch_state_vsr? Is it the
>> SWI
>>> instruction that triggers the exception or is it the execution of the
>>> hal_switch_state_vsr routine?
>>>
>>> Christophe
>>>
>>>> -----Original Message-----
>>>> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
>>>> owner@ecos.sourceware.org] On Behalf Of Philipp Meier
>>>> Sent: 24. august 2011 16:58
>>>> To: ecos-discuss@ecos.sourceware.org
>>>> Subject: Re: RE: [ECOS] ecos-3.0 current stm32 bug?
>>>>
>>>> Hello Christophe,
>>>>
>>>> Yes - both are ROM startup type. The bootloader without offset
>> (i.e.
>>>> offset 0x0), the application with offset 0x40000.
>>>>
>>>> In the bootloader elf file hal_vsr_table is 20000000 and the same
>> is
>>>> true for the application.
>>>>
>>>> GDB debug output when debugging the startup of the application:
>>>>
>>>> Bad case (Linux built bootloader):
>>>> ----------------------------------
>>>> (gdb) print /fx hal_vsr_table
>>>> $1 = {0x441c4c08, 0x61232301, 0x8040043, 0x8040043, 0x8040043,
>>>> 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
>>>>    0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
>>>> <repeats 61 times>}
>>>> (gdb) print /fx&hal_vsr_table
>>>> $2 = 0x20000000
>>>>
>>>> Good case (Cygwin built bootloader):
>>>> ----------------------------------
>>>> (gdb) print /fx hal_vsr_table
>>>> $1 = {0x4024f8df, 0xf04f4d09, 0x8040043, 0x8040043, 0x8040043,
>>>> 0x8040043, 0x8040043, 0x8040043, 0x8040043, 0x8040043,
>>>>    0x8040043, 0x8040025, 0x8040043, 0x8040043, 0x8040089, 0x8040075
>>>> <repeats 61 times>}
>>>> (gdb) print /fx&hal_vsr_table
>>>> $2 = 0x20000000
>>>>
>>>> Cheers
>>>> Philipp
>>>>
>>>> -------- Original-Nachricht --------
>>>>> Datum: Wed, 24 Aug 2011 07:22:53 -0700
>>>>> Von: "Christophe Coutand"<ccoutand@stmi.com>
>>>>> An: "Philipp Meier"<pme.neratec@gmx.ch>, "ecos discuss"<ecos-
>>>> ...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Nick Garnett]

On 25/08/11 09:48, Philipp Meier wrote:
> Hello Christophe
> 
> it is the SWI instruction ("svc 0" in disassem code) that triggers the exception (therefore breakpoint in hal_switch_state_vsr is never reached).
> 
> Where does the SWI instruction get's it's information about where to jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I have 0x8040025 which is the address for hal_switch_state_vsr - and yet it does not jumps to 0x8040025 but instead to 0x8040042 (hal_default_exception_vsr).
> 
> Any idea about the reason for this behaviour?

The SWI is probably causing the CPU to take a HardFault exception
because BASEPRI is higher than the priority of the SWI exception.

If I understand correctly, both your bootloader and application are
configured for ROM startup. The ROM startup code in hal_misc.c expects
to find the CPU in its initial state. When your application runs, the
bootloader has already run this code and put it into a different state,
which will then cause the SWI to throw a HardFault.

For your application you really need a new startup type that does the
RAM initialization parts of a ROM startup, but omits parts of the
hardware initialization.


-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

On 08/25/2011 12:37 PM, Nick Garnett wrote:
> On 25/08/11 09:48, Philipp Meier wrote:
>> Hello Christophe
>>
>> it is the SWI instruction ("svc 0" in disassem code) that triggers the exception (therefore breakpoint in hal_switch_state_vsr is never reached).
>>
>> Where does the SWI instruction get's it's information about where to jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I have 0x8040025 which is the address for hal_switch_state_vsr - and yet it does not jumps to 0x8040025 but instead to 0x8040042 (hal_default_exception_vsr).
>>
>> Any idea about the reason for this behaviour?
> The SWI is probably causing the CPU to take a HardFault exception
> because BASEPRI is higher than the priority of the SWI exception.
>
> If I understand correctly, both your bootloader and application are
> configured for ROM startup. The ROM startup code in hal_misc.c expects
> to find the CPU in its initial state. When your application runs, the
> bootloader has already run this code and put it into a different state,
> which will then cause the SWI to throw a HardFault.
>
> For your application you really need a new startup type that does the
> RAM initialization parts of a ROM startup, but omits parts of the
> hardware initialization.
>
>
Sound logic but:
Why would the code built under cygwin run (same architecture with 
bootloader and application) but not work when built under Linux? On both 
OS I use the same version of the arm-eabi tools. On both OS I use the 
same ecos library (ecos-3.0) and the same source code for 
bootloader/application.

Any idea about what would make the difference?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Nick Garnett]

> Sound logic but:
> Why would the code built under cygwin run (same architecture with 
> bootloader and application) but not work when built under Linux? On both 
> OS I use the same version of the arm-eabi tools. On both OS I use the 
> same ecos library (ecos-3.0) and the same source code for 
> bootloader/application.
> 
> Any idea about what would make the difference?

That is less easy to answer.

In theory your builds should produce similar, if not identical,
executables. Certainly as far as the initialization code is concerned.

Something you could try is to use arm-eabi-objdump with the -d option to
disassemble the ELF files. Then compare the resulting outputs, even run
them through diff. Any differences between the files might give a clue
as to what is going wrong. Concentrate in particular on hal_reset_vsr,
since this is the most likely site of any problem.



-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

On 08/25/2011 12:37 PM, Nick Garnett wrote:
> On 25/08/11 09:48, Philipp Meier wrote:
>> Hello Christophe
>>
>> it is the SWI instruction ("svc 0" in disassem code) that triggers the exception (therefore breakpoint in hal_switch_state_vsr is never reached).
>>
>> Where does the SWI instruction get's it's information about where to jump to? Is it the hal_vsr_table (located at 0x20000000)? In entry 11 I have 0x8040025 which is the address for hal_switch_state_vsr - and yet it does not jumps to 0x8040025 but instead to 0x8040042 (hal_default_exception_vsr).
>>
>> Any idea about the reason for this behaviour?
> The SWI is probably causing the CPU to take a HardFault exception
> because BASEPRI is higher than the priority of the SWI exception.
>
> If I understand correctly, both your bootloader and application are
> configured for ROM startup. The ROM startup code in hal_misc.c expects
> to find the CPU in its initial state. When your application runs, the
> bootloader has already run this code and put it into a different state,
> which will then cause the SWI to throw a HardFault.
>
> For your application you really need a new startup type that does the
> RAM initialization parts of a ROM startup, but omits parts of the
> hardware initialization.
>
>
Yes you are right - that's the case.

With the bootloader built under Windows/Cygwin, basepri (mon reg 
basepri) is 0x00 when my application's hal_reset_vsr function is reached.
When I build the bootloader  (using the same ecos-library version/code 
and the same bootloader source code) under Linux, then basepri is 0x10 
when my application's hal_reset_vsr function is reached.

Why this difference between Cygwin and Linux?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Nick Garnett]

On 25/08/11 13:13, Philipp Meier wrote:

> 
> With the bootloader built under Windows/Cygwin, basepri (mon reg 
> basepri) is 0x00 when my application's hal_reset_vsr function is reached.
> When I build the bootloader  (using the same ecos-library version/code 
> and the same bootloader source code) under Linux, then basepri is 0x10 
> when my application's hal_reset_vsr function is reached.
> 
> Why this difference between Cygwin and Linux?

In theory BASEPRI should have been set to 0x10 by both bootloaders by
the time the application starts running. That the Windows-built
bootloader has not done that is unexpected. It looks like the actual bug
is in the Windows build. The Linux build is doing what I would expect.
So it looks like you have been fortunate not to trip over this issue
earlier.

The comparison of the executables that I mentioned earlier should help.
It looks like only the bootloaders may need comparing.


-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Philipp Meier]

On 08/25/2011 02:31 PM, Nick Garnett wrote:
> On 25/08/11 13:13, Philipp Meier wrote:
>
>> With the bootloader built under Windows/Cygwin, basepri (mon reg
>> basepri) is 0x00 when my application's hal_reset_vsr function is reached.
>> When I build the bootloader  (using the same ecos-library version/code
>> and the same bootloader source code) under Linux, then basepri is 0x10
>> when my application's hal_reset_vsr function is reached.
>>
>> Why this difference between Cygwin and Linux?
> In theory BASEPRI should have been set to 0x10 by both bootloaders by
> the time the application starts running. That the Windows-built
> bootloader has not done that is unexpected. It looks like the actual bug
> is in the Windows build. The Linux build is doing what I would expect.
> So it looks like you have been fortunate not to trip over this issue
> earlier.
>
> The comparison of the executables that I mentioned earlier should help.
> It looks like only the bootloaders may need comparing.
>
>
Thank's a lot. This is exactly the case!

There has been a bug in HAL_DISABLE_INTERRUPTS (hal_intr.h) - corrected 
with "changeset:   3009:9ba76199bff2" (Mercurial): Bugzilla 1001154

This bug "helped" as so that our bootloader was working until now.

I validated this by "re-implementing" the disable interrupt bug on my 
Linux box (just have to change the hal_intr.h file in the ecos library) 
- and with this faulty version my application starts up as with the 
cygwin built bootloader.

On my Windows/Cygwin box I manually corrected this bug in the ecos 
source code (at that moment I could not change to ecos-current) - but 
for my bootloader I did not re-build the ecos library. And therefore my 
Windows/Cygwin built bootloader still has the HAL_DISABLE_INTERRUPTS bug 
which makes our code to run.

Thank you all for your good ideas - I now know where I have to change my 
implementation.

Regards
Philipp

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos-3.0 current stm32 bug?

[Nick Garnett]

On 25/08/11 13:51, Philipp Meier wrote:

> Thank's a lot. This is exactly the case!
> 
> There has been a bug in HAL_DISABLE_INTERRUPTS (hal_intr.h) - corrected 
> with "changeset:   3009:9ba76199bff2" (Mercurial): Bugzilla 1001154
> 
> This bug "helped" as so that our bootloader was working until now.
> 
> I validated this by "re-implementing" the disable interrupt bug on my 
> Linux box (just have to change the hal_intr.h file in the ecos library) 
> - and with this faulty version my application starts up as with the 
> cygwin built bootloader.
> 
> On my Windows/Cygwin box I manually corrected this bug in the ecos 
> source code (at that moment I could not change to ecos-current) - but 
> for my bootloader I did not re-build the ecos library. And therefore my 
> Windows/Cygwin built bootloader still has the HAL_DISABLE_INTERRUPTS bug 
> which makes our code to run.
> 
> Thank you all for your good ideas - I now know where I have to change my 
> implementation.

Glad to hear it.

While the "correct" approach is to introduce the extra startup type I
mentioned earlier, you could probably make things work by enabling
interrupts in your bootloader before transferring control to the
application. You would need to ensure that no interrupts actually get
delivered by masking any that are enabled, including the SysTick timer.
Enabling interrupts sets BASEPRI to zero, which should allow the SWI to
avoid the condition that caused the HardFault.

[I've not thought this through in any detail, and it might not work for
other reasons, but it is worth a try.]



-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss