Réf : Re: Réf : Re: RTEMS LEON2 EDAC Trap Management

Leonard Bise leonard.bise at syderal.ch
Wed Dec 2 07:12:36 UTC 2009


Hi,

I'll look into this asynchronous/synchronous interrupts.

And yes I'm using an AT697E, a colleague of mine spent a lot of time on it 
as well ...

Thanks for the hints.





Stephan Gruenfelder <stephan.gruenfelder at ruag.com> 
02.12.2009 08:07

A
Leonard Bise <leonard.bise at syderal.ch>
cc

Objet
Re: Réf : Re: RTEMS LEON2 EDAC Trap Management






Hi,

I am not working with RTEMS nor do I still write code. However, I might 
have a 
hint for you: SPARC defines asynchronous and synchronous interrupts. It 
sounds 
you have the wrong type. Please check.

If you are working with the AT697E, then you might face other problems, as 
well. 
To my knowledge the AT697E EDAC handling works differently than 
documented. 
Finding that out, has cost one of my team members quite some time ...

Regards
Stephan Grünfelder

On 02.12.2009 07:59, Leonard Bise wrote:
> 
> Thank you Aleix! But yeah I'm working on uncorrectable EDAC errors.
> 
> Also I was wondering, the trap table is installed using this function, 
> maybe this could be the cause of my problem?
> 
> *void* OS_install_handler(OS_FUNCPTR handler, uint32 irq) {
>     {
>         /*#[ operation OS_install_handler(OS_FUNCPTR,uint32) */
>         set_vector ((*const* rtems_isr_entry) handler, irq, 1);
>         /*#]*/
>     }
> }
> 
> 
> 
> 
> *Aleix Conchillo Flaqué <aconchillo at ice.csic.es>*
> Envoyé par : aconchillo at gmail.com
> 
> 01.12.2009 19:43
> 
> 
> A
>                Leonard Bise <leonard.bise at syderal.ch>
> cc
>                rtems-users at rtems.org
> Objet
>                Re: RTEMS LEON2 EDAC Trap Management
> 
> 
> 
> 
> 
> 
> 
> 
> Sorry Leonard, I just read your mail too fast. May be my answer helps
> someone else with single errors. :-)
> 
> Cheers,
> 
> Aleix
> 
> On Tue, Dec 1, 2009 at 17:24, Leonard Bise <leonard.bise at syderal.ch> 
wrote:
>  >
>  > Hi all,
>  >
>  > I'm working on an RTEMS application running on a LEON2 processor.
>  > I have some issues in regard to the Double EDAC error trap (0x09)
>  > management.
>  >
>  > I'm trying to validate that my application correctly manages EDAC 
> errors by
>  > launching my application, breaking then generating an EDAC error and 
then
>  > resuming.
>  > My application then detects that an error has hapened and launches 
the
>  > correct trap handler.
>  >
>  > After the trap has been handled, we resume normal execution by 
> executing the
>  > rett instruction (return from trap), with the address of the next
>  > instruction after the one that has been trapped.
>  > Only that instead of continuing executing after the rett, the same
>  > instruction that triggered the first error triggers another error 
(0x11)
>  > which should be a correctable EDAC error.
>  >
>  > This behavior then loops forever (Double EDAC than Single EDAC 
> etc...) and
>  > after some time my application resets (I have approximatively 32'000 
trap
>  > triggered for each one before it resets).
>  >
>  > I've been looking around for help in the LEON "community" but I could 
not
>  > find much help. I know it is not necessarily RTEMS related but a 
> colleague
>  > of mine which does the exact same thing on another project but only 
> in C has
>  > no problem so I'm wondering what might be causing this.
>  >
>  > For info here is my double edac trap handler.
>  >
>  > static void BGD_trap_DE_handler(void) {
>  >     {
>  >         /*#[ operation BGD_trap_DE_handler() */
>  >         volatile uint32*          failing_address;
>  >         boolean accepted = FALSE;
>  >
>  >         /* read Failure Address Register */
>  >         asm("TEST_EDAC_DOUBLE_START:nop;");
>  >         failing_address = *FAILAR;
>  >         FIFO_edac_address [FIFO_edac_next] = (uint32)failing_address;
>  >         FIFO_edac_double [FIFO_edac_next] = 1;
>  >         FIFO_edac_nb = (FIFO_edac_nb & 0xF) + 1;
>  >         /* Note: in case more than 16 errors occur during 1 second, 
> the 16
>  > oldest will be lost. */
>  >         FIFO_edac_next = (FIFO_edac_next+1) & 0xF;
>  >
>  >         /* SYD MOD */
>  >         if ((failing_address < START_EEPROM) || (failing_address >=
>  > 0x80000000))
>  >         {
>  >             BGD_process_d_edac_sram();
>  >         }
>  >         else
>  >         {
>  >             BGD_process_d_edac_eeprom();
>  >         }
>  >         /* reset fail status register */
>  >         *FAILSR = 0;
>  >         *FAILAR = 0;
>  >
>  >         //BDT_abort_request (&accepted);
>  >         /*#]*/
>  >                 asm("TEST_EDAC_DOUBLE_END:nop;");
>  >     }
>  > }
>  >
>  > Here is a disassembly of the instruction that triggers the  Double 
EDAC
>  > Trap, which is correct:
>  >  1046115464  40001400  cmp  %i0, 15                [00000ff1]
>  >  1046115466  40001404  bgu  0x40001414             [00000000]
>  >  1046115467  40001408  nop                         [00000000]
>  >  1046115468  40001414  add  %fp, -20, %i5          [401e5f34]
>  >  1046115473            ahb read,  mst=0, size=2    [401e5f34 
40053854]
>  >  1046115474  40001418  ld  [%i5], %i2              [40053854]
>  >  1046115475  4000141c  add  %fp, -24, %i4          [401e5f30]
>  >  1046115480            ahb read,  mst=0, size=2    [401e5f30 
40100000]
>  >  1046115481  40001420  ld  [%i4], %i1              [40100000]
>  >  1046115482  40001424  mov  %i2, %i3               [40053854]
>  >  1046115483  40001428  mov  %i1, %i0               [40100000]
>  >  1046115491            ahb read,  mst=0, size=2    [40100000 
a6102003]
>  >  1046115492  4000142c  ld  [%i0], %i0              [trapped]
>  >
>  > Here is the second trap triggered, which should not happen:
>  >  1046117903  4002bdc8  mov  %l0, %psr              [000000c4]
>  >  1046117904  4002bdcc  nop                         [00000000]
>  >  1046117905  4002bdd0  nop                         [00000000]
>  >  1046117906  4002bdd4  nop                         [00000000]
>  >  1046117911            ahb read,  mst=0, size=2    [401e5e84 
00000000]
>  >  1046117912  4002bdd8  ld  [%g1 + 0x6c], %g1       [00000000]
>  >  1046117913  4002bddc  jmp  %l1                    [4002bddc]
>  >  1046117914  4002bde0  rett  %l2                   [40001430]
>  >  1046117916  4000142c  ld  [%i0], %i0              [trapped]
>  >
>  > I hope someone can help ;)
>  >
>  > Léonard.
>  >
>  > _______________________________________________
>  > rtems-users mailing list
>  > rtems-users at rtems.org
>  > http://www.rtems.org/mailman/listinfo/rtems-users
>  >
>  >
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-- 
====================================================
Stephan GRUENFELDER
Dr.techn., Software Engineer

Tel.  : +43-1-80199/5530,
Mobile: +43-676 784 8424
Fax   : +43-1-80199/5577
E-Mail: stephan.gruenfelder at ruag.com
RUAG Space GmbH
Stachegasse 16
A-1120 Vienna, AUSTRIA / EUROPE
FN 91260 g Handelsgericht Wien
www.ruag.com

This e-mail is for information only. Any contractual obligations require a 
confirmation by a company fax or letter.
This e-mail and any file attached to it may contain confidential 
information. If you are not the intended recipient, please delete this 
e-mail from your system immediately and notify us of the erroneous 
transmission; any other use of this e-mail is prohibited.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20091202/d3d175c4/attachment.html>


More information about the users mailing list