TM4C1294NCPDT: Interfacing with Xbee

Bob,

We have a switching regulator outputting 3.3V to both the TM4C and the xbee module. We've also tried powering the uC while holding the xbee in a sleeping condition and then waking it up and the same problem happens.

We will try it with the resistor though and report what happens.

David Moore53 said:

...initialize the TM4C TX/RX lines as GPIOs and write them to a high state

Would not that insure an, "Output to output" conflict - with (both) the Xbee & TM4X  driving their (now connected) outputs?    That cannot be good.  (i.e. Data Contention central!)

Have you considered a pull-up resistor on the TM4C's UART_RX line?

It would also be wise to repeat this test on a 2nd MCU board...

So we've tried different pull-up resistors (strong and weak) and the same problem persists. We reset the code to just initializing the UART1 module then setting the pins as UART.

	//Enable Port C as UART1 and specify GPIOC as UART
	//This UART is used to connect to the XBee module
	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

	//Configure GPIOC Pin 4 as RX and GPIOC Pin 5 as TX
	//GPIO Pin type set as UART at Pin 4 and Pin 5
	GPIOPinConfigure(GPIO_PQ4_U1RX);
	GPIOPinConfigure(GPIO_PB1_U1TX);
	GPIOPinTypeUART(GPIO_PORTQ_BASE, GPIO_PIN_4);
	GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_1);

	//Set UART parameters, 9600 clock speed, 8 bit message length, 1 stop bit, no parity
	UARTConfigSetExpClk(UART1_BASE, g_ui32SysClock, 9600,
			(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

	IntMasterEnable();	//Enable master interrupt
	IntEnable(INT_UART1);	//Set interrupt to UART1
	UARTIntEnable(UART1_BASE, UART_INT_RX | UART_INT_RT);	//Set UART1 RX pin and RT pins to be interrupts

After probing the hardware we're seeing that once the UART1 module is initialized, the TX line goes high. The RX line jumps high as soon as it is configured as as UART pin (lasts for 6.3ms) and then drops down to the ~650mV level. With the XBEE powered, we then jump the DOUT line to the UART1 RX line then we can receive data. 

Is the fact that we're setting the RX pin as an interrupt a factor?

David Moore53 said:

The comments are off but the code gives you the right idea.

I (was) about to "squawk" at that!

When that pin is configured as "UART_RX" I'm at a loss to explain how such pin can (apparently) "pull-down" your external device's output.    And - (only) do that from power-up.

Upon "power-up" most MCU GPIO pins will default to input - likely (and deliberately) preventing such unwanted behavior.   Now - as your comments are (rushed - to be kind) might (other) areas of your code (briefly) configure "UART_RX" as an output?   (firm/I often find this due to rushed client development)

Have you a 2nd MCU board - it would be useful to repeat this test - ideally w/a "Fresh MCU board!"   Your mention of "both MCU and Xbee outputs - set (high) - during a test" make suspect (both) the MCU AND Xbee pins!   Now those pins (may) appear to work when "specially handled" (you connect ONLY after both devices have powered up).   Yet - those pins (one or both) may have been damaged - and cannot support the "extra current transients" inflicted upon "awakening."   An ideal test would employ (BOTH) a new Xbee and new MCU board - avoiding any setting of both outputs "high!"

Have you positively measured the (common) ground connection between both boards?   (recently?)   

Would you be so good as to employ a 4K7-10K pull-up R (to 3V3) @ UART_RX - and then power up - w/out any external connections?   A scope capture of that pin - at power up & just beyond - would be useful.   From your writing we cannot tell if an, "Xbee-free" connection (i.e. the pull-up) will also yield the illegal voltage level (~0.6V) shortly after power up.   Such a test - and report - will be telling.

For completeness it would be wise to monitor the 3V3 to (both) Xbee & your MCU board during "power-up."   You should also monitor (via scope) the "start-up" output signal from the Xbee - unattached to your board!   Might it over or under-shoot?   (i.e. exceed 3V3 or go below ground)   None of this detail has been reported - yet "Everything is suspect" in such an unusual case...

David,

What is the XBEE pin 17 connected to? If it is left floating, it might cause the XBEE to use SPI instead of UART.

To provide a, "Clean bill of health" to your MCU board cannot you route your (questionable) UART to a 2nd UART - resident upon that same MCU board - or upon a 2nd?   (I recommend that pull-up Rs appear at each UART_RX pin.)

Success following that procedure would (almost) completely shift blame to the Xbee.

When not using level translators (RS232/485 etc.) we find that (most) UART_RX pins either "require" or substantially benefit from the presence of a pull-up R. (we note that on Cortex M4 MCUs from several vendors (including this one)...)

Note that we requested you to "scope monitor" the output of the Xbee - with NO Connection to your MCU board.   You complied and report NO over/under-shoot - yet did not specifiy if the output level was suitable for the MCU! (i.e. high at/around 3V3, low at/around ground.)    Such proves critical as the Xbee is drifting into "guilty party" prominence...