Texas instruments offers source code for a Bluetooth stack (Serial Port Profile) that was written by Mindtree. It runs on an MSP430 microprocessor and interfaces with their baseband controller chip (i.e. the RF chip). This uses the FreeRTOS operating system. This software comes in the form of several demos; the one I used is called the accelerometer demo. This chipset is part of custom handheld hardware I am developing.
I am running the GA1.0 release (modified accelerometer demo to work on the custom hardware). I'm trying to simply trying to pass data between Bluetooth SPP and a UART running at 78K. I have SNIFF mode disabled and am disabling RTS in the UART interrupt. No processing is done in the Interrupt, other than a write to a buffer and a semaphore take. I have a low priority task that handles buffering.
All I need the chip to do is provide a link between the Bluetooth and a UART running at 76K (this UART connects with our DSP processor). Currently, the DSP is the brains of the hardware and communicates with a PC GUI via USB. I want to take the DSP UART and forward it over Bluetooth instead without the DSP knowing or caring what its UART is connected to.
As constructed right now, the software connects via bluetooth correctly and I've verified transmitting and receiving data. At low rates, this works great. Since the DSP is always transmitting a status message out its UART, I can connect a PC with a bluetooth dongle to the hardware, and use Putty (serial port terminal) to watch this status message coming across correctly. However, once I try to connect with our PC GUI, the resulting RX traffic on the bluetooth is such that the software can no longer service the DSP UART interrupts in a timely manner. With no Bluetooth RX, I'm getting over 100 UART interrupts before my task is able to process the data, even with the task's priority set to highest. I imagine it's a great magnitude more once RX data starts coming in, which currently crashes us. Unfortunately, this MSP430 processor does not offer DMA for the UART we are using, and does not offer hardware buffering.
My attempts at fixing this have always lead to one of three outcomes: my UART interrupt overflowing, the BT UART interrupt overflowing, or my UART buffer overflowing when the Stack can't manage to send the data in time. The developer guide says that at 18 MHz and 115K, the average data throughput is 84K, and the average CPU utilization is 10.7% yet the software can't keep up with a 78K UART.
It's my fear at this point that the Bluetooth UART interrupt (part of Mindtree's stack) is hogging too much CPU to allow the handling of any other interrupts at the rate we want.
Has anyone had any success integrating the TI/MindTree Bluetooth stack? If so did you run into these same issues? I'm basically loooking for any and all suggestions on how to overcome these issues.
Best Answer
Thanks for everyone's comments. I heard back from TI with the following answer regarding this issue.
"Due to something innate in the Mindtree stack, you cannot generate an interrupt in the MSP430 while data is being sent/received via BT. Therefore, you will see a limitation on the throughput in/out of the part. This is something that Mindtree was working on and would be good to ask them through your posting to the E2E forum since the Mindtree engineer “Balaji Jeyaraman” may be able to tell you if they’ve found a way around this or updated the stack. MSP430BT5190 + CC2560 data throughput/loading issues
Along the same lines, TI has posted a Wiki (different than the Bluetooth one) that focuses just on this ‘BT bridge application’. It can be found here: CC256x MT UART BRIDGE We have seen similar limitations and the data rate you are getting is a little faster than what we’ve seen. "
So not the answer I was looking for, but I thought I'd post it here for others. Thank you.