Réf : Re: RTEMS LEON2 EDAC Trap Management

[Leonard Bise]

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
>
>

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