ATxmega 128A1 (xplain) USART and FreeMODBUS help

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

First off I would like to know if the USART can send data while single stepping code. Now that I think about it some more it seems rather unlikely. But I have ported the FreeMODBUS code over the the xplain board and everything appears to work as expected on the first poll. But on the second poll I don't get a response. I have single stepped the code several times over and the USART settings are exactly the same the second time around. Interrupts are enabled, baud, parity and data-bits haven't changed, and the TX is enabled. This is all I am doing to load the USART DATA register

BOOL
xMBPortSerialPutByte( CHAR ucByte )
{
   USART.DATA = ucByte;
   return TRUE;
}

but if I watch USART.DATA in the debugger it's always zero, even when it does send. This is making it rather difficult to debug. Can I fix this? Is there a reason for that? Is it a bug in my code or the debuggers?

Are there any "gotchas" to the USART that might cause it to not send?

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

Somewhere in the documentation there is a table with all the different pin functions. I have found it many times but I can't find it now. I have been looking for an hour. Does anyone know where I can find that table?

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

In /device data sheet/IO Ports/alternate functions

Tom Pappano
Tulsa, Oklahoma

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

Thank you so much. I have found it probably 6 times and every time it has taken me forever and when I finally do find it I think duh how did I miss that. I'm printing it out and taping it up in my office this time.

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

You're welcome- that information has similarly eluded me several times!

Tom Pappano
Tulsa, Oklahoma

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

:( I have tried to port the Freemodbus code to the Xplain PCB, but am having too many problems. The freemodbus code is very confusing.

Has someone got a working port to the xplain PCB that they can share the code?

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

I will see if I can dig something up later on today. I did get it working although I handed the software off to someone else and I can't remember which version I have actually works. What have to tried to get it working? It wasn't that hard. You only need to rewrite parts of the timer file and the uart file.

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

I can receive a frame. But the unit never transmits. CRC looks correct. Address is correct. I am using modbus poll on ubuntu.
./modpoll -m RTU -a 10 -r 1000 -c 4 -t 3 -b 38400 -d 8 -p even /tty0.
The unit is being polled. The PC data looks correct. I assume modpoll is working.
The software seems to only receive the 1st frame. Then after the 1st frame nothing else happens. I am porting it onto the M2560, as I have a hardware platform.
If I get this working where is the best place to post the ported code, here or freemodbus site?

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

FreeMODBUS does ask that you post your new ports to their site. Maybe post it in both spots Not IF you get it working but WHEN you get it working.

One thing to check. If I remember correctly the spec says frames should be terminated by a \r\n but the software was actually looking for \r\r or \n\n. I can't remember which one it was so I just set the computer to send one of those. Also, I didn't trust my MODBUS program so I bumped the wait time between characters to the max and typed them in by hand with hyperterminal a few times. Then I found a program called realterm which would allow you to send a whole string all at once in what ever format you wanted. I know minicom allows you to do the same thing so maybe try minicom and see if you are receiving anything at all. Maybe you are receiving something but it's not correct so the modbus poll program is just dropping it? Are you using a debugger? Can you breakpoint after you have received a complete frame? I good place to do that would be in the ported uart driver where the receiver is turned off and the transmitter is enabled.

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

I am using a debugger. I see the frame received then The transmitter is enabled, and that is it. The event system does not take you to the next event of sending the data. No more frames can be received. Only a reset allows you to get the next frame. The software is complicated with very few comments. I am really lost in it.

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

Well my guess is, the reason that no more frames can be received is you are getting stuck somewhere after the receiver is disabled and the transmitter is enabled and before the receiver is re-enabled. So of course you are not going to receive any more frames. Are you using ASCII or RTU? There are receive and transmit state machines in both files. Throw some break points in there and see how far you get through them. What does your vMBPortSerialEnable(BOOL, BOOL) function look like in portserial.c? Are you sure you aren't turning off some interrupts that you don't want to in there? Mine looks like this

void
vMBPortSerialEnable( BOOL xRxEnable, BOOL xTxEnable )
{

	// Turn the receiver on?
    if( xRxEnable )
    {
		USART.CTRLB |= USART_RXEN_bm; // enable the receiver
		USART.CTRLA |= USART_RXCINTLVL_MED_gc;  // Receive complete interrupt enable (high priority)
    }
    else
    {
        USART.CTRLB &= ~USART_RXEN_bm; // disable the receiver
		USART.CTRLA &= ~USART_RXCINTLVL_MED_gc;  // Receive complete interrupt disable
    }

	// Turn the transmitter on?
    if( xTxEnable )
    {
        USART.CTRLB |= USART_TXEN_bm; // enable the transmitter
		USART.CTRLA |= USART_DREINTLVL_MED_gc; // data register empty interrupt enable (high priority)
    }
    else
    {
        //USART.CTRLB &= ~USART_TXEN_bm; // disable the transmitter
		USART.CTRLA &= ~USART_DREINTLVL_MED_gc; // data register empty interrupt disable
	}
}

I think that's right but I know this is not from my latest rev so no promises.