Skip navigation
Home > All Places > WICED Smart Bluetooth > WICED Smart Bluetooth Forums > Blog > Authors jota_1939431
1 2 Previous Next

WICED Smart Bluetooth Forums

16 Posts authored by: jota_1939431

This BLOG is a short introduction for configuring the TAG3 board for use with the Serial FLASH.

This information is taken from our TAG3 document Manual :  The specified item was not found. and our Quick Start Guide The specified item was not found.

1.  The TAG3 board contains a Serial FLASH device and can be configured with a few resistor modifications and additions:

See the TAG3 Board below:

 

TAG3Board_SFLASH.JPG

 

2.  TAG3 Board Assembly displaying the resistor installation/modifications for the on board Serial FLASH:

 

3.  The table below defines the resistors to configure the Serial FLASH:

 

4.  You will need to place the SW4 switches 5,6,7,8 in the OFF position (They are actually show in the ON Position in this photo):

 

 

5.  In the SDK you will need to modify your Make Target to include NV=SFLASH:

 

Note: In this case we have used COM Port 21 as observed in our Windows Device Manager:

 

 

 

5.  Using the Recovery Procedure from the The specified item was not found. document, your recovering console message should look like the following:

 

 

 

A few extra notes about Serial FLASH:

 

 

You will need to use the same Macronix Serial Flash that is supported by the ROM and ships on the TAG3 board.  Please see the schematic snippet below:

 

 

http://community.broadcom.com/servlet/JiveServlet/showImage/2-5581-2069/Macronix.png

 

The Macronix MX25U4033 device works as well if you needed a second option.

 

Please see the notes below:

 

MX25U4033: https://www.macronix.com/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25U4033E&m=Serial%20NOR%20Flash&n…  (good for new designs)

 

MX25U4035: https://www.macronix.com/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25U4035&m=Serial%20NOR%20Flash&n=…  (not recommended for new designs)

 

Regarding the two different Flash PNs, here’s a document from the Macronix website that compares the two:

https://www.macronix.com/Lists/ApplicationNote/Attachments/1872/AN126V1_MX25U4035%20to%204033E.pdf

jota_1939431

I2C Discussion

Posted by jota_1939431 Oct 27, 2014
RevisionDescriptionDate
1.0I2C Description10/27/14

 

The I2C topics seem to be a bit confusing.

I am creating this Blog to address these concerns.

 

I will post a video shortly that will thru a Code Walk Thru.

 

NOTE:

There is a known issue with i2cm_* functions.

You must use cfa_* functions instead.

 

 

i2cm_* can only be used when patch enable_spiff1_i2c_interop.a is used *and* NV is serial flash on SPI1

 

Here are miscellaneous notes that have collected regarding the I2C Issues:

 

Both SCL and SDA should be high before I2C communication begins.

 

SPIFFY1 is shared with I2C, which is already being used to talk to the EEPROM on the module.

 

 

SPI-flash and I2C interfaces concurrent:

 

 

We don’t have the drive strength once to drive the I2C line hard enough with a total of 4 slaves on the bus.

 

 

How the SDA pin is sampled during boot by the firmware and how the I2C pins behave:

  • Connecting SDA to Vdd/Vio to recover is probably a bad idea
  • SCL and SDA are both open-drain
  • The pull-ups pull the signal high while the HW drives it low
  • It never drives high, but floats the output pad leaving the pull-up to pull the line high
  • If you put a scope to either of these lines on the board when the FW accesses these, high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC
  • If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND - Not good
  • This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip
  • Shorting to GND on the other hand, is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line

 

How to decrease the clock speed during programming (and for subsequent accesses to the EEPROM), because the faster clock speed seems to be causing another i2c device to lock up:

 

 

See i2cm.h, i2cm_setSpeed(). Use I2CM_SPEED_* from this header.

 

If you use cfa_* API that is used by the i2c_temperature_sensor sample, you cannot change the I2C bus speed (defaults to 400KHz). You can use the corresponding API in i2cm.h to read/write the same data and also change speed if required

 

 

I2C and P_UART Dependency:

  • PUART and I2C don't have any dependency. You can use both at the same time. SPI2 and PUART however do have some restrictions, see the datasheet or the HW interfaces document (in short - PUART RX and SI2 have to be on the same GPO bank).
  • I2C and SPI1 share GPIOs. With SDK 2.1 and above, there is an optional patch with which you can use I2C when SPI1 is used for NV storage (serial flash). But the other way where you want to use SPI1 as an SPI master when using I2C EPROM slave is not possible.

 

 

 

To use it, you just have to include the patch and use the API in i2cm.h:

 

# Add to application’s makefile.mk:

APP_PATCHES_AND_LIBS += enable_spiffy1_i2c_interop.a

 

The in application, #include “i2cm.h”  and use the I2C API in this header to access the I2C slaves. No changes to the way you access NV (using bleprofile_*)

 

The cfa.h interface is where most people failed in their code

 

Example Code:

// Reads 16 bits from the given register address in LM73.

// \param register_address The address to the register to read.

// \param data INOUT Pointer to a INT16 into which the data is to be read, valid only if return value is 1.

// \return 1 if successful, 0 on failure.

UINT8 temperature_sensor_read_16_bit_register(UINT8 register_address, INT16* data)

{

    UINT8 read_status;

    UINT8 return_value = 0;

    UINT8 reg_read_bytes_to_write[1];

    UINT8 reg_bytes_to_read[2];

    reg_read_bytes_to_write[0] = register_address;

    // Do a combo write then read operation

    read_status = i2cm_comboRead(reg_bytes_to_read, sizeof(reg_bytes_to_read), reg_read_bytes_to_write,

                                                        sizeof(reg_read_bytes_to_write), LM73_SLAVE_ADDR);

 

    switch(read_status)

    {

        case I2CM_BUSY:

            // Transaction did not go through. ERROR. Handle this case.

                // There is already a pending transaction.

            break;

 

        case I2CM_SUCCESS:

            // The read was successful.

            *data = (INT16)(reg_bytes_to_read[1] | reg_bytes_to_read[0] << 8);

            return_value = 1;

            break;

 

        case I2CM_OP_FAILED:

 

            // No slave device with this address exists on the I2C bus. ERROR. Handle this.

        default:

            break;

    }

    return return_value;

}

 

// Writes the given value ino the given 16 bit register.

// \param register_address The address of the register to write to.

// \param data The data to write.

// \return 1 on success; else 0.

UINT8 temperature_sensor_write_16_bit_register(UINT8 register_address, INT16 data)

{

    UINT8 read_status;

    UINT8 return_value = 0;

    UINT8 reg_bytes_to_write[3];

    reg_bytes_to_write[0] = register_address;

    reg_bytes_to_write[1] = (data >> 8) & 0xFF;

    reg_bytes_to_write[2] = data & 0xFF;

    read_status = i2cm_write(reg_bytes_to_write, sizeof(reg_bytes_to_write), LM73_SLAVE_ADDR);

 

    switch(read_status)

    {

        case I2CM_BUSY:

            // Transaction did not go through. ERROR. Handle this case.

           // There is already a pending transaction.

 

            break;

 

        case I2CM_SUCCESS:

            // The read was successful.

            return_value = 1;

            break;

 

        case I2CM_OP_FAILED:

            // No slave device with this address exists on the I2C bus. ERROR. Handle this.

        default:

            break;

    }

    return return_value;

}

 

// Reads given register by first writing the pointer register

// then reading the register value. Leaves the pointer register as is when leaving

// \param register_address The register to read from

// \param data INOUT Pointer to a buffer into which to read. Valid only if the return value is 1

// \return 1 on success; else 0.

 

UINT8 temperature_sensor_read_8_bit_register(UINT8 register_address, UINT8* data)

{

                UINT8 read_status;

    UINT8 return_value = 0;

    UINT8 reg_bytes_to_read[1];

    // Do a combo write then read operation

    read_status = i2cm_comboRead(reg_bytes_to_read, sizeof(reg_bytes_to_read), &register_address,

                                                        sizeof(register_address), LM73_SLAVE_ADDR);

    switch(read_status)

    {

        case I2CM_BUSY:

            // Transaction did not go through. ERROR. Handle this case.

            break;

 

        case I2CM_SUCCESS:

            // The read was successful.

            *data = reg_bytes_to_read[0];

            return_value = 1;

            break;

 

        case I2CM_OP_FAILED:

            // No slave device with this address exists on the I2C bus. ERROR. Handle this.

        default:

 

            break;

    }

    return return_value;

 

}

// Writes the given value to the given register by first writing the pointer register

// then writing the value. Leaves the pointer register as is when leaving.

