Smart Bluetooth Forum Discussions

We are implementing the following scenarios, using the WICED Smart tag(BCM20737)

1. placing the RSA-2048 encryption key to WICED Smart tag.

2. Transfer the encrypted data to WICED Smart tag on smartphone.

3. WICED Smart tag is to decrypt the data using the key.

4. sends the decoded data to smartphone.

implement the following sources have to decrypt the data in the tag.

The following sources are implemented by reference to such methods of PolarSSL rsa_init, rsa_public ....

Run the mpi_read_binary.... had been returned to -16.

These values are defined in bignum.h as follows:

So we add the following logic to APPLICATION_INIT, create method.

and... implemented a myAlloc to debug the allocation process.

Increasing the buffer size has been increased allocation of cfa_mm_ConfigureMemoryPool number.

But still it responded to -16.

This application has been terminated without a return response codes do set the buffer size value to 40.

Is it possible to use the RSA2048 in the tag?

Attach a debug log and source. very simple application only rsa logic

------------------------------------------------------------------------------------------------------

15:38:08 - 020106030304000409bb8104

15:38:08 - 020a81

15:38:08 - Ext_ebt_tnpble_init

15:38:08 - debug mod :

15:38:08 - 9b02c2c12f1a8df42cf3902b8b607632

15:38:08 - 3e09c3ea4d331b79eabb01f41d9d5297

15:38:08 - 7a36da3c7abb839ab7570cab59ae3b71

15:38:08 - 1278f164ef1c2fc5ad727066df793ed7

15:38:08 - afaca88a70e5dfd6db46cad2694b1133

15:38:08 - cd05007c0f1392cb01b6c4400a185468

15:38:08 - 3695bdf6553b95ff0e81459b4d0d4bab

15:38:08 - 94ab71e54de89b0fc673a072d1182062

15:38:08 - fdbc35ffba025dc0456c1bd2da01bce5

15:38:08 - dd1df2fc8ac6ad225b3dd157c5ad4a2f

15:38:08 - 6ab66a348097277c16a9d57ceefea406

15:38:08 - 30ea8ac97559bed72d41abb6e2bd30c8

15:38:08 - a023cb73e9c26606d8f1c9dd03273fd2

15:38:08 - 832ff060010750a8782834b20ff6334c

15:38:08 - d5dad1ebc02c8930723a2e13be06b4fe

15:38:08 - b84c3ee0613dd4fe48d86e7ef4cc3a25

15:38:08 - debug csc :

15:38:08 - 7ee7c9113724756663bf11fab9e0923b

15:38:08 - 8aeb94495fed5eb53abd55afef8952a9

15:38:08 - 91a8c1f5491ba286876180f3440308c0

15:38:08 - 0535a4098641636f5b8ee2b6d5b24de2

15:38:08 - 65a92687f36f4edace21e8528b82c024

15:38:08 - 42afe5cba6d36bb073ed9444e4320279

15:38:08 - c49774c9cd90115886b899afc371d491

15:38:08 - 2283bd977d325c8a39275e0d41eaf25f

15:38:08 - b4ccd8a3253826b7847a65dfe30b7bcd

15:38:08 - 08799e28ad4b50e5ba88b51611caa8a7

15:38:08 - 9d02afa4885e110f66a2c2d0768b83ef

15:38:08 - cfa26f2f8914e946341e78db3b5f4355

15:38:08 - b753baa4c739890ca794e0789bf09d31

15:38:08 - 9a4fa8d94a594f25ba6412fce3a7c695

15:38:08 - bc23b1f5c1156189fe4ec02ed16394dd

15:38:08 - 798fadf82a313bb429815a423b10ba91

15:38:08 - Alloc(256)

15:38:08 - Alloc(256)

15:38:08 - Ext_ebt_tnpble_init ret : 0

15:38:08 - StackOverflow3:0

15:38:08 -

15:38:08 - make_SIGN_MESSAGE

15:38:08 - StackOverflow3:0

15:38:08 -

15:38:08 - Ext_ebt_tnpble_sign start

15:38:08 - mpi_init end

15:38:08 - free memory : 3268

