Code Composer Issue

Hi Ben,

are you sure the bluetooth LE stack is for CCS/CCS compatible?    I have been away from that area for a bit unfortunately but last I remember all code was for IAR when it came to Bluetooth.

Have you posted int he bluetooth low energy forum?

Best Regards,
Lisa

Hi Ben,

ok, thanks for updating and glad to hear you are past the issue.

All the best with development.  Bluetooth is an exciting area.

Best Regards,
Lisa

Hi Ben,

I am currently using a MSP430F2132 to interface with a BLE112 over UART and am having a heck of a time deciphering the BGLib in order to use it with the MSP.  
Would you be willing to lend me any insight you may have learned in your development or even just a base line understanding so that I can get my project at least running something basic?

I'd appreciate any help you can offer,
Thanks!

Dustin 

sure...I did get this working, but I found it was taking too much overhead on the MSP to use BGLib so I switched to using mostly BGScript to do most event handling and processing there. I still use the UART to periodically poll the BLE112 and to allow the BLE112 to send notifications/indications to the MSP.

What exactly are you trying to decipher in BGLib? Are you referring to the  API in general, or are you talking about the messages that it sends?  

Ahh, that's interesting. I wasn't aware you (or I thought the documentation said you could not) use both BGScript as well as the BGLib.

I'm mostly having a hard time figuring out what api functions need called and when; I'm not sure how the process works in the big picture so therefore it's hard to know what functions I need to implement.

I wonder if I may have to resort to using both BGScript as well as periodic polling via the MSP.  Did you experience much slow down using BGScript? I've read it has quite a substantial overheard as well.

Thanks for your help!

No, it is one or the other. You can't use both BGScript and BGLib. I am only using BGScript, not BGLib. 

Yes, BGScript does have overhead but I simply couldn't handle all the UART ISR's in my application. It was affecting the performance of more critical operations that the MSP is responsible for. The bluetooth data I am exchanging is low-priority and doesn't have strict timing deadlines. It is also a fairly simple profile (very similar to the Cable Replacement Demo). If you think about it though, I think the overhead involved with using the BGLib may close to or greater than that of the BGScript. For BGLib, the BLE112 must pack a message for every event. Then the MSP receives this message, byte by byte, and then processes the message when complete. 

The main limitation of BGScript is that it is not a rich programming "language" -- you can't build structures or even make functions. Everything must be upon an event occuring. And there are also size limitations because the BLE112 (which uses a TI CC2540 chip) , due to the size of the BLE stack, doesn't have much free ram available for user BGScript code. So if you are dealing with a large profile and / or complex logic that needs implemented via BGScript, you may have problems. 

As far as what API functions to use, and how the process works -- have you figured out which endpoint will be the scanner and which will be the advertiser? Can you tell me what other devices you are talking with? I'm assuming you are talking to some BLE112 variant on the other end, but is it paired with another MSP or is it on a PC? Generally, the device with the larger power source is the scanner, which will become the master. 

For my application, the target product (with larger power source) has an MSP430 and a BLE112 (using BGScript). I start the BLE112 in scanner mode, to listen for advertisements. It can connect to a few devices - say an iPhone, a PC, or a custom remote with a BLE112 using BGScript. Lets take the custom remote, which is usually in a low power mode. When the user presses a certain button, the BLE112  wakes up and begins sending advertisement packets. When the target device, in scanner mode, receives the advertisement it will make a connection to the remote. There's quite a bit more detail than this, but this should give you an idea of the basic process. 

Also, have you looked through the BLE Stack API Reference manual? It has lots of good information. The BGScript Developer Guide also has good info in it. I also refer to, and post to, the Blue Giga tech forum. They have pretty good application engineers. 

When developing, I generally use the BLED112 dongle hooked up to the BLEGUI App and then another DK-BLE112 development kit hooked up to a remote terminal. Then I can see the output of BGAPI from both devices. 

I see, thanks for all the great info!

I think I have some of those basics figured out.  Here is a brief outline of my project:
I have a MSP430 running as host on the 'advertiser.'  This side samples a sensor at around 20Hz, with the intent of updating that value to the 'scanner' via the BLE112.  
The 'scanner' also has a MSP430 as host.  It should look to receive the updated information from the 'advertiser' when applicable and then send it to the MSP for processing.

