Prototype boards are failing with issue similar to one previously reported

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

cross mob
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

wrote that 12 of the 20 BCM20737S based boards we received, 2 exhibited a failure that appears to be similar to Advertisement seems to be flakey

With a simple piece of example code the fault typically appears after 10s to 60s of sending Advertisements.

There are a number of issues we have with the problem:

- There are cases where we are unable to detect it when running the test, but the device does fail if we test it more often, so this seems to be a soft issue to some degree which makes testing difficult.


- There are too many unusable devices in our admittedly small sample.

- Going to deep sleep resolves the problem, but we need to send advertisements for a long time >30s which makes this an unusable strategy. Not to mention the fact that the chip is unreliable.

So we need at least a better testing method, and at best some mitigation strategy.

0 Likes
1 Solution
Anonymous
Not applicable

I ported our application to the new SDK and my experiments with one faulty bcm20737S showed that the new SDK resolves the issue. This is great news! Thanks a lot.

Regards,

Kilian

View solution in original post

0 Likes
17 Replies
Anonymous
Not applicable

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

Kilian

0 Likes
Anonymous
Not applicable

Hello Kilian,

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?

Thanks

JT

0 Likes
Anonymous
Not applicable

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:

pastedImage_0.png

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.

Regards,

Kilian

0 Likes

Please check if the crystal matches specification.  Also please check if increasing crystal warmup time helps.

0 Likes
Anonymous
Not applicable

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:

AB26TRB-32.768KHZ-T - ABRACON - CRYSTAL, 32.768KHZ, 12.5PF, SMD | Farnell element14

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).

Regards,

Kilian

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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).

...

adv_fail_test_create(void)

{

  //blecm_configFlag |= BLECM_DBGUART_LOG;

  blecm_configFlag = 0;

  bleprofile_Init(bleprofile_p_cfg);

  bleprofile_GPIOInit(bleprofile_gpio_p_cfg);

      // 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

      blecm_setTxPowerInADV(4);

      bleapputils_changeLPOSource(LPO_MIA_LPO, FALSE, 500);

      // Start advertisements

      blecm_startAdv(

          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.

Regards,

Kilian

0 Likes

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.

0 Likes
Anonymous
Not applicable

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:

Advertisement seems to be flakey

So we need a reliable test or a means to get the buggy devices to work even with the issue.

EDIT:

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.

Regards,

Kilian

0 Likes
Anonymous
Not applicable

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.

Regards,

Kilian

0 Likes
Anonymous
Not applicable

Hello Kilian,

Sorry for the long delay, but we were revisiting your post.

We hope all is well in your design.

You mention:

"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,

Sincerely,

JT

0 Likes
Anonymous
Not applicable

1.  Did you create a cgs file in the App Directory?

Yes.

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

#  $AUTOGEN(INCLUDE_FROM{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.

Regards,

Kilian

0 Likes

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.

0 Likes
Anonymous
Not applicable

I ported our application to the new SDK and my experiments with one faulty bcm20737S showed that the new SDK resolves the issue. This is great news! Thanks a lot.

Regards,

Kilian

0 Likes

This is great news.  Thanks for updating the discussion.

0 Likes
Anonymous
Not applicable

SDK 2.2.3 on Windows caused very strange errors to occur.  LEDs blinking erratically, resets, etc.  We think there~s something wrong with the fine timer in this SDK version for Windows.

We finally went back to SDK 2.2.2 on Mac.  Now the downloaded code works fine, but the initial problem of about 10% of the boards STOPPING ADVERTISEMENT is back.

How can we solve this problem?  It's always the same boards that fail; it's not random.  For example, if you have 70 boards and about 7 fail, then if you reset/restart all 70, the same 7 will fail again.

This is not a manufacturing issue, because we have used 4 different manufacturers, and different versions of the PCB layout (which follows your guidelines) and always get the same identical problem.

We need to solve this problem badly!!!!

Thanks,

Gil

0 Likes