programming atmega48/168's

comp.arch.embedded
programming atmega48/168's

	I have been programming an atmega168 for the the last few weeks with 
no trouble. Today an atmega48 was put in the 168's place, and the programming 
failed. From a quick look, there appeared to be a timeout when polling the 
flash af0ter a buffer had been written. That was a quick look at the end of 
the day, though.
	Has anyone here found differences in the programing of the two 
versions that might explain this error?

Hul

Programing method is serial. I forgot that in the last message.

Hul

Hul Tytus <ht@panix.com> wrote:
> comp.arch.embedded
> programming atmega48/168's

>         I have been programming an atmega168 for the the last few weeks with 
> no trouble. Today an atmega48 was put in the 168's place, and the programming 
> failed. From a quick look, there appeared to be a timeout when polling the 
> flash af0ter a buffer had been written. That was a quick look at the end of 
> the day, though.
>         Has anyone here found differences in the programing of the two 
> versions that might explain this error?

> Hul

Hul Tytus wrote:
> comp.arch.embedded
> programming atmega48/168's
> 
> 	I have been programming an atmega168 for the the last few weeks with 
> no trouble. Today an atmega48 was put in the 168's place, and the programming 
> failed. From a quick look, there appeared to be a timeout when polling the 
> flash af0ter a buffer had been written. That was a quick look at the end of 
> the day, though.
> 	Has anyone here found differences in the programing of the two 
> versions that might explain this error?

Am not having any problems programming a 48 over DebugWire with a 
Dragon. Quite to the contrary, it works great once DW is enabled via 
ISP. Having more problems keeping a connection with a 164P over JTAG, 
wishing for DW on the 164P.

My 48 is running from internal oscillator at roughly 8 MHz.

On 09/11/2007 Hul Tytus wrote:

> comp.arch.embedded
> programming atmega48/168's
> 
> 	I have been programming an atmega168 for the the last few weeks with 
> no trouble. Today an atmega48 was put in the 168's place, and the
> programming failed. From a quick look, there appeared to be a timeout
> when polling the flash af0ter a buffer had been written. That was a
> quick look at the end of the day, though.
> 	Has anyone here found differences in the programing of the two 
> versions that might explain this error?
> 
> Hul

Apart from the obvious differences of Flash and RAM size, what are your
fuse settings? The fuses in the mega48 behave differently from those in
the 88/168.

-- 
John B

John - the differences in fuses shouldn't (...) make a difference. Only 
the lo fuse is set and the others are left as they are.

But, the failure is apparent when trying to verify data written 
to the flash and that might be indicative of serial programming not 
being enabled, ie the hi fuse.

Anyone know what unenabled serial programming looks like?

Hul

John B <spamj_baraclough@blockerzetnet.co.uk> wrote:
> On 09/11/2007 Hul Tytus wrote:

> > comp.arch.embedded
> > programming atmega48/168's
> > 
> >       I have been programming an atmega168 for the the last few weeks with 
> > no trouble. Today an atmega48 was put in the 168's place, and the
> > programming failed. From a quick look, there appeared to be a timeout
> > when polling the flash af0ter a buffer had been written. That was a
> > quick look at the end of the day, though.
> >       Has anyone here found differences in the programing of the two 
> > versions that might explain this error?
> > 
> > Hul

> Apart from the obvious differences of Flash and RAM size, what are your
> fuse settings? The fuses in the mega48 behave differently from those in
> the 88/168.

> -- 
> John B

	The difficulty was caused by the at48's load buffer size differing 
from that of the at168, of which the programming software wasn't aware. Once 
fixed, all worked well.
	Thanks for the various suggestions.

Hul

dbr@kbrx.com wrote:
> John - the differences in fuses shouldn't (...) make a difference. Only 
> the lo fuse is set and the others are left as they are.

> But, the failure is apparent when trying to verify data written 
> to the flash and that might be indicative of serial programming not 
> being enabled, ie the hi fuse.

> Anyone know what unenabled serial programming looks like?

> Hul

> John B <spamj_baraclough@blockerzetnet.co.uk> wrote:
> > On 09/11/2007 Hul Tytus wrote:

> > > comp.arch.embedded
> > > programming atmega48/168's
> > > 
> > >       I have been programming an atmega168 for the the last few weeks with 
> > > no trouble. Today an atmega48 was put in the 168's place, and the
> > > programming failed. From a quick look, there appeared to be a timeout
> > > when polling the flash af0ter a buffer had been written. That was a
> > > quick look at the end of the day, though.
> > >       Has anyone here found differences in the programing of the two 
> > > versions that might explain this error?
> > > 
> > > Hul

> > Apart from the obvious differences of Flash and RAM size, what are your
> > fuse settings? The fuses in the mega48 behave differently from those in
> > the 88/168.

> > -- 
> > John B