Boot Time of WICED Smart Tag Board (BCM20737)

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

cross mob
Anonymous
Not applicable

Hi all,

I want to know the boot time of BCM20737 Chip on WICED Smart Tag Board. I can't find any information from datasheet or in the community. If you know or ever measured the boot time, please let me know. Thanks!

I have tried to roughly measure the boot time, here are the steps:

1.  Upload the code to ROM so the chip can boot up directly from a power source (Coin Battery etc.)

2. I have designed a very simple switching circuit, so I can supply a pulse as the power source to WICED Smart Tag. I gradually change the pulse width and see whether the chip is booted or not.

3. When BCM20737 chip is booted, it will execute the code, this code will indicate the power supply circuit that chip is already on, then a real power supply will be applied to the WICED Smart Tag Board and keep it on.

So the possible results are:

1) If the boot time is too long and chip cannot be booted during the pulse width, the Tag Board won't start after the pulse turned down.

2) If the chip can be booted and execute the code successfully, a real power supply can keep the Tag Board on even the pulse turned down.


My measurement result is: If the pulse width is 1.5 second, the WICED Smart Tag Board won't start. If the pulse width is 2 seconds, it keeps on. So it seems that the WICED Smart Tag Board needs 1.5 to 2 seconds to boot up.


I think it is too long for a chip. How can we reduce the boot time? Is it related to the SDK version?


I am appreciate for any information or discussions. Thanks!

0 Likes
1 Solution

Yes, loading application and patches and applying the patches to the

internal ROM image is what takes the time. This is why it varies from one

SDK version to the next.. More / different patches.

In our case we have three seconds of buffering in the accelerometer so we

can respond ok with a pretty long boot time, but in SDK 2.2 it was too much.

If you need faster response the only thing to do is never go to hidoff

mode.. but then you have a battery problem. The lowest idle time cost I

have seen with this chip is 40 microamps.

On May 30, 2015 3:31 PM, "noalac" <communities-list@community.broadcom.com>

View solution in original post

0 Likes
8 Replies
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

Another approach that might be easier:

Modify the hello sensor app to configure and set a GPIO pin high as the first thing it does (i.e. in application_create())

Then, hook up a scope with one channel on the reset line (one leg of the reset switch) and the other on the gpio pin output.

Then, toggle reset and measure the time between the reset going high and the gpio line being asserted.

That said, your measurement results agree with my experience although I have not measured carefully.

The chip loads the firmware image from EEPROM and maybe does other stuff, which takes a long time on bootup (and also a lot of energy -- 10 mAS or more).

It is definitely a function of SDK version - SDK 1 is the fastest at a little under 1 second, SDK 2.1 is over a second, and SDK 2.2 was well over 2 seconds, and 34 mAS. I haven't tested 2.2.1.

In any case, I don't think there is any way to reduce boot time - it is a property of the Broadcom system firmware.  I agree it is pretty long.  In our case, we decided not to use SDK 2.2 because the boot time was so much longer that it no longer allowed our application to work properly.

Anonymous
Not applicable

The issue might be caused by loading the application from EEPROM. If the chip boots from external ROM, it is very likely to cost more than 1 second.

Based on my understanding, the internal ROM of BCM20737 chip is a MASK ROM, so user defined application can only be stored on the EEPROM.

The long boot time seems to be inevitable, but this issue makes the BCM20737 chip unsuitable for BLE applications, such as wireless charging or sensing.

Could I (at) someone who may help?

mwf_mmfae  j.t @dmiya

0 Likes

I'm not aware of a means to reduce the boot time.

In fact, I have never seen this topic even come up in the past.

The entire stack, core firmware, drivers, etc. are entirely stored in ROM internal to the device.  Only patches, the user application and things like the BD_ADDR are stored in extrnal EEPROM.

Search the site for 'minidriver' and you will see where the entire process is described in detail (minus specific timing of each step, which I don't think we can provide).

We can bring this up at the developer meeting next week, but until that time I'm not sure we will be able to provide the specific guidance you are looking for from Broadcom.

Anonymous
Not applicable

Thanks mwf_mmfae,

I have read the process related with minidriver, and am really appreciate your explanation.

But the boot time issue is still there. Please post the discussion result (the part that can be provided) and let us know.

Thanks.

0 Likes

Is this still an issue? noalac

0 Likes
Anonymous
Not applicable

HI boont

Thanks for your information. I am still working on my code. I will post updates in the future. Now I have chosen the correct answer and markEd helpful replies. Thank you all for helping me.

0 Likes

Yes, loading application and patches and applying the patches to the

internal ROM image is what takes the time. This is why it varies from one

SDK version to the next.. More / different patches.

In our case we have three seconds of buffering in the accelerometer so we

can respond ok with a pretty long boot time, but in SDK 2.2 it was too much.

If you need faster response the only thing to do is never go to hidoff

mode.. but then you have a battery problem. The lowest idle time cost I

have seen with this chip is 40 microamps.

On May 30, 2015 3:31 PM, "noalac" <communities-list@community.broadcom.com>

0 Likes
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

Arvind gave a thorough insight to this question of boot-up time in the below thread. It will give you some ideas and expectations depending on the size of your code.

Wake up time from sleep/deep sleep