Maker Pro
Maker Pro

Atmel AVR development tools

D

dbvanhorn

simple solution, get a computer with a real RS-232 port on it, and use
that option, using RS-232 converters or direct USB I find is unreliable
not just for that process but for other things that really need the
attention of the PC also.

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.

   I Also find that when I used older versions of windows I have much
better luck .. 98/W2k is what I normally use for programming the units.

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

dbvanhorn

The AVR debug core is unreliable, jtag or non-jtag.  SPI programming
is much more reliable.  Also, avoid bootloaders.

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..
 
V

Vladimir Vassilevsky

dbvanhorn said:
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?

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
http://www.abvolt.com
 
D

dbvanhorn

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.

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.
 
L

linnix

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.

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.
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.

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

Arlet Ottens

linnix said:
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.
 
D

dbvanhorn

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

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.
 
J

Joseph2k

Frustrated, not knowing where to turn with this.

I love theAVRprocessors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Different computers, including ones freshly scrubbed and rebuilt.
Different processors
Different date codes
Different cables
Different serial or USB ports
Different versions of Studio
Different target boards
Different clock sources, including the internal 1 MHz RC
Different VCC (within spec)

Common threads: XP Pro. AVRStudio (though different versions), Me.

Short version, neither they nor I can figure out WTF is going on.
I've seen it, in the past week, 1: Decide that all my code is NOPs in
sim. 2: Ignore CALL or RCALL instructions. 3: Ignore some LDI
instructions, but not all, just specific ones. 4: Totally refuse to
talk to the target chip with Debugwire. And tomorrow, it will
probably be different.

All that said, for months at a time, everything will be fine.

Any ideas?

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
 
D

dbvanhorn

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


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

Nico Coesel

dbvanhorn said:
Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Any ideas?

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.
 
J

Joseph2k

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

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

dbvanhorn

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.
 
Top