atmega32 UART transmission problem in Proteus

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

Hi all.

I am trying to simply send a set of characters from an atmega32 to a virtual terminal by UART protocol in Proteus.

 

This is my code: https://gist.github.com/cod-r/83af8bd8b633b7d7ce81e76e50e928e3

What my code is supposed to do: Every 3 seconds send the text "lab micro" to the terminal, but i only get a weird character on the terminal every 3 seconds (see atached photo and please ignore the LCD)

I am using a baud rate of 300bps, 8bit, 2bit stop, even parity.

I have checked every setup of the terminal and its the same as my code.

 

I tried using an external clock of 8mhz, as well as the internal clock, but no luck.

We tested the exact same code in my uC class with an easyAVR7 development board and everything was working fine.

I tried using another baud rate in the code, no parity, odd parity, 1 bit stop, I think i tried everything.

 

Any sugestions?

 

 

Attachment(s): 

This topic has a solution.
Last Edited: Thu. Jan 4, 2018 - 09:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

codR wrote:
Any sugestions?
   Contact Proteus support, you paid for the license!

 

 

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

To trace bug set virtual terminal to show hexcode and see whats is the hex code of weird characters

Majid

Last Edited: Sat. Dec 30, 2017 - 03:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What makes you think that a forum related to Atmel Studio bugs is a suitable place to ask for support for another company's product?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Are you sure you have the baud rate properly set in the AVR? Your system clock is not USART friendly, and you may need to set the 2x bit to get communications within spec.

2 stop bits? Most of the time communications is 8 bit, no parity, one stop bit. Do you have the terminal set properly?

As noted above why not contact proteus as you have a licensed installation?

Since this is not Studio related I will move this to general programming

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

codR wrote:
i only get a weird character on the terminal

 

Wrong baud rate generally results in "garbage" characters being displayed; eg,

 

Baud Mismatch

See: https://learn.sparkfun.com/tutorials/serial-communication

 

 

see atached photo 

It makes life a whole lot easier if you embed the picture in your post where we can all see it (as above) - rather than attach it.

 

Instructions here: http://www.avrfreaks.net/comment...

 

please ignore the LCD

And make the effort to crop-out any irrelevant details

 

EDIT

 

fix quote

Last Edited: Sat. Dec 30, 2017 - 11:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
2 stop bits? Most of the time communications is 8 bit, no parity, one stop bit.

Extra Stop bits should not hurt - a stop bit is just the same as a line idle condition

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

awneil wrote:
jgmdesign wrote: 2 stop bits? Most of the time communications is 8 bit, no parity, one stop bit. Extra Stop bits should not hurt - a stop bit is just the same as a line idle condition

 

No argument there, I was/am only saying that its unusual.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I suspected proteus and wrote some code in CVAVR to test 300,600,1200,2400,9600 baud rates in proteus. Result:

300 bps dos not work fine,
600, 1200, 2400, 4800, 9600 works fine

Virtual terminal doesn't work fine when set 2 stop bits, works fine when set to 1 stop bit

Most likely simulation bug,

Majid

Last Edited: Sun. Dec 31, 2017 - 09:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well that's definitely something to take up with Proteus, then!

 

EDIT

 

But beware: http://www.catb.org/~esr/faqs/sm...

Last Edited: Sun. Dec 31, 2017 - 11:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m.majid wrote:
300 bps dos not work fine, 600, 1200, 2400, 4800, 9600 works fine Virtual terminal doesn't work fine when set 2 stop bits, works fine when set to 1 stop bit Most likely simulation bug,

Either I don't have enough information, ir I'd meed to dig deeper in anything attached/linked above.

 

1.  >>OF COURSE<< two stop bits could be a problem -- if the receiver is expecting 2 stop bits but the transmitter is only sending one.    From there, it depends on how framing errors are handled. 

1a.  However, I guess I'd agree that it may not cause the gibberish display.

1b.  Use the same settings on both ends.  Explicitly show those settings.

 

2.   Do we know the AVR's clock rate?  Have we seen the AVR UART setup code?  There are certain clock speeds where 300 will require a UBRRH value, and 600, etc. not.  IIRC there are also clock speeds where 300 (even with correct UBRR) has a higher error rate than desired.

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

theusch wrote:

2.   Do we know the AVR's clock rate?  Have we seen the AVR UART setup code? 

 

Assembly code in the github link in post #1.

'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

theusch wrote:
1.  >>OF COURSE<< two stop bits could be a problem -- if the receiver is expecting 2 stop bits but the transmitter is only sending one.   

Well, I did specifically say extra stop bits should not cause a problem - but, agree that insufficient stop bits could cause problems.

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

That is proteus
Can't stop use it, can't trust it!

Majid

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

Absolutely extra stop bits is no problem at trasmiter side

Majid

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

Your code is wrong:

ldi r16, 0x6C     ;ascii for "l"
out UDR, r16
call wait         ;wait for data to be sent

You normally check UDRE before writing to UDR.  e.g.

putchar:              ;print the character in R16
wait:
    in r16, UCSRA     ;read the state of UCSRA
    sbrs r16, UDRE    ;check if UDRE is empty
    rjmp wait         ;UDRE is not empty, we wait more
    out UDR, r16      ;then write to UDR
    ret

Note that it is always worth factoring code into subroutines.   e.g. putchar() and putstring()

 

It makes your program logic much easier to follow and maintain.

 

Your "unusual" approach of shooting first and asking questions later might work.   It makes my head hurt.

I suspect that it is corrupting the USART buffer.

 

If you want to check for TX completion,  you use the TXC flag but it is a bit fiddly because you must clear TXC manually.

 