15:38:08 - Alloc(256)

15:38:08 - mpi_read_binary ok

15:38:08 - mpi_exp_mod start

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:08 - Alloc(520)

15:38:08 - Alloc(4)

15:38:08 - Alloc(516)

15:38:08 - Alloc(516)

15:38:08 - Alloc(256)

15:38:08 - Alloc(524)

15:38:08 - Alloc(8)

15:38:08 - Alloc(12)

15:38:08 - Alloc(260)

15:38:08 - Alloc(516)

15:38:08 - Alloc(8)

15:38:08 - Alloc(12)

15:38:08 - Alloc(8)

15:38:08 - Alloc(264)

15:38:08 - Alloc(516)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(8)

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:08 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - Alloc(260)

15:38:09 - unable to alloc!!

15:38:09 - 324, -16

15:38:09 -

15:38:09 - sign_message : -16

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09 - 00000000000000000000000000000000

15:38:09  bd_addr[5:2] = 20 73 7A 10

15:38:09  bd_addr[1:0] = 5A1C 00

15:38:09  GPIO 0001 (11)

15:38:09  GPIO 0000 (104)

15:38:09  GPIO 0014 (1003)

15:38:09  GPIO 0015 (20)

15:38:09  GPIO 0028 (2001)

15:38:09  Interrupt mask[0,1]:0001 0000

15:38:09  Interrupt mask[2]:0000

15:38:09  GPIO_WP:OFF= 00

15:38:09  GPIOBTN1:OFF=1,INT:0

15:38:09  GPIO_LED:OFF=1

15:38:09  GPIOBAT

15:38:09  GPIO_BUZ:OFF=0

15:38:09  BUZBeep(0)

Can set peripheral Broadcasting status to non-connected ?

What is the spec for the 32kHz xtal used with the BCM20737?

Or alternately, please provide the manufacturer & part number of a 32kHz crystal known to work.

thanks,

jc

I know that Bluetooth SIG announce that it will release its Bluetooth Developer Studio, so I want to know that do you have a plan to support this studio's plugin to create WICED SMART source code?

Bluetooth Developer Studio | Development Kit | Bluetooth Technology Website

Hi Everyone,

I need to generate the break sequence (more than 13 continuous zeroes) on the puart. There is not function for that in the API, and maybe I am missing something, but there is no other way to access the puart than through the API. Or is there?

Now - I have tried to simulate a break by lowering the puart speed to 70% and sending 0 (with the puart_synchronousWrite), and then changing the speed back. But this does not really work - the zero and the next sent byte are somehow merged together.

Is there a way to either force the puart to generate a break, or to wait for the character to be sent before changing puart parameters? Interrupt is the only thing I can think of, but is there anything else?

BR,

M.W.

PS. I'm using the BCM920737TAG-03.

Hello there,

I'm working on a consumer hardware that will use the BCM20736S SiP for Bluetooth LE/Smart connectivity. Estimated annually sold units are 150k for this project and 1.2m for the next one, that's more budgetary.

The hardware consists of a fast main MCU that does the number crunching and controls the remaining hardware and is interfaced via P_UART and HCI_UART to the SiP.

For manufacturing we'll have to use pogo pins on the HCI_UART and the supplied chipload utility. We'd prefer to program it with the main MCU as this would ease the process.

The end customer will have the ability to update both the firmware via Bluetooth LE. For this purpose we'd like to first update the MCU's firmware and after successfully doing so let the MCU update the BLE module. We are pretty space constrained, so implementing OTA and UART update into our software on the BLE module isn't an option.

For this purpose we need the UART protocol the BLE module's bootloader is using. Sadly it's not documented nor are the sources of chipload and HEX loader file available.

If we have to sign an NDA we'll do it, as it will speed up development tremendously.

Please provide us with the source files or a person at Broadcom to contact.

Thank you in advance!

Best regards

Hannes Baumgart

Hi all,

Per the discussion here on preserving the BD_ADDR on each subsequent programming of the part: How to program BCM20736 without changing MAC Address

I'm sorry to jump in late into this discussion. I'm using Mac OS X, and the BCM920737TAG board. I mainly use the command line:

