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.
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.
Thanks for answers userc_19497
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.
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.
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.
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?
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-gpio-basics#comment-42…
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.