// \param register_address The address of the register to write to.

// \param data The data to write to the register.

// \return 1 on success; else 0.

 

UINT8 temperature_sensor_write_8_bit_register(UINT8 register_address, UINT8 data)

{

    UINT8 read_status;

    UINT8 return_value = 0;

    UINT8 reg_data_bytes[2];

    reg_data_bytes[0]= register_address;

    reg_data_bytes[1] = data;

 

    read_status = i2cm_write(reg_data_bytes, sizeof(reg_data_bytes), LM73_SLAVE_ADDR);

    switch(read_status)

 

    {

        case I2CM_BUSY:

            // Transaction did not go through. ERROR. Handle this case.

            break;

 

        case I2CM_SUCCESS:

            // The read was successful.

            return_value = 1;

            break;

 

        case I2CM_OP_FAILED:

            // No slave device with this address exists on the I2C bus. ERROR. Handle this.

        default:

            break;

    }

    return return_value;

}

 

 

 

RevisionChange DescriptionDate
1.0Initial - 15 minute video10/08/14

 

 

Michael L. takes us through a Schematic Review of the iBCN BCM20737 Reference Design.

 

Thank you Michael.

 

WICED Smart Documents & Downloads

 

The schematic is located:

iBeacon BCM20737 Reference Design PDF Schematic (SOC)

 

The Gerbers are listed here:

iBeacon BCM20737 Reference Design Gerber Files (SOC)

 

He discusses:

  1. The Baseband section of the BCM20737
  2. Recovery Process
  3. Common mistakes he has seen from designers
  4. Decoupling Caps for the Pins and RF section

 

 

 

Let us know if you have any questions

Thank you

 

JT

RevisionChange DescriptionDate
1.0Initial09/22/14 - 1:30PM

 

 

Welcome to the iBeacon and SDK 2.1 Code Overview.

 

Note:

  1. In order to obtain the Apple iBeacon Libraries, you MUST be an iBeacon Licensee.
  2. If you have received your Apple iBeacon License Number, please send us an email.
  3. If you do NOT have an Apple iBeacon License, please apply for it at: iBeacon for Developers - Apple Developer

 

Below is a short introduction to the iBeacon Definitions and a code walk_through of iBeacon and iBeacon_Managed SDK Applications.

These iBeacon Applications do NOT include the iBeacon libraries - Please see Note above:

iBeacon Introduction

 

 

Thank you

 

JT

jota_1939431

WICED SENSE Kit BLOG

Posted by jota_1939431 Aug 27, 2014
1.0Initial Release
1.9

Added WICED Sense Android Source Code Walk-Thru and iOS Source Code version 1.1

03/10/15

 

Welcome to the WICED Sense BLOG.

WICED Sense Kit Beginners Guide:

WICED Sense Kit Smart Phone Application:

 

WICED Sense Kit using SDK 2.2:

WICED Sense Kit:

 

Please refer to the WICED Sense documents are located here: WICED Smart Documents & Downloads

 

WICED Sense Beginners Guide:

  1. Removing the Battery and WICED Sense Kit Board

Remove_Battery1.JPG

Remove_Battery2.JPG

 

 

WICED Sense SDK Beginners Guide:

  1. SDK 2.1.1 Download
  2. WICED Sense BLOG, Design Files, iOS Source Code
  3. Installation of the Silicon Labs USB-UART Drivers
  4. Connecting the WICED Sense Kit to the USB Cable
  5. Creating a SDK Project for the WICED Sense Kit
  6. Compiling and Downloading the WICED Sense Firmware to WICED Sense Kit.

 

 

WICED Sense Recovery:

  1. Connect the USB Cable to the Kit
  2. Locate the COM Port enumerated by your PC

 

The Recovery Process uses either the COM35 or COM36 ports in our case.

In the SDK Make Target, the recover port is COM35 and we edit the WICED Sense Target as shown below:

Before using the SDK to Recover, we need to place the Kit in Recovery Mode by pressing the sequence of Rest and Boot Buttons as follows:

 

Now we click the Make Target Recovery button and we should see the following:

 

WICED Sense Modification for Debug:

  1. After programming the WICED Sense Kit with your application you will need to remove the resistor highlighted below to add debugging using a TeraTerm Window.
  2. Caution: Remember to Re-Install the resistor to reprogram the device.

 

Resistor_Removal_Debug_TeraTerm.png

 

WICED Sense Code Walk-Thru:

 

 

Procedure for running the WICED Sense TAG on USB Power:

  1. Remove the USB cable after you have successfully programmed the Tag
  2. Leaving the Battery cover off in this process, press the battery into the battery socket until you see the RED Led turn on

P9250930.JPGP9250931.JPG

 

3. While holding the battery with your fingers making the battery connection, insert the USB Cable in the Tag

P9250932.JPG

4.  Release your finger from the battery, letting the battery drop out of the socket and you are now running the Tag from the USB Power

P9250934.JPG

 

 

 

Introduction to WICED Sensors

 

The following STMicro Sensors are used:

 

Please refer to the STMicro Web site for details on Sensor Data Sheets.

 

 

The iOS App receives notifications in this format:

 

 

OTA_Sensor_Packets.JPG

 

struct
{
/// Bit mask of sensor data
/// Bit 0: When set, accelerometer included X (2 signed bytes), Y (2 signed bytes) and Z (2 signed bytes).
/// Bit 1: When set, gyro included X (2 signed bytes), Y (2 signed bytes) and Z (2 signed bytes).
/// Bit 2: When set, humidity included (2 unsigned bytes in percentage).
/// Bit 3: When set, magnetometer included X (2 signed bytes), Y (2 signed bytes) and Z (2 signed bytes).
/// Bit 4: When set, pressure included (2 bytes, pressure in mBar * 10)
/// Bit 5: When set, temperature included (2 unsigned bytes, temperature in C * 10).
UINT8    included_sensor_data;
/// sensor data.
/// Data included in the order of the bits set.
/// Max length is 20 bytes, may be smaller when data for only some sensors is included
///        in the notification.
/// Notifications sent out when enabled
/// Notifications for Sensor Notification characteristic value (handle 0x2A)
UINT8    sensor_data[];
};

 

Android App Released:

The WICED Sense App for Android is now available on Google Play...

 

JB 4.3 Work-Around:

WICED Sense Android Pairing Work-Around

 

iOS Application designed by www.DittyLabs.com

 

 

Thank you.

 

JT

RevisionChange DescriptionDate
1.0Initial08/08/14
1.1Added J-Link Cable for Reference08/11/14

 

WICED Smart J-Link Debugger

 

The WICED Smart J-Link Debugger is a Software debugger combined with Segger J-Link Debug Probe.

 

  1. The J-Link Debug Probe is shown below and the link is located here: SEGGER - The Embedded Experts

 

JLINK_Debugger.JPG

Figure 1: J-Link Segger Debugger

 

2.  Schematic of cable adapter to the J-Link 20 Pin connector:

 

Cable_Schematic.JPG

Figure 2: J-Link Segger Debugger Interface Connector

 

3.  Shown below is the connection to the BCM20737TAG_Q2 Board:

 

J-Link_Connector.JPG

 

Figure 3: J-Link Connection to BCM20737TAG_Q2 Board

 

 

 

 

4.  The Smart Designer J-Link setup procedure:

 

  1. Start SDK

  2. Connect USB to Top Port PC
  3. BCM20737TAG_Q2 Board Switch configuration for programming:

     JLINK_Pic.png

Figure 4: Boot ROM, Reset and Switch Buttons

 

 

 

    1. Please refer to the Quick Start Guide: http://community.broadcom.com/docs/DOC-1602

  1. Configuration for Push Button Switches
    1. BOOT ROM Push Button
    2. RESET Button
  2. Push Button Sequence:
    1. Press and Hold BOOT ROM Button
    2. Press and Hold RESET Button
    3. Release RESET Button
    4. Release BOOT ROM Button
  3. SDK Commands
    1. Run Clean
    2. Run PWM-Tones App
  4. Run Debugger:
    1. Remove USB and Insert Battery
    2. Return Switches to opposite program
    3. Connect J-Link USB Connector to PC
    4. Connect J-Link to Board - See Figure 3 above.
    5. Push Reset
    6. Run GDB Server
    7. Click OK – Observer 2 Green Lights
    8. Click Bug Icon in SDK (Top Middle Section)
    9. Click “I” Icon (Under Navigate Menu) – Instruction Mode

   Click “I” once then press F5 3 times.


Note: R3 (the 10K pulldown on RXd) must be removed for the debugger to work.


Please let us know if you have any issues.

 

Thanks

 

JT

