Data drop(!?) in MODBUS communication between two AVR[TTL]

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

Hi every one.

My MODBUS implementation is just working as expected in proteus simulation.

I send a request: [11 3 0 1 CRCLOW(86) CRCHIGH(9A)] for command READ_HOLDING_REGISTERS.

AND i receive that in other peer.

But in real hardware connection (TTL) i'm receiving [11 3 0 1A] !

I'm pretty sure about my code and i debug that many times in simulator.

 

My environment: ATmel Studio7.0 + ATmega8A + 9600@1MHz

 

What do you think ?

 

Note: i already test the UART connection by simple LED blink so my serial setup shouldn't be the problem.

Last Edited: Thu. Oct 12, 2017 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

That is a tough one.  Is the receiver checking for UART errors, particularly framing errors?  And data overrun -- does your slave do an extensive operation before digesting the checksum bytes?

 

What baud rate is being used?  Same symptoms if you slow down the baud rate?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

iman4k wrote:
I'm pretty sure about my code and i debug that many times in simulator.
What if the simulator behaves wrong in a particular detail and your code is relying on that?

There was a thread several months ago turning out that Proteus does not simulate the FE bit correctly. Find out whether you are using that buggy version or a fixed one.

Stefan Ernst

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

I've DOR :(

And the same condition if i decrease BAUD from 9600 to 2400!.

 

There is nothing special in RXC ISR:

ISR(UART_RXC_INT) {
	Byte status = UART_UCSRA;
	if (CHECK_BIT(status, UART_DOR))
		// notification or something...
	Byte data = UART_UDR;
	TIMER_RESET();
	if (!CHECK_BIT(bus_state, ACTIVE)) {
		SET_BIT(bus_state, ACTIVE);
		START_TIMER();
	}
	push_back(&buffer, &data);
}

 

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

iman4k wrote:
I've DOR

But not FE

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I agree on both.

Proteus will not simulate DOR PE FE and also CRC so i don't rely on proteus But i have no choice other than simulator for debugging!

And it ended up that i have DOR whether with BAUD 2400 or 9600 !

So i should stick to that for now !

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

iman4k wrote:

My environment: ATmel Studio7.0 + ATmega8A + 9600@1MHz

 

Internal RC oscillator? Not accurate enough for serial comms.

 

 

iman4k wrote:

My environment: ATmel Studio7.0 + ATmega8A + 9600@1MHz

 

9600 baud from a 1MHz clock? Can't be done unless you are running in U2X = 1 mode.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

No.

Neither FE nor PE.

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

So

Are you saying 9600 + 1MHz internal oscillator is impossible ?

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

iman4k wrote:
Are you saying 9600 + 1MHz internal oscillator is impossible ?

What does the datasheet say?

OP did say that a trial with 2400.  But the mentions of FE and DOR do not show code for checking and reporting such situations.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

iman4k wrote:

Are you saying 9600 + 1MHz internal oscillator is impossible ?

 

Two things are of concern here...

 

1) The internal oscillator is not very stable against VCC and temperature. See figure 170 in the datasheet.

 

2) Unless you have set U2X to 1 then your baud rate will be in error by 7%, see table 60.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

So using an external crystal with 1.8432MHz @9600 Baud rate (U2X = 0) will solve the DOR problem i'm having now ?

i'm asking this to be sure, because i don't have the crystal right now.

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

iman4k wrote:
will solve the DOR problem i'm having now ?

Are you trapping DOR events?

Are you trapping FE events?

From your description, you imply that the sequence is repeatable.  Are the trapped events also repeatable?

 

In other words, you have not shown that you indeed have a "DOR problem" right now...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

OK everyone.

Thanks for spending time on my issue.

My UART obstacle was in the hardware side and i had DOR.

As you suggested i used an external crystal (11.0592 MHz) and now there is no DOR(or CRC).

 

Regards.

Iman.

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

iman4k wrote:
My UART obstacle was in the hardware side and i had DOR.

If the problem was indeed the baud rate being "off", I'd expect to see FE. 

 

You said you see no FE, but never showed any code to trap or take action.

 

DOR is usually a structure situation, where you don't get back to USART servicing for 2+ character times.  Actaully pretty hard to do, unless there are ISR(s) that take a millisecond or more.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Actually There was a simple trap for DOR inside RXC ISR:

ISR(USART_RXC_vect) {
	Byte status = UCSRA;
	if (CHECK_BIT(status, DOR)) {
		// An alarm (turn on LED)...
        }
	Byte data = UDR;
	TIMER_RESET();
	if (!CHECK_BIT(bus_state, ACTIVE)) {
		SET_BIT(bus_state, ACTIVE);
		START_TIMER();
	}
	push_back(&buffer, &data);
}

 

But no error for FE or PE (i tested for them both)

Last Edited: Tue. Oct 17, 2017 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

iman4k wrote:
But no error for FE or PE (i tested for them both)

I'm out.  The posted code is either incomplete, or there is no action for the DOR.  And while I've heard the assertions for FE, there still have been no code snippets that reference it.  I'd still guess IME that if indeed it was a baud rate mismatch that there would be FE, and my analysis of when one might see a DOR still stands.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.