ATmega128 eeprom question

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

Hello
Can anyone tell me what values I can expect to find in the eeprom of an ATmega128 fresh out of the tube?
I think recall reading threads that describe a problem with writing to a particular location. Is anyone aware of this? Do you have any details?

Thanks,

A

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

lots of FFs?

Imagecraft compiler user

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

bobgardner,

Is this guaranteed?

Thanks,

A

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

No, but if you erase the EEPROM during flashing the program then it is. Have a look to the fuses several CPUs can keep the EEPROM contents otherwise it is erased.

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

Quote:

Can anyone tell me what values I can expect to find in the eeprom of an ATmega128 fresh out of the tube?

A non-issue--any "real" ISP sequence is going to do a signature check, followed by a chip erase.

If you care to, you could certainly read the EEPROM of fresh chips but I cannot imagine any utility.

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

OTOH if you were using EEPROM I guess your programming sequence may involve putting an initial set of (none 0xFF) values in a .eep file into it?

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

Quote:

OTOH if you were using EEPROM I guess your programming sequence may involve putting an initial set of (none 0xFF) values in a .eep file into it?


Yeah, but then you do a chip-erase first.

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

Yes but when the code comes to read the EEPROM it won't find it to be all 0xFF any more - that was the point I was making.

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

All,

The reason I ask is that we need to assign a serial number to new units. I thought if I checked one or two locations for the serial number data then I could determine if the serial number had been assigned to this unit.

The serial number is a string of about 12 characters and digits.

A

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

THen it is the programmers responsibility to program the location at blast time.

Simply put the info into the .eep file and then you are good to go.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Jim,

This is probably the way I would go if I was only programming one or two units. I will need to be doing about 12 to 24 at a time. I do not want to reload my ISP with every new board. Add to that the need for the units SN to match the one applied to the PCB.
I think it would be easiest to do this from after QC and programming.

Thanks,

A

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

I could be missing the point, but couldn't you initially do a chip erase, put in the serial# in eeprom, set fuses as needed + program the EESAVE fuse. Then anytime afterwords, any chip erase during normal programming will leave eeprom untouched and you will also know the serial# is already programmed because reading the fuses will show at least the EESAVE bit is programmed (and if not programmed = no serial# yet).

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

curtvm,
Perhaps its me that misses the point.

Each unit needs to have its own individual SN. This number is generated through our internal tracking, so at some point that code must be stored in the controller.

In order to do this with the ISP I would have to change the data in the file, reload the ISP and then program the micro. This would need to be repeated for each unit. If the tech enters the SN when after the unit is tested then he can refer to the SN printed on the PCB and this will ensure that they match.
The other point I have left out is that we will modifing the eeprom if the unit is upgraded in the field. This prevents us from using EESAVE.

Thanks for the input.

A

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

How do you get a serial number on a circuit board from a manufacturing process? I bet you dont. All the boards are identical. They are manually altered by a human. So all the programs could be identical, and they could be manually altered by a human. Is the requirement to make a costly and complicated multistep process so the process engineer can publish a paper on how to reduce productivity? Tell us why the avr needs to know the serial number on the circuit board? Whats he do with it?

Imagecraft compiler user

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

bobgardner,

Thats what we do. We make machines to put codes on just about anything. ( Beer bottles, Car trim, Visa cards and even chocolate bars ) visit us at www.ijp.ca to get an idea. So for us this is a two minute job. Not only can we do the printing on the card but we can get one of our controllers to automatically generate the SN.

Why do we want to ID a circuit board and a micro?
There are several reasons for an ID on a circuit board.
1) At times we have over dozen controllers and related hardware in our shop for service. Keeping track of what we have in the shop and who it belongs to is critical.
2) One of the failures we see on occasion is a totally dead controller. Without being able to power it up we cannot determine what the internal serial number is so it must go on the board as well as in the micro. The board is inside a hand held enclosure so reading the serial number on a controller that works is easy to do if it powers up.
3) Our industry has become highly competetive with $10,000.00 sales being lost over a couple of hundred dollars difference in quoted price. So we plan to reduce the cost of our basic product by disabling features and allowing the end user to enter an option code for a fee to enable the options they need. The option code will be keyed to the serial number of the product to keep our customers ( and distributors ) honest. In our industry there are several companies doing this so we need to compete.

A

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

As I recall there are some ISP systems that have serial number ability. I can't remember what compilers/IDEs/ISPs might have it.

I have an app that required this facility. I seem to remember threads about it at that time; perhaps a determined search can ferret them out.