RevisionChange DecriptionDate
1.0iBeacon Reference Design06/26/14

Hello Community Members,

 

Welcome to the WICED Smart Reference Design Series.

 

iBeacon Reference Design

 

Design Files are located here: WICED Smart Documents & Downloads

 

The Broadcom iBeacon reference design is based on the WICED SMART BCM20737 Bluetooth Low Energy transceiver.

 

The iBeacon hardware provides the following features:

  • 4 Connection pads (UP_TX, UP_RX, VDDIO and GND) to enable programming of the device
  • SW1: An on/off slide switch
  • SW2: Push button to disable all radio function
  • SW3: A push button for EEPROM firmware recovery
    • The procedure to recover the EEPROM is as follows:
      • Power off the device
      • Hold down SW3
      • Power on the device
      • Release SW3
      • Proceed to program the new firmware into the device

 

Top_Arrows.png

 

Bottom_Arrows.png

More Reference Designs coming next month!

 

Thanks

JT

RevisionChange DecriptionDate
1.0Initial Video - No Audio - 10 Minutes06/24/14
1.1Added/Edited Audio and Video06/25/14
1.2Added Text Annotations07/01/14
1.3Added Part 2, 3, 4, 5 and 6 without Annotations10/08/14

Hello Community Members,

 

Welcome to the WICED Smart Video BLOG Series: Interviews with the Experts.

 

Experts Interview - Sleep Deep_Sleep and Advertising

 

This Video BLOG should be used as a "guide" for walking through the Sleep and Deep_Sleep functionality with respect to the hello_sensor app in the SDK 2.0.1.

 

We will interview with Sleep Deep_Sleep expert A.S. and hear his explanation of the Sleep and Deep_Sleep control that the SDK 2.0.1 firmware uses for the hello_sensor example app in the SDK 2.0.1

 

We also discuss:

 

  1. How the System and Stack handle the HIGH and LOW Directed Advertisements
  2. Sample of 5 Sensors and how they interact with the Stack.

 

Thank you A.S. for your help in this explanation:

 

Part 1:

                                           

                                         

                                                   

                                                                                            

Part 2:

 

 

Part 3:

 

 

Part 4:

 

 

 

Part 5:

 

Part 6:

 

 

JT

RevisionChange DecriptionDate
1.0Initial Video - No Audio - 6 minutes06/23/14
1.1Added Audio06/24/14
1.2

Added detailed Smart Designer video - Uses Microbrewery and Beer Drone as Services and Characteristics explanation

09/22/14

Hello Community Members,

 

Welcome to the WICED Smart Video BLOG Series

 

This Video BLOG should be used as a "guide" for walking through the Smart Designer Tool in SDK 2.1.

 

This video will illustrate a great feature to use for configuring the GATT for Bluetooth SIG approved profiles + Vendor Specific Profiles.

 

This Smart Designer Walk-Thru uses a Sensor Device with the following sensors needed to be configured with Vendor Specific Characteristics:

  1. Temperature
  2. Barometric Pressure
  3. Humidity
  4. Gyro
  5. Magnetometer - eCompass

 

We have made it fun by showing a Microbrewery Sensor Configuration and a Beer Drone example - Hope you enjoy it!

 

It is a big file and 30 minutes, so view it when you have some time.

 

New Video starts here:

                                         

       

 

                                                 

 

Thanks

 

JT

RevisionChange DecriptionDate
1.0Initial06/22/14
1.1Added Aligned Memory Accesses10/28/14

Hello Community Members,

 

This BLOG should be used as a "guide" for examining the Memory Map configurations and Application Development.

 

This is a compilation of Memory Map questions and answers from several of our forum users and I thank you for your questions and answers.

 

The Memory Architecture consists of both RAM and ROM with external EEPROM in the BCM20732/36/37 devices.

The Memory Architecture of the BCM20732S/36S/37S consists of the RAM and ROM with Internal EEPROM.

 

ROM vs. RAM application assignment has caused some confusion in the past, so we eliminated this nomenclature in SDK 2.0.1.

 

The ROM contains:

 

  1. Embedded BLE stack
  2. L2CAP, GAP, GATT
  3. BT_SIG approved profiles such as proximity, heart rate monitor, thermometer, blood pressure monitor and time
  4. SMP
  5. HCI
  6. Drivers for I2C EEPROM, SPI EEPROM and SPI Serial flash

 

GATT:

 

  1. GATT database handles are 16 bit values from 0x00 to 0xFFFF
  2. This limits you to ~65K entries in the database
  3. With SDK 1.1.0, GATT characteristic length/max length is a 1 byte field
  4. SDK 2.0.1, it could optionally be a 2 byte field too
  5. The BT spec limits characteristics to a max of 512 bytes
  6. You will hit the available RAM limit long before your database gets anywhere close to this

 

ROM applications typically has some part of the application in the ROM and whatever user writes adds functionality to the ROM code

 

Application code is loaded in to NVRAM

RAM apps use LE Stack in the ROM

 

NVRAM:

 

Let's take an example from ws_upgrade.c in [uart|ota]_firmware_upgrade sample app from SDK 2.0.1

 

  1. When you read/write/delete NV items using bleprofile_*NVRAM, these operations are performed in the section marked VS1 in the picture above.
  2. The stack uses some of this for some internal book-keeping
  3. When you pair, all pairing information is stored in this area too
  4. So it is possible that you ran out of space when you attempted to store the 63 remaining bytes
  5. You can increase the the space allocated for VS1 by changing a couple of options in <SDK>/Platforms/BCM92073?TAG_Q32/2073?_EEPROM*.btp

 

Note: If you increase DLConfigVSLength, you may have to also increase ConfigDSLocation (which is the same as DS1 in the picture above) so that there is no overlap (the hex file conversion step when building will fail if it detects an overlap between the two regions).

 

 

Serial FLASH:

 

Serial Flash images are not compressed (because SF reads has only ~3% overhead and decompressing will make it slower).

 

BCM20736 will not access more than ~128kbytes from the base but the API uses 24 bit addresses (serial flashes use 24 bit addresses), so the entire SF should be accessible

 

The virtual addresses used by the FW API for EEPROM and SF is different

0xFF000000 for EEPROM and 0xF8000000 for Serial FLASH

 

These offsets should be used with bleappfwu_*().

 

PATCHES:

 

Patches take up 1900 bytes (today) assuming you only want the mandatory patches (no extra features that are being patched in).

So your application space gets ~28K (today)

 

MEMORY ARCHITECTURE BLOCK DIAGRAM:

 

Let's start with a Memory Map Diagram of the BCM20732:

 

 

The 30K is shared memory (between patches and the app) and the dynamically allocated buffers also take up some of this space.

 

 

The ‘total RAM footprint ‘ line at the end of the build is only the static portion of the app + patches (includes code + initialized and uninitialized data) in our flat memory model.

 

 

So you cannot take the app start address and add the app size and then subtract from 60K to get remaining size

 

The 4K CM3 Mapper is for the Cortex M3 Memory Map for Interrupts Stack, etc.

Note that our Stack (YELLOW) is 30K and is DATA ONLY.

 

The Patches Section (Features,Updates, etc) is combined with the User App but:

  1. The Patches_Init Code is overlayed and can be used by the App after the Patches are loaded
  2. The App_Init/BLE_SET_CONFIG is also overlayed by the Dynamic Allocation

 

 

 

 

 

 

Static variables that are NOT initialized end up in the data area:

 

  1. The ‘Data ONLY’ area in yellow is the data area allocated by the BLE stack that’s in the ROM
  2. So nothing new goes in here
  3. All application data (RW and ZI) and application code (Code + RO) goes into the same region in the RAM

 

 

SDK 2.0 Hello_Sensor Example App:

 

As an example, we take the Hello_Senor App and using the SDK Console Window, we see the Patches Start/End Addresses:

 

 

 

The Patches and Application Start Addresses are listed below:

 

 

 

 

As you can see, there is overlap between Patches and Beginning of Application

So after the Patches are finished loaded, a portion of the RAM is available for the Application

 

