>-----Original Message----- >From: Fritiofson, Andreas [mailto:[EMAIL PROTECTED] >Sent: Monday, November 13, 2006 05:47 AM >To: [EMAIL PROTECTED] >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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Mon 11/13/2006 9:40 AM >To: Fritiofson, Andreas; [EMAIL PROTECTED] >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
