Skip navigation
Home > All Places > Software Forums > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > Authors SeyhanA_31
1 2 Previous Next

WICED Studio Wi-Fi/Combo Forums

29 Posts authored by: SeyhanA_31

OTA2 Update for SDK-3.7.0

Posted by SeyhanA_31 Aug 23, 2016

Attached is the OTA2 update files for SDK-3.7.0.


The BCM943907AEVAL1F_1 evaluation board is used for updating firmware over the air firmware update.

The sample firmware is build for BCM943907AEVAL1F_1 using ota2_example and scan snip applications for future firmware to updates.


Extract the content of the attached compressed file OTA2Update_WicedSDK-3.7.0.tgz into Wiced SDK-3.7.0 release.

Content of OTA2Update_WicedSDK-3.7.0.tgz:



































Build the snip.ota2_extract snip application first. The ota_extract elf file is needed by the snip.ota2_example and snip.scan will be build later. The ota2_extact elf file could be found in .../build/snip.ota2_extract-BCM943907AEVAL1F_1.B1/binary/snip.ota2_extract-BCM943907AEVAL1F_1.B1.stripped.elf OTA  location.


Use the following make target command to build the ota2_extract:





Build snip.scan snip application that simulates the new firmware that will updated using OTA. Building snip.scan will cause the firmware to be downloaded to the target device.


Use the following make target to build the snip.scan:

     snip.scan-BCM943907AEVAL1F_1.B1 ota2_image



Build the snip.ota2_example snip application using the attached snip.ota2_example files.


This snip application demonstrates a firmware upgrade using OTA by following means:

- Command like interface to initiate new firmware update using over the air

- The target device could be brought up as an Soft-AP and new firmware update could be initiated using html page served by the target device.


Use the following make target to build the snip.ota2_example:

     snip.ota2_example-BCM943907AEVAL1F_1.B1 download download_apps ota2_image run



As a result of building snip.ota2_example and snip.scan application binary files will be generated for each build. These binary files will be used to update the firmware on the device using OTA. Initial release of firmware snip.ota2_example will be updated by snip.scan then back to snip.ota2_example.


The /build/snip.ota2_example-BCM943907AEVAL1F_1.B1/OTA2_image_file.bin is named as OTA2ExampleFW.bin

The /build/snip.scan-BCM943907AEVAL1F_1.B1/OTA2_image_file.bin binary file is renamed as FW2BeUpdatedUsingOTA.bin

The both binary files are attached as reference only.


