AVR Freaks

AVR Microcontrollers, megaAVR and tinyAVR

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

Posted by ph0rkeh: Sun. Nov 13, 2011 - 11:47 PM

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.

Tags:

Level: Raving Lunatic

Joined: Mon. Jul 23, 2001

Posts: 3500 View posts

Location: Rheine, Germany

Posted by sternst: Mon. Nov 14, 2011 - 01:02 AM

[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

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

Posted by ph0rkeh: Mon. Nov 14, 2011 - 02:01 AM

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?

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

Posted by ph0rkeh: Mon. Nov 14, 2011 - 02:11 AM

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?

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

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Mon. Nov 14, 2011 - 09:34 AM

Intel Hex is explained here:

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)

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

Posted by ph0rkeh: Wed. Nov 16, 2011 - 02:01 AM

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 :)

Level: Raving Lunatic

Joined: Mon. Jul 23, 2001

Posts: 3500 View posts

Location: Rheine, Germany

Posted by sternst: Wed. Nov 16, 2011 - 09:57 AM

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

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Wed. Nov 16, 2011 - 09:59 AM

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

Level: Raving Lunatic

Joined: Mon. Jul 23, 2001

Posts: 3500 View posts

Location: Rheine, Germany

Posted by sternst: Wed. Nov 16, 2011 - 10:15 AM

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

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#10

Posted by clawson: Wed. Nov 16, 2011 - 10:26 AM

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

Level: Raving Lunatic

Joined: Mon. Jul 23, 2001

Posts: 3500 View posts

Location: Rheine, Germany

#11

Posted by sternst: Wed. Nov 16, 2011 - 10:40 AM

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

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

#12

Posted by ph0rkeh: Wed. Nov 16, 2011 - 04:26 PM

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

Level: Resident

Joined: Sat. Nov 25, 2006

Posts: 771 View posts

Location: Independence, OH

#13

Posted by ph0rkeh: Sat. Nov 19, 2011 - 09:49 PM

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.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#14

Posted by clawson: Sat. Nov 19, 2011 - 10:57 PM

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