Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Resource Library

BCM2073XS GPIO Basics

MichaelF_56
Moderator
Moderator 250 sign-ins 25 comments on blog 10 comments on blog
Moderator

BCM2073XS GPIO Basics

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:

  • P8 and P33 (only one of two is available)
  • P11 and P27 (only one of two is available)
  • P12 and P26 (only one of two is available)
  • P13 and P28 (only one of two is available)
  • P14 and P38 (only one of two is available)

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:

gpio1.png

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):

  • P8/P33 (Dual bonded, only one of two is available)
    Change per information received on 4/28/15: our packaging facility confirmed that P8 and P33 are both available and that on the SIP they are not dual-bonded
  • P13/P28 (Dual bonded, only one of two is available)
  • P14/P38 (Dual bonded, only one of two is available)
  • P12/P26 (Dual bonded, only one of two is available)
    Change per information received on 4/28/15: our packaging facility confirmed that P12 and P26 are both available and that on the SIP they are not dual-bonded
    - P12 if not used as P26 or external 32KHz LPO; If used as 32KHz LPO, then P12 and P26 are unavailable
    - If external 32KHz OSC is used then P12 is not available, but P26 is available
  • P11/P27 (Dual bonded, only one of two is available)
    -P11 if not used as P27 or external 32KHz LPO; If used as 32KHz LPO, then P11 and P27 are unavailable
    - If external 32KHz OSC is used then P11 is not available, but P27 is available

For unused dual bonded pins, the unused GPIO should be input/output disabled (especially when it is an input).

gpio1.png

gpio2.png

gpio3.png

gpio4.png

gpio5.png

gpio6.png

gpio7.png

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.

Comments
Anonymous
Not applicable

In looking at the 20737S data sheet, it appears that GPIOs P8 and P33 do actually come out to independant pins on the 48 pin SIP package. ( gpio4.png)

So, am I correct in understanding that even though they are brought out to separate pins, they are still bonded and I can only use 1 at at time?  If this is the case, why even use/mention P8 since P33 has a super-set of functionality compared to P8?

Similar question for the the P11/P27 pair.  Even though P27 is brought out to an independant pin, pin 1, if pin 44 is used as LPO, P27 in unusable on pin 1?  (Same situation applies for the P12/P26 pair with pins 42 and 43)

MichaelF_56
Moderator
Moderator 250 sign-ins 25 comments on blog 10 comments on blog
Moderator

I honestly cannot speak to the decisions that were made when creating the SIP module.

I do know that the for the following dual bonded pins:

  • P8 and P33
  • P10, P11, P27 and 32 KHz xtal in
  • P12, P26 and 32 KHz xtal out
  • P13 and P28
  • P14 and P38

You can only use one of the functions listed in each of the horizontal rows.

MichaelF_56
Moderator
Moderator 250 sign-ins 25 comments on blog 10 comments on blog
Moderator

Regarding the use of P0 as a GPIO:

Essentially, P0 is part of a keyscan matrix (an artifact from the core HID design 20730 that these 2073X follow-on chips are based on).


As such, the part via P0 is looking for a keypress which is a low (i.e. ground).  Trying to use this GPIO in an application can lead to trouble, so it is advised to pull P0 high. Then, before entering deep sleep, the app must input and output disable P0 using gpio_configurePin(0,0,GPIO_INPUT_DISABLE | GPIO_OUTPUT_DISABLE,0);


For instance, if the application tried to use P0 to try to turn off the device. The device would start to go into deep-sleep, and then if this occurred at the same time as the keyscan operation (cannot be disabled), the part would detect this as a keypress and would abort the sleep operation.

Again, pull P0 high and then, before entering deep sleep, input and output disable P0 using gpio_configurePin(0,0,GPIO_INPUT_DISABLE | GPIO_OUTPUT_DISABLE,0).

MichaelF_56
Moderator
Moderator 250 sign-ins 25 comments on blog 10 comments on blog
Moderator

Important Note:

If the peripheral UART (PUART) is also being used by the application, the SPIFFY2 signals and peripheral UART RX signal must be on the lower pad bank (P0 through P7) or on the upper pad bank (P24 through P39). Thus, SPIFFY1 or SPIFFY2, and peripheral UART RX, cannot be on two different pad banks.

Please reference the tables in the WICED™ Smart Hardware Interfaces​ guide for usable combinations.

Version history
Revision #:
1 of 1
Last update:
‎Dec 17, 2014 06:36 PM
Updated by:
 
Contributors