Here is what is happening:

 

  1. Patches start at where the ROM finished 0x00204568
  2. Patches end at 0x00204AFC, but the Application starts at 0x00204974 even before the Patches end
  3. So there is an overlap.
  4. Once the application ends at 0x00204C28, but dynamic allocation starts even before this.
  5. The reason is that in the order in which we boot, The Patches get copied in first and they will get initialized.
  6. Then the section of the code where there in Patch initialization, that will get reused and we will put the application on top of it and overlay the application.
  7. Once the Patch Init code is running, we can replace that section with the application code.
  8. We are re-using the RAM from the Boot Loader and Reusing the application initialization code also for dynamic allocation
  9. Once we have initialized, we don/t need that code anymore.
  10. The ROM boots and copies in ALL of the patches
  11. And then it will run the Patch Init Code and installs all of the MANDATORY patches
  12. Once that copy is done, you don’t need that Patch Init Code
  13. The ROM will copy the Application on top of it.
  14. Overwrite the Patch Init Code with Application Code
  15. Application Code will be 1.7K of code or less.
  16. The App calls the App Init Function and will say, available RAM is here
  17. Then the ROM starts Dynamic Allocation from here
  18. What goes in?
  19. Buffer,xx, Stack Buffer Tools, and Data
  20. Call Back Registrations
  21. Dump the Stack on the Peripheral UART and reset

 

Question – How much memory do you have?

  1. There is a function call CFG_MM_MemFreeBytes
  2. This is a pointer that keeps moving at every step
  3. When ROM finishes Initialization, available RAM is pointing to this
  4. When PATCHES finish Initialization, available RAM is pointing to this
  5. When the App finishes the Initialization, available RAM points to this area
  6. We can find how much we need by making 2 calls to RAM:
  7. By using init.c, we can take a snap shot of what this function returns and this will tell you where nm is at this point of time
  8. At the end of your Application Create Function, you take another snapshot of this guy and the difference between these 2 is your dynamic allocation

 

Notes:

The NVRAM has a lot of headers.

Serial FLASH is similar 0 – 4K

 

 

 

Questions:

 

Q: In the first diagram it suggests that the maximum size of an app should be 26K?

 

A: 26K is a good approximation because it really depends on what (HW/drivers/features) the app initializes and uses.  cfa_mm_MemFreeBytes() is the ultimate authority on the amount of RAM available

 

Q: Is there any way to estimate the amount needed for 'dynamic allocation' in that first diagram?

 

A: Not really, this is allocated for OS buffers, TX and RX buffers, stack buffer pools, thread stacks, callback registrations etc.

 

Q: If I end up with a total ram footprint of 26K , I am nervous that I might get overruns?

 

A: Yes

 

Q: What is the maximum stack size?

A: The app thread stack size is 1K (1024 bytes).

 

Q: What is the amount of space available for global and static variables?

A: The app code + globals (initialized and zero-initialized) all share the same space. So allocating more globals will reduce space for app code and vice-versa.

 

Q: Are there any built in functions of the stack that can be turned off to save space, for example if I disable the battery status profile does that cut down on the footprint?

A: No, here's why

Disabling battery monitor will not give you more space because its in the ROM.

 

 

 

This BLOG should get you going and I will be adding more later.

 

Additions:

The CPU core is an ARM Cortex M3 which supports unaligned accesses (so no exceptions will be thrown).

 

However, there is a performance penalty - the instruction will take multiple cycles to complete and the pipeline will stall (see ARM documentation). Load/Store multiple instructions do not support unaligned accesses.

 

Thanks

 

JT

RevisionChange DecriptionDate
1.0Initial06/22/14

Hello Community Members,

 

This BLOG should be used as a "guide" for examining Sleep and Deep_Sleep techniques.

This is a compilation of Sleep and Deep Sleep questions and answers from several of our forum users and I thank you for your questions and answers.

 

Let's start out with a explanation of how to place the BCM2073x in Sleep and Deep_Sleep modes and then move to sample Q/A regarding a few use cases.

 

Sleep Deep_Sleep Modes:

 

Here's a list of the Sleep/Deep Sleep modes:

 

  • Pause
    • The processor is idle if sleep is not allowed or there is not enough time to sleep due to processor or BLE Radio Activity
    • All state information is maintained
    • Near 0 cycle latency to wake up
  • Sleep
    • When lower power consumption is required
    • All state information is maintained
    • Can be woken up by timer or GPIO/ Keyscan /Quadrature sensors
    • About 2 mS latency to wake up
  • Deep Sleep
    • No state information is maintained
    • Can be woken up by GPIO/ Keyscan /Quadrature sensors
    • Includes ability to wake after configured time
      • With internal clock, can wake anywhere from 64mS to ~36 Hrs.
      • With external 32 KHz xtal, 128mS to ~144 Hrs

 

