Attiny flash corruption while using Atmelice Programmer

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

Hi
I'm new to this forum.. Need help.. I'm using atmelice programmer to program attiny 2313 device on board.. I find the programmer does t programming of flash, fuse and lock bits, and the verification is also done.. But when I compare t dump data of flash content and lock bits with the source hex file. flash seems to be corrupted and lock bit is corrupted.. But the programmer verify this and passes... The voltage level seems ok.

Not sure how the atmelice passes the verification even though the flash has a corrupted data and lock bits.
Also how the corruption happens..
For the verification command I give a commnad to verify the flash content against the source hex file.

This is not happening on all the PCB with attiny 2313 it happens only on few pcb's.

Note: I use atmel studio6.2 version(OS winxp)
I use ICT BON fixture for programming.

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

Tell what you >>do<< read back.  Perhaps post the .HEX of a test program, and the read-back version.

 

My guess is that you are setting the lock bits.  So what you read back is not the actual flash contents.  (It varies, but you may see an incrementing address.)  There are many prior threads on this, if that is the case.  Are you setting the lock bits?  To what value?

 

senthil_eeemnm wrote:
I'm using atmelice programmer

OT:  Can you use atmelice in a sentence?

 

"Why are you combing and combing your hair with those fine teeth?"

"I'm trying to get at-me-lice."

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Feb 13, 2018 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

But when I compare t dump data of flash content and lock bits with the source hex file. flash seems to be corrupted and lock bit is corrupted

