BCM920737TAG puart problem

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

cross mob
Anonymous
Not applicable

Hi,

the puart interface on the TAG doen't function anymore.

I used a Silicon Labs USB bridge to communicate with the TAG over puart, but now the RxD pin of the TAG (P8/P33) stay LOW.

I'm sure the TxD pin of my USB bridge works, on the oscilloscope the signal stay HIGH until I connect it withe the TAG, then it goes down.

How can I solve that problem?

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

So you are using the TAG3 development board connected to a PC with the USB cable?  Recall that the TAG3 board leverages an onboard FTDI USB to Serial SOC with a driver that should have been installed when you installed the SDK. If not, the driver can also be found in the SDK under the /WICED-Smart-SDK/Drivers/dpinst.exe.

To confirm operation of the PUART use the procedure discussed here to route traces to the PUART: Re: how to direct traces to puart

If you still experience problems with the PUART on the TAG3 board within the recommended development environment described above, you may want to initiate the recovery process defined in the WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board)

If this is a scenario where you are trying to develop a custom interface to the board using a Silicon Labs bridge that we have never tested on the PUART, support may be limited for this type of application.

/WICED-Smart-SDK/Apps/uart_firmware_upgrade is where most customers start in these types of custom scenarios.

0 Likes
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

Pin 24 of the SOC (P8/P33) is double bonded and typically used as the Peripheral UART RX pin.

Is it possible your application code has re-configured the pin as an output and is now asserting it low?   Can you reset / recover the application firmware to known-good demo sample that doesn't have any modifications to it?

0 Likes

Good point santol.

The dual bonded pins are described here: BCM2073XS GPIO Basics

0 Likes
Anonymous
Not applicable

At the moment it works again with an external Silicon Labs USB bridge,

but my target is to comunicate instead with a host controller (Freescale Kinetis) over PUART, and the problem remains the same. The Kinetis controller can receive Data but the Broadcom controller put the RxD pin down so the Kinetis can not send Data.

0 Likes
Anonymous
Not applicable

Hello siano

Are you using Serial FLASH?  P33 is used by Serial FLASH and there would be a conflict.

RxD is an input so is it being driven by something else?

JT

0 Likes
Anonymous
Not applicable

The only way to communicate with an external host controller is to put a 10K pullup resistor on the PUART_RX pin of the Broadcom controller, like the note from the ACKme design guideline (picture attached...)

PUART_connection.jpg

It's sad that I couldn't find support on this forum / broadcom datasheets about these issues.

Now the problem is that I can not use a fast Baudrate, as the PUART_RX signal is distorted (maybe through the pullup resistor ?).

In my system I can go up to 57600, at 230400 I only receive 50% of the data.

(please look at the attached scope picture of the PUART_RX signal)

How can I eliminate this distortion????

PUART_TX_Baudrate_230400.jpg

0 Likes

The maximum baud rate supported by this interface is 115200 bps (other standard baud rates such as 19200, 38200, 57600 are also supported).

WICED™ Smart Hardware Interfaces

0 Likes
Anonymous
Not applicable

You wrote:

"The developers confirmed that there shouldn't be an issue as the PUART was tested with/out HW flow control up to 1.5M." ( PUART RTS/CTS Hardware Flow Control)

At 115200 the signal looks also distorted:

PUART_RX_Baudrate_115200.jpg

Data packets received in my system at 115200 : 94%, at 57600 : 99% at 230400 : 55%

so in the end I can not use a baudrate faster then 57600 probably because of this distortion...

If anyone has another suggestion I will appreciate.

0 Likes

We will check with the developers today on two items:

1.

The "should work" nature of the PUART working at 1.5M.  I agree that they told me this is possible and it was posted to another thread, but all of the documentation clearly lists 115200 as the upper end.

2.

The distortion observed and whether or not this distortion could be caused by the pullup that ACKme recommends in their documentation for PUART_RX.  madmax jasonrc chadoneill ndutton

0 Likes
Anonymous
Not applicable

Hello siano,

1.  We confirmed internally there is no need for a pull-up/pull-down on either PUART pins so none are recommended.

2.  Are you possibly in sleep mode? - The PUART would not work in that case.

3.  You can TX at 1.5M with the limitation of 15 bytes if your peer device can handle this speed without flow control

4.  At 1.5M, you are filling up the FIFO faster so that you may be losing bytes.

Thanks,

JT

0 Likes
Anonymous
Not applicable

The pull up on that pin is only needed when the module is asleep.  Without that pull up the any noise on the ios will wake the chip up.  I believe it is due to the keyboard scanning hardware in the chip.

0 Likes

I think you are referring to the P0 pullup noted here that is needed to prevent keyscan from bringing the part out of sleep: How does P0 and keyscan affect deep sleep?

The alternate functions for pin 28/P0 include:

• A/D converter input

• Peripheral UART TX (PUART_TX)

• MOSI (master and slave) for SPI_2

• IR_RX

• 60Hz_main

0 Likes
Anonymous
Not applicable

That is correct.  I only found it after trying to get the BCM20737 down to less than 2uA during sleep.  Without this resistor it would sit anywhere from 30 to 200uA and wake up by just touching the UART TX  with a finger or oscilloscope probe.

This was done using one of our AMS001 Bobcat modules with no other IO connections to ensure there was no phantom powering via other IO connections.

This however does not have anything to do with the initial uart speed issues. I am sure a larger resistor will work just as well.  I didnt experiment what the max value can be.

0 Likes
Anonymous
Not applicable

1. In my code the sleep mode is disabled because of the data transfer:

// Callback called by the FW when ready to sleep/deep-sleep. Disable both by returning 0 when data transfer.

UINT32 puart_device_lpm_queriable(LowPowerModePollType type, UINT32 context)

{

  return 0; // Disable sleep.

}

2. A baudrate of 115200 would be ok but it's to distorted for my system, and it does't work without pull-up!

0 Likes
Anonymous
Not applicable

Hello siano

Can you get this working on the TAG3 Board?

Can you provide the PUART portion of your schematic?

Thanks

JT

0 Likes