Deep_Sleep: Known on the BCM2073x devices as HIDOFF (Taken from the Human Interface Device OFF mode from Classic Bluetooth.

 

 

Waking the Device:

 

  1. Wake by GPIO:
  2. Note that there are 14 GPIOs on the module and most can drive/sink up to 2mA and are capable of waking device from sleep or deep sleep.
  3. All GPIO interrupts are serialized to the application thread.
  4. If the device is sleeping, the latency to get to the application thread context interrupt handler will generally be under 3mS.
  5. If not sleeping and not connected, then this will be of the order of a few tens of uS.
  6. In addition, there are multiple low power modes, and in many cases the firmware automatically handles low power states (as mentioned previously).
  7. The application may choose to participate in sleep and deep sleep decisions.

 

Permanently Disable Sleep

 

  1. To permanently disable sleep, register a callback using devlpm_registerForLowPowerQueries() and then in the callback, always return 0.
  2. For an example, see ws_upgrade_uart.c in uart_firmware_upgrade sample application.
  3. Note that this will drain more power than when sleep is enabled.

 

 

Notes regarding HidOff:

 

Deep_Sleep (HIDOFF) is not supported while the connection is up.

 

However, a connection can be kept when sleep is enabled (but not when deep sleep engages).

 

When the device is connected/scanning/advertising, it will always sleep between RF activity if the application allows it and there is sufficient time before the next scheduled activity.

 

Deep_Sleep (HIDOFF) does not retain state, so the chip cannot enter deep sleep when connected.

 

The most important point in determining Sleep and Deep Sleep modes is when to do it:

 

In many of our SDK 2.0 examples, power is automatically managed by the firmware based on input device activity.

As a power-saving task, the firmware controls the disabling of the on-chip regulator when in deep sleep mode - More on this later.

 

This BITES everyone - Be careful:

 

The BCM20732A0.cgs file has a Low Power Configuration section:

 

By default:
"Sleep enable" = 1

Change to 0 to disable the sleep function.


################################################################################
#  Low power configuration
###############################################################################
ENTRY "Sleep Mode Configuration"
{
    "Sleep mode" = "HIDD"
    "Sleep enable" = 1 ; Change to 0
}
##############################################################################

 

Sleep Current Consumption is roughly 24uA using the internal power management of the BCM20732.

 

In 1.5uA deep sleep, the xtal, IR and PWM blocks will be turned off.

 

The PWM does not operate in sleep or in deep sleep, and the PWM block is not capable of interrupting or waking up the processor.

 

GPIOs, peripheral uart, IR transmit, Keyscan and quadrature inputs can interrupt/wake the processor.

 

GPIOs that are output enabled will remain so and drive as configured in sleep/deep sleep.

 

Sleep operation in BLE Packet Transmissions:

 

Q: When sending packets periodically for BLE (e.g. 25 ms to 4 seconds), does the BLE stack put the 20732 in 1.5 uA deep sleep mode between the transmissions or is just the sleep mode (20+ uA)?

 

A: No, when advertising or in connection, the device will not go into deep sleep. However, it will go into other low power modes like sleep and pause based on the connection/ADV interval and other activities. If you want to ADV every few minutes, it is possible to ADV for some seconds, then configure timed wake from deep sleep and then enter deep sleep. After the configured time, the device will be woken up and then the application will be initialized.

 

Q: In deep sleep mode, the data sheet says core and base are turned off. Does that mean it loses the RAM contents? If so, where does application software store state information when it goes into deep sleep? The EE or an offboard chip?

 

A: Yes, in deep sleep the chip will lose its RAM contents. When woken up, the application will be loaded to RAM from the NV storage and re-initialized. This is very similar to a power-on-reset except that in the case of a wake from deep sleep, some HW state information is retained so that the application can find out what caused the wake.

 

Sleep Times:

 

Our BCM2073x device includes the ability to wake after configured time.

 

With the internal clock, this value is anywhere from 64mS to ~36 Hrs.

With an external 32 KHz xtal, 128mS - ~144 Hrs is possible.

 

PREVENTING THE DEVICE FROM GOING TO SLEEP WHEN USING THE P_UART:

 

If you are working with the PUART and in particular trying to Rx data with the PUART you will need to ensure that the following functions shown below are added into your PUART_Init() function.

 

You will also see these functions in the 'uart_firmware_upgrade' example.

 

The reason these are needed is otherwise the Device will put the PUART to sleep.

 

These functions disable the device from putting the PUART to sleep:

 

Put these inside of your PUART_Init() function devlpm_init();

 

// Since we are not using any flow control, disable sleep when download starts.

// If HW flow control is configured or app uses its own flow control mechanism,

// this is not required.

devlpm_registerForLowPowerQueries(Puart_device_lpm_queriable, 0);

//Callback function that is registered from function shown above:

devlpm_register...()

// Callback called by the FW when ready to sleep/deep-sleep. Disable both by returning 0

// when there is an active download ongoing.

UINT32 Puart_device_lpm_queriable(LowPowerModePollType type, UINT32 context)

{

// Disable sleep.

return 0;

}

 

 

Wake time from deep sleep:

 

Determination of Wake time from deep sleep is a combination of many factors:


Since this involves a full boot, it depends on whether you are using the BCM20732S/36S modules or BCM2073x SOC design, EEPROM or Serial flash (application + patch size), speed of NV access.

 

20732S modules:

 

The 20732S contains an EEPROM internally:

Boot Time: boot time* ~= 50ms + ~45mS/KByte of application + patch code (whats printed at the end of a build) assuming default I2C speed (400 KHz).

 

The 20732 chip-on-board design:

 

EEPROM Case:

You can increase the read speeds to 1MHz instead of the default 400 KHz.
But the boot time will not reduce by 2.5 times because there is a lot of processing involved during this process.
So this will be 50mS + ~30mS/KByte of app + patch code.

 

Serial FLASH Case:
When NV storage is serial FLASH, boot time ~= 50mS + 4mS/KByte of code.

 

BCM20736/7 modules:

 

EEPROM Case:

boot time ~= 20mS + ~35mS/KByte of app + patch code @ 400 KHz.
If I2C speed is increased to 1 MHz, this should be ~ 20mS + 23mS/KByte.

 

Serial FLASH Case:

boot time ~= 20mS + 900uS/KByte when SPI speed is 12 MHz.


Note: *boot time here is the time from wake interrupt to application create call.

 

 

Advertising and Sleep Modes:

 

When advertising (ADV) or in connection, the device will not go into deep sleep.

 

However, it will go into other low power modes like sleep and pause based on the connection/ADV interval and other activities.

 

If you want to ADV every few minutes, it is possible to ADV for some seconds, then configure timed wake from deep sleep and then enter deep sleep.

 

After the configured time, the device will be woken up and then the application will be initialized.

 

Crystal and Sleep:

 

The external 32KHz oscillator is optional with respect to timed wake from deep sleep.

 

The internal 128KHz LPO is used for sleep and timed wake from deep sleep

 

More later..

 

Please provide comments/questions

 

Thanks

 

JT

jota_1939431

IoT Hackathon Challenge

Posted by jota_1939431 Jun 13, 2014

Welcome to the IoT Hackathon Challenge!


If you cannot attend the IoT Hackathon, you can still submit your solution online.


Use your innovative idea for a Bluetooth low energy device.  Using WICED Smart SDK you can easily develop a device which performs as a sensor/peripheral, an embedded central, a broadcast or an observer, or can combine any of the these functions.  Broadcom will provide you required hardware, SDK and help to speed up your development.


 

Challenge:

 

Develop tone client and a tone server applications to run on the WICED Smart evaluation boards.  The server should be able to play music based on the notes sent by the client.

 


Use WICED Smart SDK to create a tone client and a tone server applications to run on the WICED Smart evaluation boards.  The server should be able to play music based on the notes sent by the client.

Detailed Instructions:

1. Developing Tone Service
     a. Use WICED Smart Designer feature of the WICED Smart SDK (File->New->WICED Smart Device Configuration) to create a           new tone_server device.  The device will need access to a buzzer of the development board.
     b. Add a Vendor Specific Service (tone_service) with 2 Vendor Specific writable characteristics Note and Command.  The Note           characteristic value corresponds to the tone to be played on the buzzer.  The Command characteristic is a control point which           peer device can use to Start or Stop playing the tone.
     c. Add a code from pwm_tones.c sample which supports playing tones on the buzzer.
     d. Implement a write_handler so that when peer device writes Start command the server starts playing the tone corresponding to           the value of the Note characteristic.
     e. Make sure that the device is discoverable while there is no connection.
     f. (Bonus) Turn on LED while a tone is being played.

 

2. Developing Tone Client
     a. Use proximity_client WICED Smart SDK as a sample.
     b. Start scanning on the startup and connect to any device publishing UUID of the Tone Server.
     c. When connection is established perform the GATT discovery to find out the handles for the Note and Command characteristics.            (You can cheat and skip this step because handles will be hard coded in the tone_server_db.h created in step 1.a).
     d. Using a timer callback play your favorite music using Bluetooth and the buzzer of the tone_server.  When it is a time to play a           specific note write to the Note characteristic and write the Start command to the Command characteristic.  You can use SONG           ).


Notes from our Applications Team.

1. The PWM can only modulate one tone at a time -can’t do polyphonic tones
2. So we have to time-slice it with some timers to change the tones every timer event.
3. Hint: If I were doing it, I would have an array of tone, duration, pause duration. 
4. And then play in the fine timer.

The trick is:
How to convert standard notes to pwm_start(PWM2, PMU_CLK, 0x2FF, 0x200); from

 

Good luck!

 

JT

RevisionChange DecriptionDate
1.0Initial05/22/14
1.1Added dsn file version 16.205/23/14
1.2Removed Reference to PDF Schematics [located in Hardware User Guide (SDK 2.x and TAG3 Board)]12/11/14
1.3MichaelF_56 removed design files from blog and relocated them to a dedicated category here within the Documents and Downloads section of the site: WICED Smart Documents & Downloads1/16/15

 

Hello Community Members,

 

This BLOG should be used as a "guide" for creating the PCB Layout for the BCM20737 device using the BCM20737TAG Board as a reference.

 

The first attachments are:

  1. BCM20737TAG_GERBERS_RevA.zip - The gerbers of a sample layout.
  2. BCM20737TAG_Allegro_CircuitBoard_Files.brd - Allegro circuit board file

 

 

The Schematic source will be added later

 

Notes:

  • You can view this PCB file by downloading a FREE Allegro PCB viewer from the following link:
  • http://www.cadence.com/products/pcb/Pages/downloads.aspx

    You will probably have to register on Allegro website before you can download the viewer.
  • Ensure you download this version:  "Reads designs for versions 15.x to 16.6. Requires a Windows OS"

 

I will include a description after this post to discuss the details and answer any questions.

 

Please refer to the latest documents related to the BCM20737TAG Board:

 

CYW20736 Product Brief

The specified item was not found.

 

Note: MichaelF_56 moved all design files previously attached to this blog to the dedicated TAG3 Category here within the Documents and Downloads section: WICED Smart Documents & Downloads

 

Thanks

 

JT

RevisionDescriptionDate
Revision 1Part 1: Added Perl Script for Manufacturing Process - Attached file below10/22/14
Revision 2Changed Title and cleaned up text for BCM20737.10/31/14

PART 1: Process for BD_ADDR Manufacturing Programming - NO SDK

 

Contents of the WICED_Smart_Programming Download attached file at the bottom of this BLOG:

 

Perl Script Definitions - See file attached below:

  1. mac.pl:
    $$r=int(rand(20480));

         rand(20480):

         1.  20480 is the maximum number you want to generate

          2.  Rand will generate a number between 0 and 20480

          3.  Upper 24 bits are the OUI numbers (Broadcom Corporation Assigned) - Please see BD_ADDR - how do you get one?

          4.  The lower 12 bits are unique for each device

          5.  If you have several production test stations operating in parallel it may be easier to generate random numbers.

          6.  A more elegant script may be written to generate a serialization for inventory purposes.

          7.  You can choose how to generate the lower 12 bits - either random or from a structured database.

 

 

 

   2.  printf "00101801%04X",$$r;

 

          00101801%04X - Lower 12 bits are programmed to a Random Value

 

 

System Programming Tools Setup:

 

The programming ecosystem of the BCM2073x devices involves the use of executable files both compile and produce necessary files for use in programming the modules.

 

The first file needed is the cgs.exe file to enable the board address (BD_ADDR) programming at the time of production.

 

The cgs.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\CGS\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at LINK

Location of cgs exe.png

Figure 22: Location of cgs.exe

 

The second file needed is the chipload.exe file to download the programming file to the programmer at the time of production.

 

The Chipload.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\ChipLoad\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at LINK

Location of ChipLoad exe.png

Figure 23: Location of ChipLoad.exe

 


The cgs file can also be edited in the SDK Build window as shown below:


The third file needing editing for programming is the EEPROM file BCM2073xAx.cgs file.  The cgs file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Platforms\BCM20737TAG_Q32) as shown below.

 

