debugging and AVR

[Simon]

Now that my projects are gradually getting more complex I'm looking at the possibility of doing debugging. But I'm not entirely clear on the nuts and bolts of this.

So at the moment I have an ATMega168, it supports debug wire which is a single wire connection that coincides with the reset pin. So my main question is when in debug mode is the chip responding to actual real world pin inputs and outputs or is it all simulated from atmel studio.

How do i actually follow the path my program is taking. As far as i know i can set a break point to read out the status at that point but if a program never gets to that point how do i know where it actually is ?

[sunnyhighway]

Set a breakpoint on a line where you know it wil hit.
Examine the the register and make an educated guess where it should go from there and set a new breakpoint a bit further down.
If the breakpoint does not get hit, your educated guess was wrong or your program logic is wrong.

[hans]

If a breakpoint is not hitting, the code is probably not working as you intend it to work
Then, set breakpoints to relevant code that is used, and narrow down to the point where for example an if condition is not met correctly.
With the debugging you can see what variables are present at the time, if these are correct, etc.

Most debuggers also support a HALT  function (usally marked as a pause icon), which will stop the program at the time it happened to be executing. This can be of use when your debugging seemed to have stopped, but for example the program is hung in a while() loop that is never ending..

[Simon]

Right, So is the uC actually interacting with the I/O pins or do i have to simulate inputs and outputs.

[westfw]

For debugwire, the uC is actually interacting with the IO pins.

[Simon]

Excellent

[legacy]

about PDI i was told that the AVR-dragon is issued about that, people are claiming that PDI is not working with AVR-dragon and they suggest to switch/buy the new ICE

any comments about that ?

[Simon]

Well from what i know ICE is the latest debugger and set to replace everything except the AVR one which I beleive is much more advanced and may be an emulator of some sort, make sure you don't end up with the similar looking, older and more expensive ICE-3

[V_King]

when I stared with arduino, I was using serial.print for debugging. after moving to programming directly atmel avrs, bought avr dragon for programming and debugging, but the PDI interface was very slow, and very limited. went back to using uart and logic analysers for debugging.

on the other hand the new atmel-ICE range looks really good - cheaper than dragon, supports AVR and ARM platforms and has nice case.

[Simon]

Yes i think Atmel have finally pulled their finger out and got a cheap debugging platform out which was their main downfall in regard to their main competitor (PIC).

I'm not working with arduino anymore except occasionally and for work I certainly don't want to be so limited.

[V_King]

connecting uart to a cheap uart to usb adapter and having a small function to print either the variable values or just steps through the code, you quite quickly can determine where the problems are. 8bit avrs seem to be very limited with their capabilities, thei have something, to tick the boxes, but it does not seem to be working that well. would not mind to be proven wrong

68hc12s had the best debugging capabilities I've ever used, you can easily step through code, and see all the info required, just like with software debuggers.

[FreddyVictor]

I'm not working with arduino anymore except occasionally and for work I certainly don't want to be so limited.

just use arduino board(s) as if they are ATmega, so you get cheap dev boards - also available FC boards with sensors
obviously they must have ISP connector on them tho'

[Simon]

Yes there is a CNC system that uses an arduino board but a totally different software in the ATMega328, I had a guy contact me and ask me if i could sell him an arduino chip with this different firmware in it, having found the firmware he was asking for I burnt it to the chip for him instead of the arduino bootloader.

As the systems I work on are far more complex than an arduino in terms of interfacing and as it's custom stuff for customers (often military) I have to do a custom PCB each time.

[Brutte]

Your best option with AVR8 is to scrap it, IMHO.

