cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hi,

I'm trying to find documentation for which GPIOs are bonded together inside of the BCM20737S. So far I've only been able to find the following note that is specific to the BCM20732TAG board, but it says to see the documentation for the module being used I've looked through the BCM20736S and BCM20732S documentation without any luck. I'm actually planning to use the BCM20737S, but there isn't much specific documentation to that part available yet.

Note: All GPIOs may not be available in the package. Some of the GPIOs may be bonded

together inside the package when not all 40 GPIOs are brought out. See the documentation

accompanying the module you are using for more information. On BCM20732TAG boards, the

following pairs of GPIOs are bonded together: P8 and P33, P11 and P27, P12 and P26, P13

andP28, P14 and P38. Only one of the bonded GPIOs from each pair may be used.


Thanks,

Briana

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator

There are internal documents which map the GPIO bondig and external muxing between the SOC and the module, but we do not release these to the public.  Please refer to the datasheet for either the SOC or the module (GPIO is different for each) for GPIO assignments.

View solution in original post

0 Likes
17 Replies
StBa_721356
Contributor

Well, have a look at BCM20737 SOC Data Sheet

Check "Section 2: Pin Assignments" and "Figure 9: 32-pin QFN Ball Map".

There you see all the GPIOs bonded together.

0 Likes
Anonymous
Not applicable

That gives bonding for the BCM2073x device, not the BCM2073xS.  The "S" -- SIP is repackaged die with other silicon inside, and so I'd assume the IO bonding might be different from the SOC package.

Does anyone know what the SIP GPIO bonding looks like?  Is it the same as the SOC? There doesn't appear to be much information about the SIP.

0 Likes
Anonymous
Not applicable

Actually I take back the last comment.  In the SIP hardware guide:

Pin 39 is both P13 and P28

Pin 40 is both P14 and P38

Pin 43 is both P12 and XTAL032K. *When XTALO32K is used, ADC/GPIO:P12 is unavailable but P26 (pin 42) may still be available

Pin 44 is both P11 and XTALI32K.  *When XTALI32K is used, ADC/GPIO:P11 is unavailable but P27 (pin1) may still be available

I'm not sure what the comments (*) mean however - the logical pins P26 and P27 are bonded to other physical pins as well, so are those pins shorted together? How can they both be available otherwise?

