Break instruction ignored/unhandled by simulators

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

Looks like both simulators in AVRStudio do not handle break instructions!?

I simply get a "Invalid opcode 0x9598 at 0x..." message and execution continues.

IMHO the simulators should handle a break instruction as a valid instruction and break on then by default.

Ideally there would be two new switches in the simulator options:

Break on BREAK instruction.
Break on invalid opcode.

Bertolt

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

The BREAK instruction is not for your use but the emulators.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
The BREAK instruction is not for your use but the emulators.

?????????

#define ASSERT(cond) if (!(cond))                                                            \
                     {                                                                       \
                       __asm__ __volatile__ ("break" ::);                                    \
                     }

Why do you think this code should not behave the same when run in the simulator as it does when debugging on real hardware?

Furthermore it is plain wrong that BREAK is an invalid opcode as it is part of the AVR instruction set (see doc0856.pdf)!

Bertolt

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

I obviously don't know what I'm talking about. I got that impression from the statement for the Break instruction on page 28 of the AVR instruction set where it says that "is normally not used by the application software"

One of those darned PDF that are locked... :evil:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Foxit Reader still has a neat "feature":
- Open a not protected pdf file
- Activate text selection mode
- Close the pdf file
- Open the protected pdf file
- Now you can copy text from the protected file

Quote:
The BREAK instruction is used by the On-chip Debug system, and is normally not used in the application software. When
the BREAK instruction is executed, the AVR CPU is set in the Stopped Mode. This gives the On-chip Debugger access to
internal resources.
If any Lock bits are set, or either the JTAGEN or OCDEN Fuses are unprogrammed, the CPU will treat the BREAK instruc-
tion as a NOP and will not enter the Stopped mode.
Hope Atmel won't get angry about me right now.

Regards
Sebastian

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

bmildner wrote:

#define ASSERT(cond) if (!(cond))                                                            \
                     {                                                                       \
                       __asm__ __volatile__ ("break" ::);                                    \
                     }

Why do you think this code should not behave the same when run in the simulator as it does when debugging on real hardware?


Is that assert macro actually shipped with a compiler? I was not aware the break instruction is used by software in this manner.
bmildner wrote:

Furthermore it is plain wrong that BREAK is an invalid opcode as it is part of the AVR instruction set (see doc0856.pdf)!

It makes a lot of sense to have the simulator break execution on a break instruction and this is something we certainly will consider for simulator2.

- roland

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

js wrote:
I obviously don't know what I'm talking about. I got that impression from the statement for the Break instruction on page 28 of the AVR instruction set where it says that "is normally not used by the application software"

Well, i'd agree with the instruction set manual, but sometimes debugging requires something "unusual". :lol:

rkruse wrote:
bmildner wrote:

#define ASSERT(cond) if (!(cond))                                                            \
                     {                                                                       \
                       __asm__ __volatile__ ("break" ::);                                    \
                     }

Why do you think this code should not behave the same when run in the simulator as it does when debugging on real hardware?


Is that assert macro actually shipped with a compiler?

Not that i know of.

rkruse wrote:
I was not aware the break instruction is used by software in this manner.

Maybe i'm a freak, but I find it astonishing that everyone seems to be surprised about this usage of the BREAK instruction. In my view it is the most natural thing to use it in ASSERT.

rkruse wrote:
bmildner wrote:

Furthermore it is plain wrong that BREAK is an invalid opcode as it is part of the AVR instruction set (see doc0856.pdf)!

It makes a lot of sense to have the simulator break execution on a break instruction and this is something we certainly will consider for simulator2.

Are there AVRs that will not be moved to simulator2 (except for the EOLed ones)?

Bertolt

Last Edited: Wed. Mar 5, 2008 - 12:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I find it astonishing that everyone seems to be surprised about this usage of the BREAK instruction
It never even crossed my mind to use it, I just let the debuggers do that for me. :) (JTAG or DW) Just put breakpoints where needed.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I'm with you on that, John. I haven't used the simulator in over a year, but I use JTAG or DW very frequently.

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

js wrote:
Quote:
I find it astonishing that everyone seems to be surprised about this usage of the BREAK instruction
It never even crossed my mind to use it, I just let the debuggers do that for me. :) (JTAG or DW) Just put breakpoints where needed.

I think the reason why BREAK was the natural choice for me was that the typical ASSERT implementation on windows looks like this:

[pseudo code]
if (!(Condition))
{
  DisplayErrorMessageBox(LineNumber, FileName, Condition);
  if (DebugButtonPressed) __asm int 3;
}

Where the

__asm int 3;

is, more or less, the x86 equivalent of the AVR's BREAK instruction.

I too do preffere to debug using JTAG.
And there my ASSERT macro works as expected... :wink:

Bertolt

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

bmildner wrote:
Are there AVRs that will not be moved to simulator2 (except for the EOLed ones)?

Our preliminary roadmap is to support all new AVR devices in simulator2 at the time they are introduced, but it will still take us some time to get up to speed with this.

Older devices will not necessarily be supported, we intend to add support for these when replacement devices/revisions are introduced. As an example, we support the PicoPower versions of the mega48 family (mega48P/88P/168P) but not the older non-P versions.

- roland