Both binary files are copied into the web server default file server location. In this case, mongoose (is used to serve the firmware binary files to be pulled and pushed by the target device.


The default port used by the ota2_example is port 80. Either the web server port could be changed to match the ota2_example port number or web server port number could be passed to the ota2_example.



After building and loading the loading the snip.ota2_example to the target, by default the target device boots and tries to connect to the AP defined in /apps/snip/ota2_example/wifi_config_dct.h.


#define CLIENT_AP_SSID       "BroadcomSA_24"
#define CLIENT_AP_PASSPHRASE "123456789SA"


Connect the device that running the web server to the same network as the target device (BCM943907AEVAL1F_1) is connected. In this case the windows laptop is also connected to  BroadcomSA_24 and has the IP address of


Using the snip.ota2_example application, the command line interface is used to initiate a new firmware update using OTA.


Issue the following command to start OTA of the snip.scan application as new firmware to update.

     get_update <web-server>/<New Firmware To OTA>


In this case, below command is used to initiate a new firmware to be pulled down to the target device:



> get_update


ota2_test_get_update() player->ota2_bg_service 0x0

ota2_test_get_update() wiced_ota2_service_init() bg_service:0x505c80

Download the OTA Image file - get it NOW!

wiced_ota2_service_network_switch_to_ota2_ap() network to switch to.

----------------------------- OTA2 Service Called : AP_CONNECTED -----------------------------

        return SUCESS (not used by service). This is informational

Try 0 Connecting to  ( !

----------------------------- OTA2 Service Called : SERVER_CONNECTED -----------------------------

        return SUCESS (not used by service). This is informational

----------------------------- OTA2 Service Called : UPDATE_AVAILABLE -----------------------------

        return SUCCESS, let Service perform the download.

Try 0 Connecting to  ( !

----------------------------- OTA2 Service Called : SERVER_CONNECTED -----------------------------

        return SUCESS (not used by service). This is informational

----------------------------- OTA2 Service Called : PERFORM_UPDATE -----------------------------

        return SUCCESS, let Service extract update on next reboot.




After download, reboot the target by "update_reboot" to extract the new firmware.

After extract, reboot the target again to start new firmware running.


Note: A full terminal output is attached as well.



Now the updated firmware of snip.scan is running on the target.

If the button 1 (push button connected between BCM943907AEVAL1F_1 J6-2 and gnd) on target is pressed and hold at reset of the target and released after 5 seconds of reset, the target device boots as Soft-AP with SSID and passphrase defined in the /apps/snip/scan/wifi_config_dct.h


#define SOFT_AP_SSID         "Scan WICED Soft AP"
#define SOFT_AP_PASSPHRASE   "abcd1234"


Connect the client device to the "Scan WICED Soft AP" where the OTA2ExampleFW.bin binary is located.


Using a web browser on the client device open the default web page of the target device.

The target device IP address is printed on the terminal:

Hi, I'm the OTA2 extraction app (ota2_extract).

IPv4 network ready IP:

Setting IPv6 link-local address

IPv6 network ready IP: FE80:0000:0000:0000:9AF1:70FF:FE6F:7D92

Using "Choose File" select the next firmware to update. In this case the snip.ota2_example firmware will be loaded back on the target by pushing new firmware to target via OTA.


Same above step could be done using snip.ota2_example snip application running on the target. In this case the target device will boot up as Soft-AP where the SSID and passphrase defined in the /apps/snip/ota2_example/wifi_config_dct.h


#define SOFT_AP_SSID         "Ota2Ex WICED Soft AP"
#define SOFT_AP_PASSPHRASE   "abcd1234"



7. DCT Structure Update for OTA


After the device firmware is updated using OTA2, the DCT data is updated from previous version to new version. For OTA2 example the version of the Wiced SDK is used for reference. Final device could use different version number then the Wiced SDK and incorporate SDK to final product changes into one. Existing DCT data structures are copied to new DCT structures and new locations. Any updates on the DCT by new version are implemented by the following files in the Wiced SDK:







  The DCT structure is defined in the .../WICED/platform/include/platform_dct.h used by the OTA application to update the DCT data.


/* The structure for the complete system DCT layout.
 * The application DCT data follows this structure in the DCT section of FLASH.
typedef struct
    platform_dct_header_t               dct_header;
    platform_dct_mfg_info_t             mfg_info;
    platform_dct_security_t             security_credentials;
    platform_dct_wifi_config_t          wifi_config;
    platform_dct_ethernet_config_t      ethernet_config;
    platform_dct_network_config_t       network_config;
    platform_dct_bt_config_t            bt_config;
    platform_dct_p2p_config_t           p2p_config;
    platform_dct_ota2_config_t          ota2_config;
    platform_dct_version_t              dct_version;
} platform_dct_data_t;



The DCT offsets are defined in the wiced_dct_external_common.c to copy the DCT data corresponding locations.


static const uint32_t DCT_section_offsets[ ] =
    [DCT_APP_SECTION]           = sizeof(platform_dct_data_t),
    [DCT_SECURITY_SECTION]      = OFFSETOF( platform_dct_data_t, security_credentials ),
    [DCT_MFG_INFO_SECTION]      = OFFSETOF( platform_dct_data_t, mfg_info ),
    [DCT_WIFI_CONFIG_SECTION]   = OFFSETOF( platform_dct_data_t, wifi_config ),
    [DCT_BT_CONFIG_SECTION] = OFFSETOF( platform_dct_data_t, bt_config ),
    [DCT_INTERNAL_SECTION]      = 0,


The new DCT structures are updated with the existing data from the device by wiced_result_t wiced_dct_external_dct_update(…) in ../platform/MCU/wiced_dct_external_common.c


 * dct_source       - Start address of the DCT to read from to update to current SDK's DCT layout
 * dct_destination  - Start address of the DCT to write current SDK's DCT layout
static wiced_result_t wiced_dct_external_dct_update(uint32_t dct_destination, uint32_t dct_source)


For example the WiFi configuration (platform_dct_wifi_config_t ) is updated by the wiced_dct_update_wifi_config_to_current(…) call in ../platform/MCU/wiced_dct_external_common.c


/* wifi config */
memset( dst_dct_buffer, 0x00, LARGEST_DCT_SUB_STRUCTURE_SIZE);
if (sflash_read( &sflash_handle, (dct_source + OFFSETOF(bootloader_dct_data_t, wifi_config)), src_dct_buffer, sizeof(platform_dct_wifi_config_t)) == WICED_SUCCESS)
    if (wiced_dct_update_wifi_config_to_current((platform_dct_wifi_config_t*)dst_dct_buffer, (platform_dct_wifi_config_t*)src_dct_buffer) == WICED_SUCCESS)
        if ( sflash_write( &sflash_handle, dct_destination + OFFSETOF(platform_dct_data_t, wifi_config), dst_dct_buffer, sizeof(platform_dct_wifi_config_t) ) != PLATFORM_SUCCESS)
            goto _update_fail;


Any specific changes made in the WiFi configuration could be included in the wiced_dct_update_wifi_config_to_current(…). Currently the current data is copied to the new DCT structure and any specific changes could be incorporated into here.


wiced_result_t wiced_dct_update_wifi_config_to_current (platform_dct_wifi_config_t* wifi_config_destination,
                                                        platform_dct_wifi_config_t* wifi_config_source)



Currently OTA2 is tested on the BCM43907 and BCM43909 based platforms.

Support for other platforms will be available soon.

It is possible to have a platform specific firmware files released by Broadcom to support specific partner modules or added features.


In order to accommodate specific firmware files for WLAN and BT/BLE, the common firmware files could be replaced in ./resources/firmware/<WLAN_CHIP>/ for WLAN and ./libraries/drivers/bluetooth/firmware/<BT_CHIP><BT_CHIP_REVISION>/ for BT/BLE. Replacing these firmware files will effect all other platforms because they share the same firmware files.




Instead of replacing the WLAN firmware file in common ./resources/firmware/<WLAN_CHIP>/ directory, the platform specific WLAN firmware could be placed in the platform directory. Such as, ./platforms/<platform>/firmware/ directory could be created and the platform specific WLAN firmware could be placed in there.


In order for makefiles to pick up the correct firmware, below lines need to be added in the platform makefile, ./platforms/<platform>/<platform>.mk:


$(NAME)_RESOURCES += ../platforms/$(PLATFORM)/firmware/PlatformSpecificFW.bin





Append the BT_CHIP_REVISION located in the ./platforms/<platform>/<platform>.mk makefile with your specific platform name.



BT_CHIP_REVISION      := B0_PlatformSpecificHCD


Create a directory in the ./libraries/drivers/bluetooth/firmware and name it as <BT_CHIP><BT_CHIP_REVISION> defined in the platform makefile.

Place the platform specific BT/BLE firmware file in this directory.


For example:

If the BCM943341WCD1 platform has a specific firmware, the following modifications could be made in the platform makefile.


BT_CHIP           := 43341
BT_CHIP_REVISION  := B0_PlatformSpecificHCD


The ./libraries/drivers/bluetooth/firmware/43341B0_PlatformSpecificHCD specific directory is created based on above changes. The platform specific BT/BLE firmware file bt_firmware_image.c file is placed in this new directory.


If needed, a platform specific firmware for 40MHz operations could be placed in the ./libraries/drivers/bluetooth/firmware/43341B0_PlatformSpecificHCD/40MHz directory as well.


Simple Usage Of Timers

Posted by SeyhanA_31 May 18, 2016

Here is a simple usage of timers with Wiced SDK.


Two timers are initialized with timeouts and callbacks. Both timers are set to count on each callback.

One of the timer is stopped when it expires and the other timer keeps counting. Second timer is kicked within the while loop after longer delay.

The both count values are printed within the while loop.


Attached is the simple snip application of timers.



 * Copyright 2016, Broadcom Corporation
 * All Rights Reserved.
 * This is UNPUBLISHED PROPRIETARY SOURCE CODE of Broadcom Corporation;
 * the contents of this file may not be disclosed to third parties, copied
 * or duplicated in any form, in whole or in part, without the prior
 * written permission of Broadcom Corporation.

/** @file
 * Timers Application
 * Features demonstrated
 *  - WICED Timer API
 * This application snippet demonstrates the timer usage.
 * Application Instructions
 *   Connect a PC terminal to the serial port of the WICED Eval board,
 *   then build and download the application as described in the WICED
 *   Quick Start Guide

#include <stdlib.h>
#include "wiced.h"

 *                      Macros

 *                    Constants

 *                   Enumerations
#define DELAY_TIMEOUT1          (500)
#define DELAY_TIMEOUT2          (500)
#define LOOP_DELAY              (1000)

 *                 Type Definitions
wiced_timer_t test_timer1;
wiced_timer_t test_timer2;

 *                    Structures

 *               Static Function Declarations
static void timer_cb1( void );
static void timer_cb2( void );

 *               Variable Definitions
int cb_count1 = 0;
int cb_count2 = 0;

 *               Function Definitions

void application_start( )
    wiced_init( );

    wiced_rtos_init_timer( &test_timer1, DELAY_TIMEOUT1, (timer_handler_t) timer_cb1, NULL );
    wiced_rtos_init_timer( &test_timer2, DELAY_TIMEOUT2, (timer_handler_t) timer_cb2, NULL );
    wiced_rtos_start_timer( &test_timer1 );

        WPRINT_APP_INFO( ( "Print from while loop: cb_count1:%d; cb_count2:%d ...\n", cb_count1, cb_count2 ) );
        wiced_rtos_start_timer( &test_timer2 );


static void timer_cb1(void)
    wiced_rtos_start_timer( &test_timer1 );

static void timer_cb2(void)

# Copyright 2016, Broadcom Corporation
# All Rights Reserved.
# This is UNPUBLISHED PROPRIETARY SOURCE CODE of Broadcom Corporation;
# the contents of this file may not be disclosed to third parties, copied
# or duplicated in any form, in whole or in part, without the prior
# written permission of Broadcom Corporation.

NAME := App_Timers

$(NAME)_SOURCES := timers.c

Here is how to enable UART4 on WICED SDK to receive set number of data within given timeout after requesting it from the simulated device.

Device is simulated using Tera Term macro script, uart_data_exchange.ttl.


Below is the sequence of data exchange:

- Data is requested on the UART4 interface by sending 0x0A ('\n') to the Tera Term terminal.

- A macro running on the Tera Term waits for the requesting data then sends a response to the Wiced device.

- The Wiced device receives the data on the UART4 interface with a given timeout.

- Data received on the UART4 is relayed to the STDIO_UART (USART6) for logging.

- The continuous receive and transmission of data could be interrupted on the Wiced debug interface STDIO_UART (USART6) by typing 'x'. If not the sequence repeats with a timeout of 4 seconds.


Both UART4 Rx and Tx pins are routed to the "Breakout Header" on the evaluation platforms.


To connect the UART4 on the BCM943341WCD1 use the following connections:

     UART4-Tx -> J7-20

     UART4-Rx -> J7-8


To connect the UART4 on the BCM943362WCD4 use the following connections:

     UART4-Tx -> J7-9

     UART4-Rx -> J7-6


For more information on Uart connections please check Enable UART4 on BCM943362WCD4 and BCM943341WCD1 as Terminal Output blog post.


Hardware setup:


- Connect UART4 on the Wiced device to PC and open a Tera Term for the connection.

- Connect a PC terminal to the serial port of the WICED Evaluation board and open a second Tera Term terminal for the debug interface.

- Copy attached uart_data_exchange snippet application to .../apps/snip directory of the Wiced SDK or apply the attached patch file.


- Start the uart_data_exchange.ttl macro on the Tera Term connected to the Wiced UART4.


Build, download and run the uart_data_exchange snippet application:


     snip.uart_data_exchange-BCM943341WCD1 download run


     snip.uart_data_exchange-BCM943362WCD4 download run


Here is outputs on the Tera Term terminals for both UART4 and STDIO_UART:

This snippet application interfaces the FXOS8700 accelerometer and magnetometer sensors to Wiced SDK using I2C interface.


Features demonstrated

     - I2C device setup and connection using WICED

     - I2C device data send and receive using WICED

     - Interface to I2C sensor device

Snipped application:

     - Sets up the I2C interface to the device and communicates to read and write sensor registers.

     - Sets up the interrupts using WICED GPIO interrupt handling function.

     - Calibrates the accelerometer and magnetometer sensors in the FXOS8700.

     - On each interrupt from the FXOS8700, the sensor data is read and printed on the serial terminal.


Connection setup for I2C device to STM32F4xx based WICED evaluation board


FRDM-STBC-AGM01      BCM943341WCD1 J7 Header

   J3-1 +                                       J7-28

   J4-5 -                                        J7-27

   J3-5 SDA                                  J7-26

   J3-4 SCL                                  J7-25

   J4-1 INT1_8700                       J7-8

   J4-8 INT1_21002                     J7-7


NOTE: On BCM943341WCD1, SDA and SCL signals already have a 4.7K pull up resistors.


Connect a PC terminal to the serial port of the WICED Eval board, then build and download the application as described in the WICED Quick Start Guide.

Either apply the attached patch or copy the attached files to ../apps/snip directory.

Application could be built using following Make Target command for BCM943341WCD1 platform:

     snip.i2c_fxo-BCM943341WCD1 download run

     snip.i2c_fxo-BCM943341WCD1-debug download run


Here is the BCM943341WCD1 EVB with FRDM-STBC-AGM01 EVB:


Here is the serial terminal output:



This snippet application interfaces the Infrared contact-less temperature sensor (TMP007) module from Adafruit ( using WICED SDK.


- The snippet application sets up the I2C device interface and probes the device.

- Then all register values are read and pushed to the serial terminal interface.

- To show writing to the I2C device, object high temperature alarm register is updated with a given value then the same register is register back.

- Every 1 second period, I2C device die and object temperature values are read from corresponding registers and printed on the serial terminal.


For BCM943362WCD4 evaluation platform update the platform.c and platform.h files for I2C device.


Update the .../platforms/BCM943362WCD4/platform.c file by adding the following changes to the file:


const platform_i2c_t platform_i2c_peripherals[] =
    [WICED_I2C_1] =
        .port                    = I2C1,
        .pin_scl                 = &platform_gpio_pins[WICED_GPIO_11],
        .pin_sda                 = &platform_gpio_pins[WICED_GPIO_12],
        .peripheral_clock_reg    = RCC_APB1Periph_I2C1,
        .tx_dma                  = DMA1,
        .tx_dma_peripheral_clock = RCC_AHB1Periph_DMA1,
        .tx_dma_stream           = DMA1_Stream7,
        .rx_dma_stream           = DMA1_Stream0,
        .tx_dma_stream_id        = 7,
        .rx_dma_stream_id        = 0,
        .tx_dma_channel          = DMA_Channel_1,
        .rx_dma_channel          = DMA_Channel_1,
        .gpio_af                 = GPIO_AF_I2C1


For platforms/BCM943362WCD4/platform.h file add the WICED_I2C_1 to the wiced_i2c_t as below:


typedef enum
} wiced_i2c_t;


The platform files for BCM943362WCD4 are attached.


NOTE: On BCM943362WCD4 evaluation board, two 4.7K pull up resistors are needs on each of the SCL and SDA connections.


For BCM943341WCD1, the I2C device of WICED_I2C_1 is already defined in the platform files. Since the SCL and SDA pull resistors are already populated on the BCM943341WCD1 evaluation board, no hardware related modifications are needed.


Your application specific platform files can be updated as above to interface the chosen I2C device to the WICED SDK 3.x platforms.


1. To run the test, connect the I2C device to the evaluation board as following:


Connection setup for I2C device to STM32F4xx based WICED evaluation board

I2C-Device   BCM943341WCD1 J7 Header

      -                    J7-27

     +                    J7-28

     SDA               J7-26

     SCL               J7-25


Connection setup for I2C device to STM32F2xx based WICED evaluation board

I2C-Device   BCM943362WCD4 J7 Header

     -                         J7-2

     +                        J7-1

     SDA                   J7-7

     SCL                   J7-6


2. Unzip and copy the attached files to the WICED SDK-3.x version.

For I2C Temp application snippet:

     Copy the content of the i2c_temp.7z source to .../apps/snip/i2c_temp


For BCM943362WCD4:

     Copy the content of the BCM943362WCD4.7z source to .../platforms/BCM943362WCD4


For BCM943341WCD1:

     Default platform files could be used.


3. To build, download and run the application below

For STM32F4xx MCU BCM943341WCD1:

     snip.i2c_temp-BCM943341WCD1 download run


For STM32F2xx MCU BCM943362WCD4:

     snip.i2c_temp-BCM943362WCD4 download run


Picture of setup:



Serial terminal log:

13:15:39.028: Starting WICED v3.3.DEVELOPMENT
13:15:39.028: Platform BCM943341WCD1 initialised
13:15:39.028: Started ThreadX v5.6
13:15:39.028: Initialising NetX_Duo v5.7_sp2
13:15:39.028: Creating Packet pools
13:15:39.028: WWD SDIO interface initialised
13:15:39.348: WLAN MAC Address : 6C:AD:F8:F0:E8:F1
13:15:39.364: WLAN Firmware    : wl0: Nov 25 2015 14:01:39 version 6.49.2 (r602357) FWID 01-1302682f
13:15:39.364: I2C LED Interface Application.
13:15:39.396: Probe successful on address 64!
13:15:39.396: Manufacturer ID: 0x5449
13:15:39.396: Device ID: 0x0078
13:15:39.396: Voltage: -27.6562 uV
13:15:39.396: Die Temp: 25.22C
13:15:39.396: Object Temp: 25.12C
13:15:39.412: Alarms(L/H): Die -256.00C / 255.50C, Object -256.00C / 198.50C
13:15:39.412: Write: 6340 Read: 6340
13:15:39.412: Write: 198.50C Read: 198.50C
13:15:39.412: Die Temp: 25.22C (78.39F) - Object Temp: 25.12C (77.22F)
13:15:39.428: Die Temp: 25.19C (78.34F) - Object Temp: 25.19C (77.34F)
13:15:40.420: Die Temp: 25.19C (78.34F) - Object Temp: 25.34C (77.62F)
13:15:41.428: Die Temp: 25.19C (78.34F) - Object Temp: 26.38C (79.47F)
13:15:42.436: Die Temp: 25.19C (78.34F) - Object Temp: 28.12C (82.62F)
13:15:43.444: Die Temp: 25.19C (78.34F) - Object Temp: 30.03C (86.06F)
13:15:44.451: Die Temp: 25.22C (78.39F) - Object Temp: 32.50C (90.50F)
13:15:45.459: Die Temp: 25.22C (78.39F) - Object Temp: 34.25C (93.65F)
13:15:46.451: Die Temp: 25.22C (78.39F) - Object Temp: 33.12C (91.62F)
13:15:47.460: Die Temp: 25.22C (78.39F) - Object Temp: 32.47C (90.44F)
13:15:48.468: Die Temp: 25.22C (78.39F) - Object Temp: 33.06C (91.51F)
13:15:49.476: Die Temp: 25.22C (78.39F) - Object Temp: 33.91C (93.03F)
13:15:50.484: Die Temp: 25.22C (78.39F) - Object Temp: 34.59C (94.27F)
13:15:51.476: Die Temp: 25.22C (78.39F) - Object Temp: 34.97C (94.94F)
13:15:52.484: Die Temp: 25.25C (78.45F) - Object Temp: 35.38C (95.68F)
13:15:53.492: Die Temp: 25.25C (78.45F) - Object Temp: 35.06C (95.11F)
13:15:54.500: Die Temp: 25.25C (78.45F) - Object Temp: 33.53C (92.36F)
13:15:55.507: Die Temp: 25.22C (78.39F) - Object Temp: 32.19C (89.94F)
13:15:56.515: Die Temp: 25.22C (78.39F) - Object Temp: 30.94C (87.69F)
13:15:57.508: Die Temp: 25.22C (78.39F) - Object Temp: 31.34C (88.42F)
13:15:58.516: Die Temp: 25.28C (78.51F) - Object Temp: 34.59C (94.27F)
13:15:59.524: Die Temp: 25.34C (78.62F) - Object Temp: 38.72C (101.69F)
13:16:00.532: Die Temp: 25.38C (78.68F) - Object Temp: 41.81C (107.26F)
13:16:01.540: Die Temp: 25.44C (78.79F) - Object Temp: 44.59C (112.27F)
13:16:02.532: Die Temp: 25.50C (78.90F) - Object Temp: 47.03C (116.66F)
13:16:03.540: Die Temp: 25.53C (78.96F) - Object Temp: 48.81C (119.86F)
13:16:04.548: Die Temp: 25.59C (79.07F) - Object Temp: 49.91C (121.83F)
13:16:05.556: Die Temp: 25.62C (79.12F) - Object Temp: 50.91C (123.63F)
13:16:06.563: Die Temp: 25.66C (79.18F) - Object Temp: 51.44C (124.59F)
13:16:07.557: Die Temp: 25.72C (79.29F) - Object Temp: 52.41C (126.33F)
13:16:08.564: Die Temp: 25.75C (79.35F) - Object Temp: 52.94C (127.29F)
13:16:09.572: Die Temp: 25.81C (79.46F) - Object Temp: 54.03C (129.26F)
13:16:10.580: Die Temp: 25.88C (79.58F) - Object Temp: 54.62C (130.32F)
13:16:11.588: Die Temp: 25.91C (79.63F) - Object Temp: 55.19C (131.34F)
13:16:12.596: Die Temp: 25.94C (79.69F) - Object Temp: 55.84C (132.52F)
13:16:13.588: Die Temp: 26.00C (79.80F) - Object Temp: 56.59C (133.87F)
13:16:14.596: Die Temp: 26.06C (79.91F) - Object Temp: 57.34C (135.22F)
13:16:15.604: Die Temp: 26.09C (79.97F) - Object Temp: 58.06C (136.51F)
13:16:16.612: Die Temp: 26.16C (80.08F) - Object Temp: 58.78C (137.81F)
13:16:17.621: Die Temp: 26.22C (80.19F) - Object Temp: 59.47C (139.04F)
13:16:18.613: Die Temp: 26.28C (80.31F) - Object Temp: 60.03C (140.06F)
13:16:19.620: Die Temp: 26.34C (80.42F) - Object Temp: 60.38C (140.68F)
13:16:20.628: Die Temp: 26.41C (80.53F) - Object Temp: 60.84C (141.52F)
13:16:21.636: Die Temp: 26.50C (80.70F) - Object Temp: 60.62C (141.12F)
13:16:22.644: Die Temp: 26.59C (80.87F) - Object Temp: 60.34C (140.62F)
13:16:23.653: Die Temp: 26.69C (81.04F) - Object Temp: 60.22C (140.39F)
13:16:24.644: Die Temp: 26.75C (81.15F) - Object Temp: 60.56C (141.01F)
13:16:25.652: Die Temp: 26.81C (81.26F) - Object Temp: 58.62C (137.53F)
13:16:26.660: Die Temp: 26.78C (81.21F) - Object Temp: 53.47C (128.24F)
13:16:27.669: Die Temp: 26.78C (81.21F) - Object Temp: 48.19C (118.74F)
13:16:28.677: Die Temp: 26.81C (81.26F) - Object Temp: 44.44C (111.99F)
13:16:29.669: Die Temp: 26.81C (81.26F) - Object Temp: 41.47C (106.64F)
13:16:30.677: Die Temp: 26.81C (81.26F) - Object Temp: 39.09C (102.37F)
13:16:31.684: Die Temp: 26.84C (81.32F) - Object Temp: 37.34C (99.22F)
13:16:32.692: Die Temp: 26.84C (81.32F) - Object Temp: 36.00C (96.80F)
13:16:33.700: Die Temp: 26.84C (81.32F) - Object Temp: 34.84C (94.72F)
13:16:34.692: Die Temp: 26.84C (81.32F) - Object Temp: 34.00C (93.20F)
13:16:35.700: Die Temp: 26.84C (81.32F) - Object Temp: 33.25C (91.85F)
13:16:36.708: Die Temp: 26.84C (81.32F) - Object Temp: 32.84C (91.12F)
13:16:37.717: Die Temp: 26.84C (81.32F) - Object Temp: 32.59C (90.67F)

The WiFi module power and reset pins are controlled by the host MCU.




For BCM943362WCD4 evaluation board, the power and reset pins are controlled by the following definitions in .../platforms/BCM943362WCD4/platform.c


[WWD_PIN_POWER] = { GPIOB,  2 },
[WWD_PIN_RESET] = { GPIOB,  5 },


The "WWD_PIN_POWER" definition in WICED SDK controls the host MCU (STM32F205) PB2 pin. The host MCU PB2 pin controls the VBAT (power) on the WiFi module. Wifi module power completely turned of by the hos MCU to save energy if the WiFi module is not in use at all.


The "WWD_PIN_RESET" definition in Wiced SDK controls the host MCU PB5 pin. The host MCU PB5 pin controls the WLAN_RESET_L (reset) on the WiFi module.
Setting this pin logic level to low causes WiFi module reset.





For BCM943341WCD1 the reset pin is controlled by the following definition in .../platforms/BCM943341WCD1/platform.c

Although it is named as WWD_PIN_POWER but actually controls the reset pin of the BCM943341 SiP module. Reason is being the logic level to reset the BCM943341 SiP module is inverted compared to the other SiP modules.


[WWD_PIN_POWER] = { GPIOB,  2 },


The "WWD_PIN_POWER" definition in WICED SDK controls the host MCU (STM32F417IGH6) PB2 pin. This pin from the host MCU controls the WL_REG_ON (reset) on the WiFi module.  Setting this pin logic level to high causes WiFi module reset.



Unlike on BCM943362WCD4 evaluation board, on BCM943341WCD1 evaluation board the WiFi module power (VBAT) is not controlled by the host MCU. The WiFi module VBAT pin directly connected to the 3.3V via bypass capacitors.


If needed, the similar power switching circuit from BCM943362WCD4 evaluation board could be used on BCM943341 module based designs as well.



The attached files update the UART peripheral of STM32F4xx and STM32F2xx host MCUs to return number of bytes within a given duration.


The below function definition is used for returning the received bytes and number of bytes over the UART within the given time duration. When the patch is applied correctly, the following code should be updated in /include/wiced_platform.h.


/** Receive data on a UART interface
* @param  uart     : the UART interface
* @param  data     : pointer to the buffer which will store incoming data
* @param  size     : number of bytes to receive
* @param  rcvd_size: number of bytes received
* @param  timeout  : timeout in milisecond
* @return    WICED_SUCCESS : on success.
* @return    WICED_ERROR   : if an error occurred with any step
wiced_result_t wiced_uart_return_received( wiced_uart_t uart, void* data, uint32_t size, uint32_t* rcvd_size, uint32_t timeout );


The attached patch file updates the following files:







The updated UART snip application (.../apps/snip/uart) is attached to test the updates.


The attached updates are for WICED SDK-3.1.2 and WICED SDK-3.5.2 release but they can be merged to other releases as well.

Replace the …/apps/demo/appliance/appliance.c and …/resources/apps/appliance/top_web_page_top.html with attached copies.


Then build and download the updated appliance application to your target EVB, example is BCM943362WCD4 EVB “demo.appliance-BCM943362WCD4 download run“.


Follow the same steps described in the appliance demo, Demo of the "Appliance Application" in WICED SDK, to associate EVB to your network and go to the website served by the EVB.


Use the buttons to toggle Red and Green LEDs on the BCM943362WCD4 EVB, as shown below screen shot.



Wi-Fi Direct is a technology that allows devices to connect to each other directly without having to join a traditional home / hotspot network. You can search for available devices and request for a connection, or receive an invitation to connect to another device. When two or more Wi-Fi Direct devices connect to each other, they form a Wi-Fi Direct group with one of the devices as the group owner.


Wi-Fi Direct also supports legacy devices that do not have P2P features. Once the P2P group is established, legacy clients can communicate with the group owner with WPA2 security. They would not be able to use the P2P functions but would be able to connect with the group owner as a traditional AP, seen as the SSID "DIRECT-test" in SDK 3.1.2.

Our WICED console application includes a number of Wi-Fi Direct(also referred to as P2P) commands(Type in "help" for the list of commands and usage). WICED supports all mandatory features of Wi-Fi Direct plus the following optional features: Invitation Procedure, Persistent Groups, Group Owner Intent Configurable to 15, and Group Owner Support for Multiple Clients.


Setting up the Group Owner on a WICED Device


You can use the following command to set up your WICED device as the group owner.

>> p2p_go_start <p|n> <SSID> <key> <operating channel>


You'll see the device set up a network.



You can check the info by typing in "status". It shows that the device is set up as the group owner and the network SSID is DIRECT-test.

>> status


Once a group owner is operating the WPS registrar can be started in PIN or PBC mode to allow clients to join. Clients may also join without using WPS if they know the SSID and WPA2 passphrase, but will not be able to use P2P features. If the WPS registrar is started in PIN mode without supplying a PIN it will generate one that can be entered into the client. The group owner registrar can be started before or after the connection request. If the client starts first and wants to use PIN mode with its own PIN then the client's PIN must be entered into the registrar when it is started. If the registrar starts first using PIN mode, then its PIN must be entered into the client. Legacy WPS clients always supply the PIN so they need to generate a PIN first. The p2p_registrar_stop command can be used to abort the group owner registrar.


Start the registrar process by

>> p2p_registrar_start <pin | pbc>

If you choose the pin method without specifying one, it will give an 8 digit pin to enter on the other device.



Connecting to the Group Owner From Another WICED Device


From another WICED device, you can request a connection by the command

>> p2p_connect <pin | pbc>

If you started the registrar in the group owner device with a pin, enter that 8 digit pin as well.


It will give you a list of group owners to connect to. In this case #9 is the one I set up on the first WICED device so I type in 9.


The connection is now set up between the two.


Connecting to the Group Owner From an Android Device




Group Owner Negotiation


Instead of setting up a group owner explicitly, you can issue p2p_connect on both WICED devices and let them negotiate who the group owner will be.


Do the following on both devices.

>> p2p_enable_discovery


Check that you can see the other device

>> p2p_peer_list



If you see it, issue the p2p_connect command on both devices and pick the the peer you want to connect to

>> p2p_connect pbc


Once it is issued on both devices they will communicate, decide on who will be the group owner, and set the network up. You should see a screen like the following



You can change the priority beforehand if you want a particular device to be the group owner. The priorities are from 0 to 15, where 15 is the highest meaning that it must be the group owner in all cases.


>> p2p_set_go_intent <intent value>


Discovery Related Console Commands


>> p2p_discovery_enable
Enables P2P discovery mode. This device can now be seen on other P2P devices.


>> p2p_peer_list
Enables discovery and prints out the list of P2P peers. It will discover peer devices, group owners and group clients. Devices do not need to be on the social channels in order to be discovered. Devices are aged out of the list over time if they are not seen.The type on left indicates whether the peer is a group owner.



>> p2p_discovery_disable
Disable P2P discovery mode



Group Owner Related Console Commands


>> p2p_go_start <p|n> [<ssid_suffix> <key> <operating channel>]
Start P2P (p)ersistent or (n)on-persistent group.


>> p2p_go_stop
Stop P2P group owner


>> p2p_registrar_start <pin|pbc> [8 digit PIN]
Start P2P group owner's WPS registrar


>> p2p_registrar_stop
Stop P2P group owner's WPS registrar


Some Examples :


Once you set up a group with the SSID, passphrase and channel, you can stop the group owner then bring it up without needing to supply the information again.





Client Related Console Commands


>> p2p_connect <pin | pbc> [8 digit PIN]
Connect to an existing Group Owner or negotiate to form a group"


>> p2p_leave
Disassociate from P2P group owner



P2P Settings Related Commands


>> p2p_set_go_intent <intent value>
Set P2P group owner intent (0..15 where 15 = must be GO)


>> p2p_set_go_pbc_mode_support <0|1>
Set P2P group owner support for PBC mode (1 = allow, 0 = disallow). This command allows connection requests where the WPS method is push button mode to be ignored.


>> p2p_set_listen_channel <channel>       
Set listen channel (1, 6 or 11)


>> p2p_set_operating_channel <channel>
Set operating channel (1..11)

Here is how to enable UART on BCM943362WCD4 and BCM943341WCD1 as terminal output.


On both platforms, BCM943362WCD4 and BCM943341WCD1, the UART4 Rx pin is routed to the SW2 but it can be setup to receive data on the UART4 if the switch is not utilized.


Both UART4 Rx and Tx pins are routed to the "Breakout Header" on the evaluation platforms.


BCM943362WCD4 Platform:

     UART4-Tx -> J7-9

     UART4-Rx -> J7-6


To change the terminal serial port from USART1 to UART4 update the below definition in .../platforms/BCM943362WCD4/platform.h

BCM943341WCD1 Platform:

     UART4-Tx -> J7-20

     UART4-Rx -> J7-8


To change the terminal serial port from USART6 to UART4 update the below definition in .../platforms/BCM943341WCD1/platform.h


Attached are the updated platform files to support UART4.


ADC Setup and Read

Posted by SeyhanA_31 Mar 16, 2015

The WICED host CPU's ADC port can be setup to read ADC data and send it to a remote host or client.


The App_temp_control application (temp_control) located in .../apps/demo/temp_control demonstrates  ADC setup and reading. This application sends temperature data (ADC data) to remote host ( The same data is served by the http server running on the WICED module and sent to http clients.  This is a comprehensive sample application with many rich features.


The attached sample application sets up the ADC using only WICED APIs and reads the ADC data then prints the read ADC value on the serial terminal.


The new adc_setup_read  snip application is located in …/apps/snip/adc_setup_read. Patch file updates the …/apps/snip/ directory with adc_setup_read application files.


In order to run this snip application on the BCM43341WCD1 platform platform.c and platform.h files needs to be updated. Attached patch file contains the needed changes.


Use the following Make Target commands to build the ADCSetupReadApp application.

For BCM943362WCD4 platform:

     snip.adc_setup_read-BCM943362WCD4 download run


For BCM943341WCD1 platform:

     snip.adc_setup_read-BCM943341WCD1 download run


The ADC values are printed on the serial terminal.


Here is an example of interfacing the BCM43362 based SN8000 WiFi module (from Murata) with the STM32F429-Discovery board.


The below schematic illustrates the connections required to connect the SN8000 to the STM32F429-Discovery board. Since the SN8000 comes as a module to connect to a PCB, a carrier board is needed to connect the module to the STM32F429-Discovery board.

ScreenHunter_95 Jan. 02 16.15.jpg

If you have the SN8000 module mounted on a SDIO carrier board, which comes with the SN8000 evaluation board, the following connection schema could be used to connect the module to the STM32F429-Discovery board.


For terminal interface between STM32F429-Discovery board and host PC the following serial (RS232) connection is needed.

To connect a JTAG debugger (Olimex_ARM-USB-TINY-H) to the STM32F429-Discovery board follow the below connection.

For more information please take a look at this link: Interfacing STM32Fx-Discovery with WICED using JTAG Debugger


After setting up the hardware connections WICED SDK-3.x should be updated to run WICED applications on STM32F429-Discovery board with SN8000 WiFi module. Unzip the attached file with the following expected updates.


Contents of the "WICED.platform.MCU.STM32F4xx.GCC.STM32F429.7z" goes to .../WICED/platform/MCU/STM32F4xx/GCC/STM32F429 directory of the WICED SDK.


Contents of the "platforms.STDiscovery429_BCM43362.7z" goes to .../WICED/platforms/STDiscovery429_BCM43362 directory of the WICED SDK.


The STM32F429 Discovery board I have does not have an external RTC oscillator and the internal oscillator needs to be setup as input.

To setup the internal oscillator for RTC define the following "#define WICED_RTC_CLOCK_SOURCE  (INTERNAL_OSCILATOR)" in updated .../include/wiced_defaults.h file.


Update the below files for the RTC oscillator source setup:

The above files and updates are attached.


To build and run application using WICED SDK following Make Target could be used;

     <Application>-STDiscovery429_BCM43362 JTAG=Olimex_ARM-USB-TINY-H download run


To build and run a sample scan app use the following Make Target:

     snip.scan-STDiscovery429_BCM43362-debug JTAG=Olimex_ARM-USB-TINY-H download run

WICED WiFi modules can be setup to restrict the number of clients that can join the WICED Soft AP mode device.


If the number of clients to join the WICED Soft AP device is set to 1, one client is allowed to join at a time. Once the joined device is disconnected from the AP the next device is allowed to join.

Copy the following code anywhere in …/WICED/WWD/internal/wwd_wifi.c

wwd_result_t wwd_wifi_set_max_associations( uint32_t max_assoc ) {
    wiced_buffer_t buffer;

    uint32_t* data = (uint32_t*) wwd_sdpcm_get_iovar_buffer( &buffer, (uint16_t) 4,IOVAR_STR_MAX_ASSOC );
    *data = max_assoc;

    RETURN_WITH_ASSERT( wwd_sdpcm_send_iovar( SDPCM_SET, buffer, NULL, WWD_STA_INTERFACE ));



Copy the following code anywhere in …/WICED/WWD/include/wwd_wifi.h

/** Set the maximum number of associations in STA mode.
*  Defined only on STA interface
* @param noise : number of allowed accociations
* @return  WWD_SUCCESS : if success
*          Error code   : if Link quality was not enabled or not successful
extern wwd_result_t wwd_wifi_set_max_associations( uint32_t max_assoc );

Add wwd_wifi_set_max_associations(…) after setting the WICED network.

For example …/apps/snip/apsta application could be updated by adding wwd_wifi_set_max_associations(…) after wiced_network_up(…).

/* Bring up the STA (client) interface ------------------------------------------------------- */
/* Restrict number of Soft AP clients */

The attached application creates threads, waits for each thread to end and then deletes the threads.


Each thread prints thread specific information on the serial terminal.


To synchronize the printing on the serial terminal, semaphore is created and passed to the each thread, along with some other data, as a thread parameter.


Block of threads are created and waited on to be joined before they are deleted.


Setting up and running the application:


Unzip the attached zip file and copy the "create_delete_thread" directory to .../apps/snip/ directory, /apps/snip/create_delete_thread.


Add "snip.create_delete_thread-<YourPlatform> download run" to the Make Target

     For BCM943362WCD4 platform: "snip.create_delete_thread-BCM943362WCD4 download run"


Connect your target module to your development host computer.

Open WicedSerial or serial terminal to observe serial data sent from the target device.


Below is the output captured via WicedSerial:

Filter Blog

By date:
By tag: