Re: No answer from cc2564 on UART

[Nils Faerber]

Am 08.04.2013 15:25, schrieb András Balogh:
> Hi for All,
Hi!

> I have a question concerning the confusing behaviour of my BT module.
> Currently I have the LSR's Tiwi-ub2 module, and a uC (AVR xmega)
> interfaced with UART.
> RTS
> After sending some commands I noticed, that the module is never raising
> the RTS (on the module) signal.

Hmm... after supplying the slow-clock (32kHz) and afterwards pulling the
!shutdown pin high the CTS of the module should drop all by itself
without any additional command.

> No matter what I sent (reset, read local version), there was no answer.

I am not sure when those commands become valid but did you already
upload the init-script?

> The format of the UART messages seems to be correct. The baud rate is
> the default (115200 8n1), and the RTS is pulled down after the boot
> sequence, the slow clock is OK too (I guess). I did not load the SP onto
> the module, because I wanted to see if UART was working...and for these
> types of HCI commands (as far as I know) no SP is needed...
>
> Did somebody experienced the same before? Could anybody please suggest a
> solution, or any point?
>
> Any help will be appreciated!

Well, I can just say that with the CC2560 I am currently experimenting
with the chip is also deaf for any additional command as long as I did
not upload the init script (I think you refer to it as SP, right?).

With an oscilloscope I was able to confirm that CTS will drop as soon as
32kHZ is applied and the shutdown signal removed (pulled high). RTS
(from host) should be pulled low as soon as you want to start
communication - else you will not get any response from the module at
all (RTS signals from host to module that the host is ready to receive
data, logic is negative).

> Best Regards,
> András Balogh
Cheers
nils

--
kernel concepts GmbH Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de

[Matthias Ringwald]

On 08.04.2013, at 15:51, Nils Faerber <nils.f...@kernelconcepts.de> wrote:

>> No matter what I sent (reset, read local version), there was no answer.
>
> I am not sure when those commands become valid but did you already
> upload the init-script?

The CC256x should always respond to an HCI Reset command.

matthias

[András Balogh]

At first, thank you for fast responses :).

Under HCI Reset you mean the "0x01 0x03 0x0C 0x00" UART byte sequence? So its not a TI specific HCI command...
Maybe some failure in the module (Though after the boot sequence, the RTS (output of the cc2564 module) is pulled low)?

matthias

[Nils Faerber]

Am 10.04.2013 13:21, schrieb András Balogh:
> At first, thank you for fast responses :).
>
> 2013. április 9., kedd 0:06:35 UTC+2 időpontban Matthias Ringwald a
> következőt írta:
>
>
> On 08.04.2013, at 15:51, Nils Faerber <nils.f...@kernelconcepts.de

> <javascript:>> wrote:
>
> >> No matter what I sent (reset, read local version), there was no
> answer.
> >
> > I am not sure when those commands become valid but did you already
> > upload the init-script?
>
> The CC256x should always respond to an HCI Reset command.

Well, actually mine does not - definitely.

The init script 2.44 also puts the module in HCILL mode, which I did
comment out. After that everything behaved pretty normal and HCI Reset
command worked as expected.

> Under HCI Reset you mean the*"0x01 0x03 0x0C 0x00"* UART byte sequence?

> So its not a TI specific HCI command...
> Maybe some failure in the module (Though after the boot sequence, the
> RTS (output of the cc2564 module) is pulled low)?
>
>
> matthias

[András Balogh]

As far as i know there is no init script (SP) is needed for the module to read information, or to reset it...
But for inquiry, and connection procedures the init script is always needed. The RTS (from host) is pulled low till the transaction of the command is complete, and after that it is pulled high...
No idea...

Andras

[András Balogh]

>     The CC256x should always respond to an HCI Reset command.

Well, actually mine does not - definitely.

The init script 2.44 also puts the module in HCILL mode, which I did
comment out. After that everything behaved pretty normal and HCI Reset
command worked as expected.

OK. I will try to load the init script on the module, and see if after that it works or not.
Thank you for answers.

[Matthias Ringwald]

hi

On Apr 10, 2013, at 1:56 PM, András Balogh <xba...@gmail.com> wrote:

>
> > The CC256x should always respond to an HCI Reset command.
>
> Well, actually mine does not - definitely.
>
> The init script 2.44 also puts the module in HCILL mode, which I did
> comment out. After that everything behaved pretty normal and HCI Reset
> command worked as expected.

Well, that's because YOU (Nils) put it into HCILL mode. After a cold start, it does respond to HCI Reset.

In fact, the init script consists of HCI commands, so if the module doesn't respond to commands, you cannot send it the init script.

