Transmission times of connection event? - Part3

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

cross mob
Anonymous
Not applicable

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,

0 Likes
1 Solution

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.

frank

View solution in original post

4 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

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.

0 Likes
Anonymous
Not applicable

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,

0 Likes

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.

frank

Anonymous
Not applicable

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,

0 Likes