Looks to me you are starting with AVR8s (although I must admit i didn't study your 7k posts) and in such situation I suggest you should invest your time into something with decent debugging support. Could be ARM, MIPS, Piccolo etc. Do not waste your time with old AVR8s.
I am not talking about starting from the biggest Jumbo. Buy some simple one, possibly a kit with a built-in debugger. Could be from Atmel, could be from Microchip, Freescale, Nuvoton, Infineon, whichever.

Once you tried debugging ARMv7M (Cortex M3/M4) I can assure you that you would never touch an AVR8 or PIC8 debugger again. If you want to try out debugging AVR8s - google "build your own JTAG clone". Works fine with AVR Studio 4.19b730 or with any Avarice but only* with classic AVR8s (m16,m32,m128 and some other).

By the way - AFAIK you cannot debug arduino, with or without debugger.

[Bored@Work]

I'd say we have a PEBCAC here.

[Simon]

Your best option with AVR8 is to scrap it, IMHO.

Looks to me you are starting with AVR8s (although I must admit i didn't study your 7k posts) and in such situation I suggest you should invest your time into something with decent debugging support. Could be ARM, MIPS, Piccolo etc. Do not waste your time with old AVR8s.
I am not talking about starting from the biggest Jumbo. Buy some simple one, possibly a kit with a built-in debugger. Could be from Atmel, could be from Microchip, Freescale, Nuvoton, Infineon, whichever.

Once you tried debugging ARMv7M (Cortex M3/M4) I can assure you that you would never touch an AVR8 or PIC8 debugger again. If you want to try out debugging AVR8s - google "build your own JTAG clone". Works fine with AVR Studio 4.19b730 or with any Avarice but only* with classic AVR8s (m16,m32,m128 and some other).

By the way - AFAIK you cannot debug arduino, with or without debugger.

Yes i have just started really in microcontrollers full stop. I started using arduino 2 years ago as i realized that I'd never learn C and an uC architecture at once. Once I had some arduino under my belt I started playing around with AVR's basically with ones that also had arduino support so that I had a safety net. I'm now doing projects on AVR8 with no prospect of falling onto arduino as a backup and I'm now progressing through the basics in C when doing a progra from scratch in C.

I will eventually get to ARM at the moment there is no need and projects are simple and I'd like to improve on my C skills before taking on more complicated architectures, just reading a C book does not do it for me i need to progress in C and using the architecture together.

I have bought at Atemel ICE which will work from AVR through to ARM.

[Brutte]

I will eventually get to ARM

And the play would start from the very beginning then.

and I'd like to improve on my C skills

Do not use uCs for learning C. Embedded stuff is much more challenging. Even Cortex-M cannot compete with a full blown x86 environment for learning C. Use uCs for learning uCs (when you already know C).

[Simon]

Here and now I have no requirement to program a PC so uC's it is. My end game is uC's so......

[Kremmen]

Opinions are like a-holes; everyone's got at least one. So here's mine: By all means go ahead and learn C (and C++) on a MCU.

While it is a reasonable argument that debugging in a PC is "easier" due to the much more resourceful environment and while it is true that a PC programming environment is much "richer", in the end you embedded code is going to have to work in an embedded environment. To me it has never been worth the bother to maintain 2 distinct environments with their separate issues and differing practices. With C and especially C++ it is the case that for embedded development you don't actually need ( or want) to learn the "full" language with all the runtime candy available for regular computing environments. The habits and ways you learn in those environments are not fully repeatable in embedded environments and if you do proper development then you anyway need to come up with ways to QA your code in the final environment. Conversely, learning the hands on practice of debugging arbitrary code fragments in the embedded environment with proper HW support  is precisely what you will need all the time while doing the actual thing. I'm sure many PC programmers don't really know how to do this and how easy it is once you get the hang of it. And you _will_ get information that is totally unobtainable in the PC environment. So why bother doing it twice, more or less?

I do grant that in case you have a ready to go PC programming environment, it will facilitate development of "pure" computing code without reference to specific embedded peripherals or I/O.

As to debugging, just one suggestion: invest in the best debug support you can afford. You mention you got the latest ICE from Atmel and that should work. I have the old JTAG ICE Mk II and ICE 3 but those have been unused since i started ARM development and acquired a Segger J-Link to debug that environment. It is pricey but will do "anything", unlimited breakpoints included. Zero issues debugging code with Atmel Studio + J-Link combo (J-link of course supports all/most common tools and mfgs).

Do bear in mind that in at least one respect software production is like playing chess: While the rules of piece movements in chess ( / the syntax of a programming language / ) are rather simple, the strategy and tactics to win a game ( / program architecture, structure and application of formal algorithms / ) can be very complex, mentally demanding and subtle. The skills of software architecture and design are separate from the skill of writing code in a specific language. A good architecture and design are only loosely coupled to the environment at hand. As much of it as feasible should be abstracted above the actual hardware and that part is the one you can profitably develop and debug in a PC environment.

There are some obvious skills a _programmer_ should have apart from knowing the syntax of his/her chosen language(s). Anyone who has created an embedded piece of code knows something about the embedded peripherals (well, maybe not all of the Arduino crowd...) so i won't go into that here. For those majoring in CS the following is a no-brainer but many embedded code developers come originally from other walks of life and may not have encountered these so here is my list. It is not the idea to cram all of these in one piece of code but at least one should know they exist, so as to be able to learn more when needed.
Others can add their favorite skills if i miss something obvious:

*Fundamentals:
- basic data structures:
  --arrays (dense, sparse),
  --lists (singly and doubly linked),
  --trees (esp. binary trees),
  --stacks, bags, heaps
- basic sort and search algorithms
  --bubble sort, quicksort,
  --binary search,
- dynamic allocation (and the risks of it),

*Multitasking
- the concept of computation context,
- context switching,
- interrupts; interrupt context,
- interprocess communication:
  --queues, pipes,
  --semaphores, mutexes

*Interfacing:
- information hiding,
- abstraction (esp. hardware abstraction),
- signal conditioning (esp. for physical interfaces),

and so on ad nauseam... more advanced concepts such as numerical and seminumerical methods and algorithms &c &c. _These_ can and should be studied outside the embedded environment.

[Simon]

You make my argument perfectly, I have plenty to learn in C but learning to print stuff on a PC screen or take in keystrokes is a waste of my time and easily learnt later if I have to switch. As i have to learn by doing (slight dyslexia and attention deficit has been suggested) there is no point in just reading a C book and going through the motions. I learn stuff as the need arises and try to stay just slightly ahead of my needs so that I know what there is there when I may come to need it. I've not needed to tackle any of what is on your list but will get there no doubt.

[eurofox]

Simon,

Maybe this will help you to start

[Simon]

Thanks

[Brutte]

I have plenty to learn in C but learning to print stuff on a PC screen or take in keystrokes is a waste of my time and easily learnt later if I have to switch.

Once you find out how difficult debugging an algorithm on a uC is (when compared to x86) please expect me to quote you.
The time relations of an embedded application is of course more difficult to test with x86. All the other stuff (including learning C syntax, multitasking, writing algorithms etc) is not. And of course x86 does not consist of only keyboard and a display. It also has USB ports, UARTs, LPTs, soundcard and a bunch of other gear connected (typically).

By the way, AFAIK* you won't be able to learn multitasking (OS) with AVR8 because ASes (Atmel Studio) and their AVR8 debugger does not support OS awareness. But that is a minor problem - it also does not support stack unwinding so you can forget about skipping through stack frames.

*I never used ASes but this is what users from avrfreaks mentioned.

[Simon]

Well I need an IDE that does not require a degree, even microchip finally upped their game and came out with a better IDE platform that tried to help the user.

My requirements for C are on uC's learning to use x86 peripherals is pointless at this stage if when i shift to an uC I then have to start going through setting up registers.

When there is a requirement I'll move to an ARM based chip but i probably need to have more C knowledge before I can use them properly. I'm aware of FreeRTOS but i'm not sure if it will help me at all.

[Kremmen]

Some say that he has three.. err sorry, no. That was Top Gear and The Stig. Let's restart. Some say that Atmel Studio is bloatware and therefore bad. Bloated it may be but who cares, disk capacity is cheap. Bad it definitely isn't, in fact quite the opposite. If one develops for Atmel's chips AS is a no-brainer especially since it now supports ARM chips as well, with all the features in place.
Again, some say that Atmel's Software Framework (ASF) is bloated and therefore bad. Again, bloated it may be but then you don't need to include it in your final product as such. It works very well to get stuff working quickly so you gan get ahead and later you can replace the bloated parts with your own supremely streamlined wundercode. The point: FreeRTOS support is included in ASF, at least for ARMs. And i know for a fact that FreeRTOS works without problems with Mega and XMega chips, having ported it there myself years ago.
Another OS of interest is ChibiOS, officially supported for a lot of ARMs and specifically for ATMegas, esp. 328p and 1280. There is even a HAL layer where a lot of peripherals are supported for the 8-bit AVRs as well. I cannot emphasize enough the benefit of learning to use a RTOS. There are those who will go to guite some lengths to avoid an OS but i do the exact opposite. If a project is simple then so will the OS implementation be and you usually don't hit any resource limitations. If the converse is true you are likely to have a more robust chip where again the OS won't become a bottleneck. The benefit of "standardizing" the use of RTOS is that your solution architectures also become standardized. You then have a far better chance than the proverbial snowball of actually making sense of a project a couple years down the road.

[Kostas]

Atmel Studio might be bloatware, but you have the option to uninstall many of its components, therefore getting back quite a lot of disk space, if its important to you. For instance, you can uninstall any of the AVR32, AVR8 and ARM toolchains independently. You can also uninstall the Atmel Software Foundation (ASF) stuff completely if you're not interested, which will not only reduce disk usage, but also somewhat shorten startup time.

[Bukurat]

By the way - AFAIK you cannot debug arduino, with or without debugger.

AFAIK Arduino isn't an MCU or a programming language. It's a platform.

If you move away away from the Ardrino IDE to either Atmel Studio or Visual Studio and add the visual micro addon  and pay the man a few dollars you can debug code running on any of the Atmel MCUs.

[Simon]

The thing is if you want to debug an arduino it's probably time you moved to atmel studio and C as most of your debug points of the data you get will be form arduino platform code and libraries and not your own.

[Kostas]

By the way - AFAIK you cannot debug arduino, with or without debugger.

AFAIK Arduino isn't an MCU or a programming language. It's a platform.

If you move away away from the Ardrino IDE to either Atmel Studio or Visual Studio and add the visual micro addon  and pay the man a few dollars you can debug code running on any of the Atmel MCUs.

It's not the ic on an arduino that can't be debugged; the ATMega328 supports debugwire. It is the way the arduino is designed that it has to be modified in order to be used with a debugger like the AVR Dragon. IIRC you need to remove a capacitor, or cut a trace, or whatever it might be (I never had an arduino).

[Kremmen]

There are many different Arduinos but at least the Uno should support bog standard Atmel debugwire without modification. It has the standard 6 pin header with all the signals in place. There is a connection from the reset line to the auxiliary USB processor but that should not cause any issues as far as i can see.

[Bukurat]

There are many different Arduinos but at least the Uno should support bog standard Atmel debugwire without modification. It has the standard 6 pin header with all the signals in place. There is a connection from the reset line to the auxiliary USB processor but that should not cause any issues as far as i can see.

Looks like the mod is simple. Cut a track between two specially prepared  pads and optionally install a jumper.
http://www.hilltop-cottage.info/blogs/adam/debugging-arduino-using-debugwire-atmel-studio-and-an-avr-dragon/

[Kremmen]

Actually you (and the link) are correct, of course. I failed to consider that the other end of the cap is not floating but tied to something - probably logic high. So it will potentially affect the reset signal from the debugger...

[Bukurat]

Actually you (and the link) are correct, of course. I failed to consider that the other end of the cap is not floating but tied to something - probably logic high. So it will potentially affect the reset signal from the debugger...

From I've read in places, the cap is there to provide a reset pulse when a new program is being loaded. It saves having to press the reset button on the board.

[Kremmen]

Exactly. The pulse is generated by the auxiliary USB processor upon progam load and that's where i made my careless mistake. The cap of course isolates the processor signal lines so there is no impact in the DC domain, but the reset pulse from the debugger will see the cap since there is the output impedance of the aux processor I/O line on the other side of the cap. Thus it can/will distort the reset pulse unless the cap is defeated somehow.

[Simon]

When i read about debug wire in the atmega168 datasheet they were clear that there couldnot be a capacitor and stated that at least 10K should be the value of the reset pin pullup.

I have blown an AVRISP MK2 before trying to program lines that had too little resistance on them, I don't know if the ICE is equally "fragile"