Xmega32A4 and TRSF3232I board can hear RS-232 but doesn't reply.

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is bothering me enough to finally make an account.

 

Custom board running XMega32A4. Trying to get a simple serial Hello World running.

 

Using TRSF3232I to convert to RS-232.

 

Board.H

#ifndef CONF_BOARD_H
#define CONF_BOARD_H
//#define RS232_USART0	&USARTD0
#define BLINKPIN IOPORT_CREATE_PIN(PORTA, 4)
#define CONF_BOARD_ENABLE_USARTD0

#endif // CONF_BOARD_H

conf_usart_serial.H


#ifndef CONF_USART_SERIAL_H_INCLUDED
#define CONF_USART_SERIAL_H_INCLUDED

#define CONF_USART				&USARTD0
#define CONF_USART_BAUDRATE		9600
#define CONF_USART_CHAR_LENGTH	USART_CHSIZE_8BIT_gc
#define CONF_USART_PARITY		USART_PMODE_DISABLED_gc
#define CONF_USART_STOP_BITS	false

main.c

#include <asf.h>
#include <string.h> 

int main (void)
{
	uint8_t tx_buf[] = "\n\rHello AVR world ! : ";
	uint8_t tx_length = 22;
	uint8_t received_byte;
	uint8_t i;
	uint8_t myMessage[] = "Hello!";
	sysclk_init();
	
	board_init();
	static usart_rs232_options_t usart_serial_options =
	{
		.baudrate = CONF_USART_BAUDRATE,
		.charlength = CONF_USART_CHAR_LENGTH,
		.paritytype = CONF_USART_PARITY,
		.stopbits = CONF_USART_STOP_BITS
	};
	//stdio_serial_init(CONF_USART, &usart_serial_options);
	ioport_set_pin_level(BLINKPIN, IOPORT_PIN_LEVEL_HIGH);
	//while (1)
	//{
		//ioport_toggle_pin_level(BLINKPIN);
		//delay_ms(500);
	//} 
	//sysclk_enable_module(SYSCLK_PORT_D, PR_USART0_bm);
	
	usart_serial_init(CONF_USART, &usart_serial_options);
	delay_ms(1000);
	
	
	printf("\r\nHello, world\r\n");
	// Send "message header"
	usart_serial_write_packet(CONF_USART, myMessage, 2);
	
	delay_ms(1000);
	for (i = 0; i < tx_length; i++) {
		usart_putchar(CONF_USART, tx_buf[i]);
	}
	// Get and echo a character forever, specific '\r' processing.
	while (true) {
		received_byte = usart_getchar(CONF_USART);
		if (received_byte == 'g') {
			ioport_toggle_pin_level(BLINKPIN);
			delay_ms(200);
			ioport_toggle_pin_level(BLINKPIN);
			usart_serial_write_packet(CONF_USART, myMessage, 2);
			usart_putchar(CONF_USART, received_byte);
			for (i = 0; i < tx_length; i++) {
				usart_putchar(CONF_USART, tx_buf[i]);
			}
		} else
		usart_putchar(CONF_USART, received_byte);
	}
	//stdio_serial_init(CONF_USART, &usart_serial_options);
}

 

I  should get a "hello world" on startup. Nothing. I should get characters I send echoed back. Nothing. If I send 'g' (chosen at random) my LED "BINKPIN" does blink. So usart_getchar() is clearly working. But I can't get any response from usart_putchar, or usart_serial_write_packet, or printf.

 

On startup, I get 00 and a RXD break according to realterm. I put in some delays to confirm that was just the TRSF3232I powering up and not a failed attempt at sending a signal. Any help?

This topic has a solution.
Last Edited: Wed. Jan 10, 2018 - 07:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would use a scope or LA to look at the TXD pin on the xmega going to the line driver ic to look for activity.

If it is there, then the problem is with your line driver. (in/out reversed perhaps?)

Why use RS-232 these days?

 

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Why use RS-232 these days?

+1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried a simple hardware loop-back - not involving the AVR at all?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

test

 

I created this, and my previous post, by pressing the 'Reply' button in the OP - so why is the forum not showing "in reply to #1" ?

Last Edited: Wed. Jan 10, 2018 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and this is a reply to #2

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Why use RS-232 these days"

 

I'm in an academic lab. It turns out that the world of science is full of people who may be geniuses at their specialty but are just kind of ok at electronics. Almost everything in environmental science runs RS-232. This board is eventually going to be a remote monitor that will talk to three sensors we commonly use at field sites. One only talks via RS-485, two only talk via RS-232. Gather data from the sensors, throw it on an SD card, periodically pass it to an XBee cellular radio, and from there the cloud. 

 

Will ask around for a scope. LA is on order.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Tried hardware loopback?"

 

Yep, that works, so it isn't the cable.

Last Edited: Wed. Jan 10, 2018 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe replies to an OP don't work?

 

EDIT:  Yup.  This post was created by clicking Reply on the OP.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Jan 10, 2018 - 06:25 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have not used xmegas, but with mega/tiny's one must set the ddr for the TXD pin to be an output.

Perhaps the xmega takes care of that detail when the tx is enabled.....   Worth checking.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SJG-NCSU wrote:
Yep, that works, so it isn't the cable.

Which side of the transceiver was that?

 

ie, have you also proved that the transceiver is working?

 

You should also try shorting the AVR Rx pin to the Tx pin - right at the chip - to demonstrate that the PCB tracking, etc, is all OK.

 

(make sure that the AVR is not driving its Tx pin while doing that!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

"I have not used xmegas, but with mega/tiny's one must set the ddr for the TXD pin to be an output."

 

Ding Ding!

 

Thank you!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have not used xmegas, but with mega/tiny's one must set the ddr for the TXD pin to be an output.

Uh, no.  All the mega I've used (haven't used a tiny with a USART yet), enabling TX overrides TXD as an output.  No need to twiddle DDR.  Same for RXD, but it is overriden as an input.

 

As I understand it, the Xmegas are different.  The OP seems to have come to that conclusion as well.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]