Hello,
I'm not at all familiar with the AVR products that include the debug wire feature. My question is this: Can you use the feature to program a chip? That is, is it within the capabilities of the protocol?
debugWire Programming?
Author
Message
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29086 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Quote:
Not in the full sense of programming. It is used for debugging and as such it will automatically program the flash and eeprom when you start debugging or you do a build and run. It caanot be used for general purpose programming as the lock bits and fuses cannot be programmed.
Can you use the feature to program a chip?
Couple of things thing I've not seen spelled out so much.
ISP, JTAG, Debugwire can all be used for uploading memories. Flash, EEPROM, Ram.
Both Debug Wire and JTAG can be used for source level debugging. ISP can not.
ISP and JTAG can be used to set fuses. Debug Wire cannot set fuses.
A different set of pins are used for the ISP and JTAG ports. Debug Wire uses the Reset line for debugging. Thus is present on the ISP standard 6 and 10 pin headers.
Typically with debug wire parts you will have one header for both debug bugging (via debug wire) andf for production programming via ISP.
JTAG parts need a second connector for debugging via JTAG. And the JTAP port pins cannont be shared.
Debug wire is minimally invasive compared to the JTAG port because it uses the RESET pin for debugging. JTAG uses four pins which can only be used for JTAG when JTAG debugging is enabled.
OK,
I appreciate the time you've all put into answering my question.
JTAG limits are understood. I try to avoid multiplexing those pins on devices where JTAG has the possibility of alternate function. From experience, a controller or CPLD where I need those pins is either too small or soon will be.
From what has been posted and the documentation, Debug Wire seems to require at least one pass from the programming interface to set the lock/fuse bits to permit it to function. Thereafter it can modify normal program memory spaces. That seems to say that once set up, debug could be used to load a program. It may not be optimal, just theoretically do-able.
Do I understand correctly that a program itself can write to the fuse/lock bits to bump hardware into higher security?
Where all this is leading, of course, is understanding the feasibility of loading and debugging a part in-situ without having to share the SPI pins. On the 8-pin 'Tiny's that's a real consideration. Setting up a target in a socket before hand is an acceptable requirement if it eliminates the need for code space and dedicating or muxing a pin for boot loader use.
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29086 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Quote:
Don't set the DW yourself with ISP, let Studio do that for you at debugtime then follow the prompts. Don't forget to disable DW from WHITHIN a DW session or you will not be able to use ISP.require at least one pass from the programming interface to set the lock/fuse bits to permit it to function.
Quote:
Not that I know of. The fuses are theoretically off limit to your code.
a program itself can write to the fuse/lock bits to bump hardware into higher security?
Microsuffer wrote:
OK,Where all this is leading, of course, is understanding the feasibility of loading and debugging a part in-situ without having to share the SPI pins. On the 8-pin 'Tiny's that's a real consideration. Setting up a target in a socket before hand is an acceptable requirement if it eliminates the need for code space and dedicating or muxing a pin for boot loader use.
I've been doing work with the ATMega168 with the debugwire for the last two years. Pretty much all you need the SPI lines for is to initially put the device in debug wire mode. You only have to do that _once_.
So yes you could for instance put your tiny in a socket, put it in debugwire mode, then solder it to your board and go from there. That will totally work. However I don't think you can program fuzes with debug wire alone. (Could be wrong).
Depending on the application, you may not need to do very much to allow the ISP pins to be shareable.
-For example, with most general digital I/O it is often sufficient to simply connect the application circuitry to the shared pin via a series resistor. (Take care that any application inputs won't go haywire and result in unsafe operation in the presence of the ISP waveforms...)
-To share the ISP pins with a standard SPI bus where the AVR acts as the master, all you need to do is attach a pull-up or pull-down resistor to the slave-select lines (whichever polarity would be necessary to cause the line to default to the NON-SELECTED state when the AVR tri-states its pins) and then wire in the ISP connector as though it were just another node on the SPI bus.
Last Edited: Tue. Feb 13, 2007 - 01:34 PM
Quote:
However I don't think you can program fuzes with debug wire alone. (Could be wrong).
Totally correct.
And only the bootloader can bump the bootloader lock bits (but *not*
the general lock bits!).
Also, if you leave debugWire enabled, you effectively give up all
code protection features.
OK,
The part comes from the factory with ISP enabled. To get to dW you use the ISP and to go back to the ISP requires using the dW. And you have to be in ISP enabled state to throw the security locks; the program itself cannot. Bottom line on debugging, if I want to debug I'll have to provide either an ISP connector or probe pads.
By the way. The reference "from within the debug session" above makes me wonder if I shut down the debug session without shifting back to ISP enabled, can I re-establish a session to change back? Oops happen.
> if I shut down the debug session without shifting back to ISP enabled,
> can I re-establish a session to change back?
Yes, technically it works as follows:
If you set the DWEN fuse, and power-cycle, the /RESET pin will belong to
the debugWire engine. You are in dW mode.
Inside dW, there's no option to set fuses. (Basically, debugWire cannot
do anything a normal AVR program could not do either.) So in order to
get back, the software driving the JTAG ICE (probably AVR Studio in your
case, frequently AVRDUDE or AVaRICE in my case) has to initiate the way
return by issuing a "reset with moncom disabled" command. This will take
the AVR into reset state, and temporarily disconnect the /RESET line from
the debugWire engine -- until the next power cycle.
Thus, in this state, you can then issue normal ISP commands (using any
ISP programmer you prefer, but obviously, the JTAG ICE or Dragon would
be the natural choice). Using these, you can among other things also
disable the DWEN fuse. If you don't, the next power-cycle will return
you into debugWire mode.
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29086 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Quote:
No problem. You can leave the DW fuse set forever (well untill the chip dies :) )if you want to use the board for development only.
can I re-establish a session to change back? Oops happen.
Not having used DebugWire yet, I have a question.
Why can't I just put a 6 pin ISP header on target PCB. Then I can use ISP to set the DW fuse and use the RESET to do DW debugging, all with the same header?
Did I miss something?
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29086 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Quote:
NO, correct as usual :) that's exactly what is supposed to be. (Didn't you use the Dragon with the LCD backpack??) The only proviso is that DW cannot use the cap to ground in the reset pin, ISP can. The other consideration is that the DW (the Dragon at least) may put some loading on the Miso, Mosi and SCK lines when in DW mode. To overcome this POSSIBLE annoyance I have made a 6 way to 3 wire squid (+ - Reset) that I use when using any of those 3 pins for input. Most of the time there is no need for this.
Did I miss something?
ps so I just looked at the diagram for the backpack and don't see a programming header.
js wrote:
NO, correct as usual :) that's exactly what is supposed to be. (Didn't you use the Dragon with the LCD backpack??)
If you remember a week or two ago, I shared the sad story about slaying my Dragon. I have been so engrossed in the My_LCD serial backpack project, I haven't taken the time to order a new one. In addition, I spent me wad today, purchasing enough parts to build 20 Serial Backpacks.
js wrote:
ps so I just looked at the diagram for the backpack and don't see a programming header.
That is correct. I chose to not put a programming header as, once it is programmed, there shouldn't be any need to re-program it. I have added the method that I have been using to do the initial programming of the serial backpack to the manual.
The problem is that, I can't update the My_LCD project in the projects forum, due to some sort of technical difficulties. Dean and Bren't have both set up hosting for me. I haven't yet had the time to log on and update the host sites with the newest version of the manual.
Though I plan on using their host sites, I'm a bit reluctant to add/update at the moment because I have been (seemingly) updating continuously, and Dean at least, has a bandwidth limitation and I don't want to abuse that.
I do think I am going to add some specific usage examples as, someone made the statement that a full working example program wasn't good enough.
I have also been thinking about adding an example on building custom characters, which, has been brought up several times on the forum.
The manual is currently 26 pages. At what point will it be acceptable, I don't know. But, 26 pages for a PCB that is 1" x 1.8" in area seems a bit out of kilter, especially when the nearest compeditor only provides two pages.
When I worked on the B-1 Bomber project, they told me that the plane doesn't fly until the documentation equals the weight of the aircraft. Nice to know that this phenominum has made the transition to the hobby world. ;-)
Microsuffer wrote:
When I worked on the B-1 Bomber project, they told me that the plane doesn't fly until the documentation equals the weight of the aircraft. Nice to know that this phenominum has made the transition to the hobby world. ;-)
Some of us, at least...
Level: Raving Lunatic
Joined: Sun. Aug 13, 2006
Posts: 7472 View posts
Location: Bellingham, WA - USA
Quote:
26 pages for a PCB that is 1" x 1.8" in area seems a bit out of kilter, especially when the nearest compeditor only provides two pages
yeah, but their circuit board is 8-1/2 by 11...
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Quote:
I have been (seemingly) updating continuously, and Dean at least, has a bandwidth limitation and I don't want to abuse that.
Don't be afraid Carl, you won't break my hosting :). I've only used in the realms of 15% of my limit this month (and that includes many site-reuploads of 10Mb each) so plug away. Feel free to use that FTP account I gave you for whatever you like, so long as it remains AVR and/or AVRFreaks-centric. I'll warn you if my limit is anywhere near close to exceeded.
- Dean :twisted:
abcminiuser wrote:
Quote:
I have been (seemingly) updating continuously, and Dean at least, has a bandwidth limitation and I don't want to abuse that.
Don't be afraid Carl, you won't break my hosting :). I've only used in the realms of 15% of my limit this month (and that includes many site-reuploads of 10Mb each) so plug away. Feel free to use that FTP account I gave you for whatever you like, so long as it remains AVR and/or AVRFreaks-centric. I'll warn you if my limit is anywhere near close to exceeded.
- Dean :twisted:
Thanks Dean.
I'm at work right now. I'll post it later tonight, when I get home - if I get home... It's raining ice here right now and 50 miles is a long way to drive on ice...
microcarl wrote:
Not having used DebugWire yet, I have a question.Why can't I just put a 6 pin ISP header on target PCB. Then I can use ISP to set the DW fuse and use the RESET to do DW debugging, all with the same header?
Did I miss something?
Nope, that what I do no problem. One thing to watch out for is that the jtagmkii uses a 10 pin header that has a pinout that is different than the stk500's 10 pin header.
I ended up making a little 10pin to 6 pin do'hicky for my first project. For the second and third projects I've just layed out a 10 pin header that directly plugs into the jtagmkii connector.