This is the file uses to program the EEPROM with the customer application.

Location of 20737_EEPROM cgs file.png

Figure 24: Location of 20737_EEPROM.cgs file

 


The fourth file needed is the EEPROM.btp file can also be edited in the SDK Build window as shown below:


The fourth file needing editing for programming is the EEPROM file 2073x_EEPROM.btp file.

 

The btp file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Platforms\BCM20737TAG_Q32) as shown below.

 

This is the file uses to program the EEPROM with the customer application.

 

Location of 2073x_EEPROM btp file.png

Figure 25: Location of 20737_EEPROM.btp file

 

Command Line Programming Procedure using the Loader.exe

 

 

Using the Loader Software Command Line Tools

 

The Loader Software tool utilizes a Command Line Tool to call the appropriate programming files to program the same BD_ADDR programming as the SDK Tool Chain, but in used in the volume programming environment.

 

Programming Procedure using Cygwin utility

 

The Cygwin Utility can be found at: http://www.cygwin.com/install.html  is used to execute the Loader commands and accesses the appropriate configuration files used in the programming procedure.

 

Below is an example of using Cygwin to execute the Loader command line utilities.


Please observe the highlighted files described previously, but change :


Figure 26: Cygwin BCM2073x File Location

 


Converting cgs file to hex file

The following procedure converts the cgs file to a hex file:


1.  Using command-line interface (e.g. Cygwin, cmd.exe), run cgs.exe.


2.  Use the following command
       a.  ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>
       b.  Example below: ./cgs.exe –I output.hex –A 0xFF000000 –B 20737_EEPROM.btp –D . A_20737A1-bleprox_mod-rom-rom-spar.cgs


3.  Definitions of parameters:


       a.  output_file_name.hex – will be the converted hex file.
       b.  btp_file.btp – btp file for the 20737_TAG board.
       c.  input_file.cgs – built cgs file for the application from  the SDK
       d.  0xFF000000 – base address for the EEPROM
       e.  File.hdf - directories for hdf file

 

Results of the successful command execution:

Converting cgs file to hex file success.jpg
Figure 27: Converting cgs file to hex file success

 

Downloading the hex file

The following procedure downloads the hex file:


1.  Using command-line interface, run chipload.exe.
2.  Use the following command


       a.  ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER
       b.  Example Below: ./chipload.exe –BLUETOOLMODE –BAUDRATE 11520nfc –PORT COM16 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20737_EEPROM.btp


3.  Definitions of parameters:


       a.  COM16 – connected port as connected thru enumeration
       b.  btp_file.btp – btp file for the TAG Board
       c.  Output_file_name.hex – converted hex file.
       d.  btp_file.btp – btp file for the TAG

  1. minidriver - Loads the Hex file into EEPROM or SFLASH image.

     - The MiniDriver uses P1 as the Write Protect Pin

     - If you use a different pin for Write Protect, then the MiniDriver will NOT work.

     - MiniDriver is specific to the P1 Write Protect Pin because it is driven LOW before Writing begins.

  1. f.   Chipload.exe - Runs the MiniDriver and does the CheckSum

     - Chipload loads the image and does the CRC

     - If it returns "0", it PASSES

     - If it returns "1", it will PRINT the errors that were encountered

 

Results of the successful command execution:

Hex File Command Success.jpg

Figure 28: Hex File Command Success

 

Results of the successful hex file download execution:

 

Download is completed successfully.jpg

Figure 29: Download is completed successfully

Hex File and BD_ADDR and Descriptions in Development

 

The WICED SMART SDK build process allows the programming of the BD_ADDR.

Below are the following steps:

  1. The SDK is able to program some of the BD_ADDR bytes with random values or
  2. The user can edit Platforms/BCM920737ATAG_Q32/20737_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
  3. To use random address set DLConfigBD_ADDRBase = "20737A1*****" where every “*” will be replaced with a random value.

 

SDK 2.0 HDF File Changes

 

The WICED SMART SDK 2.0 .hdf file is now in binary form.

 

This is a departure from the SDK 1.1 hdf that supported a superset of features that do not apply to the current device enhancements.

 

 

PART 2: Process for BD_ADDR Manufacturing Programming - Using SDK

 

The WICED SMART SDK build process allows the programming of the BD_ADDR.

Below are the following steps:

 

1.  The SDK is able to program some of the BD_ADDR bytes with random values or

2.  The user can edit Platforms/BCM920737ATAG_Q32/20737_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.

3.  To use random address set DLConfigBD_ADDRBase = "20737A1*****" where every “*” will be replaced with a random value.

 

 

Ex: DLConfigBD_ADDRBase = “20737A1*****”

 

1.  Previously in 1.1 this was the same Random Address on all computers.
2.  Now it is random per computer that you use.
3.  If you have 2 computers, it will generate 2 different Random addresses.
4.  Everyone in your development team downloads on different computers, everyone will get different addresses.
5.  However, in Development, the same bluetooth address when you reload the application.
6.  Programing multiple boards on the same computer you will get the same address.
7.  In the BUILD target say Device BD_ADDR = BD_ADDR or
8.  Device BD_ADDR = Random and Make will generate a random number.
9.  Each “*” is a random nibble – so you can place the “*” in the middle and have *1234.
10. Example:

      a. Programming 4 devices on the same PC.

11.  BD_ADDR goes into a file that the application does not have access.
12.  It is loaded into a completely different sector
13.  We can include it in one of the build targets to show users the option is there.

 

ARvind_MakeFile_BT_DEVICE_ADDRESS.png


14.  You want your board to have a specific BD_ADDR:

           a.  You can modify the Make Target:

           b.  For instance in i2c_temperature_sensor-BCM920737TAG_Q32 download:

 

Arvind_Specific_Board_Address.png

 

           c.  You can assign 6 bytes in Hex to the Target Name - In this case we used 20736 instead of 20737:

Arvind_6_Bytes_In_Target_Name.png

 

           e.  Here we did BT_DEVICE_ADDRESS=20736A112345

           f.  This is in the Quick Start Guide The specified item was not found. on the Make Target

           g.  Or you can put BT_DEVICE_ADDRESS=random

           h.  This will be random every time we do a build.

           i.  So this may be a good option for the user INSTEAD of the cgs.exe

           j.  The *.btp file paramters that you can change:

               - ConfigDSLocation – Dynamic Section – This is where the code and the Config is stored
               - DLConfigVSLocation =  is where your Link Keys are stored
               - We need 1K for at least 5 devices paired at the same time – Takes up 600 bytes.  And this is all in EPROM Layout

 

Hex File and BD_ADDR and Descriptions in Production

 

1. The WICED SMART SDK build process produces 2 hex files.

2. What is downloaded in the factory during mass production is the factory <app_name>-<platform>-rom-ram-Wiced-release.hex

3. The SDK uses this when your target, in our case the BCM20737S SPIL Module, uses ‘download’ or ‘recover’ in the make file.

4. This is the factory image and includes the BD_ADDR.

5. The SDK and will program some of the BD_ADDR bytes with random values or

6. The user can edit Platforms/BCM920736ATAG_Q32/20736_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.

7. To use random address set DLConfigBD_ADDRBase = "20736A1*****" where every “*” will be replaced with a random value.

 

Please feel free to post comments and questions.

 

JT

Programming the 20732S MODULE USING 2073xTAG Board v. 1.0

 

RevisionChange DecriptionDate
1.3

TTL-232RG-VREG3V3-WE - defined correct cable with 3V Output

Removed SPIL, Added NEW Loader file and LOTS of corrections

04/03/15
1.4

Corrections to Switch settings, correct Loader zip files for TAG2, TAG3

04/10/15

1.5Example for command line programming of Serial FLASH01/18/16
1.6

 

Section 1: Overview

Introduction

 

This application note describes two recommended procedures of programming the Broadcom  BCM2073xTAG board.

 

Programming the TAG2 (BCM20732 device)

The programming procedure utilizes the Broadcom WICED-Smart-SDK-1.1.0-IDE-Installer that may be downloaded from our Broadcom WICED Community site - WICED-Smart-SDK-1.1.0-IDE-Installer

 

Programming the TAG3 (BCM20737 device)

The programming procedure utilizes the Broadcom WICED-Smart-SDK-2.2.0-IDE-Installer that may be downloaded from our Broadcom WICED Community site - WICED-Smart-SDK-2.2-IDE-Installer (Windows)

 

 

The production environment rarely allows for the compete SDK at the programming station and Broadcom has enabled

programmability utilizing a command line utility loader program that may be downloaded from the attachment below.

 

