Re: STM32 ROMINT don't run

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