<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I'll look into this asynchronous/synchronous
interrupts.</font>
<br>
<br><font size=2 face="sans-serif">And yes I'm using an AT697E, a colleague
of mine spent a lot of time on it as well ...</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the hints.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stephan Gruenfelder <stephan.gruenfelder@ruag.com></b>
</font>
<p><font size=1 face="sans-serif">02.12.2009 08:07</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">A</font></div>
<td><font size=1 face="sans-serif">Leonard Bise <leonard.bise@syderal.ch></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Objet</font></div>
<td><font size=1 face="sans-serif">Re: Réf : Re: RTEMS LEON2 EDAC Trap
Management</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi,<br>
<br>
I am not working with RTEMS nor do I still write code. However, I might
have a <br>
hint for you: SPARC defines asynchronous and synchronous interrupts. It
sounds <br>
you have the wrong type. Please check.<br>
<br>
If you are working with the AT697E, then you might face other problems,
as well. <br>
To my knowledge the AT697E EDAC handling works differently than documented.
<br>
Finding that out, has cost one of my team members quite some time ...<br>
<br>
Regards<br>
Stephan Grünfelder<br>
<br>
On 02.12.2009 07:59, Leonard Bise wrote:<br>
> <br>
> Thank you Aleix! But yeah I'm working on uncorrectable EDAC errors.<br>
> <br>
> Also I was wondering, the trap table is installed using this function,
<br>
> maybe this could be the cause of my problem?<br>
> <br>
> *void* OS_install_handler(OS_FUNCPTR handler, uint32 irq) {<br>
> {<br>
> /*#[ operation OS_install_handler(OS_FUNCPTR,uint32)
*/<br>
> set_vector ((*const* rtems_isr_entry)
handler, irq, 1);<br>
> /*#]*/<br>
> }<br>
> }<br>
> <br>
> <br>
> <br>
> <br>
> *Aleix Conchillo Flaqué <aconchillo@ice.csic.es>*<br>
> Envoyé par : aconchillo@gmail.com<br>
> <br>
> 01.12.2009 19:43<br>
> <br>
> <br>
> A<br>
> Leonard
Bise <leonard.bise@syderal.ch><br>
> cc<br>
> rtems-users@rtems.org<br>
> Objet<br>
> Re:
RTEMS LEON2 EDAC Trap Management<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Sorry Leonard, I just read your mail too fast. May be my answer helps<br>
> someone else with single errors. :-)<br>
> <br>
> Cheers,<br>
> <br>
> Aleix<br>
> <br>
> On Tue, Dec 1, 2009 at 17:24, Leonard Bise <leonard.bise@syderal.ch>
wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > I'm working on an RTEMS application running on a LEON2
processor.<br>
> > I have some issues in regard to the Double EDAC error trap
(0x09)<br>
> > management.<br>
> ><br>
> > I'm trying to validate that my application correctly manages
EDAC <br>
> errors by<br>
> > launching my application, breaking then generating an EDAC
error and then<br>
> > resuming.<br>
> > My application then detects that an error has hapened and
launches the<br>
> > correct trap handler.<br>
> ><br>
> > After the trap has been handled, we resume normal execution
by <br>
> executing the<br>
> > rett instruction (return from trap), with the address of
the next<br>
> > instruction after the one that has been trapped.<br>
> > Only that instead of continuing executing after the rett,
the same<br>
> > instruction that triggered the first error triggers another
error (0x11)<br>
> > which should be a correctable EDAC error.<br>
> ><br>
> > This behavior then loops forever (Double EDAC than Single
EDAC <br>
> etc...) and<br>
> > after some time my application resets (I have approximatively
32'000 trap<br>
> > triggered for each one before it resets).<br>
> ><br>
> > I've been looking around for help in the LEON "community"
but I could not<br>
> > find much help. I know it is not necessarily RTEMS related
but a <br>
> colleague<br>
> > of mine which does the exact same thing on another project
but only <br>
> in C has<br>
> > no problem so I'm wondering what might be causing this.<br>
> ><br>
> > For info here is my double edac trap handler.<br>
> ><br>
> > static void BGD_trap_DE_handler(void) {<br>
> > {<br>
> > /*#[ operation BGD_trap_DE_handler()
*/<br>
> > volatile uint32*
failing_address;<br>
> > boolean accepted = FALSE;<br>
> ><br>
> > /* read Failure Address Register
*/<br>
> > asm("TEST_EDAC_DOUBLE_START:nop;");<br>
> > failing_address = *FAILAR;<br>
> > FIFO_edac_address [FIFO_edac_next]
= (uint32)failing_address;<br>
> > FIFO_edac_double [FIFO_edac_next]
= 1;<br>
> > FIFO_edac_nb = (FIFO_edac_nb
& 0xF) + 1;<br>
> > /* Note: in case more than
16 errors occur during 1 second, <br>
> the 16<br>
> > oldest will be lost. */<br>
> > FIFO_edac_next = (FIFO_edac_next+1)
& 0xF;<br>
> ><br>
> > /* SYD MOD */<br>
> > if ((failing_address < START_EEPROM)
|| (failing_address >=<br>
> > 0x80000000))<br>
> > {<br>
> > BGD_process_d_edac_sram();<br>
> > }<br>
> > else<br>
> > {<br>
> > BGD_process_d_edac_eeprom();<br>
> > }<br>
> > /* reset fail status register
*/<br>
> > *FAILSR = 0;<br>
> > *FAILAR = 0;<br>
> ><br>
> > //BDT_abort_request (&accepted);<br>
> > /*#]*/<br>
> >
asm("TEST_EDAC_DOUBLE_END:nop;");<br>
> > }<br>
> > }<br>
> ><br>
> > Here is a disassembly of the instruction that triggers
the Double EDAC<br>
> > Trap, which is correct:<br>
> > 1046115464 40001400 cmp %i0, 15
[00000ff1]<br>
> > 1046115466 40001404 bgu 0x40001414
[00000000]<br>
> > 1046115467 40001408 nop
[00000000]<br>
> > 1046115468 40001414 add %fp, -20,
%i5 [401e5f34]<br>
> > 1046115473 ahb
read, mst=0, size=2 [401e5f34 40053854]<br>
> > 1046115474 40001418 ld [%i5], %i2
[40053854]<br>
> > 1046115475 4000141c add %fp, -24,
%i4 [401e5f30]<br>
> > 1046115480 ahb
read, mst=0, size=2 [401e5f30 40100000]<br>
> > 1046115481 40001420 ld [%i4], %i1
[40100000]<br>
> > 1046115482 40001424 mov %i2, %i3
[40053854]<br>
> > 1046115483 40001428 mov %i1, %i0
[40100000]<br>
> > 1046115491 ahb
read, mst=0, size=2 [40100000 a6102003]<br>
> > 1046115492 4000142c ld [%i0], %i0
[trapped]<br>
> ><br>
> > Here is the second trap triggered, which should not happen:<br>
> > 1046117903 4002bdc8 mov %l0, %psr
[000000c4]<br>
> > 1046117904 4002bdcc nop
[00000000]<br>
> > 1046117905 4002bdd0 nop
[00000000]<br>
> > 1046117906 4002bdd4 nop
[00000000]<br>
> > 1046117911 ahb
read, mst=0, size=2 [401e5e84 00000000]<br>
> > 1046117912 4002bdd8 ld [%g1 + 0x6c],
%g1 [00000000]<br>
> > 1046117913 4002bddc jmp %l1
[4002bddc]<br>
> > 1046117914 4002bde0 rett %l2
[40001430]<br>
> > 1046117916 4000142c ld [%i0], %i0
[trapped]<br>
> ><br>
> > I hope someone can help ;)<br>
> ><br>
> > Léonard.<br>
> ><br>
> > _______________________________________________<br>
> > rtems-users mailing list<br>
> > rtems-users@rtems.org<br>
> > </font></tt><a href="http://www.rtems.org/mailman/listinfo/rtems-users"><tt><font size=2>http://www.rtems.org/mailman/listinfo/rtems-users<br>
> ><br>
> ><br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> rtems-users@rtems.org<br>
> </font></tt><a href="http://www.rtems.org/mailman/listinfo/rtems-users"><tt><font size=2>http://www.rtems.org/mailman/listinfo/rtems-users<br>
<br>
-- <br>
====================================================<br>
Stephan GRUENFELDER<br>
Dr.techn., Software Engineer<br>
<br>
Tel. : +43-1-80199/5530,<br>
Mobile: +43-676 784 8424<br>
Fax : +43-1-80199/5577<br>
E-Mail: stephan.gruenfelder@ruag.com<br>
RUAG Space GmbH<br>
Stachegasse 16<br>
A-1120 Vienna, AUSTRIA / EUROPE<br>
FN 91260 g Handelsgericht Wien<br>
www.ruag.com<br>
<br>
This e-mail is for information only. Any contractual obligations require
a confirmation by a company fax or letter.<br>
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.<br>
<br>
</font></tt></a></a>
<br>