I think the process you outlined above is a great place to at least start what I'm trying to do. In that scenario, I'm sure I can surmise the events that will occur, however, I'm not sure which BGLib functions should be associated with these events.  

I just implemented the basic UART code for the MSP on the 'advertiser' side and am looking for the system_boot event.  However, each time I reset the BLE112 to trigger this event, I am only receiving 1 byte in my MSP UART RX routine.  This byte is almost always 0x42, but occasionally 0x52.  I have everything set for 115k baud, do you suspect that is too fast or could the culprit be something else?

Thanks again for your help. 

My guess is that you suffering from overflow and not processing the UART ISR's quick enough, or you don't have the BLE112 configured properly. 

Did you disable flow control in the BLE112 hardware configuration xml file? Also, did you set the BLE112 up for BGAPI mode in the same xml file? These are two prerequisites that must be met. 

The system boot event is several bytes. It is the same size and same values every time. I'd have to check my notes to see what they are. You need to keep the UART ISR quick and small. I think I set up a buffer of about 20 bytes. I had a background task always running to see if a complete message (BGAPI has a function for this) had been received. When a new byte was received via UART ISR, I simply copied from the RXBUFF to the next slot in the Rx Buffer and incremented the the position variable. That was all the ISR did.  

in the hardware configuration file:

<usart channel="1" alternate="1" baud="115200" endpoint="api" flow="false" mode="packet"/>

When packet mode is used, the first byte sent is the number of bytes to be sent in the packet. 

Upon startup, you should receive this stream from the BLE112

10 80 0C 00 00 01 00 01 00 00 00 3E 00 02 00 01 FF

10 = # of bytes to be sent, eg 16 bytes

80 = packet type, event

0c = data length

00 = class, system

00 = specific event, boot

....

There is a thread on the BlueGiga Tech Forum that gives more detail on this process. It is called "REFERENCE: What is the difference between BGScript, BGAPI, and BGLIB?"

This is stumping me a bit.  I have the MSP configured for 8MHz, which I would expect to be plenty fast.  Here is a copy of the hardware.xml I am using:

<?xml version="1.0" encoding="UTF-8" ?>

<hardware>
<sleeposc enable="false" ppm="30" />
<script enable="false" />
<sleep enable="false" />
<wakeup_pin enable="false" />
<txpower power="15" bias="5" />
<port index="0" pull="down" tristatemask="0" />
<port index="1" pull="down" tristatemask="0" />
<usb enable="false" endpoint="none" />
<usart channel="1" baud="38400" alternate="1" endpoint="api" flow="false" mode="packet" />

</hardware>

I had tried running everything at a lower baud rate (38400), but still no success.  I believe I have the hardware.xml setup correctly.  I expected my UART ISR to be quite quick.  It's pretty straight-forward:

#pragma vector=USCIAB0RX_VECTOR

__interrupt void UART_RX_ISR(void)

{

int8_t e = UCA0STAT & UCRXERR; 

int8_t c = UCA0RXBUF;

//if(e) return; //ignore chars with framing or overrun errors

if (InBufInIdx < IN_BUFFER_SIZE_MINUS_ONE)

{

InBuf[InBufInIdx++] = c; // add to buffer

}

else

{

InBuf[0] = 0; //note the buffer overflow as command null

}

__bic_SR_register_on_exit(LPM0_bits); // rti with cpu running  

}

Like I said, I have another interrupt timer running at 20Hz that drives my sensor sampling.  Do you think that could be interfering?

it seems ok. Can you show your code for the UART initialization? I doubth the 20 Hz timer would be intefering, but you could try taking it out and stubbing it with dummy data as the "sensor". 

also, where are you setting your breakpoint at? 

Hi Ben,

Here is my code for initializing the DCO and the UART:

//set DCO to 8MHz

      DCOCTL = 0;                                     //select lowest settings to start

      BCSCTL1 = (XT2OFF | CAL_BC1_8MHZ);  //configure for 8MHz

      DCOCTL = CAL_DCO_8MHZ;                    //

      //select VLOCLK for ACLK

      BCSCTL3 = LFXT1S_2;                             //VLOCLK provides 12kHz clock

      //Init Serial Port

      //115200 Baud

