[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] BCSP synchronisation



Hello, Peter.

Peter Kjellerstedt wrote:

>>-----Original Message-----
>>From: Carl Orsborn [mailto:cjo@xxxxxxx.com]
>>Sent: 04 February 2002 17:44
>>To: Peter Kjellerstedt
>>Cc: 'Alain Paschoud'; Bluetooth-dev
>>Subject: Re: [bluetooth-dev] BCSP synchronisation
>>
>>Peter,
>>
>>1) Hardware Error code 0x1c means:
>>
>>    Either the chip received an unrecognised HCI command
>>    message from the host or the chip ran out of pool memory
>>    when processing the message. In either case the message
>>    has been discarded.
>>
>>At boot time it is unliketly to be a pool memory issue, so it
>>is probably a duff HCI command.
>>
>
>Any way to find out what command it did not like? Since the module
>seems to do what we tell it to do and respond appropriately, there
>is no obvious command to blame...
>
If the firmware detects an HCI command as invalid it should discard it.
Internally the firmware calls fault(0x1c), and 2 seconds later an HCI
Hardware_Error event should be emitted with fault code 0x1c.

The 2 second delay is from a filter that tries to prevent a block of
identical error codes being sent to the host - if the underlying problem
is from resources running low, a clump of Hardware_Error reports
would make matters worse.  (The 2s delay in reporting will be done
differently in later builds.)

The common way to find out which command provokes the
complaint is to inject a (10s?) delay between each host command,
then wait until the module squeals.

>>2) Hardware Error code 0xfe should only be emitted when
>>    using H4.
>>
>>The code is used to signal H4 link synchronisation failure, as 
>>required by the H4 specification.
>>
>
>Synchronisation between what? The Bluetooth module and the host,
>or the module and one of the clients?
>
>Whose fault is it? The stack, the hardware or the hardware at
>the other end?
>
>And most importantly: What can we do to prevent it from happening?
>
The firmware emits code 0xfe when:

   -  The first byte of an H4 frame is not one of {0x01, 0x02, 0x03}

   -  An HCI ACL or SCO frame's declared length (in its header) exceeds
        the values available from the HCI Read_Buffer_Size command.

After emitting 0xfe the firmware then goes into its sulky state of waiting
for an HCI_Reset, as required by the H4 specification.

The usual culprits for provoking an H4 sync loss are uart line byte
corruption, insufficiently responsive UART flow control and duff
host drivers.

Painful experience has shown us that fast serial PCI cards (1.3 Mbaud+)
are normally unreliable, and thus deadly for H4.  (We use Blueheat (?)
and Serial Solutions (?) for testing, which seem to be OK.)  

BCSP device drivers are often layered above a normal UART driver.  
One rather nice (unanticipated) benefit of this is that the BCSP
driver just treats dodgy fast serial cards/drivers as part of its
unreliable medium, and detects/recovers-from its errors as it
would normal line noise.


Regards,

Carl Orsborn





**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com