Debugging Arduino Uno Code on Atmel Studio 7 Simulator using serial

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

Hello,
maybe I'm totally wrong in this forum.
I would like to debug c++ code using the Atmel Studio 7 (build 1645) avr simulator and printing serial.print output to the Visual micro terminal window.

 

1.) The terminal window stays quiet. I have no idea to which port to set it to get the simulator output. It's set to the programming port com8 with the device on. But only the messages from (de)-activation are shown.

 

2.) At the moment im using the Visual micro trial version with arduino uno. But gdb-debugging should only work for the zero.
Can i use full gdb-debugging or not or do apply additional restrictions?

 

3.) Im stepping through the code but F10 - step over does sometimes do not step over but step into. E.g. creating a new object steps into the "new" and the constructor instead of stepping over as wanted. Or some library-routine were unwanted entered.
All optimizations turned off, mrelax off. Ive tried also the "best debugger experience" setting.

 

4.) variable tooltips show no values. (least important)

 

Any hints on the problems?

Is the simulator capable of doing complex debugging or do I'm expecting to much.
Is there another emulator/simulator capable of complex debugging available.

 

Many thanx in advance.

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

Atmel Studio 7 can import Arduino sketches directly - there is no need to Visual Micro.

 

 

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

Ok. But i tried it without using Visual Micro in the first place.

It ends up with a totally unclear directory structure and lots of compiler errors and warnings by a code which compiles in the arduino ide just fine.
Yes i know about the meaning of warning levels.

After fiddeling with this one day around i decided to install Visual Micro which installs into a plain directory. and compiling works.

 

Do you have reasons to believe that uninstalling the visual micro plugin solves the my problems with the simulator?

Can you tell me more about them?

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

Not many people here use Visual Micro (it is (or rather was) a very annoying "nagware") so your best bet is to approach them directly for support.

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

or to pursue getting the native AS7 import to work ...

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

Not many people here use Visual Micro (it is (or rather was) a very annoying "nagware") so your best bet is to approach them directly for support.

This is an important info to me.
yes ive asked them first, but they said the simulator is not in their responsibiltiy. I should ask Atmel.

 

I'm new to Atmel Studio. So before i spend again a lot of time into the Atmel Studio - One Question:
Step Over works fine in any case using the simulator and its possible to read serial output from the simulator?

(without visual micro)

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

Personally,   I find the Arduino IDE far more convenient for developing and running Arduino programs.

 

Occasionally I might want to view machine registers.   In which case I use debugWIRE on an XMINI-328P or an ATMEL-ICE on a regular Uno.

 

When Visual Micro first appeared,   it would make life easy with a Uno without having a hardware debugWIRE debugger.

However VM would deluge you with SPAM for evermore.

 

I have no idea whether buying a VM licence would give you your PC back.    I will not touch Visual Micro with a bargepole.

 

I suggest that you just add extra Serial.print() statements to your regular Arduino code.    This is a well established method.

 

I am sure that some happy VM customers exist.    Perhaps they can advise.

 

David.

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

For serial print debug use, connect a serial/usb adapter to the h/w serial port on the UNO and use a terminal program such as realterm or putty.

 

Jim

 

 

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

Ok, thanks.

 

But what about the simulator? Isn't it usable? with serial?

Last Edited: Tue. Jan 23, 2018 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

phunkz wrote:
Isn't it usable? with serial?
The simulator is a simulation of the AVR core and the internal peripherals. While it has the possibility of "stimuli and logging" it doesn't really simulate anything that happens "outside" the AVR. If you want something like that you probably want to take a look at something like Proteus.

 

But I understood you were talking about an Arduino here. Serial.print() just "always works" so why not just wire that up to your favourite terminal and use real Arduino hardware rather than some half-baked simulation anyway?

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

clawson wrote:
The simulator is a simulation of the AVR core and the internal peripherals ... it doesn't really simulate anything that happens "outside" the AVR.

The Keil 8051 simulator has (or had?) the facility to use the PC's actual COM port(s) to feed into its simulation from an external device, and pass output from the simulation to an external device.

 

I take it the AVR simulator doesn't have that, then?

 

