Re: [avrdude-dev] Problems reading writing fuses to at90s1200 with stk500

[Klaus Rudolph]

Hi Jan-Hinnerk, hi list
 >
> > Seems to be a much bigger problem here...
> >
> > As I looked a bit inside the code the fuse bits will be read out
> > with the
> > universal command what is not possible with actual firmware I
> > think. Instead the commands 0x72 (ReadFuseBit) 0x77
> > (ReadFuseBitsExt) and 0x73 (ReasdLockBits)
> > should be used.
> 
> I agree that it is not the best way to handle things (and it will not 
> work in parallel mode).
> 
> However, I can't see why this should fail on newer firmware unless the 
> universal command has been removed.

It would also not work in serial mode, .... the fuses could not set in
serial mode :-)
Maybe the fuse setting works for other devices with the newer firmware and
the
universal command. 
> 
> > I have changed the SPI to parallel programming in the setup, but
> > this is not enough.
> 
> Of course, the universal command won't work in parallel mode ;-(
> 
OK. If it is so, it should be simple to remove this completely because the
other commands
0x7x will work in serial and parallel mode. If you can advice me a bit, I
will bring in the
parallel mode into avrdude. 

> > As I think after 2 hour of code inspection there is a
> > avr_read_byte_default function which
> > uses for stk500 the stk500_cmd function which is not correct for
> > fuses I think.
> 
> Yes, that's the way it works.

Fine. The code is not as easy as it could be. Again a project which uses
object oriented
features without a object oriented language... Nobody out there like c++ or?
> 
> > Also for at90s1200
> > the function readLockBits (0x73) must be used to read fuse bits.
> > (This info comes from tracing
> > avr-studio and reading the AVR061 document).
> 
> Well, it would not be too hard to change the code to use the 
> appropriate functions.

Yes. But for all the pieces of code which uses universal command... lots
todo.
I miss a bit the functions like write_fuse, read_fuse and so on. It is more
organised in different memory sections (flash..., eeprom... and maybe
fuses????)
Not found that yesterday. Only saw the byte functions... OK 2 hours is not
enough
to dig all infos from more than 1000 lines of code :-)



> 
> However, I don't know how the parameters to these functions are 
> interpreted. It would be very bad, if the same value would result 
> different fuse-settings depending on the programming mode.
> 
> Do you know of any documentation?
Yes. It is downloadable from avr.com. The AppNote 061. Here the full
protocol for stk500
is documented. There are a lot of hints for comming software versions which
maybe change bits or
bytes. 

> Is the STK500-source available somewhere?
Yes. If you have an older sw-version you should be able to trace simply the
serial 
communication and extract the software during the softwareupdate with
avrstudio :-).
But that is not what is allowed at all and
I think is absolutly not needed here. 

I wrote a year ago the patch for the uisp which enables it to programm all
in parallel mode.
That work fine. So all needed functionality is in uisp, but not in the main
cvs path. I dont
know why, but Tod wont it there. If you are interesed in my actual uisp
implementation I can send
you a copy... but I think we should give avrdude a chance :-) It is not good
to support 2 tools here.
It is enough that we have two simulavr here ...

> 
> > Additional an other error was found. The command 0x45 needs 4 bytes
> > info and not 5! The code
> > holds an n_params+1 line. Thats not correct as I look inside the
> > avrstudio trace for that.
> > Currently it doesn´t matter but for future firmware?
> 
> I think you are right.

And now?
In hope I can spend a bit more time to avrdude I will bring in the parallel
mode for
stk500. BUT! older firmware will not longer be supported after that patches.
I think it is not
the best way to support all the older firmware versions with sometimes uses
universal command and
sometimes the 0x7x commands. The code will grow to much and will not be
readable anymore.
Maybe there could be a check first and the new code s only enabled for newer
firmwar. But this is not nice and
not needed because the update for the firmware is costless at all. Load
actual avrstudio from
avr.com and do the update. Thats all.

If it is acceptable for all the users here I can do the things in the next
weeks but I need an agreement that the 
patches will go to main development tree. I don´t spend my time for
elaborate a solution that is lost in
space. One time for uisp is enough! Sorry, but my time is also not costless.
In hope 
that is acceptable. 

For coding styles and tests there should be one guy which support that
change here. In hope there is one...

Thanks
   Klaus

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++