AS/MS 7 Simulator problem

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

HI

I'm working on a 2560 serial ports and using the simulator in AS7 to just check things as I go.

 

Anyway, I cannot seem to get TXENn to be anything other than 1.

 

UCSRnB - bit 3 is permanently shown as a one no matter how I try to change it be it the mouse or code. The display value also corroborates this by displaying 0x08. 

 

is it me ?

 

Slightly tweaked code from Pg 206 of the datasheet

 

#include <avr/io.h>

 #define MYUBRR 0x67
 void USART_Init(uint8_t);

void main(void)
{
	USART_Init (MYUBRR);
} // main

void USART_Init(uint8_t ubrr)
{

	UBRR1H = (unsigned char)(ubrr>>8);
	UBRR1L = (unsigned char)ubrr;

	UCSR1B = (1<<RXEN1)|(0<<TXEN1);

	UCSR1C = (0<<USBS1)|(3<<UCSZ11);
return;
} 

thanks

 

Last Edited: Thu. Nov 19, 2020 - 06:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Docara wrote:

void USART_Init(uint8_t ubrr)
{

	UBRR1H = (unsigned char)(ubrr>>8);  //just use UBRR1 = ubrr; the compiler knows the correct way to write a 16 bit value to a 16 bit register
	UBRR1L = (unsigned char)ubrr;

	UCSR1B = (1<<RXEN1)|(0<<TXEN1);     //the default for all bits is zero, so just set the one(s) you want, set a break point before here and look at register value it should be all zeros

	UCSR1C = (0<<USBS1)|(3<<UCSZ11);    //if you want 8N1, that is the default, so no need to touch this register
return;
} 

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

 

Thanks for the info, but as mentioned I just copied and pasted the basics from the datasheet. The reason I purposely but a zero in was to ensure there was a zero loaded to the TXENn register. 

 

My question was about AS7 simulator not displaying the correct info - is it a bug or me

 

Have included screen grab during debug

 

 

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

Make sure you have set optimization to -Og for debug, as different levels can do odd things to the order of execution of the code, in other words things can happen in a different order then the C code. 

Zip up your project directory and post it here for others to run and can better help you understand what your seeing.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Docara wrote:
working on a 2560 serial ports and using the simulator

For anything involving actual hardware interaction - such as the UART - surely using real hardware and a debugger is a far better option?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Docara wrote:

My question was about AS7 simulator not displaying the correct info - is it a bug or me

 

Have included screen grab during debug

Yes, you have a serious problem.   Please click on "Clean".   Then ZIP up your AS7.0 project and attach the ZIP.

 

I will attempt to replicate your problem.

 

David.

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

I tried for myself:

#include <avr/io.h>

#define MYUBRR 0x67
void USART_Init(uint8_t);

void main(void)
{
    USART1_Init (MYUBRR);
    USART0_Init (MYUBRR);
    while (1) {
        asm("nop");    //put Breakpoint on this line
    }
} // main

void USART1_Init(uint8_t ubrr)
{

    UBRR1H = (unsigned char)(ubrr>>8);
    UBRR1L = (unsigned char)ubrr;

    UCSR1B = (1<<RXEN1)|(0<<TXEN1);

    UCSR1C = (0<<USBS1)|(3<<UCSZ11);
    return;
}

void USART0_Init(uint8_t ubrr)
{

    UBRR0H = (unsigned char)(ubrr>>8);
    UBRR0L = (unsigned char)ubrr;

    UCSR0B = (1<<RXEN0)|(0<<TXEN0);

    UCSR0C = (0<<USBS0)|(3<<UCSZ01);
    return;
}

Observe USART0 and USART1 at the start of main()

Select USART0 then hold CTRL key and select USART1

Both UCSR0B and UCSR1B contain 0x08 which is wrong.

 

Then observe the registers after initialisation.   e.g. put a Breakpoint on the nop()

 

It looks as if the Simulator is seriously broken.   I tried Pack versions 1.0.91, 1.1.30,  1.2.203, 1.4.351, 1.6.634 on AS7.0.2542

All behaved the same.

 

I can't believe that a bug like this could exist without hearing about it before.

Please can someone try with an earlier AS7.0.xxxx

 

David.

Last Edited: Fri. Nov 20, 2020 - 02:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I can't believe that a bug like this could exist without hearing about it before.

Most likely because most enable the TX function! wink

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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


I'm probably just repeating David's observation but I have AS7.0.2389 and the pack I'm using for 2560 is 1.4.351 and I also see:

 

 

So just before the call to USART1_Init() I too see the TXEN bits in UARTs 1 and 2 already set.

 

Then again who simulates UARTs? It's a complete "black box" as far as the simulator is concerned - this is not like Proteus or something - you can't "see" what happens when you operate the UART so I would just stick the code into a real board and, if available, wire up a JTAG and watch it in real silicon.

 

(Having said that, given that the simulator is supposed to be based on the VHDL of the silicon, it does make you wonder what actually goes on there so I would use the JTAG to look at the power on state of the B registers before any code is executed - perhaps this really is a silicon bug too?)

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

Cliff,

 

Did you see how the wrong bits get set in UCSRnC as well ?

 

I agree that few people would Simulate USART operation.    But it is quite sensible to check the initialisation e.g. UBBRn, UCSRnB, ...

 

Simulating "operation" is difficult.   Reading and writing values to a register should be straightforward.   If read/write fails then I would not trust anything from the ATmega2560 Simulator.

 

Probably just an XML typo.   But XML, Simulation, ... should all be machine generated.

 

David.

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

See previous posts from Morten/charla/etc

 

I forget what it is called but the simulation DLLs in AS7 are just the VHDL wrapped in some "runner" so the models should be bit accurate. I don't think this is just an XML typo unless the XML is saying "look in the wrong place for what to show as UCSRA etc"

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

Verilator

IIRC, there's also Linux shared object.

https://www.avrfreaks.net/search/site/Verilator

Intro - Verilator - Veripool

 

"Dare to be naïve." - Buckminster Fuller

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

I keep saying VHDL, clearly I really meant Verilog ("same meat, different gravy" as I'm oft heard to say ;-)