public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Fwd: STM32 ROMINT don't run
       [not found] <CACra8jX5=y1-7iRktxuvK11T8zTNBPfR38=5b57PK2EJNbQ1nA@mail.gmail.com>
@ 2014-01-22 17:24 ` Samuel Charnet
  2014-01-23 17:06   ` [ECOS] " John Dallaway
  0 siblings, 1 reply; 8+ messages in thread
From: Samuel Charnet @ 2014-01-22 17:24 UTC (permalink / raw)
  To: ecos-discuss

Hi,

I want to try the ecos OS. My board come from waveshare, it is based
on stm32f407ig core ( http://www.wvshare.com/product/EVK407I.htm )

After some days I have ecos from CVS compiled. With the configtool I
have created my library with the stm3240 template and i have modified
the startup type to ROMINT

I have a simple thread which blink a led. I can upload the binary file
to the stm32 (i use the last openocd from source and olimex
arm-usb-ocd-h jtag device)

Unfortunately the led don't blink. With gdb i can't break on any
function and the stack seems broken.

The objdump seems ok but i am not a veteran with embeded developpment.

Could you give me some hints, i do not know where to search.. thanks in advance.

This is a gdb output :

(gdb) b cyg_user_start
Breakpoint 1 at 0x80001a2: file plsee.c, line 151.
(gdb) target remote :3333
Remote debugging using :3333
hal_reset_vsr () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/hal_misc.c:132
132    {
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
stm32f4x.cpu -- clearing lockup after double fault

Program received signal SIGINT, Interrupt.
0x00000000 in ?? ()

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-22 17:24 ` [ECOS] Fwd: STM32 ROMINT don't run Samuel Charnet
@ 2014-01-23 17:06   ` John Dallaway
  2014-01-23 18:02     ` Samuel Charnet
  0 siblings, 1 reply; 8+ messages in thread
From: John Dallaway @ 2014-01-23 17:06 UTC (permalink / raw)
  To: Samuel Charnet; +Cc: ecos-discuss

Hi Samuel

On 22/01/14 17:24, Samuel Charnet wrote:

> I want to try the ecos OS. My board come from waveshare, it is based
> on stm32f407ig core ( http://www.wvshare.com/product/EVK407I.htm )
> 
> After some days I have ecos from CVS compiled. With the configtool I
> have created my library with the stm3240 template and i have modified
> the startup type to ROMINT
> 
> I have a simple thread which blink a led. I can upload the binary file
> to the stm32 (i use the last openocd from source and olimex
> arm-usb-ocd-h jtag device)
> 
> Unfortunately the led don't blink. With gdb i can't break on any
> function and the stack seems broken.

You may be observing the following issue:

    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864

Try modifying hal/cortexm/arch/current/src/hal_misc.c to read as follows:

> #if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMINT)
> // Relocate data from ROM to RAM

Does that resolve the issue for you?

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-23 17:06   ` [ECOS] " John Dallaway
@ 2014-01-23 18:02     ` Samuel Charnet
  2014-01-24  8:57       ` John Dallaway
  0 siblings, 1 reply; 8+ messages in thread
From: Samuel Charnet @ 2014-01-23 18:02 UTC (permalink / raw)
  To: ecos-discuss; +Cc: John Dallaway

Hi John,

> You may be observing the following issue:
>
>     http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864
>
> Try modifying hal/cortexm/arch/current/src/hal_misc.c to read as follows:
>
>> #if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMINT)
>> // Relocate data from ROM to RAM
>
> Does that resolve the issue for you?
>
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john

Thanks for your quick answer.

I had a hope but it is not enought, it still doesn't run.

the stack is different :

(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
stm32f4x.cpu -- clearing lockup after double fault
Program received signal SIGINT, Interrupt.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x08001d3c in Cyg_Exception_Control::deliver_exception
(this=<optimized out>, exception_number=<optimized out>,
exception_info=<optimized out>)
    at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx:234
#2  0x0800005e in hal_default_exception_vsr () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
#3  0x0800005e in hal_default_exception_vsr () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-23 18:02     ` Samuel Charnet
@ 2014-01-24  8:57       ` John Dallaway
  2014-01-24 11:19         ` Samuel Charnet
  2014-01-25 11:07         ` Samuel Charnet
  0 siblings, 2 replies; 8+ messages in thread
From: John Dallaway @ 2014-01-24  8:57 UTC (permalink / raw)
  To: Samuel Charnet; +Cc: eCos Discussion

Hi Samuel

On 23/01/14 18:02, Samuel Charnet wrote:

> John Dallaway wrote:
>
>> You may be observing the following issue:
>>
>>     http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001864
>>
>> Try modifying hal/cortexm/arch/current/src/hal_misc.c to read as follows:
>>
>>> #if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMINT)
>>> // Relocate data from ROM to RAM
> 
> Thanks for your quick answer.
> 
> I had a hope but it is not enought, it still doesn't run.
> 
> the stack is different :
> 
> (gdb) target remote :3333
> Remote debugging using :3333
> 0x00000000 in ?? ()
> (gdb) c
> Continuing.
> Note: automatically using hardware breakpoints for read-only addresses.
> stm32f4x.cpu -- clearing lockup after double fault
> Program received signal SIGINT, Interrupt.
> 0x00000000 in ?? ()
> (gdb) where
> #0  0x00000000 in ?? ()
> #1  0x08001d3c in Cyg_Exception_Control::deliver_exception
> (this=<optimized out>, exception_number=<optimized out>,
> exception_info=<optimized out>)
>     at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx:234
> #2  0x0800005e in hal_default_exception_vsr () at
> /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
> #3  0x0800005e in hal_default_exception_vsr () at
> /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

If you have not already done so, disable compiler optimisation by
removing "-O2" from the CYGBLD_GLOBAL_CFLAGS option. Also enable
CYGPKG_INFRA_DEBUG. You should then be able to step into your code from
system reset and see where the exception is triggered.

Note that STM3240G-EVAL ROMINT startup is similar to STM32F4-Discovery
ROM startup which is working fine. So I don't think there is a major
problem here. Check all references to "CYG_HAL_STARTUP == ROM" and
"CYG_HAL_STARTUP_ROM". Modify these expressions if the code they control
is also relevant for ROMINT startup.

Good luck with your debugging...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-24  8:57       ` John Dallaway
@ 2014-01-24 11:19         ` Samuel Charnet
  2014-01-25 11:07         ` Samuel Charnet
  1 sibling, 0 replies; 8+ messages in thread
From: Samuel Charnet @ 2014-01-24 11:19 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Discussion

First, thanks for help, ecos is a complex piece of code ^^

I have already try stm32discovery template but i have another problem,
my jtag device hang with this one. I have set assert and ROM option,
default template, this is the result with gdb :

(gdb) target remote :3333
Remote debugging using :3333
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Remote communication error.  Target disconnected.: Connexion
ré-initialisée par le correspondant.
(gdb) q

OpenOCD complain too :

wrote 49152 bytes from file plsee.bin in 2.094767s (22.914 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020,
part: 0x6413, ver: 0x0)
Warn : Invalid ACK 0 in JTAG-DP transaction

>
> Note that STM3240G-EVAL ROMINT startup is similar to STM32F4-Discovery
> ROM startup which is working fine. So I don't think there is a major
> problem here. Check all references to "CYG_HAL_STARTUP == ROM" and
> "CYG_HAL_STARTUP_ROM". Modify these expressions if the code they control
> is also relevant for ROMINT startup.
>

I add another CYG_HAL_STARTUP_ROMINT in var_io.h, i think there is no more.

This is the stack with stm3240 template, the exception is broken ?

(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
stm32f4x.cpu -- clearing lockup after double fault

Program received signal SIGINT, Interrupt.
0x08001be2 in diag_write_long_num (n=65535, base=16, sign=43,
pfzero=0, width=0) at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/diag.cxx:189
189            cyg_ucount8 d = n % base;
(gdb) wher
#0  0x08001be2 in diag_write_long_num (n=65535, base=16, sign=43,
pfzero=0, width=0) at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/diag.cxx:189
#1  0x08001cd6 in diag_write_num (n=65535, base=16, sign=43, pfzero=0,
width=0) at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/diag.cxx:218
#2  0x08001b4c in diag_write_hex (n=65535) at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/diag.cxx:157
#3  0x08002c72 in write_thread_id () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/tcdiag.cxx:132
#4  0x08002d2c in cyg_assert_msg (psz_func=0x800cf44 "void
Cyg_Exception_Control::deliver_exception(cyg_code, CYG_ADDRWORD)",
    psz_file=0x800ced0
"/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx",
linenum=214,
    psz_msg=0x800cf24 "Out of range exception number") at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/infra/current/src/tcdiag.cxx:173
#5  0x08004a4a in Cyg_Exception_Control::deliver_exception
(this=0x20002dc0, exception_number=537001784,
exception_info=537001784)
    at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx:213
#6  0x0800474a in Cyg_Thread::deliver_exception (this=0x0,
exception_number=537001784, exception_info=537001784)
    at /home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/thread.cxx:1012
