<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Wolfgang.<br>
<br>
What board / hardware are you using?<br>
<br>
In general it must be said that the handling of<br>
VME bus timeouts or errors is hardware and BSP dependent.<br>
<br>
Since I'm most familiar with PPC boards (which usually<br>
employ Tundra's universe or tsi148 vme-pci bridge) I'll<br>
give an overview of that board/BSP family.<br>
<br>
Examples for these boards are the motorola mvme series<br>
(e.g., mvme2300, mvme2100, mvme5500, mvme6100)<br>
<br>
When the VME bridge detects a timeout or some other<br>
error then it has a way to signal that condition via<br>
one (or multiple) hardware 'pins'.<br>
<br>
On some boards these pins are wired directly to the<br>
CPU or host-bridge and raise e.g., a machine-check<br>
exception.<br>
<br>
Other boards just route them to the ordinary interrupt<br>
controller.<br>
<br>
Depending on the BSP signalling VME errors is enabled<br>
or disabled by default.<br>
<br>
Especially if the board doesn't support raising a machine-check<br>
exception then it is left to the user/application to properly<br>
program the VME bridge and interrupt controller so that<br>
errors can be intercepted.<br>
<br>
However, several details must be kept in mind (again<br>
PPC specific):<br>
<br>
a) When VME errors must be handled as ordinary interrupts<br>
then signalling can be delayed due to code running with<br>
interrupts disabled or higher priority interrupts.<br>
<br>
b) The VME bridges I know of all use 'write-posting', i.e.<br>
a CPU write operation doesn't wait for the write to <br>
complete on the VME bus but only deposits the address/value<br>
into a FIFO inside the bridge which then performs the<br>
transaction on the bus asynchronously<br>
<br>
These and probably other scenarios have the consequence<br>
that VME errors sometimes are signalled, i.e., interrupt the CPU <br>
long after the violating code has been executed and thus<br>
may produce misleading error messages (because these <br>
messages usually point to the interrupted code sequence<br>
rather than the one that caused the error.<br>
<br>
HTH<br>
-- Till<br>
<br>
<br>
<br>
<br>
On 08/05/2010 10:49 AM, Wolfgang Rostek wrote:
<blockquote
cite="mid:OF8986F528.FDD9A480-ONC1257776.0055F1FD-C1257776.0056F23D@esg-gmbh.de"
type="cite"><font face="sans-serif" size="2">Hi all,</font>
<br>
<br>
<font face="sans-serif" size="2">I'm doing some tests accessing VME
bus
addresses.</font>
<br>
<br>
<font face="sans-serif" size="2">I wonder that an invalid address is
somehow tolerated by the Ada/RTEMS</font>
<br>
<font face="sans-serif" size="2">program but shows a correct trap
using
dBUG. No Ada exception handler</font>
<br>
<font face="sans-serif" size="2">seems to get invoked. Is it ok for
the
program to continue that way?</font>
<br>
<br>
<font face="sans-serif" size="2">The second assignment '</font><font
size="3">abcd</font><font face="sans-serif" size="2">'
I can verify in RAM after restart. (the </font><font size="3">Memory_Address</font>
<br>
<font face="sans-serif" size="2">function is working for the whole
address
range)</font>
<br>
<font face="sans-serif" size="2"><br>
</font><font size="3">----------------------------------------------------------------------------------------
</font><br>
<font size="3">tip675_dummy : UNSIGNED_16 := 16#fedc#; </font>
<br>
<font size="3">for tip675_dummy'Address use
Memory_Address(16#a0000000#);
</font><br>
<br>
<font size="3">tip675_dummy2 : UNSIGNED_16 := 16#abcd#; </font>
<br>
<font size="3">for tip675_dummy2'Address use
Memory_Address(16#40000000#);
</font><br>
<br>
<font size="3">----------------------------------------------------------------------------------------</font>
<p><font face="Arial" size="2">dBUG> md.l a0000000</font><font
size="3">
</font><font face="Arial" size="2"><br>
md.l a0000000</font><font size="3"> </font><font face="Arial" size="2"><br>
A0000000: FF</font><font size="3"> <br>
</font><font face="Arial" size="2"><br>
VME Bus Time Out</font><font size="3"> <br>
</font><font face="Arial" size="2"><br>
PC: F0001474 SR: 2004 [t.Sm.000...xnZvc]</font><font size="3"> </font><font
face="Arial" size="2"><br>
An: FE000000 F001F830 F001F848 F001F7DD F001F830 CBF5F311 F001F7CC
F001F7A8</font><font size="3">
</font><font face="Arial" size="2"><br>
Dn: 00000000 00008600 00000046 FFFFFF00 00000000 00000008 00000008
00000046</font><font size="3">
</font><font face="Arial" size="2"><br>
F0001474: 0801 0002 BTST
#0x02,D1</font><font size="3"> </font><font face="Arial" size="2"><br>
dBUG></font><font size="3"> </font><font face="sans-serif" size="2"><br>
<br>
Wolfgang Rostek<br>
<br>
Phone: +49 (89) 92 16-2183<br>
Fax: +49 (89) 92 16-162183<br>
<a class="moz-txt-link-abbreviated" href="mailto:wolfgang.rostek@esg.de">wolfgang.rostek@esg.de</a><br>
</font>
</p>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rtems-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a>
</pre>
</blockquote>
<br>
</body>
</html>