UART rx over 15 bytes question on SDK2.1.1/BCM20736

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi Sir,

I check a lot of information on the forum about UART routine, but I still can find how to deal with it.

We connect the puart to micro-controller and proceed the communication between.

The problem is when the MCU continuous sending the data over 15 bytes. The data over 15 bytes are gone.

The signal from the MCU Tx to BCM20736 puart Rx as the photo. The baudrate is 115200/8n1, these packet is around 25 bytes.

I've tried rx interrupt callback, busy polling puart_read, all can get just 15 bytes...

Do you have any suggestion?

IMG_0229.JPG

Thanks,

Fran

0 Likes
1 Solution
Anonymous
Not applicable

If you see only 0-15 that means you are getting 16 bytes and this is the size of RX FIFO.

The rest are lost due to the lack of flow control.

View solution in original post

13 Replies
Anonymous
Not applicable

Update new information.

I upgrade to latest SDK2.2 and got the same results.

One more experiment, I do a testing that separate the 25 bytes data into 15bytes->delay10ms->10bytes that transmit from MCU Tx to BCM20736 Rx and the waveform like following picture. I can get all packet correctly.

Does it an expected behaviour?

IMG_0230.JPG

0 Likes
Anonymous
Not applicable

Do you have flow control enabled ?

Looks like you're overwriting UART RX FIFO.

Anonymous
Not applicable

No, the flow control is off.

A question is that if the fifo are 16 bytes, why is that happen?


eg. I set the configuration to be rx interrupt per byte. The interrupt callback should be triggered immediately when first byte is received. After 1st byte is read, there is one byte fifo space is free. But the behaviour seems not like that.

I also try the busy rx by polling in the fine timer and I get the same results.


It looks like the mechanism not as what I think. Can anyone answer it?

0 Likes
Anonymous
Not applicable

Did you disable sleep mode ?


// Callback called by the FW when ready to sleep/deep-sleep. Disable both by returning 0

// when there is an active download ongoing.

static UINT32 serial_uart_device_lpm_queriable(LowPowerModePollType type, UINT32 context)

{

  // Disable sleep.

  return 0;

}

void UART_init()

{

  ...

  devlpm_registerForLowPowerQueries(serial_uart_device_lpm_queriable, 0);

  ...

}

Anonymous
Not applicable

Yes, disabled.

0 Likes
Anonymous
Not applicable

Make sure the RX FIFO is empty and then send the exact 16-byte block but enumerate each byte 1..16 and upon receiving check which byte is missing/overwritten

Anonymous
Not applicable

What I saw earlier today was not like overwritten, eg. if I mark it as from 0~25, it just show 0~15, 16~25 are disappear.

Anyway, I'll double check again later.

0 Likes
Anonymous
Not applicable

If you see only 0-15 that means you are getting 16 bytes and this is the size of RX FIFO.

The rest are lost due to the lack of flow control.

Anonymous
Not applicable

I'll send more test result here. Even no flow control, it's still weird... unless it's the hardware limitation.

BTW, if it's really hardware limitation, what's the min time is required between packet(16bytes) and packet(16 bytest)?

0 Likes
Anonymous
Not applicable

Hi Sir,

It's seems overwritten in last bytes. I also try 1ms delay from MCU between 16 bytes and still get some bytes loss occasionally.

May I ask one question, does the rx callback is execute in hardware interrupt service routine or it's a software event callback?

0 Likes

When rx data arrive, an interrupt service routine will be triggered to put the event into message queue by using bleappevt_serialize(). So application thread will process it at a later time.

To get more info about bleappevt_serialize(), you can refer to http://community.broadcom.com/message/4254#4254. arvinds has elaboration about that in very detail.

Anonymous
Not applicable

Thanks, it totally explain why over written happen.

But I still have a question, is there any suggestion of the min delay between the 15bytes packet?

0 Likes

You never want to use delays because it is not a scalable solution. Use HW flow control or SW flow control (like the UART firmware upgrade app does - sends a 1 byte ack for every 15 byte chunk).