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

[James Koehler]

The byte at 0x3ff does get written correctly.  When the first avrdude
command to write the cal.hex file is executed, it should first erase the
flash, which it does, then write a single byte which it doesn't.

On Sun, 2006-09-07 at 11:14 +0900, Nick Lott wrote:
> yeah my understanding is that is you use the -D option it should just  
> program the one byte and exit.
> If you omit the -D option it should erase the chip and then program  
> one byte.
> 
> is the address in bytes or words? if in bytes then 0x3ff is byte  
> number 1023, but if address is in words then 0x1FF is byte 1023
> 
> perhaps you need to make an ihex file that uses 0x1ff as the address  
> instead of 0x3ff
> 
> just a thought. see where your byte ends up.
> 
> On 9/07/2006, at 11:06 AM, James A.R. Koehler wrote:
> 
> > 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
> >>
> >
> >
> >
> > _______________________________________________
> > 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