- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I made a couple of very simple custom boards that host the BCM20732S SiP.
I can successfully download the firmware onto the module and connect to it. However if I disconnect and try again, the peripheral cannot be discovered anymore.
1 - I use LightBlue app to scan and connect to the peripheral.
2 - I tired this with other sample firmwares that same with the SDK and the same things happened. Confirming that this has nothing to do with my own firmware.
3 - The interesting thing is that I do not have any issue with the BCM20732 TAG dev kit. I can connect and disconnect as many times as I want to the peripheral but when I run the same code on the module, the module becomes undiscovered after 1 or 2 times of connecting to it. Depending on how much time I allow before I disconnect and reconnect, I can only reconnect only once or twice before the module become undiscoverable (stops advertising).
4 - At first I though the problem might be because of lack external pull-up/down resistors on RESET, TMC, SDA, SCL pins (I assumed they are probably picking up noise). Then I tired soldering pull-up/down resistors to these pins through test pad on my board, but the issue persists.
5 - I barely have anything else on the board and this is driving me nuts. I can share the schematic through email (since I cannot attach pictures here)
Please help!
Thanks,
Mehrdad
Solved! Go to Solution.
- Labels:
-
Crystal Warm-Up
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent work, you just saved my bacon! Had just started a production build and had the same exact issue. Even the exact same datecode. Oddly the datecode of my preproduction parts were newer than my latest order... Will have to keep tabs on this one. This might also explain some odd issues I had with my an occasional pre-production unit sometimes disappearing briefly at start-up as it may have been on the edge of long enough delay.
Cheers.
Joel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spoke to the team and they suspect that you are using the S03 module. If the device is going to sleep and not waking up, it is probably because of the xtal warm up is not long enough (our packaging house changed the xtal from S02 and it takes much longer to come up).
Can you contact your local distributor/Broadcom sales team and obtain some additional modules?
One sure way of telling if this is the problem is by disabling sleep (app registers with devicelpm and then returns 0 when polled for sleep). If you stop seeing the problem with sleep disabled, then the xtal is the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These are my observations so far.
1) I ran Hello Sensor on the module and by looking at the ble traces, after connection down callback, advertizing does not resume.
2) pollpowersave returns 0.
Can this be related to xtal warmup time? If so how can we change (increase) xtal warmup time in the firmware?
Thanks,
Mehrdad
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here's the module info:
Lot No. 317132
Date Code: TN 1337 21
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are working with the factory on translating the date/lot code information to module revision. If needed, your local distributor will sample new parts.
Have you confirmed that the problem goes away when disabling sleep per the instructions here: http://community.broadcom.com/message/2320#2320
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirm that issue was due to crystal warmup time.
We manage to resolve this issue in firmware by doing the following:
1 - create a CSG file inside the application folder named app.csg with the content below:
ENTRY "PMU Crystal Warm up Time"
{
"Crystal warm up time" = 5000
}
Note that the default Crystal warm up time is 2500. By increasing this to 5000 we managed to resolve the issue.
2 - Add the following line to makefile.inc in the same folder:
GS_LIST += $(DIR)/app.cgs
This trick only works in SDK 1.1 and does NOT work in version 1.0.1.
Needless to say we spent weeks to fix this bug while I would have expected the Broadcom team to come up with this a lot faster and saved us this huge headache.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for sharing. I had the same issue; this saved me a great deal of time. I can confirm that turning off sleep mode and your solution worked for me. Just to reiterate:
Solution 1.
a. In file Platforms>BCM920732TAG_Q32>BCM20732A0.cgs change "Sleep enable" = 1 to "Sleep enable" = 0
b. Done
Solution 2.
a. Create file xtal.cgs in your application folder with content:
ENTRY "PMU Crystal Warm up Time"
{
"Crystal warm up time" = 5000
}
b. In your makefile.inc add:
CGS_LIST += $(DIR)/xtal.cgs
c. Done
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, jpwerre. The solution 1 changing "Sleep enable" to 0 save my problem.
Julien
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent work, you just saved my bacon! Had just started a production build and had the same exact issue. Even the exact same datecode. Oddly the datecode of my preproduction parts were newer than my latest order... Will have to keep tabs on this one. This might also explain some odd issues I had with my an occasional pre-production unit sometimes disappearing briefly at start-up as it may have been on the edge of long enough delay.
Cheers.
Joel