I would expect a licensed copy of Proteus to simulate the USART correctly.    Try it and see.

 

David.

Last Edited: Sun. Dec 31, 2017 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m.majid wrote:
That is proteus

Hmm -how are you so sure?

 

Again, see: http://www.catb.org/~esr/faqs/sm...

 

Can't stop use it

Of course you can!

 

In this day & age of on-chip debug, the value of simulations like this is greatly reduced.

 

can't trust it!

See above.

 

It is a well-established product from a reputable source - it seems rather unlikely that something so basic could be seriously broken.

 

Again, have you actually contacted Proteus support - https://www.labcenter.com/ - about this ?

 

Or used the Proteus forum: https://support.labcenter.com/forums/index.php

 

edit

 

typo

Last Edited: Mon. Jan 1, 2018 - 12:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ofcourse labcenter is reputable company, I am familiar with proteus isis since I was student at university, and I use it to examine some aspects of my projects. It is useful

I cant trust it since I spend hours and days to test and establish a bug in FE of UART in ATmega model, you know the below thread :

http://www.avrfreaks.net/comment/2212801#comment-2212801

The value of simulation for AVR is $487+$322

For 2 new issues "ATmega 300 bps baud rate" and "VirtualTerminal"
Don't worry, I am pursuing both to establish absolute result, I will share results here

Majid

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

The value of simulation for AVR is $487+$322

That value of an Atmel ICE is about $100! 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Since you own a Proteus license, why are you here getting help with it?

 

m.majid wrote:
That is proteus Can't stop use it, can't trust it!

Can you explain why you cannot stop using it?

 

m.majid wrote:
The value of simulation for AVR is $487+$322

Well you paid it didn't you?

 

js wrote:
That value of an Atmel ICE is about $100! 

Well, add $30.00 for 5 Arduino UNO knockoffs from Ebay and now you have actual hardware to work with.  And any terminal program can communicate with the USB connection as it emulates as a COM port.

 

And before you say that this wont work because you are using a Mega32......the USART is the same in the Mega32 as it is in the Mega328.  What IS diffent is the internal clock on the UNO but its a non issue in the grand scheme of things.

 

JIm 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

you are using a Mega32

Didn't see that, so the debugger costs between $3 and $5 instead of $100??

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

jgmdesign wrote:
Can you explain why you cannot stop using it?

The main reason is it is easy to use, I can quickly test and evaluate design ideas with minimum effort before starting real pcb design. also simulating several input sources and inspecting instruments.
Debugging is not everything, Benenefits of simulation such as easy to make and archive projects can not be denied
I mean along with benefits simulation can not be 100% trusted, it should be used watchfully

Majid

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

m.majid wrote:
I can quickly test and evaluate design ideas with minimum effort before starting real pcb design.

Then there was no need for this thread then, right? wink

 

m.majid wrote:
I mean along with benefits simulation can not be 100% trusted,

As the MANY threads we have here on Proteus users finding out that the simulator is not as good as they thought.

 

I used to use Electronics Workbench Pro back in the day and found it used up way too much time compared to a breadboard and a handful of parts from the stores in the lab.

Nowadays I simply CAD the boards, and while they are being made write the code and then load it into the PC board and make adjustments as needed.

 

To each his own.

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

especially nowadays with on-chip debug - so you can single-step, examine variables & registers, etc, in the actual hardware ...

 

Although no simulation is perfect, I very much doubt that the "problems" the OP is seeing are faults in the simulator - far more likely to be bugs in the code.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Although no simulation is perfect, I very much doubt that the "problems" the OP is seeing are faults in the simulator - far more likely to be bugs in the code.

I repeated the test using ATmega88 both on real chip and simulated chip on proteus isis

Internal rc 8 MHz
300/600/1200 bps
Sending fixed data 0x55
And inspected 1bit pulse width on oscilloscope
300 bps pulse is wrong only on isis, true on real chip
600/1200 bps pulse is true both on isis and real chip

Now I am quite sure it is proteus fault!
What can be other explanation?

Majid

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

That is very interesting.   I would expect Proteus to Simulate just fine.

 

URRR = 8000000 / 16 / 300 - 1 = 1666 which is well within the 12bit UBRR size.   It even works with U2X (UBRR = 3332)

An 8MHz AVR will fail on 110 baud and 75 baud.   But I doubt if there is much call for those speeds nowadays.

 

I have never considered buying a Proteus licence.    It seems an excellent Tool for Universities to use.

 

David.

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

Proteus is indeed very good, but the simulation of some more obscure details of the peripherals may have bugs. Certainly not on par with the AS simulator.

Sometimes, if you have a legit Proteus license, they will send you an improved model file fixing the bugs you discovered. Other times, they will kindly ignore you: "We will look into it, fix it in a future version..."

Maybe some bugs are just too hard to fix, who knows...

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

m.majid wrote:
Now I am quite sure it is proteus fault!

So have you reported it to Labcenter (the makers of Proteus) yet?

 

There's no use just moaning about it here - it has nothing to do with Atmel.

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

awneil wrote:
So have you reported it to Labcenter (the makers of Proteus) yet?

Dont worry I have already reported

awneil wrote:
There's no use just moaning about it here - it has nothing to do with Atmel.

sharing test results to help solve this thread is useful not moaning

Majid

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

What I find interesting that the OP (CodR) is NOWHERE to be found after the first post.  This thread seems to be m.majid vs just about everyone.

 

Long story short, I think the OP is gone, There seems to be a  bug in Proteus(which has been reported allegedly), and there is NO reason to continue this arguing any further.

 

Jim 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Topic locked