Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

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


// 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.


/* Turn on flow control */


// BEGIN - puart interrupt


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


//Start receive.


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


void IPP_ReceivedData(void* unused)













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

1 Solution
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