Can't update TCNT1 while debugging in simulator.

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

I have this problem, not sure if this affects me or everyone. I am using ATmega324PB. Every time when I try to debug something in atmel microchip studio simulator with device selected ATmega324PB, I can't update the TCNT1 register manually.

 

Suppose if the timer is running and I pause the program. The value in TCNT1 is 100 and I update it to 1000 and then continue the program. The TCNT1 starts from 100 not from 1000.

 

I tried this exact thing with with another device selected say ATmega2560 and it works, no problem with that device in simulator.

 

I also tried with real ATmega324PB connected with JTAG.  It also works fine. TCNT1 updates okay.

 

So problem seems to be in the simulator with device ATmega324PB.

 

Can anyone confirm? Is this a bug?

 

Here is program to test -

 

int main(void)
{
    TCCR1B |= (1 << WGM12) | (1 << CS10) ;
    OCR1A = 100;

    while (1)
    {
        __asm__ __volatile__("nop");
    }
}
This topic has a solution.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

Last Edited: Mon. Aug 9, 2021 - 03:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

Yeah, I see the same. If I run it a few steps...

 

and then click on the 0x18 that is in TCNT1 and just type "99" and Enter then at first I see:

 

 

(0x63 = 99) but as soon as I start to step again it reverts to:

 

 

so has returned to the previous counting sequence.

 

Often this kind of error is because of a fault in the ATDF file being used.

 

EDIT: looked at Atmega324pb.atdf:

 

 

don't see much wrong with that - the datasheet confirms TCNT1H/L at 0x85/0x84.

 

Last Edited: Thu. Aug 5, 2021 - 08:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Often this kind of error is because of a fault in the ATDF file

Other than ensuring it's up-to-date, Is there a way to fix such faults? Or is it just a matter of raising an issue with Microchip Support?

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: 1

awneil wrote:
Other than ensuring it's up-to-date, Is there a way to fix such faults? Or is it just a matter of raising an issue with Microchip Support?
See my edit  - it doesn't seem to be the problem this time. But on the occasion it does turn out to be the XML then sometimes (like a wrong IO address) it can be fixed simply by editing the XML.

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

Okay, thanks for conforming.

 

Not really a big issue but still sad to know. I use simulator extensively.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

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

Finally back from summer vacation ;-)

The error was related to the access of the TCNT register in the RTL code. The fix will be out in the next ATmega_DFP release. Meanwhile you can replace your current .dll with the one attached. The default .dll location is "C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\<dfp-version-number>\simulator\win32".

 

-Jan Egil

Attachment(s): 

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

One small note:
The new TCNT value will take one cycle to propagate through the model, which means that if you do a one-cycle step after writing to TCNT it will remain unchanged. Only after the next cycle will it count as expected.

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

Hurray !!! je_ruud for the win. 

Welcome back and thanks.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery