eZ430-RF2560 debug messages
283 views
Skip to first unread message
car...@k2.t.u-tokyo.ac.jp
Feb 18, 2012, 1:45:32 AM2/18/12
to btstack-dev
I was quite excited to see the addition of an eZ430-RF2560 directory
to btstack. Today I compiled the examples and uploaded a few to my
development kit. I've noticed that the led_counter program operates
correctly, but when I try to observe its debug messages I see things
like the following:
BTstack counter 0212
BTsBTacn 1
BTacn 217BTacn 2
BTacn 2
Usually the first message is clear but subsequent lines are garbled.
I'm assuming I should use /dev/ttyACM0 from Linux with the parameters
9600,8,N,1 to view the debug messages. The process I used was:
# checkout btstack
svn checkout http://btstack.googlecode.com/svn/trunk/ btstack-read-
only
# place missing files into chipset-cc256x directory
# copy BTPSVEND.c to chipset-cc256x
# copy bluetooth_init_cc2560_2.42.bts to chipset-cc256x
# make examples
cd eZ430-RF2560/example
make
# program device
mspdebug rf2500 'prog led_counter.out'
# open serial connection
screen /dev/ttyACM0
to btstack. Today I compiled the examples and uploaded a few to my
development kit. I've noticed that the led_counter program operates
correctly, but when I try to observe its debug messages I see things
like the following:
BTstack counter 0212
BTsBTacn 1
BTacn 217BTacn 2
BTacn 2
Usually the first message is clear but subsequent lines are garbled.
I'm assuming I should use /dev/ttyACM0 from Linux with the parameters
9600,8,N,1 to view the debug messages. The process I used was:
# checkout btstack
svn checkout http://btstack.googlecode.com/svn/trunk/ btstack-read-
only
# place missing files into chipset-cc256x directory
# copy BTPSVEND.c to chipset-cc256x
# copy bluetooth_init_cc2560_2.42.bts to chipset-cc256x
# make examples
cd eZ430-RF2560/example
make
# program device
mspdebug rf2500 'prog led_counter.out'
# open serial connection
screen /dev/ttyACM0
Matthias Ringwald
Feb 21, 2012, 3:17:03 PM2/21/12
to btsta...@googlegroups.com
Hi Carson
Someone on this list said he got BTstack working on that hardware. I've update the configuration to use the right UART/PINS/etc.. and gave it a quick spin. As far as I remember, the debug output was working fine, but I couldn't see my device in a device scan. Then some other task came along and I was already annoyed by the slowness of the spy-by-wire programming (using mspdebug->fet430-uif->battery holder->eZ430-RF2560 as I don't have much luck with the drivers for the TUSB3410 USB-2-UART chips).
Could you add a first printf("Started...\n") to see if the device is rebooting?
Could those guys getting BTstack to run on that device tell me what I've missed :) ?
Best
Matthias
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
car...@k2.t.u-tokyo.ac.jp
Feb 22, 2012, 4:48:50 AM2/22/12
to btstack-dev
Matthais,
Thanks for considering the matter. We put in the diagnostic printf you
suggested. Judging from its output and the counter I don't think it is
resetting. Here is a sample of the output after a initializing:
Stt.R.
BTacn 0
BTacn 002BTacn 0
BTcct 04BTtacoe 5BTacun
The initial text seems to have morphed from "Starting..." to "Stt.R."
The counter is steadily increasing but with each line the terminal
output is a bit scrambled. Just to be safe we tried it on the second
module supplied in the development kit and the results were the same
which may rule out a problem specific to one module.
I'd be curious if other eZ430-RF2560 can reproduce this problem. In
the mean time we'd be happy to try out further test cases to diagnose
the problem.
-carson-
On Feb 22, 5:17 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
Thanks for considering the matter. We put in the diagnostic printf you
suggested. Judging from its output and the counter I don't think it is
resetting. Here is a sample of the output after a initializing:
Stt.R.
BTacn 0
BTacn 002BTacn 0
BTcct 04BTtacoe 5BTacun
The initial text seems to have morphed from "Starting..." to "Stt.R."
The counter is steadily increasing but with each line the terminal
output is a bit scrambled. Just to be safe we tried it on the second
module supplied in the development kit and the results were the same
which may rule out a problem specific to one module.
I'd be curious if other eZ430-RF2560 can reproduce this problem. In
the mean time we'd be happy to try out further test cases to diagnose
the problem.
-carson-
On Feb 22, 5:17 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
Risto Kivela
Feb 22, 2012, 8:01:19 PM2/22/12
to btsta...@googlegroups.com
Hi Matthias,
I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to
program...
Thanks,
- Risto -
From: Matthias Ringwald <matthias...@gmail.com>
To: btsta...@googlegroups.com
Sent: Tuesday, February 21, 2012 2:17 PM
Subject: Re: eZ430-RF2560 debug messages
> To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To post to this group, send email to btsta...@googlegroups.com.
To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
Matthias Ringwald
Feb 23, 2012, 8:59:00 AM2/23/12
to btsta...@googlegroups.com
Hi Risto
thanks for checking. Cool, you got farther then me with my code. :)
hal_uart_dma_init() is called during open() of src/hci_transport_h4_dma.c resp. src/hci_transport_h4_ehcill_dma.c
Has the debut output worked for you?
Best
Matthias
On Feb 23, 2012, at 2:01 AM, Risto Kivela wrote:
> Hi Matthias,
>
> I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> Thanks,
>
> - Risto -
>
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
Risto Kivela
Feb 23, 2012, 9:38:23 AM2/23/12
to btsta...@googlegroups.com
Yes, the debug port worked fine @ 9600, 8, N, 1 settings on putty terminal. I didn't see any data corruption.
I did have the stock accelerometer up and running too on this eZ430 board with BTstack, using polling though. Using interrupts I had to disable the debug port as I didn't dive into correct int handling for enabling both interfaces - I'm not experienced in msp430 programming (or any C programming)...
Thanks,
- Risto -
Sent: Thursday, February 23, 2012 7:59 AM
> > To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> > For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To post to this group, send email to btsta...@googlegroups.com.
To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
car...@k2.t.u-tokyo.ac.jp
Feb 25, 2012, 2:43:22 AM2/25/12
to btstack-dev
Dear Mitthias and Risto,
It appears that there is something specific to Ubuntu Linux 11.10
which is causing the garbling. From Windows 7 and PuTTY we're able to
connect to the device and see clear messages:
rfcomm_send_internal cid 117 doesn't exist!
BTstack counter 26230
rfcomm_send_internal cid 117 doesn't exist!
BTstack counter 26231
So now we're left to figure out what is specific about Ubuntu's
handling of the serial port as /dev/ttyACM0 is introducing the serial
communication errors. The garbled out put appears irrespective of
client (we've tried screen, minicom, cutecom, kermit so far).
Out of curiosity I thought I'd see what happen on OS X 10.7 and it
looks like by default a tty is not created. A console message states:
2/25/12 3:29:25.000 PM kernel: 0 0 AppleUSBCDCACMControl: start
- configureACM failed
But at least we're making some headway in diagnosing the problem. I'll
try a follow up question on askubuntu.com to see if we can get some
pointers about how to proceed with the Ubuntu specific problem.
-carson-
On Feb 23, 11:38 pm, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Yes, the debug port worked fine @ 9600, 8, N, 1 settings on putty terminal. I didn't see any data corruption.
>
> I did have the stock accelerometer up and running too on this eZ430 board with BTstack, using polling though. Using interrupts I had to disable the debug port as I didn't dive into correct int handling for enabling both interfaces - I'm not experienced in msp430 programming (or any C programming)...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: Matthias Ringwald <matthias.ringw...@gmail.com>
> > > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
It appears that there is something specific to Ubuntu Linux 11.10
which is causing the garbling. From Windows 7 and PuTTY we're able to
connect to the device and see clear messages:
rfcomm_send_internal cid 117 doesn't exist!
BTstack counter 26230
rfcomm_send_internal cid 117 doesn't exist!
BTstack counter 26231
So now we're left to figure out what is specific about Ubuntu's
handling of the serial port as /dev/ttyACM0 is introducing the serial
communication errors. The garbled out put appears irrespective of
client (we've tried screen, minicom, cutecom, kermit so far).
Out of curiosity I thought I'd see what happen on OS X 10.7 and it
looks like by default a tty is not created. A console message states:
2/25/12 3:29:25.000 PM kernel: 0 0 AppleUSBCDCACMControl: start
- configureACM failed
But at least we're making some headway in diagnosing the problem. I'll
try a follow up question on askubuntu.com to see if we can get some
pointers about how to proceed with the Ubuntu specific problem.
-carson-
On Feb 23, 11:38 pm, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Yes, the debug port worked fine @ 9600, 8, N, 1 settings on putty terminal. I didn't see any data corruption.
>
> I did have the stock accelerometer up and running too on this eZ430 board with BTstack, using polling though. Using interrupts I had to disable the debug port as I didn't dive into correct int handling for enabling both interfaces - I'm not experienced in msp430 programming (or any C programming)...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> To: btsta...@googlegroups.com
> Sent: Thursday, February 23, 2012 7:59 AM
> Subject: Re: eZ430-RF2560 debug messages
>
> Hi Risto
>
> thanks for checking. Cool, you got farther then me with my code. :)
>
> hal_uart_dma_init() is called during open() of src/hci_transport_h4_dma.c resp. src/hci_transport_h4_ehcill_dma.c
>
> Has the debut output worked for you?
>
> Best
> Matthias
>
> On Feb 23, 2012, at 2:01 AM, Risto Kivela wrote:
>
>
>
>
>
>
>
>
>
> > Hi Matthias,
>
> > I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> > I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> > Thanks,
>
> > - Risto -
>
> Sent: Thursday, February 23, 2012 7:59 AM
> Subject: Re: eZ430-RF2560 debug messages
>
> Hi Risto
>
> thanks for checking. Cool, you got farther then me with my code. :)
>
> hal_uart_dma_init() is called during open() of src/hci_transport_h4_dma.c resp. src/hci_transport_h4_ehcill_dma.c
>
> Has the debut output worked for you?
>
> Best
> Matthias
>
> On Feb 23, 2012, at 2:01 AM, Risto Kivela wrote:
>
>
>
>
>
>
>
>
>
> > Hi Matthias,
>
> > I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> > I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> > Thanks,
>
> > - Risto -
>
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
priyasheel
Feb 25, 2012, 8:45:08 AM2/25/12
to btstack-dev
Hi Risto,
Could you please tell what is "eCHILL" in spp_counter.c and
spp_flowcontrol.c ?
Thank you
Best,
Priyasheel
On Feb 23, 10:01 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Matthias,
>
> I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: Matthias Ringwald <matthias.ringw...@gmail.com>
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
Could you please tell what is "eCHILL" in spp_counter.c and
spp_flowcontrol.c ?
Thank you
Best,
Priyasheel
On Feb 23, 10:01 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Matthias,
>
> I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
priyasheel
Feb 25, 2012, 3:01:52 AM2/25/12
to btstack-dev
Hi Risto
Can you please explain what do you mean by eCHILL ?
Thanks
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
Can you please explain what do you mean by eCHILL ?
Thanks
> Hi Matthias,
>
> I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: Matthias Ringwald <matthias.ringw...@gmail.com>
>
> I've had BTstack running on the eZ430 board for a while now. I took a quick peek at your new files in the eZ430-RF2560 directory and it seems that the main program files spp_counter.c and spp_flowcontrol.c are missing the hal_uart_dma_init(); call from the main function. Also I have not been able to get anything running with eCHILL on, so I've just commented that out in the main function. With these two changes I can pair with your new eZ430 examples with my Android phone.
>
> I haven't found the spywire programming that slow. I've been using the Windows FET-Pro430 Lite, which is free and supports eZ430 board. The blank checking needs to be turned off however. With that on it takes a while to program...
>
> Thanks,
>
> - Risto -
>
> ________________________________
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
Risto Kivela
Feb 26, 2012, 6:29:06 PM2/26/12
to btsta...@googlegroups.com
Hi Priyasheel,
Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
// use eHCILL
// bt_control_cc256x_enable_ehcill(1);
// bt_control_cc256x_enable_ehcill(1);
Thanks,
- Risto -
From: priyasheel <priyash...@gmail.com>
To: btstack-dev <btsta...@googlegroups.com>
Sent: Saturday, February 25, 2012 7:45 AM
> > To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To
unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To post to this group, send email to btsta...@googlegroups.com.
To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
priyasheel
Feb 29, 2012, 5:08:34 AM2/29/12
to btstack-dev
Hi,
With the "eHCILL " commented out and "hal_uart_dma_init();" added to
the main function, the EZ430-RF2560 device can be detected by an
android
device/ computer running Ubuntu and OS X but this seems to be true
even if only "eHCILL " commented out without adding
"hal_uart_dma_init();" to the main function. On executing:
$ hcitool scan
Scanning ...
B8:FF:FE:AE:CB:E4 n/a
The device is listed as n/a. Similarly OS X lists the device type as
unknown. Furthermore sdptool provides the following output:
$ sdptool browse B8:FF:FE:AE:CB:E4
Failed to connect to SDP server on B8:FF:FE:AE:CB:E4: Host is down
I'd expect to see some sort of SPP Service class, but perhaps further
configuration is necessary. In any case thank you for helping us get
further along in our debugging experiments.
Best,
Priyasheel
On Feb 27, 8:29 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Priyasheel,
>
> Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> // use eHCILL
> // bt_control_cc256x_enable_ehcill(1);
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: priyasheel <priyasheel1...@gmail.com>
> > > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
With the "eHCILL " commented out and "hal_uart_dma_init();" added to
the main function, the EZ430-RF2560 device can be detected by an
android
device/ computer running Ubuntu and OS X but this seems to be true
even if only "eHCILL " commented out without adding
"hal_uart_dma_init();" to the main function. On executing:
$ hcitool scan
Scanning ...
B8:FF:FE:AE:CB:E4 n/a
The device is listed as n/a. Similarly OS X lists the device type as
unknown. Furthermore sdptool provides the following output:
$ sdptool browse B8:FF:FE:AE:CB:E4
Failed to connect to SDP server on B8:FF:FE:AE:CB:E4: Host is down
I'd expect to see some sort of SPP Service class, but perhaps further
configuration is necessary. In any case thank you for helping us get
further along in our debugging experiments.
Best,
Priyasheel
On Feb 27, 8:29 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Priyasheel,
>
> Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> // use eHCILL
> // bt_control_cc256x_enable_ehcill(1);
>
> Thanks,
>
> - Risto -
>
> ________________________________
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
Matthias Ringwald
Mar 2, 2012, 9:03:36 AM3/2/12
to btsta...@googlegroups.com
Hi
Aside from the FET430 UIF, I haven't been able to get any of the TI devices with the TUSB3410 USB-to-UART chip to work on Mac. I'll have to admit, I gave up pretty quickly. I'm now just soldering wires to the UART debug lines and use on of those FTDI USB-2-UART boards that are popular with Android devices to get me a debug output.
For the eZ430-RF2560, it's easy to plug the device into the battery holder and solder wires to through holes there.
Best
Matthias
Matthias Ringwald
Mar 2, 2012, 9:06:01 AM3/2/12
to btsta...@googlegroups.com
Hi Risto
k. Noted. When I'll play with the eZ430-RF2560 next time, I'll double check the eHCILL stuff = setup of CTS lines and IRQ.
Best
Matthias
On Feb 27, 2012, at 12:29 AM, Risto Kivela wrote:
> Hi Priyasheel,
>
> Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> // use eHCILL
> // bt_control_cc256x_enable_ehcill(1);
>
> Thanks,
>
> - Risto -
>
> > > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
car...@k2.t.u-tokyo.ac.jp
Mar 15, 2012, 8:05:34 AM3/15/12
to btsta...@googlegroups.com
A short follow up on this issue. We did some testing with another notebook and the text came through clear. At this point the bug seems to be related to the combination particular notebook (Thinkpad X220) and Ubuntu version 11.10.
-carson-
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
priyasheel
Mar 19, 2012, 5:45:26 AM3/19/12
to btstack-dev
Hi,
The output string from "spp_flowcontrol.c" is sometimes garbled and
sometimes not (we even tried a fresh install on new hardware but still
the problem persists).
My msp430-gcc version is 4.5.3 and mspdebug version is 0.16. I am
curious, what version of msp430-gcc are you using for development?
Thank you
Priyasheel
On Mar 2, 11:06 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
The output string from "spp_flowcontrol.c" is sometimes garbled and
sometimes not (we even tried a fresh install on new hardware but still
the problem persists).
My msp430-gcc version is 4.5.3 and mspdebug version is 0.16. I am
curious, what version of msp430-gcc are you using for development?
Thank you
Priyasheel
On Mar 2, 11:06 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
> Hi Risto
>
> k. Noted. When I'll play with the eZ430-RF2560 next time, I'll double check the eHCILL stuff = setup of CTS lines and IRQ.
>
> Best
> Matthias
>
> On Feb 27, 2012, at 12:29 AM, Risto Kivela wrote:
>
>
>
>
>
>
>
> > Hi Priyasheel,
>
> > Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> > // use eHCILL
> > // bt_control_cc256x_enable_ehcill(1);
>
> > Thanks,
>
> > - Risto -
>
>
> k. Noted. When I'll play with the eZ430-RF2560 next time, I'll double check the eHCILL stuff = setup of CTS lines and IRQ.
>
> Best
> Matthias
>
> On Feb 27, 2012, at 12:29 AM, Risto Kivela wrote:
>
>
>
>
>
>
>
> > Hi Priyasheel,
>
> > Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> > // use eHCILL
> > // bt_control_cc256x_enable_ehcill(1);
>
> > Thanks,
>
> > - Risto -
>
car...@k2.t.u-tokyo.ac.jp
Mar 26, 2012, 7:41:55 AM3/26/12
to btsta...@googlegroups.com
After many experiments we discovered that this "garbling" is due to interference between the program accessing the serial port (such as screen, kermit, or minicom) and mspdebug, which is used to load programs. During the programming process of the msp430 we can see a warning message from mspdebug indicating:
"Warning: rf2500: warning: can't detach kernel driver: No data available"
After seeing this message, the output of the msp430 is garbled and subsequent programming will be corrupted until there is a reboot. Perhaps mspdebug should exit when it can't detach the kernel driver? In any case this is not a btstack issue.
-carson-
> > > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > > To post to this group, send email to btsta...@googlegroups.com.
> > > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/btstack-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> > To post to this group, send email to btsta...@googlegroups.com.
> > To unsubscribe from this group, send email to btstack-dev+unsubscribe@googlegroups.com.
Risto Kivela
Mar 27, 2012, 9:30:47 PM3/27/12
to Ralf Ackermann, btsta...@googlegroups.com
Hi Ralf,
I'm guessing you were testing the test binary I sent to Martijn?
I didn't have ton's of time today after work to investigate, but I compared the files I downloaded about a month ago to test the spp_counter for Priyasheel (down in this thread) to ones I've been using for my project (these are from 10/29/2011). I downloaded a bluetooth spp tester and with new files I do see issues with connection going on and off with the new files.
With initial look it seems that there could be some issues with the new chipset files? I grabbed the old ones I was using and changed the new Makefile:
${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
With this change the spp_counter stays paired, the RFCOMM channel opens up and stays up, but the counter stops counting :) The red led does not flash anymore and debug terminal does not print any counts. With the old files the counter keeps counting... The bluetooth spp test application I was using was sending acccelerometer data towards the BTstack, but this should not make any difference.
Thanks,
- Risto -
From: Ralf Ackermann <rac...@me.com>
To: btsta...@googlegroups.com; risto_...@yahoo.com
Sent: Monday, March 26, 2012 7:17 AM
Subject: Re: eZ430-RF2560 debug messages
Dear all, dear Risto,
as an important side note: I was able to use Risto's test binary - and it repeatedly (I re-flashed
it several times after unsuccessful tests with the binary generated from the code in the repository)
it several times after unsuccessful tests with the binary generated from the code in the repository)
works fine (can pair from OSX, can see the counting up on the receiving side with a terminal program on OSX).
=> Seems to me that a most efficient way to proceed would be to really fully check against the
source code that Risto used.
@Risto: Would you be able to either do so or alternatively share an archive of the code you used
so that somebody else could compare in detail with what is in the repository now.
Also -
could we do a re-check of the toolchain (did you use the OSX toolchain provided
by fink - or something else?) so we can be sure this is not what made the difference for
the working version.
I'd be very interested to also spent effort to finally make the things work for all interested users.
best regards
Ralf
To view this discussion on the web visit https://groups.google.com/d/msg/btstack-dev/-/7t1ccHThN64J.
To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
Risto Kivela
Mar 27, 2012, 9:45:17 PM3/27/12
to btsta...@googlegroups.com, Ralf Ackermann
Just a quick additional note. The counter seems to stay counting with the new files (using the old chipset files) when the eZ430 module is not connected to the debug port, so it could be that the debug UART gets clogged up with all the accelerometer data from my phone. The red led flashes a lot so there's probably more data than 9600 bauds can handle...
- Risto -
From: Risto Kivela <risto_...@yahoo.com>
To: Ralf Ackermann <rac...@me.com>; "btsta...@googlegroups.com" <btsta...@googlegroups.com>
Sent: Tuesday, March 27, 2012 8:30 PM
priyasheel
Mar 29, 2012, 5:51:22 AM3/29/12
to btstack-dev
Hi Risto,
The fingerprint for the chipset files I'm using are as follows:
${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c
\ a530e26db25c9f57a42813bb3d74b396
${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c
\ 02833c6d4dc1b3bcdc84e5d7ff32d33b
Could you confirm whether the chipset files which you are using are
the same as mine. If not, where to find the ones you used ?
Thank you
Best,
Priyasheel
On Mar 28, 10:30 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Ralf,
>
> I'm guessing you were testing the test binary I sent to Martijn?
>
> I didn't have ton's of time today after work to investigate, but I compared the files I downloaded about a month ago to test the spp_counter for Priyasheel (down in this thread) to ones I've been using for my project (these are from 10/29/2011). I downloaded a bluetooth spp tester and with new files I do see issues with connection going on and off with the new files.
>
> With initial look it seems that there could be some issues with the new chipset files? I grabbed the old ones I was using and changed the new Makefile:
>
> ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
> ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
>
> With this change the spp_counter stays paired, the RFCOMM channel opens up and stays up, but the counter stops counting :) The red led does not flash anymore and debug terminal does not print any counts. With the old files the counter keeps counting... The bluetooth spp test application I was using was sending acccelerometer data towards the BTstack, but this should not make any difference.
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: Ralf Ackermann <rac...@me.com>
> To: btsta...@googlegroups.com; risto_kiv...@yahoo.com
> >To view this discussion on the web visithttps://groups.google.com/d/msg/btstack-dev/-/7t1ccHThN64J.
The fingerprint for the chipset files I'm using are as follows:
${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c
\ a530e26db25c9f57a42813bb3d74b396
${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c
\ 02833c6d4dc1b3bcdc84e5d7ff32d33b
Could you confirm whether the chipset files which you are using are
the same as mine. If not, where to find the ones you used ?
Thank you
Best,
Priyasheel
On Mar 28, 10:30 am, Risto Kivela <risto_kiv...@yahoo.com> wrote:
> Hi Ralf,
>
> I'm guessing you were testing the test binary I sent to Martijn?
>
> I didn't have ton's of time today after work to investigate, but I compared the files I downloaded about a month ago to test the spp_counter for Priyasheel (down in this thread) to ones I've been using for my project (these are from 10/29/2011). I downloaded a bluetooth spp tester and with new files I do see issues with connection going on and off with the new files.
>
> With initial look it seems that there could be some issues with the new chipset files? I grabbed the old ones I was using and changed the new Makefile:
>
> ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
> ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
>
> With this change the spp_counter stays paired, the RFCOMM channel opens up and stays up, but the counter stops counting :) The red led does not flash anymore and debug terminal does not print any counts. With the old files the counter keeps counting... The bluetooth spp test application I was using was sending acccelerometer data towards the BTstack, but this should not make any difference.
>
> Thanks,
>
> - Risto -
>
> ________________________________
> From: Ralf Ackermann <rac...@me.com>
priyasheel
Mar 29, 2012, 5:55:19 AM3/29/12
to btstack-dev
I used md5sum <file name> to generate the fingerprint for the files.
On Mar 29, 6:51 pm, priyasheel <priyasheel1...@gmail.com> wrote:
> HiRisto,
> ...
>
> read more »
On Mar 29, 6:51 pm, priyasheel <priyasheel1...@gmail.com> wrote:
> HiRisto,
>
> The fingerprint for the chipset files I'm using are as follows:
>
> ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c
> \ a530e26db25c9f57a42813bb3d74b396
> ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c
> \ 02833c6d4dc1b3bcdc84e5d7ff32d33b
>
> Could you confirm whether the chipset files which you are using are
> the same as mine. If not, where to find the ones you used ?
>
> Thank you
> Best,
> Priyasheel
>
> The fingerprint for the chipset files I'm using are as follows:
>
> ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c
> \ a530e26db25c9f57a42813bb3d74b396
> ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c
> \ 02833c6d4dc1b3bcdc84e5d7ff32d33b
>
> Could you confirm whether the chipset files which you are using are
> the same as mine. If not, where to find the ones you used ?
>
> Thank you
> Best,
> Priyasheel
>
> On Mar 28, 10:30 am,RistoKivela <risto_kiv...@yahoo.com> wrote:
>
>
>
>
>
>
>
> > Hi Ralf,
>
> > I'm guessing you were testing the test binary I sent to Martijn?
>
> > I didn't have ton's of time today after work to investigate, but I compared the files I downloaded about a month ago to test the spp_counter for Priyasheel (down in this thread) to ones I've been using for my project (these are from 10/29/2011). I downloaded a bluetooth spp tester and with new files I do see issues with connection going on and off with the new files.
>
> > With initial look it seems that there could be some issues with the new chipset files? I grabbed the old ones I was using and changed the new Makefile:
>
> > ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
> > ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
>
> > With this change the spp_counter stays paired, the RFCOMM channel opens up and stays up, but the counter stops counting :) The red led does not flash anymore and debug terminal does not print any counts. With the old files the counter keeps counting... The bluetooth spp test application I was using was sending acccelerometer data towards the BTstack, but this should not make any difference.
>
> > Thanks,
>
> > -Risto-
>
> > ________________________________
> > From: Ralf Ackermann <rac...@me.com>
> > To: btsta...@googlegroups.com; risto_kiv...@yahoo.com
> > Sent: Monday, March 26, 2012 7:17 AM
> > Subject: Re: eZ430-RF2560 debug messages
>
> > Dear all, dearRisto,
>
> > as an important side note: I was able to useRisto'stest binary - and it repeatedly (I re-flashed
>
>
>
>
>
>
>
> > Hi Ralf,
>
> > I'm guessing you were testing the test binary I sent to Martijn?
>
> > I didn't have ton's of time today after work to investigate, but I compared the files I downloaded about a month ago to test the spp_counter for Priyasheel (down in this thread) to ones I've been using for my project (these are from 10/29/2011). I downloaded a bluetooth spp tester and with new files I do see issues with connection going on and off with the new files.
>
> > With initial look it seems that there could be some issues with the new chipset files? I grabbed the old ones I was using and changed the new Makefile:
>
> > ${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
> > ${BTSTACK_ROOT}/chipset-cc256x/cc2567_init_script.c \
>
> > With this change the spp_counter stays paired, the RFCOMM channel opens up and stays up, but the counter stops counting :) The red led does not flash anymore and debug terminal does not print any counts. With the old files the counter keeps counting... The bluetooth spp test application I was using was sending acccelerometer data towards the BTstack, but this should not make any difference.
>
> > Thanks,
>
> > -Risto-
>
> > ________________________________
> > From: Ralf Ackermann <rac...@me.com>
> > To: btsta...@googlegroups.com; risto_kiv...@yahoo.com
> > Sent: Monday, March 26, 2012 7:17 AM
> > Subject: Re: eZ430-RF2560 debug messages
>
> > Dear all, dearRisto,
>
> > >>> On Feb 27, 2012, at 12:29 AM,RistoKivela wrote:
>
> > >>> > Hi Priyasheel,
>
> > >>> > Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> > >>> > // use eHCILL
> > >>> > // bt_control_cc256x_enable_ehcill(1);
>
> > >>> > Thanks,
>
> > >>> > -Risto-
>
> > >>> > From: priyasheel <priyasheel1...@gmail.com>
> > >>> > To: btstack-dev <btsta...@googlegroups.com>
> > >>> > Sent: Saturday, February 25, 2012 7:45 AM
> > >>> > Subject: Re: eZ430-RF2560 debug messages
>
> > >>> > HiRisto,
>
> > >>> > Could you please tell what is "eCHILL" in spp_counter.c and
> > >>> > spp_flowcontrol.c ?
>
> > >>> > Thank you
> > >>> > Best,
> > >>> > Priyasheel
>
>
> > >>> > Hi Priyasheel,
>
> > >>> > Sorry, I had a typo, I meant eHCILL. So what I commented out in main function was:
>
> > >>> > // use eHCILL
> > >>> > // bt_control_cc256x_enable_ehcill(1);
>
> > >>> > Thanks,
>
> > >>> > -Risto-
>
> > >>> > From: priyasheel <priyasheel1...@gmail.com>
> > >>> > To: btstack-dev <btsta...@googlegroups.com>
> > >>> > Sent: Saturday, February 25, 2012 7:45 AM
> > >>> > Subject: Re: eZ430-RF2560 debug messages
>
> > >>> > HiRisto,
>
> > >>> > Could you please tell what is "eCHILL" in spp_counter.c and
> > >>> > spp_flowcontrol.c ?
>
> > >>> > Thank you
> > >>> > Best,
> > >>> > Priyasheel
>
>
> read more »
Risto Kivela
Mar 29, 2012, 1:10:32 PM3/29/12
to btsta...@googlegroups.com
Hi Priyasheel,
bt_control_cc256x.c md5 hash is the same, but cc2567_init_script.c is different. But after running actual diffs on the repository and my files, I noticed one more major difference in the hal_usb.c: the USB RX IRQ vector
repository:
#ifdef USE_IRQ_RX
/************************************************************************/
interrupt(USCI_A1_VECTOR) USCI_A1_ISR (void)
{
halUsbReceiveBuffer[bufferSize++] = UCA3RXBUF;
__bic_SR_register_on_exit(LPM3_bits);
}
#endif
/************************************************************************/
interrupt(USCI_A1_VECTOR) USCI_A1_ISR (void)
{
halUsbReceiveBuffer[bufferSize++] = UCA3RXBUF;
__bic_SR_register_on_exit(LPM3_bits);
}
#endif
my file:
#ifdef USE_IRQ_RX
/************************************************************************/
interrupt(USCI_A3_VECTOR) USCI_A3_ISR (void)
{
halUsbReceiveBuffer[bufferSize++] = UCA3RXBUF;
__bic_SR_register_on_exit(LPM3_bits);
}
#endif
/************************************************************************/
interrupt(USCI_A3_VECTOR) USCI_A3_ISR (void)
{
halUsbReceiveBuffer[bufferSize++] = UCA3RXBUF;
__bic_SR_register_on_exit(LPM3_bits);
}
#endif
Could you take a look if this makes any difference for you - it's working on my eZ430 boards. I was using for chipset driver the latest:
${BTSTACK_ROOT}/chipset-cc256x/bt_control_cc256x.c \
${BTSTACK_ROOT}/chipset-cc256x/bluetooth_init_cc2560_2.44.c \
${BTSTACK_ROOT}/chipset-cc256x/bluetooth_init_cc2560_2.44.c \
So let's try this first. If it does not work for you, I'll start sending you my files, starting with the binary so that you can test your HW.
Thanks,
- Risto -
Sent: Thursday, March 29, 2012 4:55 AM
To unsubscribe from this group, send email to btstack-dev+unsub...@googlegroups.com.
Matthias Ringwald
Mar 29, 2012, 1:21:39 PM3/29/12
to btsta...@googlegroups.com
Hi
The eZ430-RF2560 uses, well, the CC2560 chipset. So we need the cc2560 variant of either old (extracted) or new (converted) init scripts. (That's correct in the ez430-RF2560/example/Makefile).
The Debug UART ( "USB" ) driver doesn't use IRQs (yet). So it won't make a difference while you're update might be correct.
Could I also get a snapshot of your tree, I thought I had it working before doing the commit, but it failed in subsequent tries.
Best
Matthias
To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
Risto Kivela
Mar 29, 2012, 11:52:43 PM3/29/12
to btsta...@googlegroups.com
Ok, I had more time today to debug this issue. Instead of comparing more of my messy files from last year :), I checked out the latest btstack (revision 1640) to get a fresh start and tried to make it to work on my eZ430 board. After trying all kinds of things it seems that my eZ430 board works fine with this revision when it's connected to a windows PC via the USB dongle that came with the kit. I can reset the board either with the reset button or using FET-Pro430, and board pairs again and works. Trying to run as stand alone (i.e. with the battery pack or in my analyzer) nothing works (except LEDs), no pairing, nothing - there is no debug UART in either - why would this make a difference?. Now, my boards are modified, but only the analog ports in J3 are used - everything else is stock, so my HW should compare with the stock
kit.
I guess the the way I got this revision to work as stand alone was to use the repository checkout and only use cc2567_init_script.c instead of the bluetooth_init_cc2560_2.xx.c. cc2567_init_script.c seems to be a variant of cc256x_init_script. With this the spp_counter binary pairs as stand alone with my hacked Android ICS 4.0.3 phone and connects with my app + a spp terminal app. I can see the counts in the terminal app just fine. Disconnect, unpair, pair, connect, etc all work w/o reset (at least a few rounds).
So I've attached here the cc2567_init_script.c I've been using. Seems to make a difference on my board...
Thanks,
- Risto -
From: Matthias Ringwald <matthias...@gmail.com>
To: btsta...@googlegroups.com
Sent: Thursday, March 29, 2012 12:21 PM
Matthias Ringwald
Apr 1, 2012, 5:19:07 PM4/1/12
to btsta...@googlegroups.com
Hi Risto
Interesting observation with the results of connecting the RF2560 via USB vs. battery pack. I think I always used the battery pack as I never got the eZ430 thing to work on my Mac (so I was using the FET430-UIF and soldered the Spy-by-Wire interface to the battery pack - I also used a regular FTDI USB-2-UART board btw)
AFAIK there are two major versions of the CC256x out there. The first one is used on the eZ430-RF2560 and requires and init script of about 40 kB. The second one has most of this long init script included so the init scripts are around 10 kB. More also here: http://code.google.com/p/btstack/wiki/CC256x
Actually, something is incorrect here. The cc2567_init_script.c is 18 kB which would be smaller than 10 kB in binary. On http://processors.wiki.ti.com/index.php/CC2567_Bluetooth_%2B_ANT_for_MSP430 the table lists 60 kB for the size of the init script.
Either that number is wrong or the script from the Stellaris SDK isn't for the CC2567. If someone figures that out, please let me know :)
Best
Matthias
<cc2567_init_script.c>
priyasheel
Apr 2, 2012, 6:51:19 AM4/2/12
to btstack-dev
Hi,
With the new "cc2567_init_script.c" file in the .../chipset-cc256x
folder, we executed the following commands (after deleting the .o
files)
$ ./convert_bts_init_scripts.py
$ ./create_cc256x_init_scripts.py
and then in .../example directory, we executed
$ make clean
$ make
and then programmed the device with "spp_flowcontrol.c".
$ mspdebug rf2500 'prog spp_flowcontrol.out'
We then tried to connect to the device (we could proceed up to the
following steps)...
$ sudo bluez-simple-agent hci0 B8:FF:FE:AE:CB:E4
RequestPinCode (/org/bluez/1091/hci0/dev_B8_FF_FE_AE_CB_E4)
Enter PIN Code: 0000
Release
Creating device failed: org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply,
the reply timeout expired, or the network connection was broken.
We may have succeeded in pairing with the device but not actually
sending data. Anyways, thanks a lot for the invaluable help.
priyasheel
On Apr 2, 6:19 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
> ...
>
> read more »
With the new "cc2567_init_script.c" file in the .../chipset-cc256x
folder, we executed the following commands (after deleting the .o
files)
$ ./convert_bts_init_scripts.py
$ ./create_cc256x_init_scripts.py
and then in .../example directory, we executed
$ make clean
$ make
and then programmed the device with "spp_flowcontrol.c".
$ mspdebug rf2500 'prog spp_flowcontrol.out'
We then tried to connect to the device (we could proceed up to the
following steps)...
$ sudo bluez-simple-agent hci0 B8:FF:FE:AE:CB:E4
RequestPinCode (/org/bluez/1091/hci0/dev_B8_FF_FE_AE_CB_E4)
Enter PIN Code: 0000
Release
Creating device failed: org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply,
the reply timeout expired, or the network connection was broken.
We may have succeeded in pairing with the device but not actually
sending data. Anyways, thanks a lot for the invaluable help.
priyasheel
On Apr 2, 6:19 am, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
> Hi Risto
>
> Interesting observation with the results of connecting the RF2560 via USB vs. battery pack. I think I always used the battery pack as I never got the eZ430 thing to work on my Mac (so I was using the FET430-UIF and soldered the Spy-by-Wire interface to the battery pack - I also used a regular FTDI USB-2-UART board btw)
>
> AFAIK there are two major versions of the CC256x out there. The first one is used on the eZ430-RF2560 and requires and init script of about 40 kB. The second one has most of this long init script included so the init scripts are around 10 kB. More also here:http://code.google.com/p/btstack/wiki/CC256x
>
> Actually, something is incorrect here. The cc2567_init_script.c is 18 kB which would be smaller than 10 kB in binary. Onhttp://processors.wiki.ti.com/index.php/CC2567_Bluetooth_%2B_ANT_for_...the table lists 60 kB for the size of the init script.
>
> Interesting observation with the results of connecting the RF2560 via USB vs. battery pack. I think I always used the battery pack as I never got the eZ430 thing to work on my Mac (so I was using the FET430-UIF and soldered the Spy-by-Wire interface to the battery pack - I also used a regular FTDI USB-2-UART board btw)
>
> AFAIK there are two major versions of the CC256x out there. The first one is used on the eZ430-RF2560 and requires and init script of about 40 kB. The second one has most of this long init script included so the init scripts are around 10 kB. More also here:http://code.google.com/p/btstack/wiki/CC256x
>
> Either that number is wrong or the script from the Stellaris SDK isn't for the CC2567. If someone figures that out, please let me know :)
>
> Best
> Matthias
>
> On 30.03.2012, at 05:52, Risto Kivela wrote:
>
>
>
>
>
>
>
> > Ok, I had more time today to debug this issue. Instead of comparing more of my messy files from last year :), I checked out the latest btstack (revision 1640) to get a fresh start and tried to make it to work on my eZ430 board. After trying all kinds of things it seems that my eZ430 board works fine with this revision when it's connected to a windows PC via the USB dongle that came with the kit. I can reset the board either with the reset button or using FET-Pro430, and board pairs again and works. Trying to run as stand alone (i.e. with the battery pack or in my analyzer) nothing works (except LEDs), no pairing, nothing - there is no debug UART in either - why would this make a difference?. Now, my boards are modified, but only the analog ports in J3 are used - everything else is stock, so my HW should compare with the stock kit.
>
> > I guess the the way I got this revision to work as stand alone was to use the repository checkout and only use cc2567_init_script.c instead of the bluetooth_init_cc2560_2.xx.c. cc2567_init_script.c seems to be a variant of cc256x_init_script. With this the spp_counter binary pairs as stand alone with my hacked Android ICS 4.0.3 phone and connects with my app + a spp terminal app. I can see the counts in the terminal app just fine. Disconnect, unpair, pair, connect, etc all work w/o reset (at least a few rounds).
>
> > So I've attached here the cc2567_init_script.c I've been using. Seems to make a difference on my board...
>
> > Thanks,
>
> > - Risto -
>
>
> Best
> Matthias
>
> On 30.03.2012, at 05:52, Risto Kivela wrote:
>
>
>
>
>
>
>
> > Ok, I had more time today to debug this issue. Instead of comparing more of my messy files from last year :), I checked out the latest btstack (revision 1640) to get a fresh start and tried to make it to work on my eZ430 board. After trying all kinds of things it seems that my eZ430 board works fine with this revision when it's connected to a windows PC via the USB dongle that came with the kit. I can reset the board either with the reset button or using FET-Pro430, and board pairs again and works. Trying to run as stand alone (i.e. with the battery pack or in my analyzer) nothing works (except LEDs), no pairing, nothing - there is no debug UART in either - why would this make a difference?. Now, my boards are modified, but only the analog ports in J3 are used - everything else is stock, so my HW should compare with the stock kit.
>
> > I guess the the way I got this revision to work as stand alone was to use the repository checkout and only use cc2567_init_script.c instead of the bluetooth_init_cc2560_2.xx.c. cc2567_init_script.c seems to be a variant of cc256x_init_script. With this the spp_counter binary pairs as stand alone with my hacked Android ICS 4.0.3 phone and connects with my app + a spp terminal app. I can see the counts in the terminal app just fine. Disconnect, unpair, pair, connect, etc all work w/o reset (at least a few rounds).
>
> > So I've attached here the cc2567_init_script.c I've been using. Seems to make a difference on my board...
>
> > Thanks,
>
> > - Risto -
>
>
> read more »
Reply all
Reply to author
Forward
0 new messages