VME bus trap ignored

[Till Straumann]

Wolfgang.

What board / hardware are you using?

In general it must be said that the handling of
VME bus timeouts or errors is hardware and BSP dependent.

Since I'm most familiar with PPC boards (which usually
employ Tundra's universe or tsi148 vme-pci bridge) I'll
give an overview of that board/BSP family.

Examples for these boards are the motorola mvme series
(e.g., mvme2300, mvme2100, mvme5500, mvme6100)

When the VME bridge detects a timeout or some other
error then it has a way to signal that condition via
one (or multiple) hardware 'pins'.

On some boards these pins are wired directly to the
CPU or host-bridge and raise e.g., a machine-check
exception.

Other boards just route them to the ordinary interrupt
controller.

Depending on the BSP signalling VME errors is enabled
or disabled by default.

Especially if the board doesn't support raising a machine-check
exception then it is left to the user/application to properly
program the VME bridge and interrupt controller so that
errors can be intercepted.

However, several details must be kept in mind (again
PPC specific):

a) When VME errors must be handled as ordinary interrupts
     then signalling can be delayed due to code running with
     interrupts disabled or higher priority interrupts.

b) The VME bridges I know of all use 'write-posting', i.e.
     a CPU write operation doesn't wait for the write to
     complete on the VME bus but only deposits the address/value
     into a FIFO inside the bridge which then performs the
     transaction on the bus asynchronously

These and probably other scenarios have the consequence
that VME errors sometimes are signalled, i.e., interrupt the CPU
long after the violating code has been executed and thus
may produce misleading error messages (because these
messages usually point to the interrupted code sequence
rather than the one that caused the error.

HTH
-- Till




On 08/05/2010 10:49 AM, Wolfgang Rostek wrote:
> Hi all,
>
> I'm doing some tests accessing VME bus addresses.
>
> I wonder that an invalid address is somehow tolerated by the Ada/RTEMS
> program but shows a correct trap using dBUG. No Ada exception handler
> seems to get invoked. Is it ok for the program to continue that way?
>
> The second  assignment 'abcd' I can verify in RAM after restart. (the 
> Memory_Address
> function is working for the whole address range)
>
> ---------------------------------------------------------------------------------------- 
>
> tip675_dummy : UNSIGNED_16 := 16#fedc#;
> for tip675_dummy'Address use Memory_Address(16#a0000000#);
>
> tip675_dummy2 : UNSIGNED_16 := 16#abcd#;
> for tip675_dummy2'Address use Memory_Address(16#40000000#);
>
> ---------------------------------------------------------------------------------------- 
>
>
> dBUG> md.l a0000000
> md.l a0000000
> A0000000:  FF
>
> VME Bus Time Out
>
> PC: F0001474 SR: 2004 [t.Sm.000...xnZvc]
> An: FE000000 F001F830 F001F848 F001F7DD F001F830 CBF5F311 F001F7CC 
> F001F7A8
> Dn: 00000000 00008600 00000046 FFFFFF00 00000000 00000008 00000008 
> 00000046
> F0001474: 0801 0002            BTST      #0x02,D1
> dBUG>
>
> Wolfgang Rostek
>
> Phone: +49 (89) 92 16-2183
> Fax: +49 (89) 92 16-162183
> wolfgang.rostek at esg.de
>
>
> _______________________________________________
> 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/20100910/0699079e/attachment-0001.html>