I'm on to this weird bug, which probably was there in my system from the
start. It only happens when I _don't_ optimize, when I use -O0. So I
compiled with -O2 all the time until now.

The problem seems to be that when eCos enables the tick timer, I
instantly receive an exception. All the values from the saved registers
look screwed up, like this (printed out from cyg_hal_exception_handler()):

vector 0xfffffdf7, sp 0x04083004, fp 0x04083004, lr 0xffff6324, sr
0xbdfffee3, pc 0xffffffbf, eear 0xbffdf2e7

Can anyone find some sense in this? I mean, why do I get an exception
with this totally insane vector? Obviously, stack and frame pointer are
bogus too, since they don't point to RAM but to code in ROM (they point
to the beginning of _cyg_hal_default_exception_vsr ).

Heiko

Looks similar to what I got when I did a null pointer dereference. No, I couldn't make any sense of the registers either :-) Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________

Dear, I experienced the same problem when running programs out of SDRAM. When I ran the same programs out of onchip-RAM, they worked without the -O2 option. Really strange! Best regards, Dries Driessens -------------------------------------------- Subject: RE: [openrisc] eCos crash when not optimizing From: "Robert Cragie" rcc@jennic.com> Date: Fri, 16 Jan 2004 12:29:36 -0000 To: "List about OpenRISC project" openrisc@opencores.org> Looks similar to what I got when I did a null pointer dereference. No, I couldn't make any sense of the registers either Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________ >> -----Original Message----- >> From: openrisc-bounces@opencores.org >> [mailto:openrisc-bounces@opencores.org]On Behalf Of Heiko Panther >> Sent: 16 January 2004 12:06 >> To: openrisc@opencores.org >> Subject: [openrisc] eCos crash when not optimizing >> >> >> I'm on to this weird bug, which probably was there in my system from the >> start. It only happens when I _don't_ optimize, when I use -O0. So I >> compiled with -O2 all the time until now. >> >> The problem seems to be that when eCos enables the tick timer, I >> instantly receive an exception. All the values from the saved registers >> look screwed up, like this (printed out from cyg_hal_exception_handler()): >> >> vector 0xfffffdf7, sp 0x04083004, fp 0x04083004, lr 0xffff6324, sr >> 0xbdfffee3, pc 0xffffffbf, eear 0xbffdf2e7 >> >> Can anyone find some sense in this? I mean, why do I get an exception >> with this totally insane vector? Obviously, stack and frame pointer are >> bogus too, since they don't point to RAM but to code in ROM (they point >> to the beginning of _cyg_hal_default_exception_vsr ). >> >> Heiko >> >> _______________________________________________ >> http://www.opencores.org/mailman/listinfo/openrisc >>

What kind of SDRAM controller are you using? regards, Damjan ----- Original Message ----- From: "Dries Driessens" ddr@denayer.wenk.be> To: openrisc@opencores.org> Sent: Monday, January 19, 2004 1:57 PM Subject: RE: [openrisc] eCos crash when not optimizing

> I experienced the same problem when running programs out of SDRAM.

Yeah, I'm running from external memory too (flash with homebrewed
controller).

Heiko

Got this one too. In the HAL architecture of eCos, vectors.S, routine
cyg_hal_default_interrupt_vsr. r4 contains the all-important vector
number, which is clobbered by a call to _cyg_instrument for a -O0 build.
Here's my quick fix:

FUNC_START(cyg_hal_default_interrupt_vsr)

# Stash away pointer to saved regs for later
l.or r31,r3,r3
# and the vector number too!
l.or r29,r4,r4

(...)

#if defined(CYGPKG_KERNEL_INSTRUMENT) &&
defined(CYGDBG_KERNEL_INSTRUMENT_INTR)
# Log the interrupt if kernel tracing is enabled
l.ori r3,r0,0x0301 # arg1 = type = INTR,RAISE
# arg2 = vector number
l.ori r5,r0,0 # arg3 = 0
l.jal _cyg_instrument # call instrument function
l.nop

# and because _cyg_instrument might have destroyed r4, get it back
l.or r4, r29, r29
#endif

Note also the added l.nop.

Regards,
Heiko

Aha - I think I now know why I didn't see this. I have been disabling CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT in eCos configuration. See: http://www.opencores.org/forums/openrisc/2003/08/00036 With regard to other comments, yes it would be nice to see a new release of 3.2.3 with all patches etc. in to upgrade to. I've applied some which have been previously posted but I'm now a bit confused as to exactly what I've done ;-) Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________

Robert Cragie wrote:


I don't think the setting of
CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT could hide this bug
completely, because the dispatch to the interrupt service routine [which
follows the corruption of r4 by cyg_instrument()] would be adversely
affected regardless of the setting of that macro.

More likely is that you don't have kernel instrumentation turned on, so
the call to cyg_instrument() is never made. It's used for performance
tuning, so I'm guessing that most developers rarely turn it on.

-Scott