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

Re: [bluetooth-dev] CSR chip : bcsp problem



Hi,

You are right, there was a wrong setting on my UART (now it is in one stop bit, even parity). Now I receive a message that seems to be a correct bcsp frame (and now it is always the same). But the data is empty. Here is it :

0xc0 0x07 0x00 0x00 0xf8 0xc0

But the problem is still the same : this is the only frame I receive and it doesn't look as a sync frame.

After having received this frame, I send a sync frame (and expect a sync-resp). I send :

0xc0,0x00,0x41,0x00,0xbe,0xda,0xdc,0xed,0xed,0xc0

but I never get anything back.

According to indications given my Muarata (which sold use the CSR chips), firmware version is 12.7

Any idea why the first frame contains an empty payload ?

Best regards.


On Mon, 09 Dec 2002 10:13:45 +0000
Carl Orsborn <cjo@xxxxxxx.com> wrote:

> Gavin,
> 
> I suspect this is the wrong analysis path.  Alain's original email
> described the initial messages emitted by the module to be the
> same for a given module, but slightly different on 3 separate
> modules:
> 
>     1) 0xc0 0x1d 0x07 0x08 0x20 0xfe 0x60
>     2) 0xc0 0x1d 0x03 0x08 0x20 0xfe 0x60
>     3) 0xc0 0x1d 0x07 0x08 0x20 0xfe 0xe0
> 
> These all start with 0xc0, a bcsp start-of-frame marker, so it
> looks likely they are bcsp messages.  However, the rest of
> these messages seem deeply weird.  I (quickly) analyse the first
> to be:
> 
>    no-crc
>    unreliable msg
>    seq = 5
>    ack = 6
>    len = 128
>    channel = 7 (SCO)
>    checksum = invalid
> 
> We then get 2 bytes of payload and no terminating 0xc0.  If this
> is a bcsp message then it is badly broken.
> 
> I would expect the initial bytes to be a bcsp-le sync message.
> I would expect something like:
> 
>    0xc0 0x00 0x41 0x00 0xbe 0xda 0xdc 0xed 0xed 0xc0
> 
> I've constructed this by hand (not by collecting bytes
> from a known good module), so I may have it wrong in detail.
> The payload shows the "dad ceded" message - a bcsp "sync" message.
> It has 0xc0 at both ends.  I'd expect the module to emit this
> message every 250ms.
> 
> This is significantly different from Alain's report.  The fact
> that the message starts 0xc0, makes it look like bcsp, but
> the rest of Alain's messages don't compare well to a sync.
> 
> The fact that Alain's messages start right, but are too short
> and are otherwise messed up makes me strongly suspect there is
> a problem with the baud rate and/or uart settings.  This
> is amplified by the fact that Alain's modules' messages
> are different.  This is what I advised Alain in my first
> email response.
> 
> The things that worry me still are:
> 
>    Alain reports that each module's message is emitted
>      only once.
> 
>    Alain's report of a bcsp sync message from a "good"
>      module is also invalid, though it is closer to being
>      a good sync message.
> 
> If we're still at the "sync" stage of BCSP-LE, then the
> PSKEY_USE_OLD_BCSP_LE is not yet relevent.
> 
> Kind regards,
> 
> Carl
> 
> Gavin Jewell wrote:
> > Alain,
> > if you look at the latest version of PStools, you'll see a key called "Use
> > the old version of BCSP link establishment" or "436 PSKEY_USE_OLD_BCSP_LE"
> > the comment associated with this is...
> > 
> > "If this pskey is set to FALSE then the firmware uses the BCSP Link
> > Establishment protocol described in bc01-s-010g, otherwise it uses
> > the older protocol described in bc01-s-010f.
> > 
> > The new protocol only differs significantly from the old one in
> > that:
> > 
> >     - The "choke" is turned off when moving from "curious" to
> >       "garrulous".
> > 
> >     - The "cnf_cnt_limit" logic is removed; "conf" messages are
> >       continuously emitted in the "curious" state.
> > 
> > It may be necessary to set this pskey to TRUE if the host
> > has an old implementation of bcsp-le
> > 
> > See the comment for PSKEY_BCSP_LM_CNF_CNT_LIMIT."
> > 
> > Hope this points you in the right direction
> > Regards
> > 
> > --
> > Gavin Jewell
> > Research and Development Manager
> > Brain Boxes Limited
> > www.brainboxes.com 
> > 
> > -----Original Message-----
> > From: Alain Paschoud [mailto:alain.paschoud.list@xxxxxxx.ch]
> > Sent: 09 December 2002 08:55
> > To: Gavin Jewell; Carl Orsborn
> > Cc: Bluetooth-dev
> > Subject: Re: [bluetooth-dev] CSR chip : bcsp problem
> > 
> > 
> > Hi,
> > 
> > Thank you for your answers. I got some up-to-date documentation from CSR. I
> > have now next documents :
> > 
> > bc01-an-102a
> > bc02-an-005a
> > 
> > in bc02-an-005a, I didn't find any changes concerning BCSP related keys.
> > 
> > I think my problem comes from new firmware (however, I can't verify firmware
> > version now that I can't communicate any more with the modules). Otherwise,
> > we should have no problem to change key to set module in BCSP as we did
> > before. When we got CSR chips, we thought that they where in BCSP mode. But
> > they were in H4. They are now solded on our embedded system, and serial line
> > is connected to a micropocessor. I must now change the keys without any
> > specific tool, just by sending packets on the serial line.
> > 
> > According to bc01-an-102a documentation, I should change key 0x1F9. Ok, I
> > did that. Before I get in troubles, I changed key PSKEY_HOSTIO_UART_PS_BLOCK
> > (0x191) which is indicated as "Do not modify these keys under any
> > circumstances" in the document. But it was the only way I found to change
> > parity and flow control activation/desactivation. Now in the document, it is
> > indicated : "Since the keys can be set elsewhere it is not necessary to
> > change this key directly". But I didn't find another way to set the keys.
> > 
> > Gavin Jewell is speaking about "USE_OLD_BCSP or something similar" in new
> > firmwares. For the moment, I haven't found such information in CSR
> > documentation. But in facts, I just need to know exactly which keys I have
> > to change with new firmwares to move from H4 to BCSP. I've a small embedded
> > software to change them, and because keys are only read at boot, I can
> > change every necessary keys to move from H4 to BCSP before to activate
> > changes with a reboot. The speed is known (115k) because I could communicate
> > in H4 with the module at this speed.
> > 
> > I didn't find the update Gavin is telling me about : "CSR have published
> > updated documentation on their site to say how the
> > behaviour has changed". If you have some more precise references...
> > 
> > Thank you very much for your help.
> > 
> > Best regards.
> 
> 
> 


-- 
Alain Paschoud                      SMARTDATA SA
alain.paschoud@xxxxxxx.ch         PSE-A
http://www.smartdata.ch             1015 Lausanne
Phone +41-21-693'84'98              
Fax   +41-27-693'84'91              
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com