- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Thanks,
Fran
Solved! Go to Solution.
- Labels:
-
Peripherhal UART
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have flow control enabled ?
Looks like you're overwriting UART RX FIFO.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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);
...
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, disabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).