#7  0x08004aec in cyg_hal_deliver_exception (code=537001784,
data=537001784) at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/kernel/current/src/common/except.cxx:247
#8  0x0800801a in hal_deliver_exception (regs=0x2001ff38) at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/hal_misc.c:350
#9  0x0800005e in hal_default_exception_vsr () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
#10 0x0800005e in hal_default_exception_vsr () at
/home/lucky/Devel/PLSee/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:184
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) q


>
> If you have not already done so, disable compiler optimisation by
> removing "-O2" from the CYGBLD_GLOBAL_CFLAGS option. Also enable
> CYGPKG_INFRA_DEBUG. You should then be able to step into your code from
> system reset and see where the exception is triggered.

It's done.

> Good luck with your debugging...
>

I need it ;)

--
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-24  8:57       ` John Dallaway
  2014-01-24 11:19         ` Samuel Charnet
@ 2014-01-25 11:07         ` Samuel Charnet
  2014-01-25 13:41           ` Samuel Charnet
  1 sibling, 1 reply; 8+ messages in thread
From: Samuel Charnet @ 2014-01-25 11:07 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Discussion

I still can't debug

I looked in more detail objdump output and i have a strange thing :

So, this is the header :

$ arm-none-eabi-objdump -h hello

hello:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_aranges 000012e0  00000000  00000000  000050d8  2**3
                  CONTENTS, READONLY, DEBUGGING
  1 .debug_info   00047978  00000000  00000000  000063b8  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_abbrev 0000b993  00000000  00000000  0004dd30  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_line   0000b85d  00000000  00000000  000596c3  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_frame  00002ba8  00000000  00000000  00064f20  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_str    00008f1a  00000000  00000000  00067ac8  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_loc    00012afc  00000000  00000000  000709e2  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .rom_vectors  00000008  08000000  08000000  00000098  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .ARM.exidx    00000008  08000008  08000008  000000a0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .text         00004d18  08000010  08000010  000000a8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .rodata       00000160  08004d28  08004d28  00004dc0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .eh_frame     00000008  08004e88  08004e88  00004f20  2**0
                  ALLOC
 12 .data         000001b8  20000288  08004e90  00004f20  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 13 .bss          000034bc  20000440  08005048  000050d8  2**3
                  ALLOC
 14 .ARM.attributes 0000002f  00000000  00000000  000834de  2**0
                  CONTENTS, READONLY
 15 .comment      00000070  00000000  00000000  0008350d  2**0
                  CONTENTS, READONLY
 16 .debug_ranges 000046c8  00000000  00000000  0008357d  2**0
                  CONTENTS, READONLY, DEBUGGING

