* [ECOS] ecos-3.0 current stm32 bug? @ 2011-08-24 10:34 Philipp Meier 2011-08-24 11:35 ` Sergei Gavrikov 0 siblings, 1 reply; 19+ messages in thread From: Philipp Meier @ 2011-08-24 10:34 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 10:34 [ECOS] ecos-3.0 current stm32 bug? Philipp Meier @ 2011-08-24 11:35 ` Sergei Gavrikov 2011-08-24 14:11 ` Philipp Meier 0 siblings, 1 reply; 19+ messages in thread From: Sergei Gavrikov @ 2011-08-24 11:35 UTC (permalink / raw) To: Philipp Meier; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 11:35 ` Sergei Gavrikov @ 2011-08-24 14:11 ` Philipp Meier 2011-08-24 14:26 ` Christophe Coutand 2011-08-24 18:54 ` Sergei Gavrikov 0 siblings, 2 replies; 19+ messages in thread From: Philipp Meier @ 2011-08-24 14:11 UTC (permalink / raw) To: ecos discuss -------- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 14:11 ` Philipp Meier @ 2011-08-24 14:26 ` Christophe Coutand 2011-08-24 14:58 ` Philipp Meier 2011-08-24 18:54 ` Sergei Gavrikov 1 sibling, 1 reply; 19+ messages in thread From: Christophe Coutand @ 2011-08-24 14:26 UTC (permalink / raw) To: Philipp Meier, ecos discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: RE: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 14:26 ` Christophe Coutand @ 2011-08-24 14:58 ` Philipp Meier 2011-08-24 16:44 ` Christophe Coutand 0 siblings, 1 reply; 19+ messages in thread From: Philipp Meier @ 2011-08-24 14:58 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: RE: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 14:58 ` Philipp Meier @ 2011-08-24 16:44 ` Christophe Coutand 2011-08-25 8:49 ` Philipp Meier 0 siblings, 1 reply; 19+ messages in thread From: Christophe Coutand @ 2011-08-24 16:44 UTC (permalink / raw) To: Philipp Meier, ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: RE: RE: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 16:44 ` Christophe Coutand @ 2011-08-25 8:49 ` Philipp Meier 2011-08-25 9:37 ` Christophe Coutand 2011-08-25 10:38 ` Nick Garnett 0 siblings, 2 replies; 19+ messages in thread From: Philipp Meier @ 2011-08-25 8:49 UTC (permalink / raw) To: Christophe Coutand, ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: RE: RE: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 8:49 ` Philipp Meier @ 2011-08-25 9:37 ` Christophe Coutand 2011-08-25 10:01 ` Philipp Meier 2011-08-25 10:38 ` Nick Garnett 1 sibling, 1 reply; 19+ messages in thread From: Christophe Coutand @ 2011-08-25 9:37 UTC (permalink / raw) To: Philipp Meier, ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 9:37 ` Christophe Coutand @ 2011-08-25 10:01 ` Philipp Meier 0 siblings, 0 replies; 19+ messages in thread From: Philipp Meier @ 2011-08-25 10:01 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 8:49 ` Philipp Meier 2011-08-25 9:37 ` Christophe Coutand @ 2011-08-25 10:38 ` Nick Garnett 2011-08-25 11:25 ` Philipp Meier 2011-08-25 12:13 ` Philipp Meier 1 sibling, 2 replies; 19+ messages in thread From: Nick Garnett @ 2011-08-25 10:38 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 10:38 ` Nick Garnett @ 2011-08-25 11:25 ` Philipp Meier 2011-08-25 12:12 ` Nick Garnett 2011-08-25 12:13 ` Philipp Meier 1 sibling, 1 reply; 19+ messages in thread From: Philipp Meier @ 2011-08-25 11:25 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 11:25 ` Philipp Meier @ 2011-08-25 12:12 ` Nick Garnett 0 siblings, 0 replies; 19+ messages in thread From: Nick Garnett @ 2011-08-25 12:12 UTC (permalink / raw) To: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 10:38 ` Nick Garnett 2011-08-25 11:25 ` Philipp Meier @ 2011-08-25 12:13 ` Philipp Meier 2011-08-25 12:31 ` Nick Garnett 1 sibling, 1 reply; 19+ messages in thread From: Philipp Meier @ 2011-08-25 12:13 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 12:13 ` Philipp Meier @ 2011-08-25 12:31 ` Nick Garnett 2011-08-25 12:52 ` Philipp Meier 0 siblings, 1 reply; 19+ messages in thread From: Nick Garnett @ 2011-08-25 12:31 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 12:31 ` Nick Garnett @ 2011-08-25 12:52 ` Philipp Meier 2011-08-25 13:46 ` Nick Garnett 0 siblings, 1 reply; 19+ messages in thread From: Philipp Meier @ 2011-08-25 12:52 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-25 12:52 ` Philipp Meier @ 2011-08-25 13:46 ` Nick Garnett 0 siblings, 0 replies; 19+ messages in thread From: Nick Garnett @ 2011-08-25 13:46 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 14:11 ` Philipp Meier 2011-08-24 14:26 ` Christophe Coutand @ 2011-08-24 18:54 ` Sergei Gavrikov 2011-08-25 8:54 ` Philipp Meier 2011-08-25 9:07 ` Philipp Meier 1 sibling, 2 replies; 19+ messages in thread From: Sergei Gavrikov @ 2011-08-24 18:54 UTC (permalink / raw) To: Philipp Meier; +Cc: ecos discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 18:54 ` Sergei Gavrikov @ 2011-08-25 8:54 ` Philipp Meier 2011-08-25 9:07 ` Philipp Meier 1 sibling, 0 replies; 19+ messages in thread From: Philipp Meier @ 2011-08-25 8:54 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [ECOS] ecos-3.0 current stm32 bug? 2011-08-24 18:54 ` Sergei Gavrikov 2011-08-25 8:54 ` Philipp Meier @ 2011-08-25 9:07 ` Philipp Meier 1 sibling, 0 replies; 19+ messages in thread From: Philipp Meier @ 2011-08-25 9:07 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-08-25 13:46 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-24 10:34 [ECOS] ecos-3.0 current stm32 bug? Philipp Meier 2011-08-24 11:35 ` Sergei Gavrikov 2011-08-24 14:11 ` Philipp Meier 2011-08-24 14:26 ` Christophe Coutand 2011-08-24 14:58 ` Philipp Meier 2011-08-24 16:44 ` Christophe Coutand 2011-08-25 8:49 ` Philipp Meier 2011-08-25 9:37 ` Christophe Coutand 2011-08-25 10:01 ` Philipp Meier 2011-08-25 10:38 ` Nick Garnett 2011-08-25 11:25 ` Philipp Meier 2011-08-25 12:12 ` Nick Garnett 2011-08-25 12:13 ` Philipp Meier 2011-08-25 12:31 ` Nick Garnett 2011-08-25 12:52 ` Philipp Meier 2011-08-25 13:46 ` Nick Garnett 2011-08-24 18:54 ` Sergei Gavrikov 2011-08-25 8:54 ` Philipp Meier 2011-08-25 9:07 ` Philipp Meier
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).