BCM20737S acting different with same software

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

cross mob
Anonymous
Not applicable

Hello developers.

I'm programming these BCM20737S single chip modules with the WICED SMART IDE. My problem here is, why does two of the same kind of module act different, when i put the same software into them? (They are set to not to have same mac-address). I want the BLE modules to send data when connected to power (3.3V). One of them is sending the data continuously when connected to power through pin 3 (VBAT) 3,3V and a GND, while the other module is only sending once when connected. (Note that they both have the same software intergrated!) I have used the hello_sensor example. I have changed the BLE modules name and they both updated their names which can be seen through a BLE scanner which means that they both have downloaded the application.

One of the module are acting like it's suppose to do, while the other are doing some nonsense stuff.

Does anybody know why this is happening and what can i do?

0 Likes
1 Solution
Anonymous
Not applicable

Hi all,

After disabling of sleep the modules run continually. So that problem is solved.

With that code in Platforms\BCM920737TAG_Q32\BCM20737A1.cgs

ENTRY "I2C Speed"

{

    "Speed" = "400 KHz"

}

the modules start much faster. The problem is solved, but why should it make a difference?

View solution in original post

0 Likes
8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

I've never heard of this happening to be honest.

Have you implemented the crystal warmup procedure on both? Apart from the lower performing XTALs used on some modules - from a HW perspective - all of the modules are identical.

jamesle1

0 Likes
Anonymous
Not applicable

Hello.

What is the intended behavior of the application?

To send data continuously or send data once (or for certain amount of time)?

Also are you testing these with more than two modules?

Perhaps the module that is not producing the right behavior, is defective.

Can you test it with another module if you have one?

Also if the behavior is just sending data by broadcasting, I would try mybeacon application on both modules and see if they behave the same.

James

0 Likes

Agree, the module could be defective (although I doubt it), but I've also witnessed really screwey behavior due to board layout nuances.  (I'm no RF expert, but I do know when the layout was cleaned up, the problems went away).   Double check the date-codes on the modules to ensure they were indeed from the same MFG date.

If I were you, I'd disable sleep just to ensure there is no issue there, refer to Sleep Deep_Sleep Explanation and Techniques

Disabling Sleep also avoids having to monkey with the crystal warmup issue, until you've confirmed that it (the warmup issue) is actually at fault.   Disabling sleep also takes the infamous "P0" pullup resistor issue out of the conversation.

Could there be floating GPIOs that are causing interrupts to take over the system and crash it?

Can you use the MBT.EXE (manufacturing test) tool to exercise the modules?  Perhaps those tests may lead you towards something.   It's found in the SDK under ~Tools/mbt

I also agree with James to try one of the "stock" applications that come with the SDK before trying a custom application.

0 Likes
Anonymous
Not applicable

Thanks for answers jamesle1

I did as described here Crystal warm-up work-around video... . It has no effect.

If I change fine_timer_interval to less then 9, the module runs continually, ortherwise it dies after few advertisement messages. Furthermore, it takes about 2 seconds to start the module.

The first few modules we got from our supplier were free of these errors.

Any ideas?

0 Likes

Just to be sure on the BD address, below is an example of hello_sensor make target:

hello_sensor-BCM920736TAG_Q32 download BT_DEVICE_ADDRESS=3868A17223A2

If you have a tag3 board, you can verify some of these work on it.

0 Likes
Anonymous
Not applicable

Hi all,

After disabling of sleep the modules run continually. So that problem is solved.

With that code in Platforms\BCM920737TAG_Q32\BCM20737A1.cgs

ENTRY "I2C Speed"

{

    "Speed" = "400 KHz"

}

the modules start much faster. The problem is solved, but why should it make a difference?

0 Likes

There are two side-effects when sleep mode is enabled.  1 - The crystal warmup workaround may be necessary for some modules.  2 - You should put a 10K Ohm resistor on Pin P0 to prevent the Keyscan feature from inhibiting sleep mode.   Refer to the "mwf_mmfae Sep 22, 2015 10:56 AM" update from this thread for details:  https://community.broadcom.com/community/wiced-smart/wiced-smart-forums/blog/2014/12/17/bcm2073xs-gp...

0 Likes

It sounds like the defective module is going to sleep after transmitting once.

-The Keyscan problem prevents the module from going to sleep

-The Crystal warmup issue prevents the application from working as the crystal needs more time to stablize

So the question is what would cause one unit to go to sleep almost immediately after transmit.

Then, why would speeding the boot speed up from the default resolve this issue.

0 Likes