I see that on page 16 of your HW Guide, it states: The combinations of pins shown in Table 3 and Table 4 are the only valid options for the four UART signals (Receive – RXD, Transmit – TXD, Clear to Send – CTS and Ready to Send –
RTS). All four signals must be selected from the same group.
My understanding is that Group = same horizontal row of the table, either table 3 or table 4.
For instance: RXD(P2), TXD(P0), CTS(P3) and RTS(P1) is a valid group if those 4 signals are required by the application.
It seems you found that on TAG3 3, three signals used are from the 2nd group (RX, TX, RTS) and one signal is from 1st group (CTS). This contradicts the document and my understanding for sure.
I will need to look into this and get back to you.
I spoke to the SW team and they are not sure how this is possible either.
Question: which application are you using to determine this configuration?
I don't think Group = same horizontal row first because some rows would have incomplete number of signals for example: row 3,4,5 of Table 3 - row 4 of the same table has only TXD (32) - so that means if you pick P 32 for TXD you cannot use any other signals ?
Besides, tables: 3 and 4 are marked "Group 1" and "Group 2" so the whole table makes the group rather than a single row.
In include/Platforms/BCM920737TAG_Q32/platform.h I found this:
#define GPIO_PIN_UART_TX 32
#define GPIO_PIN_UART_RX 33
These are the pins used for TX and RX by sample apps built for TAG3.
Also if you look at the tables there is no single row that has both TX 32 and RX 33 but they are all present in Group 2 (table 4). Problem is that there is no CTS signal available in this group (P35 - marked as read is not available in TAG3).
Does it mean that flow control is not available with TAG 3 ?
This is really confusing.
I know from prior experience that you need to use the available logical pin references available as a single horizontal line in the various tables within this document.
You are correct. A group refers to the entire table, not a single horizontal row.
There are several other threads on this topic. Here's one: Re: Can I use P3, P2, P4 and P25 as SPI master and slave on BCM20732S?
However, the PUART code snippet in that same document shows how to initialize the peripheral UART using the low-level driver API available in the WICED SDK.
// Use P33 for peripheral uart RX.
#define PUART_RX_PIN 33
// Use P32 for peripheral uart TX.
#define PUART_TX_PIN 32
Those pins match what you are observing in the platform file, so I am wondering if the tables in this document apply to the high level API, while this code and the mappings in the platform file apply to the low level API.
Flow control is not available via the PUART interface on the module.