I made a VB6 program for entering the serial number and doing the ISP. Here is the sequence of events; YMMV depending on your tool chain.

-- I allocate memory for the "serial number" in an otherwise unused area of EEPROM, and give it an initial value so that it is part of the .EEP file.

-- I "know" that the CodeVision compiler will then generate a separate Intel HEX record for this 8-byte value at the designated address. YMMV.

-- So now I have a firmware set of base.HEX and base.EEP.

-- The VB program gets a new serial number from the operator. The VB program creates a new thisone.EEP file, reading records from base.EEP until the "magic record" is found. It then constructs a new magic record in Intel HEX format with the proper checksum for the serial number information, writes that record and then copies the rest of the file.

-- The VB program then kicks off an ISP session using a .BAT file that invokes STK500.EXE that does ISP with base.HEX and thisone.EEP.

-- The output of STK500.EXE session is captured, shown on the screen, and examined in the VB program for magic strings that indicate success or failure.

Lather, rinse, and repeat.

We were going to do a barcode scan of the board/unit label to eliminate the manual entry but decided it wasn't worth it for a batch of, say, 100 every few months.

It works OK, but was somewhat of a pain to get the VB + batch + STK500.EXE + results set up, and have the correct full file names for base.HEX, base.EEP, and STK500.EXE into the program. And the only way I had success was to do a full AVRStudio downlad and install, just to get a "working" STK500.EXE of modest size properly installed.

Lee

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

Lee,

At our end we can use one of our print systems to automatically generate the serial number and print it on the board without any operator input.

The tech has to handle the controller for testing anyways. This includes a test of the keypad operation. With initial testing the tech will prompted for the serial number from the PCB. Only after the serial number is entered will the tech be able to proceed with his testing.

A

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

Quote:
Can anyone tell me what values I can expect to find in the eeprom of an ATmega128 fresh out of the tube?
I have no idea, but unless I saw a document that guarantees an avr always leaves the factory erased, I would assume its not (even though it may normally be the case).
Quote:
I thought if I checked one or two locations for the serial number data then I could determine if the serial number had been assigned to this unit.
If there is an app in the avr, a chip erase was done, so the eeprom is in a known state. Your serial# eeprom locations are all 0xFF (until tech man enters serial#). We are back to a point earlier in this thread. It seems. I can be wrong.

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

curtvm,

Thanks,

A

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

I always use a byte or several bytes in a bit pattern that is not likely to be something in a random set of EEPROM bytes. Like 0xA5 or 0x5AA5 or along those lines. These are my "programmed key" to tell me if I have messed with it.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

JIm,

I think my plan is to put our serial number in a standard location. Some of the characters are fixed so I will do what you suggest and check for those.

Thanks,

A

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

theusch wrote:

As I recall there are some ISP systems that have serial number ability. I can't remember what compilers/IDEs/ISPs might have it.

I have an app that required this facility. I seem to remember threads about it at that time; perhaps a determined search can ferret them out.

I made a VB6 program for entering the serial number and doing the ISP. Here is the sequence of events; YMMV depending on your tool chain.

-- I allocate memory for the "serial number" in an otherwise unused area of EEPROM, and give it an initial value so that it is part of the .EEP file.

-- I "know" that the CodeVision compiler will then generate a separate Intel HEX record for this 8-byte value at the designated address. YMMV.

-- So now I have a firmware set of base.HEX and base.EEP.

-- The VB program gets a new serial number from the operator. The VB program creates a new thisone.EEP file, reading records from base.EEP until the "magic record" is found. It then constructs a new magic record in Intel HEX format with the proper checksum for the serial number information, writes that record and then copies the rest of the file.

-- The VB program then kicks off an ISP session using a .BAT file that invokes STK500.EXE that does ISP with base.HEX and thisone.EEP.

-- The output of STK500.EXE session is captured, shown on the screen, and examined in the VB program for magic strings that indicate success or failure.

Lather, rinse, and repeat.

We were going to do a barcode scan of the board/unit label to eliminate the manual entry but decided it wasn't worth it for a batch of, say, 100 every few months.

It works OK, but was somewhat of a pain to get the VB + batch + STK500.EXE + results set up, and have the correct full file names for base.HEX, base.EEP, and STK500.EXE into the program. And the only way I had success was to do a full AVRStudio downlad and install, just to get a "working" STK500.EXE of modest size properly installed.

Lee

 

Thank you for giving this suggestion, you must be experienced.