Smart Bluetooth Forum Discussions
BCM20732S and BCM20737S data sheet state max. reflow temp = 245°C
but process needs 250°C.
Can Broadcom confirm 250°C reflow temperature is possible?
Show Less
Hi All,
So far, as we knew the fine timer is the SW timer and was driving by App thread and we have to use the timer to implement loop.
We require to have the periodic 20 Hz timer (uniform) to access sensor data and also need to calculate the senor data.I have some question.
1.The max escape time value of fine timer, if I configured fine timer to 20 Hz. The value shall not affect the BLE stack behavior
50ms is fine.
2.How to guarantee the uniform interval timer.what's delta time of the each tick .
12.5ms
3.Can we have the independent HW timer to access sensor rather than the SW timer.
Better not to use HW timer but we have seen 6.25ms
Br,
BB119
Show LessExternal MCU Design Purpose
BCM2073X is a great SoC for most of IoT/wearable products.But an external MCU may be needed for more complicated use case such as smart watch on which there are LCD, camera etc. This article is a guide on hardware design between BC2073X and external MCU.
System Architecture Introduction
Architecture Diagram
The following Figure shows the usual connection between MCU and BCM2073X chip, together with some other devices.
Fig1
The Interconnection BUS between MCU and BCM2073X
There are at least five interconnection bus needed between MCU and our BCM2073X chip: UART RX/TX, RESET, INT, and Wake up signals.
UART RX/TX buses are recommended to do data communication work, like notification status reporting data, external sensors inputting data, LCD display data, camera image data etc.
A reset signal from MCU to BCM2073X chip is used to give a reset signal when BCM2073X chip starts
up, or at any time when BCM2073X work abnormally.
An INT signal is an interruption from BCM2073X chip to MCU. For the occasion when MCU is in sleep mode, there are incoming calls,
messages, alarm or other notifications from the smartphones, tablets or other smart devices, which are connected with our BCM2073X chip through Bluetooth4.0/4.1. BCM2073X chip delivers these messages to MCU once it gets them, so that MCU can manage the related external devices to make the related response.The related response includes turning on or off LCD/LED/Vibrator/buzzer, etc., we can see the related devices showed on the above Fig.
A wake up signal is critical to MCU to wake up BCM2073X chip, when BCM2073X is in sleeping mode. For example when there are inputs from sensors, MCU will send a dedicated status update to BCM2073X after calculation, and BCM2073X chip pass them to the smart device for notifying the end user.
SW Download/Debugging Interface
SW downloading and debugging interface is located in MCU side, the software download interface can be UART or USB. This is determined by the MCU chip we choose. Ask support from MCU vendor for detailed download method.
The debugging interface can be shared with the download UART interface, or other ports. It’s also determined by MCU chips.
RF Testing Interface
We can do RF testing by separately controlling BCM2073X chip to enter into a testing mode by using Broadcom MBT tool. For HW, we connect BCM2073X chip UART RX/TX pin with a computer’s RS232 port. A level shift is needed for keeping the voltage of the two side at the same level, usually 5V voltage level from the computer side, a Vx(for BCM2073X chip, the voltage range is1.6-3.6V, the dedicated value of Vx is determined by BCM2073X, MCU and all the other device) voltage level from the board side. We can also have another simple way to add a USB to COM converting chip to connect BCM2073X UART RX/TX pin on the PCB board with the computers by common USB bus. Please refer the picture below for the detail physical connection between the instruments and the tested device.
For the detailed testing procedures we can refer to the application notes of BLE RF Testing Setup Procedures.
Of course, we have some other methods to do the RF testing, since the extra MCU is the master chip of the whole board, we choose MCU UART interface for commands inputting interface, the dedicated testing commands were sent by the putty or hyper terminal tool passing MCU UART interface to control BCM2073X chip, of course the detailed controlling way mostly rely on the MCU system used; or we also can have another method to integrate the dedicated testing commands into the source code of MCU system side, downloading into the memory on the board, a special testing tool can be added in a APK tool of the smart device in the far end, the special commands of APK tools trig the different testing mode of BLE chip, let the testing work going on by the clear human-computer interaction interface APK tool. MCU pass them to the BCM2073X chips, let it enter into the related testing mode.
Components Selections
For the wearable products, power consumption is the critical side for whole system. Both application requirement and power consumption should be considered during component selection. For MCU, Freescale’s KL25 is one of recommends for wearable products.
LDO or DC to DC convertor is the other key component on the board, the lower working power and the lower idle leakage current is preferred. SII S-1313 is one of recommendation with only 10nA current consumption in sleeping mode.
The other devices like G-sensor, LCD, UV-sensor, etc.Please also consider its working power consumption and standby, sleep power
consumption, make sure they have deep sleep mode and wake up mechanism, when not used, can enter into the deep sleep mode for power consumption reducing and easily return from the deep sleep mode.
Components’ dimension size is needed to be taken into the considerations, which can make the total PCB board smaller and flexible to fulfill the different shape demands of the wearable products. For example, 0201package size is preferred to the RCL parts. CSP and BGA package is recommended for IC chip,and module with more integrated functions is preferred for the ultra small wearable products.
Hello,
I have the following problem, I don't know if it is related to the Android-Application or the BT-Module.
The first connection, when the user connectes the Smartpone and the Module, all Characteristics and Data are read within 2-4 seconds (after he entered the pin). But if he reconnects to to the Module, the reading of all Characteristics and Data will take about 10-30 seconds.
Anybody a hint what could be the reason for this?
Show LessI'd like to reduce frequency of waking-up from sleep due to battery life.
When I configure 1,000[ms] as adv_interval,
is advertising happens at the same timing with 1s normal timer?
I don't want to let it wakes up twice a second.
Show LessHi,
- According to Bluetooth SIG, the 4.1 spec for BLE supports L2CAP programming - Vendors can create profile over L2CAP. (In 4.0 spec, the custom profile was only possible above GATT). Since 20736/37 are designed for 4.1 spec, do they support custom profiles on L2CAP? And if they do is there any example on the SDK 2.2?
- Can the chip operate without GAP? Or in other words, can we avoid using GAP and GATT?
- BLE spec lists that the device can have 3 MAC address - public, random and hard. Which ones are supported on the stack. Does it specifically support random MAC address?
- If a device is advertising, can we only discover the device on GATT layer or is it discoverable on the L2CAP layer?
- L2CAP supports 23 bytes according to 4.1 spec. How many packets can a device transmit continuously before maxing out?
- Does Broadcom have a technical document which says what all does it provide from the 4.1 ble specs on their stack?
- According to the example the interval between two advertisements can be a maximum of 40.96(UINT16). Is this right?
- Does Broadcom support lazy scan? Any example or documentation is available if any?
- Does does one find the latency for when a device transmits an advertisement packet and then the scan response data packet? Can we control when we send Scan response?
- Is controller manager in the ble stack api the way we can control GAP, which is responsible for scanning or this the link management layer?
- When we use GATT, we can use the cache. If we use any other layer can we use the cache as well(ex. L2CAP)?
- On GATT level, L2CAP size is 23 bytes, some devices can support more than it. The client or the server may support more than 23 bytes. For this to work the devices need to communicate to check if the other device can support this? Is there a way to do this check?
I'm trying to get a notification service up & going. The App I've got is unreliable in it's ability to successfully sign up for, & receive notification data.
The code I've got so far receives a 10 byte packet from another µC every second. It then tries to push that data via a Vendor Specific Notification service created by the Smart Designer. The code doesn't request or enable security. ( /*.encr_required =*/ 0, //(SECURITY_ENABLED | SECURITY_REQUEST), // data encrypted and device sends security request on every connection)
Below is an annotated trace dump showing my App unsuccessfully signing up for notifications & then retrying resulting in success.
16:18:56 - | |
16:18:56 - Pckt(10):ba00 & 4a93 | Packet received by Broadcom from MSP, size 10 bytes. |
16:18:56 - timeout:29 | |
16:18:57 - | |
16:18:57 - Pckt(10):bb00 & 4a93 | |
16:18:57 - timeout:30 | |
16:18:58 - | |
16:18:58 - Pckt(10):bc00 & 4a93 | |
16:18:58 - timeout:31 | Broadcoms 1s timer |
16:18:59 - | |
16:18:59 - Pckt(10):bd00 & 4a93 | |
16:18:59 - timeout:32 | |
16:19:00 - | |
16:19:00 - Pckt(10):be00 & 4a93 | |
16:19:00 - timeout:33 | |
16:19:01 - | |
16:19:01 - Pckt(10):bf00 & 4a93 | |
16:19:01 - timeout:34 | |
16:19:02 - | |
16:19:02 - Pckt(10):c000 & 4a93 | |
16:19:02 - timeout:35 | |
16:19:03 - | |
16:19:03 - Pckt(10):c100 & 4a93 | |
16:19:03 - timeout:36 | |
16:19:04 - | |
16:19:04 - connection_up: 78a8735dd09b h=64 | First Connection since programming. |
16:19:04 Connection is UP. | |
16:19:04 profile idle timer stop | |
16:19:04 connUp | |
16:19:04 noAdv | |
16:19:04 noAdv | |
16:19:04 - Pckt(10):c200 & 4a93 | NB: because no other messages appear here the Broadcom is not attempting to send any data because no "bonded peer" has been located. |
16:19:04 - timeout:37 | |
16:19:05 - | |
16:19:05 - Pckt(10):c300 & 4a93 | |
16:19:05 - timeout:38 | |
16:19:06 - | |
16:19:06 - Pckt(10):c400 & 4a93 | |
16:19:06 - timeout:39 | |
16:19:07 - | |
16:19:07 - Pckt(10):c500 & 4a93 | |
16:19:07 - timeout:40 | |
16:19:08 - | |
16:19:08 - Pckt(10):c600 & 4a93 | |
16:19:08 - timeout:41 | |
16:19:09 - | |
16:19:09 - Pckt(10):c700 & 4a93 | |
16:19:09 - timeout:42 | |
16:19:10 - | |
16:19:10 - Pckt(10):c800 & 4a93 | |
16:19:10 - timeout:43 | |
16:19:11 - | |
16:19:11 - Pckt(10):c900 & 4a93 | |
16:19:11 - timeout:44 | |
16:19:12 - | |
16:19:12 - Pckt(10):ca00 & 4a93 | |
16:19:12 - timeout:45 | |
16:19:13 - | |
16:19:13 - Pckt(10):cb00 & 4a93 | |
16:19:13 - timeout:46 | |
16:19:14 - | |
16:19:14 - Pckt(10):cc00 & 4a93 | |
16:19:14 - timeout:47 | |
16:19:15 - | |
16:19:15 - Pckt(10):cd00 & 4a93 | |
16:19:15 - timeout:48 | |
16:19:16 - | |
16:19:16 - Pckt(10):ce00 & 4a93 | |
16:19:16 - timeout:49 | |
16:19:17 - | |
16:19:17 - Pckt(10):cf00 & 4a93 | |
16:19:17 - timeout:50 | |
16:19:18 - | |
16:19:18 - Pckt(10):d000 & 4a93 | |
16:19:18 - timeout:51 | |
16:19:19 - | |
16:19:19 - Pckt(10):d100 & 4a93 | |
16:19:19 - timeout:52 | |
16:19:20 - | |
16:19:20 - Pckt(10):d200 & 4a93 | |
16:19:20 - timeout:53 | |
16:19:21 - | |
16:19:21 - Pckt(10):d300 & 4a93 | |
16:19:21 smp timer started 00 | First attempt to sign up for Notifications. |
16:19:21 - timeout:54 | |
16:19:21 - | |
16:19:21 SMPTmrRef | |
16:19:21 SMPTmrRef | |
16:19:22 - encryption changed 78a8735dd09b | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrRef | |
16:19:22 SMPTmrStp | |
16:19:22 - Pckt(10):d400 & 4a93 | |
16:19:22 - smp_bond_result 03 | Successful bonding |
16:19:22 - NVRAM write:0018 | Writing Bonding data to non-volatile RAM on Broadcom. |
16:19:22 - timeout:55 | |
16:19:23 - | |
16:19:23 - Pckt(10):d500 & 4a93 | |
16:19:23 - don't notify handle:811 | (This is the extra message that we didn't see earlier) Now the notification function has located a "bonded peer" but as far as it knows that peer hasn't signed up for notifications. |
16:19:23 - don't notify handle:541 | |
16:19:23 - timeout:56 | |
16:19:24 - | |
16:19:24 - Pckt(10):d600 & 4a93 | |
16:19:24 - don't notify handle:811 | |
16:19:24 - don't notify handle:541 | |
16:19:24 - timeout:57 | |
16:19:25 - | |
16:19:25 - Pckt(10):d700 & 4a93 | |
16:19:25 - don't notify handle:811 | |
16:19:25 - don't notify handle:541 | |
16:19:25 - timeout:58 | |
16:19:26 - | |
16:19:26 - Pckt(10):d800 & 4a93 | |
16:19:26 - don't notify handle:811 | |
16:19:26 - don't notify handle:541 | |
16:19:26 - timeout:59 | |
16:19:27 - | |
16:19:27 - Pckt(10):d900 & 4a93 | |
16:19:27 - don't notify handle:811 | |
16:19:27 - don't notify handle:541 | |
16:19:27 - write_handler: handle 0550 | This is where the notifications checkbox, which is ticked from the first touch is pressed again unchecking the box, i.e. writing "0" to HDLD_ALERTS_CLIENT_CONFIGURATION (0550) |
16:19:27 - handle:550 val:0000 | |
16:19:27 - NVRAM write:0018 | |
16:19:27 WriteCb: handle 0000 | |
16:19:27 - timeout:60 | |
16:19:28 - | |
16:19:28 - Pckt(10):da00 & 4a93 | |
16:19:28 - don't notify handle:811 | |
16:19:28 - don't notify handle:541 | |
16:19:28 - timeout:61 | |
16:19:29 - | |
16:19:29 - Pckt(10):db00 & 4a93 | |
16:19:29 - don't notify handle:811 | |
16:19:29 - don't notify handle:541 | |
16:19:29 - timeout:62 | |
16:19:30 - | |
16:19:30 - write_handler: handle 0550 | 2nd attempt to sign up for notifications Now the notifications checkbox on the Broadcom is pressed again, "checking" the box, writing "1" |
16:19:30 - handle:550 val:0001 | |
16:19:30 - NVRAM write:0018 | |
16:19:30 WriteCb: handle 0000 | |
16:19:30 - Pckt(10):dc00 & 4a93 | |
16:19:30 - don't notify handle:811 | |
16:19:30 - notify len:10 handle:541 | Now that a bonded peer is found & that peer has signed up for notifications, data is sent reliably between connections & disconnections. |
16:19:30 - timeout:63 | |
16:19:31 - | |
16:19:31 - Pckt(10):dd00 & 4a93 | |
16:19:31 - don't notify handle:811 | |
16:19:31 - notify len:10 handle:541 | |
16:19:31 - timeout:64 | |
16:19:32 - | |
16:19:32 - Pckt(10):de00 & 4a93 | |
16:19:32 - don't notify handle:811 | |
16:19:32 - notify len:10 handle:541 | |
16:19:32 - timeout:65 | |
16:19:33 - | |
16:19:33 - Pckt(10):df00 & 4a93 | |
16:19:33 - don't notify handle:811 | |
16:19:33 - notify len:10 handle:541 | |
16:19:33 - timeout:66 | |
16:19:34 - | |
16:19:34 - Pckt(10):e000 & 4a93 | |
16:19:34 - don't notify handle:811 | |
16:19:34 - notify len:10 handle:541 | |
16:19:34 - timeout:67 | |
16:19:35 - | |
16:19:35 - Pckt(10):e100 & 4a93 | |
16:19:35 - don't notify handle:811 | |
16:19:35 - notify len:10 handle:541 | |
16:19:35 - timeout:68 | |
16:19:36 - | |
16:19:36 - Pckt(10):e200 & 4a93 | |
16:19:36 - don't notify handle:811 | |
16:19:36 - notify len:10 handle:541 | |
16:19:36 - timeout:69 | |
16:19:38 - | |
16:19:38 - Pckt(10):e300 & 4a93 | |
16:19:38 - don't notify handle:811 | |
16:19:38 - notify len:10 handle:541 | |
16:19:38 - timeout:70 |
So it looks like the first attempt to sign up for notifications from the app resulted in a lesmp_sendSecurityRequest(). Is this expected behaviour when encr_required = 0?
Show LessHello Broadcom team,
Could you please clarify the Power up and down sequence for BCM20736 device?
I would like to know the detail of the timing chart like "Figure 4: Internal Reset Timing" on page 16 of "20736-DS102-R".
Best regards,
D.Kato
メッセージ編集者: 大輔 加藤
Show LessHello Broadcom team,
I’m considering booting up BCM20736 from Host via SPI slave function. (Not EE-PROM or F-ROM)
Can you support the Host boot like above?
If yes, could you please provide us some instructions or documents to use the Host boot?
Show Less