BTstack SPP reset on MSP430

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by redwalke...@gmail.com on 22 May 2013 at 7:43

[GoogleCodeExporter]

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.

Original comment by matthias@bluekitchen-gmbh.com on 22 May 2013 at 7:52

[GoogleCodeExporter]

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

Original comment by redwalke...@gmail.com on 22 May 2013 at 8:05

[GoogleCodeExporter]

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)

Original comment by matthias.ringwald@gmail.com on 22 May 2013 at 8:29

[GoogleCodeExporter]

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

Original comment by redwalke...@gmail.com on 23 May 2013 at 10:18

[GoogleCodeExporter]

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 :)

Original comment by matthias.ringwald@gmail.com on 1 Jun 2013 at 1:04