The following sections describe the BCM2073xTAG programming procedure:

 

Section 1: “Overview,” lists the links for the SDK.


Section 2: “BCM20732TAG Setup: Component/Switch Locations,” contains the setup.


Section 3: “BCM2073xTAG Setup: Component/Switch Locations,” contains the setup.


Section 4: “USB Connection to the PC,” describes the USB enumeration preparation process.


Section 5: “Setup for Command Line Programming.

 

Section 6: "Command Line Programming Procedure using the Loader.exe,” describes the Command Line Tool.


Section 7: “Hex File and BD_ADDR Configurations in Development and Mass Production", describes engineering development of BD_ADDR and Final Configuration for Mass Production.

 

 


Section 2: BCM20732TAG Setup:

Component/Switch Locations BCM20732/BCM2073x TAG Board Configuration

 

Procedure:

1.  BCM20732TAG - Locate the SW2 and SW3 Pins on the Board

 

Figure 1: BCM20732 TAG2 Switches and Buttons

Fig_1_BCM20732TAG Switches and Buttons.png


2.  BCM20732TAG - Place the SW2 and SW3 to the UP Positions as shown:

 

Figure 2: BCM20732 TAG2 SW2 and SW3 Up Positions
Fig_2_BCM20732TAG SW2 and SW3 Up Positions.png


3.  BCM20732TAG - All Dip switches should be in the ON(Up) Position as shown below:

 

Figure 4: BCM20732 TAG2 4 Pin Switch Settings


4.  BCM2073xTAG - Place the Dip Switch positions 2 and 4 to the OFF(Down) Position as shown:

 

 

 


Section 3: BCM2073xTAG Setup: Component/Switch Locations

BCM2073xTAG Board Configuration

 

Procedure
1.  Locate the SW3 and SW3 Pins on the BCM20737TAG Board


Figure 6: BCM20737TAG Switches and Buttons

 

BCM2073xTAG Switches and Buttons.png


2.  Place the SW2 to UP Position and SW3 to the DOWN Position as shown:

 

Figure 7: BCM20737TAG SW2 Up and SW3 Down Positions

BCM20732TAG SW2 Up and SW3 Down Positions.jpg

3.  Locate the Dip Switch on the TAG Board

 

Figure 8: BCM20737TAG Dip Switch

BCM2073xTAG Dip Switch.png


4.  Place the Dip Switch positions should be in the ON(Up) Position as shown below:

 

Figure 9: BCM2073xTAG3 4 Pin Switch Settings

 

 

 

 

 

Section 4: USB Enumeration Connection to the PC
USB Enumeration of the BCM2073xTAG Board

 

The BCM2073xTAG board must be enumerated by the Programing PC.  The FTDI chip on the TAG Board will enumerate the device on the Device Manager under the Ports Section as shown below:

 

Figure 10: Sample COM Port before 20732TAG USB Insertion

 

Sample COM Port before 20732TAG USB Insertion.jpg

Procedure
1.  Open up the Device Manager in the Control Panel as shown above.

 

2.  Insert the USB Cable (Connected to the USB Port on the BCM2073xTAG board) to enumerate the Device Driver for the FTDI chip on the Board.


a.  The BCM20732TAG board uses the FTDI TTL-232RG-VREG3V3-WE USB to Serial Cable - you MUST get the 3V output.

 

(http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm)

 

 

Figure 11: Correct FTDI Cable


b.  This enables the programming of the BCM2073x devices without the need for a JTAG Interface


c.  Note that Serial Wire Debug (SWD) debug/trace messages can also be output through the HCI UART port that’s onboard.


d.  The SWD pins are muxed with HCI UART and are used in such a manner that the hardware and firmware can auto-detect the presence of SWD or the HCI host


e.  This means that HCI based download (programming) and SWD (debugging) are mutually exclusive of one another.


3.  In order to use the onboard UART header and a TTL-232RG-VREG3V3-WE USB to Serial cable to program your custom board, you would need to do the following:

a.  With the BCM20732S board powered down, connect the TTL-232RG-VREG3V3-WE USB to Serial Cable to your PC (USB) then to the UART header on your board: RXD, TXD, VBAT and GND respectively.

b. Power your board up while making sure that RXD is held high during power up. Note that by default this pin is pulled low through an internal 10k ohm resistor

c. Program the board using the Broadcom IDE just as you would if a BCM20732S Tag board were connected.


4.  As an example, the BCM2073xTAG board has been enumerated as COM16 as shown below:


Figure 12: Sample COM AFTER 2073xTAG USB Insertion – COM16 Enumerated

 

Sample COM AFTER 2073xTAG USB Insertion – COM16 Enumerated.jpg


If you’re not familiar with the installation of the drivers for your TAG board, refer to the WICED Smart™ Quick Start Guide found in the ~Docs folder of the SDK.

 

Section 5: Programming

 

 

Section 5.1: Software Programming Setup

 

Broadcom BCM20732x devices are be programmed using either the SDK Developer’s Tools or by using a command line tool called loader.exe.

 

The Loader directory of files to download can be found as an attachment at the bottom of this BLOG.

 

The SDK combined with the BCM2073xTAG Board provide the developer a convenient methodology for programming the BCM2073x or BCM2073xS Modules discussed below or for the developer’s Pre-Production Board.

 

To prepare the Production Board for Mass Production programming, the Loader command line tools provide a convenient process to automate the programming at a contract manufacturing facility or at a distribution programming center.

 

You will also need the ChipLoad.exe file attached at the bottom of this BLOG.

 

Section 5.2 System Programming Tools Setup:

 

The programming ecosystem of the BCM2073x/BCM2073xS devices involves the use of executable files both compile and produce necessary files for use in programming the modules.

 

The first file needed is the cgs.exe file to enable the board address (BD_ADDR) programming at the time of production.

 

The cgs.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\CGS\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at the bottom of this BLOG.

 

Figure 13: Location of cgs.exe

 

Location of cgs exe.png

The second file needed is the chipload.exe file to download the programming file to the programmer at the time of production.

 

The Chipload.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\ChipLoad\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at the bottom of this BLOG.

 

Figure 14: Location of ChipLoad.exe

Location of ChipLoad exe.png


The cgs file can also be edited in the SDK Build window as shown below:


The third file needing editing for programming is the EEPROM file BCM2073xAx.cgs file.  The cgs file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x/build/hello_sensor-BCM*_Q32-rom-ram-Wiced-release/A_*-hello_sensor-rom-ram-spar.cgs as shown below.

 

This is the file uses to program the EEPROM with the customer application.


Figure 15: Location of 20737_EEPROM.cgs file

 


The fourth file needing editing for programming is the EEPROM file 2073x_EEPROM.btp file.

 

The btp file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Platforms\BCM2073xTAG_Q32) as shown below.

 

This is the file uses to program the EEPROM with the customer application.

 

Figure 16: Location of 2073x_EEPROM.btp file

Location of 2073x_EEPROM btp file.png

 

Section 6: Command Line Programming Procedure using the Loader.exe

Using the Loader Software Command Line Tools

 

The Loader Software tool utilizes a Command Line Tool to call the appropriate programming files to program the same BD_ADDR programming as the SDK Tool Chain, but in used in the volume programming environment.

 

Programming Procedure using Cygwin utility

 

The Cygwin Utility can be found at: http://www.cygwin.com/install.html  is used to execute the Loader commands and accesses the appropriate configuration files used in the programming procedure.

NOTE: Cygwin is a 32GB file that takes time to download and install

 

Below is an example of using Cygwin to execute the Loader command line utilities.


Please observe the highlighted files described previously:


Figure 17: Contents of Loader.zip file at bottom of BLOG

 

Figure 18: Cygwin BCM2073x File Location

 

 

 

NOTE: You need to move the files highlighted above into the cygwin\home\<your name>\ directory under Cygwin.

 


Section 6.1 Converting cgs file to hex file

 

The following procedure converts the cgs file to a hex file:


1.  Using Cygwin Tools installed above, type the following command:


a.  ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>

Note: -D refers to a different directory


b.  Example below:

./cgs.exe –I output.hex –A 0xFF000000 –B 20732_TAG32_EEPROM.btp –D . A_20732A0-bleprox_mod-rom-ram-spar.cgs


3.  Definitions of parameters:


a.  output_file_name.hex – will be the converted hex file.
b.  btp_file.btp – btp file for the 2073x_TAG board.
c.  input_file.cgs – built cgs file for the application from  the SDK
d.  0xFF000000 – base address for the EEPROM
e.  File.hdf - directories for hdf file

 

Results of the successful command execution:


Figure 19: Converting cgs file to hex file success

