Re: [ECOS] Wrong asserts in mpc5xx var_intr.h?

[bob dot koninckx at o-3s dot com]

>-----Original Message-----
>From: Fritiofson, Andreas [mailto:andreas.fritiofson@newmad.se]
>Sent: Monday, November 13, 2006 05:47 AM
>To: ecos-discuss@sourceware.org
>Subject: RE: [ECOS] Wrong asserts in mpc5xx var_intr.h?
>
>Thanks for your reply!
>
>It works well when the asserts are switched (just as well as with them disabled) and most of the test pass just fine. So i certainly seems the are wrong.

Could you prepare a patch ?

>
>However i get another failed assert when i press ctrl-c from within gdb in the twothreads.c demo:
>
>...
>Thread 1: and now a delay of 224 clock ticks
>Thread 0: and now a delay of 243 clock ticks
>ASSERT FAIL: <1>hal_misc.c[195]hal_default_isr() Spurious Interrupt!!!
>[New thread 1]
>
>Program received signal SIGINT, Interrupt.
>[Switching to thread 1]
>cyg_hal_user_break (regs=0x0) at /home/andfri/Develop/ecos/packages/hal/common/current/src/hal_misc.c:138
>138         CYGARC_HAL_GET_RETURN_ADDRESS_BACKUP(_cyg_hal_compiler_dummy);
>Current language:  auto; currently c
>(gdb)
>
>This doesn't happen when I interrupt for example tests/services/memalloc/common/current/tests/heaptest. Why the difference? I'm not sure that the mpc5xx port has the same problem or if it is one of my modifications to it to make it work on a mpc565 platform that doesn't work. I have no mpc555 hardware to try it on.

I have no idea. If I find the time, (don't know when that'll be, though), I'll try it on mpc555 and see if it's also happening there.

Bob

>
>-
>Andreas Fritiofson
>Newmad Technologies AB
>
>-----Original Message-----
>From:	bob.koninckx@o-3s.com [mailto:bob.koninckx@o-3s.com]
>Sent:	Mon 11/13/2006 9:40 AM
>To:	Fritiofson, Andreas; ecos-discuss@sourceware.org
>Cc:	
>Subject:	Re: [ECOS] Wrong asserts in mpc5xx var_intr.h?
>
>Hi Andreas,
>
>I wrote this code a long time ago, so I can't say for sure without doing some tests. At first sight, It seems you are right and the Asserts should be the other way around.
>
>I ordered the vectors in such way that all VECTORS < CYGNUM_HAL_INTERRUPT_IMB3_QUADCA_CI1 are from devices that are connected directly to the SIU controller, so they can only have priorities from 0-7. All others >= CYGNUM_HAL_INTERRUPT_IMB3_QUADCA_CI1 come from sources that are connected to the IMB3 controller, so there priorities from 0-31 are valid.
>
>Could you try and see if it solves you problem ?
>
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>



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