Can't get P_UART to work with BCM20736S module

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

cross mob
Anonymous
Not applicable

Hello everybody,

I'm stuck with getting P_UART to work with a custom PCB containing the BCM20736S BLE-module and a Cortex-M4-MCU. Both UARTs are connected to the Cortex-M4, I'm perfectly able to get the BLE-module to reset, run and enter programming or recover mode via the M4. I am also able to send data via the M4's UART to the BLE-module.

Connections are as follows:

HCI_UART_RX and _TX are connected to high impedance ports of the M4 and a FTDI-USB-Serialbridge. Programming and tracing is working.

GPIOs P0 (P_UART_TX) and P2 (P_UART_RX) are connected to a UART's RX and TX pin of the M4 respectively. But the BLE-module won't send a byte (or receive one for that matter) via P_UART.

I changed platform.h defines to accomodate the different hardware:

#define GPIO_PIN_UART_TX   0
#define GPIO_PIN_UART_RX   2

For easy testing I used the code of puart_control but no luck. I need a connection with a baudrate of 115200, 8N1, no flow control (these pins are used for internal EEPROM on the BCM20736S module).

I removed the GPIO_PIN_BUTTON and even GPIO_PIN_WP and set them to -1 in the gpio_cfg - still no joy.

I then issued a puart_enableTx() in the init function to no avail.

Best regards

Hannes Baumgart

0 Likes
1 Solution
Anonymous
Not applicable

Hi together,

I tested all GPIOs and the P_UART on an evaluation board with the BCM20736S SiP.

Sadly P_UART seems only to work on pins P32 and P33, I couldn't change these pins. Luckily we were already making an adapted board so this could be changed.

While testing the GPIOs I noticed that P0 doesn't seem to work at all with the module so I avoided using it during the redesign.

Best regards

Hannes Baumgart

View solution in original post

0 Likes
5 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

The good news is that you have the HCI UART working and programming your custom board.  This is the UART most customers have issues with when initially bringing up their own board.

Where I see many customers struggle with the PUART is running it at higher baud rates and the port losing data based on the lack of flow control. Since it's a simple UART implementation, basic connectivity between the external processor and the part over PUART is normally straight forward.

Above you state that "I am also able to send data via the M4's UART to the BLE-module."

How is this being accomplished?  SPI or I2C as the PUART seems to be where the issue lies?

Have you tried the UART_Firmware sample app?  It's a bit simpler and may be a better place to start.   Also, do you have a TAG3 eval board you can use for comparison purposes?  Is the part in application mode when you are trying to access the PUART?

I'm guessing the issue is somewhere in the software/platform.h configuration, which is why it may be best to start with a working sample then start adding customizations.

david_armour

0 Likes
Anonymous
Not applicable

Hi David,

thank you for your reply and especially for your optimism:

The good news is that you have the HCI UART working and programming your custom board.  This is the UART most customers have issues with when initially bringing up their own board.

You're right, there are already some things working. But there will be a new hardware revision, so I'm in a bit of a hurry.

Where I see many customers struggle with the PUART is running it at higher baud rates and the port losing data based on the lack of flow control. Since it's a simple UART implementation, basic connectivity between the external processor and the part over PUART is normally straight forward.

Above you state that "I am also able to send data via the M4's UART to the BLE-module."

How is this being accomplished?  SPI or I2C as the PUART seems to be where the issue lies?

To clearify this: I can see the bits on the trace that connects the M4's UART TX line to the GPIO_P2 of the BCM20736S and I'm able to read the data that's sent with a FTDI-USB-serial-chip. I2C hasn't been tested, because I was careful not to interrupt communication with the internal EEPROM, so the M4's I2C interface is configured as High-Z inputs. SPI isn't connected to the main MCU, but maybe this could be done for the next revision if there are SPI peripherals left.

I can't see any activity on the module's P_UART TX line with the oscilloscope.

Have you tried the UART_Firmware sample app?  It's a bit simpler and may be a better place to start.   Also, do you have a TAG3 eval board you can use for comparison purposes?  Is the part in application mode when you are trying to access the PUART?

I'm guessing the issue is somewhere in the software/platform.h configuration, which is why it may be best to start with a working sample then start adding customizations.

I'll try to get debugging working first, as traces aren't enough to tackle the problem. After that I'll give the BCM920737TAG a spin with the UART sample app.

It should enter application mode automatically after downloading or recover, right? I'll try it without serial adaptor, but I can discover the part with the WICED Smart Explorer on my Android device.

Best regards

Hannes Baumgart

0 Likes
Anonymous
Not applicable

Hello everybody,

I experimented with the uart_firmware_upgrade example and the Broadcom BCM920737TAG-03 Development System.

If I switch back to P32 and P33 I can send a byte with puart_write in the hello_sensor_timeout routine.

Sleep mode is disabled, by the way. It looks like the trace messages stop after some time, if I'm not connected to the HCI-port.

To change GPIO_PIN_UART_TX and _RX to P0 and P2 are there more things to consider besides platform.h and hello_sensor_gpio_cfg?

Thanks in advance!

Best regards

Hannes Baumgart

0 Likes
Anonymous
Not applicable

Hello Hannes,

If you are using the TAG3, you have to use P32 and P33.

Thanks

JT

0 Likes
Anonymous
Not applicable

Hi together,

I tested all GPIOs and the P_UART on an evaluation board with the BCM20736S SiP.

Sadly P_UART seems only to work on pins P32 and P33, I couldn't change these pins. Luckily we were already making an adapted board so this could be changed.

While testing the GPIOs I noticed that P0 doesn't seem to work at all with the module so I avoided using it during the redesign.

Best regards

Hannes Baumgart

0 Likes