hello,
to my surprise I found a hint on the atmel homepage, that the ATJTAGICE mk-II already exists. It supports JTAG and debugWire interface and is connectable through Serial port or USB to the PC.
Does anybody have any experience with this tool already?
regards
gerhard
They have not exactly made a song and dance about it, so I expect it to be pretty much the same as the existing JTAGICE, but with a different interface.
http://www.atmel.com/dyn/product...
Sacha.
I see there is no support for the Mega8, I guess we will have to use the Mega88 for debugging Mega8 code or.......perhaps the Mega8 is old hat :-) Not that it matters if we can get a better, pin compatible chip at a lower price.
The JTAGICE mk-II PDF file refers to the following supported AVR devices;
ATmega329
ATmega3290
ATmega649
ATmega6490
ATmega1281
ATmega1280
ATmega256
ATmega2560
where do you get informaion for these parts?
hello,
i already found that pdf but didn't care abotu the list of supported devices.
it's interesting that obviously the atmega256 will have a jtag interface and not debugwire which is mentioned in some other pdf's of atmel.
it would be a good idea of atmel to clarify the future situation!
regards
gerhard
Hi,
I have seen the JTAGICE-2 yesterday at a exhibition Embedded World here in germany.
The people from Atmel told me that it should be available in March. It supports JTAG and debug wire. By the way, it has an USB interface too.
Very nice...
Is it possible to program flash memory with a JTAGICE-2 connected to the debugwire are do you still need an ISP with its three port attachment?
To me, your question seems to mix apples, oranges, & pears and ends up as fruit salad.
You mentioned three separate methods of ISP. Each uses different connection pin(s) and protocol. The answer is no.
Lee
Hi,
Is it possible to program flash memory with a JTAGICE-2 connected to the debugwire
Like the current JTAG ICE, it should not only be possible, but required to actually debug!
-Colin
I know that the original JTAGICE could be used as a programmer; however, the flyer for the JTAGICE-II does not mention programming flash. Also, the documentation for the Mega44/88/168 briefly describes the debugwire interface and makes a big deal about the sole register that interfaces the debugwire and is dedicated to in-circuit-emulation. As far as I know, there are three way to program flash in AVRs: in-circuit-programming, parallel programming, and JTAG programming. If debugwire programming were possible, there would be four ways. The only documented programming done by debugwire is insertion and abstraction of break points. It would be great if one, single-pin tool did ICE and programming. It would be wonderful to only worry about one pin when designing for in-circuit-programming (currently I have to fret over four pins -- reset, sclk, miso, mosi). It would also be nice if Atmel published the debugwire protocol.
Hi,
Hmm I see your point. I really can't imagine they wouldn't add the ability to program, but I guess it IS possible you need to use another way to program!
Using the debugwire would be more of a hassle then - needing another tool connected in to program, etc.
-Colin
If you read the quick start guide for the new mkII JTAGICE and the new (1/04) Mega48/88/168 datasheet, it's fairly clear you can program the flash via the one-wire interface. In fact, the quick start guide states the regular ISP is disabled to allow full use of the reset pin while using the debugWIRE interface. There's a new fuse to do this. So until you reset that fuse, via debugWIRE, the device won't even accept regular programming via the usual SPI interface.
I would, however, expect programming flash via debugWIRE to be slower than ISP or JTAG.
Interesting interpretation Rocket Scientist -- it isn’t at all clear to me that the JTAGICE mkII will program flash or eeprom. Unlike the User Guide for the JTAGICE mkI, the Quick Start Guide for the JTAGICE mkII does not state that the unit will program. A whole section of the JTAGICE mkI User Guide, section 3.3, is dedicated to describing the programming abilities of the mkI. These is no text in the mkII Quick Start Guide stating that the mkII will program flash or eeprom (inserting and abstracting breakpoints is not the same as writing a program to flash). Just because it would be a major pain to develop with a mkII that can’t program does not mean that Atmel didn’t design it with this limitation. Until we have a definitive statement from Atmel on this issue, or Atmel documents the debugWire protocol, or someone who actually owns a mkII says in this forum that he/she can download a program into flash with the mkII, I will not assume that the JTAGICE mkII has the ability to download programs/data into flash or eeprom. And, I definitely will not fork out $300 USD to find out.
I certainly don't have lots of faith in Atmel where tools are concerned, but the data sheet does say "to program the different non-volatile memories" in the debugWIRE section. The Quick Start guide says "Once the DWEN fuse is programmed, only three pins are needed for further debugging the microcontroller." The three pins are power, ground and reset.
I agree the above statements are not 100% definitive, but considering using the debugWIRE disables the regular ISP programming (the debugWIRE parts don't even have JTAG programming) it just doesn't seem reasonable that you couldn't program the flash memory via debugWIRE. Otherwise, as someone pointed out earlier in this thread, it would be very difficult to do any real debugging.
If they release it on time (mid March) we shouldn't have long to find out just how it works.
Don't forget that we also need support in AVRStudio for the new JTAG-II before we can use it for anything else that an expensive desk decoration.
Looking back at history and considering that Atmel have just barely succeded to make the old JTAG work reasonably in 4.08, I would expect the JTAG-II to be fully supported in AVRStudio 7.44, which should be ready anytime soon this century.
I was hoping, probably beyond all reason, that the mkII just might use the same commands as the old JTAGICE (at least via serial) and ship with internal firmware that works with 4.08? If not, and 4.08 doesn't already include (working) support for it, I agree we're in trouble.
You should join the Studio Crashes Thread in the Studio4 forum. I made similar points about the state of Atmel tools there.
It sure would be nice to have ANY sort of usable emulator for the 32pin Mega parts! I've tried the ICE50 and it's basically useless (apparently IAR agrees as they don't support it). I have to believe the ICE40 is just about as bad.
If Atmel would just release the protocol for Debugwire, we could develop our own inexpensive debugger/programmer. This concept of single wire debugging has to be the ultimate in simplistic emulation. Insertion of software breakpoints and extraction of register info was possible early in AVR history using homebuilt ISP devices and AVRMON. Something similar may be possible with Debugwire if only Atmel would publish the protocol. I think the hobby market would increase substantially if a programmer/emulator could be built for under $20 USD.
Yes, more open specifications would be a good thing. In fact, there's a strong argument for just making all of AVR Studio open source.
Atmel doesn't exactly have a good history for developing and maintaining their tools. Opening everything up would allow 3rd party tool developers (including the WinAVR project) to deliver full featured tools for the AVR platform. Some speculate the only reason Atmel doesn't make the free AVR Studio open source is because they are "in bed with" IAR and don't want to risk that relationship.
Considering IAR doesn't provide a way to run ANY ICE with the 32 pin mega parts (they don't support the so far nearly worthless ICE40/50), there's a big hole left behind. IAR also, as we all know, is priced out of reach for many AVR developers--even some commercial ones.
Since you mentioned WinAVR...
There are already Open Source tools available, that are cross-platform as well:
GDB: GNU Debugger
Insight: GDB + GUI
SimulAVR: Works with GDB / Insight to provide AVR simulation.
AVaRICE: Works with GDB / Insight to provide AVR emulation via JTAG ICE.
(All of these are included in WinAVR.)
What is really needed is more people to help work on these projects to get them farther along, especially SimulAVR. These tools could be made into a viable alternative to AVR Studio.
Yes, but my point is AVaRICE is dependent on Atmel releasing the specs or time-intensive reverse engineering to support the new mkII JTAGICE. And how long will it be before the open source community writes their own USB device drivers for the mkII? I suspect a long time. USB drivers are not an easy thing--and nearly impossible if you don't have the spec.
I'm all for more people working on the WinAVR project. But it would be much easier if AVR Studio and all the hardware tools were fully open from Atmel.
If Atmel cannot give people the tools their developers want, and they don't make any money off the tools anyway, they should really open everything up. It would help them sell a lot more MCUs--which is, after all, what they're in business to do. They should not be in business to protect companies like IAR--a company that provides only a partial solution for larger commercial developers.
Yes, but my point is AVaRICE is dependent on Atmel releasing the specs or time-intensive reverse engineering to support the new mkII JTAGICE.
Agreed.
I'm all for more people working on the WinAVR project. But it would be much easier if AVR Studio and all the hardware tools were fully open from Atmel.
Or at the very least, open up the protocols involved.
If Atmel cannot give people the tools their developers want, and they don't make any money off the tools anyway, they should really open everything up. It would help them sell a lot more MCUs--which is, after all, what they're in business to do. They should not be in business to protect companies like IAR--a company that provides only a partial solution for larger commercial developers.
Again, agreed. But after writing about this very topic, I doubt it will go anywhere with Atmel. :evil:
Opening up AVRStudio and the protocols were suggeted to Atmel years ago, just before the Alfa version (Atmel called it a release version) release of AVRStudio 4.
As usual it fell for deaf ears.
Atmel claimed that AVRStudio 4 would have a documented plug-in interface, would support external compilers and much other.
This was in February 2001, and NONE of it has happened.
Surprised ? I'm not, and you probaby aren't either, if you've worked with (funny word here, "with") Atmel for a while.
They're full of sh^H^H hype !
They're totally in bed with IAR and the marketing people aren't bright enough to see that more (funtioning) tools would result in a wider customer base. It doesn't matter WHO makes the tools, as long as they work and are free (or at least cheap).
Some good comments Jesper. It would be nice if Atmel would see the big picture! When the AVR was introduced, it had little competition. But now, it has quite a bit of competition. I think Atmel probably started thinking "we have the best chips, we don't need good tools" but that is no longer true as they no longer have the best chips for many applications.
So now, with more MCU competition, I hope Atmel will see the need for better tool support. If not, they will lose more and more business to other vendors that do have good tool support.
Someday soon a small ARM/THUMB processor with onboard peripherals will be so cheap that 8 bit processors like the AVR may only be used for very small (< 2KB code) simple applications.
Right now, Philips has an ARM7 processor priced about the same as a Mega16. How much longer before we have $3 USD ARM (or "THUMB") parts with A/D, SPI, UARTs, USB, on board oscillators, etc? Sure, such a part might be overkill for that outdoor thermometer product, but if it's only $3 and has great tool support, why not use it?
For those building MP3 players around Mega128's, look at the new Analog Devices Blackfin processors--they're cheaper and more powerful.
For those doing low power projects, look at the MSP430 which does many things better than the AVR.
The competition is growing everywhere. Atmel should wake up and do something to differentiate the AVR from the rest. Their advantage could be better (instead of generally worse) tool support.
Another point that should be made is that releasing the Debugwire protocol does not require any effort on Atmel’s part. The ATtiny13 datasheet contains the following statement: “See the debugWIRE documentation for detailed description of the limitations.” Clearly documentation for Debugwire already exists and all that Atmel need do is post it on its web site. This simple act would establish the operating capabilities of Debugwire and allow designers to start creating products that utilize Debugwire. Atmel published the protocol for ISP in each and every datasheet at the dawning of the AVR. Why is the Debugwire protocol being handled differently?
Often, companies refuse to release technical documentation with the pretty stupid argument that it would result in a rise in technical support questions.
This is of course pure BS. They can just make the statement that the information is released for pure info, and that they don't support questions about it.
It may actually result in LESS tech support, because people got an answer to their questions, and doesn't need to experiment and reverse engineer.
If they think that not releasing the document on a protocol will keep users from hacking it and using it, they're more stupid than I thought.
All code (and HW) can and will be hacked, if it has any value to somebody.
Atmel should definitely be aware of the competition.
I will be swithing to the Philips ARM-7 chip in several new products, where I would otherwise have put the mega128.
It's low power (30 mA @ 60 MIPS, where the mega128 is about 20mA @ 16MIPS), much much faster (see above), and cost less.
And, there's a full GCC tool suite for it.
What are you waiting for ? :wink:
Yes, the Philips LPC2106 is a very valid competitor to the bigger Mega processors. It has 128K flash ROM, 64K SRAM and the usual collection of timers, uarts, SPI, etc.
Also, being an ARM7 device there are MANY solid development tools for it. Even the expensive IARpeople have a $499 USD starter kit that gets you a development board with the LPC2106, a JTAG ICE, a 32K code limit version of Embedded Workbench C/C++, C-Spy debugger, their MakeApp utility and even a limited version of their $10,000 visualSTATE code generator!
So for just a little more than the price of an AVR JTAGICE and an AVR development board, you can have a 32 bit ARM 60 MIPS processor, dev board, ICE and a full suite of well proven and powerful commercial tools!
IAR obviously isn't doing Atmel any favors in offering the Philips development kit (Atmel does make ARM processors, but they're not price competitive with the LPC2106). Why is Atmel seemingly doing IAR favors by not opening up their development tools?
Come on Atmel, open up your tools before the competition lures much of your AVR business away!
:arrow: According to using the debugwire to program the device, this is actually possible, but is limited to flash, eeprom, and lockbits but the fuse bits, except for its own fuse-bit "debugwire enable", are not accessible. The debugwire is using the same principles as the bootloader by using the SPM instruction.
However, all parts are shipped with the debug wire disabled so u have to use an alternative programming interface to enable the debugwire, e.g. ISP.... This is because you cant get complete controll of the OSC. while using debugwire when going to sleep and therefor the chip will consume more power than expected, (like JTAG).
Atmel also states that the debugwire is not intended to be an alternate programming tool interface.
Regards
Z
This is welcome news Zainka. How/where did you obtain your information?
Simple enough, I called them.... :mrgreen:
hello
I will be swithing to the Philips ARM-7 chip in several new products, where I would otherwise have put the mega128.
It's low power (30 mA @ 60 MIPS, where the mega128 is about 20mA @ 16MIPS), much much faster (see above), and cost less.And, there's a full GCC tool suite for it.
What are you waiting for ? :wink:
sounds really interesting, didn't thought that an ARM-7 µC is that cheap. i asked a distributor for the price of a LPC2124FBD64 (256kB Flash/16kB RAM) and the price is only app. 30%-40% higher then the atmega128.
has anybody her experience with the Philips ARM-7?
how much code is it producing in comparison to an atmega?
how is the quality of the tools?
many thanks in advance
gerhard
The Philips LPC2114 ARM7 with 128K Flash and 16K SRAM (four times what the mega128 has) is about $7 USD for 250pcs. With ARM you have the option of using the THUMB instruction set for 8/16 bit instructions or the full ARM instruction set for 32 bit work. Two THUMB instructions fit in the space of one 32 bit instruction.
For a mix of 8/16 bit or 32 bit work the ARM/THUMB combination is at least as code efficient as the MEGA128 because it can do 16 and 32 bit operations in a single instruction where the AVR cannot. It uses a similar RISC instruction set. For mostly 8 bit work, the AVR will probably be a bit more efficient.
But if you can get a 128K 32 bit ARM part for the price of a Mega32, and it runs much faster (60Mhz), efficiency is no longer so important for many applications! In general, the LPC2100 series will far outperform the AVRs. The A/D's, for example, run up to 500KS/s. There are also such nice things as a built in real time clock.
The LPC2104 has most everything the MEGA128 does except it's a 48 pin part with no A/D and is priced at $5 for 250pcs. The LPC2114 is a 64 pin part with 10bit A/D and are about $7. They also have controllers with CAN built in and up to 256K flash and 64K SRAM for just a little more.
There are many development tools for ARM including GCC/GNU, Green Hills, Keil, Metroworks Codewarrior, IAR and others. ARM is the most widely used embedded architecture for new applications in the world. It's in most newer PDA's (Dragonfire, X-Scale, etc.), many cell phones, most low-end network routers, WiFi equipment, MP3 players, home audio gear and MUCH more. There are more than a dozen different vendors supplying ARM embedded processors that I know of and I think the ARM folks have more than a hundred total licensees.
As I mentioned above, Atmel also makes a few ARM processors but they're not price/feature competitive with the new ones from Philips. I also mentioned IAR has a rather attractive (especially for IAR!) ARM development kit for $499 USD. By the time you buy an AVR JTAGICE, STK500, STK501, Mega128 and C-compiler , you'll spend more than that but have a lot less. You can get more basic development kits based on the GCC tools for under $250.
hello,
many thanks for your comments.
here a useful link to the lpc2xxx family:
http://www.lpc2100.com/
regards
gerhard
