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.

Mindtree bluetooth stack for MSP430BT5190 Questions

Other Parts Discussed in Thread: MSP430BT5190, CC2560, MSP430F5438

Hi, I had some questions about Mindtree's bluetooth stack for the MSP430BT5190. Specifically, does anyone know the size of the stack and how many cpu cycles its using? I am trying to determine if I should be dedicating this uC to just bluetooth or if I can use it for other purposes.

 

I was also curious how feasible it would be to port the stack from FreeRTOS to our company's own real time OS (or perhaps this is not allowed from the Terms and Conditions)?

 

Thanks,

 

Mike

  • Mike,

     

    The information about the size of the bluetooth stack is available in the Developer's Guide:

    http://processors.wiki.ti.com/images/6/6f/MSP430BT5190_CC2560_Developers_Guide.pdf

    Specifically pages 115 and 116. As for porting the stack,  I suggest you contact Mindtree since they are the stack provider and will be able to provide you with that information. You may contact them at ethermind_support@mindtree.com. It is possible to adopt the mindtree libraries and use your own OS, but there might be some requirements (aside from licensing) that I'm not aware of.

     

    Gustavo

     

  • When will we get Mindtree BT Stack libraries for CCS?

    I have been working with a customer on a demo application that we've been working on taking the Accelerometer example application and changing it to a Serial Pass-through application, which would work with 2 ez430 modules and 2 radios on 2 computers (using something like HyperTerm.) We currently have this working, but the character latency is about 140ms - taking over a second to caputure and transmit 8 bytes of data. I suspect that there is some threading issue going on, however IAR is NOT thread aware for FreeRTOS.

    I wanted to port all this code over to CCSv4.2, but the thing that is impeding me is the BT Stack Library support - which is currenly only IAR.

  • Gerry,

    140ms to transmit 8 bytes is clearly too low. The stack has been verified to enable much higher throughput.

     

    CCS support is in the works, but I could not immediately tell you when it will be aailable. If I have any news, I will inform you.

     

    Gustavo

     

     

  • Gustavo L wrote the following post at Sat, May 7 2011 2:38 PM:

    "140ms to transmit 8 bytes is clearly too low. The stack has been verified to enable much higher throughput."

    Which is why I think there may be a threading issue involved. I modified the UART ISR with the follwing:

    /**
     * \fn      USB_UART_VECTOR
     * \brief   This is the USB interrupt handler. The byte received on the USB is
     *          copied to a receive buffer.
     * \param   void
     * \return  void
     */
    #ifdef __TI_COMPILER_VERSION__
    #pragma CODE_SECTION(USB_UART_ISR, ".text:_isr");
    #endif /* __TI_COMPILER_VERSION__ */
    #pragma vector=USB_UART_VECTOR
    __interrupt void USB_UART_ISR(void)
    {
        char temp_data;
        temp_data = USB_RXBUF;

        halUsbReceiveBuffer[circular_usb_buf_wr++] = temp_data;     //* GCS 04-26-11
        if (MAXUSBRCVBUF == circular_usb_buf_wr) {                            //* GCS 04-26-11
            circular_usb_buf_wr = 0;                                                               //* GCS 04-26-11
        }
        UPDATE_USER_BUFFER(USB_DATA_IN);                                 //* GCS 04-27-11
            
        inactivity_counter = 0;
    #ifdef MSP430_LPM_ENABLE
        if (TRUE == lpm_mode) {
            lpm_mode = FALSE;
            restore_peripheral_status();
            EXIT_MSP430_LPM();
        }
    #endif /* MSP430_LPM_ENABLE */
    #ifdef DEBUG_TESTING
        halUsbSendString("~\n");
    #endif
    }

    I also changed the USB_UART_VECTOR to A3 so that the back-channel UART on the ez430 module could give me characters through the USB interface in sdk_pin_config.h:

    #define USB_UART_VECTOR                 USCI_A3_VECTOR         //** GCS 4-22-11

    I've tried sending one character at a time, and a buffer of 8 chars at a time - to no avail.

    IDEAS?

  • Greg,

     

    I myself developed a program that allows for two devices to replace a serial cable. The changes are in several places and depends on which application did you use as your basis. I used accl myself (unfortunately I am prevented from sending the exact changes because of licensing issues). However, I can give an overview.

    I am using the buffer that is already available in the program. When bytes arrive, I place them in the buffer. I have added a timeout so that if characters aren't received after x amount of time after the last character, we call the function to send the data. The ISR of the timer is shown below

     

    // Timer B0 interrupt service routine
    #pragma vector=TIMERB0_VECTOR
    __interrupt void TIMERB0_ISR (void)

       TBCCTL0 &= ~CCIE;                           // TBCCR0 interrupt disable
      
      // Activate task to send
      signed portBASE_TYPE xHigherPriorityTaskWoken;
      
      UART_DISABLE_BT_UART_RTS();
     
      xHigherPriorityTaskWoken = pdFALSE;
      inactivity_counter = 0; 
     
      #ifdef MSP430_LPM_ENABLE
          if (TRUE == lpm_mode) {
              lpm_mode = FALSE;
              restore_peripheral_status();
              EXIT_MSP430_LPM();
          }
      #endif /* MSP430_LPM_ENABLE */
     
          if (FALSE == lpm_mode) {
              UPDATE_USER_BUFFER(UART_TIMER_SEND);
              /* Unlocking User Task */
              if (bytes_to_be_processed_in_user_buf > 0) {
                  /* Unblock the user task by releasing the semaphore */
                  xSemaphoreGiveFromISR(xUserSemaphore,
                                        &xHigherPriorityTaskWoken);
              }
          }
          bytesToSend = bufferSize;
          bufferSize = 0;
     
        /* Force a context switch if xHigherPriorityTaskWoken was set to true */
        if (xHigherPriorityTaskWoken) {
            portYIELD();
        }
    }

     

    In user_task_routine I added another case:

     

    case UART_TIMER_SEND:
                        SDK_SPP_CHANGE_TX_STATE(0, SDK_SPP_TX_ON);
                         appl_send_spp_data(0);
                        __no_operation();
                      break;

     

    Note that I previously declared:

    #define UART_TIMER_SEND 0x0A

     

    This way, it will check wiether it's time to send and send the data in the user_task routine.

    Note that there are several places in the accl application where we send data. Doing CTRL+SHIFT+F and looking for appl_send_spp_data  will show you when it's called. The way the accl program is structured, it starts sending data immediately after the connection. Also, it responds to the incoming data with data. So stopping that might be needed in your case.

    It is possible that we will add a serial cable replacement application somewhere, but I cannot guarantee it.

     

    Gustavo

  • So, our approach was nearly identical to yours; i.e using the accl application as a base. Not much was modified, obvioulsy removing the accelerometer related code and replacing it with the reading of the character buffer filled in by the USB_UART_ISR. However, I did remove the several calls to appl_send_spp_data in the appl_spp_notify_cb routine. Seems that anytime any command was sent through the stack (CONNECT and SEND,) this routine initiated another call to appl_send_spp_data - collecting accelerometer data and putting the packet on the stack (SPP_CONNECT_CNF, SPP_CONNECT_IND, and SPP_SEND_CNF handlers.) The SPP_SEND_CNF handler was particular puzzling, because it appeared that the mere act of sending a packet through the stack seemed to trigger a new call to appl_send_spp_data and appears self perpetuating.

    I too added a new command handler to user_task_routine, USB_DATA_SEND, that called the sdk_bluetooth_menu_handler with a newly defined OP_USB_DATASEND signal. This signal was caught by the menu handler and called appl_send_spp_data(0), which now takes the characters read by the UART ISR and sends them over the stack. The working implementation only sends one character at a time over the stack and this appears to take 140ms from character UART in on one side to character UART out on the other.

    Do you have an explanation as to why it takes so long for a character to be caught in an ISR and propogated through the stack?

    I DID create some #define'd test code that simply fills the usb_receive_buffer with data from a constanst string character buffer of hexadecimal digits, creates a  4 byte packet while moving a pointer through the buffer, and sends that packet over the BT stack. Conversely, I also left in all those "extra" calls to appl_spp_send_data in the appl_spp_notify_cb routine, and THIS data streamed over to the other BT device with great speed, similar to the accelerometer application. However, this is not really useful other than to compare my new routines to the previous accelerometer routines.

    My customer and I are trying to understand why handling one character at a time takes so long.  But, without task aware debug tools, this seems to be an alusive task. If we had CCS support, since the Stellaris support in CCS also includes task information from FreeRTOS, we were hoping to have task aware debug in CCS for this code. At this stage, without the MindTree BT stack libraries that are compatible with CCS, this is impossible.

  • Gerry,

    Unfortunately, without running the code myself it would be difficult to check. If you post it, or send it to me at g-litovsky@ti.com I might be able to run and test it.

    The Simple application that is now part of the SDK is inherently designed to send 100 bytes and might be a better fix, but I haven't used it.

    CCS support is in the works, so hopefully soon you can solve these issues. You can download a 30 day full evaluation version of IAR, si that what you're using?

     

    Gustavo

  • Gustavo,

    I would be more than happy to e-mail you the code archive I have. Sending to your e-mail as a write. Please confirm that you received it.

    As far as IAR tools, I have full FAE licenses to all IAR tools.

  • Gerry,

            Did you remove the sniff mode from the code? 

    Rgds,

     

  • If it's on by default in the SDK, then no.

    Should I have?

  • Hey guys,

    This was my first chance to look at the code, and YES, I disabled the SNIFF_MODE awhile ago when I was debugging all of this. It is currently off.

  • Gerry,

             I was not sure if your question was answered or you found the issue. Please let us know if you need further help.

    Regards,

  • The default USB driver available as part of the MSP430F5438 HAL files use interrupt mode to receive data over the USB and use polling mode to transmit data over the USB port.

    You may want to try changing the transmit portion of the USB HAL driver to see if this reduces the latency issues faced in your application.

    With regard to CCS support, we have the application & libraries working on CCS v4.2. Please contact bluetooth@mindtree.com for support related to CCS. 

    Regards

  • That is a great suggestion!  However, I know that I am not having an issue with the transmit portion of the USB driver. I know this because I can take a dummy buffer, and comment out the serial port receive side, and stream data back and forth over the channel just fine.

    I will take your suggestion and try contacting MindTree directly.

  • I was VERY disappointed to hear from MindTree that they will only offer IAR versions of the stack for the MSP430BT5190. Evidently, they have a CCS version, but they want to charge the end customer for it.

    Bad Form.   You guys are REALLY partnered with these folks?

  • Gerry,

     

    I understand your frustration, however it is not just Mindtree's decision. There are many considerations when deciding on how to offer some of the development options.

     

    Regards,
    Gustavo

     

     

  • Gerry,

          As Gustavo mentioned to you earlier, an example code similar to your needs is explained in here: http://processors.wiki.ti.com/index.php/CC256x_MT_UART_BRIDGE 

    Regards,

    ~Miguel

  • Interesting ... many of the changes I made were very similar. However, there were a few modifications to appl_spp.c and sdk_pl.c that delt with halUsbShutDown() and halUsbInit(). I wonder if these could have been hosing me up.

    There were also significant changes to user_task.c including moving the UART ISR to this file. I can kind of understand why this was necessary, but if one of you could enlighten me, that would be good.

    BTW, I found an error in the ez430 Modifications section: 

    1) Correct the define for the UART Vector. In sdk_pin_config.h line 86, USB_UART_VECTOR is erroneously declared for USCI_A1 when in fact USCI_A3 is used for communications with the host. Therefore, modify it to be:

    #define USB_UART_VECTOR USCI_A1_VECTOR
    
    

    You mentioned that USB_UART_VECTOR was erroneously declared as USCI_A1 when it should have been declared as USCI_A3. I had discovered this as well. However, your modification kept it as USCI_A1. Oooops!

    I've made these changes and successfully built everything. I will now try and program two radios and let you know how it works.

     

     

  • Gerry,

    Moving the ISR was done for convenience. Given that the ISR's primary function was to deal with incoming data and send it to the bluetooth, I decided to place it there (also to avoid using some extern I believe). It really doesn't matter

    The real main change was to call the user task and give the parameter used in that switch statement. It's important to use the RTOS flow. In this case, the user_task can handle both the case where the UART buffer is full and when the timeout timer fires.

    Thank you for letting me know aboutthe error. It will be fixed. I hope the code works well for your application.

     

    Regards,

    Gustavo

  • Hey guys,

    I have 2 ez430-RF2560 kits - one old and one new.  When I rebuilt the code with the UART-Bridge modifications, I ran into an issue with the radio in this new kit. When the code executed the Red and the Blue LED just started blinking in unison. So, I decided to go back to the virgin GA 1.0 code as a baseline. However, THAT code failed in the very same way!

    Then I went back to the original Beta code (that, BTW, ships on the CD in the kit,) and THAT code works perfectly.

    BOTH the GA 1.0 code and the Beta code work on the old radios from the OLDER kit. 

    Any idea what's happening here before I start stepping through code?

  • Gerry,

    The code is downloading the wrong service pack. Please look here for information:

    http://processors.wiki.ti.com/index.php/CC256x_Bluetooth_Versions_and_Service_Packs

    It's an easy fix.

     

    Gustavo

  • You guys ROCK!!!

    I'll let you know how the UART Bridge modifications work for me!

  • 0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789abcdef0123456789ABCDEF0123456789ABCDEF0123456789abcdef

    Kudos to you both!!

    I implemented your changes for the UART Bridge and tested it today, and it seems to work quite well.

    However, I did run into an issue.  My test profile allows for sending a simple Hex datafile through Hyperterm. I've attached it. When I try "Transfer -> Send Text file" with the attached file, a few characters are missing, then the sending radio crashes. It appears to be a buffer over-run requiring, perhaps, a bit of character delay so as not to over-run the buffer.

    A 1msec character delay seems to cure this issue. A CONSIDERABLE improvement over MY code.

    Did you guys test this?  Would you?

    I have a Windows 7 machine (Quad-Core i7 w/ 16GB RAM) and I would like to eliminate THAT as a possible cause.

  • Gerry,

    I will add a few comments on the code's limitations. The reason for the need to delay is that the Bluetooth stack is sending data. At this time, the UART ISR will interfere with the Bluetooth Stack's operation and is disabled. This will mean lost characters because there is no ISR to store the bytes in the UART's RX buffer. I am not sure why would the radio crash. The time to send the characters is about 1ms or so.

    I did test the code myself to a certain point  but the customer would need to perform tests to ensure that it fits their purpose, especially because it does not come from Mindtree.

    It's good to hear its working for you.

    Regards,
    Gustavo