Atmel AVR development tools

It's not that simple. The JtagMkII is only usb, but I have had all these problems with real hardware serial ports as well as USB serial, even Digi's Edgeport which is a first-class unit.

Might be interesting to try a machine with W98 on it and see if studio still flakes out.

I keep hoping it's something I'm doing. That's fixable, I just need to know what to do/not do .

Interesting comment re bootloaders, why do you say that? I just wrote another one, the first was for the M128 and this one for the M168. I am the paranoid sort that does readback verify, sets the lock bits, etc.

One place where I HAVE seen odd behaviour in the chip, is with the default low power crystal oscillator. The low power "vittoz" mode osc can cause cycle skipping in some parts of the chip with the sorts of wierd errors you'd expect from that. VERY nasty as it usually works just fine. That's the CKOPT fuse in the M128. Just make sure you never use one without programming that fuse. The factory default is to enable the low power osc..

The AVR bootloader has to contain the subroutines for erasing and programming. Those subroutines can be activated accidentally by an electric glitch, software bug, cosmic ray, unholy spirit or something like that. Although this event is not very likely, I have observed the failure rate due to that at the order of one per 5k units per year in the harsh EMI environment.

The safer approach would be loading the subroutines to RAM from the outside only when you need to reflash the device. However this can't be done with the AVR.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Theoretically, I agree, but that would be true of anything really, and any routine in the system.

My biggest experience with bootloaders was millions of credit card terminals. The feature was WELL worth it, any problems that the bootloaders gave us were so far down in the noise as to be unobservable. Our harshest environments were Ski resorts and Las Vegas/Reno casinos. Cold dry air and industrial carpeting make for some impressive ESD problems. These systems kept their operating program in SRAM, and the loader/ interpreter in ROM, so it was a bit safer that way.

I like how the AVR implements the loader, and both the loader, and the lockbits can be used to prevent writes to the loader itself. In my case, the system may end up with a bunch of small peripheral processors who all need to be updated from the core processor, so I'm pretty much forced to use it, or forego the ability to do an upgrade without disassembly and special tools.

In my loader, when the loader boots, it checks the lock bits, and if they aren't set properly, it sets them. Then while loading, it examines the page addresses, and prevents any attempt (even though it wouldn't work) to write to the loader space. Wild app code could try to overwrite the loader, but I don't use the SPM instruction anywhere in my application code, so there isn't a routine that could accidentally run, and even if it did, it would be prevented by the lock bits.

The routines up in the loader space exist, and could trash the app, but I'd have to have multiple and very exact failures to cause them to over-write the loader itself. As long as that's true, I'm good. Systemwise, I have bigger threats.

Very often, the bootloader does not boot. I have tried serial and usb boot loaders. They just stop working suddenly. I can still erase and reflash the chip with spi. Same thing with jtag debugging. Jtag would fail to response, but spi always work.

AVR runtime core and spi programming is the only thing I trust. Otherwise, i would be looking for another uC.

Yes, the biggest weakness of the AVR is accessibility of the sram from spi.

It wouldn't do you much good, since its harvard architecture lacks the possibility to run code from RAM.

Another weakness, at least for my applications, is that I often run out of RAM space, while the flash isn't even half full.

The AVRs are also fairly expensive. Digikey sells devices from the LPC2xxx family for less than some of the Atmegas. With the LPCs, you get more memory, nice peripherals such as 32 bit timers, and smaller packages.

I've never actually run out of SRAM.

I've had to overlap my buffers, like in a UPC/EAN/UPC-E/EAN-8 barcode reader that handled 2 and 5 digit supplementals in forward and reverse. There, I had to overlap the input and output buffers, and the stack, but I got it all into a 2343. Codespace was a bit tight, 7 words left.

It seems to converge on the the connectors. Have you tried resoldering them? Also PCBs have a tendency to fail (often intermittently) near connectors.

HTH

Joseph2k

No, unfortunately. This is across multiple platforms, processors, debuggers, you name it. The root problem here is that Studio is unreliable.

Jtag... I stay clear from jtag. I've been burned too many times by using jtag. I write my code on a PC first and then port it over to an embedded platform. Many times I use a big embedded controller which can support some debugging aids like a command line interface. When everything works fine, I move the project to the final controller.

Just two questions. How many target boards (or whatevers)? Is it (Are they) plugged in repeatedly?

It really dosen't apply. I've had these problems with studio for a long time now. (years) I've used MANY target boards, connector problems are not the issue.