Re: [avrdude-dev] Reading and writing a calibration byte in an ATTiny12

[James A.R. Koehler]

Yes, I do, thanks for pointing it out.

However, even if I omit line with the second programming command (i.e., 
where it programs the PPM_AT12.hex file), and just have the line where 
avrdude should just program the single byte at 0x3ff, it programs the 
whole flash from 0 to 0x3ff - and exits with an error.  My question is 
why doesn't it just program that single byte?

Nick Lott wrote:
> don't you also need the -D option to disable auto erase?
>
> On 9/07/2006, at 5:07 AM, James A.R. Koehler wrote:
>
> >  I've written a script which should work but it doesn't (famous last 
> > words). It is below:
> >
> > /#!/bin/sh/
> >
> > /# shell script to read the calibration byte in an ATTiny12/
> > /# and write it to location 0x3ff in the flash memory/
> >
> > avrdude -p t12 -P /dev/ttyUSB0 -c stk500v2 -U cal:r:cal.tmp:r
> > /#/
> > /# then, my C program to read cal.tmp and create an/
> > /# Intel hex file named cal.hex/
> > /#/
> > *.*/get_cal
> > avrdude -p t12 -P /dev/ttyUSB0 -c stk500v2 -U flash:w:cal.hex
> > avrdude -p t12 -P /dev/ttyUSB0 -c stk500v2 -U flash:w:PPM_AT12.hex
> > *exit* 0
> >
> > The second last line is to program the rest of the flash with the 
> > program I want in it: PPM_AT12.hex.
> >
> > My C program, get_cal, reads the single byte cal.tmp file and writes 
> > an Intel hex file to put that byte to location 0x3ff. For this 
> > particular ATTiny12, the calibration byte was 0x31 and the hex file 
> > produced is show below:
> >
> > :0103FF0031CC
> > :00000001FF
> >
> > This Intel hex file cal.hex, is just two lines long and should just 
> > write the calibration byte to a single byte in the Tiny12's flash 
> > memory. However, when avrdude executes this instruction, it programs 
> > all 1024 bytes of the flash up to and including the 0x31 at location 
> > 0x3ff. Should it do this?
> >
> > avrdude also gives me an error saying that the byte at 0x0201 is 
> > incorrect after programming. Just in case I had a faulty ATTiny12, I 
> > ran the script file with another ATTiny12 on another board and got 
> > the same result. The byte at 0x3ff is, indeed, programmed to 0x31 so 
> > it works in that sense.
> >
> > Any ideas?
> >
> > > >    I'd prefer to do this using avrdude in a Linux machine.  I think
> > > > I should be able to do this in the 'terminal' mode of avrdude but,
> > > > because I'd like to program a number of these processors in one
> > > > session, I'd rather do it with a script file.  Is this possible?
> > >
> > > Terminal mode is meant for human interaction.
> > >
> > > What you need is to capture the output of avrdude when reading the
> > > calibration value, and then use it to subsequently produce a new intel
> > > hex file from it.
> > >
> > > To capture it, you can use:
> > >
> > > cal=$(avrdude -p ... -c ... -P . -qq -U cal:r:-:r | hexdump -e '/1 
> > > "%02x\n"')
> > >
> > > This leaves a two-char hex value in the variable "cal".  Then you need
> > > to produce a new ihex (or S-record) file, as that is the only possible
> > > input that would allow you to specify an offset for where to program
> > > it to.  The ihex format should be reasonably specified, so you could
> > > write a small python or perl script for it.  I'd assume you might
> > > already find modules for that job somewhere in the Internet.
> >
> >
> >
> > _______________________________________________
> > avrdude-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
>
>
> _______________________________________________
> avrdude-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avrdude-dev