The text section should be

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-25 11:07         ` Samuel Charnet
@ 2014-01-25 13:41           ` Samuel Charnet
  2014-01-28 20:36             ` Samuel Charnet
  0 siblings, 1 reply; 8+ messages in thread
From: Samuel Charnet @ 2014-01-25 13:41 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Discussion

hum sorry, my mail was truncated

The text section should be at 0x8000010, the same address as the
reset_vector function, it is the entry point.

But in objdump i can see  "start address 0x08000011", is it normal ?

When I try to break to reset_vector, nothing append, can I conclude
that reset_vector is not called ?

-- 
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] 8+ messages in thread

* [ECOS] Re: STM32 ROMINT don't run
  2014-01-25 13:41           ` Samuel Charnet
@ 2014-01-28 20:36             ` Samuel Charnet
  0 siblings, 0 replies; 8+ messages in thread
From: Samuel Charnet @ 2014-01-28 20:36 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Discussion

Hi,

I come back to tell my problem is solved ! gcc 4.7.2 was my problem, i
now use the toolchain from ecos centric and i can begin to play :)

I am surprise because this toolchain work with ST standard library and
chibios RT..

2014-01-25 Samuel Charnet <samcharnet@gmail.com>:
> hum sorry, my mail was truncated
>
> The text section should be at 0x8000010, the same address as the
> reset_vector function, it is the entry point.
>
> But in objdump i can see  "start address 0x08000011", is it normal ?
>
> When I try to break to reset_vector, nothing append, can I conclude
> that reset_vector is not called ?

-- 
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] 8+ messages in thread

end of thread, other threads:[~2014-01-28 20:36 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CACra8jX5=y1-7iRktxuvK11T8zTNBPfR38=5b57PK2EJNbQ1nA@mail.gmail.com>
2014-01-22 17:24 ` [ECOS] Fwd: STM32 ROMINT don't run Samuel Charnet
2014-01-23 17:06   ` [ECOS] " John Dallaway
2014-01-23 18:02     ` Samuel Charnet
2014-01-24  8:57       ` John Dallaway
2014-01-24 11:19         ` Samuel Charnet
2014-01-25 11:07         ` Samuel Charnet
2014-01-25 13:41           ` Samuel Charnet
2014-01-28 20:36             ` Samuel Charnet

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).