Can you double check that
- the 32k clock is there
- the Shutdown pin has the NOT-Shutdown level
- the CTS/RTS stuff is configured correctly
- the TX data reaches the module at the correct ping

(sorry; don't remember the details, but please check the MSP430 sources for details)

also, is that module easy to use? It's certainly easier to solder as the PAN132x modules. What antenna do you use? Any other thing that oe should consider when using it for a hobby project?

matthias

>
> OK. I will try to load the init script on the module, and see if after that it works or not.
> Thank you for answers.
>

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To post to this group, send email to btsta...@googlegroups.com.
> Visit this group at http://groups.google.com/group/btstack-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[András Balogh]

2013. április 10., szerda 14:03:01 UTC+2 időpontban Matthias Ringwald a következőt írta:

hi

On Apr 10, 2013, at 1:56 PM, András Balogh <xba...@gmail.com> wrote:

>
> >     The CC256x should always respond to an HCI Reset command.
>
> Well, actually mine does not - definitely.
>
> The init script 2.44 also puts the module in HCILL mode, which I did
> comment out. After that everything behaved pretty normal and HCI Reset
> command worked as expected.

Well, that's because YOU (Nils) put it into HCILL mode. After a cold start, it does respond to HCI Reset.

In fact, the init script consists of HCI commands, so if the module doesn't respond to commands, you cannot send it the init script.

Can you double check that
- the 32k clock is there

It is there.
 

- the Shutdown pin has the NOT-Shutdown level

It has, otherwise the RTS is never pulled low...
 

- the CTS/RTS stuff is configured correctly

...The RTS changes, so its the output of the module, and it is configured to that too.
 

- the TX data reaches the module at the correct ping

What do you mean under "ping"? If the baudrate, then its the default 115,2k 8n1...
 

(sorry; don't remember the details, but please check the MSP430 sources for details)

also, is that module easy to use? It's certainly easier to solder as the PAN132x modules. What antenna do you use? Any other thing that oe should consider when using it for a hobby project?

The module is quite easy to use (should be), there is only a 32k oscillator, VBAT, and an antenna is needed (+ a uC).
The antenna used: 2450AT43B100 - http://www.johansontechnology.com/images/stories/ip/rf-antennas/JTI_Antenna-2450AT43B100_09042008.pdf
Nothing special, the RL (SWR) is around max. -9dB, and the gain is around 1 dB (at its best). Simple SM microstrip antenna...

 

matthias

Anyway I will give a try to the init script. In the worst case I will still be at the same point...

András

[Nils Faerber]

Am 10.04.2013 14:03, schrieb Matthias Ringwald:
> hi
>
> On Apr 10, 2013, at 1:56 PM, András Balogh <xba...@gmail.com> wrote:
>
>>
>>> The CC256x should always respond to an HCI Reset command.
>>
>> Well, actually mine does not - definitely.
>>
>> The init script 2.44 also puts the module in HCILL mode, which I did
>> comment out. After that everything behaved pretty normal and HCI Reset
>> command worked as expected.
>
> Well, that's because YOU (Nils) put it into HCILL mode. After a cold start, it does respond to HCI Reset.

He, I can not let that stand without reply ;)

Yes, I am aware that the init script put my module to HCILL which caused
a seemingly unresponsive module after loading the script.

BUT my module also does not respond to e.g. an HCI reset command
*before* loading the script.

I do not have the script at hand right now and so don't know which
command is sent first, but after the first init script command the
module starts to reply, at least to the script commands (I can see tons
of command complete events with status 0x00 while the script loads).

Again, a normal HCI reset did not work after just applying clock, RTS
and releasing shutdown. This was at least with the CC2560 I tried.

> In fact, the init script consists of HCI commands, so if the module doesn't respond to commands, you cannot send it the init script.

Maybe the first command in the script is a "special" command to wake the
chip?

> Can you double check that
> - the 32k clock is there
> - the Shutdown pin has the NOT-Shutdown level
> - the CTS/RTS stuff is configured correctly
> - the TX data reaches the module at the correct ping
>
> (sorry; don't remember the details, but please check the MSP430 sources for details)
>
> also, is that module easy to use? It's certainly easier to solder as the PAN132x modules. What antenna do you use? Any other thing that oe should consider when using it for a hobby project?
>
> matthias

Cheers
nils

>>
>> OK. I will try to load the init script on the module, and see if after that it works or not.
>> Thank you for answers.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
>> To post to this group, send email to btsta...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>

[Matthias Ringwald]

On Apr 10, 2013, at 2:43 PM, Nils Faerber <nils.f...@kernelconcepts.de> wrote:

… some drama ….

> BUT my module also does not respond to e.g. an HCI reset command
> *before* loading the script.
>
> I do not have the script at hand right now and so don't know which
> command is sent first, but after the first init script command the
> module starts to reply, at least to the script commands (I can see tons
> of command complete events with status 0x00 while the script loads).
>
> Again, a normal HCI reset did not work after just applying clock, RTS
> and releasing shutdown. This was at least with the CC2560 I tried.
>
>> In fact, the init script consists of HCI commands, so if the module doesn't respond to commands, you cannot send it the init script.
>
> Maybe the first command in the script is a "special" command to wake the
> chip?

Interesting. So you might be correct after all! :)

If the first command isn't a HCI Reset, I'm sure it's an undocumented vendor command..

cheers
matthias

[András Balogh]

I tried sending the first command from the init script, but there still was no response...I am using the 2.8 in which the first command is:

"0x01 0x37 0xFE 0x02 0x06 0x0F" (OCF and OGF is far beyond the specified limits, so its completely vendor specific...)
And the TI documentation says its GAP BOND GET PARAMETER...which has no sense after all...

What is more interesting that I tried to "DoS attack" the module (causing buffer overflow, or st), to see if it is actually
responding or not, and got no answer (RTS was never pulled up...). There should have been an event telling st, but there was not...

[András Balogh]

Hi again,

Maybe the module doesn't have a firmware on it? Should have I specified something at the ordering procedure?
Or every module, from cold start should respond to reset or the first HCI command in the init script?

Is there any HCI command sent in the msp430 project prior to the init script?
Till now I tried to figure it out using the source code, but unfortunately with no luck...

Thank you for help!

Andras

[Matthias Ringwald]

Hi

(some mails before, I referred to connecting the RX/TX to the correct pins, it's easy to swap them etc.)

BTstack always sends an HCI Reset as very first command, then a baud change if requested and then the init script. The init script is on the order of 60kB on the older C2560, so sending that at 1 mbps was much faster than at 115 kbps..

If you didn't get any response, and usually you would get an Hardware Error very quickly for just messing up the packet format, I guess either your module is broken, or the wiring is not correct (sorry, no further details here..)

Best

 Matthias

[András Balogh]

Hi,

Then I should try this all, with an other module...

Thank You for help!

Best regards,

Andras

[András Balogh]

Hi,

Finally! After the change of the module, it started answering. So it was simply broken, as You said before.

But I tried the HCI write scan enable (0x01 - only Inquiry) command, and it always responded SUCCESS, though it is not discoverable (it was once, but after that...nothing) at all...

Since this is a really BT specific thing, I tried loading the SP (Init Script), and after that I'm facing the same problem...no answer (not even for a simple Reset command)
I commented out the eHCILL, and the fast clock Xtal support, but I am not sure about the connection of these features to the error...

Also there is a period in the loading (SP), when the RTS is high for quite a long time...

Even though that's much more than it was before, so thank you for helping me...

Best Regards,

Andras

[Bruno Montenegro]

Hello,

Just a simple qUestions....

Is the bluetooth module USB?? Or is it serial one?? I'm asking this because, in the past, I've faced similar problems with slvae only serial bluetooth modules...

Bruno

--
---------------------------
Bruno Montenegro

[Matthias Ringwald]

Hi

On Apr 17, 2013, at 4:09 PM, András Balogh <xba...@gmail.com> wrote:
> But I tried the HCI write scan enable (0x01 - only Inquiry) command, and it always responded SUCCESS, though it is not discoverable (it was once, but after that...nothing) at all…

That's to be expected without the init script.

>
> Since this is a really BT specific thing, I tried loading the SP (Init Script), and after that I'm facing the same problem...no answer (not even for a simple Reset command)

> I commented out the eHCILL, and the fast clock Xtal support, but I am not sure about the connection of these features to the error…

If you enable eHCILL, it will quickly go to sleep and you have to wake it first (but probably didn't implement the code for that). So, don't enable it for now. Don't know about fast clock xtal, I never touched anything there.
>
> Also there is a period in the loading (SP), when the RTS is high for quite a long time…

There are some warm reset commands in there, that could cause a short (few hundred ms) pause.

> Even though that's much more than it was before, so thank you for helping me…

Just follow the init script and see if you get an event for every CMD you send. You're using the BTstack code for this, no? :)

m.

[András Balogh]

Following the init script is not a simple thing in my situation...

I am using an AVR (xmega) controller, and i want to expose the module (i.e. make it discoverable), by making it do inquiry scans, and sending advertisements on BLE advertising channels.
To achieve this I planned to use simple HCI commands. Because of this simple approach, I don't think the whole BTstack is needed right now...so there is no need for a complex uC, like MSP430 after all.

As I have seen in the source you are controlling the CTS/RTS (I am supposing by UART frames) from hardware. This function in my uC is not available, so I need to handle these things from uC by reading up the current states of the CTS/RTS pins. What I have found out, is that the CC2564 is using edge-controlled logic for that (correct me if I'm wrong...), and that makes catching an event (the starting time of which is unknown) a bit difficult...

Can it be somehow biased? (Not all of the commands are public at all, so are the events...)

[Nils Faerber]

Am 17.04.2013 16:44, schrieb András Balogh:
> Following the init script is not a simple thing in my situation...
>
> I am using an AVR (xmega) controller, and i want to expose the module
> (i.e. make it discoverable), by making it do inquiry scans, and sending
> advertisements on BLE advertising channels.
> To achieve this I planned to use simple HCI commands. Because of this
> simple approach, I don't think the whole BTstack is needed right
> now...so there is no need for a complex uC, like MSP430 after all.
>
> As I have seen in the source you are controlling the CTS/RTS (I am
> supposing by UART frames) from hardware. This function in my uC is not

I am controlling RTC/CTS in software too - just two GPIOs, one input one
output. Pretty easy. Before sending data to the module I check CTS and
if my input buffer is almost full I raise my RTS.
You can definitely do this with almost any AVR too.

> available, so I need to handle these things from uC by reading up the
> current states of the CTS/RTS pins. What I have found out, is that the
> CC2564 is using edge-controlled logic for that (correct me if I'm
> wrong...), and that makes catching an event (the starting time of which
> is unknown) a bit difficult...

Why so complicated?
Just poll the GPIOs before sending the data.
You can also send and receive data from the UART byte by byte, so
between the bytes you have all control to check for the hardware
handshake lines.

> Can it be somehow biased? (Not all of the commands are public at all, so
> are the events...)

Cheers
nils

[András Balogh]

Hi,

You were right, it just seemed to be difficult. Now it works like charm.
I really appreciate all of your help.

What I needed to do, was to get (read) all of the events...after it was done, it was answering for all
HCI commands...

Now I am facing another problem, but I will start a different thread for that...

Thank (all of) you again!

Best Regards

András Balogh

[Michał Plebański]

I know it's a bit old, but I'm facing the same issue. Did your 1st BT controller was actually broken or was it the issue with ehcill support? Mine cc256x isn't responding to basic reset command, I double checked the connectivity and I'm pretty sure it's ok. Before I order 2nd controller I would like to check if it is maybe due to ehcill putting controller to sleep. 

[Matthias Ringwald]

Hi

Ehcill uses 0x30-0x33. It wont trigger so early - in fact, it will be enabled, if configured, as part of the custom init. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.

Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.

[Michał Plebański]

Hello,

Could you tell me the exact format of data in RESEND HCI Reset, please? (lenght, bytes) I could compare it to the outgoing traffic on my platform. Maybe something is corrupted.

[Matthias Ringwald]

Hi Michał

No problem. The very first message is HCI Reset and it will be on the UART:

0x01 0x03 0x0c 0x00

The response should then be an HCI Event Command Complete

0x04 0x0e 0x04 0x01 0x03 0x0c 0x00

Best

 Matthias

[Michał Plebański]

Sorry for my delayed responses. 

I managed to read BLE advertisements on my mobile finally, thanks to you. 

Yet there is stilll one thing that bothers me in those logs:

I can't decode this sequence:

0x01 0x03 0x0c 0x00 
I understand from spec that 0x03 is OCF for reset command, but what about OGF which is equal to 0x03 for Controller & Baseband Commands? 
What does the 0x01 and 0x0c 0x00 means? Spec says that reset takes no arguments. I'm missing something big here.

Same goes for 

0x04 0x0e 0x04 0x01 0x03 0x0c 0x00

Now I know that 0x0e is a Event Complete Event, and 0x04 that follows is a parameter length variable. Again:

What does the first byte 0x04 and the last four bytes mean? OGF for Events equals 0x08

If I decode those I will be able to decode every logged packet. 

[Matthias Ringwald]

Hello Michal

the first byte is the packet type: 0x01 HCI CMD, 0x02 HCI ACL, 0x03 HCI SCO, and 0x04 HCI EVENT

Then, 0x03 0x0c match the opcode for HCI RESET. The 0x00 is the len for the arguments, so no arguments here.

Similar for the Command Complete event. 0x04 packet type, 0x0e command complete event, 0x04 len of remaining params, 0x01 = 1 HCI command can be sent, 0x03 0x0c opcode for HCI Reset, and finally 0x00 for Status = 0 == OK

but...

as this is tedious, you can process the console output with tools/create_packet_log.py and open it with Wireshark for better readability

best

matthias