The BCM2073x chip (SoC) has 40 logical GPIOs (P0-P39).
The GPIOs themselves are broken out into three separate ports (meaningful when you start programming):
• P0 through P15 on port0
• P16 through P31 on port1
• P32 through P39 on port2
The 32 pin package (i.e. the SoC - BCM20736 and BCM20737 *without* the S) only brings out 14 of the 40 logical GPIOs. The System in Package/SIP (the BCM20736S and BCM20737S modules) follows the SoC closely with regards to which pins are brought out (but there is a slight difference) and these are what you see in the SIP module datasheets.
Since the 32 pin package (SoC) and the modules are pin-limited, some of the logical GPIOs within the SoC are multi-bonded before bringing them out on the balls on the chip.
For the 32 pin package, the following pins are bonded in this manner:
Very Important Note: The SOC packaged part described above is not used for the SIP module. The SIP uses the raw die and wirebonds it differently than the DFN part, so the IOs described above for the SoC are not bonded together from the die - they are bonded together on the DFN wirebond package.
Always refer to the BCM20737S Bluetooth Low Energy SiP Module Technical Reference for the bonding/alternate function information relevant to the SIP modules, not the BCM20737 SOC Data Sheet.
When leveraging the WICED™ Smart Hardware Interfaces for your development, you will run across several GPIO mapping tables in the document that look like this one:
Note here that you can use only one of the GPIOs (noted in black) from each of the vertical rows above. This is what is referenced in the WICED™ Smart Hardware Interfaces as a "group" (all signals must be selected from the same group, which is essentially the table).
All options may not be available in the package used within the SIP module (shown in red). Combinations shown in red text are also not generally available on the BCM20732 TAG. Additional options may be unavailable if they are being used for the peripheral UART interface.
All GPIOs support programmable pull-up and pull-down resistors, along with a 2 mA drive strength except P26, P27, and P28, which provide a 16 mA drive strength at 3.3V supply (this will change as the supply drops and the GPIO pins will sink less current).
The GPIOs are all capable of waking the device from sleep or deep sleep and the application can configure interrupts (both/either edges, level), pull-up/pull-down High-Z, etc.
The following GPIOs are available on the BCM2073XS based SIP Modules (remember, only 14 are brought out on the SIP module):
For unused dual bonded pins, the unused GPIO should be input/output disabled (especially when it is an input).
From the perspective of writing software against the GPIO mappings defined above, it's important to keep in mind that the GPIO is physically mapped to a BCM2073XS device within the platform.h file which is custom to the TAG development board by default.
However, this mapping in platform.h can be reconfigured for a custom design.
The values in platform.h then map to definitions and function prototypes in bleprofile.h
Note that the specific values in the bleprofile.h bitmasks themselves are not intended to be exposed as the code beneath these bitmasks is proprietary and cannot be released for reasons outside the scope of this discussion.
In addition to reconfiguring the mappings of your custom board within the bleprofile.h, GPIO can also be assigned within BLE_PROFILE_GPIO_CFG within the .c file for each application. This is also where you allocate/initialize the GPIO within your application. The bleprofile_xxx() routines are then how you use/access what you have configured above.
With this said, I realize there is some ambiguity in this message as we have documents like WICED™ Smart Hardware Interfaces which clearly states that the BCM2073X (note that this guide was written for the SoC, then modified slightly for the SIP module) includes two sets of APIs that are available for the application: the low-level driver API and the high-level profile API.
So yes, the Low Level API is there and in some cases ok to use, but we are not consistent in exposing everything a developer needs to actually use it effectively on a consistent basis.
Hopefully you guys find this helpful. I know many of you have tidbits to add, so feel free to comment (please stay on topic). I would love to see some examples and code snippets showing usage of the bleprofile_xxx() routines.
Show LessRevision | Description | Date |
---|---|---|
1.0 | I2C Description | 10/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:
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:
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 >> 😎 & 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), ®ister_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;
}
Show Less
Product Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |