What steps will reproduce the problem? 1. Connect PC with MSP430F5438 with USB. 2. Send 102 Bytes data to the MCU per 300 ms 3. transfer the data using Bluetooth every time after finishing receiving every 102 Bytes What is the expected output? What do you see instead? The system works well. But there is no data received by the linked device using Bluetooth, and no error log in the debug command. When I reduce the frequency of the data, such as 102 Bytes per 500 ms or 1 s, the system continue to work well. While if I increase the number of bytes to send, the MCU may reset sometime.

I've registered a data_source in the run_loop to handle the USB receiving.There is no timer in the run_loop. Every time in the process of the data_source , it will check if the USB receiving finished, once done, it will send the data by Bluetooth.

I'm wondering why the situation occurred in the experiment, and I need some help.

Please attach a package log, as described here: http://btstack.uservoice.com/knowledgebase/articles/69548-how-to-get- btstack-communication-log

and provide any additional information below.

Hi. While this is an issue, I'd rather discuss this on the mailing list, as none besides me reads this item.

I'm not at home and won't have access to hardware for the next two weeks. Could you try to replace the USB code with synthetic data, eg. a timer that fires every 250 ms and see what happens?

What happens if your sending faster? What does the MCU do? Could you use a debugger or add more debut output.

Finally, could you post the reduced code - that shouldn't be much more then e.g. the spp_counter example, no.

Hi. Thank you for your reply. Here is some of my code. // This is the process of data_source used to handle USB receiving. static int uart1_handler() { if(halUsbTail == 0) // check if receiving return 0; if(halUsbIFlag == uart_flag){ // check if receiving finished int err = rfcomm_send_internal(rfcomm_channel_id, halUsbBuffer, halUsbTail); switch (err){ case 0: counter_to_send++; break; case BTSTACK_ACL_BUFFERS_FULL: printf("full"); break; default: printf("rfcomm_send_internal() -> err %d\n\r", err); break; } halUsbTail = 0; } } uart_flag = halUsbIFlag; return 0; } // This is the interrupt handler void USCI_A1_ISR (void) { volatile char c = UCA1RXBUF; halUsbBuffer[halUsbTail] = c; halUsbTail = (halUsbTail + 1) % BUF_LEN; halUsbIFlag++; // use to check if receiving finished // __bic_SR_register_on_exit(LPM3_bits); } The upper code is the core of my experiment. There is only one data_source and no timer in the run loop. I wonder the USB interrupt handler may crash if the interrupt handled too frequently.

Best wishes

-- ף�ã� Regards��

�ź��� Haixiang Zhang

�廪��ѧ�������ѧ�뼼��ϵ Dept.Computer Science & Technology , Tsinghua University

+86 18618168176

redwalker.05@gmail.com

Does the program crash or does it just doens't do anything? (if it crashes, the LEDs will blink again, it will say hello...)

I'd try to split it in two parts: a) USB UART, b) BTstack and test each separately. I don't have much experience with MSP430 IRQ handling, I just got BTstack working properly.

Finally, it might make sense to disable both eHCILL and MCU sleep during testing. (in run_loop_embedded.c just comment the part that puts the MCU to sleep)

Hi, I've found that one tick takes 250 ms so that when the data from USB is quickly enough, the loop may fail. I've reduce the time of per tick to 125 ms. I did an experiment about sending 104 bytes through Bluetooth every 200 ms, and all work well. But if I combine the USB receiving with the Bluetooth sending, that means there was a data_source in the loop to check if the USB buffer had data.If there was, the data source process would send the data away using rf_comm_send. The situation would be OK for just few minutes. Then it would occur BTSTACK_ACL_BUFFERS_FULL or error 114(RFCOMM_NO_OUTGOING_CREDITS). I wonder what is the reason of the two errors. Best Wishes

-- ף�ã� Regards��

�ź��� Haixiang Zhang

�廪��ѧ�������ѧ�뼼��ϵ Dept.Computer Science & Technology , Tsinghua University

+86 18618168176

redwalker.05@gmail.com

BTSTACK_ACL_BUFFERS_FULL and RFCOMM_NO_OUTGOING_CREDITS are temporary errors. Please read the BTstack Manual on how to deal with them.

Also, as far as I know, BTstack doesn't loose any packets, so there might be a bug in your logic :)