This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430BT5190 + CC2560 data throughput/loading issues

I am running the GA1.0 release (modified accelerometer demo to work on 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.  This setup works for smaller amounts of data, but once I start throttling up to a full 78K of throughput, the software can no longer keep up with the UART interrupts.  My attempts at fixing this have alwalys 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.  In my current setup, there is no other processing other than the BT stack.  Does anyone have any suggestions?

  • Chad,

    I'm looking into your question to find some answers.

    Gustavo

  • The CPU utilization is a function of other interrupts on the system. There may be differences in throughput numbers based on your actual HW and the changed different measurement conditions.

    Have you tried measuring the CPU utilization when you start getting the errors mentioned to check if it has increased significantly to the point that errors can be introduced?

     

    Have you enabled global interrupts in your custom UART ISR? If not, this could lead to errors being faced by you on the BT UART.

    Regards

     

  • Chad,

    I ran into almost the same problem. Totally confused was I by "calculation".

    I guess the 430 to cc256x communication UART is pretty low-efficient which take unreasonable period to load data into cc256x.

    If you load data byte--by-byte into cc256x then the actual byte-quantity/sec would be multiplied a X incurred by the frames from 430 into cc256x.

    I used a simple fifo to temporarily store uart incoming bytes and to load them onto BT block by Block.

    that you could use.

     

    Kepei

  • Kepei,

    This is actually what I'm doing; buffering the UART and sending 110 byte blocks to the BT stack.  Right now I backed off to 56Kbps and am using a lot of buffering but I still drop packets occasionally when the BT stack gets behind.

    I wonder if the throughput measurements in the Developers guide are meant to be taken as full-duplex  i.e.  25MHz @ 115.2 Kbps =  90045 bps (throughput) is meant to be taken as 45Kbps uplink and 45kbps downlink?   45Kbps is a lot closer to what I'm seeing in practice.

    -Chad

  • The developer guide lists the test conditions used for calculating the CPU utilization and throughput numbers in sections 2 & 4 of the Appendix. 

    The throughput is calculated by transmitting the payload in only one direction from the MSP430 to the PC.

    Have you tried calculating the MSP430 CPU utilization of your system based on the modifications that have been done on your system? If the utilization numbers turn out to be too high, it is possible that the BT UART may have trouble keeping up with the multiple interrupts in the system and you may end up getting a lesser throughput.

    Regards

  • Hello Balaji,

    I am working with Chad regarding this issue.  We received the following information from TI. 

    "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. http://e2e.ti.com/support/low_power_rf/f/660/p/123238/453812.aspx

    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: http://processors.wiki.ti.com/index.php/CC256x_MT_UART_BRIDGE We have seen similar limitations and the datarate you are getting is a little faster than what we’ve seen. "

    Do you have any new information regarding this interface?

    Thank you,

    Chris

     

  • Chris,

    I believe it should be possible to try the MSP430's DMA to move the data out of the UART RX buffer to a memory buffer. The main issue in the software, as it currently is on the wiki, is that the UART ISRs cannot occur while the BT stack is running the transmission, causing loss of data. However, the DMA might work, even though it uses some CPU cycles. Perhaps it will not interfere with the BT stack's operation. Just to clarify, this is the DMA for the non Bluetooth UART.

     

    Regards,
    Gustavo