cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

LuGi_2890336
New Contributor II

I'm using CYBT 343026 for audio streaming and for transfer data with characteristics BLE. These data are exchanged with another micro via the PUART.

The sending of the data on PUART may have frequency peaks of 1000 packects per second and every packet contains 21 bytes (for the final version they could increase).

I tested this case and, when I start the sending of data via PUART, the streaming stop, the smartphone or tablet disconnect from it and it's necessary to reset module for reconnect again for audio streaming.

If I decrease the sending at 10 packects per second it seems works fine even if seems some times the audio streaming stop for a moment.

If I use audio streaming and sending data separately all works fine also a 1000 packets per second.

The strange thing is that this happens even if I do not set BLE characteristic and do not initialize PUART. If I do not initialize PUART it's not necessary to reset module but   the audio stop for a moment (as if dashed).

I receive the bytes with ISR and I process packets in the same routine but the problem persist even if I process the packets inside a timer routine every 10ms (as if were a MainLoop).

This is initialization code for PUART:

//Configure the PUART

wiced_hal_puart_init();

// Possible uart tx and rx combination.

// Pin for Rx: p2, Pin for Tx: p0

// Note that p2 and p0 might not be avaliable for use on your

// specific hardware platform.

// Please see the User Documentation to reference the valid pins.

wiced_hal_puart_select_uart_pads(WICED_PUART_RXD, WICED_PUART_TXD, WICED_PUART_CTS, WICED_PUART_RTS);

/* Turn on flow control */

wiced_hal_puart_flow_off();

// BEGIN - puart interrupt

wiced_hal_puart_register_interrupt(IPP_ReceivedData);

//Change puart baud rate. eg: 9600, 19200, 38200 */

wiced_hal_puart_set_baudrate(1000000);

//Start receive.

wiced_hal_puart_enable_rx();

and this is the code lines in PUART interrupt routine, for read byte and clear interrupt flag:

wiced_hal_puart_read(&pktBufRx[iPktBufRx]);

void IPP_ReceivedData(void* unused)

{

.

.

.

     iPktBufRx++;

     if(iPktBufRx>=sizeof(pktBufRx))

         iPktBufRx=0;

.

.

.

     wiced_hal_puart_reset_puart_interrupt();

}

It's a resource limitation of module or it's a software bug (mine or stack)?

0 Likes
Reply
1 Solution
Anonymous
Not applicable

It is not a bug in your code. I was able to reproduce the issue. The large number of PUART interrupts seem to be interfering with the Bluetooth interrupts causing the issue that you are seeing.

As a workaround, I disabled the interrupt, configured a timer and read the bytes inside the timer callback. It worked for me, maybe you could give it a try.

View solution in original post

3 Replies
Anonymous
Not applicable

It is not a bug in your code. I was able to reproduce the issue. The large number of PUART interrupts seem to be interfering with the Bluetooth interrupts causing the issue that you are seeing.

As a workaround, I disabled the interrupt, configured a timer and read the bytes inside the timer callback. It worked for me, maybe you could give it a try.

View solution in original post

LuGi_2890336
New Contributor II

Ok thank you! I'll try as soon as possible.

How many milliseconds you have set the timeout? I think could be useful to know the PUART buffer size to set the timeout. Do you know the buffer size? I didn't find this information in documents.

0 Likes
Reply
LuGi_2890336
New Contributor II

yssu I have tried to set timeout for PUART receive and:

1) I have to use directly "wiced_init_timer" function instead "wiced_bt_app_start_timer" because with the last one the module wasn't never visible.

2) With timer module doesn't reset but the audio continue to be breaking stop for a moment and restart. I'm using a 1ms timeout because with the speed that I need it's necessary this timeout but I don't think this is the problem.

After a few seconds the transmission on PUART is started, the module no longer receives bytes. Is it possible that the PUART is in OVERRUN? How can I know that?

However  the stange thing is that this behaviour happen also if I do not initialize PUART. Why? It's stange!

0 Likes
Reply