- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi BRCM FAE,
As a continuation of this thread: Transmission times of connection event? & Transmission times of connection event? - Part2
I finally found out where the problem.
I add this to the end of my APPLICATION_INIT:
BLE_APP_DISABLE_TRACING(); |
When I disable the trace of HCI UART, I can get 4 packets in each connection after performing a reset.
BAD HCI UART! BAD!
But I still have a question. Why does the stack work properly (send 4 packets in each connection event) after I download the firmware? But I execute the reset, I only got 1 packet in connection event. The HCI UART printed the same results when I execute reset and download the firmware. What the different between execute reset and download the firmware? Dose the ROM operation in different states when I execute reset and download the firmware?
Michelle,
Solved! Go to Solution.
- Labels:
-
MasterSlave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are actually a few threads that discussed about how by disabling tracing can get things to run faster.
Is 80 kbps throughput really possible with 20736S?
Minidriver should not be a concern as it is responsible for pushing the code into the nvram when you program it. I don't have a reply to your question, perhaps tracing is hogging resources at the expense of the overall performance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you doing all this on your custom board or the tag3 eval board? After a reset, the code residing in the eeprom will be loaded onto the ram for processing. Therefore a reset should not change the characteristic of your application.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi boont,
Thank for your comment.
Are you doing all this on your custom board or the tag3 eval board?
>I use the custom board to doing the test.
After a reset, the code residing in the eeprom will be loaded onto the ram for processing.
>OK. The minidriver will loaded the application into the ram. Is the stack in the rom will loaded same part(download firmware and execute reset) into the ram?
I would like to clarify this phenomenon.
Enabled HCI debug trace:
download the application: 4 packet in each connection event
execute reset: 1 packet in each connection event
disable HCI debug trace:
download the application: 4 packet in each connection event
execute reset: 4 packet in each connection event
If the firmware in the ram is same(After download the application and execute reset). Why I got different packet amount when I enable HCI debug trace?
Michelle,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are actually a few threads that discussed about how by disabling tracing can get things to run faster.
Is 80 kbps throughput really possible with 20736S?
Minidriver should not be a concern as it is responsible for pushing the code into the nvram when you program it. I don't have a reply to your question, perhaps tracing is hogging resources at the expense of the overall performance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi boont,
Thank for your comment.
It seem the cpu loading will affect packet amount in connection event. So we disable HCI trace will reduce cpu loading.
I add this to the end of my APPLICATION_INIT, and it will reduce cpu loading.
APPLICATION_INIT()
{
bleapp_set_cfg(..................);
BLE_APP_DISABLE_TRACING(); //disable the HCI trace
}
Michelle,