(although I don't see that it would really be very useful here anyhow)

 

why not just wire that up to your favourite terminal and use real Arduino hardware rather than some half-baked simulation anyway?

Absolutely!

 

With on-chip debug, I really don't see the point of simulation here 

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

Well, there is an unconsistency (unless my English is very bad) between title and OP '1rst sentence.

Maybe he wanted to use a debugger (and a user friendly  debugger might be better than serial.print-s-, the latter  leading to bad habbits), which lacks with Arduino (their IDE improves ... slowly) ; this lack can led to bad habits

Last Edited: Tue. Jan 23, 2018 - 05:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I take it the AVR simulator doesn't have that, then?
AS4 + Hapsim used to offer this. It seems Atmel weren't interested in implementing "external peripherals" in any of their sims (then or now) but Hapsim "hacked" into the AS4 simulator DLLs and added some things:

 

 

However (unlike Proteus) it was not an exactly perfect external peripheral simulator. While it offered "UART terminal" and "HD44780 LCD" for example you could write code that had the most atrocious timing muck ups and yet it would still appear to simulate those things correctly. In Proteus on the other hand it will actually tell you that "UART baud rate is -17% and will never work" or "your E pulses to HD44780 are 220ns too short" or whatever.

 

The other downside of Hapsim was that each time Atmel released a new AS4.nn then there had to be a new Hapsim with the DLL "hook addresses" fixed up for the new issue of AS4.

 

But it was kind of "fun" and it gave you a completely "no hardware required" simulation system on which you could make up "real circuits". The only thing (AFAIK) that comes  close to that these days is Proteus.

 

I don't see much point trying to use the AS7 simulator for Arduino - most of the stuff that needs to be tested with Arduino are the driving of external peripherals and AS7 just doesn't offer that.

 

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

clawson wrote:
you could write code that had the most atrocious timing muck ups and yet it would still appear to simulate those things correctly

IIRC,  that was similar in Keil: the baud rate, etc, was set by the PC configuration - so the 8051 code could be totally messing-up the config, but the simulation would "work".

 

 

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

I suggest that you just add extra Serial.print() statements to your regular Arduino code.    This is a well established method.

I know and ive used it. But ive written a pretty complex program with some pretty complex classes.
And im looking for an acceptable way of debugging it.

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

So use the on-chip debug to debug on the target hardware.

 

Of course, this doesn't stop you also having  Serial.print() statements sending stuff to a terminal.

 

In fact, that's the way I would normally do stuff.

 

  • On-chip debug is great for when you want to stop & examine the internal state,
    or single-step the fine detail of a particular part of the code.
     
  • Serial output is great for watching the long-term operation of the system.

 

#DebuggerPlusSerial

 

Last Edited: Tue. Jan 30, 2018 - 01:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK I understood. Even if the program runs mostly using internal resources (running a state-machine, doing some compression/encryption and storing cleverly in EEPROM (which is the buggy-part) and flashing

some statusleds in different patterns without blocking )

the simulator is NOT capable of doing some useful debugging or nobody do use it this way. (but what way then?)

 

Everybody talks about on chip debugging but to this time I've bought no hardware debugger (If i had ived asked other questions.)

because i don't thought about going very deep into this arduino thing and ive got just a few anoyying bugs for which the download and usage of a simulator seems a fast and easy way to fix.

And emulators (not simulators) mostly do very good jobs in supporting debugging. So i was keen to use this one also.

 

Thanks for the discussion and sharing your time and knowledge.

 

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

phunkz wrote:
(but what way then?)
The simulator is great if you want to try out one specific function (like making sure that you have configured a timer so the ISR() really is called every 2048 CPU cycles or something) but it's utility is quickly lost with "large"/"complex" software. Don't expect to be able to debug all the complex interactions in large code using the simulator alone because, like I said, it has almost no simulation of external, real-world events and let's face it that all but the most trivial micro designs are "system" with lots of things interacting with the CPU not just a lone CPU with nothing around it. So for a "system simulation" you would need something that could simulate the precise operation of everything that was attached to the CPU too. Proteus actually attempts to do this (which is presumably why it costs £300?) and for the most part seems to succeed so we do see posts here where folks have designed quite complex "complete solutions" in simulation alone using only Proteus. But AS7 is not like that. Yes it has simuli and logging:

 

http://www.microchip.com/webdoc/...

 

but are you really going to prepare a stimuli "script" that mimics every last external signal and event that is coming into the micro?

 

The alternative to all this is "real silicon". The 328 in an Arduino has an On Chip Debug (OCD) interface called debugWire which allows a device (preferably Atmel-ICE) to be connected to the chip so it can now sit in the middle of a complete system with all the real external peripherals around it on the PCB acting as they do in real life and now you can study exactly what is going on at the heart of the AVR and all its internal peripherals as the result of real-world stimuli that are occurring in the circuit around the chip. Now you really can see the details and nuances of how systems in the AVR interact when operating "for real".

 

If you are programming complex systems then personally I don't see any real alternative to using OCD/ICE in order to debug the interactions of the "complete system". Of course quality software is written in a modular way and if done right each module can be tested through its entire range of operating in unit testing so I guess that without OCD/ICE you could get about 90% of the way there. But there comes a day where you connect all these individually proven modules and they begin to interact and it's often difficult to test that with anything but invasive hardware debuggers.

 

So if you have hit the "quite complex" design point I'd say the $50..$100 that an Atmel-ICE costs is probably a worthwhile investment.

 

Your mileage may vary.

 

(oh and note that you may need to make a small mod to an Arduino circuit to enable the ICE to work without interference from other parts of the Arduino reset circuitry)

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

Alternatively, get an ATMega328P XPlained Mini:

 

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATMEGA328P-XMINI

 

It costs less than a tenner, and has the debug interface built-in.

 

It also has holes for Arduino headers - so you can even attach shields.

 

 

 

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

I am sure that someone must be using Visual Micro and be happy.  Perhaps they can offer advice.

 

An XMINI-328P costs about $10.   Solder Arduino headers to it.   And you have hardware debugging on an (8MHz) Uno for $11.

An ATMEL-ICE costs about $99.    You can use it with any AVR, Xmega,  ARM, UC32 chip.   (and is a lot faster than the XMINI)

 

European prices tend to be the same dollar quantity in UK pounds or Euros.

 

I find it easier to develop  in the Arduino IDE.   Occasionally I export to AS7 for ATMEL-ICE (or XMINI)

 

Quite honestly.   If you have a genuine project,  it is worth buying an ATMEL-ICE.

 

David.

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

david.prentice wrote:
If you have a genuine project,  it is worth buying an ATMEL-ICE.

Absolutely.

 

Even for a hobbyist, think what $99 would buy you for basic equipment in any other hobby - it wouldn't get you very far, say, as a model railway enthusiast: