Debugger making mistakes

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
vpa
vpa's picture
Level: New Member
Joined: Mon. Jan 9, 2006
Posts: 13 View posts
#1
Posted by vpa: Tue. Feb 14, 2006 - 10:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

I've noticed that when I run a program with AVRStudio and JTAG step by step, it sometimes makes mistakes, such as reads a value incorrectly or skips an instruction. Often you don't notice the mistake at the time it happens, only afterwards. But sometimes you notice it so clearly that it is obvious, such as when the RET command of a function is skipped and processor continues to execute the next function like nothing... unless you notice it soon enough to set the Program Counter to a value that will get it back on track.

Do you have any hints as to how to minimize the number of unnecessary JTAG mistakes? I've tried by minimizing the communications speeds between JTAG and the computer (50kHz and 9600 bps seem to be the minimums), but I'm not sure if it makes any real difference.

Nowadays I'm using an Olimex JTAG. Earlier I had a genuine Atmel JTAG but I think it made mistakes, too. I understand that the circuit board could also be a source of instability in some cases.

Thanks for any advice you can give.

Regards,
Vesa

Tags:

Tools, Atmel Studio (AVR-related)
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101134 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Feb 14, 2006 - 10:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used an Atmel JTAGICE mkII with lots of different AVRs and I have NEVER seen it misbehave in the way you describe. I'd suggest that there's either something wrong with your installtion of Studio or with your JTAG hardware or your understanding of what's really going on.

Cliff

Top
vpa
vpa's picture
Level: New Member
Joined: Mon. Jan 9, 2006
Posts: 13 View posts
Posted by vpa: Thu. Feb 23, 2006 - 10:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I'm glad to hear that the mistakes are not an inherent property of unprotected serial transfers or anything like that...

If you want to check whether your debugger is really free from mistakes or just sufficiently free that you don't notice it, you can leave the debugger in autostepping mode for a long process (like for your lunch hour) and check afterwards whether the iteration/calculation has produced correct results... (In my system it usually goes awry pretty soon.)

I suppose that the amount of data transfer during autostepping depends somewhat on how many updating information windows--such as watches or the CPU register view--you have active. It may also be worthy of note that some processes are not slowed down--for example, USART sends get immediately ready in autostepping. But I suppose that that kind of things don't usually affect the way a program runs (except if you have "Run Timers in Stopped mode" in JTAG ICE Options checked...).

- Vesa

Top
bengtr
bengtr's picture
Level: Hangaround
Joined: Tue. Apr 17, 2001
Posts: 242 View posts
Location: Linkoping, Sweden
Posted by bengtr: Mon. Feb 27, 2006 - 07:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I donät think it miss anything. Remember that the emulator follows the assembler code but shows you the C-code. (I guess that you use C). This will mean that depending on the compiler, the actual assembler may make the emulator going to c-lines that may be a little unpredictable.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

Top
Bronze Markjs
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29979 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
Posted by js: Mon. Feb 27, 2006 - 09:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I have NEVER seen it misbehave in the way you describe

I have seen it misbehave...when I change the source file and forget to reload the new code or the new EEPROM data. :oops: So the chip is running the old code but your source has changed and the whole debugging thing becomes a mess (did it yesterday :oops: ), in my case it was a loose nut behind the JTAG :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
vpa
vpa's picture
Level: New Member
Joined: Mon. Jan 9, 2006
Posts: 13 View posts
Posted by vpa: Fri. Mar 3, 2006 - 09:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bengtr wrote:
Remember that the emulator follows the assembler code but shows you the C-code. (I guess that you use C). This will mean that depending on the compiler, the actual assembler may make the emulator going to c-lines that may be a little unpredictable.

Thanks for the point, but you can use the disassembly view to watch the assembly commands being stepped through one by one.

Quote:
I have seen it misbehave...when I change the source file and forget to reload the new code or the new EEPROM data.

Usually AVRStudio loads the FLASH image in automatically when you start debugging; so the mismatch you describe doesn't happen very easily, does it. Nevertheless, I've seen confusing situations arise when I take a copy of a directory and I start the .aps file in the new directory, because AVRStudio still load other files from the old directory location, not noticing the change. (But that's not the cause of the problem I described.)

Regards,
Vesa

Top