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?
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?
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.
require at least one pass from the programming interface to set the lock/fuse bits to permit it to function.
a program itself can write to the fuse/lock bits to bump hardware into higher security?
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.
However I don't think you can program fuzes with debug wire alone. (Could be wrong).
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.
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?
Did I miss something?
ps so I just looked at the diagram for the backpack and don't see a programming header.
NO, correct as usual :) that's exactly what is supposed to be. (Didn't you use the Dragon with the LCD backpack??)
ps so I just looked at the diagram for the backpack and don't see a programming header.
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. ;-)
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...
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
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:
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...
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.