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 The specified item was not found.
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.
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?
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.
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...)
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????
"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:
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.
We will check with the developers today on two items:
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.
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.
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.
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
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.
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!