Let me mention that I'm using our own hardware design in that test. Looking at the message I sent you, that wasn't obvious, sorry.
I have minimized the test that shows the issue and attached it to the message. I compiled it with:
adv_fail_test-BCM920737TAG_Q32 download BT_DEVICE_ADDRESS=20737A1A000F
adv_fail.zip 2.6 K
Have you tried hello_sensor (Advertises indefinitely) on the Broadcom TAG to see if this works?
Can you try hello_sensor on your board to see if it works?
Trying hello_sensor I found that when I start it multiple times on our hardware (one of the two faulty boards) that in some cases the advertisments stop without any trace in the output. I have attached the trace output (adv_bug.log) of one such case where after timeout 5 (11:51:11) Advertisments stop. The file adv_bug_scan.txt shows the received advertisments I collect under Linux with a CSR8510.
Let me also attach the BCM20737S part of our schematic:
I do not have the TAG board with the 20737. Also note that the Pullup for P1 (R107) is not placed since it didn't work then. LED and Button signals are active low.
Please check if the crystal matches specification. Also please check if increasing crystal warmup time helps.
I'm using the following app.cgs file:
ENTRY "PMU Crystal Warm up Time"
"Crystal warm up time" = 5000
ENTRY "I2C Speed"
"Speed" = "100 KHz"
I hope this works in SDK 2.2.0 just as well.
The 32768Hz crystal is the following:
I doubt that it could be a problem since the hello_service doesn't use it. I could check whether the load capacitance changes anything (15pF -> 12pF).
Changing the capacitance doesn't solve the problem. The supply voltage doesn't change the problem either, even though superficially it seemed that battery powered the problem occured less often.
Temperature changes didn't alter the frequency of the issue occuring either. What does seem to change it is using nonconnectable advertisments in the code I posted initially (from mybeacon).
//blecm_configFlag |= BLECM_DBGUART_LOG;
blecm_configFlag = 0;
// Configure P0 as active high input to pause advertisements.
// bleprofile_configureGpioForSkippingRf(GPIO_PIN_P0, GPIO_PIN_INPUT_HIGH);
// register with LE stack to be called 2.5msec before the advertisement event
// bleprofile_notifyAdvPacketTransmissions(&advertisement_packet_transmission, 2500);
// Set TX power for advertisement packets at 4dBm
bleapputils_changeLPOSource(LPO_MIA_LPO, FALSE, 500);
// Start advertisements
HCIULP_ADV_NONCONNECTABLE_EVENT, // non-connectable undirected advertisement
160, // adv interval 100 msec
HCIULP_ADV_CHANNEL_MAP_MASK, // all channels
HCIULP_PUBLIC_ADDRESS, // int advAdrType,
HCIULP_ADV_FILTER_POLICY_WHITE_LIST_NOT_USED, // int advFilterPolicy,
HCIULP_PUBLIC_ADDRESS, // int initiatorAdrType,
NULL); // UINT8* initiatorAdr
The same code using connectable Advertisments shows the problem however. Unfortunately I cannot solely use non-connectable advertisments. Even though my personal opinion is that BLE only ever needs 40 advertising channels + some random access scheme to support some message passing protocol , the current state of affairs requires that I open a connection to our device. If you could suggest a solution I would be glad.
We are chasing a bug reported by another customer that the duration while device is staying in the high duty and low duty advertisements may be off. If you look at the console output you can see when it happens. I guess if you do not care about high duty/low duty you can configure the parameters to be the same in the configuration, and just restart the advertisement when you receive notification that they are stopped.
Unfortunately BLE is using just 3 channels for advertisements repeating every message 3 times, and I do not think there is a way out of it. Establishing connection typically works better and saves power because you do not need to have the receiver opened all the time.
The thing is that the two buggy bcm20737S I have will not send advertisments again until I reset them. I tried this with alternating connectable and non-connectable advertisments, but this unfortunately doesn't work.
Notice that my software normally works on the BCM20737S but our concern is that there are too many faulty devices and the test we have is too unreliable to catch them all.
Also somebody else has seen similar behaviour:
So we need a reliable test or a means to get the buggy devices to work even with the issue.
I noticed that while I cannot receive any advertisments neither with Linux nor with the TI sniffer, I see a current draw every 100ms and also the callback registered with the function bleprofile_notifyAdvPacketTransmissions() is still called. So I can't reset the chip to get the advertisments back, because I just don't know when they are gone.
As a side note the bleprofile_notifyAdvPacketTransmissions() callback now also works with connectable advertisments. Maybe this changed in SDK2.2.0 - very nice.
Today I tested the transmitter of the buggy device with mbt and it showed no fault after about an hour of runtime. I only used channel 0, I have no idea whether this is a good test.
Sorry for the long delay, but we were revisiting your post.
We hope all is well in your design.
"I'm using the following app.cgs file"
1. Did you create a cgs file in the App Directory?
2. A suggestion might be to:
3. Change /WICED-Smart-SDK/Wiced-Smart/tier2/brcm/mandatory/bld/2073X/mandatory.cgs
4. Then set "Crystal warm up time" = 5000, clean and build
Hope this helps,
1. Did you create a cgs file in the App Directory?
2. A suggestion might be to: ...
Ok, I'll give that a try. It is currently set to 2800. I always assumed that it is overwritten by whatever comes after
# End of configdata_common.agi
in the cgs file that lives under build/xyz-app-BCM920737TAG_Q32-rom-ram-Wiced-release/
Apart from that we will try to go with the 20736S for now, assuming that we can port our code. We have heard only good from our distributor about this chip so my focus is now on the porting effort once we get the hardware. The other reason to use the 20736S is the availability of the 20736E which we will focus on next.
Note that we found out today from the developers that some of our tier 1 customers have actually run into isolated instances where the crystal warmup period needs to be increased to 6000, or slightly more (even 7000). If more than 7000 is needed, then there is something else that is causing the issue.