./make <app>-BCM920737TAG_Q32 download

to download code to the board, and don't use the IDE. Following this thread, I added a new target to the Makefile for download, and included the -NOERASE flag to it:

download_using_chipload_no_erase:

  $(QUIET)$(ECHO_BLANK_LINE)

  $(QUIET)$(eval UART:=$(shell $(CAT) < com_port.txt))

  $(QUIET)$(if $(UART), \

          $(ECHO) Downloading application leaving EEPROM intact... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -NOERASE -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \

          && $(ECHO) Download complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) \

          || $(ECHO) $(QUOTES_FOR_ECHO)****Download failed - Press the reset button on the device and retry ****$(QUOTES_FOR_ECHO), \

          $(ECHO) Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices)

Note that the other change suggested by arvinds  (adding -O DLConfigFixedHeader:0 to create_ota_image) is already in the Makefile.

However, when I change the line

in the 20737_EEPROM.btp file, it does indeed erase the old value and replace it with the new value. So, it doesn't work as suggested in this thread. Any help is greatly appreciated. I would like to find a way to download code to different boards without having to change the .btp file each time.

Thanks,

Arvind

Hi,

I'm writing an Android app to test and study the speed_test example in WICED SMART SDK, but encounter this problem:

Writing descriptor of SPEED_TEST_CHARACTERISTIC_DATA receives a success status on Android, but speed_test_write_handler is not called in the firmware. The "data descriptor" value changed trace is also not called.

Same writing method works for SPEED_TEST_CHARACTERISTIC_CONTROL_POINT. (speed_test_write_handler is called and shows "control descriptor" value changed)

And, the peerapp (Windows app) in the SDK project is able to write descriptor for both data and control characteristics.

Is it because descriptor writing method for data characteristic is different from control? Appreciate for helping!

Best regards,

Sam

[Edit]

Did some more tests and it seems which descriptor can be written is related to the handle. Following is my test:

1. No change in code:

Result:

Write Control descriptor shows success on phone. Write_handler callback is called by Control descriptor handle.

Write Data descriptor shows success on phone. Write_handler callback is not called.

2. Swap Data characteristic handles with Control characteristics handles:

#define HANDLE_SPEED_TEST_CHARACTERISTIC_DATA                       0x2d

#define HANDLE_SPEED_TEST_CHARACTERISTIC_DATA_VALUE                 0x2e

#define HANDLE_SPEED_TEST_DATA_CLIENT_CONFIGURATION_DESCRIPTOR      0x2f

#define HANDLE_SPEED_TEST_CHARACTERISTIC_CONTROL                    0x2a

#define HANDLE_SPEED_TEST_CHARACTERISTIC_CONTROL_VALUE              0x2b

#define HANDLE_SPEED_TEST_CONTROL_CLIENT_CONFIGURATION_DESCRIPTOR   0x2c

Result:

Write Control descriptor shows success on phone, but write_handler callback is not called.

Write Data descriptor shows success on phone. Write_handler callback is called by Data descriptor handle.

3. Swap Data characteristic handles with Control characteristics handles, and swap position for Data and Control in speed_test_gatt_database[] (both positions of characteristic and descriptor are changed)

Result:

Write Control descriptor shows success on phone, but write_handler callback is not called.

Write Data descriptor shows success on phone. Write_handler callback is called by Data descriptor handle.

I have also tried several other handle numbers, but seems only 0x2f works.

[Edit 2]

I used wiced smart designer created a new project and created a characteristic with Device Role as Sensor sends value to host, and allow permission Notification in Client Configuration. Then, it works.

Guessing unable to write descriptor might because in speed_test, the characteristic is "writable". And, in .wic file, if set Device Role as Host writes to or read from sensor, Client Configuration tab will disappear.

Is it possible to use trace level on tag BCM 20737 for the firmware debug?
I find in dbfw_app.h, there is trace level for different model to apply.
To categorize system trace as different function or level but from header file,

it says it's workable on BCM2045 so dont know it can be workable on 20737 or not.

If yes, what else compiler option to be switched on?