[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] CSR chip : bcsp problem
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 :
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 ?
On Mon, 09 Dec 2002 10:13:45 +0000
Carl Orsborn <firstname.lastname@example.org> wrote:
> 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
> 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:
> 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,
> 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:email@example.com]
> > 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
http://www.smartdata.ch 1015 Lausanne
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org