Also, I assume that the SIP does in fact have different bonding than the SOC (so we don't have to take the bonding from one and piggyback it to the other..

0 Likes
MichaelF_56
Moderator
Moderator

Logical P27 is Physical Pin 1
This pin defaults to PWM1, but has an alternate function of MOSI (master and slave) for SPI_2

Logical P26 is Physical Pin 42
This pin defaults to PWM0, but has an alternate function of SPI_CS (slave only) for SPI_2

XTALI32K is the LPO input (optional), when used it connects to the dual function P11/XTALI32K (Logical), or Pin 44.

On that dual function pin, if you map it to XTALO32K, P27 will be consumed.If you map it to P11 (other side of the dual function pin), then P27 will be free.

All of the logical pin mappings are controlled in firmware through a series a muxing that abstracts one from the physical pin assignements on the SOC inside the module.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

Can you clarify if your statement above ("On that dual function pin, if you map it to XTALO32K, P27 will be consumed") applies to the SIP as well as the SOC package?

In particular, on our SIP-based design we would like to use a crystal (connected to XTAL032K/pin43 and XTALI32K/pin44) concurrently with GPIO26/pin42 and GPIO27/pin1.  Can that configuration work?

Thanks,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

I think jeremynigh was referring to this?

WICED™ Smart Hardware Interfaces

0 Likes
Anonymous
Not applicable

Hmmm, the word XTAL does not appear at all on that document.

Javier

0 Likes
MichaelF_56
Moderator
Moderator

SIP and SOC GPIO mappings are different as many of the SIP's GPIOs are dual function pins internally muxed inside the module.

Use the SIP Datasheet here: BCM20737S Bluetooth Low Energy SiP Module Technical Reference

As it contains the GPIO configuration for the module.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

Thanks, we used BCM20736S Bluetooth Low Energy SiP Module Technical Reference to guide our design, as it uses that SIP.  There is no mention on that document to any conflicts in using P26,P27 (pins 42, 1) while using the external crystal (pins 43, 44), so we'll assume our design is correct.

We are double checking everything related to the RTC as we have encountered a severe problem when we run rtc_sample.c on our board:  the board becomes unusable, beyond recovery via SDA.  We'll open a separate thread for that as we collect all the details.

Best,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

XTAL.png

I agree that the dual functions pins can be pretty confusing because we deliberately abstract the muxing which is happening inside of the SIP module in hopes that it will make things easier for devlopers.

Based on the screenshot above, my understanding is that physical pins 43 and 44 are used for XTALI and XTALO respectively. You can then access these pins through their logical representation in firmware using P12 and P11 (primary) or XTALO32K and XTALI32K (secondary). When using the secondary mapping in firmware of XTALO32K and XTALI32K, you then loose the ability to a. use the primary function of P11 or P12 or b. the other secondary functions P26 and P27.

So to answer your question, I don't think that using the primary firmware mapping of P12/P11 will conflict with P26/P27 based on this understanding.

I also looked in the default platform.h files for the TAG board that are included within the SDK and niether platform.h files have pins 43 and 44 defined for use within that design.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

I definitely agree with your assessment that "using the primary firmware mapping of P12/P11 will conflict with P26/P27".  But the secondary mapping (XTALI32K,XTALO32K) is the issue here.

I cannot tell from the table you pasted in your last message if configuring pins 43,44 as XTALO32K and XTALI32K (by disabling those GPIOs and invoking rtc_init()) would prevent using pins 42,1 as P26 and P27.

If that was the case, I would expect to see that fact mentioned in the documentation for pins 42 and 1, or elsewhere on that same document.  I suspect this is a documentation error carried over from the SOC datasheet, which does have those conflicts and properly documents them.

Thanks,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

It will NOT conflict based on my assessment: So to answer your question, I don't think that using the primary firmware mapping of P12/P11 will conflict with P26/P27 based on this understanding.

P12/11 logical pins should be fine and not involve P26/P27, which are noted as secondary functions on the noted pins 43/44.

I have to track someone down when everyone returns to the office tomorrow and see if my understanding is correct.

0 Likes
Anonymous
Not applicable

Yes, sorry, pasting error.  Since I can't edit my previous response I'll repost in case someone else reads this:

Hi mwf_mmfae,

I definitely agree with your assessment that "I don't think that using the primary firmware mapping of P12/P11 will conflict with P26/P27".  But the secondary mapping (XTALI32K,XTALO32K) is the issue here.

I cannot tell from the table you pasted in your last message if configuring pins 43,44 as XTALO32K and XTALI32K (by disabling those GPIOs and invoking rtc_init()) would prevent using pins 42,1 as P26 and P27.

If that was the case, I would expect to see that fact mentioned in the documentation for pins 42 and 1, or elsewhere on that same document.  I suspect this is a documentation error carried over from the SOC datasheet, which does have those conflicts and properly documents them.

Thanks,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

jcardona,

As a follow up to the dialog over the weekend, I wanted to update/confirm with you a few items I learned/verified today (I may have to span this across the multiple threads that are open).


Regarding our discussion above of logical pins/GPIOs assigned to the External Oscillator function and any conflicts those pins would have on logical pins P26/P27:

Using the primary firmware mapping of P12/P11 will NOT conflict with P26/P27.  However, if you are using the secondary mappings and calling/configuring the GPIO using XTALI32K,XTALO32K, these will definitely conflict and cause issues.

Please confirm that you are indeed using P11/P12 and not using XTALI32K/XTALO32K.


0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

Thanks for following up.  We are using an external clock connected to XTALI32K/XTALO32K.  We are also using P26 and P27 as a gpio input and output respectively.  So it appears that we will have a conflict with our board if we attempt to use the external clock.

It turns out that we'll need to do another prototype iteration because of this.  I would strongly recommend that Broadcom clearly documents this conflict in BCM20736S Bluetooth Low Energy SiP Module Technical Reference .  Table 2 on that document only mentions 'P27' as an "Alternate function" for physical pin 44, but no mention is made in the description of physical pin 1 (logical P27).

Thanks,

Javier

0 Likes
Anonymous
Not applicable

Hello jeremynigh,

Can you provide the full name of the document you are referring to ("the SIP Hardware Guide")?

I am looking at BCM20736S Bluetooth Low Energy SiP Module Technical Reference and it does not mention any limitation regarding using XTAL(O/I)32K concurrently with P12 and P11.

Thanks,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

There are internal documents which map the GPIO bondig and external muxing between the SOC and the module, but we do not release these to the public.  Please refer to the datasheet for either the SOC or the module (GPIO is different for each) for GPIO assignments.

View solution in original post

0 Likes