Smart Bluetooth Forum Discussions
We want to dynamically change the BD_ADDR of our 20736 device to a Non-Resolvable Private Address (see BLUETOOTH SPECIFICATION Version 4.0, 10.8.2.1).
We know that we can specify a 'static' BD_ADDR which will never change.
But now we need to change the BD_ADDR every now and then to a Non-Resolvable Private Address.
How would we do this?
There is a function called blecm_set_static_random_bd_addr() but it looks like this is not what we need because it can only be called once but we have to change the BD_ADDR as often as we want.
Show LessHi,
I've downloaded the provided WICED Smart SDK v2.1.1 and have begun experimenting with it.
My question is regarding the "other" side of the communication - that of the Smart-Ready devices.
Is there an SDK that is provided by Broadcom (to employees/developers) to begin developing these "server-side" applications?
If there are such kits - preferably for Windows 7/8 - I'd appreciate it if anyone could point me to them.
Thanks in advance!
Regards,
Arik
Show LessHi,
I received the BCM20737S WICED Sense TAG for experimentation(hackathon). After installing the SDK, I compiled one of the existing targets ("Hello Client") and downloaded it to the device. The new code overwrote the original code that came with the tag, and now the tag won't work with the WICED Sense application.
I've tried to recover the device several times based on the information in the recovery video and various documentation (BOOT->RESET->RELEASE BOOT->RELEASE RESET and BOOT->RESET->RELEASE RESET->RELEASE BOOT etc.) multiple times, but it didn't restore the tag to its original state.
Could you please refer me to the location of the original code (BRCM internal/external site), so I can recompile and restore the tag to its original state?
Thank you,
Arik
Show LessI downloaded WICED Smart IDE 2.1.1 and followed all the instructions in the Quick Start Guide (WICED-Smart-QSG202) up to page 14 where you double-click the newly created heart_rate_monitor-BCM920737TAG_Q32 download target to build the heart rate monitor application, but the build crashes and I get a "Symbol 'bleapp_pre_init' could not be resolved" error in the sparinit.c file
Show LessI have a WICED BCM9WCDPLUGS1_2 board, and downloaded the documents/sample code and SDK before.
But since my hard drive died, I need to install it on my machine again.
I cannot find this board on Broadcom website anymore.
Does Broadcom stopped supporting the board?
Does anyone know where I can download the docs/sample codes?
Thx.
Show LessHi,
We've been following the recovery steps provided by mwf_mmfae in this thread:
How to recover BCM20736S on custom board?
but we still observe certain failures in our firmware that make us doubt of our understanding of the boot/recovery process. Let me start with the facts:
1. We have a development firmware image that compiles, downloads and runs fine EXCEPT that after loading that image, the device cannot be re-programmed normally. Let's call this the "faulty" firmware.
2. We are able to recover by asserting reset while holding SDA high (VDD). After doing that, we can download the "faulty" firmware again, with the same behaviour described in 1.
3. We can "correct" our firmware image by simply reducing the program size. By #ifdef'ing out a 1 kbyte constant array in the code, we obtain a firmware image that can now be re-programmed normally over and over.
4. The "faulty" firmware is this size:
Patches start at | 0x00204568 (RAM address) |
Patches end at | 0x00205280 (RAM address) |
Application starts at | 0x00204F9C (RAM address) |
Application ends at | 0x00208D1C (RAM address) |
Patch size (including reused RAM) | 3352 bytes |
Patch size | 2612 bytes |
Application size | 15744 bytes |
------ | |
Total RAM footprint | 18356 bytes (17.9kiB) |
5. The "corrected" firmware is this size:
Patches start at | 0x00204568 (RAM address) |
Patches end at | 0x00205280 (RAM address) |
Application starts at | 0x00204F9C (RAM address) |
Application ends at | 0x0020890C (RAM address) |
Patch size (including reused RAM) | 3352 bytes |
Patch size | 2612 bytes |
Application size | 14704 bytes |
------ | |
Total RAM footprint | 17316 bytes (16.9kiB) |
Now some questions...
1. Our theory is that the "normal" download requires some firmware that is stored on EEPROM, let's call that a "download helper". And that our "faulty" firmware overwrites the area where the "download helper" is stored. Is that correct?
2. If 1 is correct, how can we find the exact address where the "download helper" is stored? We would then include a check in the build scripts to raise a warning if a firmware build exceeds that memory address and avoid a painful recovery. Makes sense?
3. What is the purpose of the "download helper"? Could we *always* program the device using the recovery sequence? Are there any problems with that? Seems to be more robust, and it also seems like this would allow us to use more of the EEPROM memory.
Thanks!
Show LessJust wanted to check, if you want to use ota upgrades to program the 20737, can you do that the first time you get the 20737 chip? Or do you have to program the 20737 using the HCI UART the first ever time you get your boards from the factory?
Show LessI currently have a voltage regulator to supply voltage to 20736S from a coin cell operating at 3V. Going over the blebat.c,
blebat_batmon_cfg =
{
/*.adcInputConnectedToBattery =*/ ADC_INPUT_VDDIO, // P15. ADC input to be used for measurement. Note that this may not be a GPIO.
/*.measurementInterval =*/ 60000, // msec. Interval between battery measurements
/*.numberOfMeasurementsToAverage =*/ 8, // Number of measurements averaged for a report, max 16
/*.fullVoltage =*/ 3200, // millivolts. The nominal full battery voltage
/*.emptyVoltage =*/ 1800, // millivolts. The voltage at which the batteries are considered drained
/*.shutdownVoltage =*/ 1700, // millivolts. System should shutdown if it detects battery
// voltage at or below this value. 0 disables shutdown.
/*.maxLevel =*/ 100, // Sets the range of the reported number of steps
// Set it to 100 to report battery in %, 0-100.
/*.reportID =*/ 3, // ID of the battery report
/*.reportLength =*/ 8, // Length of the battery report
/*.reportOnConnect =*/ TRUE, // if TRUE report should be sent when connection is established
}
Shows that the full battery is measured at 3.2V. Can I then power the chip with the regulated voltage and have direct input from the battery at P15(3V input) and the internal ADV will monitor the battery level?
Show Less