8xx bus monitoring

8xx bus monitoring

[Robin Gilks]

Greetings

System is a MPC859 based controller.

I'm trying to determine whether a peripheral is not responding to memory 
fetches by using the bus monitor feature on the Transfer Acknowledge 
(TA) signal. This is set to the maximum count in the Bus Monitor Timeout 
(BMT) in the System Protect Control Register (SYPCR). The monitoring is 
enabled by setting the Bus Monitor Enable (BME) bit in SYPCR as well.

I understand that I can use the Transfer Error Status Register (TESR) to 
read the fact that I have had a timeout by checking the Data Transfer 
Monitor Timeout (DTMT) bit in this register.

The problem is, how do I know any error has occured so I know to look at 
  the TESR. I can't see a way of generating an exception from this 
condition.

Any help appreciated.

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks@tait.co.nz
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================

Re: 8xx bus monitoring

[Pantelis Antoniou]

Robin Gilks wrote:
> Greetings
> 
> System is a MPC859 based controller.
> 
> I'm trying to determine whether a peripheral is not responding to memory 
> fetches by using the bus monitor feature on the Transfer Acknowledge 
> (TA) signal. This is set to the maximum count in the Bus Monitor Timeout 
> (BMT) in the System Protect Control Register (SYPCR). The monitoring is 
> enabled by setting the Bus Monitor Enable (BME) bit in SYPCR as well.
> 
> I understand that I can use the Transfer Error Status Register (TESR) to 
> read the fact that I have had a timeout by checking the Data Transfer 
> Monitor Timeout (DTMT) bit in this register.
> 
> The problem is, how do I know any error has occured so I know to look at 
>  the TESR. I can't see a way of generating an exception from this 
> condition.
> 
> Any help appreciated.
> 

You get a machine check exception.

It's pretty obvious then :)

Regards

Pantelis

Re: 8xx bus monitoring

[Robin Gilks]

Pantelis Antoniou wrote:
> Robin Gilks wrote:
> 
>> Greetings
>>
>> System is a MPC859 based controller.
>>
>> I'm trying to determine whether a peripheral is not responding to 
>> memory fetches by using the bus monitor feature on the Transfer 
>> Acknowledge (TA) signal. This is set to the maximum count in the Bus 
>> Monitor Timeout (BMT) in the System Protect Control Register (SYPCR). 
>> The monitoring is enabled by setting the Bus Monitor Enable (BME) bit 
>> in SYPCR as well.
>>
>> I understand that I can use the Transfer Error Status Register (TESR) 
>> to read the fact that I have had a timeout by checking the Data 
>> Transfer Monitor Timeout (DTMT) bit in this register.
>>
>> The problem is, how do I know any error has occured so I know to look 
>> at  the TESR. I can't see a way of generating an exception from this 
>> condition.
>>
>> Any help appreciated.
>>
> 
> You get a machine check exception.
> 
> It's pretty obvious then :)
> 

Using a 2.4.22 based kernel, as far as I can see a machine check should 
be trapped (its only allowed to cause a reset in the reboot code I 
think). Assuming I got it right and it really is trapped, how come I 
always get a reset:-((

Any pointers to the code that does setup for causing an exception 
(rather than reset) would be appreciated.

-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks@tait.co.nz
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================

Re: 8xx bus monitoring

[Pantelis Antoniou]

Robin Gilks wrote:
> Pantelis Antoniou wrote:
> 
>> Robin Gilks wrote:
>>
>>> Greetings
>>>
>>> System is a MPC859 based controller.
>>>
>>> I'm trying to determine whether a peripheral is not responding to 
>>> memory fetches by using the bus monitor feature on the Transfer 
>>> Acknowledge (TA) signal. This is set to the maximum count in the Bus 
>>> Monitor Timeout (BMT) in the System Protect Control Register (SYPCR). 
>>> The monitoring is enabled by setting the Bus Monitor Enable (BME) bit 
>>> in SYPCR as well.
>>>
>>> I understand that I can use the Transfer Error Status Register (TESR) 
>>> to read the fact that I have had a timeout by checking the Data 
>>> Transfer Monitor Timeout (DTMT) bit in this register.
>>>
>>> The problem is, how do I know any error has occured so I know to look 
>>> at  the TESR. I can't see a way of generating an exception from this 
>>> condition.
>>>
>>> Any help appreciated.
>>>
>>
>> You get a machine check exception.
>>
>> It's pretty obvious then :)
>>
> 
> Using a 2.4.22 based kernel, as far as I can see a machine check should 
> be trapped (its only allowed to cause a reset in the reboot code I 
> think). Assuming I got it right and it really is trapped, how come I 
> always get a reset:-((
> 
> Any pointers to the code that does setup for causing an exception 
> (rather than reset) would be appreciated.
> 

Check the MSR register at the time of the access.
Is RI set? If not instead of an exception you get a reset...

Regards

Pantelis

Re: 8xx bus monitoring

[Robin Gilks]

Pantelis Antoniou wrote:
>>>
>>> You get a machine check exception.
>>>
>>> It's pretty obvious then :)
>>>
>>
>> Using a 2.4.22 based kernel, as far as I can see a machine check 
>> should be trapped (its only allowed to cause a reset in the reboot 
>> code I think). Assuming I got it right and it really is trapped, how 
>> come I always get a reset:-((
>>
>> Any pointers to the code that does setup for causing an exception 
>> (rather than reset) would be appreciated.
>>
> 
> Check the MSR register at the time of the access.
> Is RI set? If not instead of an exception you get a reset...

I don't understand this - the whole point is that an exception occurs 
asynchronously and therefore I don't know where the access it, except of 
course I don't get an exception!!!

Where (insert name of source file in kernel tree) is RI set in MSR (or 
should be set but is missing from the kernel I'm using) so as to ensure 
that an exception occurs and how does the kernel distinguish a bus 
monitor timeout from other causes.

If the kernel (or the MPC8xx) is not capable of this then I guess I'll 
just have to fix the hardware :-((


-- 
Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks@tait.co.nz
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================