Converting cgs file to hex file success.jpg

Section 6.2 Downloading the hex file

The following procedure downloads the hex file:


1.  Run chipload.exe using the following command:


a.  ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER
b.  Example Below:

./chipload.exe –BLUETOOLMODE –BAUDRATE 115200nfc –PORT COM16 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20732_TAG32_EEPROM.btp


3.  Definitions of parameters:


a.  COM16 – connected port as connected thru enumeration
b.  btp_file.btp – btp file for the TAG Board
c.  Output_file_name.hex – converted hex file.
d.  btp_file.btp – btp file for the TAG

e.  minidriver - Loads the Hex file into EEPROM or SFLASH image.

     - The MiniDriver uses P1 as the Write Protect Pin

     - If you use a different pin for Write Protect, then the MiniDriver will NOT work.

     - MiniDriver is specific to the P1 Write Protect Pin because it is driven LOW before Writing begins.

 

f.   Chipload.exe - Runs the MiniDriver and does the CheckSum

     - Chipload loads the image and does the CRC

     - If it returns "0", it PASSES

     - If it returns "1", it will PRINT the errors that were encountered

Results of the successful command execution:

 

Figure 20: Hex File Command Success

 

 

Hex File Command Success.jpg

Results of the successful hex file download execution:


Figure 21: Download is completed successfully

 

Notes:

The key to programming procedure is to know the state of the device:

1.  If device has never been programmed OR device is in recovery mode:
    - Add –NODLMINIDRIVER to chipload.exe

2.  If device has been successfully programmed before AND it is not in recovery mode:
    - Do *not* add –NODLMINIDRIVER to chipload.exe

3.  If in doubt, always use recovery mode.

 

The following example shows the command line for programming Serial FLASH:

 

jtate@LTSDO-JTATE /cygdrive/c/cygwin/home/jtate

$ ./chipload.exe -BLUETOOLMODE -PORT COM100 -BAUDRATE 115200nfc -MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex -CONFIG output.hex -BTP 20737_SFLASH.btp

Download minidriver successfully had written 251 bytes to address 0x0020AF00

Download minidriver successfully had written 251 bytes to address 0x0020AFFB

Download minidriver successfully had written 251 bytes to address 0x0020B0F6

Download minidriver successfully had written 251 bytes to address 0x0020B1F1

Download minidriver successfully had written 251 bytes to address 0x0020B2EC

Download minidriver successfully had written 251 bytes to address 0x0020B3E7

Download minidriver successfully had written 251 bytes to address 0x0020B4E2

Download minidriver successfully had written 251 bytes to address 0x0020B5DD

Download minidriver successfully had written 251 bytes to address 0x0020B6D8

Download minidriver successfully had written 251 bytes to address 0x0020B7D3

Download minidriver successfully had written 251 bytes to address 0x0020B8CE

Download minidriver successfully had written 251 bytes to address 0x0020B9C9

Download minidriver successfully had written 251 bytes to address 0x0020BAC4

Download minidriver successfully had written 251 bytes to address 0x0020BBBF

Download minidriver successfully had written 251 bytes to address 0x0020BCBA

Download minidriver successfully had written 251 bytes to address 0x0020BDB5

........

Download config successfully had verified 167 bytes at address 0xFF004B58:  78 25 30 38 58 2C 20 55 47 20 6C 65 6E 67 74 68 3A 20 30 78 25 30 38 58 00 0D 75 70 67 72 61 64 65 20 63 6F 6D 70 6C 65 74 65 2C 20 70 65 72 66 6F 72 6D 20 72 65 73 65 74 00 49 6E 76 61 6C 69 64 61 74 65 64 20 4F 6C 64 20 53 53 2E 00 0A 4C 00 BC 9E 20 00 0A 48 0B 49 08 B5 88 42 02 D0 0A 4A 35 F6 4C FE 00 22 09 49 09 48 35 F6 8D FE 09 4A 09 4B 22 F0 0F 02 1A 60 BD E8 08 40 FE F7 B4 BB 60 9A 20 00 60 9A 20 00 00 00 00 00 5C 04 00 00 60 9A 20 00 DC 9E 20 00 50 0F 20 00 0B 04 00 BD 9E 20 00 FE 00 00
Chip reset to address 0x00000000 succeeded
Downloaded 0 code bytes ( 0.0%) and 18279 data bytes (100.0%). Verified 0 code bytes ( 0.0%) and 18279 data bytes (100.0%).   Current state: Completed successfully

A total of 2 contiguous memory areas were filled:
[FF000000..FF000027] DATA (40 bytes)
[FF0004C0..FF004BFE] DATA (18239 bytes)

 

Section 6.3 Hex File and BD_ADDR and Descriptions in Development

 

 

The WICED SMART SDK build process allows the programming of the BD_ADDR.

Below are the following steps:

 

1.  The SDK is able to program some of the BD_ADDR bytes with random values or

2.  The user can edit Platforms/BCM920736ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.

3.  To use random address set DLConfigBD_ADDRBase = "20736A0*****" where every “*” will be replaced with a random value.

 

Section 6.4 SDK 2.0 HDF File Changes

 

The WICED SMART SDK 2.2 .hdf file is now in binary form.

 

 

Figure 22: Binary Form of .hdf file

Binary_hdf.PNG

 

 

Section 7 Hex File and BD_ADDR Configurations in Development and Mass Production

 

BCM2073x Design: Using the BCM20736 in SDK 2.2 from the Platforms Directory

 

Figure 23: Binary Form of .hdf file

Arvind_Platform_Specific_Support_Files.png

 

Ex: DLConfigBD_ADDRBase = “20736A1*****”

 

1.  Previously in SDK 1.1 this was the same Random Address on all computers.
2.  Now, in SDK 2.2 it is random per computer that you use.
3.  If you have 2 computers, it will generate 2 different Random addresses.
4.  Everyone in your development team downloads on different computers, everyone will get different addresses.
5.  However, in Development, the same bluetooth address when you reload the application.
6.  Programing multiple boards on the same computer you will get the same address.
7.  In the BUILD target say Device BD_ADDR = BD_ADDR or
8.  Device BD_ADDR = Random and Make will generate a random number.
9.  Each “*” is a random nibble – so you can place the “*” in the middle and have *1234.
10. Example:

      a. Programming 4 devices on the same PC.

11.  BD_ADDR goes into a file that the application does not have access.
12.  It is loaded into a completely different sector
13.  We can include it in one of the build targets to show users the option is there.

 

 

Figure 24: BT_DEVICE_ADDRESS in the Makefile

ARvind_MakeFile_BT_DEVICE_ADDRESS.png


14.  You want your board to have a specific BD_ADDR:

           a.  You can modify the Make Target:

           b.  For instance in i2c_temperature_sensor-BCM920736TAG_Q32 download:

 

Figure 25: _i2c_temperature_sensor selected

Arvind_Specific_Board_Address.png

 

           c.  You can assign 6 bytes in Hex to the Target Name:

 

Figure 26: 6 Bytes assigned to Target Name

Arvind_6_Bytes_In_Target_Name.png

 

           e.  Here we did BT_DEVICE_ADDRESS=20736A112345

           f.  This is in the Quick Start Guide on the Make Target

           g.  Or you can put BT_DEVICE_ADDRESS=random

           h.  This will be random every time we do a build.

           i.  So this may be a good option for the user INSTEAD of the cgs.exe

           j.  The *.btp file parameters that you can change:

               - ConfigDSLocation – Dynamic Section – This is where the code and the Config is stored
               - DLConfigVSLocation =  is where your Link Keys are stored
               - We need 1K for at least 5 devices paired at the same time – Takes up 600 bytes.  And this is all in EPROM Layout

 

Section 7.1 Hex File and BD_ADDR and Descriptions in Production

 

1. The WICED SMART SDK build process produces 2 hex files.

2. What is downloaded in the factory during mass production is the factory <app_name>-<platform>-rom-ram-Wiced-release.hex

3. This is the factory image and includes the BD_ADDR.

4. The SDK and will program some of the BD_ADDR bytes with random values or

5. The user can edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.

6. To use random address set DLConfigBD_ADDRBase = "20732A0*****" where every “*” will be replaced with a random value.

 

NOTES:

1.  ChipLoad.exe loads the hex file into EEPROM or SFLASH depending on your configuration.

2.  Once you generate the .hex file, you know were the BD_ADDR is going to be: Byte 21 offset

3.  Jump to 21 Byte location and then generate the next 6 Bytes for the BD_ADDR and then you are done!

 


Please feel free to add comments and questions and I will update appropriately.

 

Thank you,

 

JT

Filter Blog

By date:
By tag: