AVR ISP Programming Serial

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys;

I have created a simple set of functions to utilize ISP. I have successfully done the following:

Read device signature
Read high&low fuse bits
Read calibration bits
Read lockbits

But I am having issues trying to understand the read/write from program memory. Mainly it says its uploaded by word/page.

Word is just a 16 bit right? Whats a page?

I setup a simple function trying to read the first 3 'words' from a traget device; I get the following results: (ProgMem1:3)

[M32] >> Received response from target, gathering data...
[M32] >>  
[M32] >> DeviceSig: 91
[M32] >>  
[M32] >> LockByte: ff
[M32] >>  
[M32] >> lFuse: ee
[M32] >>
[M32] >> hFuse: df
[M32] >>  
[M32] >> exFuse: ff
[M32] >>  
[M32] >> CaliByte: 58
[M32] >>  
[M32] >> ProgMem1: c074
[M32] >>  
[M32] >> ProgMem2: c081
[M32] >>  
[M32] >> ProgMem3: c080
[M32] >>  
[M32] >> Done.

This was just a shot in the dark; but I did get data which is nice. But; here is the first few line from the .hex file on the target2313:

:1000000094C0A1C0A0C09FC09EC09DC09CC01EC186
:1000100047C199C098C097C096C095C094C093C07E
:1000200092C091C090C00A0D3E3E20436F6D706C2F
:100030006574652E0A0D003E3E4F55545055543A96
:1000400020003A00213E204552524F523A204E6F36
:100050002070726573656E636520666F756E642EC1

I dont understand how they translate; or am I way off here? Could anyone provide me some information on how the read/write to program memory and EEPROM are performed? and if those first 3 'words' look correct..

*edit: Also; am I correct in thinking the .hex file is what is uploaded to the AVR? For somereason I have that in my head; of course I do not have extended knowledge of the innerworkins of the AVR-GCC libc toolchan or the programming interface avrdude; or how they work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
[M32] >> ProgMem1: c074
         HEX-File: C094

[M32] >> ProgMem2: c081
         HEX-File: C0A1

[M32] >> ProgMem3: c080
         HEX-File: C0A0

Your software incorporates a difference of 0x20 somehow.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting. I put in a printf to grab the data right after its recived and im printing the same result as I get:

[M32] >> CaliByte: 	58
REF:C0

REF:74

[M32] >> ProgMem: C074
REF:C0

REF:81

[M32] >> ProgMem: C081
REF:C0

REF:80

[M32] >> ProgMem: C080
[M32] >> Done.

What about the first C094 though? In the hex there is no C0 its 00?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OH wait I see. It looks like in the hex file the first 8 bits? are the line. Now I understand a bit more about the datasheet too:

10000000
10001000
10002000
10003000
=
1000 - 0000
1000 - 1000
1000 - 2000
1000 - 3000

or even:
1-0
1-1
1-2
1-3

could that mean:

page 1 -line 0
page 1 -line 1
page 1 -line 2
page 1 -line 3

or something on those lines, maybe?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Intel Hex is explained here:

http://en.wikipedia.org/wiki/Int...

The Example pretty much explains everything:

http://en.wikipedia.org/wiki/Int...

(as this is nothing to do with GCC in particular I'll move this to AVR Forum or you'll face the wrath of Bob)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked into all that hex stuff and starting to understand it a bit more.

I re-flashed my attiny2313 target (a mega32 is reading these values) so I know the hex im looking at is the same as on the AVR.

This run I got better results.. kind of:

      :C094C0A1C0A0C09FC09EC09DC09CC10A
:1000000094C0A1C0A0C09FC09EC09DC09CC00AC19A

      :C133C099C098C097C096C095C094C093
:1000100033C199C098C097C096C095C094C093C092

      :C092C091C0900D0A3E3E43206D6F6C70
:1000200092C091C090C00A0D3E3E20436F6D706C2F

      :74652E650D0A3E004F3E545555503A54
:100030006574652E0A0D003E3E4F55545055543A96

      :0020003A3E2145205252524F203A6F4E
:1000400020003A00213E204552524F523A204E6F36

      :702065726573636E20656F666E752E64
:100050002070726573656E636520666F756E642EC1

      :2E2E632065686B6363206E6F656E7463
:100060002E2E20636865636B20636F6E6E6563740C

      :6F69736E2E2E002E0D0A0A003E0D203E
:10007000696F6E732E2E2E000A0D000A0D3E3E2073

      :6F436D6D6E6120646552696365763A64
:10008000436F6D6D616E6420526563697665643A95

      :00206C50616565736920706E74756120
:100090002000506C6561736520696E707574206115

The hex I dumped is the top (the line are like this: first line: My dumped hex, second line is from the .hex file and then a blank line.)

You see lines one and two match good. (I assume i am supposed to generate the checksum and then of course leave out the addressing bits. Im not sure what the first byte of each line is...) but anyways a little bit into the 3rd line it starts to not match anymore and then jumps back and from.

Does anyone have any information on this that could help shed some light? this is really interesting me at this point.

and any help would be greatly appreciated :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but anyways a little bit into the 3rd line it starts to not match anymore and then jumps back and from.
What do you mean? The 3rd line is also entirely correct.
     : C092 C091 C090 0D0A 3E3E 4320 6D6F 6C70
002000 92C0 91C0 90C0 0A0D 3E3E 2043 6F6D 706C 2F 

You know the AVR is little endian, so the high and low byte in the HEX are swapped, don't you?

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stefan

So what happened in the first two lines? Also in both the .hex and (I guess) his hex dump the bytes are just sequential as you'd read/write them in flash surely?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
So what happened in the first two lines?
They are correct too.

     : C094 C0A1 C0A0 C09F C09E C09D C09C C10A
000000 94C0 A1C0 A0C0 9FC0 9EC0 9DC0 9CC0 0AC1 9A

     : C133 C099 C098 C097 C096 C095 C094 C093
001000 33C1 99C0 98C0 97C0 96C0 95C0 94C0 93C0 92

It was pure luck that ph0rkeh came to the same conclusion with his wrong comparison method.

clawson wrote:
Also in both the .hex and (I guess) his hex dump the bytes are just sequential as you'd read/write them in flash surely?
Apparently he has dumped words in his hex dump, not bytes. ;-)

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I see. What confused me is his own hex dump starting with ':' (haven't a clue why!). I therefore assumed (I know!) the first byte was a count, not data. I wonder why one would have dumped words? Surely the obvious mechanism is:

for (uint16_t i=CODE_START; i

rather than:

for (uint16_t i=CODE_START; i

??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I wonder why one would have dumped words? Surely the obvious mechanism is:
Yes, but ...
ph0rkeh wrote:
I have created a simple set of functions to utilize ISP.
...
I setup a simple function trying to read the first 3 'words' from a traget device; I get the following results:

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh the : is just a splitter every 16bytes.

I see now, I wonder how why I didnt notice that. I guess just because the first two seemed to line up so nice.

Thats just great.

Also i noticed that it seems to read the target 2313 at any spi clock speed /32 to /8. Does it really matter which speed I use? Would one be better then the other? I did a test where I dumped 18 bytes in all speeds they all seemed to dump exactly the same. The target is 10Mhz.

edit* And the master (mega32) is 14.7Mhz

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Works great now. I got the main controller a mega32 (can be made into a smaller one, i need the space for prototyping). At the moment it can do alot:

Read/Write fusebits/Calibits/extended/lockbits

Read/Write EEPROM

Enters a load external eeprom mode 24LC256 which allows you to transfer a .hex file via uart to the eeprom.

allows you to program the target with the eeprom memory.

you can dump the current hex on the target (if not locked)

and a couple more things.

Whats the easiest way to generate a clock signal for chips that had been accidently programmed with wrong fusebits? Is it as simple as just creating a square wave? i would like to add that to this project, along with HVP programming.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Whats the easiest way to generate a clock signal for chips that had been accidently programmed with wrong fusebits? Is it as simple as just creating a square wave?

Yes - read my "locked out" article in Tutorial

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did it even cheaper... I have a ton of tiny25s laying around... I simply programmed one to put CKOUT on PB4 and ad the main m32 switch it on when an external clock source is needed. I did this because I could not find a good schematic for using a 555 timer to generate a square wave greater then 50Hz and most importantly I didnt want the main controller doing it as its cannot multi-task it. I dont think it would work because while programming it cannot stop and flip an IO and so on..

The whole project was a learning experience I have already wrote the schematic and tore it down because really I can just use my programmer, laptop, & AVRdude to perform the same tasks; faster, more stable; and more options.