AVR-Chat

I have successfully compiled the Atmel Butterfly demo program after converting
it from CodeVision to WinAVR(gcc) ... (at least I'm now at the point where I
just get warnings about 'char' types being used as array subscripts, etc. which
I'll address later).

I used AVRStudio to program the butterfly via JTAG with the Butterfly mounted on
an ECROS Technologies Butterfly carried board.

When I brought up AVRStudio and programmed the m169 I got the following from
AVRStudio:

...... start ..............
Loaded objectfile: C:\Documents and Settings\Charles Hackett\My Documents\AVR
Stuff\Butterfly\Copy of Demo Application Source\main.elf

JTAG ICE: Warning: Execution stopped on boot loader reset vector.

JTAG ICE: Warning: Boot reset fuses are programmed, but the program entry
function is located in the application section. Wrong boot reset fuses will
probably cause erronous execution.

JTAG ICE: Warning: If this is not an error, this check can be disabled in the
'Debug' section in the JTAG ICE options.
...... end ..............

The Atmel hex file was running fine before I tried my version.

Fuses are set as follows (to my knowledge these are 'as shipped'):
 
JTAGEN 			(JTAG Enable)
SPIEN				(SPI Enable)
BOOTSZ=00 			(4096 words)
BOOTRST			(Boot Reset vector enabled)
BODLEVEL=1			(Brownout 2.7v)
CKSEL=0010, SUT=10 	(2Mhz RC Osc.)

Lock Bits are set as follows (to my knowledge these are 'as shipped'):

Mode 1: No memory lock features enabled
Application Protection Mode 1: No lock on SPM and LPM in Application Section
Boot Loader Protection Mode 1: No lock on SPM and LPM in Boot Loader Section

I am only somewhat familiar with compiling for and loading an 'application' to
an AVR (ATMega16's and 128's).  I am not at all familiar with the intricacies of
boot loaders and would prefer to let that go for another day.

I have looked at the application code, and from what I can tell, the only 'boot'
stuff it has in it is a section of code that enables the Watchdog Timer and then
enters an infinite loop waiting for the AVR to be reset and (I assume) enter the
boot loader.

I thought that, since I'm compiling the Atmel demo, that all would be well and
that the application and boot loader would cooperate but I guess there is
something about this setup I don't understand.  So ...

Since I am currently loading the Butterfly using the JTAG interface can I
disable the boot loader but leave it in memory in case I want to use it later?  

To accomplish this do I just un-program the BOOTRST fuse?

On the other hand:  If I wanted to recover the memory for use in my application
how would I go about it and how do I restore the boot loader at a later time?

Thanks for your time in helping me along ...

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

As follow-up to my first message in this thread:

I verified that I can reload the original Butterfly program (hex file from
Atmel's site) and it still works fine - nice to have a "known good" point to
start from and return to :-)

I then cleared (unprogrammed) the BOOTRST fuse and my WinAVR version of the demo
program can now be programmed by AVRStudio via the JTAG without errors.

It now starts normally (as shown by the debugger) but does not function
correctly yet.  I'm sure that it has something to do with my translation from
CodeVision to WinAVR.

One thing I've discovered that is different from my debugging days on mainframes
and minis is that it's difficult to 'step' through code (w/AVRStudio) because of
the frequency of interrupts (LCD scan completion in my case).  I'm thinking
that, rather than use the debugger "step" function, the best approach would be
to manually advance a breakpoint as I go (aside: I would have thought that
"step" would have been doing this internally).

I also discovered that, when I tried to compile the demo with optimization = 0
(to make debugging easier), the code was too big (122% full) for the available
program memory so I compiled it with opt=s (85% full).  I may go back and try
some other optimization levels to strike a compromise.

Am I going about this (debugging, opt, etc.) correctly or are there other
techniques I should employ?

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

Quick question to someone who has done this recently - the last time I 
used SRAM on a micro, I used 6116 and 6164 memory (actually more 
recently I used 4164 DRAMs with a Z80!)  ...

I can certainly spend time looking at the data sheet to work this out, 
but on a Mega64 or 128, using external memory, if I'm running a 16 Mhz 
clock with a 74AHC373 address latch, ..

1. what speed SRAM will I need for zero wait states?

2. What generally available 32 k byte or larger SRAM chip are 
generally available these days? I'm assuming the 62256 SMD chips that 
are readily found on many 10 year old PCBs (HDDs, etc.) are now very 
hard to source, and certainly unwise to use in a new design.

Peter.

OK,

anyone have any experience with the Cypress 128 k Byte ram chip

   CY7C109B-15VC     (Digi-Key = CY7C109B-15VXC)

Sure, overkill (15 nSec) if I only need 1/4 that RAM, but available 
for a few dollars.

Peter

Peter Gargano wrote:

> Quick question to someone who has done this recently - the last time I 
> used SRAM on a micro, I used 6116 and 6164 memory (actually more 
> recently I used 4164 DRAMs with a Z80!)  ...
> 
> I can certainly spend time looking at the data sheet to work this out, 
> but on a Mega64 or 128, using external memory, if I'm running a 16 Mhz 
> clock with a 74AHC373 address latch, ..
> 
> 1. what speed SRAM will I need for zero wait states?
> 
> 2. What generally available 32 k byte or larger SRAM chip are 
> generally available these days? I'm assuming the 62256 SMD chips that 
> are readily found on many 10 year old PCBs (HDDs, etc.) are now very 
> hard to source, and certainly unwise to use in a new design.

In my quest for more RAM on an M128 ...

Of course, sadly, I'm answering my own questions here, but 
nevertheless, a few SRAM chips I've looked at, including the Cypress 
CY7C109B have a guaranteed VOHmin of 2.4 Volts (at -4 mA) but the 
Atmel's VIHmin is 0.6Vcc, or 3.0 Volts, when run at 5.0 Volts. This 
says that, if the data bus is loaded by at least 4.0 mA then the SRAMs 
high bits are not guaranteed to be seen by the processor.

I see a number of boards, that are commercially available, use an M128 
connected to this same part (or similarly spec'd part), so I can only 
assume it does work. But clearly this is not a desirable situation.

Here's an example using the Cypress CY7C1019

   http://www.bdmicro.com/images/mav2re2_vsm.jpg
   http://www.bdmicro.com/images/mav2b_phtv_ann1b.jpg

and using the Samsung KM681000 (VOHmin of 2.4 Volts (at -1 mA!!!)

  http://www.prllc.com/productcart/pc/catalog//128MMC.jpg

Anyone think I'm just over cautious?

Peter.