OF COURSE!! If you program the lockbits then the data read back is rubbish.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hi,
Let me list t steps I do. First I check whether the flash is pre-programmed if not I do a chip erase and then program the flash with the source file and then do a verification of flash comparing against the source file(I'm yet to program the fuse& lock bits) the verification passes here. Then I write the fuse bits and verify it against the source file. Then write the lock bird verify it against the source file. Once the flash, fuse and lock bits are programmed and verified then I configure an output file to take a log of all the flash fuse and lock bit. When I verify the log files of flash content the contents are corrupted and the lock bits dump I different compared to source file.

But the PCB passes here but when I try to boot the PCB in another system level test this attiny fails to boot on further analysis found the flash and lock bits are corrupted. My query after the lock bits are programmed then reading of dump is invalid ok but when I program the flash with the source file the programmer programs and create a log file inside which it stated "verification of write ok" immediately after this I do a verification of flash against the source file. Here if there is a corruption in the flash the programmer should have failed in the verification but instead the programmer passes the verification ( at this moment the lock bits are not programmed),so the programmer can read the flash content. But the programmer reads the flash contents and passes even if there is a corrupted data. Same is the case happening for lock bits.

I can share the commands I use and the lock bits files

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

When I verify the log files of flash content the contents are corrupted and the lock bits dump I different compared to source file.

So after you set the lockbits you expect the flash to read the same as what you programmed? Do you understand what the lockbits do? What do you think they do?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hi,
Let me list t steps I do. First I check whether the flash is pre-programmed if not I do a chip erase and then program the flash with the source file and then do a verification of flash comparing against the source file(I'm yet to program the fuse& lock bits) the verification passes here. Then I write the fuse bits and verify it against the source file. Then write the lock bird verify it against the source file. Once the flash, fuse and lock bits are programmed and verified then I created a dump file.

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

Hi js,
If I'm not wrong lock bits are used for protecting t program and memory data.

If u go through my steps I mentioned l. I do a programming of flash (flashing only the data) at this moment I didn't write the fuse bits or lock bits and I can read back t memory.. After programming of flash I give a verify command comparing the memory data against the source file l..the programmer passes the verify test but the same board is not booting up in my functional test I have an led indication stating that the flash is corrupted..

With the same scenario few pcb's that have passed the flash verification tests boot successful in functional test.

The corruption happening here is intermittent....

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

Before setting the lock bits I do a flash verification against the source file.. If the flash has a corrupted data then the programmer should have failed the test this is not happening...

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

If I'm not wrong lock bits are used for protecting t program and memory data

Correct! So how do you expect to read the data you just programmed if you lock the chip? And what do you mean by the data? EEPROM? Ram cannot be "programmed".

 

As far as the board not working I can't help, I'm only trying to tell that once the lock bits are set you can no longer verify or read correctly the chip.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hi Js,

 

Flash Programming

 

printer is "ABC_epv_result";echo

Filename$="program/ABC/xxxxx_flash.hex" -- > Source file location

 execute "atprogram -t atmelice -i ISP -d ATtiny2313 -cl 128khz program -f "&Filename$,Err;append  --> Flash programming

 

assign @READ to "ABC_epv_result";read

   loop
      enter @READ,,Err;Line$
      exit if Err<>0
      if pos(Line$,"Programming completed successfully") then Flash_Status$="PASS"
   end loop

   assign @READ to *

 

In the above I create a log file ABC_epv_result and check for line "Programming completed successfully" if present the flash is programmed correctly.

 

fuse bit programming

printer is "ABC_fuse_result";echo

execute "atprogram.exe -t atmelice -i  ISP -d ATtiny2313 write -fs -v --values E2DBFF",Err;append

 

assign @READ to "ABC_fuse_result";read

   loop
      enter @READ,,Err;Line$
      exit if Err<>0
      if pos(Line$,"Verification of write OK") then Fuse_Status$="PASS"
   end loop

   assign @READ to *

 

In the above I create a log file ABC_fuse_result and check for line "Verification of write OK" if present the fuse is programmed correctly.

 

Lock Bit Programming 

printer is "ABC_lock_result";echo

execute "atprogram.exe -t atmelice -i  ISP -d ATtiny2313 write -lb -v --values FE",Err;append

 

assign @READ to "ABC_lock_result";read

   loop
      enter @READ,,Err;Line$
      exit if Err<>0
      if pos(Line$,"Verification of write OK") then Lock_Status$="PASS"
   end loop

 

In the above I create a log file ABC_lock_result and check for line "Verification of write OK" if present the lock is programmed correctly.

 

 

execute "atprogram.exe -t atmelice -i  ISP -d ATtiny2313 write -lb -v --values FE",Err;append  --> programming lock bits with FE (LB1 as 0 & LB2 as 1)

in the lock bit write i write the LB2&LB1 with 1&0. as per the datasheet if LB2,LB1 is 10 then further programming of flash is disabled and can read the flash In case if the LB2& LB1 are 00 then further programming & verification of flash is not possible.

 

snap of datasheet attached.

 

After this i create a dump file of Flash content, Fuse bit & lock bit.

Folder_Dump$ ="/log/"

 

   OutFile$ = Folder_dump$&"_flash_u3510"
  execute "atprogram -t atmelice -i ISP -d ATtiny2313 read -fl -f "&OutFile$,Err;append  --> Read the flash

   OutFile$ = Folder_dump$&"_fuse_u3510"
  execute "atprogram -t atmelice -i ISP -d ATtiny2313 read -fs -f "&OutFile$,Err;append  --> Read the fuse bits

   OutFile$ = Folder_dump$&Serial$[1;12]&"_lock_u3510"
  execute "atprogram -t atmelice -i ISP -d ATtiny2313 read -lb -f "&OutFile$,Err;append  --> Read the lockbits

 

When i open the above dump files i find the flash and lock bits are corrupted (but this happening on only few boards) 

 

 

 

 

 

Attachment(s): 

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

I use Atmel Studio for programming, everything else is gooblygook wink no idea at all what you are doing above. Maybe someone else knows.

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Yes, automating a test procedure and making a log is useful to YOU. It is not much good to us humans.
.
Please quote a few lines of your output HEX file together with the corresponding lines from the input HEX file.
Do this for Flash, Fuse, Lock.
.
If your top secret program is too sensitive, just create a regular public project and follow your same procedure.
.
After you set some lock bits you can read but receive gobbledygook. To stop master criminals reading your secret program.
.
David.

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

Hi,

 

I did the following steps as below:

 

Used STK 500 Programmer to Program the flash, fuse and lock bits and verified it and took a dump of the flash fuse and lock bits. compared the dump files against the source file the dump is matching. 

(atmel studio 4, with win xp OS)

 

the same board i tried to verify using ATMELICE Programmer the programmer had passed the verification and took a dump of flash, fuse and lock bit and passed the board. When i compare the flash,fuse and lock bit dump against the source file the dump shows a corrupted sector. 

 

Not sure how come the atmelice programmer passed the verify command.

(Atmel studio 6.2, Win XP OS)

 

any idea.. this looks silly but i'm scratching my head. Not sure whether to suspect on the verify command i use or suspect on the hardware or is that a bug in the atmel studio???

 

command i use for verify in Atmelice

 

Filename$="programming/S-M3002-11050_flash.hex"
execute "atprogram -t atmelice -i ISP -d ATtiny2313 verify -fl  -f "&Filename$&"",Err;append

 

 

 

command i use for verify in STK500

 Filename$="programming/S-M3002-11050_flash.hex"
 execute "STK500/stk500 -cISP -ms -dATtiny2313 -if"&Filename$&" -vf -GFF -FDBE2 -LFE",Err;append

 

 

 

 

 

 

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

You have repeatedly been asked to post the "good" .HEX file, and the "bad" .HEX file read back from the chip.  At least for me to have any continuing interest, you need to do this.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Sharing snap shot of comparison between good hex and bad hex is that ok???