Re: [Bluez-users] Has anyone seen these problems with the CSR BlueCore and BlueZ before ?

[Steven Singer <steven.singer@csr.com>]

Marcel Holtmann wrote:
> Steven Singer wrote:
>> would it be a good idea to add reading of the panic and
>> fault codes to the CSR specific section of hcitool revision? Or,
>> get BlueZ to read the panic code when the inerface is brought up. If
>> it's non-zero and < 0x0100 write it to an event log and then zero it.
> 
> the kernel code should be complete vendor independent and thus adding
> this to "hciconfig hci0 revsion" is the only option.

That's OK. At least it will make it easy for users to find out this
information.

> Are both variables UINT16? If yes, then it will be quite easy to add
> this information to the hciconfig command.

Yes.

>                                            What document should I read
> for more information about the panic/fault code meanings?

HQ Commands (bcore-sp-003Pc). They're in section 6.

In addition to the information in there, you can decode the following:

  0x0080-0x00ff: Debugging codes. These should be used only within CSR
                 for testing purposes and, in theory, should not make it
                 into released code, but you never know.

  0x0100-0xffff: No panic/fault since last power cycle. When the chip is
                 powered on, the panic and fault codes usually end up
                 somewhere in this area. In theory they could end up in
                 the valid range, but it's unlikely. We don't use codes
                 in this area for real panics or faults.

If you want to test them, then the BCCMD variables are writable so you
should be able to write to them, read them back, and confirm that
they're preserved across reset but not power cycle.

If you want to test them further, then writing to variables 0x4820 and
0x4822 will cause the chip to panic or fault respectively. Each takes a
single 16 bit argument containg the code to use. In the case of panic,
this means that the chip will reset (unless the watchdog is disabled).
In the case of fault, an HCI Hardware_Error event and an HQ PDU should
be emitted.

If you're writing the codes or provoking the actions via BCCMD then you
can specify codes outside the normally valid range. This means you
should be able to test the full range your decode.

	- Steven
-- 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users