//    UCA0CTL1 |= UCSWRST;    //Hold in RESET during config

//    P3SEL |= BIT4 + BIT5;   //P3.4 and P3.5 => UART TX and RX (respectively)

//    UCA0CTL1 |= UCSSEL_2;   //SMCLK

//    UCA0BR0 = 69;                 //8MHz, 115200 settings

//    UCA0BR1 = 0;                  //8MHz, 115200 settings

//    UCA0MCTL = UCBRS2;            //UCBRSx = 4

//    UCA0CTL1 &= ~UCSWRST;   // **Initialize USCI state machine**

//   

//    IE2 = UCA0RXIE;               //Enable USCI_A0 RX interrupt

      //38400 Baud

      UCA0CTL1 |= UCSWRST;    //Hold in RESET during config

      P3SEL |= BIT4 + BIT5;   //P3.4 and P3.5 => UART TX and RX (respectively)

      UCA0CTL1 |= UCSSEL_2;   //SMCLK

      UCA0BR0 = 208;                //8MHz, 38400 settings

      UCA0BR1 = 0;                  //8MHz, 38400 settings

      UCA0MCTL = UCBRS1 + UCBRS0;         //UCBRSx = 3

      UCA0CTL1 &= ~UCSWRST;   // **Initialize USCI state machine**

      IE2 = UCA0RXIE;               //Enable USCI_A0 RX interrupt

Can you double check that this sets the baud rate at 38400? I'm wondering if I'm just making a stupid mistake somewhere.

I am trying to measure the baud rate from the radio with an o-scope (my logic analyzer is busted).  It seems like it is running at a baud rate much faster than the 38400 I am trying to program it to.

Also as for where I am setting the breakpoint, I've tried a number of places, both before the variable 'c' is loaded with the value from the RX buf and immediately after.

Looks ok. I'm not as familiar with your family of MSP...I couldn't figure out if UCA0MCTL was set correctly. But as it's used for the fractional modulation, the BR0 and BR1 should get you pretty close. 

Have you verified that your SMCLK is at 8 MHz? 

I haven't verified the 8 MHz clock, do you know if there is a way to set it to an output pin so that I can measure it?

Also, did you have any problems programming the BLE112's UART baud rate?  I was able to catch the system_boot event on an o-scope and it appears to be running at a much much faster baud rate than what I had set it to in the hardware.xml.  Do you know of any problems with downloading the project .xml?

Ben,

I've found the problem! Here's what I've found.  It turns out that my initialization of the DCO was off (I found this by measuring it on a GPIO pin, thanks for that help). The problem were the macro definitions I used for setting up the 8 MHz clock.  Originally, this is what I had:

BCSCTL1 = (XT2OFF | CAL_BC1_8MHZ); //configure for 8MHz
DCOCTL = CAL_DCO_8MHZ;

The problem with this is that the CAL_BC1_8MHZ and CAL_DCO_8MHZ were the incorrect definitions.  They instead need to be this (just remove a single underscore):

BCSCTL1 = (XT2OFF | CALBC1_8MHZ); //configure for 8MHz
DCOCTL = CALDCO_8MHZ;

And that's all it took! Sometimes it's just a simple, albiet a bit cryptic, oversight that causes all the problems.  Thanks so much for your consistent help, I don't think I've ever had such good help on this forum before!

Cheers.

Glad I could help. 

Hi Ben,

Right now I am working on BLE Master development with MSP- 430f5255 as host controller and BLE121LR (same as BLE112 but with Long Range). And I am using Code composer studio 7.1.0 version. I successfully developed BLE Master using BG Script. But due to memory issues and OTA requirements, we want to go with BG Lib. 

I tried using the BG Lib provided in the SDK, but getting too many errors. So can you please share your updated library with us. Or at least guide us what to change in the library files. I tried removing PACKSTRUCT, but when I use any function in the main, I am getting errors in Linking. I am not getting whether to use PACKSTRUCT or not. 

I'd appreciate if you help us.